AWSマルチアカウント基盤Vol2｜Security Lake・委任管理・コスト

1. マルチアカウント運用統制の全体像と本記事の位置づけ

マルチアカウント基盤は、Control Tower Landing Zoneで「構築」して終わりではありません。複数アカウントが本番稼働を始めると、ログの分散・セキュリティサービスのアカウント個別設定・コストの不透明化という運用課題が顕在化します。本記事は、Vol1で構築した基盤の上に「組織横断で運用を統制する層」を実装で設計するシリーズVol2です。

マルチアカウント環境の運用課題は「可視性の欠如」に集約されます。アカウントが10を超えると、どのアカウントで誰がどんなAPIコールをしたかを追跡するための「ログの一元化」、全アカウントのセキュリティサービス設定状態を把握するための「委任管理の集約」、どのチームがいくら使っているかを把握するための「コストの可視化」が、運用の三大課題として浮上します。Vol2はこの三大課題を解決する技術的な実装パターンを解説します。

なお、本記事で扱う「委任管理」は特定のセキュリティサービスをメンバーアカウントに委任する機能（delegated administrator）を指します。AWS Organizations全体の管理責任とは異なる概念であるため、用語の使われ方にご注意ください。

Control Tower Landing Zoneによる組織構造の整備と初期セキュリティ設定（SCP/RCP・AFTでのアカウント自動プロビジョニング・CfCTによるガードレール）が完成した後、次のステージで直面するのが「アカウント横断の継続的な運用統制」です。組織内のアカウント数が増えるにつれ、個別アカウントに分散したCloudTrailログの追跡困難・セキュリティサービスの設定漏れ・コストの所有者不明化という課題が顕在化します。これらを組織レベルで統制する仕組みが、本記事で扱う3層の運用統制基盤です。

本節（§1）では、本記事のゴール・想定読者像・Vol1基盤の接続・既存記事との棲み分けを整理します。すでに集約ログや委任管理の課題感をお持ちの方は§2から直接お読みいただけます。

1-1. 本記事のゴール

本記事では、組織横断の運用統制を実装する以下の3つの能力を身に付けることを目標とします。

① 集約ログ統制 — Organization CloudTrailとSecurity Lakeによる組織横断ログ基盤

各アカウントに分散するログを中央のログアカウントへ集約し、Security LakeでOCSF（Open Cybersecurity Schema Framework）に正規化することで、組織全体のセキュリティ分析を単一基盤で行えるようにします。個別アカウントのCloudTrail証跡を手作業で管理する運用から脱却し、組織証跡による自動カバーと改ざん検知ダイジェストでコンプライアンス要件に応えるログ基盤を設計します。Security LakeのOCSF正規化により、CloudTrail・VPC Flow Logs・Route 53・Security Hub findingsといった多様なデータソースを統一スキーマで分析できる基盤を構築します。

② セキュリティサービスの委任管理展開 — delegated administratorによる組織オンボーディング

GuardDuty・新世代Security Hub・Inspector・Config・IAM Access Analyzerを、管理アカウントから委任した管理者アカウント（delegated administrator）に集約し、新規アカウントを自動オンボーディングする統制を設計します。2025年12月のre:Invent 2025でGAとなった新世代Security Hubは、GuardDuty・Inspector・Security Hub CSPM・Macieのシグナルを相関する統合セキュリティ運用基盤へ進化しており、委任管理展開の設計方針と既存名称との正確な区別を解説します。

③ コスト配分統制 — Cost Categories/統合請求によるアカウント横断のコスト可視化

統合請求（Consolidated Billing）を前提に、Cost CategoriesとCost Allocation Tagsでアカウント横断のコストを分類し、チームやプロジェクト単位のチャージバック／ショーバックを実現します。2025年12月に新機能として追加されたOrganizations経由のAccount Tagsにより、タグ付けできないリソースを含む全課金対象使用量に対しても一貫したコスト配分が可能になりました。本記事はコスト「削減手法」ではなく「配分・可視化の統制設計」に集中し、既存のコスト最適化シリーズと棲み分けます。

3層統制の相互補完

上記3つの能力は、それぞれ独立して実装できますが、組み合わせることで相乗効果が生まれます。集約ログ（§2〜§3）はセキュリティサービスの委任管理（§4〜§5）にログソースを供給し、セキュリティサービスが検出した脅威・コンプライアンス違反の情報はコスト配分（§6）と組み合わせることで「どのチームの環境が高リスクか」という統合的なリスクコスト評価が可能になります。3層を段階的に実装する場合は、「集約ログ（基盤）→委任管理（セキュリティ）→コスト配分（可視化）」の順が推奨です。

1-2. 読者像とユースケース

本記事は以下の課題を持つエンジニアおよびアーキテクトを主な読者として想定しています。

プラットフォームエンジニア・クラウドアーキテクト

Organizations/Control Towerを用いたマルチアカウント基盤を設計・構築しており、「基盤の次に組織横断の運用統制をどう実装するか」を設計したい方です。Vol1で扱ったSCP/RCPやAFTによる自動プロビジョニングの知識を前提に、本番稼働後の継続的な統制設計の全体像を把握することを目指します。どのアカウントに何の委任管理者を配置すべきかという「責務分界の設計」は§7の実戦統合パターンで詳しく解説します。

SRE・インフラエンジニア

本番環境のマルチアカウントを運用しており、アカウント横断のログ集約やセキュリティサービスの設定を効率化したいエンジニアです。新規アカウントを追加するたびにCloudTrailやGuardDutyを手動で有効化する運用から脱却し、組織証跡・委任管理のauto-enable機能を活用した自動化設計を習得することを目指します。§2〜§4の集約ログと委任管理の実装パターンが参照すべき中心となります。

セキュリティエンジニア・CISO補佐

組織全体のセキュリティ態勢をアカウント横断で可視化・統制したい担当者です。GuardDuty・Security Hub・Inspectorの委任管理展開と、IAM Access Analyzerによる最小権限改善の継続サイクルを組み合わせた組織規模のセキュリティ統制を設計します。§4〜§5のセキュリティサービス統制が中心的な参照先です。新世代Security Hub（2025年12月GA）の新旧名称の区別は§4で詳しく整理しているので、既存ドキュメントと混同しないよう事前に確認することをお勧めします。

財務・FinOpsエンジニア

マルチアカウントのコストをチームやプロジェクト単位で可視化し、チャージバックの仕組みを整備したい担当者です。統合請求・Cost Categories・Account Tagsを組み合わせたコスト配分設計の実装パターンを§6で詳しく解説します。

前提とする知識

本記事はVol1の基礎知識を前提としていますが、以下の知識があれば独立して参照できます。

• AWS Organizations・Control Towerの基本概念（OU構造・管理アカウント・メンバーアカウント）
• CloudTrail・AWS Configの個別アカウントでの基本的な利用経験
• IAM・S3バケットポリシーの基本操作
• AWS Billing and Cost Managementコンソールへの基本的なアクセス経験

1-3. Vol1基盤との接続と既存記事との棲み分け

本記事はVol1（Control Tower Landing Zone・AFT・CfCT・SCP/RCP設計）で構築した基盤を前提とし、その「上」に乗る運用統制層へ集中します。

Vol1基盤との接続

Vol1では、Control TowerによるOU構造の設計（セキュリティOU・ワークロードOU）、アカウントファクトリーとAFTによる自動プロビジョニング、SCPとRCPによる予防的ガードレールを扱いました。本Vol2はその基盤が整備された後の「組織横断の継続的な運用統制」を対象とします。セキュリティOU配下のログアカウント・セキュリティツールアカウントを委任管理者として活用し、組織全体のログ・セキュリティ・コストを一元管理するパターンを前提とした設計を解説します。Vol1未読の方は、まずVol1で組織構造とアカウントプロビジョニングの基盤を理解された上で本記事を参照されることをお勧めします。

なお、本記事ではセキュリティOU配下の「ログアカウント」「セキュリティツールアカウント」を前提として登場しますが、これらはAWS公式のランディングゾーン設計で推奨される専用アカウントです。ご自身の環境でアカウント構成が異なる場合は、「ログ集約先アカウント」「セキュリティサービス委任管理者アカウント」と読み替えてください。

Cost Optimizationシリーズとの棲み分け

AWSコスト関連の記事として既存のコスト最適化シリーズ（Reserved Instances活用・Savings Plans・Right-sizing・Spot活用による削減手法）がありますが、本記事との対象領域は明確に異なります。コスト最適化シリーズは「使用量・購入方法によるコスト削減量の最大化」を扱い、本記事（§6）は「マルチアカウント環境でのコスト配分・可視化の統制設計」に集中します。チャージバック・ショーバックの仕組みを設計したい場合は本記事§6を、月額コストの削減量を最大化したい場合はコスト最適化シリーズを参照してください。統制設計と削減施策を組み合わせることでFinOpsの成熟度を高められます。

GuardDuty・Security Hub既存記事との棲み分け

GuardDutyやSecurity Hubの検知運用・Findings分析・Terraform実装を扱う既存記事との棲み分けは、「統制設計の層」の違いにあります。既存記事は個別アカウントでの検知設定・Findings対応・TerraformリソースのIaC化を扱い、本記事（§4）は「組織横断で委任管理者に集約し、新規アカウントを自動オンボーディングする設計」という一段上の統制設計を扱います。2025年12月にGAとなった新世代Security Hubと従来のSecurity Hub（Security Hub CSPM）の名称の区別は、既存記事と本記事を参照する際に混乱しやすいポイントです。この点は§4で詳しく整理します。両シリーズを組み合わせることで、個別アカウントの検知運用から組織規模の統制展開まで一貫した体系が完成します。

M&Gシリーズ・IAM設計記事との棲み分け

AWS Organizations・Control TowerのサービスレベルでのAWS Managed Organizationsの概要はマネジメント＆ガバナンス概要記事に、IAMの権限設計はIAM設計記事に委ねます。IAMの権限棚卸しについては、本記事§5で「組織レベルのIAM Access Analyzer委任管理による組織横断の未使用アクセス検出」を扱い、既存IAM記事とは「組織スコープの委任管理」という差別化軸で棲み分けます。

Data Lake・DataZone記事との棲み分け

Security LakeはAmazon S3・Lake Formation・Glueを活用するデータレイク基盤に見えますが、その目的は「セキュリティデータの集約・OCSF正規化・分析」に特化しており、ビジネスデータのデータガバナンスを扱うDataZoneや汎用データレイク設計記事とは対象が根本的に異なります。「Security Lake = セキュリティ専用SIEM基盤」「DataZone = ビジネスデータカタログ・ガバナンス」という役割の違いを念頭に置いてください。本記事§3のSecurity Lake解説は、OCSFによるセキュリティログの正規化と委任管理展開の設計に絞ります。

1-4. 記事の読み方

§2〜§3で集約ログ基盤を、§4〜§5でセキュリティ統制を、§6でコスト統制を扱い、§7で3層を統合した実戦パターン、§8でつまずきとアンチパターンを整理します。各章は独立した一工程として読める構成です。

特定の課題を持つ読者には以下の読み方をお勧めします。

• 集約ログ基盤の構築を優先したい場合 → §2（組織証跡・Config）と§3（Security Lake）を重点的に
• セキュリティサービスの委任管理設計を優先したい場合 → §4（各サービス委任管理）と§5（Access Analyzer）
• コスト配分の統制設計を優先したい場合 → §6（Cost Categories・統合請求・Billing Conductor）
• 3層統制の全体を設計したい場合 → §1→§2→§4→§6→§7の順に通読後、詳細節を参照
• 実装ミスやアンチパターンを先に確認したい場合 → §8を最初に読み、注意点を把握してから各節を参照

各節の冒頭に要点のep-boxを配置しているため、斜め読みをする場合はep-boxのみを通読することで本文の概要を把握できます。詳細な実装パターンや注意点が必要な場合に本文を参照する、という二段階の読み方も効果的です。

