Security Hub 組織統合設計書

1. 目的・スコープ

目的

AWS Security Hubの組織統合を行い、Organization全体のセキュリティ検出結果を一元管理する。これにより以下を実現する。

全アカウントにSecurity Hubを導入し、セキュリティ態勢を可視化
GuardDuty / Config Rules / Inspector の findings を Delegated Admin に集約
セキュリティ標準（FSBP + CIS + AISBP）による継続的なコンプライアンスチェック
Config Rules 評価結果の通知基盤構築（Config単体では通知基盤がないため）
通知基盤の統合（GuardDuty + Security Hub を security-notification.tf に統合）
ライブラリ・コンテナイメージの脆弱性の自動検知（現状の手動検知からの脱却）

スコープ

Security Hub組織統合の設計・構築
Delegated Admin登録
セキュリティ標準の選定・有効化
既存 Organization Config Rules との重複整理
service-linked configuration recorder の影響評価
通知基盤の統合設計（guardduty-notification.tf → security-notification.tf）
Datadog 転送設計（Forwarder Lambda方式）
findings の cross-region aggregation
カスタムアクションの設計
脆弱性管理の方針（詳細設計は Inspector 組織統合設計書で実施）

スコープ外

自動修復（Automated Response and Remediation）の設計（finding検知時にLambda/Step Functionsでリソースを自動修正する仕組み。誤修復リスクがあり本番環境への影響が大きいため、まず手動対応で非準拠パターンを把握してから設計する。Config設計書でも同方針）
Security Hub Insights のカスタマイズ（全findingsをDatadogに転送するため、集計・分析はDatadog Log Analytics / Dashboard / Bits AIで対応する。Security Hub Insightsは AWS コンソール内に閉じるため二重管理になる。Datadogでカバーできない要件が出た場合に検討）
CloudTrail APIコールのリアルタイム監視（IAM変更、SG変更等の「操作自体」の即時検知。Security Hubは「設定の結果が危険か」をチェックするが「誰がいつ変更したか」の即時通知はカバーしない。CloudTrail → EventBridge方式で構築可能だが、何を監視対象にするかの整理が必要なため別途設計する。CIS BenchmarkのCloudWatch Logs + メトリクスフィルタ系コントロールは旧方式のため無効化し、必要に応じてEventBridge方式で対応する）

前提

OU・アカウント構成はOU・アカウント設計書に従う
SCP設計はSCP設計書に従う
Terraform運用はTerraform運用設計書に従う
Config組織統合（Recorder全アカウント展開）が完了していること ※ CSPM 単独運用の場合、customer managed recorder が必須（AWS公式: "you must enable AWS Config for your account and turn on resource recording"） ※ CSPM + Security Hub（V2）の両方を有効化した場合は service-linked recorder が自動作成されるため、customer managed recorder は Security Hub の必須前提ではない（AWS公式: "You don't need to manually enable or configure AWS Config"） ※ ただし customer managed recorder を削除すると S3 への CI 配信・Config Aggregator が使えなくなるため、本番環境では維持する方針（Section 8 参照） ※ 我々は Config 組織統合を完了済みのため、CSPM の推奨を満たしている
GuardDuty組織統合・通知基盤が稼働していること
「Security Hub CSPM」と「Security Hub」は別サービスである ※ Security Hub CSPM: セキュリティ体制評価（設定ミス検出） service principal: securityhub.amazonaws.com / API: EnableSecurityHub Terraform: aws_securityhub_account ※ Security Hub（V2）: 統合セキュリティソリューション（相関分析・優先順位付け） service principal: securityhubv2.amazonaws.com / API: EnableSecurityHubV2 Terraform: aws_securityhub_account_v2（AWS Provider v6 以降） ※ 本設計書の Phase A〜E は CSPM の導入。V2 は Phase F として別途導入判断する

2. 現状と課題

現状（2026-07-28時点）

Security Hub導入状況:
  ・全アカウント未導入（全15アカウント + マネジメントアカウント）

完了済みの組織統合:
  ✅ CloudTrail 組織トレイル
  ✅ Health Dashboard 組織ビュー
  ✅ GuardDuty 組織統合 + 通知基盤
  ✅ Config 組織統合 — 完了

通知基盤の現状:
  ・GuardDuty: EventBridge → SNS → Amazon Q Developer → Slack（severity >= 7）
  ・GuardDuty: EventBridge → Datadog Forwarder Lambda → Datadog（全severity）
  ・Config: 通知基盤なし（Security Hub導入まで手動運用の方針）
  ・通知先: #squad-sre-noti-security

既存Datadog Forwarder Lambda:
  ・fd-security-toolingの4リージョンにデプロイ済み
  ・ap-northeast-1, us-east-1, us-west-2, ap-northeast-3
  ・GuardDuty findings転送用として稼働中

SCP:
  ・SCP①（deny_disable_security_services）に securityhub:DisableSecurityHub 設定済み
  ・SCP②（deny_non_approved_regions）に securityhub:* は未追加

課題

#	課題	影響
1	Security Hubが全アカウント未導入	セキュリティ態勢の一元的な可視化ができない
2	Config Rules評価結果の通知手段がない	NON_COMPLIANT検知後のリアルタイム通知ができない
3	GuardDuty / Config / Inspector の findings が分散	横断的なセキュリティ分析ができない
4	セキュリティ標準によるコンプライアンスチェックがない	ベストプラクティスからの逸脱を検知できない
5	通知基盤がGuardDuty専用	Security Hub導入時に拡張が必要
6	Config Rules評価イベントが各アカウントに分散	Delegated Adminに自動集約されない（Config単体の制約）。Security Hub導入で解消

3. アーキテクチャ

全体構成

組織統合の動作

Security Hub組織統合を有効化すると:
  ・全メンバーアカウントでSecurity Hubが自動有効化される
  ・指定したセキュリティ標準が全アカウントで有効化される
  ・各アカウントのfindings（GuardDuty, Config, Inspector）が
    Delegated Admin（fd-security-tooling）に自動集約される
  ・新規アカウントがOrganizationに追加された場合も自動有効化
  ・Cross-Region Aggregationで全リージョンのfindingsを1リージョンに集約

  GuardDuty findingsの流れ:
    ・メンバーアカウントのGuardDuty → メンバーのSecurity Hub → Delegated AdminのSecurity Hub
    ・GuardDutyのDelegated Admin集約とSecurity Hubの集約の両方で届く
    → 通知は Security Hub 側のみにし、GuardDuty 直接の通知は統合する（詳細はSection 10）

  Config Rules findingsの流れ:
    ・Organization Config Rules評価結果 → メンバーのSecurity Hub → Delegated AdminのSecurity Hub
    ・Security Hub標準のservice-linked Config Rules評価結果 → メンバーのSecurity Hub → Delegated AdminのSecurity Hub
    → Config単体では通知基盤がなかったが、Security Hub経由で自動的に通知可能になる

  Inspector findingsの流れ:
    ・Inspector組織統合は別途設計・実施するため、ここでは詳細を記載しない
    ・Security Hubを先に有効化しておけば、Inspector導入時に自動集約される

4. Delegated Admin・Trusted Access

設定内容

項目	設定値	備考
Delegated Admin	fd-security-tooling (860801568046)	GuardDuty / Config と同じアカウント
Trusted Access	securityhub.amazonaws.com	Security Hub組織統合用

適用手順

マネジメントアカウント (703480710002) で実施する。
実施者: SRE

  ・fd-security-tooling (860801568046) を Delegated Admin に登録
  ・Central Configuration 使用のため、ホームリージョン（東京）のみで実施
  ・Trusted Access は Delegated Admin 登録時に自動有効化される
  ・マネジメントアカウントの Security Hub 有効化は production 展開時に
    全アカウント一括で実施する

  参照: https://docs.aws.amazon.com/securityhub/latest/userguide/designate-orgs-admin-account.html

5. セキュリティ標準

FDが遵守すべき規制・ガイドライン

セキュリティ標準の選定にあたり、FDの事業特性と遵守すべき規制を整理する。

  1. 3省2ガイドライン（経産省ガイドライン）:
     ・FDは医療機関に情報システムを提供する「対象事業者」に該当
     ・リスクマネジメントプロセスの実施、多層防御、ログ保全（5年以上）、
       多要素認証、バックアップのイミュータブル化等が求められる
     ・ISMS認証の取得を要求 → FDは取得済み（サーベイランス審査実施中）
     ・令和9年度（2027年度）までに二要素認証対応が期限付きで要求
     参照: Notion「FD事業と3省2ガイドライン及びISMS等の関連性」
     参照: Notion「三省二ガイドラインから読み解く インフラ設計の要点」

  2. ISMS / ISO 27001:
     ・3省2ガイドラインが対象事業者に求める認証
     ・全社で取得済み、定期的にサーベイランス審査を実施
     ・Security Hubのセキュリティスコアは ISMS 審査時の技術的対策の
       エビデンスとして活用できる

  3. 個人情報保護法:
     ・要配慮個人情報（医療情報 = 病歴・健康情報等）を取り扱っている
     ・患者の医療情報がFDシステムに保存されている

  4. PCI DSS（決済関連）:
     ・決済はGMO経由で処理（クレカ）、NP後払い（コンビニ）
     ・カード番号はフロントエンドからGMOサーバーに直接送信してトークン化
     ・FDのバックエンドにはカード番号は送られない（GMOトークンのみ保持）
     ・PCI DSS準拠はGMO側で完結 → Security HubのPCI DSS標準は不要

