イベント概要
Session1: AWS WAFの運用を地道に改善し、自社で運用可能にするプラクティス
登壇者：宜野座 清貴（株式会社アンドパッド 開発本部セキュリティグループ テックリード）
セッションレベル：Level 300（中級）
- ANDPADにおけるWAF導入の課題と対策
- CloudFront、ALBにAWS WAFをアタッチ、ログはS3+Athenaで解析したりDataDogに転送したりしている
- 環境間の差分
- 個別ルールのコード化が不十分、手動での更新をしてしまっていたのが原因
- 知らぬ間に変更が起きても気付けない、、、
- まずは差分を愚直に洗い出し、IaC管理を徹底した
- コードからの反映のみに制限したことでdiffをすぐ確認できるようになった
- 個別ルールのコード化が不十分、手動での更新をしてしまっていたのが原因
- Terraformの大量差分
- 差分が膨大で「多分大丈夫だろう」という判断になりがちだった
- マネージドルールのバージョン更新で1行更新しただけでも大量の差分が出てくる
- WAFのルール記述をJSONに切り出してレビューをしやすくした
- 差分が膨大で「多分大丈夫だろう」という判断になりがちだった
- AWSマネージドルール更新の追随
- アップグレードに追随しきれず本番環境への適用が遅れた
- RSSの更新を通知させることに加えて、Countルールを活用した
- 偽陽性への後手対応
- ログが膨大で精緻に確認できない、実際のお客様が困っているのかどうかもわからなかった
- DataDogなどでALBのBlock発生を検出するようにした
- 顧客リクエストの可能性が高いパスはSlackに通知させた
- 結果、お客様からの問い合わせは減った
- WAFにおけるAI活用
- ログ分析の人手不足解消に活用
- LLMにログを食わせる、DevOps Agentの活用、など
- ログ分析の人手不足解消に活用
- まとめ
- WAFの運用に銀の弾丸はない
- 組織の状況に合わせて自社運用か外部委託かを最適に選択しよう
- 自社運用は大変だが、継続的な改善がチームの運用実感につながる
QA
- DataDogにCloudFrontではなくALBのログを送ったのはなぜか
- コスト削減のため
- Log 調査に AI 導入する期間はどれくらいの期間を見込んでいますか？
- 1,2ヶ月は必要ではと思っている
- WAFルールをtfファイルに直接ではなくjsonファイル読み込みで設定されているとのことですが、そうするとterraform planを見るだけではレビューができないと思います。コードレビューはどのようにされているのでしょうか？
- jsonファイルの差分とplan結果、2段階のレビューをしている
- コードからの反映のみに制限したとのことですが、具体的にどのように仕組み化したのでしょうか？
- ロールによって編集権限を剥奪した
- CloudFrontとALBの双方にWAFを紐づけていたと思いますが、何らかの使い分けなどしていますか？
- 基本的にはALBで受け付けることが多い、公開されるものはCloudFrontに適用している
- CloudFrontにはあまり厳密なルールは適用しないようにしている
- 私も自社サービスのWAFログを最近AIで分析しています。私の場合はトークン消費量を減らすために一度生ログからpythonでデータ統計レポートを作成し、その結果をAIに食べさせて分析してもらっています。ANDPADさんではどのように分析しているのかを聞きたいです。
- まだ分析段階にAIは活用できてないのが現状
Session2: 「遊んで終わり」にさせない！ AWS BuilderCardsセキュリティ拡張パックで実装する、組織の脅威検知カルチャーとアーキテクチャ
登壇者：coosuke（某製造業）
セッションレベル：Level 300（中級）
- W-Aフレームワークとセキュリティ、BuilderCardsについて
- W-AフレームワークはAWS以外のクラウドベンダーも公開している
- セキュリティの柱を具体化するには4+1の柱が重要
- アクセス管理
- 防御
- 検知
- 対応
- 学習（＋１の部分）
- セキュリティの柱を具体化するには4+1の柱が重要
- W-Aフレームワークが言っていることは抽象的、実際に現場で実装するにはハードルが高い
- そのコストを埋めるためにBuilderCardsのセキュリティ拡張パックが活用できる
- 拡張パックには脅威アクターとして4匹のペットアクターがいる
- 4層（アプリ＆ランタイム、データ＆ストレージ、ネットワーク＆インフラ、アカウント）の多層防御を模擬している
- ペットアクターを検知して対応することでペナルティを免れる
- 検知と対応にはそれぞれ必要なAWSサービスがある
- 拡張パックには脅威アクターとして4匹のペットアクターがいる
- 検知と対応をセットで考えるのは、実際のインシデントレスポンスを模擬している
- セキュリティ対策の「4+1」のメソッドに完全に対応しているのが拡張パック
- 実際に起こさずに体験できる
- 複数のメンバーでやることが知見の共有になる
- そのコストを埋めるためにBuilderCardsのセキュリティ拡張パックが活用できる
- W-AフレームワークはAWS以外のクラウドベンダーも公開している
- 今後のBuilderCardsの方向性
- 詳細はNoteを参考に
- 開発者のDavidさんがAWSを退職され、メンテナンスモードに移行
- JAWS-UG Leaders有志でワーキンググループを立ち上げている
- 新しいアイディアを具現化動きもある、乞うご期待、、、
QA
- BuilderCardsはどこで買えるのか
- 英語版はAmazonで買える、日本語版はJAWS-UGの各種イベントでもらえる（かも）
Session3: 実例から学ぶ、GuardDuty (SSH BruteForce) 調査の全体フローと勘所
登壇者：水品 亜久里（株式会社サイバーセキュリティクラウド セキュリティエンジニア）
セッションレベル：Level 300（中級）
- GuardDutyで実際に検知したSSH BruteForceアラートについて
- CSCさんとの契約前にいただいた相談、EC2に対して外部から大量のSSHログイン試行が検知された
- SSH BruteForceではOSログが重要になる
- 侵害されたのかどうかの確認に利用できる
- スナップショットを共有してもらい調査を開始
- ルート権限で実行された不審なプロセスを発見
- 不審な外部IPへの接続も確認
- プロセスの実行ファイル作成日とアラート発生日が同じ、静的解析の結果マルウェアと判定
- 動的解析を行なったものの、サンドボックス環境であることを検知されて動作確認ができなかった
- ルート権限で実行された不審なプロセスを発見
- 攻撃の概要解明
- 不正ログインを行いマルウェアを設置、マルウェアによって実行ファイルを配置して実行させた
- まとめ
- 今回はAWSが公開するEC2のアーティファクト収集推奨順序にしたがった
- https://docs.aws.amazon.com/ja_jp/security-ir/latest/userguide/collect-relevant-artifacts.html
- その他参考資料
- 揮発性が高いデータを優先して解析するような順序になっている
- 発生したアラートは放置せずに早期対策をすることが重要
- 今回はAWSが公開するEC2のアーティファクト収集推奨順序にしたがった
QA
- 0.0.0.0/0 での公開に至った経緯は分かりますか
- 経緯は不明
- EC2のログの推奨される保持期間をお聞きしたいです（会社のポリシーなどによって異なる部分はあると思いますが、一般的な推奨保持期間をお聞きしたく）
- EC2内にしかログが存在しておらず、数ヶ月前までしか遡れない状況だった
- 半年〜1年くらいが目安だとは思うがケースバイケース
- （発表の主題とは異なる質問かもしれませんが、）今回、EC2インスタンスにグローバルIPアドレスを持たせてインターネットから到達できるようにしておく必要性があったのでしょうか？
- 今回は特に不要ではないかと思っているが詳細は話せず、、、
- ANY.RUNで分析とおっしゃっていましたが、これはエンタープライズ版ですか？
- エンタープライズ版です
- GuardDuty の EC2 の Runtime Monitoring やマルウェアプロテクション機能は有効化されていたのでしょうか。また、有効化していた場合、侵害を食い止めることできるのでしょうか？
- 今回は有効化されていなかった、有効化されていれば早期対応に繋がったはず
- 用意されていたフォレンジック環境というのは使い捨てのコンテナ環境のようなものでしょうか？それともIaCが用意されていてそこからデプロイする感じなんでしょうか？
- 今回は前者
- DNS Firewall でのアウトバウンド通信の制限など、C2 サーバーへの通信を防止する何らかの仕組みは導入されていたのでしょうか？
- 今回はそこまでは不明
- 今回の相談に対してお客様にはどのような報告であったり推奨策を提案しましたか？
- お伝えするときに事実と解釈をはっきりわけて伝えていた
- 自身の痕跡/諸々のログを消してしまうようなマルウェアの調査は難しいと思いますがどのように調査を進めるのがいいでしょうか？
- 動的解析では難しいため、ファイルそのものの静的解析が有効だと考えている
- 今回のような規模のケースでは、相談受けてから調査結果報告完了するまでどのくらいの時間かかるのでしょうか？
- ケースバイケースではあるが、今回は1,2週間
- ログの削除ができなくするような設定はなかったのでしょうか
- 一定期間のログのみを保持するような設定がEC2に入っていた
Session4: 10サービス以上のメール到達率改善を地道に継続的に進めている話
登壇者：山口 隆史（株式会社エス・エム・エス SRE）
セッションレベル：Level 300（中級）
- タイトルには10サービス以上と記載したが、実際には30サービス50ドメイン存在していた、、、
- メール到達率を考えることになった背景
- 元々は個別に障害対応や問い合わせ対応をしてた
- 2024年2月に出たGoogleガイドラインが一つ目のきっかけ
- メール認証は「やっておくといい」ではなく「やらないといけない」ことになった
- 二つ目のきっかけはIPレピュテーション低下
- 迷惑メール判定などによりメールが送れなくなる可能性が出てきた
- どのサービスで、どの宛先で、どのような失敗が起きているのかを分析できていなかった
- 見える化して分析・対策する必要が出てきた
- 今回のユースケース
- EC2でメールリレーサーバーを構築・運用
- メール送信にはSaaSを利用
- SaaS利用時はFromとReturn-Pathが異なるのでSPFが通らなくなる
- SPFにincludeを足し続けるとDNS lookupの制限に当たるため、サブドメインを適宜切る必要がある
- include数は自分で書いたincludeだけはなく、DNS参照の合計で評価される
- グループアドレス、転送アドレスも利用している
- グループアドレスから個人に転送するが、退職者などのバウンスは送信側からコントロールできない
- DMARCレポートも万能ではない
- ユーザーが迷惑メール報告した理由、迷惑メール率が上がった原因、どの対策が効いたのか、などはわからない
- 送信元台帳を棚卸しすることで、誰がどのドメインでどこから送っているのかをいつでも説明できるようになる
- PostMasterToolsを使うことで迷惑メール率やIPレピュテーションはわかるが、どの宛先リストが悪いのか、どのメールが原因なのかなどはわからない
- アラートを上げることに使うのがベスト
- 共有リレーサーバーの課題
- 共有するとIPレピュテーション低下の影響が他のメールにも影響してしまう
- IPレピュテーションを低下させないことが重要
- サービス単体ではなく全体のIPレピュテーションを見る必要がある
- 低下し切るまでに介入することがまずは重要
- どうしようもない場合は対象メールを外してしまうこともあり
- 「見てるだけで終わらせない」が重要、地道な運用をするしかない
- 事業部と一緒に改善するところまで持っていくべき
- 説明する際には、送信元を説明できるようにしておくことが重要
- 共有するとIPレピュテーション低下の影響が他のメールにも影響してしまう
QA
- DMARCレポートから失敗するケースを修正し、その後 P=reject にするタイミングの見極め目安はありますか？
- 特にはない、合意が取れればいいと思っている
- quarantineにまずは持っていくようにしていた
- SESを利用しなかった理由
- 分析などを自前で全部できればSESでも良いと思ったが、外部業者の力を借りたかったのでEC2を採用した
- List-Unsubscribe ヘッダや BIMI に対する重要度や優先度みたいなものはどうお考えですか? 絶対やるべきなのか、送信者認証やバウンスの解消の方が圧倒的に重要なのであまり気にしなくてよいという感じなのか、そのあたりの肌感。
- 費用対効果によって考えると良いのではない
- DMARCレポート監視はなにかツール使われてますか？
- 可視化にはOSSを使っている
- 10サービス以上とのことですが、ドメインも別で10ドメイン以上ということでしたでしょうか？10本以上のメールの維持運用を何人体制でどのくらいの頻度でPDCAまわす時間をかけてますか？
- 50ドメイン、定例は10人くらいで実施し必要に応じて事業部の方にも参加いただいている
- 自社ではDMARC対応はしたもののまだnoneのまま。そろそろrejectなどに移行しないとまずいですかね？
- noneだとなりすましも増えてくるので、そのリスクも考慮して検討すべき
- IPやDNSのレピュテーションが悪化してペナルティを食らったことはありますか? ある場合にはどう対応しましたか?(いつ回復するかが読めないのでどう対応するのが良さそうか)
- 落ち切ったところまで行ったことはないが、IPを切り捨てたことはある
Session5: ポスト量子暗号の概要とAWSでの取り組み
登壇者：秋山 直輝（アジアクエスト株式会社 クラウドエンジニア）
セッションレベル：Level 300（中級）
- ポスト量子暗号がなぜ求められるのか
- ポスト量子暗号（PQC: Post-Quantum Cryptography）は、将来登場するとされる「量子コンピュータ」でも解読できない、次世代の暗号技術のこと
- アルゴリズムとして現在はRSA、ECDSAが使われる
- コンピューターの性能向上や攻撃手法の発達によって暗号の安全性が低下する危殆化のリスク
- 現在のアルゴリズムの安全性が2030年まで持たない問題（2030年問題）
- 量子コンピュータは入力ビットを大きくしても効果が薄い
- 今データを盗んでおき、あとで解析するハーベスト攻撃に量子コンピュータが利用されるリスクもある
- 生体認証データ、IoTデバイスのデジタル署名などがターゲットになりうる
- 今データを盗んでおき、あとで解析するハーベスト攻撃に量子コンピュータが利用されるリスクもある
- ポスト量子暗号の標準化
- ベンダー間での互換性、安全性の担保のために標準化が必要
- 現在はハイブリッドポスト量子暗号が推奨されている
- 既存のアルゴリズムと組み合わせることで、今までのアルゴリズムの実績を使いつつ暗号強度を高めることができる
- AWSにおけるポスト量子暗号
- 転送中のデータ保護を優先する
- 公開鍵暗号が侵害されるリスクがある
- 奪取しておいて後で解読（ハーベスト攻撃）のリスクが高い
- 公開鍵暗号が侵害されるリスクがある
- 保存データの保護は再暗号化の必要なし
- AES-256など共通鍵暗号はポスト量子暗号への耐性を持っている
- 署名アルゴリズムの提供
- アルゴリズムとしてPQC署名を利用することが可能
- セッション認証の保護は優先度が低い
- 証明書チェーンの効果、ハーベスト攻撃への耐性
- 転送中のデータ保護を優先する
QA
- 多くの企業にとっては、もしTLS 1.2以前を使っているケースがあるならまずTLS 1.3に移行することかな、と思いますがどうでしょうか
- まずはTLS 1.3への移行が大事ではある
- なぜこのテーマを選んだのか
- JAWS DAYSの時にCommunity Buildersになった報告をしたら、吉江さんから登壇してよと言われて、セキュリティ系でCfP通りそうなテーマを選んだw
Session6: AI飲み会幹事エージェントを作っただけなのに
登壇者：木美 雄太（Japan Digital Design株式会社 VP of Architecture）
セッションレベル：Level 300（中級）
- 飲み会幹事の作業を全て自動化する「Nominator」を作った話
- AIエージェント特有のセキュリティのとっかかりとなる話
- 事件編：AIエージェントのやらかし（※やらかしは作り話）
- 高級フレンチを即時予約してしまった
- 高級フレンチ好きな先輩がエージェントに偽情報を刷り込んでいた
- HRシステムから年収情報が漏洩してしまった
- 飲み会費用の傾斜付けの根拠に年収を利用し、年収を推測できるような傾斜付けにしてしまった
- 高級フレンチを即時予約してしまった
- 指針編
- ベースラインは先人たちの経験に頼るべき
- リスクは3段階で評価
- 従来同等のITシステム一般のリスク
- エージェントの頭脳に起因するリスク
- エージェントの身体全体に起因のリスク
- 特定したリスクに対する具体的な対策も先人たちの経験に頼る
- 環境によらないAIエージェント特有のリスク
- AWSにおけるAIエージェントリスク特有の対策
- リスクは3段階で評価
- ベースラインは先人たちの経験に頼るべき
- 分析編
- 高級フレンチを予約してしまった
- OWASP Top 10のうち「メモリ・コンテキスト汚染」、「人間とエージェントの信頼の悪用」の2つに関連
- 年収情報が漏洩
- OWASP Top 10のうち「ツールの誤用および悪用」に関連
- 高級フレンチを予約してしまった
- 解決編
- 最強かつ最大の対策 「それAIでやらないとあかんの？」
- AIエージェントのセキュリティを考える上で一番最初に考えるべき
- 決定論的な実行で実現できるのであればAIエージェントは不要
- 決定論的な実行で実現できない価値を絞り込んでいくのがセキュリティ向上、ユーザーの満足度向上にもつながる
- 確率論的な部分にAWS機能で対策できるもの（今日はインフラ実装にフォーカス）
- メモリ汚染への対策
- AgentCore Memoryの属性情報で記憶の信頼度を分類させる
- 名前空間、メタデータで信頼度を定義させておく
- AgentCore Memoryの属性情報で記憶の信頼度を分類させる
- ツールの誤用
- AgentCore Gateway経由でPolicyを適用することで、利用可能なツールをコントロール可能
- AgentCoreでは、インフラレイヤーから決定論的な制御・監査ができる機能を拡充しているようにも見える
- メモリ汚染への対策
- 最強かつ最大の対策 「それAIでやらないとあかんの？」
QA
- AIエージェントに携わっているのですごく参考になりました。例えば、ハルシネーションで架空のお店を出さないようにしている工夫などありますか？
- 今の所入れてはいない、ハルシネーションだけではなく「Human in the loop」なども組み合わせて考えるべき
Session7: Amazon Bedrock/SageMaker時代のガバナンス・ギャップを埋める——IAMとSTSから紐解く2026年の予防的セキュリティ
登壇者：ハオ / Hao Xue（Tenable Network Security Japan 株式会社 セキュリティエンジニア）
セッションレベル：Level 200（初級）
- AI時代のセキュリティリスク
- 開発スピードが急上昇している一方で、セキュリティレビューが間に合っていないのが現状
- 攻撃者の標的になる「空白地帯」が生まれている
- Tenable調べでの現状
- 過剰なIAM権限によるクラウド侵害：65%
- 未使用のまま放置されているSTSクレデンシャル：45日
- AIモデル以外の周辺インフラから侵害したケース：80%
- Bedrock（AI）は自律的なアクターであるため、「混乱した代理人」として悪用されるリスクが高い
- 開発スピードが急上昇している一方で、セキュリティレビューが間に合っていないのが現状
- 代表的なリスク4選
- IAM、Identityリスク
- Lambda実行ロールに「BedrockFullAccess」や「S3FullAccess」を付与している場合はプロンプトインジェクションによって侵害される可能性が高い
- さらに、権限昇格のリスクもある
- Lambda実行ロールに「BedrockFullAccess」や「S3FullAccess」を付与している場合はプロンプトインジェクションによって侵害される可能性が高い
- STS、セッションのリスク
- MythosによってSTSセッションの悪用が可能、AssumeRoleの期限は1時間だが攻撃するには十分な時間
- 認証情報管理
- バックドアになるような認証情報は無いか
- AIサプライチェーン
- 複雑な依存関係を悪用する攻撃、昨今増えている攻撃手法
- IAM、Identityリスク
- まとめ
- AIエージェントは過剰な権限をもつ自律的アクターとして扱うべき
- 攻撃経路のコンテキストで優先順位をつけるべき
- 放置されたクレデンシャルなどがないかどうか、自分の環境をまずは確認しよう
QA
- 自分もGitHubに公開する前にシークレット情報がないかをAIに調べさせますが、たとえAIがOKと言っても怖くて自分でも全コード確認しています。AIでコードを書くのは簡単になったものの自分でのチェックもあるので時間がかかりすぎで大変です。この辺の時間を削減することができますか？
- AIでのチェックで確認するのではなく正規表現を検知するなどの決定論的仕組みの方がよい
Session8: Claude Code / Codex / Kiro に AWS 権限を渡すとき、何を設計すべきか
登壇者：足立 和生（アジアクエスト株式会社）
セッションレベル：Level 300（中級）
- Claude Code / Codex / KiroでAWS APIを使う場合にフォーカスした話
- コーディングエージェントがAWSを触れる経路の制御（※AWS操作＝AWS APIの実行と定義）
- 現状、AIエージェントが本番環境を触る経路が増えている
- やらかしはリソースの誤削除だけではなく、見せてはいけないものが見えてしまう、設定を変えてしまうなど色々なパターンがある
- やらした場合にAIエージェントがやったのかどうかを判断できるのか？
- CloudTrail（プリンシパル）にはAIの名前は残らない
- 人間用のロールをAIにそのまま渡すと、AIのやらかしが人間のせいになる
- AI用のロールを作っておく
- 現状、AIエージェントが本番環境を触る経路が増えている
- Claude Code / Codex / Kiroの比較
- ユーザー向けの企業はいたちごっこになりがちなので比較軸にならない
- ID管理、権限制御などのエンタープライズ向けの機能で比較すべき
- Claude Code
- managed ruleでMCPやskillsを中央管理可能
- 監査ログをOTelやログ基盤に転送できる
- 割と万能な機能を保有している、端末の実行制御を細かく絞れる
- Codex
- 万能ではあるがCodex側でデータを持つところがある
- AWSとの接点がまだ薄い
- Kiro
- AWS管理プレーンに寄せて統制するならかなり優秀
- AWSクレジットの恩恵も受けることができる
- ユーザー向けの企業はいたちごっこになりがちなので比較軸にならない
- 実際どう進めていくのかのTips
- Agent Toolkit for AWSはすぐ導入できてお手軽な統制部品
- MCP Proxy for AWSを使うとSigv4を使ってMCP接続を管理できる
- AWS MCP ServerがGAされたことにより、監査の入り口が増えている
- aws loginを使うと短期認証情報でアクセス可能
- 承認は危険度での段階化がおすすめ
- ログは1箇所にまとまらないので管理が必要
- AIエージェントのセキュリティはAIモデルの問題ではなく、誰に許して、何を記録して、どう止めるのかが軸になる
QA
- ClaudeCode をよく使っています。自分も自身の操作とエージェントの操作は別でログを残してほしいとは思っているのですが人間とエージェントのプリンシパルはどう分けて設定しているのでしょうか？
- 個人単位であればIAMロールを分けるのがよいと思う
Session9: 全社統制を維持しながら現場負担をどう減らすか〜プラットフォームチームとセキュリティチームで進めたSecurity Hub活用によるAWS統制の見直し〜
登壇者：志田 淳弥（株式会社みずほ銀行 情報数理工学研究所 デジタル技術開発部 主任研究員）
セッションレベル：Level 300（中級）
- これまでのセキュリティ運用の課題
- チェックリストをスプシとして配布、利用者に確認してもらいセキュリティチームにレビューしてもらうという流れ
- 課題①：複数画面スクリーンショット取得作業
- 課題②：チェックミスがあった時のコミュニケーションコスト
- 利用者とセキュリティチーム間のコミュニケーションが煩雑になりがち
- 課題③：チェックリスト変更や定期的な確認の運用継続が負担に
- 定期的なチェックの時にしか評価ができない
- 詳細はbuilder flashの記事を参考に
- チェックリストをスプシとして配布、利用者に確認してもらいセキュリティチームにレビューしてもらうという流れ
- 共通ダッシュボードの構築・展開
- Security Hub CSPMのインサイト
- チェック項目をカスタムインサイトに変換（要件を違反検出ロジックに変換）
- 複数画面のスクリーンショットを撮る必要がなく、ダッシュボードの画面のみを取れば十分な運用になった
- 段階的なリリースによる素早い価値提供
- 最初からチェックリスト全部対応するのではなく、段階的に対応していく方針に変更
- AWS Service Catalogによってカスタムインサイトを各アカウントに一括配布
- 各アカウントでの更新は利用者側に委任、任意のタイミングで更新してもらう
- Auditアカウントに全利用アカウントの状況を集約させ、コミュニケーションコストを削減した
- Security Hub CSPMのインサイト
- 運用負荷をさらに下げるための自動化、予防的統制
- セキュリティ基準を違反したリソースの情報をSNSで通知させる
- Configによる違反リソースの自動修復機能のアップデートも追加
- Organizationsでルートユーザーの一括無効化ができるようになったアップデートを実装
- プラットフォームチームとセキュリティチームとの協力
- エビデンスを不要にする運用の実現
- 利用者とセキュリティチームで同じ画面を見れることを目指し、エビデンス提出という運用そのものをなくすことができた
- 現場浸透に向けたアクション
- カスタムインサイトの実装方法をブログにして周知してもらう（プラットフォームチーム）
- チェックリストに「カスタムインサイト利用時は提出不要」を記載してもらう（セキュリティチーム）
- エビデンスを不要にする運用の実現
QA
- 運用負荷を下げるためのソリューションを作られたと思うのですが、開発工数に対してどの程度の運用工数を削減することができたのでしょうか。 運用工数を毎月”1”減らせたとしても、ソリューションの開発工数が”100”とかだと割に合わないかなと思ったので質問させていただきたいです
- 日々の開発の合間に、2,3名で実装したためほぼ工数はかかっていない
- Security Hub CSPMを独自に有効活用している利用者がいた場合、設定を配ることで不都合が出たりもしそうですが、そういったことは発生しなかったでしょうか？（発生しない工夫をされていたら教えていただきたいです。）
- 特に影響は出なかった
- AWS Security Hubのカスタムインサイト機能はどの程度カスタムでルールを作りこめますか？標準的なコントロールのパラメータ変更程度ですか？それとももっと自由度が高いですか？
- そこまで複雑な実装は今回やっていない
- 私自身もクラウド推進の立場なのですが、啓蒙活動の中で苦労した点およびそれをどのように対応されたかを可能な範囲でお聞きできれば幸いです
- 技術ブログに加えて、今回のような登壇活動なども有効だと考えている
- 運用浸透に対して工夫されたことはありますか？事前の徹底した根回しや認知負荷を下げるための手順書やブログ書き方などあれば伺いたいです
- 絵を描いておく、公式ドキュメントくらいの細かさで書く、など粒度を使い分けた
- 週次で各チェック結果を通知するようにした という話がありましたが、委任管理者アカウントで集約し通知もそこから逐次通知するという方式にするのが簡単な気がするのですが、週次での通知にしたのには何か理由があったのでしょうか？
- クリティカルにすぐに対応しないといけないという要件がそもそもないので週次で回している
- カスタムインサイト画面をエビデンスにするとのことですが、Security Hub CSPMの「ワークフローステータス」を使わない理由は何でしょうか？
- 一画面で見れることを優先したため
Session10: Bottlerocket on ECS Dive Deep
登壇者：米澤 拓也（Japan Digital Design, Inc. Software Engineer）
セッションレベル：Level 400（上級）
- Bottlerocketとは？なせセキュアなのか？
- コンテナをセキュアに動かすために開発されたLinuxベースのOS
- セキュアな理由
- 不要なパッケージを徹底的に削減
- シェルがそもそもないのでコマンドが打てない
- インタプリタもないのでコード実行も不可
- パッケージマネージャーも利用不可
- ファイルシステムの整合性担保
- Bottlerocket AMIからAMIを起動するとEBSが2つ必要
- Root Device：イミュータブル、OS稼働用のストレージ
- Data Device：ミュータブル、アプリケーション用ストレージ
- Root Deviceにdm-verifyハッシュツリーを持っている
- カーネルレベルで実装されていて、全データをSHA256で階層的にハッシュ化
- もし改ざん検知したら即座にRebootする仕組み
- Bottlerocket AMIからAMIを起動するとEBSが2つ必要
- Control ContainerとAdmin Container
- Control Container：APIの受け口、SSM Agentも内包されている
- Admin Container：シェルやパッケージマネージャーが使える、デフォルトではオフ
- SELinuxによるミュータブル領域
- BottlerocketではSELinuxが強制適用されている
- その他、カーネルロックダウンなども取り入れられている
- 不要なパッケージを徹底的に削減
- Bottlerocketのアップデート
- バージョンをActive/Passiveとして管理し、スワップした状態でRebootさせる仕組みになっている
- 何かあってもすぐスイッチできるような仕組み
- Bottlerocket ECS Updaterを利用してアップデートを自動化することが可能
- バージョンをActive/Passiveとして管理し、スワップした状態でRebootさせる仕組みになっている
- 導入して得られた気づき
- そもそもFargate使えばいいのでは？
- とはいえECS on EC2が必要になることはある
- GPU利用、RI/SP、FargateのCPUガチャ、ややこしいコンテナ利用の要件、などなど
- ECS標準AMIも脆弱性がそれなりに出てきている
- ECS Managed InstanceがBottlerocketで動いている
- 14日で自動的にパッチ適用が走るが、おそらく裏で動いているBottlerocketの更新をしている
- とはいえECS on EC2が必要になることはある
- そもそもFargate使えばいいのでは？
- Bottlerocketの脆弱性検知
- AL2023、ECS最適化AMI、Bottlerocketを1ヶ月放置した結果、Bottlerocketにおける脆弱性の数が圧倒的に少なかった（1ヶ月間で1件のみ）
- CVE-2026-31431（Copy Fail）：一般権限でシェルを触れるユーザーが特権昇格できる、カーネルにおける脆弱性
- とはいえ脆弱性をゼロにすることはできない
- AL2023、ECS最適化AMI、Bottlerocketを1ヶ月放置した結果、Bottlerocketにおける脆弱性の数が圧倒的に少なかった（1ヶ月間で1件のみ）
QA
- ECSマネージドインスタンスでOSアップデートで勝手にEC2が再起動してしまうのはECS的にはサービス利用する上でちょっと怖い気がする
- 14日の時間はある程度メンテナンスウィンドウ調整が可能
- CPUガチャで、あたりと外れでどれくらい差がありますか
- ARMだと割と安定していそうだが詳細は不明
- Bottle rocketをECS以外(例えばROSA)で利用できるのでしょうか？
- 可能、ROSAがAL系で動くのであれば可能なはず（詳細は要確認）
Session11: Security-JAWS 振り返り
登壇者：Security-JAWS
- Security-JAWS立ち上げ当初は「クラウド怖い」という認識がまだまだ根強かった
- 専門支部としては13番目の支部
- AWSセキュリティサービスの移り変わり、世間的に大きなセキュリティインシデント、Security-JAWSの移り変わり
- 他支部とのコラボ
- NW JAWSとのコラボ
- 会場でL0セキュリティとして護身術の実演を開催w
- https://nwsecjaws.connpass.com/event/63018/
- Ops-JAWSとのコラボ
- NW JAWSとのコラボ
- 運営メンバーの怒り駆動で、AWSのセキュリティに関する利用実態調査レポートを実施し公開したことも
- APJ Meetup、re:Inforce 2024での登壇のベースになる調査
- Security Hub CSPMでの利用実態調査レポートも臼田さんが公開
- Security-JAWSからAWS Security Heroが2名輩出
- Heroは目指してなるものではない、アウトプットした結果なってるもの