AWS Config 組織統合設計書
1. 目的・スコープ
目的
AWS Configの組織統合を行い、Organization全体のリソース構成管理を一元化する。 これにより以下を実現する。
- ctop系・cc-poc等の未導入アカウントにリソース構成記録を適用
- 全アカウントの構成データをDelegated Admin（fd-security-tooling）に集約
- Security Hub導入の前提基盤を整備 （CSPM 単独運用の場合は customer managed recorder が必須。 V2 有効化時は SLR が自動作成されるため必須ではないが、 S3 配信・Config Aggregator 等の独自目的で引き続き必要）
- 新規アカウント追加時の自動記録開始
スコープ
- Config組織統合の設計・構築
- Delegated Admin登録
- Aggregator（組織集約ビュー）の構築
- 未導入アカウントへのRecorder展開
- グローバルリソース記録の重複排除（コスト最適化）
- Config Rules / Conformance Packの初期設計方針
スコープ外
- Remediation（自動修復）の設計（別途検討）
前提
- OU・アカウント構成はOU・アカウント設計書に従う
- SCP設計はSCP設計書に従う
- Terraform運用はTerraform運用設計書に従う
2. 現状と課題
現状（2026-07-17時点）
Config導入済み（7アカウント — 個別導入、全て手動設定）:
・production (967691968827) — Recorder: fd-config, S3: fd-config-logs-to-s3-production
・staging (301608970378) — Recorder: fd-config, S3: fd-config-logs-to-s3-staging
・infra-dev (853790572692) — Recorder: fd-config, S3: fd-config-logs-to-s3-infra-dev
・fd-sys (913831226605) — Recorder: fd-config, S3: fd-config-logs-to-s3-amazon-connect
・develop (900176301532) — Recorder: fd-config, S3: fd-config-logs-to-s3-develop
・外部連携 (866741171210) — Recorder: fd-external-relation-prd-config, S3: fd-external-relation-prd-config
・踏み台 (770217130318) — Recorder: default, S3: fd-common-aws-config-bucket
共通設定:
・AllSupported: true（全リソースタイプ記録）
・IncludeGlobalResourceTypes: true（IAM等のグローバルリソース含む）
・Recording: true, LastStatus: SUCCESS
・Snapshot: 24時間ごと
・SNS通知: なし（全アカウント）
・Config Rules: ほぼなし（developにカスタムLambdaルール1件のみ）
developの AWS-config-notif-new-resource:
・カスタムLambdaルール（Terraform管理外、手動作成、作成経緯不明）
・全リソースタイプの設定変更をトリガーにLambdaを実行
・新規リソース作成をNON_COMPLIANTとして記録するだけ（通知先なし）
・月27万回呼び出されており、ルール評価コストが発生
・Notion/Slack/Gitに作成経緯の記録なし、担当者不明
→ 開発環境であり実質未活用のため、Recorder再作成時に手動削除する
・Terraform管理: 一部あり（common/{env}/globals/config/）だが設定がバラバラ
マルチリージョン状況:
・production: 東京 + バージニア + オレゴン（大阪なし）
・infra-dev: 東京 + バージニア + オレゴン + 大阪（4リージョン）
・その他: 東京のみの可能性あり（要確認）
Config未導入（7アカウント）:
・security-tooling (860801568046) — 新規アカウント
・log-archive (385800115893) — 新規アカウント
・ctop-staging (323155024650)
・ctop-production (324454774785) — ⚠️ 本番環境
・cc-poc (499591337329)
・hospital-ai-prod (925091289901) — 新規追加アカウント（セキュリティサービス未構築）
・online-internal-production — 本番環境（Config未導入）
その他:
・Aggregator: なし（どのアカウントにも未設定）
・Trusted Access: 未設定
・Delegated Admin: 未設定
・マネジメントアカウント (703480710002): Config未設定課題
| # | 課題 | 影響 |
|---|---|---|
| 1 | ctop-production（本番）を含む6アカウント + マネジメントにConfigがない | リソース構成変更が記録されていない |
| 2 | Aggregatorがない | 全アカウントの構成を横断的に確認できない |
| 3 | Config Rulesがほぼない | コンプライアンスチェックが行われていない |
| 4 | S3配信先がアカウントごとにバラバラ | ログの一元管理ができていない |
| 5 | グローバルリソースが全リージョンで記録されている | IAM等が重複記録されコスト増 |
| 6 | Terraform管理は一部されているが設定がバラバラ | Recorder名・IAMロール・S3配信先が統一されていない |
| 7 | Security Hub導入の前提が整っていない | Config RecorderがSecurity Hubの必須要件 |
3. 組織統合アーキテクチャ
全体構成
組織統合で実現すること
1. Aggregator（集約ビュー）:
・fd-security-toolingに組織Aggregatorを作成
・全アカウント・全リージョンの構成データを一元閲覧
・読み取り専用（リソースへの変更操作はできない）
・追加コストなし
・Advanced Queries（SQL）で横断検索可能
2. 未導入アカウントへのRecorder展開:
・security-tooling, ctop系, cc-pocにRecorderを新規作成
・マネジメントアカウントにもRecorderを作成
・Organization Config Rules / Conformance Packの前提
3. Organization Config Rules:
・Delegated Adminから全アカウントにConfig Rulesをデプロイ
・新規アカウント追加時に自動適用
・Security Hubのセキュリティ標準と連携4. Delegated Admin・Trusted Access
設定内容
| 項目 | 設定値 | 備考 |
|---|---|---|
| Delegated Admin | fd-security-tooling (860801568046) | GuardDuty等と同じアカウント |
| Trusted Access① | config.amazonaws.com | データ集約用 |
| Trusted Access② | config-multiaccountsetup.amazonaws.com | ルール・Conformance Packデプロイ用 |
適用手順
全てマネジメントアカウント (703480710002) で実施する。
実施者: SRE
Step 1: Trusted Access 有効化
aws organizations enable-aws-service-access \
--service-principal=config.amazonaws.com
aws organizations enable-aws-service-access \
--service-principal=config-multiaccountsetup.amazonaws.com
Step 2: Delegated Admin 登録
aws organizations register-delegated-administrator \
--service-principal=config.amazonaws.com \
--account-id 860801568046
aws organizations register-delegated-administrator \
--service-principal=config-multiaccountsetup.amazonaws.com \
--account-id 860801568046
Step 3: 確認
aws organizations list-delegated-administrators \
--service-principal=config.amazonaws.com
aws organizations list-delegated-administrators \
--service-principal=config-multiaccountsetup.amazonaws.com5. Aggregator
設計
fd-security-tooling に組織Aggregatorを作成する。
Aggregator設定:
・名前: fd-organization-config-aggregator
・ソース: AWS Organizations（全アカウント自動集約、個別認可不要）
・リージョン: 全リージョン（AllAwsRegions: true）
・配置リージョン: ap-northeast-1（東京）
Aggregatorでできること:
・全アカウント・全リージョンのリソース構成を一元閲覧
・コンプライアンス状況の組織全体サマリ
・Advanced Queries（SQL）による横断検索
例: 「パブリックサブネットに配置されたEC2一覧」
例: 「暗号化されていないS3バケット一覧」
例: 「特定のSecurity Groupを使用しているリソース一覧」
注意:
・Aggregatorは読み取り専用ビュー
・ルールのデプロイやリソース変更はできない
・追加コストなしTerraform管理
fd-security-tooling（Terraform）:
・aws_config_configuration_aggregator — 組織Aggregator
コードの配置:
fastdoctor-template/common/security-tooling/config.tf6. Recorder展開
既存Recorderの課題と再作成の方針
既存Recorderの問題点:
・Terraform管理されているが、設定がアカウントごとにバラバラ
- Recorder名: fd-config / fd-external-relation-prd-config / default（3種類）
- IAMロール: service-role/aws-config-role（手動作成）
- S3配信先: アカウントごとに個別バケット（命名規則も不統一）
・Config Rulesがほぼ未設定（コンプライアンスチェックが行われていない）
・SNS通知がどのアカウントにもない
・グローバルリソースが全リージョンで重複記録されコスト増
・結果として、Configを導入しているが実質的に活用できていない状態
方針:
・既存Recorderを削除し、全アカウント統一設定で再作成する
・新規アカウント（ctop系、cc-poc、security-tooling、マネジメント）も同じ設定で作成
・Terraform管理に統一し、今後の設定変更・運用を容易にする
既存データへの影響:
・Recorderを削除・再作成しても過去のデータは即座に消えない
- S3に配信済みのログ → 消えない（S3バケットは別リソース、独自のライフサイクルに従う）
- Configタイムライン（履歴） → Configデータストアの保持期間に従い保持される
（デフォルト7年。AWS Config独自のデータストアであり、S3とは別管理）
- Config Rulesの評価結果 → Recorder再作成後にルールが再評価される
・記録の一時停止はRecorder削除→作成の間のみ
※ Terraformのdestroy+createで実行するため秒単位の停止統一Recorder設定
全アカウント共通の設定:
aws_config_configuration_recorder:
name: fd-organization-config
role_arn: AWSServiceRoleForConfig（Service-Linked Role）
※ 手動で作成したIAMロール（aws-config-role等）は不要になる
※ SLRはRecorder作成時に自動作成される
recording_group:
all_supported: false
include_global_resource_types: false
recording_strategy: EXCLUSION_BY_RESOURCE_TYPES
exclusion_by_resource_types:
全リージョン共通:
- AWS::BedrockAgentCore::WorkloadIdentity（除外理由は下記参照）
東京以外のリージョン（重複排除）:
- AWS::IAM::Group
- AWS::IAM::Policy
- AWS::IAM::Role
- AWS::IAM::User
※ この戦略に至った経緯・各設定値の理由は下記「recording_group の設計経緯」を参照
recording_mode:
recording_frequency: CONTINUOUS
recording_mode_overrides:
- recording_frequency: DAILY
resource_types:
- AWS::EC2::NetworkInterface（ECSデプロイで大量発生）
- AWS::EC2::Subnet（リレーションシップ連鎖記録）
- AWS::EC2::VPC（同上）
- AWS::ECS::TaskSet（デプロイごとに変化）
- AWS::RDS::DBClusterSnapshot（スナップショット作成）
- AWS::ElasticLoadBalancingV2::TargetGroup（ターゲット登録・解除）
- AWS::CodeDeploy::Application（デプロイ操作）
- AWS::CodeDeploy::DeploymentGroup（同上）
- AWS::SSM::ManagedInstanceInventory（インベントリ更新）
- AWS::SSM::AssociationCompliance（同上）
aws_config_delivery_channel:
s3_bucket_name: fd-config-organization（Log Archiveアカウント）
snapshot_delivery_properties:
delivery_frequency: TwentyFour_Hours
記録対象から除外するリソースタイプ:
AWS::BedrockAgentCore::WorkloadIdentity
除外理由:
Bedrock AgentCore がAIエージェントの認証・認可のために内部で管理するリソース。
Bedrock が短命なワークロードを大量に作成・削除するエフェメラルな特性を持つ。
productionアカウントでの実態（2026-08時点）:
・Bedrock API での実際の現存リソース数: 約 2,140 個
・Config が記録している累計リソース数: 263,471 個（現存の約123倍）
・Recorder 再作成時に初回ベースラインで全リソースの CI が一括記録され、
7/30-31 に $3,742 のコスト高騰が発生
CONTINUOUS でも DAILY でもコストが高い:
・CONTINUOUS（6月）: 月 $397（変更頻度が高いため CI が大量発生）
・DAILY（7月〜）: 初回 $3,742 + 定常的にも高コスト
→ 記録対象からの除外が最もコスト効果的
除外しても問題ない理由:
・CloudTrail に API 呼び出しログが残るため「誰が何をしたか」は追跡可能
・ユーザーが直接操作するリソースではなく、Bedrock の内部管理リソース
・現時点で WorkloadIdentity を対象とする Config Rules は AWS から提供されていない
recording_group の設計経緯（2026-08）:
当初の設計:
・ALL_SUPPORTED_RESOURCE_TYPES 戦略 + all_supported=true
・BedrockAgentCore::WorkloadIdentity は DAILY override でコスト削減
・IAM 重複排除は includeGlobalResourceTypes で制御（東京のみ true）
課題1: BedrockAgentCore::WorkloadIdentity のコスト高騰
・Recorder 再作成（7/29）後、7/30-31 に $3,742 のコスト高騰が発生
・原因: WorkloadIdentity はエフェメラルなリソース（実体2,140個に対し Config 記録263,471件）
・DAILY 記録でも「前回と異なる場合のみ記録」の仕様上、変更頻度が高く CI が大量発生
・CONTINUOUS でも月 $397 のコストが発生しており、記録対象からの除外が最もコスト効果的
→ 対処: exclusion_by_resource_types で WorkloadIdentity を除外
課題2: ALL_SUPPORTED_RESOURCE_TYPES と exclusion_by_resource_types の非互換
・all_supported=true + exclusion_by_resource_types の組み合わせは AWS API で拒否される
（InvalidRecordingGroupException: The recording group provided is not valid）
・除外機能を使うには EXCLUSION_BY_RESOURCE_TYPES 戦略への切り替えが必要
→ 対処: recording_strategy を EXCLUSION_BY_RESOURCE_TYPES に変更、all_supported=false に
課題3: EXCLUSION_BY_RESOURCE_TYPES と includeGlobalResourceTypes の非互換
・EXCLUSION_BY_RESOURCE_TYPES 戦略では includeGlobalResourceTypes=true が AWS API で拒否される
・includeGlobalResourceTypes=false にすると IAM は除外リストに入れない限り全リージョンで記録される
（2022年2月以前のグローバルリソースは includeGlobalResourceTypes ではなく除外リストで制御される）
・全リージョンで IAM が重複記録される → コスト増
→ 対処: 東京以外のリージョンでは IAM 4タイプ（User, Group, Role, Policy）を除外リストに追加
東京のみ include_global_resource_types=true をモジュールに渡し、IAM を除外リストに含めない
これにより東京でのみ IAM を記録し、重複排除を実現
最終的な設計:
・EXCLUSION_BY_RESOURCE_TYPES 戦略（all_supported=false, includeGlobalResourceTypes=false）
・全リージョン共通除外: BedrockAgentCore::WorkloadIdentity
・東京以外の追加除外: IAM::Group, IAM::Policy, IAM::Role, IAM::User
・東京のみ IAM を記録（include_global_resource_types=true で除外リストから除く）
・検証結果: infra-dev で IAM の新規リソース作成→CI 記録を確認済み（2026-08-03）
参考ドキュメント:
・Recording frequency: https://docs.aws.amazon.com/config/latest/developerguide/select-resources.html
・Excluding resources: https://docs.aws.amazon.com/config/latest/developerguide/select-resources-excluding.html
・Recording with CLI: https://docs.aws.amazon.com/config/latest/developerguide/select-resources-cli.html
対象アカウント（全15アカウント）:
既存Recorder削除→再作成（7アカウント）:
・production (967691968827)
・staging (301608970378)
・infra-dev (853790572692)
・fd-sys (913831226605)
・develop (900176301532)
・外部連携 (866741171210)
・踏み台 (770217130318)
新規作成（8アカウント）:
・security-tooling (860801568046)
・log-archive (385800115893)
・ctop-staging (323155024650)
・ctop-production (324454774785)
・cc-poc (499591337329)
・hospital-ai-prod (925091289901)
・online-internal-production
・マネジメント (703480710002)既存Recorderの削除手順
既存Terraformコードの場所:
fastdoctor-template/common/{env}/globals/config/
削除手順（各アカウント）:
1. S3バケットをTerraform管理から外す（監査ログ保持のため）
terraform state rm 'module.globals.aws_s3_bucket.congfig-log-bucket'
terraform state rm 'module.globals.aws_s3_bucket_lifecycle_configuration.main'
terraform state rm 'module.globals.aws_s3_bucket_policy.congfig-log-bucket'
→ S3バケットはAWS上に残り、既存のライフサイクル（365日削除）に従い自然削除される
2. terraform destroy -var-file=terraform.tfvars
→ 既存Recorder、Delivery Channel、IAMロールを削除
→ S3バケットはstate rmしているため影響なし
3. 新しい統一Recorder（security-tooling側のTerraform）を apply
→ Log Archiveバケットへの配信で再作成
4. 旧Terraformコード（common/{env}/globals/config/）を削除
実施順序:
・infra-devから開始（検証環境）
・staging → develop → その他 → production（本番は最後）新規アカウント追加時の運用
新規アカウントがOrganizationに追加された場合、以下の対応が必要。
自動的に適用されるもの（対応不要）:
・SCP — OUに紐づいているため自動適用
・CloudTrail 組織トレイル — 自動適用
・GuardDuty — Delegated Adminが自動有効化
・Aggregator — 自動的に集約対象に含まれる
・S3バケットポリシー — aws:SourceOrgIDで自動カバー
・Organization Config Rules — 自動デプロイ（ただしRecorderが前提）
手動で対応が必要なもの:
・Config Recorder + Delivery Channelの作成
→ Recorderがないとorganization Config Rulesが適用されない
→ アカウント追加後7時間以内にRecorderを作成するのが望ましい
（7時間を超えるとOrganization Rulesの自動デプロイリトライが停止する）
（7時間を超えた場合はRecorder作成後にOrganization Config Rulesを
再デプロイ（put-organization-config-rule）すれば適用される）
→ 統一設定（fd-organization-config、Log Archiveバケット、Dailyオーバーライド）で作成
手動対応の手順:
1. 新規アカウントにTerraform環境を作成し、共通モジュールでRecorderを定義
2. terraform apply でRecorder + Delivery Channelを作成
・Recorder名: fd-organization-config
・IAMロール: AWSServiceRoleForConfig
・S3配信先: fd-config-organization（Log Archive）
・IncludeGlobal: 東京のみtrue
・recordingModeOverrides: 既存アカウントと同じDaily対象を設定
3. Aggregatorに反映されたことを確認
4. Organization Config Rulesが適用されたことを確認
Recorderの管理方針:
・各アカウントの既存Terraform + 共通モジュールで管理する
・Organization Config Rulesのデプロイ（② ルール展開）は
Delegated Adminから自動展開されるため個別管理不要
・Recorder有効化（① 基盤構築）のみ各アカウントのTerraformで管理
Terraformで運用する理由:
・設定変更時にコードのdiffでレビューでき、Git履歴で変更理由を追跡できる
・terraform planで影響を事前確認できる
・既存の全アカウント（8アカウント）にTerraform環境がある
・Recording Frequencyの変更等、設定変更があった時にコードで管理できる
StackSetsを初期で利用しない理由:
・マネジメントアカウントでの操作が必要（マネジメントアカウントにリソースを置かない方針）
・アカウント追加は年に数回程度で、自動化の工数に見合わない
・StackSetsとTerraformの二重管理になる（RecorderはStackSets、Config RulesはTerraform）
・StackSetsで作成したRecorderを後からTerraformにimportして管理するのは煩雑
→ アカウント追加頻度が増えたらStackSetsの導入を検討する
Organization統合の機能整理:
① Recorder有効化（各アカウントでConfigを動かす基盤）
→ Organization Rules では自動化できない
→ 各アカウントのTerraformで管理（アカウント追加は年数回程度）
② Config Rulesデプロイ（コンプライアンスチェック）
→ Organization Config Rulesで全アカウントに自動展開 ✅
→ 新規アカウントにも自動適用（Recorderがあれば）✅
→ Delegated Adminから管理可能 ✅
自動化の選択肢（将来検討）:
・CloudFormation StackSets — Recorder有効化を自動化可能
マネジメントアカウントからOU単位で展開、自動デプロイで新規アカウントにも対応
カスタマイズ（Recorder名、Dailyオーバーライド、S3配信先）が全て可能
・Systems Manager Quick Setup — AWSベストプラクティスとして推奨されているが、
Recorder名・Recording Frequency・S3配信先のカスタマイズに非対応（検証済み）
・Control Tower — Phase 5で検討。アカウント作成から全ガバナンスを統制
→ アカウント追加頻度が増えたらStackSetsの導入を検討するマネジメントアカウントの注意事項
Delegated AdminからOrganization Config Rulesをデプロイする場合、
マネジメントアカウントにService-Linked Role（SLR: AWSServiceRoleForConfig）が必要。
SLRはRecorder作成時に自動作成されるIAMロールで、AWS Configの動作に必要な権限を持つ。
SLRがない場合:
・マネジメントアカウントへのルールデプロイが失敗する
・メンバーアカウントへのデプロイは問題なく動作する
※ Delegated AdminからOrganization Config Rulesをデプロイすると、
メンバーアカウントにはSLRが自動作成されるが、
マネジメントアカウントには自動作成されない（AWSの仕様）
今回の対応:
・適用手順Step 7でマネジメントアカウントにRecorderを作成する
・Recorder作成時にSLRが自動作成される
・Step 9のOrganization Config Rulesデプロイより前に実施するため問題なしSCP との関係
SCP修正は不要（確認済み）。
SCP②（リージョン制限: deny_non_approved_regions）:
・config:* は NotAction に含まれていない
・ただしRecorderはSCP許可リージョン（東京・バージニア・オレゴン・大阪）にのみ
作成するため問題なし
SCP①（セキュリティサービス保護: deny_disable_security_services）:
・Config関連は既に保護済み:
- config:StopConfigurationRecorder — Recorder停止を禁止 ✅
- config:DeleteConfigurationRecorder — Recorder削除を禁止 ✅
- config:DeleteDeliveryChannel — 配信チャネル削除を禁止 ✅
・追加のSCP修正は不要7. Recording方針
Recording Frequency
デフォルト: CONTINUOUS（継続記録）
一部リソースタイプ: DAILY（recordingModeOverridesで指定）
現状の問題:
・既存7アカウントが全てCONTINUOUS（デフォルト）で全リソースタイプを都度記録
・しかしConfig RulesもSNS通知もないため、CIを記録してS3に保存するだけで
コストだけ発生し活用できていない状態
・ECSデプロイのたびにENI作成→SG関連付け→Subnet/VPC関連更新が連鎖的に記録され、
セキュリティ上意味のないCIが大量に発生している
コスト実績（過去30日、東京リージョンのみ）:
staging: 262,256 CI $787/月 ← EC2系4タイプが90%（関連リソースの変化による連鎖記録）
production: 195,738 CI $587/月 ← BedrockAgentCore::WorkloadIdentityが68%
infra-dev: 14,794 CI $44/月
develop: 6,319 CI $19/月
fd-sys: 4,591 CI $14/月
合計: 483,698 CI $1,451/月（東京リージョンのみ）
productionの詳細内訳:
BedrockAgentCore::WorkloadIdentity 132,184 CI $397 (67.5%) ← 最大コスト要因
EC2::NetworkInterface 17,291 CI $52 ( 8.8%)
EC2::SecurityGroup 14,443 CI $43 ( 7.4%)
EC2::Subnet 14,410 CI $43 ( 7.4%)
EC2::VPC 12,483 CI $37 ( 6.4%)
その他39タイプ 4,927 CI $15 ( 2.5%)
stagingの詳細内訳:
EC2::NetworkInterface 73,766 CI $221 (28.1%)
EC2::SecurityGroup 64,157 CI $192 (24.5%)
EC2::Subnet 55,491 CI $166 (21.2%)
EC2::VPC 42,558 CI $128 (16.2%)
ALB::TargetGroup 17,082 CI $51 ( 6.5%)
その他 9,202 CI $28 ( 3.5%)
方針:
・セキュリティ上重要なリソースはContinuousを維持
・それ以外はrecordingModeOverridesでDAILYに変更しコスト削減
・この方式はSecurity Hubとも互換性がある
（Dailyでもchange-triggeredコントロールの評価が最大24h遅延するだけで動作する）
（periodicコントロールは影響なし）
Continuous維持（Security Hub change-triggered対象 + セキュリティ上重要）:
・EC2::SecurityGroup — ポート開放・0.0.0.0/0許可の即時検知
・IAM::Role / Policy / User — 権限昇格・不正なポリシー変更
・S3::Bucket — パブリックアクセス設定変更
・RDS::DBInstance / DBCluster — パブリックアクセス・暗号化設定
・Lambda::Function — コード・権限・環境変数の変更
・KMS::Key — 暗号化キーポリシー変更
Dailyにオーバーライド（コスト削減対象）:
※ 具体的なリソースタイプ一覧はセクション6「統一Recorder設定」の
recording_mode_overrides を参照
・主な対象: BedrockAgentCore::WorkloadIdentity、EC2系（NI/Subnet/VPC）、
ECS::TaskSet、RDS::DBClusterSnapshot、ALB::TargetGroup、CodeDeploy系、SSM系
・Subnet/VPCのCI大量発生の原因:
ECSタスク起動・停止でENIが増減するたびにリレーションシップ変化としてCI記録
（実測: Subnetは2分間でENI数91→93の変化でCI 2件発生、
VPCは4分間でENI数217→216の変化でCI記録。設定自体は変更なし）
Subnet/VPCをDailyにしても問題ない理由:
・本番はIAMロール制限で大半のユーザーがNW関連のリソースを更新する権限がない（更新系ロールは特定の人のみ）
・SCPでリージョン制限・データ保護が適用済み
・CloudTrailで全APIコールが記録済み（誰がいつ変更したか追跡可能）
・Security HubのperiodicコントロールはDailyでも影響なし
・CIの大半はECSタスク起動・停止によるENI増減のリレーションシップ連鎖記録であり、
Subnet/VPC自体の設定変更（CIDR、ルートテーブル、NACL等）ではない
（Config履歴で実際に確認済み）
損益分岐点:
・CI単価: Continuous $0.003 vs Daily $0.012（Dailyが4倍高い）
・ただしDailyは1日に何回変更してもCI 1件のみ
・1リソースあたり1日5回以上変更がある場合にDailyが安くなる
・変更頻度が低いリソースはContinuousの方が安いか同等
推定削減効果:
・Daily候補を全て変更した場合: 月 $1,200以上の削減（全5アカウント、東京リージョン）
・他リージョン分を含めるとさらに大きな効果Recording Strategy
Recording Strategyは「どのリソースタイプを記録するか」の設定。
選択肢:
・ALL_SUPPORTED_RESOURCE_TYPES — AWSがサポートする全リソースタイプを記録
・特定リソースタイプのみ — 指定したリソースタイプだけ記録（コスト削減可能）
・全タイプ + 除外オーバーライド — 全タイプから特定タイプを除外
採用: ALL_SUPPORTED_RESOURCE_TYPES（全リソースタイプ記録）
全タイプを採用する理由:
・既存の全アカウントがこの設定で運用中
・Security Hub導入時にどのリソースタイプがチェック対象になるか
事前に予測することが困難
・特定リソースタイプを除外すると、そのリソースのコンプライアンスチェックが
できなくなる
・コスト最適化は記録対象の絞り込みではなく、
頻度（Continuous/Daily）のオーバーライドで対応する方針8. S3配信先の集約（Log Archiveアカウント）
現状
各アカウントに個別のS3バケットが存在:
・production: fd-config-logs-to-s3-production
・staging: fd-config-logs-to-s3-staging
・infra-dev: fd-config-logs-to-s3-infra-dev
・fd-sys: fd-config-logs-to-s3-amazon-connect
・develop: fd-config-logs-to-s3-develop
・外部連携: fd-external-relation-prd-config
・踏み台: fd-common-aws-config-bucket
問題:
・命名規則がバラバラ
・ログが分散しており一元管理できない
・個別バケットのライフサイクル管理が統一されていない方針
CloudTrailと同様に、Log Archiveアカウント (385800115893) に
集約用S3バケットを作成し、全アカウントのConfig配信先を集約する。
集約バケット:
・バケット名: fd-config-organization
・配置: Log Archiveアカウント (385800115893) の ap-northeast-1
・暗号化: KMS（Config専用キーをLog Archiveに作成、bucket_key_enabled = true）
・バージョニング: 有効
・パブリックアクセス: 全ブロック
・force_destroy: false（terraform destroyで誤削除防止）
・ライフサイクル:
- 365日後 → GLACIER
- 2555日（約7年）後 → 削除
※ CloudTrailと同じ保持期間
・アクセスログ: 別バケット（fd-config-organization-access-log）に出力
S3パス構造:
s3://fd-config-organization/AWSLogs/{account-id}/Config/{region}/...
※ AWSデフォルトのパス構造
バケットポリシー:
・config.amazonaws.com に s3:GetBucketAcl, s3:ListBucket を許可
・config.amazonaws.com に s3:PutObject を許可（AWSLogs/配下）
・aws:SourceOrgID条件でOrganization内のアカウントに限定
（SourceAccountで個別指定するとアカウント追加時にポリシー更新が必要になるため、
SourceOrgIDを使えば新規アカウント追加時も自動的にカバーされる）
KMSキーポリシー:
・config.amazonaws.com に kms:GenerateDataKey* を許可
・config.amazonaws.com に kms:DescribeKey を許可
・fd-security-tooling に kms:Decrypt を許可（直接ログ分析が必要な場合）
移行方針:
・新規アカウント（ctop系, cc-poc, security-tooling, マネジメント）は
最初からLog Archiveバケットに配信
・既存アカウントは段階的に移行
1. 既存バケットへの配信を維持したまま新バケットへの配信に切り替え
2. 切り替え後、既存バケットのログは保持期間に従い自然削除
※ Delivery Channelの変更はRecorderの再起動不要Terraform管理
fd-log-archive（Terraform）:
・aws_s3_bucket — fd-config-organization
・aws_s3_bucket_policy — クロスアカウント配信用ポリシー
・aws_s3_bucket_versioning / public_access_block / encryption / lifecycle
・aws_kms_key — Config用暗号化キー
・aws_kms_alias — alias/fd-config-key
コードの配置:
fastdoctor-template/common/log-archive/config.tf9. Config Rules
段階的アプローチ
Phase 1（今回）: 組織統合 + 基本ルールのデプロイ
・Aggregatorで全アカウントの構成データが閲覧可能になることを確認
・Organization Config Rulesで基本的なセキュリティルールをデプロイ
Phase 2: Security Hub導入後の Organization Config Rules 削除 ← 現在ここ
・Security Hub CSPM を導入済み（infra-dev / develop / staging、全アカウント展開進行中）
・CSPM 有効化により service-linked Config Rules（securityhub- プレフィックス）が自動作成
・Phase 1 の初期12本全てが FSBP のコントロールでカバーされることを確認済み
（Security Hub 設計書 Section 7 参照）
・Organization Config Rules を削除し、service-linked rules を唯一の評価ソースとする
・削除手順:
1. service-linked rules が全アカウントに展開されたことを確認
2. config.tf から aws_config_organization_managed_rule（12件）を削除して apply
Phase 3: カスタムルール（必要に応じて）
・Security Hubでカバーされない組織固有のルールを追加
・Organization Conformance Packで全アカウントにデプロイ
・例: 特定のタグが必須、特定のリージョン以外にリソースがないか等
・現時点ではカスタム要件はないため Organization Config Rules は全削除でよい初期デプロイルール（Phase 1）
Organization Config Rulesとして全アカウントにデプロイする。
新規アカウント追加時にも自動適用される。
デプロイ方式:
・Delegated Admin（fd-security-tooling）からOrganization Config Rulesとしてデプロイ
・Terraform管理（fastdoctor-template/common/security-tooling/config.tf）
初期ルール（AWS Managed Rules）:
【IAM】
・iam-root-access-key-check
— ルートユーザーにアクセスキーがないことを確認
・iam-user-mfa-enabled
— IAMユーザーにMFAが設定されていることを確認
・iam-user-unused-credentials-check
— 90日以上未使用のIAMクレデンシャルを検出
【S3】
・s3-bucket-public-read-prohibited
— S3バケットがパブリック読み取りを許可していないことを確認
・s3-bucket-public-write-prohibited
— S3バケットがパブリック書き込みを許可していないことを確認
・s3-bucket-server-side-encryption-enabled
— S3バケットのサーバーサイド暗号化が有効であることを確認
【暗号化】
・rds-storage-encrypted
— RDSインスタンスのストレージが暗号化されていることを確認
・encrypted-volumes
— EBSボリュームが暗号化されていることを確認
【ネットワーク】
・restricted-ssh
— Security Groupで0.0.0.0/0からSSH（ポート22）が許可されていないことを確認
・vpc-default-security-group-closed
— デフォルトSecurity Groupにインバウンド/アウトバウンドルールがないことを確認
【ログ・監査】
・cloud-trail-log-file-validation-enabled
— CloudTrailのログファイル検証が有効であることを確認
・cloudtrail-enabled
— CloudTrailが有効であることを確認
ルール選定の基準:
・AWS Well-Architected Framework セキュリティピラーの推奨事項
・CIS AWS Foundations Benchmarkの基本チェック項目
・既存環境で実際にリスクとなりうる項目
・false positive（誤検知）が少ないルール
・Security Hub導入後に重複するルールは削除する前提
注意事項:
・Organization Config Rulesは全アカウント・全リージョンにデプロイされる
・Config Recorderがないアカウントには適用されない
・初期デプロイ時に大量のNON_COMPLIANT結果が発生する可能性がある
→ 優先度をつけて段階的に対応する10. 非準拠リソースの運用
検知から対応までのフロー
基本フロー:
1. 検知: Config Rules評価で NON_COMPLIANT を検出
2. GitHub Issueに起票
3. 優先度・対応方針を相談して決定
4. 対応実施
5. COMPLIANT になったことを確認
※ 以下は優先度判定の参考例であり、実際は都度相談して決定する
優先度の参考例:
・HIGH: パブリックアクセス系（S3公開、SSH全開放）、ルートキー存在
・MEDIUM: 暗号化未設定（RDS, EBS）、MFA未設定
・LOW: ログ系（CloudTrail検証無効）、未使用クレデンシャル初期デプロイ時の対応
初期デプロイ時は既存リソースの NON_COMPLIANT が大量に発生する可能性がある。
対応方針:
・まずAggregatorでNON_COMPLIANT件数の全体像を把握する
・検知された非準拠リソースはGitHub Issueに起票し、優先度を決めて対応する
・HIGHの項目（パブリックアクセス、ルートキー）を最優先で対応
・既知の許容事項（例: 意図的にパブリックなS3バケット）はサプレッション設定
自動修復（Remediation）:
・初期段階では自動修復は設定しない
・運用が安定し、非準拠パターンが把握できてから段階的に導入
・例: デフォルトSGにルールが追加されたら自動削除
・例: 暗号化されていないEBSボリュームを自動暗号化
・誤修復のリスクがあるため、本番環境への導入は慎重に判断する
・修復アクションは各アカウントのConfig Rulesから実行される
（Delegated Adminから一括修復はできない）
注意:
・Config Rulesは非準拠リソースの操作を拒否するものではない
（検知のみで、ブロックはしない。ブロックにはSCPやIAMポリシーが必要）通知
Config単体での自動通知は構築しない。
理由:
・Config Rulesの評価イベントは各メンバーアカウントのEventBridgeに発生する
（GuardDutyのようにDelegated Adminに自動集約されない）
・全アカウント分を通知するにはクロスアカウントEventBridge転送が必要で構築工数が大きい
・Security Hub導入後はSecurity Hubが全アカウントのfindings（Config Rules含む）を
Delegated Admin（fd-security-tooling）に自動集約するため、
Security Hubの通知基盤で一元的にカバーできる
・Config組織統合の次のステップとしてSecurity Hubを導入する予定のため、
Config単体の通知は構築せず、Security Hub導入まで手動運用とする
通知の方針:
・Config組織統合後、Security Hub導入と通知基盤構築を優先して進める
・Security Hub導入が時間がかかる場合の回避策として、
Aggregator + Claude Code skillsで週次手動確認の運用を行う
- AggregatorのダッシュボードとAdvanced Queriesで非準拠リソースを確認
- Claude Code skillsで確認・レポートを自動化
- HIGHの項目が検知された場合はGitHub Issueに起票して対応
Security Hub導入後の通知（自動）:
・Security Hubに全アカウントのfindings（GuardDuty + Config + Inspector）が
Delegated Admin（fd-security-tooling）に自動集約される
・EventBridge（source: aws.securityhub）→ SNS → Slack / Forwarder Lambda → Datadog
・Config単体の通知構築は不要
Datadog転送:
・Security HubのfindingsをForwarder Lambda経由でDatadogに転送
・Datadog公式がSecurity HubについてForwarder Lambda方式を推奨
参照: https://docs.datadoghq.com/integrations/amazon_security_hub/
・Config単体のDatadog転送は構築しない（Security Hub経由でカバー）
参考: Datadog公式のConfig Integration
・Datadog公式のTerraformモジュール（DataDog/config-changes-datadog/aws）は
SNS → Kinesis Firehose → Datadog方式で提供されている
参照: https://docs.datadoghq.com/integrations/amazon_config/
・今回はSecurity Hub経由で転送するため不採用
通知基盤の統合:
・現在のGuardDuty専用の通知基盤（guardduty-notification.tf）を
セキュリティ全般の通知基盤（security-notification.tf）に作り替える
・リソース名もsecurity-notification系に統一
（例: guardduty-slack-notification → security-slack-notification）
・GuardDuty + Security Hub（Config Rules/Inspector含む）を統合管理
・再作成対象:
- EventBridgeルール × 4リージョン — 名前変更 + Security Hub用ルール追加
- SNSトピック + ポリシー × 4リージョン — 名前変更
- SQS DLQ + ポリシー × 4リージョン — 名前変更
- chatbot（IAMロール + ポリシー + CloudFormation Stack）— project名変更
- Lambda permission × 4リージョン — source_arn変更
・再作成不要:
- Forwarder Lambda（名前はdatadog-forwarderのまま）
- Secrets Manager（Datadog APIキー）11. Security Hubとの関係
Security HubはConfig Recorderに依存する:
・CSPM 単独運用の場合: customer managed recorder（CMR）が必須
・CSPM + V2 の場合: SLR が自動作成されるため CMR は Security Hub のためには不要
・ただし CMR は S3 配信・Config Aggregator 等の独自目的で引き続き必要な場合がある
現在の状況（2026-08 確認済み）:
・Security Hub CSPM を infra-dev / develop / staging に導入済み
・全アカウント展開を進行中
・V2 は infra-dev で検証済み、全アカウント導入は CSPM 展開後に実施予定
Service-Linked Recorder（SLR）の確認結果:
・AWS サポート（ケース #16485）および infra-dev での V2 有効化検証で確認済み
・SLR は全て INTERNAL（課金なし・CI 配信なし）
- AWSConfigurationRecorderForSecurityHubAssets（約230種類のリージョナルリソース）
- AWSConfigurationRecorderForSecurityHubAssetsGlobal（11種類のグローバルリソース）
- AWSConfigurationRecorderForSecurityHubCSPM（CSPM 評価用）
・INTERNAL のため Dailyオーバーライドへの影響なし
（recording frequency precedence は PAID の SLR にのみ適用される仕様）
・CMR の除外設定（BedrockAgentCore::WorkloadIdentity）も影響を受けない
Customer Managed Recorder（CMR）の方針:
・production / amazon-connect: CMR を残す
- インシデント時の設定状態の遡及確認に備える
- 監査で過去の設定状態の提示を求められた場合に対応できる
- コスト: Config 実績 production 約 $54/月、fd-sys 約 $56/月
・本番以外（develop / staging / infra-dev 等）: V2 導入時に CMR 削除を検討
- Security Hub の評価は SLR でカバー
- staging $150/月、develop も同程度のコスト削減が見込める
- 開発環境は壊れても作り直せるため不可逆リスクは許容可能
※ CMR 削除は不可逆（削除後の期間の CI は遡って取得できない）
※ 将来的にコスト削減を要求された場合の削除オプションとして記録
詳細は Security Hub 組織統合設計書 Section 8 を参照12. コスト
AWS Config の課金:
・Continuous recording: CI 1件 $0.003
・Daily recording: CI 1件 $0.012（単価は4倍だがCI件数が大幅に減る）
※ 1日に10回変更してもCIは1件のみ → 変更頻度が高いリソースほどDaily有利
・Config Rules 評価: $0.001/評価（最初の100,000件/月は無料）
・Conformance Pack 評価: $0.001/評価
・Aggregator: 無料
※ 上記はus-east-1の料金。東京リージョンは若干異なる可能性あり
コスト見積もり（新規5アカウント分）:
・リソース数が少ないアカウント（ctop系, cc-poc, hospital-ai-prod (925091289901)）は月数ドル程度
・リソース変更頻度に依存するため、運用後に実コストを確認する
コスト最適化の方針:
・グローバルリソース記録は1リージョンのみ（Recorder再作成時に対応）
・Dailyオーバーライドは初期段階から適用する（セクション7参照）
既存環境のCI発生量分析に基づき、コスト削減対象のリソースタイプを特定済み
・不要なリソースタイプの除外は当面行わない
（Security Hub導入時にどのリソースタイプが必要か判明するため）
・Config Rules評価は最初の100,000件/月が無料のため、初期ルール程度ではコスト影響は小さい13. 適用手順
Step 1: Trusted Access有効化 + Delegated Admin登録
→ マネジメントアカウントで実施（Section 4参照）
Step 2: Log ArchiveにConfig用S3バケット + KMSキーを作成
→ Terraform apply（fastdoctor-template/common/log-archive/config.tf）
→ 全アカウントの配信先となるバケットを先に用意
Step 3: fd-security-toolingに統一Recorderを作成
→ Terraform apply（config.tf）
→ S3配信先はLog Archiveバケットを指定
→ Aggregatorの前提として必要
Step 4: fd-security-toolingにAggregatorを作成
→ Terraform apply（config.tf）
→ 既存アカウントの構成データが集約されることを確認
Step 5: 既存アカウントのRecorder削除→再作成（infra-devから段階的に）
→ 既存Terraformコード（common/{env}/globals/config/）で terraform destroy
→ 統一設定の新Recorderを作成（Log Archiveバケット、IncludeGlobal東京のみ）
→ 実施順序: infra-dev → staging → develop → 外部連携 → 踏み台 → fd-sys → production
Step 6: 未導入アカウントにRecorderを新規作成
→ ctop-staging, ctop-production, cc-poc, hospital-ai-prod (925091289901)
→ log-archive (385800115893)
→ Terraform環境があるアカウントはTerraformで、ないアカウントはCLIで手動作成
Step 7: マネジメントアカウントにRecorderを作成
→ 手動作成（マネジメントアカウントはTerraform管理外）
→ Service-Linked Roleが自動作成される
Step 8: 動作確認
→ Aggregatorで全アカウントの構成データが表示されることを確認
→ Advanced Queriesで横断検索が機能することを確認
→ 全アカウントのRecorderがSUCCESSステータスであることを確認
→ Log ArchiveバケットにConfigログが配信されていることを確認
Step 9: Organization Config Rulesのデプロイ
→ Terraform apply（fd-security-tooling から Organization Config Rules）
→ 初期ルール（Section 9参照）を全アカウントにデプロイ
→ NON_COMPLIANT結果を確認し、優先度をつけて対応開始
Step 10: developのカスタムLambdaルール削除
→ AWS-config-notif-new-resource（Config Rule + Lambda関数）を手動削除
→ 作成経緯不明、通知先なし、実質未活用のため削除
→ Terraform管理外のため手動対応
Step 11: 旧Terraformコードの削除
→ fastdoctor-template/common/{env}/globals/config/ を削除
→ 旧S3バケットが残っている場合は手動削除（ライフサイクルで自然削除でも可）動作確認チェックリスト
適用手順完了後に以下を確認する:
□ 全アカウント（14アカウント）のRecorderがRecording=true, LastStatus=SUCCESSか
□ AggregatorでRecorderのないアカウントがないか
□ Log Archiveバケット（fd-config-organization）にConfigログが配信されているか
□ Organization Config Rulesが全アカウントにデプロイされているか
□ Advanced Queriesで横断検索が機能するか
□ グローバルリソース（IAM等）が東京リージョンのみで記録されているか
□ Dailyオーバーライド対象のリソースタイプがDAILYで記録されているか
□ 旧Recorder（fd-config等）が残っていないかロールバック手順
問題発生時の対応方針:
Configは設定変更（in-place）で修正可能なため、
基本的にはロールバック（元に戻す）ではなく修正対応を行う。
問題パターンと対応:
1. 新Recorder作成後にOrganization Config Rulesが動かない
→ RecorderのrecordingGroupを確認（allSupported=trueか）
→ Organization Config Rulesを再デプロイ
（put-organization-config-ruleで再適用）
2. Log Archiveへの配信が失敗する
→ S3バケットポリシー（aws:SourceOrgID条件）を確認
→ KMSキーポリシー（config.amazonaws.comの権限）を確認
→ 一時的に各アカウント内のS3バケットに配信先を戻すことも可能
（Delivery ChannelのS3バケット名を変更するだけ）
3. Dailyオーバーライドで問題が発生する
→ recordingModeOverridesを削除してCONTINUOUSに戻す
→ コスト増になるが機能的には問題なし
4. 既存Recorder削除後に新Recorderが作成できない
→ SLR（AWSServiceRoleForConfig）の存在を確認
→ IAM権限を確認
→ 既存Recorderの削除はterraform destroyで実施するため、
destroyが成功していれば新Recorder作成は可能
5. 全体をロールバックする場合
→ 旧Terraformコード（common/{env}/globals/config/）がGit履歴に残っているため、
git revertしてterraform applyで旧Recorderを復元可能
→ ただし旧S3バケットをstate rmしているため、S3バケットの再作成が必要14. Terraform管理
fd-security-tooling（Terraform）:
Config基盤:
・aws_config_configuration_recorder — Recorder（security-tooling自身用）
・aws_config_delivery_channel — 配信チャネル（Log ArchiveバケットへのS3配信）
・aws_config_configuration_aggregator — 組織Aggregator
・aws_config_organization_managed_rule — Organization Config Rules（初期ルール）
・aws_iam_service_linked_role — Config用SLR（必要に応じて）
※ Config単体の通知・Datadog転送は構築しない
※ Security Hub導入時に通知基盤を統合:
- guardduty-notification.tf → security-notification.tfにリネーム
- GuardDuty + Security Hub（Config/Inspector含む）のEventBridgeルールを統合
- Forwarder Lambda・chatbotは既存を再利用する
コードの配置:
fastdoctor-template/common/security-tooling/config.tf
fd-log-archive（Terraform）:
・aws_s3_bucket — fd-config-organization（集約バケット）
・aws_s3_bucket_policy — クロスアカウント配信用ポリシー
・aws_s3_bucket_versioning / public_access_block / encryption / lifecycle
・aws_kms_key + aws_kms_alias — Config用暗号化キー
コードの配置:
fastdoctor-template/common/log-archive/config.tf
既存Terraform環境があるアカウント（9アカウント）:
・各アカウントのTerraformで共通モジュールを呼び出してRecorderを管理
・production, staging, infra-dev, develop, fd-sys, 外部連携, 踏み台, security-tooling, log-archive
Terraform環境がないアカウント（5アカウント）:
・ctop-staging, ctop-production, cc-poc, hospital-ai-prod: 手動作成（CLI）
・マネジメント: 手動作成（Terraform環境を置かない方針のため）
・アカウント追加時にTerraform環境を作成すれば以降はTerraform管理に移行可能15. 今後のタスク
| 優先度 | タスク | 概要 | 時期 |
|---|---|---|---|
| 高 | Organization Config Rules 削除 | Security Hub の service-linked rules で全12本カバー済み。重複削除 | CSPM 全アカウント展開後 |
| 高 | Security Hub V2（Essentials）導入 | Inspector 精査後にコスト比較して判断。CSPM 全アカウント展開後に実施 | Inspector 精査後 |
| 高 | CMR 方針の決定 | 本番は残すか削除するかチームで相談。本番以外は V2 導入時に削除検討 | V2 導入前 |
| 高 | 通知基盤のリネーム | guardduty-notification.tf → security-notification.tf に統合 | Security Hub 通知構築時 |
| 中 | ResourceCompliance 記録停止 | AWS 公式推奨。Phase C（通知基盤）構築後に実施 | Phase C 完了後 |
| 中 | 自動修復（Remediation）の設計 | 運用が安定し非準拠パターンが把握できてから | 運用3ヶ月後 |
| 低 | Recording Frequency見直し | 運用後のCI発生量を再分析し、Dailyオーバーライド対象を調整 | 運用3ヶ月後 |