選定

採用: FSBP + CIS AWS Foundations Benchmark + AI Security Best Practices

  参考:
    ・https://dev.classmethod.jp/articles/security-hub-cspm-standards-selection-guide/
    ・https://zenn.dev/cscloud_blog/articles/security-hub-cspm-aisbp-standard
    ・利用可能な標準は13個あるが、FDの事業特性に合わせて以下を選定する
    ・選定方針は「ベースライン（FSBP）+ 要件の積み上げ」

  ① FSBP（AWS Foundational Security Best Practices）v1.0.0:
    ・AWSが独自に定めたベストプラクティス集
    ・AWSサービスごとの設定チェックが最も充実（約280コントロール）
    ・暗号化、アクセス制御、ログ管理、ネットワーク設定等を網羅
    → 全組織が有効化すべきベースライン

  ② CIS AWS Foundations Benchmark v5.0.0:
    ・CIS（Center for Internet Security）が定めた第三者機関の業界標準
    ・4バージョン（v1.2.0, v1.4.0, v3.0.0, v5.0.0）があり、新規導入は最新 v5.0.0
    ・FSBPと重複する項目が多いが、CIS固有のコントロールもある
      （パスワードポリシーの具体要件等）

    FSBP との重複について:
      ・Security Hub は「統合コントロール findings」（Consolidated control findings）で
        同じコントロールが複数標準に含まれる場合でも finding は1件のみ生成される
      ・ルール評価も1回のみ（コストの二重課金もない）
      ・CIS 固有コントロール分のみチェック回数が増加する

    Consolidated control findings の注意点（2026-08 検証で判明）:
      ・ControlFindingGenerator = SECURITY_CONTROL の設定が必要
      ・Central Configuration（Configuration Policy）ではこの設定を管理できない仕様
        参照: https://docs.aws.amazon.com/securityhub/latest/userguide/controls-findings-create-update.html
        （公式ドキュメント明記: "the administrator cannot use central configuration
        policies to enable or disable consolidated control findings for the accounts"）
      ・Delegated Admin の各リージョンで明示的に設定が必要
        → ホームリージョンのみ Terraform で設定されており、リンクリージョンが
          STANDARD_CONTROL のままで findings が最大3倍に重複していた
        → PR #2652 でリンクリージョンの aws_securityhub_account を追加して対応
      ・メンバーアカウントは管理者アカウントの設定に従い自動で反映される

    有効化する理由:
      ・findings / コストの重複がないため、有効化のデメリットが小さい
      ・FDは医療情報を扱う対象事業者であり、第三者基準への準拠は
        善管注意義務を果たすための重要なエビデンスとなる
      ・3省2ガイドラインが求める「リスクマネジメントプロセスの実施」
        「多層防御」の技術的実装を第三者基準でチェックできる
      ・ISMS サーベイランス審査で「CIS準拠のセキュリティスコア」を
        提示することで、技術的安全管理措置の実効性を示せる
      ・ISO 27001 / ISO 27017（クラウド向け）との親和性が高い
      ・将来のISMAP申請検討時にもCIS準拠実績が有用

  ③ AI Security Best Practices（AISBP）v1.0.0:
    ・2026年7月に追加されたAIワークロード向けのセキュリティ標準
    ・31コントロール（Bedrock 1個、AgentCore 7個、SageMaker 23個）
    ・ネットワーク隔離、KMS暗号化、アクセス制御、監査ログをチェック
    ・デフォルト無効のため明示的に有効化が必要

    有効化する理由:
      ・本番環境で Bedrock を利用しており、直接該当する
      ・AIエージェントのセキュリティ（AgentCore）は新しい領域で
        手動でのベストプラクティス把握が困難
      ・3省2ガイドラインの経産省ガイドラインでも
        AI活用時のセキュリティ管理が求められつつある
      ・31コントロールと少なくコスト影響も軽微

不採用:
  ・PCI DSS v4.0.1 / v3.2.1 — カード番号はフロントエンドから GMO サーバーに
    直接送信してトークン化しており、FDのバックエンドにはカード番号は送られない
    （Notion「支払基盤引き継ぎ」: 「カード番号はバックエンドに送らず、
    GMOサーバーに直接送りトークン化すること。自社システムでカード情報を
    扱うと高水準のセキュリティ基準が必要になる」）
    FDが保持するのは GMO のトークンであり、PCI DSS 準拠は GMO 側で完結
  ・CIS v1.2.0 / v1.4.0 / v3.0.0 — 旧バージョン。v5.0.0 を選択
  ・NIST SP 800-53 — 米国政府向け。要件なし
  ・NIST SP 800-171 — 米国防総省サプライチェーン向け。要件なし
  ・HIPAA — 米国医療情報規制。日本国内事業のため不要
    （3省2ガイドラインが日本における相当の規制）
  ・AWS リソースタグ付け標準 — タグポリシーは Phase 5 で検討（ロードマップ参照）
  ・Azure 系標準（2種）— Azure を使用していないため不要

コントロールの初期設定

初期は全コントロールを有効のまま運用し、導入後に傾向を見て
false positive や自社環境に該当しないコントロールを段階的に無効化する。
無効化の精査は今後のタスク（Section 19 参照）。

無効化の方針:
  ・Central Configuration で configuration policy を作成し、
    全アカウント一括で無効化コントロールを管理する
  ・各アカウントで個別に無効化はしない
  ・無効化理由はconfiguration policyのコメントやGitHub PRに記録する

6. 脆弱性管理（Vulnerability Management）

現状の課題:
  ・ライブラリの脆弱性情報は手動で外部サイトを確認してアップデートしている
  ・ECRイメージ・Lambda関数の脆弱性スキャンは未導入
  ・どのサービスにどの脆弱性があるか全体像を把握できていない
  ・3省2ガイドラインが求める「脆弱性対応の管理」が体系的に実施できていない

Security Hub による解決:
  ・Essentials プランに Amazon Inspector の脆弱性スキャンが統合されている
  ・ECR / Lambda / EC2 の脆弱性を自動検知し、findings として集約
  ・新しいCVEが公開されたら既存イメージも再スキャン（継続スキャン）
  ・findings は Security Hub 通知基盤で Slack / Datadog に自動通知
  → 手動で外部サイトを確認する運用が不要になる

コストの考慮:
  ・Essentials プランのリソース単位課金に含まれる
    （ECR 18個=1unit、Lambda 12個=1unit、EC2 1個=1unit）
  ・イメージ数が多いほどコスト増のため、
    不要イメージの事前削除（ECRライフサイクルポリシー）でコスト最適化が可能

Security Hub 導入時の方針:
  ・まず有効化して現状の脆弱性の全体像を把握する（30日無料トライアル期間）
  ・対応フロー、SLA、ECRクリーンアップ、CI/CD統合等の
    詳細設計は Inspector 組織統合設計書で別途実施する

7. Organization Config Rules との重複整理

現状のOrganization Config Rules（初期12件）

Config組織統合の設計時に以下の12件をデプロイする計画だったが、
Security Hub 導入を優先したため未デプロイ。
Security Hub の service-linked rules で全てカバーされるため対応不要。
今後 Organization Config Rules を独自にデプロイした場合は、
Security Hub の service-linked rules と重複するため以下の整理が必要になる。

計画されていた12件:
  【IAM】
  ・iam-root-access-key-check
  ・iam-user-mfa-enabled
  ・iam-user-unused-credentials-check

  【S3】
  ・s3-bucket-public-read-prohibited
  ・s3-bucket-public-write-prohibited
  ・s3-bucket-server-side-encryption-enabled

  【暗号化】
  ・rds-storage-encrypted
  ・encrypted-volumes

  【ネットワーク】
  ・restricted-ssh
  ・vpc-default-security-group-closed

  【ログ・監査】
  ・cloud-trail-log-file-validation-enabled
  ・cloudtrail-enabled

重複整理の方針

Security Hub FSBPを有効化すると、関連するservice-linked Config Rulesが
自動的に作成される。これらはOrganization Config Rulesとは別物で、
名前に「securityhub-」プレフィックスが付く。

例:
  Organization Config Rule: restricted-ssh
  Security Hub service-linked Rule: securityhub-restricted-ssh-xxxxx

重複の影響:
  ・両方が同時に評価を実行する（機能的には共存可能）
  ・Config Rules評価コストが2倍になる（1ルールあたり$0.001/評価）
  ・Aggregatorに両方の結果が表示される（見づらい）

対応方針:
  ・Security Hub導入後、重複するOrganization Config Rulesを削除する
  ・Security Hub側のservice-linked rulesを唯一の評価ソースとする
  ・Security Hubでカバーされないルールがあれば、Organization Config Rulesとして残す

削除対象の判定:
  上記12件のOrganization Config Rulesのうち、
  FSBPのコントロールでカバーされるもの:

  | Organization Config Rule | FSBP コントロール | 削除 |
  |---|---|---|
  | iam-root-access-key-check | IAM.4 | ✅ 削除 |
  | iam-user-mfa-enabled | IAM.5 | ✅ 削除 |
  | iam-user-unused-credentials-check | IAM.22 | ✅ 削除 |
  | s3-bucket-public-read-prohibited | S3.2 | ✅ 削除 |
  | s3-bucket-public-write-prohibited | S3.3 | ✅ 削除 |
  | s3-bucket-server-side-encryption-enabled | S3.4 | ✅ 削除 |
  | rds-storage-encrypted | RDS.3 | ✅ 削除 |
  | encrypted-volumes | EC2.3 | ✅ 削除 |
  | restricted-ssh | EC2.13 | ✅ 削除 |
  | vpc-default-security-group-closed | EC2.2 | ✅ 削除 |
  | cloud-trail-log-file-validation-enabled | CloudTrail.4 | ✅ 削除 |
  | cloudtrail-enabled | CloudTrail.1 | ✅ 削除 |

  → 初期12件の全てがFSBPでカバーされる

