
Security-JAWS 第38回レポート #secjaws #secjaws38 #jawsug
Security-JAWS 第38回のレポートです。新しい機能をガンガン使っていきましょう!そして次回はIAM祭りなのでCFPの登録待ってます!
こんにちは、臼田です。
Security JAWS 第38回が開催されましたのでレポートします。
Security-JAWS【第38回】 勉強会 2025年8月21日(木) - connpass
動画
のちほど
レポート
Session1: AWS re:Inforce 2025 TDIR reCap アマゾン ウェブ サービス ジャパン 技術統括本部 喜多 望さん
- 本日はTDIR計サービスのアップデート3つ紹介
- Amazon GuardDutyの拡張脅威検出カバレッジ拡大
- まずは拡張脅威検出とは
- 英語だとExtended Threat Detection
- これまでAmazon GuardDutyが個別に検出していたシグナルをまとめて攻撃シーケンスとして検出できるようになった
- 既存での攻撃シーケンスはIAMとS3だけだった
- 今回EKSクラスターでも攻撃シーケンスの検出ができるようになった
- 侵害された可能性のあるAmazon EKSクラスターによって実行される一連の疑わしいアクションが検出される
- 重要度はCriticalで検出されるため迅速な対応が必要
- EKS保護とRuntime MonitoringのEKSアドオンの2つの設定を一緒にするのが推奨
- まずは拡張脅威検出とは
- 新しいAWS Security Hubがプレビュー
- 既存のAWS Security Hubとは別のコンソールになる
- 既存の画面の左下に「Security Hub Advanced」をクリックすると使える
- 既存の名前がAWS Security Hub CSPMに変わった
- プレビューで無料で使えるのでどしどし使ってほしい
- 何ができるようになったか?
- 既存ではAWS Security Hub CSPMでできたCSPM機能と検出結果の集約があった
- 新しい方では集約が強化されて色々できるようになった
- 相関付けしたり露出を検出したり攻撃パスが可視化できたり
- サードパーティ統合も強化されていてJira/ServiceNowのチケット管理と連携できる
- 画面も既存と違う感じ
- 脅威情報としてAmazon GuardDutyの内容が見れるウィジェット
- 露出はあたらしいウィジェット
- 他にも脆弱性・機密データなどそれぞれの検出結果がページ分けされた
- フィルタリングの設定保存もできる
- 露出の詳細
- セキュリティシグナルの相関付けをして可視化してくれる
- 英語ではExposure
- 環境独自の潜在的脅威、リスクを検出できる
- 例えばAmazon Inspectorで検出するEC2インスタンスの脆弱性が実際に他の問題と繋がる可能性があるかわかる
- 設定ミス・脆弱性・機密データなどそれぞれの情報を統合して優先度を決定する
- AWSネイティブの各セキュリティ機能を使っていると相関付けできるので役立つ
- 潜在的な攻撃パスの可視化
- 攻撃者が脆弱性や設定ミスを連鎖させて重要度の高いリソースの侵害をする可能性のあるパスを理解し可視化してくれる
- 現状の使い分け
- 既存のAWS Security Hub CSPMは従来通りCSPMの機能として利用していく
- こちらでしかCSPM機能を持っていない
- 新しいAWS Security Hubで一元管理・可視化の機能として使っていく
- 既存のAWS Security Hub CSPMは従来通りCSPMの機能として利用していく
- Amazon Inspectorコードセキュリティ機能
- Amazon Inspectorは脆弱性管理のサービス
- これまでEC2/ECR/Lambdaに対応していた
- 今回リポジトリに保存されているコードのレビューができるようになった
- これまではパッケージのみでアプリケーションの脆弱性管理を別で行う必要があったが、Amazon Inspectorでできるようになった
- コア機能
- 静的アプリケーションセキュリティテスト(SAST)
- ソフトウェアコンポジション解析(SCA)
- Infrastructure as Code(IaC)スキャン
- それぞれの機能でサポート言語は違う
- 詳細はドキュメントで
- 検出結果はこれまでと同じように確認できる
- SASTスキャンではコードの具体的な指摘や修正方法が出たりする
- Git Actionsに組み込むことができる
- スキャン結果をPRに追記できる
感想
いいアップデートがいっぱいありますな!
新しいAWS Security Hubを今から使い倒そう!
Session2: AWS re:Inforceで行われたレベル500の2つのセッションをレベル200にて紹介 Security-JAWS 吉江 瞬
- タイトルに書いたけど実際にはレベル200で説明するのが難しいかも
- SEC501/SEC504の2つのセッションを優しく紹介する
- レベル500ってなに?
- これまでAWSが出すセッションのレベルは400がExpertで一番上だった
- 今回のre:Inforceで500がDistinguishedがでた
- レベル説明で高度な研究、理論的基礎などなどと説明が書いてある
- 論文を読みながら展開されたりする高度なセッション
- SEC 501 ショアのアルゴリズムとポスト量子暗号の話
- 線形代数の授業を受ける感じ
- 量子計算の話がされて、耐量子暗号がどうなるかという話だった
- 量子コンピュータとは?
- 今あるいろんな暗号(RSA/楕円曲線など)が量子コンピューティングが出てくると既存の暗号化一瞬で破られる可能性がある
- それに耐えうる新しい暗号として耐量子暗号(PQC)がある
- NISTが3つのPQCスタンダードを出した
- それが今後のベースになってくる
- AWSもこれらを使ってどうするか、という段階になっている
- KMSではPQC対応している
- Transfer Familyでも一部使える
- 我々が気にしておくのはPQCが必要になったときAWSでどう使えるのかを知っておくこと
- AWSとしてもユーザーがPQC対応を一括で行うことは推奨していなくて、順次移行したほうがいいとしている
- いずれどのサービスがPQCに対応しているかをわかるようにしたいとのこと
- SEC 504 REACTという脅威検出モデル
- REACTフレームワークの論文を紐解き解説された
- クラウドセキュリティの脅威検出について話した
- ありとあらゆる脅威が学習データに対してラベルが付いていない
- 検出が難しいところ、REACTで上手くラベル付けして検出するフレームワーク
- 実際にAmazon GuardDutyやAmazon Macieで利用している
感想
500は難しいが、PQC対応などやらなければいけないことはあるので準備していきたい
Session3: バラバラ運用からの脱却!セキュリティ統制をAWS Organizationでまとめてみた セコムトラストシステムズ株式会社 DX推進部 新井 貴大さん
- 背景・目的
- システム運用を委託いただいているお客様の社内でAWS活用が進んでいて100AWSアカウント以上がある
- AWS Organizationsを使っていたり使っていなかったりバラバラであった
- 設定や運用が統一されていない
- 対応方針
- 1つのAWS Organizationsに統合することにした
- 課題
- OU構成アカウント構成の違い
- セキュリティ設定の課題
- ドキュメント不足の課題
- OU・アカウント構成の課題解決
- AWSのベストプラクティスに合わせて構成をした
- Policy Statementなど一部は使う予定がないので作らないようにした
- 一部OU統廃合した
- 整理したので共通設定できるようになった
- セキュリティ設定の課題解決
- 今回のメインで内容も多い
- SCPによる権限の制限
- ログイン方法の変更
- Configによる自動修復
- セキュリティサービスの通知
- インターネット出口の一元化
- ログイン方法の変更
- 統合前はJumpアカウントや直接ログインが多かった
- IAM Identity Centerにまとめた
- 外部IdPのJustInTimeのログインをできるようにした(TEAMではない)
- Configによる自動修復
- リスクのある設定をConfig適合パックをStaskSetsでOU選択して展開
- S3.5/EC2.18/EC2.19などが対象
- セキュリティサービスの通知
- すべてAuditアカウントで管理するようにした
- AWS Security Hubでは検知時のみ1回通知と、サマリ通知を行うようにした
- Amazon GuardDutyとIAM Access Analyzerは即時通知と電話連絡
- Inspectorで週次でサマリ通知
- インターネット出口の一元化
- Infrastructure OUに構築しTransit Gateway/Network Firewallを利用
- オンプレとの専用線接続があったのでそれを拡張した形
- Network Firewallでホワイトリストで制限している
- ドキュメント拡充
- 3つのパターンを定義
- AWS Organizationsアカウント自体の設定ドキュメント
- 設定意図がわかるように
- アカウント利用者向けドキュメント
- セキュリティ検知の対応ポリシーなど
- セキュリティオペレーション関連ドキュメント
- 対応方針も通知のURLに動的に埋め込んでいる
- スケジュール
- 当初6ヶ月ほどで完了予定だったが、諸々調整で3ヶ月程度遅延した
- 対象アカウントの精査をして結果的に削除したアカウントもありコスト削減できた
- 1アカウント40分程度で移行
- 移行時に注意したこと
- GuardDuty/Access Analyzerの抑制ルールの作成を事前にして検出量を減らした
- Security Hub検出結果が無くなる場合もあるためエクスポートした
- 移行時に通知が飛ぶ場合があるため各通知を一時停止する
- Control Tower登録のため手動で設定されていたものなどのConfigレコーダーを削除
- AWS Organizations配下では請求書設定・電話番号認証が未設定のものがあったので事前に設定対応
- 苦労した点
- 各部署への調整は費用周りも含め丁寧に
- いろんなアカウントの状態があったので手順の確立が大変
- SCPの上限があるのでポリシーを一部統合
- 改善できた点
- アカウントセキュリティを向上できた
- アカウント発行時に検出0の状態で出せるようになった
- Security Hubのスコアの可視化・定期報告
- 月次セキュリティ報告会の対象となり利用者意識が向上した
- 人間が利用するIAMユーザーの削減
- アカウントセキュリティを向上できた
- 学びと展望
- 既存を使わずに新しいAWS Organizationsを作ったのが正解だった
- AWS利用部署全体の協力と理解が必要
- 統廃合はスタートであり今後も改善していく
- IAM Identity Centerの情報を利用したEC2へのログインをしたい
- GuardDutyのランタイムモニタリングの自動設定を行いたい
- 既存アカウントのNW統合したい
- アドレス管理をしっかりしてまとめられるようにしたい
- 料金を最適化したい
感想
いい話だった!非常に参考になるマルチアカウント管理への移行の内容なのでみんな真似しましょう!
Session4: 【実例付き】aws-cdkでAPIを0円防衛する技 Wallarm, Inc. 日本支店 上町 (かみまち)さん
- 例えばAIを使ったアプリを作ったときにどう防御しますか?
- AWS WAFを使って保護するなども考えられる
- しかしWebACLが月$5から始まり、リクエストがたくさん来たら課金が増える
- ほとんどのWAFは正規表現とシグネチャ中心で動いている
- 断片化によって検出されないことがある
- 32KBを超えるペイロードの場合無視して通すなどの場合もある
- AWS WAFの導入は簡単
- セルフで似たような仕組みを作るのは大変だった
- CDKで配布と制限性が担保できるようになった
- すべて宣言的に作れる
- TypeScript CDKでWallarmを試す
- 無料枠は50万リクエスト/月
- その分ホストを立てる必要があるのは注意
- スライド1枚に収まるコード量
- 使ってみてね
感想
コストを抑えてセキュリティ適用するのは大事ですね。無料枠を駆使しましょう。
Session5: (仮)セキュリティ監視でSecurity Lake使うと楽しい、という話 ken5scalさん
- SIEMじゃないなーと思ってSecurity Lakeを使ったところから今回の話
- Apache Icebergがきになったのでその話をする
- FISCのドキュメントにSIEMについて書かれている
- いろんなソリューションはある
- 本当に必要なSIEMって?
- 分析対象にしたいデータの制限
- そもそも取得する情報が限定的
- フォーマットがバラバラだったりして利用しづらい
- 保管できるデータ量が限定的
- ストレージ料金が高くなる
- 個人情報が除去できないと大変
- 分析も独自のクエリ
- ブラウザ上でしかクエリが使えなくてローカルで試したりできないとか
- 頑張ればなんとかできる
- ただし労力がかかる割に全部を解決できるわけではない
- やっぱつらい
- SIEM前提でやるから辛いのでは
- というわけで構成を変えてみた
- ログをいろんなことをしてアーカイブにいれる
- フォーマット整えたりなんだりする
- そしてAWS Security Lakeに入れる
- セキュリティログを集約して一元管理できる
- AWSのCloudTrailやGuardDutyやWAFのログなどもOCSFというフォーマットに統一して入れてくれる
- Athenaとかでクエリできる
- AWSのログ以外は自分でOCSFにして入れている
- 複数の取得方式を使っている
- APIのクローリング、Webhook、ストレージへ直接保管、手動
- AWS AppFabricも使っている
- Amazon Macieで検出もしている
- 分析
- 色んなところから分析している
- AthenaもそうだがDuckDBなども使っている
- 任意のクエリエンジニでローカル検証も簡単
- ほしかったコントローラビリティを実現できた
- これはApache Icebergが支えている
- 標準だからそれに準拠したツールであれば何でも使えるのが強み
- Apache Icebergは実際のデータにアクセスするのではなく論理的なメタデータ層をつくってそれを経由してアクセスする
- カタログとメタデータがあることで柔軟な対応が可能
- データレイヤーに実データが格納される
- Security LakeではS3に保存される
- シナリオ: お客様(投資家)の資金保護
- 個別の要望に対してのスキーマの進化に対応できる
- 監査もできる
感想
AWS Security Lakeにセキュリティログを集めてOCSFで整えて扱えるようにすると楽になりそうですね。とはいえ、いろんな分析の用途に耐えうる一方でネイティブでよしなに使える、というわけではなく使いこなすにはまたいろいろやる必要があるので利用用途はよく考えましょう。
Session6: AWS Security Hubアンケートのレポートを紹介しちゃうよ Security-JAWS 臼田佳祐
レポートの公開はもう少し待ってね★ミ
[クラウドZoom相談] 当日のslido & connpassで受付けた質問に回答する枠
今回は相談なし!みんないっぱい相談してね。
まとめ
今回もいろんな知見がありましたね!アンケートのレポートはもう少し待ってね★ミ