構築中。

名古屋のITインフラお守り係です。ITイベントへの参加記録などを残していきます。

Security-JAWS【第 30 回】[Security-JAWS DAYS] ~Day1~（8/26）

イベント・勉強会

同僚 2 人と一緒に現地参加しました。

s-jaws.doorkeeper.jp

（本当は 4 人で参加予定だったのですが 1 人事情でキャンセルになり残念）

配信（期間限定？）

全体を通しての感想

「とにかくやらなきゃいけないことがたくさんあるな」でした。

利用アカウントの都合で Organizations まわりが足を引っ張っている印象があるので、そこから整理しないとセキュリティに（本格的には）進めない…。

最初のパート（おやつ休憩 1 回目まで）

Verified Permissions、認可をアプリケーションロジックから切り離すのに使えるサービスっぽいですが、リリースのアナウンスを見たとき、「わかるような、わからないような…？」感じだったんですよね。

認可ルールを定義するのに正規表現を使うと、「理論上の正しさ」は OK でも負荷の面で NG なことはよくありますね（正規表現爆弾…）。

染みついたやり方はそう簡単に変えられないという…。

…予定被ってた。残念。

油断していると増えるとか新しいシナリオに変わるとかで慌てて発表のために追加で体験しないといけなくなるあるある。

こっちのパターンも。

「クラウド以前」を経験していないと、どうしてもネットワークの知識不足がネックになりがち。

あと（直前で触れられていた）IAM まわりも大事。

他の方が触れられていましたが、クレジット（クーポン）の確保、大事ですね。

後のセッションに出て来ますが、Network Firewall（といいながらメインは IPS かな？）プロダクト環境に入れるか悩みますね。

（個人的な意見は決まっていますが、なかなか「お気持ち表明」しづらい…）

「お勧めできないワークショップ」一番手は「動かないワークショップ」でした。

（なわけない）

そして「お勧めしたいけど候補に入れられないワークショップ」まであるとは。

セキュリティにバリバリ絡んでいるのにタグに「Security」が付いていないという…。

ちょうどこの構成を使っているので気になります。

「ページ数が多すぎた」そうで。

NIST SP800-190 の翻訳版、ちゃんと読んでおこう。

別のポリシーを混同して思い切りハマりました。

その他、Inspector v2 でのイメージ脆弱性調査やそれ以前の段階でのチェックについての話が。

Sysdig さんの話は 1 〜 2 年前にオンライン勉強会か何かで聞いていたのですが、うっかり忘れていました。

創業者が過去に Wireshark を作っていた話も思い出しました。

なので、やられた後が大事、と。

この業界、略語が多すぎて紛らわしいのなんとかなりませんかね…。

2 つ目のパート（おやつ休憩 2 回目まで）

密かに気になっていたセッションです。

みなさん反応されていましたが、IPS だと WAF よりシグネチャ更新は高頻度ですね（守る対象が多いから当然か）。

あとみなさん IPv6 対応も気にされていましたが、思いがけず空前の IPv6 学習ブーム到来？

（弊社はわたしと SRE チームリーダー以外無反応…）

たとえ使わなくても、「使う理由」と同じくらい「使わない理由」が大事な気がしますし。

話を聞いていて「あー、あれの件だったか」と思い出しました。

目立ちますからね。

「脆弱性を生んだメンタルモデル」として「新技術こそが優れているという思い込み」と「AWS に対する過度な信頼と責任共有モデルの理解不足」が挙げられていましたが、個人的にはもっと単純（？）に、対象のシステムを開発していた時期は

世の中の多くがこの程度の認識だったのでは？という気がしなくもないです。

その後、2019 年までの間に「そうじゃない」という雰囲気は出て来たものの、サイバーセキュリティ・チームの人たちの定着性の悪さも相まって、過去に作られた部分が放置されたままに…？

この話の中では「情シス」ではなくてサイバーセキュリティ・チームの人たち（すごい勢いで離職）でしたが。

反応を見ていると、透過的暗号化とか鍵管理（の重要性）とか理解が難しいのかな、と思いました。

あと、IDMS の件に絡んで「169.254.169.254 にアクセスさせたくない場合、169.254.169.254という文字列をフィルタで落とすだけではダメ」というのも思い出しました。

Snyk（サービス）は利用を検討していたのですが事情で止まっていたりします。

一方、CodeGuru はこの問題の解消の見通しがないので採用できず。

アプリケーションではなくて IaC のコードのほうは、CDK がこの状態でちょっと残念。

Datadog のブースには後ほど挨拶に行き、骨に見立てた T シャツをいただきました。

（Small Size 以外は骨に見えなかったのは内緒）

などと言いつつわたしは Oracle 屋さんじゃないのであっちの ASM には縁がないんですけどね。

多層防御が正常に動いている分には良いのですが、いざ誤検知の疑いが出てくると、この問題が…。

3 つ目のパート（最後まで）

この分野は（リアルに）素人なのですが…。

「初期設定、途中でコケたのが運の尽きで進めず・戻れず」で文鎮化したりしないのかな…？

ドローン、「直接電波が届かない（から通信できない）」ところでは使えない・使わない」んでしょうか…？

（リアルに素人なのでよくわかっていない）

ここもちょっと気になっていました。

これから調べる身にとってこれはちょっと辛そう、かと思いきや、導入自体は簡単、との声が。

（簡単だからこそ資料が更新されないのかな？）

あと「IdP 死んだときの対策は別途必要」というのはシングルサインオンするときは大事なことですよね。

Policy as Code についてはノーマークだったので、まず話を聞いて存在を知ったことが収穫でした。

（このセッションではまともなことをポストしてなかった…）

Config は一度しっかり確認しておかないといけないなー、と思いながらつい後回しにしていました。

（Organizations 絡みの問題もあり）

アカウント削除後 90 日間内部的なリソースが残る点は注意が必要ですね。

クロージング→帰路

個人的に新幹線の無料 Wi-Fi サービスに繋ぐのがあまり好きじゃないので、トンネルを意識しつつ、数セッションごとに区切って複数の回答に分けて書いて送信しました（読みづらかったと思います。ごめんなさい）。

良かった！

非常に運良く絶妙のタイミングで帰ることができました。

みなさま、ありがとうございました＆おつかれさまでした！