コスト影響の整理:
  ・Security Hub 導入時は Recorder を再作成しない（fd-organization-config はそのまま）
  ・追加されるのは service-linked Config Rules（ルール評価）のみ
  ・ルール評価コスト: $0.001/評価（最初の100,000件/月は無料）
  ・CI 記録コスト（$0.003〜$0.012/件）とは異なり、はるかに安い
  ・Recorder 再作成時に発生した $3,742 のコスト高騰（CI 一括生成）は再発しない
  ・Organization Config Rules と service-linked rules の並行期間に
    ルール評価が重複するが、ルール評価コストは軽微
    （例: 12件 × 1,000リソース = 12,000評価 → 無料枠内）

削除の方針:
  ・Security Hub 導入後に Organization Config Rules を削除する
  ・削除は develop/staging の先行検証でコスト実測した後に実施
  ・先行削除は不要（ルール評価の二重課金は軽微で、CI 記録の高騰とは無関係）

削除手順:
  1. Security Hub 導入後、service-linked rules が全アカウントに展開されたことを確認
  2. Aggregator で両方のルールの評価結果を比較し、差異がないことを確認
  3. Organization Config Rules を Terraform から削除
     → fastdoctor-template/common/security-tooling/config.tf の
       aws_config_organization_managed_rule リソースを削除して apply

将来カスタム要件が出た場合:
  ・Security Hub のコントロールでカバーされない組織固有のルールは
    Organization Config Rules として追加する
    例: 特定タグの必須化、特定 AMI 以外の検出 等
  ・現時点ではカスタム要件はないため Organization Config Rules は全削除でよい

8. Service-Linked Configuration Recorder

概要

CSPM + Security Hub（V2）の両方が有効な場合、service-linked configuration recorder（SLR）
が自動的に作成される。CSPM 単独運用の場合は作成されない。

SLR の作成条件（AWS サポート ケース #16485 で確認済み）:
  ・CSPM と Security Hub（V2）の両方が有効であること
  ・customer managed recorder の有無に関わらず確実に作成される
  ・他の阻害条件はない

SLR 一覧（infra-dev で V2 有効化時に確認・2026-08-24）:

  | リージョン      | SLR 名                                          | Scope    | ServicePrincipal                        |
  |----------------|------------------------------------------------|----------|----------------------------------------|
  | ap-northeast-1 | AWSConfigurationRecorderForSecurityHubAssets    | INTERNAL | assets.securityhub.amazonaws.com       |
  | ap-northeast-1 | AWSConfigurationRecorderForSecurityHubCSPM      | INTERNAL | cspm.securityhub.amazonaws.com         |
  | us-east-1      | AWSConfigurationRecorderForSecurityHubAssetsGlobal | INTERNAL | assets.global.securityhub.amazonaws.com |

  ・Assets: ホームリージョンにリージョナルリソース用（約230種類）として作成
  ・AssetsGlobal: us-east-1 にグローバルリソース（IAM, CloudFront, Route53 等11種類）用として作成
  ・CSPM: ホームリージョンに CSPM 評価用として作成

recording scope:
  ・全て INTERNAL（AWS サポート確認済み）
  ・CI 配信なし、課金なし
  ・customer managed recorder の DAILY オーバーライドが上書きされることはない
  ・recording frequency precedence は PAID の SLR にのみ適用される仕様のため、
    INTERNAL の SLR では発生しない

CSPM 単独運用の場合（現在の Phase A〜E）:
  ・SLR は作成されない
  ・customer managed recorder（fd-organization-config）を使用して CSPM が評価を行う
  ・Config.1 は customer managed recorder の設定が正しければ PASSED

CSPM + V2 の両方が有効な場合（Phase F）:
  ・SLR が自動作成される
  ・CSPM は SLR を使用して評価を行い、customer managed recorder を参照しなくなる
  ・Config.1 は常に PASSED（SLR が自動管理するため）
  ・customer managed recorder は独立して稼働を継続する（S3 配信、Aggregator 等）

Customer Managed Recorder の方針

V2 有効化後、SLR が Security Hub の評価をカバーするため、
customer managed recorder（CMR）は Security Hub のためには不要になる。

ただし CMR を削除すると以下の機能が失われる（SLR は INTERNAL のため動作しない）:
  ・S3 への CI 配信（リソース設定変更の履歴記録）
  ・Config Aggregator による全アカウント横断検索
  ・Organization Config Rules の動作（Phase D で削除予定のため影響小）

CMR 削除は不可逆:
  ・削除後の期間の CI は遡って取得できない
  ・再作成しても削除期間の履歴は失われる

方針:
  ・CMR を残すアカウント（本番・本番相当・基盤アカウント）:
    - production          — 本番環境
    - amazon-connect      — 本番環境
    - hospital-ai-prod    — 本番環境
    - rdip-production     — 本番環境
    - online-internal-production — 本番環境
    - log-archive         — ログ保管基盤。監査対応に必要
    - security-tooling    — セキュリティ基盤（Delegated Admin）。Config Aggregator も稼働
    - integration         — 各アカウントへのスイッチロール踏み台。本番経由にも使用
    理由:
    - インシデント時の設定状態の遡及確認に備える
      （CloudTrail は「誰が API を呼んだか」の記録であり、
      「その時点でどう設定されていたか」の再構成は困難）
    - 監査で過去の設定状態の提示を求められた場合に対応できる
    - AWS::Config::ResourceCompliance の記録停止でコスト最適化
      （Phase C の Datadog 転送構築後に実施。詳細は後述）
    - Bedrock WorkloadIdentity 除外・DAILY オーバーライドは維持
    - コスト: Config の Cost Explorer 実績は production 約 $54/月、fd-sys 約 $56/月
      ※ Config Rules 評価等も含むため全額が CMR のコストではないが、
        CI 記録がコストの大半を占めるため、CMR を残す場合の保険コストは最大で約 $110/月

  ・CMR を削除するアカウント（非本番・検証用）:
    - develop             — アプリケーション開発環境
    - staging             — ステージング環境
    - infra-dev           — インフラ開発環境（定期リセット対象）
    - cc-poc              — PoC 環境
    - rdip-staging        — RDIP ステージング環境
    - external-relation   — 外部連携検証用（リソースなし）
    - online-temporal-poc — PoC 環境
    理由:
    - Security Hub の評価は SLR でカバー
    - staging $150/月、develop も同程度のコスト削減が見込める
    - 開発環境は壊れても作り直せるため不可逆リスクは許容可能

根拠:
  ・3省2ガイドラインで Config CI の S3 配信は明示的に要求されていない
  ・社内ログ長期保管設計（Notion）でも Config CI は保存対象ログ種別に含まれていない
  ・CloudTrail が操作ログ（誰が何の API を呼んだか）の監査要件をカバーしている

AWS::Config::ResourceCompliance の記録停止

概要:
  Config Rules の評価結果（COMPLIANT / NON_COMPLIANT）が変わった時に記録される CI。
  リソースの設定変更ではなく「ルールへの準拠状態の変更記録」。
  例: S3 バケットが s3-bucket-server-side-encryption-enabled ルールに対して
      COMPLIANT → NON_COMPLIANT に変わった → ResourceCompliance の CI が1件記録される

停止しても影響がないもの:
  ・Security Hub CSPM のセキュリティチェック — 影響なし（AWS 公式が明記）
  ・Config Rules の評価自体 — 影響なし（評価は引き続き実行される）
  ・Config コンソールでの準拠/非準拠の表示 — 影響なし
  ・リソース設定変更の CI 記録（EC2, RDS, S3 等）— 影響なし（別の CI）

停止で失われるもの:
  ・ResourceCompliance の CI が S3 に配信されなくなる
  ・「この S3 バケットがいつ NON_COMPLIANT になったか」の変更履歴を
    Config CI として S3 に保存しなくなる

補足:
  ・Security Hub の findings は 90日で自動削除される（アーカイブ後30日で永久削除）

AWS 公式の推奨:
  "If you use the AWS Config configuration recorder only for Security Hub CSPM,
   and don't use this configuration item for other purposes, we recommend
   turning off recording for it in AWS Config. This can reduce your AWS Config costs.
   You don't need to record AWS::Config::ResourceCompliance for security checks
   to work in Security Hub CSPM."
  出典: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-setup-prereqs.html

コスト削減効果:
  ・ResourceCompliance の CI 発生量に応じた Config コストの一部削減
  ・この CI を他用途で使用していないため、停止によるデメリットはない

実施タイミング:
  ・Phase C（通知基盤統合）で Security Hub findings の Datadog 転送を構築した後に実施
  ・Datadog で findings の履歴が検索できることを確認してから停止する
  ・停止前に ResourceCompliance の代替手段（Datadog 検索）が機能していることを検証

9. Cross-Region Aggregation

設計