§8のつまずきポイント・アンチパターンは、各節の実装段階で遭遇しやすい問題を体系的に整理しています。特にSecurity Hubの新旧名称の混同・委任管理者解除時のサービス無効化・Cost Allocation Tagsの有効化忘れは、実装後に発覚しやすいため事前の確認を推奨します。

2. 集約ログ統制基盤 — Organization CloudTrailとConfig集約

組織横断の運用統制は「ログの一元化」から始まります。本節では、Organization CloudTrail（組織証跡）による全アカウントのAPI監査ログ集約と、AWS Configの組織アグリゲータ・Conformance Packによるコンプライアンス状態の集約を設計します。個別アカウントのCloudTrail証跡を管理するアプローチから組織証跡へ移行することで、新規アカウントへの自動カバー・改ざん検知・一元管理の3つの運用上のメリットを得られます。

本節（§2）の設計が完成すると、組織内のすべてのアカウントで発生したAPIコール・構成変更を単一のS3バケットへ集約して管理でき、セキュリティインシデント発生時の調査・フォレンジック・コンプライアンス監査の基盤が整います。§3（Security Lake）と組み合わせることで、CloudTrailログをOCSF形式へ正規化し、高度なセキュリティ分析へ活用できるようになります。

本節の設計が完成した後、§4のセキュリティサービス委任管理の設計と組み合わせることで、「ログの可視性」と「セキュリティ態勢の可視性」を一体で管理できる統制基盤が完成します。まず§2で集約ログ基盤を整備してから§4のセキュリティサービス委任管理へ進むことで、Security Hubのマルチアカウント統合に必要なログ基盤を事前に確立できます。

2-1. 組織証跡（Organization Trail）の設計

組織証跡は、AWS Organizationsと連携したCloudTrailの機能で、組織全体のすべてのアカウントとリージョンをカバーする単一の証跡を作成できます。管理アカウントまたは委任管理者アカウントで作成し、管理アカウントと全メンバーアカウントのCloudTrailイベントを単一のS3バケットへ集約します。

組織証跡とアカウント証跡の違い

アカウント証跡（個別アカウントで作成する通常の証跡）は、作成したアカウント内のイベントのみを記録します。一方、組織証跡は管理アカウントが持つ組織へのアクセス権限を活用し、すべてのメンバーアカウントへ証跡を自動的に展開します。メンバーアカウントのユーザーは組織証跡を変更・削除できず、組織横断の改ざん耐性を持ちます。この「メンバーアカウントからは読み取りのみ可能で変更不可」という特性が、組織証跡をコンプライアンス要件への対応に適した選択肢としています。

組織証跡を作成した後も、各メンバーアカウントで個別の証跡を併存させることは技術的に可能です。ただし、複数の証跡が同一バケットへ書き込む場合、プレフィックスの設計とS3バケットポリシーの整合性確認が必要です。一般的なベストプラクティスは、組織証跡1本に集約し個別アカウント証跡は廃止する方向での設計です。既存の個別証跡を持つ組織では、組織証跡への完全移行完了後に個別証跡を順次削除するフェーズドマイグレーションを計画してください。

証跡で記録するイベントタイプ

CloudTrailが記録するイベントは、管理イベント・データイベント・Insightsイベントの3種類に分類されます。管理イベントはAWSリソースの作成・変更・削除といったコントロールプレーンの操作を記録し、デフォルトで有効になっています。データイベントは、S3バケットへのオブジェクトレベルのアクセスやLambda関数の実行といったデータプレーン操作を記録し、追加費用が発生します。Insightsイベントは、通常とは異なるAPI呼び出しのパターン（異常なバースト・エラー率の急上昇）を自動検知します。組織証跡の設計では、コンプライアンス要件に基づいて管理イベントに加えてどのデータイベントを有効化するかを事前に設計してください。

サービスリンクロール（SLR）と新規アカウントの自動カバー

組織証跡を作成すると、メンバーアカウントにはCloudTrail専用のサービスリンクロール（AWSServiceRoleForCloudTrail）が自動的に付与されます。これにより、既存のメンバーアカウントだけでなく、組織に追加された新規アカウントに対しても自動的にログ記録が開始されます。新規アカウントプロビジョニングのたびにCloudTrailを手動で有効化する手間が不要になる点は、AFTやアカウントファクトリーと組み合わせた自動プロビジョニング環境で特に大きなメリットとなります。

ログファイル検証（log file validation）

ログファイル検証を有効化すると、CloudTrailは1時間ごとにダイジェストファイルを生成し、その時間内に配信されたログファイルのハッシュ値を記録します。ダイジェストファイル自体もデジタル署名され、ログファイルが改ざん・削除・変更されていないかを検証できます。金融・医療・官公庁などのコンプライアンス要件が厳しい環境では、ログファイル検証の有効化を証跡設計の必須項目として設定することを強く推奨します。

組織証跡の作成（AWS CLIリファレンス）

aws cloudtrail create-trail \
  --name org-trail \
  --s3-bucket-name <ログ集約バケット名> \
  --is-organization-trail \
  --enable-log-file-validation \
  --include-global-service-events \
  --is-multi-region-trail \
  --region ap-northeast-1

--is-organization-trail を指定することで組織証跡として作成されます。--enable-log-file-validation でダイジェストファイルを有効化し、--is-multi-region-trail で全リージョンのイベントを記録します。作成後は start-logging コマンドでロギングを開始してください。

CloudWatch Logs連携による準リアルタイムアラート

CloudTrailをAmazon CloudWatch Logsと連携させると、ログイベントを準リアルタイムで分析できます。ルートアカウントのサインイン・MFAなしのAPIコール・セキュリティグループ変更といった重要イベントに対してCloudWatch Alarmを設定し、SNS経由でアラートを通知する構成が標準的なベストプラクティスです。

組織証跡とグローバルサービスイベントの注意点

--include-global-service-events オプションを有効化すると、IAM・STS・Route 53・CloudFrontなどのグローバルサービスのイベントを記録できます。ただし、組織証跡でグローバルサービスイベントを有効化する場合、すべてのリージョンで同じグローバルイベントが重複して記録されることに注意が必要です。コスト最適化のためには、グローバルサービスイベントの記録を特定のリージョン（例: us-east-1）のみに限定する設定を検討してください。マルチリージョン証跡とグローバルサービスイベントの組み合わせはコストに直結するため、設計段階でCloudTrailの料金シミュレーションを実施することを推奨します。

2-2. 中央ログアカウントとS3集中バケット

ログ集約先は、セキュリティOU配下の専用ログアカウントに配置することがAWSのベストプラクティスです。ログアカウントを本番ワークロードとは独立したアカウントに分離することで、本番側でのIAM誤設定やアプリケーションバグがログの改ざん・削除に連鎖するリスクを排除します。

ログアカウントの設計原則

ログアカウントへのアクセスは最小限の人員（セキュリティ担当・監査担当）に限定し、MFAを前提とした認証制御を設けます。ログアカウントのS3バケットへの書き込み権限はSCPで厳密に制限し、万一ログアカウントが侵害された場合でもバケット内の既存ログを保護できる構成にします。このアカウント分離により、セキュリティインシデント時に「ログアカウントが影響を受けていない」という確信を持ってフォレンジック調査を開始できます。

S3バケットポリシーの設計

