全社統制を維持しながら現場負担をどう減らすか — Security Hub活用によるAWS統制の見直し
大手金融機関のプラットフォームチームがSecurity Hubカスタムインサイトで手作業チェック+スクショ提出を撤廃。3つの防衛線モデルで現場オーナーシップを維持
🎤 大手金融機関 デジタル技術開発部 主任研究員
キーテイクアウェイ
Security Hubのカスタムインサイトでチェックリストをダッシュボード化。エビデンス提出を廃止し、セキュリティチームと現場が同じ画面を見て会話できる状態を実現
登壇者の背景
- 大手金融機関のデジタル技術開発部 主任研究員
- グループ内の組織統合を経て現部門に配属
- 業務: AWS活用システム開発、クラウド人材育成、共通プラットフォーム構築、AI駆動開発推進
課題: 手作業チェックの限界
従来の運用:
- CISベンチマーク等を基にした社内セキュリティルール
- チェック方法: 複数画面でコンソール確認 → スクリーンショット取得 → スプレッドシートで提出
- 全社員がクラウド利用時にチェックリスト準拠が必須
問題点:
- 確認作業の負荷が高い
- チェック頻度の確保が困難
- アカウント数増加にスケールしない
- 形骸化リスク
解決: カスタムインサイト
具体例: EBS暗号化チェック
| 従来 | カスタムインサイト化後 |
|---|---|
| EC2コンソールでEBS一覧表示 | フィルター条件で違反を自動抽出 |
| 暗号化ステータスを1つずつ確認 | 1画面で違反状況を確認 |
| スクショ取得+スプレッドシート | 画面自体がエビデンス |
段階的リリース戦略
チェック項目を一度に全部リリースしない:
- 1ヶ月程度の間隔でグループごとにリリース
- 利用者の更新作業負荷を軽減
- チェックリスト変更への対応も容易
マルチアカウント配布: Service Catalog
プラットフォームチーム
→ IaCテンプレート作成（カスタムインサイト含む）
→ Service Catalog に「セキュリティ製品」として登録
→ Organizations共有で各アカウントに配布
→ 利用者が好きなタイミングで更新監査アカウント集約
各アカウントの検出結果を監査アカウントに集約。セキュリティチームと利用者が同じ画面を見ながら会話可能。
3つの防衛線モデル
| 線 | 担当 | 責任 |
|---|---|---|
| 第1線 | プラットフォームチーム + 現場 | リスクの直接管理（提案主体） |
| 第2線 | セキュリティチーム | ルール定義・評価 |
| 第3線 | 監査部門 | 独立評価 |
第1線が主体 = 現場のオーナーシップを尊重。
自動化・予防的統制
通知
- 検出結果をWeeklyで通知
- POC/サンドボックス環境メインのため即時対応不要なケースが多い
自動修復
- AWS Configによる自動修復を提供
- 大阪リージョン対応追加
- 複数リージョン対応
ルートユーザー認証の無効化
- 2024年11月のAWSアップデートを採用
- Organizationsでルートユーザー認証を一括無効化
- 無意識のセキュリティ違反を根本解消
現場浸透アクション
プラットフォームチーム: 技術ブログ執筆（図表多め） セキュリティチーム: チェックリストに「カスタムインサイト利用ならエビデンス不要」と明記
Q&Aハイライト
Q: 開発コストは？ A: エンジニア2〜3名が週1〜2日、運用の隙間で実装。大きな体力不要。
Q: 既存カスタム利用との干渉は？ A: インサイトはFindings をフィルターするのみ。既存のCSPMや利用者実装に影響なし。
Q: 通知はオーディットアカウントから一括配信が楽では？ A: 3つの防衛線で第1線がリスク管理責任を持つため、利用者自身が対応する方式を採用。
初心者向け補足
Security Hubとは
AWS環境のセキュリティ状態を一元可視化するサービス。CIS Benchmark等の基準に沿って設定ミスや脆弱性を自動検出。
カスタムインサイトとは
Security HubのFindings（検出結果）に独自のフィルター条件を設定して集計・可視化する機能。「自組織にとって重要な観点」でダッシュボードを作れる。
Service Catalogとは
AWSリソースのテンプレートを「製品」として登録し、組織内に配布するサービス。承認されたリソースを正しい設定で作成できる。