Security HubのfindingsをDelegated Adminの1リージョンに集約する。

設定:
  ・ホームリージョン: ap-northeast-1（東京）
  ・リンクリージョン: SCP 許可4リージョン（SPECIFIED_REGIONS）
    - ap-northeast-1（東京）
    - us-east-1（バージニア）
    - us-west-2（オレゴン）
    - ap-northeast-3（大阪）
  ・4リージョンのfindingsが東京リージョンに集約される
  ・SPECIFIED_REGIONS を選択した理由は Section 11（マルチリージョン方針）を参照

メリット:
  ・Security Hubコンソールで4リージョンのfindingsを一画面で確認可能
  ・EventBridge "Findings Imported V2" イベントは、集約リージョン（東京）に
    リンクリージョンのfindingsが自動的に含まれる（AWS公式ドキュメント確認済み）
    "In an aggregation Region, the event feed in EventBridge includes events
    for findings from the aggregation Region and the linked Regions.
    Cross-Region findings are included in the event feed in near real time."
    → 通知基盤は東京リージョン1箇所のみに構築すれば全findingsをカバーできる

注意:
  ・この機能は "Findings Imported V2" イベントタイプでのみ利用可能
  ・旧イベントタイプ "Security Hub Findings - Imported"（CSPM用）は
    リージョンローカルのみのため使用しない

Terraform管理:
  ・aws_securityhub_finding_aggregator — Cross-Region Aggregation設定
  ・配置: fastdoctor-template/common/security-tooling/securityhub.tf

10. 通知設計

通知基盤の統合

現在のGuardDuty専用通知基盤を、Security Hub統合通知基盤に作り替える。

リネーム:
  ・guardduty-notification.tf → security-notification.tf
  ・guardduty-notification モジュール → security-notification モジュール
  ・リソース名もsecurity-notification系に統一

変更理由:
  ・Security Hubには GuardDuty / Config Rules / Inspector の全findingsが集約される
  ・EventBridgeのsourceが aws.guardduty から aws.securityhub に変わる
  ・1つの通知基盤で全セキュリティサービスのfindingsをカバーできる

通知経路

通知（EventBridge ルール① — Slack通知）:
  ・対象: Security Hub findings のうち severity HIGH/CRITICAL
  ・経路: EventBridge → SNS → Amazon Q Developer → Slack（#squad-sre-noti-security）
  ・リージョン: 東京（ap-northeast-1）のみ
    ※ Cross-Region Aggregation + "Findings Imported V2" により、
      集約リージョンのEventBridgeに全リンクリージョンのfindingsが含まれるため、
      東京1箇所で全リージョンのfindingsをカバーできる

  EventBridgeイベントパターン:
    {
      "source": ["aws.securityhub"],
      "detail-type": ["Findings Imported V2"],
      "detail": {
        "findings": {
          "Severity": {
            "Label": ["HIGH", "CRITICAL"]
          },
          "Workflow": {
            "Status": ["NEW"]
          },
          "RecordState": ["ACTIVE"]
        }
      }
    }

    注意:
      ・detail-type は "Findings Imported V2" を使用する（Security Hub用）
        ※ "Security Hub Findings - Imported" はCSPM用の旧イベントタイプ
        ※ 両方がaws.securityhubソースで送信されるため、
          detail-typeを正しく指定しないと重複通知になる
      ・Workflow.Status = "NEW" でフィルタし、初回検知のみ通知
        （更新されたfindingsの再通知を防ぐ）
      ・RecordState = "ACTIVE" でアーカイブ済みfindingsを除外
      ・severityはLabel（HIGH/CRITICAL等）で判定
        （GuardDutyのnumericとは異なる）

調査用収集（EventBridge ルール② — Datadog）:
  ・対象: 全severity（INFORMATIONAL含む全findings）
  ・経路: EventBridge → Datadog Forwarder Lambda → Datadog Log Management
  ・リージョン: 東京（ap-northeast-1）のみ（Cross-Region Aggregationで全findingsカバー）

  EventBridgeイベントパターン（Security Hub用）:
    {
      "source": ["aws.securityhub"],
      "detail-type": ["Findings Imported V2"]
    }

  Datadog転送:
    ・Datadog公式がSecurity HubについてForwarder Lambda方式を推奨
      参照: https://docs.datadoghq.com/integrations/amazon_security_hub/
    ・Datadog公式の推奨構成:
      - EventBridge → Datadog Forwarder Lambda
      - Datadog公式ドキュメントでは "Security Hub Findings - Imported"（CSPM用）と
        "Findings Imported V2"（Security Hub用）の2ルール作成を推奨しているが、
        重複を避けるため "Findings Imported V2" のみを使用する
    ・既存のForwarder Lambda（東京リージョン）を再利用
    ・新規のEventBridgeルールを追加するだけでSecurity Hub findingsも転送可能

GuardDuty通知基盤との構成の違い:
  ・GuardDuty通知: 4リージョンにEventBridge + SNS + DLQを構築
    → GuardDutyのEventBridgeイベントはリージョンローカルのため
  ・Security Hub通知: 東京リージョン1箇所のみ
    → "Findings Imported V2" + Cross-Region Aggregationで
      全リージョンのfindingsが東京のEventBridgeに含まれるため
  ・Forwarder Lambdaは東京リージョンの既存1つを再利用
    （他3リージョンのForwarderはGuardDuty直接通知用として残る。
    GuardDuty直接通知を削除する際に不要になれば整理する）

GuardDuty通知との統合

Security Hub導入後の通知の流れ:

  Before（現在）:
    GuardDuty findings → EventBridge（source: aws.guardduty）→ SNS/Lambda

  After（Security Hub導入後）:
    GuardDuty findings → Security Hub → EventBridge（source: aws.securityhub）→ SNS/Lambda

  GuardDuty直接のEventBridgeルールを残すか:
    ・Security Hubが全findingsを集約するため、GuardDuty直接のルールは不要
    ・ただし、Security Hub導入直後は並行運用として両方のルールを維持
    ・Security Hubの通知が安定したら（1-2週間）、GuardDuty直接のルールを削除

  統合後のEventBridgeルール（東京リージョンのみ）:
    ルール①: security-slack-notification
      source: aws.securityhub, detail-type: "Findings Imported V2",
      severity HIGH/CRITICAL → SNS → Slack
    ルール②: security-datadog-collection
      source: aws.securityhub, detail-type: "Findings Imported V2",
      全severity → Forwarder Lambda → Datadog

  削除するルール（統合完了後）:
    ・guardduty-slack-notification（4リージョン全て）
    ・guardduty-datadog-collection（4リージョン全て）
    ※ GuardDuty直接通知を削除後、他3リージョンのForwarder Lambdaが
      不要になれば合わせて整理する

通知フィルタリング設計

大前提: CSPM コントロールと Inspector CVE を分ける

  ・CSPMコントロール = 設定ミス。有限で、直せば収束する
  ・Inspector CVE = 新規CVEで増え続ける「流量」。ゼロにはならない
  ・同じダッシュボード・同じ通知に混ぜると必ず破綻する
  → 前者は「潰し切る」、後者は「稼働中イメージの Critical を N日以内に解消」
    という SLA 型で管理する

即時通知:
  ① CSPM コントロール CRITICAL かつ新規:
    EventBridge → SNS → Amazon Q Developer → Slack
    フィルタ:
      Severity.Label = CRITICAL
      Workflow.Status = NEW
      RecordState = ACTIVE
      Compliance.Status = FAILED
      ProductName = "Security Hub"（Inspector を除外）

  ② CVE: 稼働中イメージ かつ Critical かつ Fix available = Yes のみ:
    EventBridge → SNS → Amazon Q Developer → Slack（別チャネル推奨）

サマリー通知:
  ③ CSPM コントロール HIGH: 週次サマリー

  サマリーの実現方法:
    ・EventBridge Scheduler → Lambda → Slack Webhook
    ・脆弱性はセキュアな情報のため、AWS に閉じたサービスで実現する
    ・Security Hub Insight を事前作成すれば集計済み結果が返るため、
      Lambda は整形のみで済む
    ・集計量が多い場合は Bedrock の活用を検討（集計は Lambda で確定させ、Bedrock は要約に限定）
    ※ "Security Hub Insight Results" イベントは手動カスタムアクションでしか
      発火せず、スケジュール配信には使えない

  参考実装（aws-samples）:
    ① 定期サマリー型（日次サマリーに適用可能）
      EventBridge → Lambda で集計 → Bedrock で要約 → 配信
      https://github.com/aws-samples/analyze-securityhub-findings-with-bedrock
    ② 個別 finding 解説型（トリアージ支援）
      カスタムアクション → Lambda → Bedrock が1件ずつ要約 → Security Hub に書き戻し
      https://github.com/aws-samples/generative-ai-summarize-securityhub
    ※ 集計は Lambda 側で確定させ、Bedrock は要約に限定する
      （件数の算出まで LLM に任せると誤りを検知できないため）
    ※ まずは①の日次サマリーで検討する

suppress / disable の使い分け:
  ・disable（Configuration Policy）→ チェック未実行、課金なし
    用途: 自社に該当しないコントロール
  ・suppress（automation rules）→ チェック実行、課金継続
    用途: 該当するが当面受容するもの
    ※ automation rules は新規・更新の findings に適用され、既存の滞留分には遡及しない
    ※ 初期の一括処理は BatchUpdateFindings を使用（上限: 管理者アカウントあたり100ルール）
  ・Inspector suppression rule → suppress された findings は Security Hub / EventBridge に配信されない
    用途: CVE の抑制（通知基盤に有効）
    ※ 委任管理者アカウントのみ作成可能、反映に最大24時間
  ・いずれも「期限付き」にし、四半期ごとの棚卸しを推奨