組織証跡のログ集約先となるS3バケットには、組織内の全アカウントからの書き込みを許可するバケットポリシーが必要です。aws:SourceOrgID 条件を使用し、組織外アカウントからの書き込みを拒否する最小権限の設計が推奨です。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Sid": "AWSCloudTrailAclCheck",
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::org-central-logs"
 },
 {
"Sid": "AWSCloudTrailWrite",
"Effect": "Allow",
"Principal": { "Service": "cloudtrail.amazonaws.com" },
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::org-central-logs/AWSLogs/*",
"Condition": {
  "StringEquals": {
 "s3:x-amz-acl": "bucket-owner-full-control",
 "aws:SourceOrgID": "o-xxxxxxxxxxxx"
  }
}
 },
 {
"Sid": "DenyNonOrgWrites",
"Effect": "Deny",
"Principal": "*",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::org-central-logs/AWSLogs/*",
"Condition": {
  "StringNotEquals": {
 "aws:SourceOrgID": "o-xxxxxxxxxxxx"
  }
}
 }
  ]
}

aws:SourceOrgID 条件により、組織IDを持つプリンシパルからのみ書き込みを受け付けます。o-xxxxxxxxxxxx は自組織のOrganizations IDに置き換えてください。

バケット設計のベストプラクティス

中央ログバケットには以下の設定を合わせて適用します。

• サーバーサイド暗号化: AWS KMSによる暗号化（SSE-KMS）を有効化し、暗号化キーへのアクセス制御でログへのアクセスを二重に制御します。
• バージョニング有効化: ログファイルの誤削除・上書きからの復旧手段として必須です。
• アクセスログの有効化: ログバケット自体へのアクセスを別のS3バケットに記録します。
• パブリックアクセスのブロック: バケットのパブリックアクセスブロック設定をすべて有効化します。

S3 Object LockによるWORM保護

コンプライアンス要件が厳格な環境では、S3 Object LockのComplianceモードを設定することで、規定の保持期間中はルートユーザーを含む誰もオブジェクトを削除・上書きできないWORM（Write Once Read Many）保護を実現できます。Object Lockはバケット作成時にのみ有効化できるため、ログバケットの設計段階で要否を決定してください。

クロスアカウントアクセスの設計

ログアカウントのS3バケットに集約されたCloudTrailログを、他のアカウント（セキュリティツールアカウント・監査アカウント）から参照する場合、S3バケットポリシーにクロスアカウントのGetObjectおよびListBucket権限を追加します。Security Lakeを使う場合（§3）は、Security Lakeの委任管理者アカウントがSecurity Lake専用のGlueデータカタログとS3パスを通じてデータを参照するため、クロスアカウントS3アクセスの手動設定は不要です。ログアカウントの直接アクセスが必要な監査担当には、AssumeRoleによる一時認証情報を発行する読み取り専用ロールを設計してください。

ライフサイクルポリシーとコスト最適化

アクセス頻度に応じてS3 Standard → S3 Standard-IA → S3 Glacierへ段階的に移行するライフサイクルポリシーを設定し、コンプライアンス要件を満たしつつコストを抑制します。直近90日間はS3 Standard、90日〜1年はS3 Standard-IA、1年以降はS3 Glacier Instant Retrievalへの移行が費用対効果の高い設計の一例です。

ライフサイクルポリシーを設定する際は、CloudTrailのログファイル本体のプレフィックスとダイジェストファイルのプレフィックスを別々に管理することを検討してください。ダイジェストファイルは改ざん検知のために長期保持が必要な一方、ログファイル本体は業務要件やコンプライアンス要件に応じた保持期間の設定が可能です。例えば、ダイジェストファイルは7年間S3 Standard-IAで保持し、ログファイルは1年後にGlacierへ移行するという設計が運用上の利便性とコスト最適化のバランスを保ちます。

VPCエンドポイントとネットワーク経路の最適化

組織内のワークロードからCloudTrailログが書き込まれるS3バケットへの通信は、デフォルトではインターネット経由になります。セキュリティ要件が高い環境では、ログアカウントのS3バケットへのゲートウェイ型VPCエンドポイント（com.amazonaws.ap-northeast-1.s3）を構成し、CloudTrailからの書き込みをAWS内部ネットワークのみで完結させる設計を検討してください。VPCエンドポイントのバケットポリシーに aws:sourceVpce 条件を追加することで、エンドポイント経由以外のアクセスを拒否できます。ただし、組織証跡は管理アカウントからメンバーアカウントへの分散書き込みのため、全アカウントへのVPCエンドポイント展開コストとセキュリティ要件を比較した上で判断してください。

2-3. Config組織アグリゲータとConformance Pack

AWS Configの組織アグリゲータを使うと、管理アカウントまたは委任管理者が全アカウント・全リージョンの構成情報を一元的に集約し、コンプライアンス状態を組織横断で可視化できます。組織Conformance Packと組み合わせることで、共通のコンプライアンスルールを組織全体に一括デプロイ・更新・削除できます。

組織アグリゲータの設定手順

組織アグリゲータは以下の手順で設定します。まず管理アカウントで config-multiaccountsetup.amazonaws.com サービスプリンシパルを使った組織アクセスを有効化し、委任管理者アカウントを指定します（最大3アカウントまで登録可能）。委任管理者に指定されたアカウントは、管理アカウントの認証情報なしに組織全体のConfigデータを集約・操作できます。委任管理者アカウントのAWS Configコンソールから組織アグリゲータを作成すると、組織内の全アカウント・全リージョンが集約対象となります。

組織アグリゲータを作成するには、各メンバーアカウントがAWS Configで有効化されている必要があります。Vol1のAFT/CfCTでConfig有効化を適用済みの場合は追加設定なしで集約対象になりますが、一部のアカウントでConfigが未有効化の場合は、集約結果のコンプライアンスサマリにそのアカウントが反映されません。定期的に「未Configアカウント」の一覧を確認し、SCPでConfig無効化を禁止する予防的ガードレールと組み合わせることで、組織アグリゲータのカバレッジを100%に近づけられます。

組織Conformance Packのデプロイ

組織Conformance Packは、AWS Configルールの集合をテンプレートとしてパッケージ化し、組織全体のすべてのメンバーアカウントに一括デプロイできます。管理アカウントまたは委任管理者アカウントからデプロイでき、デプロイ・更新・削除の操作が組織内の全アカウントに伝播します。展開結果は組織アグリゲータのコンソールで集約確認でき、準拠していないアカウントをドリルダウンして確認できます。

代表的なConformance Packテンプレート

AWSが提供するサンプルテンプレートの中で、マルチアカウント環境に適用しやすいものを以下に示します。

• AWS-FoundationalSecurityBestPractices: CloudTrail有効化・MFAの強制・VPCフローログ有効化などをチェックするルールセット
• CIS AWS Foundations Benchmark: CISベンチマークに基づいたセキュリティ設定のコンプライアンスチェック
• NIST SP 800-53 Rev 5: 米国NIST標準への対応が必要な組織向けのルールセット
• PCI DSS: クレジットカード業界のセキュリティ基準PCI DSSへの対応確認

Config評価結果の活用と改善サイクル

組織アグリゲータに集約されたConfig評価結果は、AWS Security Hubと連携させることでセキュリティ態勢のダッシュボードに統合できます。Security Hubのセキュリティ基準チェック（AWS Foundational Security Best Practicesなど）とConfig Conformance Packを組み合わせると、「Config評価＝インフラ構成のコンプライアンス確認」「Security Hub＝セキュリティ態勢の統合可視化」という役割分担で重複なく運用できます。Config評価の結果は自動修復（AWS Config AutoRemediations）と組み合わせることで、非準拠リソースへの自動対処パイプラインを構築できます。自動修復はSSM Automation経由で実装しますが、誤検知や想定外の変更リスクを考慮し、初期段階では通知のみとし段階的に自動修復を拡大するアプローチを推奨します。

委任管理者サービスプリンシパルの正確な記述

委任管理者でConfig組織横断デプロイを行う場合、サービスプリンシパルとして config-multiaccountsetup.amazonaws.com を正確に指定する必要があります。名称を誤ると組織Conformance Packの展開に失敗するため、コンソールやIaCでの設定時に正確な文字列を確認してください。

組織Conformance PackのIaC管理（Terraformリファレンス）

組織Conformance PackのデプロイをTerraformで管理する場合、aws_config_organization_conformance_pack リソースを使用します。テンプレートはS3バケットのURLまたはインラインのYAMLテンプレートとして指定できます。Conformance Packの展開先となるすべてのメンバーアカウントにデリバリーチャンネル（S3バケット）が設定されている必要があります。組織Conformance Packは即時反映ではなく、組織内の各アカウントへのデプロイが完了するまでに数分〜数十分を要するため、テスト環境での動作確認後に本番展開することを推奨します。

なお、AWS ConfigルールとConformance Packは名称が似ているため混同しやすいですが、役割は異なります。Config組織ルールは個別のルールを組織横断で展開する機能であり、組織Conformance Packは複数のConfigルールをパッケージとして一括展開・管理する上位概念です。既存の組織ルールを整理してConformance Packに移行することで、ルールセットのバージョン管理・デプロイの一元化・コンプライアンス評価の集約管理が容易になります。

CloudTrail Lakeとの連携（オプション）

組織証跡と並行してAWS CloudTrail Lakeを活用すると、CloudTrailイベントを独自のデータレイクへ7年間保持しSQLでクエリできます。通常のCloudTrailはS3にJSONを配信し、AthenaやSecurity Lakeを経由して分析しますが、CloudTrail Lakeはイベントのインジェスト・保持・クエリを単一のマネージドサービスで完結します。ユースケースとしては、長期のフォレンジック調査や組織横断のAPIコールパターン分析が挙げられます。組織証跡とCloudTrail Lakeは排他ではなく共存できるため、短期アラート（CloudWatch Logs連携）・中期分析（S3+Athena）・長期保持（CloudTrail Lake）を組み合わせた多層ログ保持戦略を検討してください。

CloudTrail Lakeの組織横断有効化は、管理アカウントまたは委任管理者から組織イベントデータストアを作成し、--organization-enabled フラグを有効化することで実現します。イベントデータストアは1日あたりのインジェスト費用とストレージ費用が発生するため、保持期間・クエリ頻度・S3との使い分けを事前に設計してください。Security LakeのOCSF正規化との違いは「スキーマ」にあり、CloudTrail LakeはCloudTrail固有のスキーマ（eventName・eventSource等）でSQLクエリ可能な一方、Security Lakeは複数サービスをOCSFで統一スキーマに変換する点が差別化軸です。

組織証跡のコスト設計

組織証跡のコストは、管理イベント（各アカウントの最初の証跡は無料）とデータイベント（有料）に分かれます。組織証跡を有効化すると管理イベントは無料で記録されますが、データイベント（S3オブジェクト操作・Lambda実行）はイベント数に応じた課金が発生します。組織全体での集約ログのコスト試算は、アカウント数×平均API呼び出し数×単価で概算できます。大規模組織では、データイベントのフィルタリング（必要なS3バケット・Lambda関数のみ記録）を検討することでコストを最適化できます。

3. Security Lake — OCSF正規化による組織横断ログ分析基盤

集約したログを「分析可能な統一スキーマ」へ変換するのがAmazon Security Lakeです。§2で構築した組織証跡・Config集約はログの「収集基盤」であり、Security Lakeはそれらを「セキュリティ分析基盤」へ昇格させる役割を担います。

従来のセキュリティログ分析は、各AWSサービスが独自形式でS3に出力するログをAthenaや自前パイプラインでスキーマ変換し、SIEMへ取り込む煩雑な処理が必要でした。Security LakeはこのOCSF変換・パーティショニング・ライフサイクル管理をマネージドで提供し、セキュリティチームが分析ロジックに集中できる環境を整えます。

本節では、Security Lakeの委任管理者設計・SLR推奨の境界・OCSF正規化の仕組み・サブスクライバのアクセス限定設計・OpenSearch Zero-ETL統合・ライフサイクル管理を順に扱います。

3-1. Security Lakeの役割と組織への展開設計

Amazon Security Lakeは、AWSサービスと独自アプリケーション・サードパーティのセキュリティデータを組織全体から収集し、OCSF（Open Cybersecurity Schema Framework）形式へ正規化して中央のS3バケット（セキュリティデータレイク）に格納するマネージドサービスです。データの正規化・パーティショニング・ライフサイクル管理はSecurity Lakeが自動処理するため、パイプラインの構築・保守コストを最小化できます。

組織規模での利用において最も重要な設計判断は「委任管理者をどのアカウントに置くか」です。Security Lakeの委任管理者は、管理アカウントからマネジメントコンソールまたはAWS CLIで指定します。委任管理者アカウントは、組織内の全メンバーアカウントに対してSecurity Lakeを有効化し、データソースを構成し、ライフサイクルポリシーを設定する権限を持ちます。

実運用においては、セキュリティOUの専用セキュリティツールアカウントを委任管理者として指定し、ログアカウントとは分離する構成が一般的です。これにより、ログの収集（§2のS3集中バケット）とセキュリティ分析（Security Lake）の責務を分離しつつ、Security Lakeがログアカウントのデータを参照する設計が実現できます。

委任管理者の指定フロー

委任管理者の指定は管理アカウントで実行します。

# 1. 管理アカウントで委任管理者を指定
aws organizations enable-aws-service-access \
  --service-principal securitylake.amazonaws.com

aws securitylake register-data-lake-delegated-administrator \
  --account-id 123456789012

# 2. 委任管理者アカウントでSecurity Lakeを有効化（東京リージョン例）
aws securitylake create-data-lake \
  --configurations '[{
 "encryptionConfiguration":{"kmsKeyId":"alias/security-lake"},
 "region":"ap-northeast-1",
 "lifecycleConfiguration":{"expiration":{"days":365},"transitions":[{"days":60,"storageClass":"GLACIER"}]}
  }]'

# 3. 組織全体へのデータソース自動設定
aws securitylake create-data-lake-organization-configuration \
  --auto-enable-new-account '[{
 "region":"ap-northeast-1",
 "sources":[
{"sourceName":"CLOUD_TRAIL_MGMT"},
{"sourceName":"VPC_FLOW"},
{"sourceName":"ROUTE53"},
{"sourceName":"SH_FINDINGS"}
 ]
  }]'

3-2. SLR（サービスリンクロール）推奨設定の境界

Security Lakeのリソース管理方式には、2025年4月17日を境に変化があります。

2025年4月17日より前に有効化した環境では、Security LakeはAWS Lake Formationを使用してS3のデータレイクリソースをプロビジョニングしていました。この方式はレイテンシが高く、Lake Formation管理コストが発生するため、AWS公式ではサービスリンクロール（SLR）方式への移行を推奨しています。SLR方式ではAmazonSecurityLakeResourceManagementServiceRolePolicyを持つロールがリソース管理を担い、レイテンシとコストの低減が期待できます。

2025年4月17日以降に有効化した環境では、デフォルトでSLR方式が使用されるため、追加の設定変更は不要です。

既存環境でのSLR移行は、Security LakeのコンソールまたはAPIから実施できますが、移行中はデータのインジェストが一時停止するため、メンテナンスウィンドウでの実施を推奨します。有効化日時の確認は、CloudTrailのCreateDataLakeイベントで行えます。

3-3. OCSF正規化とネイティブデータソース

OCSF（Open Cybersecurity Schema Framework）は、セキュリティデータの相互運用性を高めるために業界団体が策定したオープンスキーマです。Security Lakeはネイティブ対応のAWSサービスのデータを自動的にOCSFへ変換・正規化して格納します。

OCSFネイティブ対応のAWSデータソース

これらのデータソースを有効化すると、Security Lakeは自動的にOCSFスキーマへ変換し、対応するS3バケットのプレフィックスに格納します。Parquetフォーマットで保存されるため、Athenaや他の分析ツールから効率的にクエリできます。

OCSF正規化によって、例えばCloudTrailのeventName・VPC Flow Logsのaction・Security Hubのseverityが統一フィールド名にマッピングされ、複数データソースをまたいだ相関クエリがJOINなしで記述できるようになります。

カスタムデータソースの統合

OCSFへの変換をサポートするサードパーティ製品（Palo Alto Prisma Cloud・CrowdStrike Falcon等）は、Security Lakeのカスタムソース機能を通じてデータを直接書き込めます。自社アプリケーションのログも、OCSF変換処理を実装することでSecurity Lakeに統合できます。カスタムソースはGlueテーブルとして登録され、ネイティブソースと同一のクエリインタフェースで扱えます。

3-4. サブスクライバのアクセス限定設計

Security Lakeに蓄積されたデータは、サブスクライバを通じて分析ツールやSIEMへ配信します。サブスクライバのアクセス権は最小権限で設計することが重要です。

サブスクライバを作成する際には、以下の粒度でアクセスを制限できます。

• ソース限定: CloudTrailのみ・VPC Flow Logsのみなど、特定のデータソースへのアクセスに限定できます。
• リージョン限定: 特定リージョンのデータのみにアクセスを制限できます。
• アカウント限定: 関連メンバーアカウントが所有するデータのみへのアクセス権を付与できます。

この粒度により、例えば「コンプライアンス担当チームはCloudTrailデータのみ参照可能、セキュリティ運用チームは全データソースを参照可能」といった権限分離が実現できます。

サブスクライバのアクセス方式

クエリアクセス（S3直接クエリ）: Amazon AthenaやS3 Selectでデータを直接クエリします。SIEMやデータ分析ツールとの統合に向いています。Athenaでは事前定義されたOCSFスキーマのGlueテーブルを使用してクエリを実行できます。

通知アクセス（SQS/SNS通知）: 新しいデータが到着するたびにSQSキューまたはSNSトピックへ通知を送信します。リアルタイムに近い処理が必要なSIEMやLambdaによるアラート処理に適しています。

3-5. Amazon OpenSearch ServiceとのZero-ETL統合

Security LakeとAmazon OpenSearch Serviceは、データ変換パイプラインを自前で構築することなくデータを連携できるZero-ETL統合をサポートしています。

Zero-ETL統合では、OpenSearch Ingestion（旧Data Prepper）がSecurity LakeのS3バケットを継続的に監視し、新着のOCSFデータをOpenSearchのインデックスへ取り込みます。従来のアーキテクチャではKinesis Data Streams→Lambda変換→OpenSearch Serverlessという複数コンポーネントが必要でしたが、Zero-ETL統合ではSecurity Lakeのサブスクライバ設定とOpenSearch Ingestionのパイプライン設定のみで連携が完結します。

OpenSearch DashboardsのSecurity Analytics機能を使えば、OCSFスキーマを前提とした脅威検知ルール（シグマルール互換）・相関エンジン・インシデントタイムラインを統合した分析基盤を構築できます。

3-6. Security Lakeのライフサイクル管理とコスト設計

Security Lakeのデータは長期保持することでフォレンジック分析に活用できますが、無制限の保持はストレージコストを増大させます。ライフサイクル設定で保持期間とストレージクラスを管理します。

推奨ライフサイクル設定の例

ライフサイクルポリシーはSecurity Lake作成時に設定するか、後からupdate-data-lakeコマンドで変更できます。Security Hubのデフォルトは90日（変更可能）ですが、Security Lakeは独立してポリシーを設定するため、意図した保持期間になっているかを定期的に確認してください。

セキュリティポリシー上、組織としての最低保持期間（例: PCI DSS=1年、SOC 2=1年）を設定し、それを下回らないようにSCPで保護することを推奨します。

4. セキュリティサービスの委任管理展開

セキュリティサービスをアカウントごとに手動設定すると、設定漏れがそのままセキュリティホールになります。本節では、GuardDuty・新世代Security Hub・Inspectorを委任管理者に集約し、組織横断で自動オンボーディングする統制を設計します。Security Hub新旧の名称区別が本節の最重要ポイントです。

4-1. 新世代Security Hubと旧版（Security Hub CSPM）の区別

この節を読む上で最も重要な前提知識として、Security Hubには2025年12月以降「2つの異なるサービス」が存在します。名称を混同すると設計・実装が根本的に誤ります。

新世代Security Hub（2025-12-02 re:Invent 2025 GA）

2025年12月2日のre:Invent 2025で一般提供（GA）となった新世代版です。製品名は単に「Security Hub」と表記され、以下の特徴を持ちます。

• 統合セキュリティ運用基盤: GuardDuty（脅威検知）・Inspector（脆弱性管理）・Security Hub CSPM（ポスチャ管理）・Macie（機密データ検出）のシグナルを相関し、優先度付きリスクビューを提供します。
• ニアリアルタイム分析: 従来の定期バッチではなく、イベントドリブンの処理でFindingsをほぼリアルタイムに更新します。
• トレンドダッシュボード: リスクスコアの時系列推移・修正効果の可視化・攻撃対象領域の俯瞰が可能です。
• 統合料金: 連携サービスの利用量に応じた一元的な料金体系。
• シングルクリック横断有効化: 管理アカウントまたは委任管理者から、全アカウント・全リージョンをシングルクリックで有効化できます。
• Terraform: aws_securityhub_account_v2リソース（2025年12月GA）で管理します。

Security Hub CSPM（旧版・改称）

2025年12月以前から提供されていた従来版です。re:Invent 2025以降は「Security Hub CSPM」として提供されています。

• ポスチャ管理・コンプライアンス監視: CIS AWS Foundations Benchmark・PCI DSS・SOC 2等のセキュリティ基準に対するチェック。
• Findings集約: AWSサービスとサードパーティからのFindingsを集約・一元管理。
• ベストプラクティスチェック（Security Controls）: 自動評価ルールによるリソース設定のコンプライアンス検証。
• Terraform: 従来のaws_securityhub_accountリソースで管理。

新旧の違いを整理した比較表

新世代Security Hubは、Security Hub CSPMを内包しつつGuardDuty・Inspector・Macieとのシグナル相関機能を追加した上位サービスです。既存環境では段階的な移行が可能であり、Security Hub CSPMの機能は継続して利用できます。

委任管理者によるOrganizations展開

新世代Security Hubの組織展開は、管理アカウントから委任管理者を指定した後、委任管理者アカウントで実施します。

# 管理アカウントで委任管理者を指定
aws securityhub designate-aggregation-region \
  --aggregation-region ap-northeast-1

# 委任管理者アカウントで組織設定（新世代版）
aws securityhub update-organization-configuration \
  --auto-enable \
  --organization-configuration '{"ConfigurationType":"CENTRAL"}'

4-2. GuardDutyの委任管理とauto-enable 3モード

GuardDutyは委任管理者アカウントのみが、メンバーアカウントの保護プランと新規アカウントのauto-enable設定を構成できます。委任管理者の指定は管理アカウントで実施します。

auto-enable 3モードの使い分け

実運用では、初期展開時にALLで全アカウントを一括有効化し、安定後にNEWへ切り替えて新規アカウントの自動カバーを維持するパターンが一般的です。

Extended Threat Detectionの展開

Extended Threat Detectionは、GuardDutyの検知機能を複数ステップにわたる攻撃シーケンスの検知へ拡張する機能です。追加費用なしで自動有効化されます。

2025年12月の拡張により、以下のコンピュートリソースを対象とした多段攻撃シーケンス検知がサポートされました。

• EC2: クレデンシャル侵害→横移動→データ流出の多段攻撃検知
• ECS: コンテナ脱出→エスカレーション→クラスター全体への横移動検知
• EKS: KubernetesAPIサーバー不審コール→コンテナ実行→永続化の検知

これらはGuardDutyが単独のAPIコールや通信パターンではなく、時系列にまたがる行動シーケンスをモデル化して検知します。委任管理者が有効化すると、管理下の全メンバーアカウントに自動適用されます。

委任管理者からのauto-enable設定

# GuardDuty委任管理者の指定（管理アカウントで実行）
aws guardduty enable-organization-admin-account \
  --admin-account-id 123456789012

# auto-enableの設定（委任管理者アカウントで実行）
aws guardduty update-organization-configuration \
  --detector-id <detector-id> \
  --auto-enable-organization-members NEW \
  --features '[{"Name":"EXTENDED_THREAT_DETECTION","AutoEnable":"NEW"}]'

4-3. Inspectorの組織横断委任管理展開

Amazon Inspector（脆弱性管理）は、EC2・ECS/ECR・Lambdaの脆弱性を継続的にスキャンし、Findingsを生成します。組織横断の展開では委任管理者アカウントが一元的に管理します。

委任管理者によるInspector展開フロー

1. 管理アカウントで委任管理者を指定: aws inspector2 enable-delegated-admin-accountを実行。
2. 委任管理者アカウントでInspectorを有効化: スキャン対象（EC2/ECR/Lambda）を選択して組織全体へ有効化。
3. メンバーアカウントの自動オンボーディング: 組織設定により新規アカウントを自動的にスキャン対象に追加。
4. Findingsの集約: 委任管理者アカウントのコンソールに全メンバーアカウントのFindingsが集約表示されます。

Inspectorのシグナルは、新世代Security Hubの統合リスクビューに取り込まれ、GuardDuty・Security Hub CSPMのFindingsと相関して優先度付きリスクとして提示されます。

4-4. 複数サービスの委任管理アカウント設計パターン

各セキュリティサービスの委任管理者を同一アカウントに集約することで、シグナル相関の精度が向上し、運用負荷を低減できます。

推奨パターン: セキュリティツールアカウントへの集約

同一アカウントへの集約により、委任管理者の認証情報管理を一元化しつつ、新世代Security Hubが各サービスのシグナルをアカウント内で直接相関できる構成になります。

5. IAM Access Analyzer 組織分析 — 最小権限への継続改善

委任管理で展開したセキュリティサービスに加え、権限そのものを継続的に最小化するのがIAM Access Analyzerの組織分析です。本節では、組織アナライザの設計・未使用アクセス5種類の検出・internal access findings・分析スコープのカスタマイズ・継続的な権限改善サイクルを設計します。

本節は「組織レベルの委任管理による横断分析」に集中します。アカウント単体でのIAMポリシー最小権限設計・ポリシー作成支援・個別ロール設計は既存のIAM権限設計記事を参照してください。委任管理者を起点にした組織全体の権限改善サイクルが、IAM権限棚卸し記事との差別化軸です。

5-1. 組織アナライザの役割と委任管理設定

IAM Access Analyzerは、リソースポリシーの外部公開と未使用アクセスを継続的に分析するサービスです。組織全体を分析スコープとする「組織アナライザ」を作成することで、管理アカウントから全メンバーアカウントの権限状態を一元的に把握できます。

組織アナライザを利用するには、管理アカウントでIAM Access Analyzerの委任管理者をセキュリティツールアカウントに指定します。委任管理者の指定はOrganizations APIまたはマネジメントコンソールから実施し、指定後はセキュリティツールアカウントで組織スコープのアナライザを作成します。

アナライザ作成時のリクエスト例は以下のとおりです。

{
  "analyzerName": "org-access-analyzer",
  "type": "ORGANIZATION_UNUSED_ACCESS",
  "configuration": {
 "unusedAccess": {
"unusedAccessAge": 90
 }
  }
}

typeにORGANIZATION_UNUSED_ACCESSを指定すると、組織全体の未使用アクセスを分析するアナライザが作成されます。unusedAccessAgeは「何日間使用されていなければ未使用とみなすか」のしきい値で、90日が一般的な推奨値ですが、組織のポリシーに応じて30〜180日の範囲で調整します。

委任管理者を解除すると、そのアカウントで作成した組織アナライザはすべて無効化されます。委任管理者アカウントを変更する際は、新しい委任管理者での再作成が必要です。この挙動は§8のつまずき①として詳説しています。

5-2. 未使用アクセス検出の5種類

組織アナライザが検出する未使用アクセスには5種類あります。それぞれの検出対象と対処の方向性を把握しておくことが、Findings対応の効率化につながります。

① 未使用ロール（Unused Role）

過去90日間（設定値）に一度もAWS APIを呼び出していないロールを検出します。最終使用日・ロールのARN・Trustポリシーの委任先情報が記録されます。対処の基本は「確認 → 削除またはアーカイブ」です。CI/CDパイプラインのデプロイロールや一時的なアクセス用ロールが検出対象に入りやすいため、タグによる除外設定を活用します。

② 未使用のアクセスキー（Unused Access Key）

IAMユーザーに紐付く、未使用または長期間ローテーションされていないアクセスキーを検出します。ローテーション推奨期間（90日）を超えたキーは削除・ローテーション対象として処理します。サービスアカウント用のアクセスキーはIAMロールへの移行を優先し、フェデレーションが難しい環境でのみアクセスキーを残す方針が推奨されます。

③ 未使用のパスワード（Unused Password）

マネジメントコンソールにサインインしていないIAMユーザーのパスワードを検出します。コンソールアクセスが不要なサービスアカウントはパスワードを無効化し、人間ユーザーはAWS IAM Identity Centerを経由したサインインに統一することが推奨されます。パスワードポリシー（最大有効期間・最小長・複雑性要件）も組織ポリシーとして定義します。

④ 未使用のサービス（Unused Service）

ロールまたはユーザーがポリシーで許可しているが、一度も呼び出していないAWSサービスを検出します。「S3へのアクセス権限は付与しているが、そのロールはS3を一度も利用していない」といったケースが典型です。不要なサービスアクセス権限をポリシーから除去し、最小権限の実態に近づけます。

⑤ 未使用のアクション（Unused Action）

許可済みのサービス内で、一度も実行していない個別のAPIアクションを検出します。5種類の中で最も粒度が細かく、過剰に許可されたポリシーの改善に直結します。s3:*をまとめて許可しているが実際に使用しているのはs3:GetObjectのみ、といったケースを精確に特定できます。IAM Policy Generatorと組み合わせることで、CloudTrailアクセス記録から最小権限ポリシーの草案を自動生成できます。

5-3. internal access findingsとzone of trust

IAM Access Analyzerのアナライザタイプには、リソースの外部公開を検出する「外部アクセスアナライザ」と、信頼境界内部のアクセスを分析する「internal access analyzer」の2系統があります。

外部アクセスアナライザは、S3バケット・KMSキー・SQSキュー・IAMロールなどのリソースポリシーを分析し、組織外部からアクセス可能なリソースを検出します。zone of trustを「組織」に設定すると、組織外部のプリンシパルからのアクセスをすべて外部公開とみなしてFindingsを生成します。

internal access analyzerはzone of trustを「同一アカウント」または「Organizations OU」として設定し、信頼境界内部のアクセスパスを可視化します。組織内でのクロスアカウントアクセスを全容把握し、意図しないアクセスパスの早期検出に活用します。

組織横断アナライザでのzone of trust設定は「Organizations組織全体」が最も広い範囲です。この設定により、組織メンバーアカウント間のアクセスは「内部アクセス」として扱い、組織の外部への意図しない公開のみをFindingsとして表面化できます。セキュリティレビューでは、まず外部公開Findingsを全件解消し、次いで未使用アクセスの整理を継続的に実施する2段構えの対応フローが有効です。

5-4. 分析スコープのカスタマイズ

Findingsが大量に生成される環境では、重要度の高い領域に集中するためのカスタマイズが不可欠です。IAM Access Analyzerは、アカウント・ロール・ユーザー単位での除外設定をサポートします。

除外アカウントの設定

特定のアカウント（例：セキュリティ検証用のSandboxアカウント）を分析スコープから除外します。OUレベルで除外を設定することで、一時的な検証環境のFindingsを本番統制の対象から分離できます。除外設定はアナライザのArchive ruleとして保存し、除外理由をタグに記録して監査証跡を維持します。

除外ロール・ユーザーの設定

Break-glass用の緊急アクセスロールや管理者ロールなど、意図的に広い権限を持つプリンシパルを除外対象として登録します。たとえばControl Towerが作成するAWSControlTowerExecutionロールなどは、除外ルールを設定しないと大量のFindingsが継続生成されます。除外ルールにコメントを付けて除外理由を記録しておくと、四半期レビューで見直しを判断しやすくなります。

Findingsの優先度付け

委任管理者のダッシュボードでは、アカウント別・Findingsタイプ別・最終アクセス日別にFindingsを絞り込めます。未使用アクセスキーと未使用アクションは対処の緊急度が異なるため、SLO（例：アクセスキーは発見後30日以内に対処・未使用アクションは四半期ごとに整理）を組織ポリシーとして定義することを推奨します。

5-5. 継続的な最小権限改善サイクル

組織アナライザの価値は、一度きりのスキャンではなく「継続的な権限改善サイクル」を実現する点にあります。以下のフローを組織横断で継続することで、権限の肥大化（permission sprawl）を防止します。

1. 組織アナライザが設定した未使用日数（例：90日）の条件でFindingsを継続生成します。
2. 委任管理者のダッシュボードでFindingsをタイプ別・アカウント別に確認します。
3. 対象のロール・ユーザー・アクセスキーを各メンバーアカウントの担当者と連携して処理します（削除・ローテーション・ポリシーの絞り込み）。
4. 処理済みFindingsをアーカイブし、除外ルールを必要に応じて更新します。
5. 未使用アクション（⑤）のFindingsをもとにIAM Policy Generatorで最小権限ポリシーの草案を生成し、既存ポリシーを置き換えます。

このサイクルを四半期ごとに実施することで、「構築時は必要だったが今は不要な権限」が蓄積する状態を解消し続けられます。権限の最小化はGuardDuty・新世代Security Hubの検知精度を高める副次効果も持ちます。侵害されたプリンシパルによるラテラルムーブメントの影響範囲を事前に限定できるからです。

また、Security Hubのダッシュボードと統合することで、セキュリティ運用チームが日常的なFindingsレビューの一環として未使用アクセスの整理を実施できる体制を構築できます。組織アナライザのFindingsをEventBridgeルールでSecurity Hub Findingsに連携するパターンも有効です。

5-6. Archive Rulesと自動化パターン

Findingsの対処フローを継続的に運用するには、Archive Rulesによる「既知の正常状態の自動除外」が効率化の鍵です。Archive Rulesは、条件式を満たすFindingsを生成時点で自動アーカイブし、ダッシュボードへの表示を抑制します。

Archive Rulesの設計パターン

• タグベース除外: aws:ResourceTag/purpose = infrastructureのタグを持つロールを自動アーカイブ。インフラ管理用ロールの定期的なFindingsを排除します。
• アカウントベース除外: Sandboxや実験用アカウントのFindingsを自動アーカイブし、本番アカウントのFindingsのみを可視化します。
• ロールARNパターン除外: arn:aws:iam::*:role/AWSControlTower*のパターンでControl Towerが作成するロールを一括除外します。

EventBridgeによるFindings通知

IAM Access AnalyzerはFindingsの状態変化（ACTIVE/ARCHIVEDへの遷移）をEventBridgeイベントとして発行します。EventBridgeルールでSNSトピックやSlackチャンネルへの通知を設定することで、新規の未使用アクセスキー検出をリアルタイムに運用チームへ通知できます。高緊急度のFindingsタイプ（未使用アクセスキー）のみをフィルタリングして通知する設定が実用的です。

Infrastructure as Codeでの管理

組織アナライザとArchive RulesはTerraformリソースaws_accessanalyzer_analyzer・aws_accessanalyzer_archive_ruleで管理できます。IaCで管理することで、除外ルールの変更履歴が残り、セキュリティ審査で「意図的な除外である」根拠を提示できます。

5-7. IAM Access Analyzerと他セキュリティサービスの連携

IAM Access Analyzerのorganization analyzerは、他のセキュリティサービスと連携することで運用統制の網羅性が高まります。

Security Hub連携

委任管理者のSecurity Hubには、IAM Access AnalyzerのFindingsが自動的に統合されます。新世代Security HubのリスクビューでAccess AnalyzerのFindingsを他サービス（GuardDuty・Inspector）のFindingsと並べて優先度を判断できます。

Security Lake連携

IAM Access AnalyzerのFindingsはSecurity Hubを経由してSecurity LakeのOCSFフォーマットで格納されます。過去のFindingsデータをAthenaでクエリすることで、「特定ロールの未使用期間の推移」「アカウントごとのFindingsクローズ速度」といった時系列分析が可能です。

Config連携

AWS Configの管理ルールaccess-keys-rotated・iam-password-policyと組み合わせることで、Access AnalyzerのFindingsとConfigのコンプライアンス状態を1つのConfigダッシュボードで確認できます。両者を統合することで、最小権限の実態（Analyzer）と設定ポリシーのコンプライアンス（Config）の2軸で権限状態を評価する体制が整います。

Config Conformance Packにiam-user-no-policies-check・iam-root-access-key-checkなどの関連ルールをまとめて定義し、組織Conformance Packとして組織横断デプロイすることで、IAM権限ガバナンスを自動評価できます。Access Analyzerが「未使用の実態」を検出し、Configが「ポリシー設定のコンプライアンス」を評価する役割分担で、権限統制の網羅性を高めます。

これらの連携により、IAM Access Analyzerは「単独の権限チェックツール」から「組織全体のセキュリティ統制基盤の一部」として機能します。§4の委任管理展開で構築したセキュリティツールアカウントを中心に、Access Analyzerのデータが他のセキュリティシグナルと統合され、全体的なリスク低減に貢献します。

IAM Access Analyzerを運用統制基盤に組み込む際、最初の90日間は除外ルールの整備とFindingsの優先度設定に集中することを推奨します。初期Findingsは数百件に達することもありますが、Break-glassロール・インフラ管理ロール・CI/CDロールを適切に除外した後は、継続的に対処すべき「実質的な未使用アクセス」のみが残ります。この初期設定の品質が、以降の権限改善サイクルの効率を決定します。

6. コスト配分統制 — Cost Categories・統合請求によるアカウント横断管理

マルチアカウントのコストは、放置すると「誰が何にいくら使っているか」が不透明になります。本節では、統合請求を前提としたCost Categories・Cost Allocation Tags・Billing Conductorによるアカウント横断のコスト配分統制を設計します。

本節の範囲: 本節はコスト「配分・可視化の統制設計」に集中します。RI（リザーブドインスタンス）・Savings Plans・Spotインスタンス・Right-sizingなどのコスト削減手法は、コスト最適化シリーズ（別記事）が専門的に扱います。本節ではコストを「適切に見える化し、担当チームに紐付ける仕組み」の設計のみを扱います。

6-1. 統合請求（Consolidated Billing）の基本設計

Organizationsを利用するマルチアカウント環境では、管理（支払い）アカウントが全メンバーアカウントの請求を一括受領する統合請求（Consolidated Billing）が標準です。統合請求により、複数アカウントの使用量が合算されてRI/Savings Plansの共有割引が効率的に適用される一方、「どのアカウントがいくら使用しているか」の内訳が正確に把握できない状態になりがちです。

管理アカウントのBillingコンソールでは、アカウント別の月間コスト内訳・サービス別コスト・タグ別コストをCost Explorerで確認できます。ただしCost Explorerのデータは生の使用量記録であり、チームやプロジェクト単位でのチャージバックには「分類ルール」の定義が必要です。

Invoice Configurationによる請求書分割

Invoice Configurationを利用すると、連結アカウントのグループを分けて個別の請求書を受領できます。「本番OU配下のアカウント群」と「開発OU配下のアカウント群」を別々の請求書に分割し、各部門の経理担当が直接確認できる体制を整えられます。グループ単位での請求書分割は、大規模組織でのチャージバック処理を簡略化します。

6-2. Cost Categoriesの設計と全メンバー自動適用

Cost Categoriesは、管理（支払い）アカウントレベルで作成し、リンクされた全メンバーアカウントへ自動適用されるコスト分類ルールです。タグ・アカウントID・サービス名・使用タイプなどの条件でコスト使用量をカテゴリに振り分けます。

ルールは優先度順に評価され、どのルールにも合致しないコストは「その他」に分類されます。ルールの設計例は以下のとおりです。

{
  "Name": "ProductCategory",
  "Rules": [
 {
"Value": "ProductA",
"Rule": {
  "Dimensions": {
 "Key": "LINKED_ACCOUNT",
 "Values": ["123456789012", "234567890123"]
  }
}
 },
 {
"Value": "SharedServices",
"Rule": {
  "Dimensions": {
 "Key": "SERVICE",
 "Values": ["AWS Support (Business)", "AWS Config"]
  }
}
 }
  ]
}

Cost Categoriesは月次・日次・時間単位のコストデータに適用でき、Cost Explorer・CUR 2.0・FOCUSフォーマットで分析に利用できます。複数のCost Categoriesを階層的に組み合わせることで、「部門 → プロジェクト → 環境（本番/開発）」といった多段階の分類も実現します。

6-3. Account Tags 2025年12月新機能

2025年12月に、Organizations経由でアカウント単位のコスト配分タグ（Account Tags）を適用する機能が追加されました。従来のCost Allocation Tagsはリソースレベルのタグに依存していたため、タグ付けできないリソース（例：AWS Support費用・Organizationsサービス費用・一部のサービスリンクリソース）のコストを分類できないという課題がありました。

Account Tagsはアカウントそのものにタグを付与し、そのアカウントの全課金対象使用量に自動適用されます。タグ付け不可（untaggable）なリソースを含む、アカウント内のすべての使用量を分類できる点が従来のリソースタグとの決定的な差異です。

Account Tags活用のシナリオ

アカウントにTeam: platform・CostCenter: 100・Env: prodのタグを設定すると、そのアカウントで発生する全コスト（タグ付けが困難なサポート費用・Config費用も含む）が自動的にこれらのタグ値で分類されます。Cost ExplorerおよびCUR 2.0・FOCUSでAccount Tagsによるフィルタリングが可能なため、既存のリソースタグと組み合わせて高精度なコスト配分を実現できます。

Account TagsはBilling and Cost Managementコンソールの「コスト配分タグ」から有効化します。有効化後は翌日以降のコストデータからAccount Tagsが適用されます。

Account Tagsのタグ設計推奨値

組織全体で一貫したAccount Tagsの効果を得るには、タグキーの命名規則をOrganizations SCPで強制することを推奨します。代表的なタグキーとしてCostCenter・Owner・Environment・Projectを設定し、Cost Categoriesのルールと対応づけて設計します。

タグキーの命名はCamelCase（CostCenter）またはkebab-case（cost-center）のどちらかに組織全体で統一します。混在すると同一キーが別カラムとして扱われ、CUR 2.0の分析で集計漏れが発生します。Account Factoryで新規アカウントをプロビジョニングする際に、必須タグキーを自動付与するカスタマイズを組み込んでおくと、Account Tagsの設定漏れを防止できます。

6-4. Billing Conductorによるチャージバック設計

Billing ConductorはAWSコストの「仮想請求書」を作成し、内部チャージバックやショーバックのためのカスタマイズ料金を設定するサービスです。実際の請求には影響せず、内部的なコスト配分の計算に利用します。

Billing Conductorの主要機能

• Pricing Rules（料金ルール）: AWSの公表価格に対してマークアップやディスカウントを適用したカスタム料金を定義します。クラウドコスト管理部門が内部に手数料を加算する「プロライズドプライシング」に利用します。
• Billing Groups: メンバーアカウントをグループ化し、グループ単位でプライシングルールを適用します。
• Pro-rated Discounts: RI/Savings Plansの割引を複数の請求グループに按分して配分します。

チャージバック実装パターン（Cost Categories + CUR 2.0）

Billing ConductorのProForma CURとCost CategoriesおよびAccount Tagsを組み合わせることで、プロジェクト単位のチャージバック金額を自動計算するパイプラインを構築できます。

1. Account Tags（アカウントレベル）とリソースタグ（リソースレベル）でコストを分類します。
2. Cost Categoriesで「プロジェクト」「環境」「チーム」のディメンションに集約します。
3. Billing ConductorのProForma CURをS3に出力します。
4. AthenaまたはQuickSightでProForma CURをクエリし、チャージバックレポートを生成します。

6-5. CUR 2.0とFOCUSによるコスト分析

CUR 2.0（コスト・使用状況レポート v2）

CUR 2.0はAWSの詳細コストレポートの最新形式で、Athenaパーティション分割やParquet形式をネイティブサポートします。Cost Categories・Account Tags・リソースタグのすべてがカラムとして含まれるため、SQLベースでの高度なコスト分析が可能です。

FOCUS（FinOps Open Cost and Usage Specification）

FOCUSはLinux Foundationが策定するオープンなコスト仕様で、AWSはFOCUSフォーマットのエクスポートをCUR 2.0内でサポートします。マルチクラウド環境でのコスト統合分析やFinOpsツールとの連携に利用します。

6-6. AWS Cost Anomaly Detectionによるコスト異常検知

コスト配分の統制と並行して、想定外のコスト急増を早期に検出する「コスト異常検知」を設定することが推奨されます。AWS Cost Anomaly Detectionは、機械学習モデルを用いてコストパターンを学習し、過去のトレンドから逸脱した異常コストを自動検出します。

モニター設定の種類

• アカウント別モニター: 特定のアカウントまたはアカウントグループのコストを監視します。Cost Categoriesに定義したカテゴリ単位でモニターを設定して、プロジェクト・チーム単位の異常を検出できます。
• サービス別モニター: EC2・RDSなど特定のAWSサービスのコスト急増を監視します。
• タグ別モニター: コスト配分タグ（Account Tagsまたはリソースタグ）で絞り込んだコストを監視します。

アラートしきい値の設定

1回のアラートでの異常金額のしきい値（例：100USD以上）を設定し、SNSトピック経由でメール・Slackへ通知します。「絶対金額」と「前月比パーセンテージ」の両方でしきい値を指定できるため、規模の異なるアカウントに柔軟に対応できます。

マルチアカウント組織では、payerアカウントで組織全体を対象とするモニターを設定しつつ、各事業部担当者のメールアドレスをSNSサブスクライバとして追加することで、担当範囲のコスト異常のみを各担当者に通知する体制を構築できます。

Cost Anomaly Detectionはある程度の学習期間（7〜14日）を必要とするため、新規アカウントや新規サービス利用開始直後は誤検知が発生しやすい点に注意してください。学習期間中は通知しきい値を高めに設定し、パターンが安定した後に本番しきい値へ引き下げる段階的な運用が推奨されます。

また、Cost Anomaly DetectionのFindingsはCost Explorerコンソールから確認できますが、APIを通じてFindingsを取得してダッシュボードに統合する設計も可能です。FinOpsチームの週次コストレビューの一環として、Cost Anomaly DetectionのFindingsをCost Categoriesと組み合わせて「どのプロジェクト・アカウントで異常が発生したか」を迅速に特定できる体制を整えます。

6-7. コスト配分設計の全体まとめ

本節で設計したコスト配分の3層構造を整理します。各層は独立して導入できますが、組み合わせることで精度と自動化度が向上します。

各層を段階的に導入することで、スモールスタートで効果を確認しながらコスト配分の成熟度を高めることができます。まずCost Categoriesで主要プロジェクト・OU単位の分類を開始し、次にAccount Tagsで網羅性を高め、最後にBilling ConductorとCost Anomaly Detectionで自動化を完成させる順序が推奨されます。統合請求（Consolidated Billing）はOrganizations導入と同時に有効化されているため、Cost Categoriesの設定のみで即日コスト分類を開始できます。

なお、Account Tags（2025年12月新機能）を有効化した場合は、既存のCost Categoriesルールとの整合性を確認することを推奨します。Account Tagsとリソースタグが同一のキーを使用していると、Cost Explorerの分析結果が二重集計のように見えることがあります。Account Tagsは「アカウント全体」への適用であり、リソースタグは「リソース個別」への適用です。この区別を設計段階で整理し、Cost Categoriesの優先度ルールにより衝突を解消します。さらに、CUR 2.0のレポートにはAccount Tagsカラムとリソースタグカラムの両方が含まれるため、どちらを優先してチャージバック計算に使用するかをチームで合意してからAthenaクエリを設計することが、後続の経理処理の混乱を防ぎます。

7. 実戦統合パターン — 3層統制の責務分界と組み合わせ設計

集約ログ（§2〜§3）・セキュリティ委任管理（§4〜§5）・コスト配分（§6）の3層を、実際のマルチアカウント環境でどう組み合わせるかが運用統制設計の核心です。各層の統制機能は独立して動作しますが、担当アカウント・担当チーム・展開順序を設計なしに決定すると、権限の重複や設定漏れが発生します。本節では、統制レイヤーの責務分界・委任管理者の分離配置・実際の展開手順という3つのテーマで整理します。

7-1. 3層統制の責務分界

3層統制をマルチアカウント環境で運用するには、「どの統制機能をどのアカウントが担当するか」を明確に定義する必要があります。一般的なベストプラクティスは、セキュリティOU配下に専用の機能アカウントを配置し、機能ごとに委任管理者を分離することです。

3層統制の責務分界表

ログアカウントは、組織証跡の集約先S3バケットを保持するとともに、ConfigとSecurity Lakeの委任管理者として機能します。アカウント内のデータへの不正アクセスを防ぐため、ログアカウントへの人的アクセスは厳格に制限し、Breakglass手順を除く通常オペレーションを禁止することが推奨されます。

セキュリティツールアカウントは、GuardDuty・新世代Security Hub・Inspector・IAM Access Analyzerの委任管理者として、組織全体のセキュリティ状態を一元的に把握します。このアカウントではFindingsダッシュボードやアラート設定を管理し、セキュリティ運用チームの日常的な作業の起点となります。新世代Security Hubが各サービスのシグナルを統合するため、このアカウントが実質的なセキュリティ運用センターとして機能します。

管理（payer）アカウントのコスト配分統制は、財務やFinOpsチームが主管します。Cost Categoriesはpayerアカウントレベルで作成・管理し、Account Tagsや統合請求データをCost ExplorerやCUR 2.0で分析します。このアカウントへのアクセスは財務権限を持つロールに限定し、インフラエンジニアとの職務分掌を維持します。

7-2. 委任管理者の分離配置パターン（規模別設計）

委任管理者の最適な配置は、組織のアカウント規模と運用チーム構成によって異なります。小規模・中規模・大規模の3つのパターンで設計を比較します。

小規模構成（〜10アカウント）：統合セキュリティアカウントモデル

アカウント数が少ない組織では、ログアカウントとセキュリティツールアカウントを1つのセキュリティアカウントに統合する構成が運用効率的です。

• セキュリティアカウント（統合）：Organization CloudTrail委任・Config委任・Security Lake委任・GuardDuty委任・Security Hub委任・Inspector委任・IAM Access Analyzer委任をすべて集約
• payerアカウント：Cost Categories・Billing Conductor管理

この構成はアカウント数が少なく、セキュリティ担当が兼任の場合に適しています。ただし、Security Lakeの委任管理者はGuardDutyやSecurity Hubと同一アカウントに置く必要はなく、将来の分離を念頭に置いたIAMロール設計を初期から行うことで移行コストを抑えられます。

中規模構成（〜100アカウント）：ログ／セキュリティ分離モデル

アカウント数が増加し、専任のセキュリティ運用チームが存在する場合は、ログアカウントとセキュリティツールアカウントを分離します。

• ログアカウント：Organization CloudTrail委任・Config委任・Security Lake委任
• セキュリティツールアカウント：GuardDuty委任・Security Hub委任・Inspector委任・IAM Access Analyzer委任
• payerアカウント：Cost Categories・Billing Conductor・Account Tags管理

この分離により、ログの長期保存ポリシーとセキュリティ検知の運用ポリシーを独立して管理できます。ログアカウントは「書き込み専用に近い保存基盤」として最小権限化し、セキュリティツールアカウントはFindingsに対処する「運用基盤」として位置づけます。

大規模構成（100+アカウント）：サービスクラスター分離モデル

100アカウントを超える大規模組織では、サービスごとに専用アカウントを割り当てるか、機能クラスターで分離する構成が保守性を高めます。

• ログアカウント：Organization CloudTrail・Config集約の専任
• Security Lakeアカウント（またはログアカウントと統合）：OCSF正規化・サブスクライバ管理の専任
• セキュリティ検知アカウント：GuardDuty・新世代Security Hub・Inspector
• 権限管理アカウント（またはセキュリティ検知アカウントと統合）：IAM Access Analyzer
• payerアカウント：Cost Categories・Billing Conductor・Invoice Configuration

大規模構成ではConfigの委任管理者は最大3名という制約に注意が必要です。Conformance Packのデプロイ管理をスケールさせるためには、委任管理者の割り当てを慎重に計画します。また、GuardDutyのExtended Threat Detectionや新世代Security HubのEKS・ECS多段攻撃検知など、2025年末以降に追加された機能は自動有効化されるため、大規模環境での影響範囲を事前に評価します。

7-3. 実戦統合パターン3例

統制レイヤーの責務分界と委任管理者配置を決定したら、次に「どの順序でサービスを展開するか」の実施計画を立てます。以下に代表的な3つの統合パターンを整理します。

パターンA：セキュリティOU新規構築時の展開順序

新規にセキュリティOUを設計・構築する場合の推奨展開順序を示します。

ステップ1：組織証跡の作成と集約ログ基盤の確立

最初に実施するのは集約ログの確立です。管理アカウントまたは委任管理者アカウントで組織証跡（Organization Trail）を作成し、中央ログアカウントのS3バケットへのログ集約を開始します。ログファイル検証を有効化し、新規アカウント追加時のサービスリンクロール自動付与を確認します。Configの組織アグリゲータを有効化し、委任管理者（最大3名）を設定します。

この段階でログ基盤が確立され、以降のセキュリティサービス展開の記録が残るようになります。

ステップ2：Security Lakeの委任管理者指定と有効化

組織証跡が安定した後、Security Lakeの委任管理者をログアカウントに指定します。委任管理者の認証情報でSecurity Lakeを有効化し、CloudTrail・VPC Flow Logs・Route 53・Security Hub findingsをOCSFソースとして追加します。サブスクライバ（OpenSearch Zero-ETL統合など）を設定し、OCSF正規化データの参照が可能な状態にします。

ステップ3：セキュリティサービスの委任管理展開

セキュリティツールアカウントをGuardDuty・新世代Security Hub・Inspector・IAM Access Analyzerの委任管理者として指定します。GuardDutyのauto-enableをNEWモードで設定し、新規アカウントの自動オンボーディングを有効化します。新世代Security Hubを有効化して既存メンバーアカウントをオンボーディングし、GuardDuty・Inspector・Security Hub CSPMのシグナルを相関させます。IAM Access Analyzerの組織アナライザを作成して未使用アクセスの検出を開始します。

ステップ4：コスト配分統制の設定

payerアカウントでCost Categoriesを作成し、アカウントやタグを条件にしたコスト分類ルールを定義します。2025年12月の新機能であるAccount Tagsを組織経由で設定し、タグ付けできないリソースを含む全課金対象使用量への自動適用を有効化します。Billing ConductorでチャージバックワークフローとInvoice Configurationを設定し、財務チームへのコスト可視化を完成させます。

パターンB：既存Organizations環境への後付け統制実装

すでにOrganizationsを運用中の環境に統制層を後付けする場合は、既存設定との衝突を避けながら段階的に展開します。

既存環境での注意点と移行戦略

既存環境では、アカウント個別に作成されたCloudTrailやConfig Ruleが存在するケースもあります。組織証跡を新規作成すると、管理対象アカウントの証跡が増えてコスト増につながる可能性もあるため、事前に各アカウントの既存CloudTrail設定を棚卸しします。

既存のセキュリティサービス設定（GuardDutyのアカウント個別有効化など）は、委任管理者設定後に段階的にマイグレーションします。GuardDutyのauto-enableをNEWモードで先に設定し、既存アカウントの移行はALLモードへの変更タイミングを慎重に選定します。

Security Lakeを後付けする場合、2025年4月17日以降に環境を有効化した場合はサービスリンクロール（SLR）権限の推奨設定を確認します。既存ログアカウントにS3バケットが存在する場合、Security LakeのS3ライフサイクルポリシーと既存ポリシーの競合を検証します。

Cost Categoriesの後付けは比較的リスクが低く、payerアカウントでルール作成後すぐに全メンバーへ自動適用されます。ただし、Account Tagsは既存のリソースタグ戦略を整理した後に有効化することで、意図しない分類を防げます。

パターンC：Control Tower Landing Zone環境での統制層追加

Vol1でControl Tower Landing Zoneを構築済みの環境では、既存のアカウント構造・SCP/RCP・AFTプロビジョニングを活用しながら運用統制層を追加します。

Control Tower環境との統合ポイント

Control Towerには、セキュリティOU・ログアーカイブアカウント・監査アカウントのデフォルト構成が含まれています。本記事の「ログアカウント」はControl Towerの「ログアーカイブアカウント」に相当し、「セキュリティツールアカウント」は「監査アカウント」または別途作成した専用アカウントに相当します。

Control Towerのマネージドサービス制御（ガードレール）は、コンプライアンスベースのSCPをControl Tower管理下で維持します。本記事で扱うConfig Conformance PackやSecurity Hub設定はControl Towerのガードレールとは独立して展開できますが、Config委任管理者がControl Tower管理の設定と重複しないよう、展開前にControl TowerのConfig設定を確認します。

AFT（Account Factory for Terraform）を利用している環境では、新規アカウントのプロビジョニング時にAccount Customizationsでセキュリティサービスの初期設定を組み込めます。ただし、委任管理者側のauto-enable設定と二重適用にならないよう、AFTのカスタマイズとOrganizations委任管理を適切に分担します。

Control Tower環境でのCost Categoriesは、Control Towerが自動作成するアカウントの命名規則（アカウントエイリアス・組織OU構造）を活用してルール定義を簡略化できます。OU単位のコスト分類ルールを設計すると、新規アカウントのプロビジョニング後に自動でコスト分類が適用される運用を実現できます。

7-4. 3層統制の統合確認チェックリスト

3層統制の展開が完了したら、以下の確認項目で統合の正常稼働を検証します。各層が独立して機能していても、連携が取れていなければ統制としての効果が出ません。

集約ログ層の確認

• 組織証跡のS3バケットに、管理アカウントを含む全アカウントのCloudTrailログが集約されているかを確認します
• ログファイル検証ダイジェストが定期的に生成されていることをコンソールで確認します
• Config組織アグリゲータで全アカウント・全リージョンの設定変更が遅延なく反映されているかを確認します
• Security LakeのOCSFソースとして設定したデータソース（CloudTrail・VPC Flow Logs等）がデータを取り込んでいるかを確認します

セキュリティ委任管理層の確認

• GuardDutyの委任管理者コンソールで全メンバーアカウントが「管理対象」として表示されているかを確認します
• 新規アカウントを追加した際にauto-enableが機能し、GuardDuty・Security Hubが自動的に有効化されているかを確認します
• 新世代Security Hubで委任サービス（GuardDuty・Inspector・Security Hub CSPM）のシグナルが相関されているかを確認します
• IAM Access Analyzerの組織アナライザで未使用アクセスFindingsが定期的に更新されているかを確認します

コスト配分層の確認

• Cost Categoriesのルールが全メンバーアカウントのコストに適用されているかをCost Explorerで確認します
• Account Tags（2025年12月追加）がタグ付けできないリソースの課金にも反映されているかを確認します
• チャージバック対象のOU・チームごとのコスト分類がCost ExplorerやCUR 2.0で正確に表示されているかを確認します

8. つまずきポイント・アンチパターン・まとめ

組織横断の運用統制は、設計が正しくても実装フェーズで細かな設定漏れや思い込みが重なり、想定外の障害やコスト増に直結します。本節では、実装時によく遭遇するつまずきポイントを症状・原因・対処の形式で8件整理し、避けるべきアンチパターンを❌悪例／✅改善例の対比で6件示します。最後に3層統制の実装完了状態を整理し、次のステップへの道筋をまとめます。

8-1. つまずきポイント

つまずき①：委任管理者を解除するとIAM Access Analyzerの組織アナライザが無効化される

症状：GuardDutyやSecurity Hubの委任管理者をセキュリティツールアカウントから変更した直後に、IAM Access Analyzerの組織アナライザがコンソールから消えたように見える。未使用アクセスのFindingsが参照できなくなる。

原因：IAM Access Analyzerの組織アナライザは、委任管理者として設定されたアカウントのコンテキストで作成されます。委任管理者を解除・変更すると、そのアカウントに紐付いた組織アナライザはスコープを失い、参照・更新ができなくなります。アナライザ自体は削除されず、delegated admin権限が剥奪された状態で残るため、コンソール上から見えなくなったように感じます。

対処：委任管理者を変更する際は、（1）新しい委任管理者アカウントで組織アナライザを再作成し、（2）旧アカウントのアナライザを削除する手順を踏みます。管理アカウントからaws organizations deregister-delegated-administratorを実行する前に、引き継ぎ手順をあらかじめ設計しておくことが重要です。セキュリティ運用の継続性のために、委任管理者の変更は計画的なメンテナンスウィンドウで実施してください。

つまずき②：Security Hub新旧名称の混同（新世代Security Hub vs Security Hub CSPM）

症状：Terraformのリソース名やドキュメントを調べると「Security Hub」という名称が複数の意味で使われており、どちらの機能を設定しているのかが分からなくなる。コンソールの表示と旧ドキュメントの記述が食い違う。

原因：2025年12月のre:Invent 2025で新世代Security HubがGA（一般提供）となり、従来のSecurity Hub（コンプライアンスチェック・Findingsの集約）は「Security Hub CSPM」に改称されました。無印の「Security Hub」は、GuardDuty・Inspector・Security Hub CSPM・Macieのシグナルを相関する統合セキュリティ運用基盤を指すようになっています。re:Invent 2025以前に書かれたブログ・ドキュメント・Terraformリソース（aws_securityhub_account）は旧版を指している場合があります。

対処：AWSドキュメントやTerraformプロバイダーのリリースノートで、2025年12月以降に更新されたリソース（aws_securityhub_account_v2など）と旧リソースを区別して参照してください。設計書や手順書には「新世代Security Hub（2025-12 GA）」または「Security Hub CSPM（旧版）」と明記し、どちらを使用しているかを明確にします。組織の移行計画では、旧版から新世代への切り替えタイミングを意識して設計してください。

つまずき③：Security Lake SLR未設定によるコスト増・レイテンシ劣化

症状：Security Lakeを有効化しているにもかかわらず、ログ取り込みのレイテンシが高く、予想以上のAWSコストが発生している。組織内の他アカウントに比べてデータ取り込みが遅い。

原因：2025年4月17日より前にSecurity Lakeを有効化した環境では、リソース管理用のサービスリンクロール（SLR）がデフォルトで有効化されていません。SLR未有効化の環境では、Security Lakeはリソース管理に追加のAPI呼び出しを必要とするパスを使用するため、レイテンシの増加と余分なコスト発生につながります。

対処：該当環境では、Security Lakeコンソールまたはaws securitylake update-data-lakeでSLR権限を有効化してください。2025年4月17日以降に新規有効化した環境はデフォルトでSLRが有効になっているため、影響を受けません。既存環境をオーバーホールする際には、SLR有効化の状態確認を必ずチェックリストに含めてください。

つまずき④：組織証跡のlog file validation未有効化でコンプライアンス要件未達

症状：CloudTrailのログは中央S3バケットに届いているが、コンプライアンス監査で「ログの完全性が証明できない」と指摘される。AWSの特定の規制フレームワーク（PCI DSS・SOC 2等）の要件を満たしていない。

原因：組織証跡を作成する際にEnableLogFileValidationを有効化しないと、CloudTrailはログファイルのSHA-256ダイジェストファイルを生成しません。ダイジェストファイルがないと、特定のログファイルが改ざんや削除なしに配信されたことを検証できず、コンプライアンス要件で「ログ完全性の証明手段がない」という判定になります。

対処：組織証跡の作成・更新時にEnableLogFileValidation: true（CLIでは--enable-log-file-validation）を必ず指定してください。既存の証跡に対してもaws cloudtrail update-trail --enable-log-file-validationで後から有効化できます。Terraformではaws_cloudtrailリソースのenable_log_file_validation = trueを必ず明記し、Infrastructure as Codeとして管理します。

つまずき⑤：Config組織アグリゲータのサービスプリンシパル未設定でメンバーデータが集約されない

症状：Config組織アグリゲータを設定したにもかかわらず、一部のメンバーアカウントの設定変更履歴や準拠状態がアグリゲーターのダッシュボードに反映されない。アグリゲーターの「対象アカウント数」が全メンバー数より少ない。

原因：Config組織アグリゲータを委任管理者から使用するには、管理アカウントでOrganizationsのサービスプリンシパルconfig-multiaccountsetup.amazonaws.comへの組織アクセスを有効化する必要があります（aws organizations enable-aws-service-access）。この手順を省略すると、委任管理者はメンバーアカウントへのアクセスを取得できず、データが集約されません。

対処：委任管理者アカウントを登録する前に、管理アカウントで以下のコマンドを実行してサービスアクセスを有効化してください。

aws organizations enable-aws-service-access \
  --service-principal config-multiaccountsetup.amazonaws.com

その後、aws organizations register-delegated-administratorで委任管理者を登録します。Terraformではaws_organizations_delegated_administratorリソースとaws_organizations_organizationのaws_service_access_principalsにconfig-multiaccountsetup.amazonaws.comを含めて管理します。

つまずき⑥：GuardDuty Extended Threat Detectionの有効状態確認方法の誤解

症状：GuardDutyコンソールでExtended Threat Detectionを探しても「有効化」ボタンが見当たらない。有効になっているのかどうかが判断できない。

原因：Extended Threat Detectionは2025年12月に追加費用なしで自動有効化された機能です。「有効化する」という操作項目は存在せず、GuardDutyが有効な状態であれば自動的に機能します。コンソールに独立した設定項目がないため、無効化状態と区別がつきにくいと感じる場合があります。

対処：GuardDutyが委任管理者アカウントで有効になっていれば、Extended Threat Detectionは追加操作なしに機能しています。機能が正常に動作しているかはGuardDutyのFindingsタイプに「AttackSequence」カテゴリが含まれているかで確認できます。AWSのGuardDutyコンソールの「Findings」画面で検索フィルタにAttackSequenceを指定するか、Security HubのFindingsで相関されたシグナルを参照してください。

つまずき⑦：Cost Allocation Tagsを有効化しないとCost Explorerに分類が表示されない

症状：リソースにタグを付与しているにもかかわらず、Cost ExplorerやCost Categoriesのダッシュボードに当該タグの分類が表示されない。コスト配分タグが「非アクティブ」のまま。

原因：AWSはタグが実際に使用されていても、Billing and Cost Managementコンソールでコストアロケーションタグとしてアクティブ化するまで、コスト配分への適用を開始しません。タグの有効化から実際にコストデータへ反映されるまで、最大24時間かかります。また、Account Tags（Organizations経由で設定）もCost Explorerでアクティブ化しないとCost Categoriesで参照できません。

対処：Billing and Cost Managementコンソールの「コスト配分タグ」画面で、分析に使用するすべてのタグキーをアクティブ化してください。Account TagsはOrganizations管理アカウントのコンソールから管理し、アクティブ化を行います。IaC管理する場合はaws_ce_cost_allocation_tag（Terraform）でアクティブ化を自動化することを推奨します。

つまずき⑧：組織証跡のS3バケットポリシーが不完全でメンバーログが拒否される

症状：組織証跡を作成して数日後、特定のメンバーアカウントからのログだけが届いていないことに気づく。CloudTrailのステータスでは「ログ記録: 有効」と表示されているにもかかわらず。

原因：組織証跡用の中央S3バケットには、管理アカウントだけでなく全メンバーアカウントからの書き込みを許可するバケットポリシーが必要です。CloudTrailコンソールから組織証跡を作成すると、バケットポリシーは自動更新されます。ただし、既存のカスタムポリシーを持つバケットを指定した場合や、後からメンバーアカウントを追加した場合に条件分岐の不整合が生じる点に注意してください。特にaws:SourceOrgID条件と個別のアカウントIDリストを混在させると、予期せぬ拒否が発生します。

対処：バケットポリシーはOrganizationsのaws:PrincipalOrgID条件を使用して組織全体に書き込み許可を付与する形式を採用してください。個別アカウントIDの列挙は新規アカウント追加のたびに更新が必要となり、管理コストと設定ミスのリスクが増大します。バケットポリシーのテンプレートはAWS CloudFormationまたはTerraformで管理し、組織証跡作成と同じIaCリポジトリで一元管理することを推奨します。

8-2. アンチパターン

アンチパターン①：各メンバーアカウントに個別CloudTrailを作成する

❌ 悪例：メンバーアカウントごとにCloudTrailを個別作成し、ログをそれぞれの S3バケットへ送信する。新規アカウントが増えるたびに手動でTrailを作成・設定する。

✅ 改善例：管理アカウントまたは委任管理者から組織証跡（Organization Trail）を1本作成し、全メンバーアカウントのログを中央ログアカウントの単一S3バケットへ自動集約する。新規アカウントはOrganizations参加と同時にサービスリンクロールが付与され、自動でログ記録が開始されます。組織証跡はメンバーアカウントのコンソールには表示されず、管理アカウント側でのみ管理できるため、誤削除リスクも低減されます。

アンチパターン②：GuardDuty auto-enableをNONEに設定する

❌ 悪例：GuardDutyの委任管理者設定でauto-enableをNONE（自動有効化なし）のまま運用する。既存アカウントには手動でGuardDutyを有効化しているが、新規アカウントは有効化されないままになっている。

✅ 改善例：委任管理者アカウントでauto-enableをNEW（新規参加アカウントを自動有効化）またはALL（全アカウントを自動有効化）に設定します。NEWを選択すると、Organizationsに新規参加したアカウントへGuardDutyが自動でオンボーディングされ、設定漏れによるセキュリティホールを防止できます。まず既存アカウントをALLで一括有効化した後、運用フェーズに移行してからNEWへ変更するのが推奨パターンです。

アンチパターン③：Cost Categoriesのルールを未設定のまま運用する

❌ 悪例：統合請求を有効化しているが、Cost Categoriesのルールを設定していない。Cost Explorerのコスト配分ビューを確認すると、ほぼすべてのコストが「その他」や「未分類」に集約されており、チームやプロジェクト単位の内訳が不明。

✅ 改善例：管理（支払い）アカウントのCost Categoriesで、OU・アカウントID・タグの組み合わせによる分類ルールを事前設計します。例えば、OUをルールのマッチ条件にすることで、本番OU・ステージングOU・セキュリティOUのコストを自動分類できます。ルールの設計はAccount Tags（2025年12月新機能）と組み合わせ、タグ付けできないリソースのコストもアカウント単位で分類することで、ほぼ全コストを「その他」なしに分類する設計が実現します。

アンチパターン④：Security Hub CSPMと新世代Security Hubを混在させる

❌ 悪例：一部のアカウントで旧版のSecurity Hub（現Security Hub CSPM）のみを有効化し、別のアカウントでは新世代Security Hubを有効化している。同一組織内での世代混在により、Findingsの集約先とダッシュボードの表示が一致しない。

✅ 改善例：組織内では使用するSecurity Hubの世代を統一します。2025年12月以降に新規構築する場合は新世代Security Hubを採用し、従来のCSPM機能はSecurity Hub CSPMとして引き続き利用できます。委任管理者の設定やTerraformリソースで「新世代」か「旧世代」かを明示し、全メンバーアカウントへのオンボーディングを一世代に統一することでFindingsの集約とダッシュボードの整合性を維持します。

アンチパターン⑤：Invoice ConfigurationなしでチャージバックをCost Explorerのみで管理する

❌ 悪例：各ビジネスユニットへのチャージバックをCost ExplorerのCSVエクスポートで手動計算し、Excelで集計する。月末の請求処理に大量の手作業が発生し、計算ミスや報告遅延が頻発する。

✅ 改善例：Invoice ConfigurationとBilling Conductorを組み合わせ、ビジネスユニット単位の請求グループを設計します。Invoice ConfigurationはBilling and Cost Managementコンソールで設定し、特定アカウント群を別請求書で受領できるようにします。Billing Conductorではショーバック／チャージバックのカスタム価格設定とカスタムCURの出力により、経理・財務チームが直接参照できるコストレポートを自動生成する設計が実現します。

アンチパターン⑥：IAM Access AnalyzerのFindingsを放置して最小権限を維持しない

❌ 悪例：IAM Access Analyzerの組織アナライザを設定し、Findingsが検出されているにもかかわらず、対応するプロセスがなく数ヶ月単位でFindingsが未解決のまま蓄積する。未使用アクセスが残存し続け、権限のクリープが発生する。

✅ 改善例：Findingsのレビュー・対処サイクルを定期運用として組み込みます。例えば、月次でAccess AnalyzerのFindingsをCost & Usageレポートのサイクルと合わせてレビューし、未使用ロール・アクセスキー・アクションに対してポリシーの更新または無効化を実施します。Security Hubのダッシュボードに未使用アクセスのFindingsをカテゴリとして追加することで、セキュリティレビューの一部として継続的に可視化できます。分析スコープのカスタマイズで優先度の高いアカウント・ロールに絞って対処を開始し、段階的に全組織へ展開するアプローチを推奨します。

8-3. まとめ — 3層統制の実装完了と次のステップ

本記事では、Vol1で構築したControl Tower Landing Zone基盤の上に、組織横断で運用統制を実装する3つの能力を設計しました。

① 集約ログ統制（§2〜§3）の実装完了状態

Organization CloudTrailで全アカウントのAPI監査ログを中央ログアカウントのS3バケットへ集約し、log file validationで改ざん検知を有効化します。Config組織アグリゲータとConformance Packで構成コンプライアンスを組織横断で管理します。Security LakeでOCSF正規化を施し、OpenSearch等のサブスクライバが統一スキーマで横断分析できる状態を整えます。

② セキュリティサービスの委任管理展開（§4〜§5）の実装完了状態

GuardDuty・新世代Security Hub・Inspector・Macie・IAM Access Analyzerをセキュリティツールアカウントへ委任管理者として集約し、組織全体を単一のガラス板（single pane of glass）で監視します。GuardDuty auto-enableで新規アカウントの自動オンボーディングを保証し、Extended Threat Detectionで多段攻撃を自動検知します。IAM Access Analyzerの組織アナライザで未使用アクセスを継続的に可視化し、最小権限の維持サイクルを確立します。

③ コスト配分統制（§6）の実装完了状態

Cost Categories（管理アカウントで作成）とAccount Tags（2025年12月新機能）で全アカウントの使用コストをOU・チーム・プロジェクト単位に分類します。Invoice ConfigurationとBilling Conductorでビジネスユニット単位のチャージバック／ショーバックを自動化し、経理・財務チームが直接利用できるコストレポートを提供します。

次のステップ — さらなる高度化への道筋

Vol1基盤（Control Tower・AFT・CfCT・SCP/RCP）とVol2運用統制層（集約ログ・委任管理・コスト配分）を実装した後、さらなる高度化として以下を検討できます。

• セキュリティ自動化：Security Hubのカスタムアクション＋EventBridge＋Lambda/Step Functionsによる自動修復パイプラインの構築
• コスト予測と異常検知：AWS Cost Anomaly Detectionのアラート設計と、予算アラート（AWS Budgets）による組織横断コスト管理
• 継続的コンプライアンス：Config Conformance PackのカスタムルールとSecurity Hub Standards（CIS Benchmarks / PCI DSS）の組み合わせによる自動コンプライアンス評価
• 組織管理の成熟度向上：AccountFactory for Terraform（AFT）によるアカウントプロビジョニングの完全自動化とガードレールのIaC管理

本記事で扱ったGuardDuty/Security Hubの検知運用・Findings分析・Terraform実装の詳細は、既存のセキュリティ記事で深掘りしています。また、RI/Spot/Right-sizingによるコスト削減手法はコスト最適化シリーズをご参照ください。

Vol1：マルチアカウント基盤の構築編を読む