20250509_AWSアカウント管理担当者が、Security Hub活用のためにQuickSightに手を出したら大変だった話

JAWS-UG 名古屋 5月会①「データ利活用研究会」
https://jawsug-nagoya.connpass.com/event/349797/

Transcript

1. AWS アカウント管理担当者が、 Security Hub 活用のために QuickSight に手を出したら 大変だった話 tsunojun @tsunojun2451821
2. 自己紹介 大阪の某機械メーカーの研究機関　 7 年目 製造業が盛んな名古屋に興味があり、JAWS-UG Nagoya に遠征 主務：AWS ・GitHub などのプラットフォーム提供 Organization からアカウントの払い出し・棚卸 ↑ の延長で、AWS インフラのセキュリティレビューをすることも 手動レビュー レビュー自動化（Security Hub/ カスタムルール） 今後は Amazon Q などを用いて、もっと積極的に？
3. 目次 社内での Security Hub の導入目的 デフォルトの画面では満足できない！ どんな画面（可視化機能）が必要か Security Hub と QuickSight のつなぎ方 AWS ブログを基に、Athena でクエリ 問題発生したため、OpenSearch でのクエリに挑戦中 所感
4. 社内での Security Hub の導入目的 各アカウント上の設定が適切か 利用者に確認させたい 情シス部門の Admin から一覧したい 確認項目 汎用的なベスプラ( 例：EC2 をパブリック 0.0.0.0/0 に公開しない) 社内規定( 例：社内向けアプリは、社内からの接続のみに限定) Config カスタムルールを作成し、配布
5. デフォルトの画面では満足できない！ - 利用者に確認させたい 各アカウント毎の表示 or 全アカウント集約表示 前者は手間がかかるし、後者は見せたくない情報が多い - Configカスタムルールを作成し、配布 汎用的なべスプラと Config カスタムルールが別々に表示される
6. どんな画面（可視化機能）が必要か やらないといけないこと 利用者ごとに表示するアカウントを変更する カスタムルールを一覧表示する 追加でやりたいこと Security Hub 以外にも、情シス部門 Admin が確認するログの表示 GitHub Enterprise の Audit Log （各リポジトリのアクセス状況） CloudTrail （AWS の API コールの履歴）
7. 他の方の記事を参考にする JAWS-UG 千葉支部 #19 AWS Security Hub のダッシュボードがイ ケてないので AWS Security Lake を試してみた JAWS-UG 千葉 #20 AWS Security Lake を試してみたら 最高の運用 者体験だった Security Lake を用いれば、S3 と LakeFormation からなるデータレイ クを一発構築し、各アカウントの情報を集約できるようだ → 上手いことクエリすれば、やりたいことができるのでは？
8. AWS ブログを基に、Athena でクエリ （最近、QuickSight も Amazon Q 推し　使ったことはないが、 、 、 ）
9. 可視化結果
10. Athena でクエリした際に問題発生 利用者が QuickSight 上のダッシュボードにアクセスした際に 都度クエリするため、表示が遅い(~1 分程度) ▪JAWS-UG千葉支部 #19 AWS Security HubのダッシュボードがイケてないのでAWS Security Lakeを試してみた 現在の情報を取得するのが難しいかも - 既に存在しない情報がファイルに存在している - なのでfinding ID + リソースで、最新の情報を取得する必要がある → 裏で定期的にクエリし、SPICE キャッシュに格納することで対応 しかし、SPICE がダッシュボード毎に作成される仕様があった → ダッシュボード件数が増えるにつれ費用が増大
11. さっきの図、細かく書くとこんな感じ ↑ よくわかってなかった(Blackbelt で学んだ)
12. Athena を使わずにクエリしたい、 、 、 いったんOpenSearch に格納し、QuickSight→OpenSearch にクエリ すればよいのでは？ 事前検証で、ある程度パフォーマンスが出ることは判明 現在、Lake→Athena から Lake→OpenSearch に移行中だが、難航 中 難航している理由：接続方法が複数ある
13. サービス名 利点 欠点 OpenSearch Ingestion Pipeline OpenSearch 上にデー タを移動するため、ク エリ時間短縮が見込ま れる ランニングコスト(USD 0.326 per OCU per hour) SIEM on Amazon OpenSearch Service ↑ に加えランニングコス トが安い AWS 提供の OSS かつ 更新頻度が下がってい る・内部 Lambda の内 容把握が必要 Zero-ETL 統合 設定が容易 前述の問題が解消しな い（Athena 同様クエ リ時に都度 S3 を参照）
14. 所感 アカウント管理が主務のため、データ利活用の知見が不足と痛感 Security Lake のような「まとめて一発構築するサービス」は、活用 を進めるにつれ中身の理解が必要 最初の一歩を軽くしてくれることはとても助かる 運用を考えた際に、色々な問題が出てくるため、都度対応する アーキテクチャが最適でないと気づいたら、再構築する勇気が要る 再構築の際は、サービス選定だけでなく、連携方法の選定も必要 今日の登壇で LT される DuckDB にも、興味あり、 、 、