suppress 候補:
  ① Fix available = No の CVE
  ② 非稼働イメージの CVE
  ③ 開発専用リポジトリの CVE
  ④ 自社に該当しないコントロール（← こちらは disable 側）

Terraform管理

新規作成（東京リージョンのみ）:
  ・EventBridgeルール①（Slack通知用 — CSPM CRITICAL 即時）
  ・EventBridgeルール②（Datadog転送用 — "Findings Imported V2", 全severity）
  ・SNSトピック + ポリシー
  ・SQS DLQ + ポリシー
  ・chatbot（IAMロール + ポリシー + CloudFormation Stack）
  ・Lambda permission

  ※ GuardDutyの4リージョン構成と異なり、Security Hubでは
    Cross-Region Aggregation + "Findings Imported V2" により
    東京リージョン1箇所で全findingsをカバーできる

再作成不要:
  ・Forwarder Lambda — 名前はdatadog-forwarderのまま。既存を再利用
  ・Secrets Manager（Datadog APIキー）

変数名の移行:
  ・var.guardduty_datadog_api_key → var.security_datadog_api_key にリネーム
  ・variable.tf の変数宣言を変更
  ・terraform.tfvars の変数名も合わせて変更
  ・S3上の tfvars ファイルも upload-tfvar.sh で更新

コードの配置:
  fastdoctor-template/common/security-tooling/security-notification.tf（新規）
  fastdoctor-template/common/security-tooling/guardduty-notification.tf（削除）

11. Central Configuration

Delegated Admin からセキュリティ標準・コントロールの設定を
全アカウント・全リージョンに一括適用する仕組み。
Configuration Policy を作成し、アカウント/OU/Root に適用する。
アカウント/OU単位で異なるポリシーを適用したり、
特定のアカウントを self-managed（自己管理）に指定して適用外にできる。
参照: https://docs.aws.amazon.com/securityhub/latest/userguide/central-configuration-intro.html

設定:
  ・ホームリージョン: ap-northeast-1（東京）
  ・リンクリージョン: SCP 許可4リージョン（SPECIFIED_REGIONS）
  ・configuration policy: 1つ（全アカウント共通）
    - Security Hub有効化
    - FSBP + CIS v5.0.0 + AISBP 有効化
    - 不要なコントロール（EKS系、CIS CloudWatch Logs系等）を無効化
  ・段階的適用時は target でアカウント/OU を指定し、
    適用しないアカウントは self-managed に設定する

Terraform管理:
  ・aws_securityhub_configuration_policy — configuration policy定義
  ・aws_securityhub_organization_configuration — Central Configuration有効化
  ・配置: fastdoctor-template/common/security-tooling/securityhub.tf

マルチリージョン方針

方針: Security Hub を SCP 許可4リージョンで有効化する（SPECIFIED_REGIONS）

各セキュリティサービスのリージョン方針との整合:
  ・CloudTrail: 全リージョン（マルチリージョントレイル）
  ・GuardDuty: 全サポートリージョン（AWS推奨。SCP② NotAction に追加済み）
  ・Config Recorder: 4リージョン（SCP許可リージョンのみ）
  ・Security Hub: 4リージョン（Config Recorder と同じ範囲）← 今回

4リージョンに限定する理由:
  ・SCP 外リージョンには Config Recorder が存在しないため、
    Configuration Policy の適用が FAILED になる
    （Config が「properly configured」でないと標準を有効化できない）
  ・ALL_REGIONS で有効化すると、SCP 外リージョンで Config.1 / CIS 3.3 の
    CRITICAL findings が大量にノイズとして発生し、
    本当に対処すべき findings が埋もれる（infra-dev 検証で確認済み）
  ・SCP でリソース作成を禁止しているリージョンでは
    セキュリティ標準のチェック対象リソースが存在しないため実害なし

GuardDuty との違い:
  ・GuardDuty は全リージョンのまま維持する（Security Hub とは性質が異なる）
  ・Security Hub: リソースの設定をチェック → リソースがなければチェック不要
  ・GuardDuty: API コール・ネットワークトラフィックを監視
    → SCP を迂回した攻撃（クレデンシャル漏洩、SCP 設定ミス等）を検知するため
      リソースがないリージョンでも有効にしておく意味がある
  ・GuardDuty はアクティビティがないリージョンではコスト $0
  ・AWS 公式も GuardDuty は全リージョンでの有効化を推奨:
    "It is highly recommended that you enable GuardDuty in all supported AWS Regions.
    Doing so allows GuardDuty to generate findings about unauthorized or unusual activity,
    even in Regions that you do not actively use."
  ・GuardDuty は独自の通知基盤（4リージョン × EventBridge → SNS → Slack）で
    全リージョンの脅威検知をカバーしているため、Security Hub を4リージョンに
    絞っても攻撃検知に影響なし

Config Recorder との関係:
  ・customer managed recorder（fd-organization-config）は4リージョンのまま
  ・Security Hub を4リージョンに限定するため、
    SCP 外リージョンの service-linked recorder は作成されない
  ・4リージョンでは service-linked recorder が自動作成される

SCP 修正:
  ・securityhub:* を SCP② の NotAction に追加済み
  ・config:* を SCP② の NotAction に追加済み
    （Security Hub の service-linked role が Config API を使用するため）

Phase C（通知基盤統合）時の考慮:
  ・GuardDuty 直接通知を削除して Security Hub 経由に統合した後は、
    SCP 外リージョンの GuardDuty findings が Security Hub に集約されなくなる
  ・その時点で以下のいずれかを判断:
    - SCP 外リージョンだけ GuardDuty 直接通知を残す
    - SCP 外リージョンの GuardDuty findings は発生頻度が極めて低いため許容する
    - Config を全リージョンに展開して ALL_REGIONS に戻す
  ・現状は GuardDuty 直接通知が4リージョンで動作しているため今すぐの問題はない

将来の変更:
  ・Config を全リージョンに展開する場合は ALL_REGIONS に戻す

12. SCP

SCP修正

SCP②（リージョン制限: deny_non_approved_regions）への対応:

  Security HubのCentral Configurationはホームリージョンから
  リンクリージョンの設定をサーバーサイドで管理する。

  追加対象（いずれも GuardDuty と同じパターンで NotAction に追加）:
    ・"securityhub:*" — Central Configuration の管理に必要 ✅ 追加済み
    ・"config:*" — Security Hub の service-linked role が全リージョンで
      Config API（service-linked recorder の作成・管理等）を使用するため ✅ 追加済み
  修正ファイル: scp_policies/deny_non_approved_regions.json

SCP①（セキュリティサービス保護: deny_disable_security_services）:
  ・securityhub:DisableSecurityHub は既に設定済み ✅
  ・securityhub:DisassociateFromAdministratorAccount を追加済み ✅
    — メンバーアカウントからのDelegated Admin離脱を防止
    （GuardDutyと同様のパターン: guardduty:DisassociateFromAdministratorAccountと対）

13. コスト

料金体系:

  現在（CSPM 単独・Phase A〜E）:
    ・CSPM: チェック数ベース（$0.001/件、最初の10万件/月）
    ・Inspector: イメージ数・スキャン数ベース（個別課金）
    ・Config: customer managed recorder の CI 記録コスト
    ・各サービスが独立して課金される

  V2 有効化後（Phase F・Essentials プラン）:
    ・リソースユニット定額: $3.75/ユニット/月（us-east-1）、$4.10/ユニット/月（東京）
    ・V2 を有効にすると、含まれる機能の課金は統合される
      "When you enable Security Hub, billing for included capabilities is
       consolidated through Security Hub streamlined pricing."
      出典: https://aws.amazon.com/jp/security-hub/pricing/
    ・Essentials に統合される（個別課金がなくなる）もの:
      - CSPM チェック、findings 取り込み、オートメーションルール
      - Inspector EC2/ECR/Lambda 脆弱性スキャン、CIS ベンチマーク評価
      - GuardDuty EC2/EBS マルウェア保護
      - Exposure Findings（攻撃パス可視化）
    ・Essentials に含まれない（個別課金が残る）もの:
      - GuardDuty 脅威検知（CloudTrail, VPC Flow Logs 等の分析）
      - Inspector Lambda コードスキャン
    ・Config の CMR コストは Essentials とは独立（Section 8 参照）

  リソースユニット換算:
    ・EC2 1台 = 1ユニット
    ・Lambda 12関数 = 1ユニット
    ・ECR 18イメージ = 1ユニット
    ・IAM 125ユーザー・ロール = 1ユニット

コスト比較（2026-08 実績ベース）:

  staging:
    ・個別課金: Inspector $308/月 + CSPM $8/月 = $316/月
    ・Essentials: Cost Estimator 見積もり $276/月
    → Essentials の方が $40/月 安い

  production:
    ・個別課金: Inspector $79/月 + CSPM $3/月（予想）= $82/月
    ・Essentials: Cost Estimator 見積もり $88/月
    → Essentials の方が $6/月 高い（ほぼ同額）

  2アカウント合算:
    ・個別: $398/月、Essentials: $364/月 → Essentials の方が $34/月 安い

  ※ コストの大半は ECR イメージ数に依存（staging で92%）
  ※ Inspector 精査（ECR ライフサイクル、再スキャン期間縮小）後に再比較が必要
  ※ Cost Estimator の見積もりは us-east-1 単価で計算されている可能性あり、
    東京リージョンでは単価が異なるため注意

  CMR 削除によるコスト削減:
    ・staging: Config $150/月 → 削除で $0
    ・production + fd-sys: Config 実績 約 $110/月（CMR の CI 記録が大半を占める）
      → CMR を残す場合は最大で約 $110/月の保険コスト（ResourceCompliance 停止で微減）
    ・V2 導入 + 本番以外の CMR 削除で月 $200〜300 の削減が見込める

  コスト最適化:
    ・AWS::Config::ResourceCompliance の記録停止（AWS 公式推奨）
      "If you use the AWS Config configuration recorder only for Security Hub CSPM,
       and don't use this configuration item for other purposes, we recommend
       turning off recording for it in AWS Config."
    ・不要コントロール無効化でチェック対象を削減
    ・ECR ライフサイクルポリシーでイメージ数を削減（コスト影響最大）

コスト確認方針:
  Step 1: Security Hub Cost Estimator で事前概算
    ・Security Hub コンソール（設定 → 使用）に組み込みのコスト見積もりツール
    ・左側（個別課金）vs 右側（Essentials）の比較が可能
    ・リソース数は CLI で取得して入力
    ※ 30日無料トライアルは AWS 公式では提供されるが、
      HyperBilling（リセラー請求）では反映されないため、
      トライアル期間中も通常課金される前提で計画する
  Step 2: staging/develop でコスト実測
    ・Cost Explorer で Inspector + Security Hub + Config のコスト推移を監視
    ・V2 有効化前後のコスト変動を比較
  Step 3: 実測結果に基づき全アカウント展開・V2 導入の判断

コスト高騰の検知:
  Config コスト高騰（$3,742）の教訓を踏まえ、以下の対策を講じる。

  ・Datadog Monitor（Config CI 数の anomaly アラート）:
    - CloudWatch メトリクス ConfigurationItemsRecorded を監視
    - 急激な増加を検知した場合にアラート
    - WorkloadIdentity の記録再発を早期検知
    → このアラートが実装されてから本番に Security Hub を導入する

  ・導入後1週間は Cost Explorer で手動確認:
    - Config コスト（DAILY/CONTINUOUS 別）の日次推移
    - Security Hub / Inspector のコスト
    - 異常な増加がないことを確認

アドオン機能の検討

Essentials に加えて以下のアドオンがある。初期は全て不採用とし、今後検討する。
詳細は AWS 公式料金ページを参照: https://aws.amazon.com/jp/security-hub/pricing/

① Threat Analytics（GuardDuty 統合課金）: 初期は不採用
  ・GuardDuty 組織統合で既に個別課金で稼働中（月$1,000-1,100）
  ・アドオンは個別課金を統合課金に移行するもの。検知の仕組みは変わらない
  → Essentials 導入後に個別課金 vs 統合課金のコスト比較を行い判断

② Lambda コードスキャン（Inspector）: 初期は不採用
  ・「コード自体」の脆弱性検出（SQLインジェクション、認証情報のハードコード等）
  ・Essentials の Lambda スキャンは「ライブラリの既知 CVE」のチェック（別物）
  ・関数ごと月額の追加課金。本番の Lambda 関数数: production 28個、fd-sys 165個
  → まず Essentials のパッケージスキャンで傾向を把握してから判断
  → 詳細は Inspector 設計書で検討

③ S3 Malware Protection（GuardDuty）: 初期は不採用
  ・S3 アップロードファイルのマルウェアスキャン
  ・バケット数が多く監視対象の整理が必要（GuardDuty 設計書に今後のタスクとして記載済み）
  → 監視対象バケットの整理後に検討

④ Extended プラン（パートナーソリューション）: 不採用
  ・CrowdStrike、Okta、Proofpoint 等。現時点では要件なし

14. Findings の集約

Security Hub を有効化すると、GuardDuty / Config Rules / Inspector / Macie / 
IAM Access Analyzer 等の findings が Delegated Admin に自動集約される。
各サービスで追加設定は不要（有効化されていれば自動連携）。
対応サービスの詳細: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-internal-providers.html

我々の環境での確認事項:
  ・GuardDuty（組織統合済み）の findings が Security Hub 経由で集約されているか
  ・Config Rules の評価結果が Security Hub に取り込まれているか
  ・Cross-Region Aggregation で全リージョンの findings が東京に集約されているか
  ・マネジメントアカウントは Security Hub 有効化後に集約対象になる

15. Findings の S3 エクスポート

Security Hub の findings は 90日で自動削除される（AWS仕様）。
監査要件（3省2ガイドライン: セキュリティログ5年以上保存）を満たすため、
findings を S3 にエクスポートして長期保存する。

方針:
  ・GuardDuty の S3 エクスポート（fd-guardduty-findings）と同様の構成
  ・エクスポート先: fd-log-archive (385800115893)
  ・S3バケット: fd-securityhub-findings（新規作成）
  ・KMS暗号化
  ・ライフサイクル: CloudTrail / GuardDuty と同じ
    Standard(365日) → Glacier(2555日/7年) → 削除
  ・Security Hub 導入時に合わせて構築する

  構成:
    Security Hub findings → EventBridge → Lambda → S3
    ・GuardDuty の Forwarder Lambda 方式と同じパターンを踏襲する
    ・Kinesis Data Firehose 方式は追加コスト・設定の複雑さがあるため不採用
    ・Lambda で finding JSON をそのまま S3 に書き込む（シンプル）

  Datadog との使い分け:
    ・Datadog: リアルタイム分析・検索・ダッシュボード（保持期間は Datadog プランに依存）
    ・S3: 監査用の長期保存（7年）。Athena で必要時に検索可能

Terraform管理:
  ・S3バケット + KMS + ライフサイクル: fastdoctor-template/common/log-archive/securityhub.tf
  ・EventBridge + エクスポート設定: fastdoctor-template/common/security-tooling/securityhub.tf

16. Terraform管理

リソース配置

fd-security-tooling（Terraform）:
  Security Hub基盤:
    ・aws_securityhub_account — Security Hub CSPM 有効化（ホームリージョン）
    ・aws_securityhub_account（リンクリージョン）— Consolidated control findings 設定
    ・aws_securityhub_account_v2 — Security Hub V2 有効化（Phase F、AWS Provider v6 以降）
    ・aws_securityhub_organization_configuration — 組織設定（Central Configuration）
    ・aws_securityhub_configuration_policy — configuration policy
    ・aws_securityhub_finding_aggregator — Cross-Region Aggregation

  通知基盤（security-notification.tf — guardduty-notification.tfからリネーム）:
    ・東京リージョンのみに構築（Cross-Region Aggregation + "Findings Imported V2" で
      全リージョンのfindingsが東京のEventBridgeに含まれるため）
      - EventBridgeルール①（Slack通知用 — "Findings Imported V2", severity HIGH/CRITICAL）
      - EventBridgeルール②（Datadog転送用 — "Findings Imported V2", 全severity）
      - SNSトピック + ポリシー
      - SQS DLQ + ポリシー
      - Lambda permission
    ・chatbotモジュール（Amazon Q Developer — 東京リージョンSNS）
    ・Forwarder Lambda（東京リージョンの既存を再利用、変更なし）

コードの配置:
  fastdoctor-template/common/security-tooling/securityhub.tf（新規）
  fastdoctor-template/common/security-tooling/security-notification.tf（リネーム）

マネジメントアカウント（手動操作）:
  ・Delegated Admin登録（各リージョンで実施、またはCentral Configurationでホームリージョンのみ）
  → Terraform管理しない（マネジメントアカウントにTerraform環境を置かない方針）

17. 適用手順

概要

Phase A: 準備（SCP①②修正 + Delegated Admin登録）
Phase B: Security Hub CSPM 構築（Central Configuration + FSBP + CIS + AISBP 有効化、全リージョン）
Phase C: 通知基盤統合（guardduty-notification → security-notification）
Phase D: Organization Config Rules 削除（develop/staging でコスト実測後）
Phase E: 動作確認・安定化
Phase F: Security Hub V2（Essentials）導入（コスト比較後に判断）

詳細手順

Phase A: 準備

  Step 1: SCP①修正（DisassociateFromAdministratorAccount を追加）
    → scp_policies/deny_disable_security_services.json に追加
    → fd-security-toolingでterraform apply

  Step 2: SCP②修正（securityhub:* を NotAction に追加）
    → scp_policies/deny_non_approved_regions.json に追加
    → 全リージョンで Security Hub を有効化するため（GuardDuty と同じパターン）
    → fd-security-toolingでterraform apply

  Step 3: マネジメントアカウントでDelegated Admin登録
    aws securityhub enable-organization-admin-account \
      --admin-account-id 860801568046 \
      --region ap-northeast-1
    ※ Central Configuration使用の場合、ホームリージョンのみで実施

  Step 3.5: マネジメントアカウントで Security Hub を手動有効化（4リージョン）
    ※ Central Configuration の管理下ではマネジメントアカウント側から
      EnableSecurityHub を実行できないため、Configuration Policy 適用前に有効化が必要
    ※ 有効化が先行していない場合、Configuration Policy 適用が FAILED になる
    ※ FAILED になった場合の対処手順:
      1. fd-security-tooling からマネジメントアカウントを self-managed に設定
         aws securityhub start-configuration-policy-association \
           --configuration-policy-identifier "SELF_MANAGED_SECURITY_HUB" \
           --target '{"AccountId":"703480710002"}' \
           --region ap-northeast-1 --profile fd-security
      2. マネジメントアカウントで Security Hub を手動有効化
         for region in ap-northeast-1 us-east-1 us-west-2 ap-northeast-3; do
           aws securityhub enable-security-hub --no-enable-default-standards --region $region
         done
      3. fd-security-tooling から再度 centrally managed に戻す
         aws securityhub start-configuration-policy-association \
           --configuration-policy-identifier "<policy-id>" \
           --target '{"AccountId":"703480710002"}' \
           --region ap-northeast-1 --profile fd-security

Phase B: Security Hub構築

  Step 4: fd-security-toolingでSecurity Hub有効化
    → Terraform apply（securityhub.tf）
    → aws_securityhub_account（Security Hub有効化）

  Step 5: Central Configuration有効化
    → aws_securityhub_organization_configuration
    → ホームリージョン: ap-northeast-1
    → リンクリージョン: 全サポートリージョン

  Step 6: Cross-Region Aggregation設定
    → aws_securityhub_finding_aggregator

  Step 7: Configuration Policy作成・適用
    → aws_securityhub_configuration_policy
    → FSBP + CIS v5.0.0 + AISBP 有効化、不要コントロール無効化
    → 全アカウントに適用

  Step 8: service-linked recorder確認
    → Section 8の手順に従い、recording scopeを確認
    → INTERNALであれば対応不要
    → PAIDであればDailyオーバーライドへの影響を評価

  Step 9: 動作確認
    → CSPM の findings が正常に生成されているか確認
    → customer managed recorder に影響がないか確認
    ※ AWS::Config::ResourceCompliance の記録停止は Phase C 完了後に実施（Section 8 参照）

Phase C: 通知基盤統合

  Step 10: security-notification モジュール作成
    → template_modules/common/platform/security-notification/ を新規作成
    → EventBridgeパターンを "Findings Imported V2" に設定
    → リソース名をsecurity-*系に統一

  Step 11: security-notification.tf作成・apply
    → Security Hub用EventBridgeルール + SNS + DLQを東京リージョンのみに構築
      （Cross-Region Aggregation + "Findings Imported V2" により1リージョンで十分）
    → chatbotのproject名変更
    → Forwarder Lambdaは東京リージョンの既存を再利用

  Step 12: 動作確認（並行運用）
    → Security Hub通知とGuardDuty直接通知の両方が届くことを確認
    → Slack、Datadogの両方で確認

  Step 13: 並行運用（1-2週間）
    → 両方の通知ルールを維持

  Step 14: GuardDuty直接通知の削除
    → guardduty-notification.tf を削除
    → guardduty-notification モジュールを削除
    → terraform apply

Phase D: Organization Config Rules 削除

  Step 15: develop/staging でコスト実測後、Organization Config Rules を削除
    → service-linked rules で同等のチェックがカバーされていることを確認
    → Aggregator で両方のルールの評価結果を比較し、差異がないことを確認
    → config.tf から aws_config_organization_managed_rule（12件）を削除
    → fd-security-toolingでterraform apply

  Step 16: 削除後のコスト確認
    → Cost Explorer で Config Rules 評価コストが減少していることを確認

Phase E: 動作確認・安定化

  Step 17: 最終確認
    → 全アカウントでSecurity Hubが有効になっていることを確認
    → FSBP + CIS + AISBP のセキュリティスコアを確認
    → 全findingsソース（GuardDuty, Config, Inspector）が集約されていることを確認
    → Slack通知（HIGH/CRITICAL）が正常に届くことを確認
    → Datadogに全findingsが収集されていることを確認
    → コストを確認（30日無料トライアル期間内）

Phase F: Security Hub V2（Essentials）導入

  前提:
    → Phase A〜E（CSPM 導入）が完了していること
    → Inspector 精査（ECR ライフサイクル、再スキャン期間、レジストリスキャン設定）が完了していること
    → Cost Estimator で個別課金 vs Essentials のコスト比較が完了していること
    → infra-dev での V2 検証が完了していること（2026-08-24 検証済み）

  Step 17.5: マネジメントアカウントで V2 を手動有効化
    ※ CSPM の時と同様、Central Configuration の管理下では
      マネジメントアカウント側から有効化できないため先に実施
    ※ CSPM の委任管理者が設定済みのため、V2 の委任管理者は
      自動的に fd-security-tooling になる（追加設定不要）
      参照: https://docs.aws.amazon.com/ja_jp/securityhub/latest/userguide/securityhub-v2-set-da.html
    aws securityhub enable-security-hub-v2 --region ap-northeast-1

  Step 18: V2 を有効化（fd-security-tooling）
    → Terraform apply（aws_securityhub_account_v2）
    → -target=aws_securityhub_account_v2.main で実行
    → SLR（3つ、全て INTERNAL）の作成を確認
    ※ これだけではメンバーアカウントに V2 は適用されない
    ※ auto_enable_controls の drift が発生する場合がある
      （Central Configuration の管理下で AWS 側が上書きするため）
      → lifecycle { ignore_changes } で対応済み

  Step 18.5: Delegated Admin ポリシーの作成（マネジメントアカウント）
    → マネジメントアカウントで V2 コンソールにアクセス
      https://console.aws.amazon.com/securityhub/v2/home
    → 設定 → 委任された管理者に関するポリシー → ポリシーの更新
    ※ CSPM の委任管理者が設定済みなら V2 の委任管理者は自動設定されるが、
      ポリシーは別途作成が必要

  Step 18.6: Configuration catalog で全アカウントに適用（fd-security-tooling）
    → V2 コンソール → 管理 → 設定 → 設定カタログ
    → 「Security Hub (必須機能とその他の機能)」を選択
    → Security Hub の設定:
      - Security capabilities: Enable essential（アドオンなし）
      - アカウント: すべての組織単位とアカウント
      - リージョン: 一部のリージョンで有効にする（SCP 許可4リージョン）
    → Cross Region Aggregation:
      - ホームリージョン: ap-northeast-1
      - リンクリージョン: us-east-1, us-west-2, ap-northeast-3
    ※ Terraform リソースが存在しないためコンソール操作が必要
    ※ ManagedBy: Console タグを付与

    Configuration catalog の仕組み:
      2つのタイプがある:
      ・ポリシー型: Organizations ポリシーを生成。編集可能。新規アカウントに自動適用
        対象: Security Hub, Inspector
      ・デプロイ型: 一回限りのアクション。編集不可。新規アカウントには自動適用されない
        対象: CSPM（Central Configuration で管理済みのため不要）,
              GuardDuty（GuardDuty 組織統合で管理済みのため不要）
      参照: https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-v2-da-policy.html

    適用結果の想定:
      ・Security Hub ポリシー → 成功（V2 が全アカウントに適用される）
      ・Inspector ポリシー → 成功（Organizations ポリシーで管理。Terraform の
        aws_inspector2_organization_configuration とは競合しない。
        ポリシーは有効/無効のみ制御、設定内容は Terraform で管理可能）
      ・CSPM デプロイ → 失敗する可能性あり（Central Configuration で管理済みの場合）
        → 失敗しても問題なし。CSPM は既に有効化済みで V2 の相関分析にも影響なし

    前提条件:
      ・Inspector の Organizations service access が有効であること
        未有効の場合、マネジメントアカウントで以下を実行:
        aws organizations enable-aws-service-access --service-principal inspector2.amazonaws.com

  Step 19: V2 の動作確認
    → 全メンバーアカウントで V2 が有効化されたか確認
      aws securityhub describe-security-hub-v2 --region ap-northeast-1
    → Exposure findings が生成されているか
    → CIEM（未使用 IAM 分析）が動作しているか
    → V2 ダッシュボードで脅威・露出・リソース・体制管理が表示されるか
    → CSPM の既存 findings に影響がないか

  Step 20: CMR の整理（V2 有効化後）
    → 本番以外のアカウントで CMR 削除を検討（月 $200〜300 削減）
    → 本番の CMR は残す（ResourceCompliance 記録停止でコスト最適化）

  Step 21: コスト監視
    → Cost Explorer で Essentials 課金と個別課金の比較
    → Inspector + CSPM の個別課金がなくなり統合されているか確認
    → CMR 削除分の Config コスト削減を確認
    → Security Hub + Inspector の日額が $100 を超える場合は V2 を無効化
      （aws securityhub disable-security-hub-v2 で即時無効化可能。CSPM には影響しない）

環境ごとの適用順序

Security Hubは Central Configuration で全アカウントに一括適用されるため、
個別アカウントの段階的展開は不要。

ただし、以下の手順で段階的に確認する:
  1. infra-dev で Security Hub 有効化・Central Configuration の基本動作を確認
     → configuration policyで infra-dev のみを対象にテスト
     → 設定手順・Terraformコードの動作検証が目的

  2. develop, staging で先行検証（1-2週間）
     → サービスが稼働しておりリソース量が多いため、
       コスト影響（特に service-linked recorder / Config Rules 評価コスト）を
       正確に把握できる
     → Cost Explorer で以下を監視:
       - Config コスト（DAILY/CONTINUOUS）に変化がないか
       - WorkloadIdentity の記録が再発していないか
       - Security Hub 自体のコスト
     → findings の量・傾向を把握し、通知のノイズレベルを評価

  3. 検証結果を判断
     → コスト増が許容範囲内 → 全アカウント展開へ進む
     → コスト増が想定を超える → 原因特定、AWSサポート相談、対策後に再検証

  4. 全アカウントに適用（マネジメントアカウント含む）
     → staging/develop で問題なければ残り全アカウントに一括適用
     → configuration policy の target を Root に変更
     → マネジメントアカウントもこのタイミングで有効化

動作確認チェックリスト

□ 全アカウントでSecurity Hubが有効になっているか
□ FSBP + CIS + AISBP が全アカウントで有効になっているか
□ 不要コントロール（EKS系等）が無効化されているか
□ Cross-Region Aggregationで全リージョンのfindingsが東京に集約されているか
□ GuardDuty findingsがSecurity Hub経由で集約されているか
□ Config Rules findingsがSecurity Hub経由で集約されているか
□ Slack #squad-sre-noti-security にHIGH/CRITICALのfindingsが通知されるか
□ Datadogに全findingsがログとして収集されているか
□ セキュリティスコアが算出されているか
□ service-linked recorderのrecording scopeを確認済みか
□ Organization Config Rules（初期12件）を削除済みか
□ コストが想定範囲内か

ロールバック手順

Security Hubを無効化する場合:
  ・Central Configuration のconfiguration policyからSecurity Hubを無効化
  ・または Delegated Admin登録を解除
    aws securityhub disable-organization-admin-account \
      --admin-account-id 860801568046 \
      --region ap-northeast-1
  ・Security Hub無効化後もGuardDuty直接通知は引き続き動作する
    （Phase CでGuardDuty直接通知を削除する前にロールバックが必要な場合は
    guardduty-notification.tfをGit履歴から復元してapply）

通知基盤のロールバック:
  ・security-notification.tf を削除
  ・guardduty-notification.tf をGit履歴から復元
  ・terraform apply
  ・GuardDuty直接通知が復旧

18. カスタムアクション

Security Hub コンソール上で findings を選択し、手動でトリガーできるアクション。
ボタンを押すと EventBridge に "Security Hub Findings - Custom Action" イベントが発行され、
EventBridge → Lambda で後続処理を実行する。
自動通知（Findings Imported V2 → Slack/Datadog）とは異なり、
SRE が finding を確認・判断した上で手動で起こすアクション。

想定するアクション:
  ①: Slack調査依頼 — finding を #squad-sre-noti-security に共有
  ②: GitHub Issue起票 — finding の対応タスクを起票
      ※ 組み込みチケット統合は Jira Cloud / ServiceNow のみ対応
        GitHub Issues は非対応のため、カスタムアクション + Lambda で実装
  ③: サプレッション — 既知の許容事項・誤検知をアーカイブ

検知〜修正リリースまでの具体的な運用フロー、
カスタムアクションの詳細実装は Security Hub 導入後に別途設計する。

19. 今後のタスク

短期タスク

Week 1: 母数削減 + 確認事項
  ・ECR ライフサイクルポリシーの整備（不要イメージ削除）— コスト影響最大
  ・Inspector 再スキャン期間の確認・縮小（Last pull date 60日 + push date duration 3日）
  ・ECR レジストリスキャン設定（本番: CONTINUOUS_SCAN、それ以外: SCAN_ON_PUSH）
  ※ Inspector 設定はリージョン単位で全メンバーアカウントに適用されるため注意
  ※ 詳細は Inspector 組織統合設計書で対応

Week 2: 件数の再計測 + 即日対応可能な CRITICAL 解消
  ・SSM.7（各リージョンで aws ssm update-service-setting で即日解消）
  ・IAM.6（Organizations 中央集中型 root アクセス管理で root 資格情報を削除）
  ・findings 件数の再計測（母数削減の効果確認）

Week 3: 一括修正 + 抑制ルール設計
  ・ECS.5（IaC テンプレートに readonlyRootFilesystem: true を一括追加。
    書き込みが必要なパスのみ tmpfs / volume を明示）
  ・suppress / disable 対象コントロールの精査
  ・automation rules の設計

Week 4: 通知しきい値の決定
  ・develop/staging で通知量を1〜2週間実測
  ・しきい値を決めてから本番に展開

中長期タスク

優先度	タスク	概要	時期
高	全アカウント展開	Configuration Policy の target を Organization Root ID に変更	Week 4 後
高	コントロール無効化の精査	false positive・自社環境に該当しないコントロールの精査	導入後1ヶ月
高	脆弱性対応フローの確立	CVE はベースイメージ単位で管理。トリアージ基準は「稼働中コンテナに載っているか」を第一基準。CRITICAL/HIGH の対応 SLA 定義	脆弱性の全体像把握後
高	セキュリティスコア改善	FSBP + CIS + AISBP セキュリティスコアの目標設定と改善活動	導入後3ヶ月
高	V2（Essentials）導入判断	Inspector 精査後にコスト再比較。個別課金 vs Essentials の正味効果で判断（Phase F）	Inspector 精査後
中	CMR 整理	本番以外の CMR 削除検討。本番は ResourceCompliance 記録停止	V2 導入時
中	通知メッセージのフォーマット設計	EventBridge Input Transformer で findings を見やすく整形	導入後2ヶ月
中	サプレッションルール	既知の findings の自動アーカイブ設定。期限付きにし四半期ごとに棚卸し	運用しながら
中	ECR ベースイメージ標準化	共通ベースイメージの選定・統一。定期リビルドのパイプライン化。1本の更新で数百件の CVE が同時解消	脆弱性傾向把握後
中	CloudTrail APIコール監視設計	何を監視対象にするか整理し、EventBridge方式で即時検知を構築。CIS CloudWatch Logs系コントロールの代替	Security Hub安定後
中	インシデント調査方法の整備	Detective / Athena 等を活用した調査手順の確立	運用開始後
中	セキュリティ運用管理体制の整備	定期対応（月1-2回）の運用ルール、対応フロー、エスカレーション先の定義	運用開始後
低	AWS Security Agent の検討	AI による自動ペネトレーションテスト、コードセキュリティレビュー、脅威モデリング。現在プレビュー（無料）。参照: https://docs.aws.amazon.com/securityagent/latest/userguide/what-is.html	プレビュー期間中

Security Hub 組織統合設計書 ​

1. 目的・スコープ ​

目的 ​

スコープ ​

スコープ外 ​

前提 ​

2. 現状と課題 ​

現状（2026-07-28時点） ​

課題 ​

3. アーキテクチャ ​

全体構成 ​

組織統合の動作 ​

4. Delegated Admin・Trusted Access ​

設定内容 ​

適用手順 ​

5. セキュリティ標準 ​

FDが遵守すべき規制・ガイドライン ​

選定 ​

コントロールの初期設定 ​

6. 脆弱性管理（Vulnerability Management） ​

7. Organization Config Rules との重複整理 ​

現状のOrganization Config Rules（初期12件） ​

重複整理の方針 ​

8. Service-Linked Configuration Recorder ​

概要 ​

Customer Managed Recorder の方針 ​

AWS::Config::ResourceCompliance の記録停止 ​

9. Cross-Region Aggregation ​

設計 ​

10. 通知設計 ​

通知基盤の統合 ​

通知経路 ​

GuardDuty通知との統合 ​

通知フィルタリング設計 ​

Terraform管理 ​

11. Central Configuration ​

マルチリージョン方針 ​

12. SCP ​

SCP修正 ​

13. コスト ​

アドオン機能の検討 ​

14. Findings の集約 ​

15. Findings の S3 エクスポート ​

16. Terraform管理 ​

リソース配置 ​

17. 適用手順 ​

概要 ​

詳細手順 ​

環境ごとの適用順序 ​

動作確認チェックリスト ​

ロールバック手順 ​

18. カスタムアクション ​

19. 今後のタスク ​

短期タスク ​

中長期タスク ​

参考ドキュメント ​

Security Hub 組織統合設計書

1. 目的・スコープ

目的

スコープ

スコープ外

前提

2. 現状と課題

現状（2026-07-28時点）

課題

3. アーキテクチャ

全体構成

組織統合の動作

4. Delegated Admin・Trusted Access

設定内容

適用手順

5. セキュリティ標準

FDが遵守すべき規制・ガイドライン

選定

コントロールの初期設定

6. 脆弱性管理（Vulnerability Management）

7. Organization Config Rules との重複整理

現状のOrganization Config Rules（初期12件）

重複整理の方針

8. Service-Linked Configuration Recorder

概要

Customer Managed Recorder の方針

AWS::Config::ResourceCompliance の記録停止

9. Cross-Region Aggregation

設計

10. 通知設計

通知基盤の統合

通知経路

GuardDuty通知との統合

通知フィルタリング設計

Terraform管理

11. Central Configuration

マルチリージョン方針

12. SCP

SCP修正

13. コスト

アドオン機能の検討

14. Findings の集約

15. Findings の S3 エクスポート

16. Terraform管理

リソース配置

17. 適用手順

概要

詳細手順

環境ごとの適用順序

動作確認チェックリスト

ロールバック手順

18. カスタムアクション

19. 今後のタスク

短期タスク

中長期タスク

参考ドキュメント