マルチアカウント構成になってから、このような悩みがあるケースが増えています。
本番・開発・ステージングでアカウントを分けたり、事業部ごとにアカウントを作ったりすると、CloudTrail・VPC Flow Logs・Security Hubのログがアカウントごとに分散して保存されます。
個別に確認する手間が膨大になり、横断的な脅威の検出が遅れます。
この記事では、AWSログ監視をマルチアカウント構成で一元化する設計を解説します。AWS Security Lakeを中心に、集約アーキテクチャの設計パターンと有効化の手順を整理します。想定環境はAWS Organizations管理下の複数アカウント構成です。
この記事のポイント
・AWS Security Lakeは複数アカウントのログをS3に一元集約できる
・OCSFフォーマットに正規化されるため、SIEMとの連携が容易になる
・Organizations委任管理者アカウントで集中管理する設計が基本形
・CloudTrail・VPC Flow Logsなど主要ソースを自動収集できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
マルチアカウントのAWSログ監視はなぜ難しいのか
AWSのセキュリティ設計でよく起きるのが「ログは取っているが、見られていない」状態です。シングルアカウントなら、CloudWatchダッシュボードやCloudTrailのコンソールで確認できます。しかし、アカウント数が増えると同じことが難しくなります。
具体的には、次のような問題が出てきます。
・各アカウントのCloudTrailログが別々のS3バケットに保存される
・VPC Flow LogsはCloudWatch Logsに出力されており、アカウントをまたいだ検索ができない
・Security Hubの検知結果も各アカウントに閉じている
・GuardDutyのアラートが届いても、どのアカウントのどのリソースか特定に時間がかかる
「10アカウントあれば10か所確認しなければならない」という状況になります。
これを解決する方法の一つが、ログを1か所に集約するアーキテクチャです。以前はS3のクロスアカウントレプリケーションを手動で設定することが多かったのですが、現在はAWS Security Lakeが標準的な選択肢になっています。
AWS Security Lakeとは何か（集約設計の全体像）
AWS Security Lakeは、AWSアカウントとリージョンにまたがるセキュリティログを、単一のS3バケットに集約するマネージドサービスです。特徴は大きく2つあります。
OCSFへの正規化
収集したログをOpen Cybersecurity Schema Framework（OCSF）という標準フォーマットに変換してから保存します。ログのフォーマットがソースごとに異なるという問題を解決し、AthenaやSIEMから統一したクエリで分析できるようになります。
Organizationsとの統合
AWS Organizationsと連携することで、管理アカウントから全メンバーアカウントのログを一括で収集できます。新しいアカウントが追加されたときも、自動的に収集対象に含めることができます。
主なデータソースとして、次のものを自動収集できます。
・AWS CloudTrail（管理イベント・データイベント）
・VPC Flow Logs
・Amazon Route 53 Resolverクエリログ
・Amazon Security Hub（検知結果）
・Amazon EKS監査ログ
・AWS WAFログ
サードパーティのログ（Okta・CrowdStrikeなど）をカスタムソースとして追加することもできます。
Security Lakeを有効化してログを集約する設定手順
ここでは、AWS Organizationsを使ったマルチアカウント構成での設定手順を説明します。1. 委任管理者アカウントを設定する
Security Lakeの運用は、専用のセキュリティアカウント（Security Account）を委任管理者として設定するのが基本です。管理アカウントで次のコマンドを実行します。
# Security Lake の委任管理者を設定する（管理アカウントで実行） aws organizations register-delegated-administrator \ --account-id 111122223333 \ --service-principal securitylake.amazonaws.com
次に、委任先アカウントでSecurity Lakeを有効化します。
# Security Lake を有効化する（東京リージョンの例） aws securitylake create-data-lake \ --configurations '[ { "region": "ap-northeast-1", "encryptionConfiguration": { "kmsKeyId": "alias/aws/securitylake" }, "replicationConfiguration": { "regions": [], "roleArn": "" } } ]' \ --meta-store-manager-role-arn \ arn:aws:iam::111122223333:role/AmazonSecurityLakeMetaStoreManagerV2
現在の状態を確認するには次のコマンドを使います。
# データレイクの状態を確認する aws securitylake get-data-lake-status \ --account-ids 111122223333 # 出力例（環境により異なります） # { # "dataLakes": [ # { # "dataLakeArn": "arn:aws:securitylake:ap-northeast-1:111122223333:data-lake/default", # "region": "ap-northeast-1", # "status": "INITIALIZED" # } # ] # }
2. データソースを追加する
有効化後、収集するログのソースを設定します。次のコマンドでOrganizationsの全アカウントにCloudTrailとVPC Flow Logsを設定します。# 組織内の全アカウントでデータソースを有効化する aws securitylake update-data-lake-organization-configuration \ --auto-enable-new-account '[ { "region": "ap-northeast-1", "sources": [ {"sourceName": "CLOUD_TRAIL_MGMT"}, {"sourceName": "VPC_FLOW"}, {"sourceName": "SH_FINDINGS"} ] } ]'
Sources に指定できる主な値は次のとおりです。
・CLOUD_TRAIL_MGMT（CloudTrail管理イベント）
・LAMBDA_EXECUTION（Lambda実行ログ）
・S3_DATA（S3データイベント）
・VPC_FLOW（VPC Flow Logs）
・ROUTE53（Route 53 Resolverクエリログ）
・SH_FINDINGS（Security Hub検知結果）
Organizationsの全メンバーアカウントに設定を反映させるには、コンソールの「組織設定」から「既存アカウントにも適用」を有効にします。
3. サブスクライバーを設定する
集約したログをAthenaやSIEMから参照するには、サブスクライバーを設定します。次のコマンドで、Athenaからクエリできるサブスクライバーを作成します。
# Athena用のサブスクライバーを作成する aws securitylake create-subscriber \ --subscriber-name "athena-subscriber" \ --sources '[ {"awsLogSource": {"sourceName": "CLOUD_TRAIL_MGMT", "sourceVersion": "2.0"}}, {"awsLogSource": {"sourceName": "VPC_FLOW", "sourceVersion": "2.0"}} ]' \ --subscriber-identity '{ "principal": "111122223333", "externalId": "my-external-id" }' \ --access-types '["S3"]'
LinuxサーバーとAWSを組み合わせた運用の基礎については、Amazon LinuxでのLinuxサーバー構築と基礎設定も参考にしてください。
マルチアカウント設計の3つのパターン
Security Lakeを使ったマルチアカウントのログ監視設計には、いくつかのパターンがあります。パターン1: 専用セキュリティアカウント型
AWS Organizations内に「セキュリティアカウント」を作成し、Security Lakeの委任管理者として設定します。全アカウントのログが1つのS3バケットに集約されます。コスト管理が明確になり、SIEMとの統合がシンプルになります。
パターン2: リージョン集約型
東京リージョンと大阪リージョンそれぞれにSecurity Lakeを有効化し、東京リージョンを「ロールアップリージョン」として設定する方法です。大阪リージョンのログが東京に自動的にレプリケートされます。リージョン障害を想定した設計に向いています。
パターン3: LogArchiveアカウント連携型
AWS Control Towerを使っている場合、LogArchiveアカウントとSecurity Lakeを連携させる設計です。既存のS3集約と整合しやすく、Control Tower環境での採用例が多いパターンです。
3つの中では、専用セキュリティアカウント型が最もシンプルで、はじめて取り組む場合に向いています。
注意点とよくある問題
Security Lakeの運用で注意が必要な点と、よくある問題を整理します。コストの見積もりを事前に行う
Security Lakeのコストは主に次の3つで構成されます。
・S3ストレージコスト（収集したログの保管）
・データ取り込みコスト（1GBあたりの料金）
・クエリコスト（Athenaを使う場合は1TBあたりの料金）
VPC Flow LogsはデータボリュームがCloudTrailより大きくなりやすいため、すべてのアカウントで有効化する前にサンプルアカウントで取り込み量を確認することをお勧めします。
コストを抑えるには、Security Lakeのライフサイクル設定でS3の保存期間を設定します。コンソールの「ライフサイクル管理」から各データソースの保存日数を設定できます。
データソースが「PENDING」のまま進まない
データソースを追加したあと、収集が始まるまで15～20分かかることがあります。それ以上PENDING状態が続く場合は、次を確認してください。
・委任管理者アカウントへのアクセス許可ポリシーが正しく設定されているか
・OrganizationsのSCPでSecurityLakeの操作がブロックされていないか
・CloudTrailがすでに有効化されているアカウントで設定が競合していないか
AthenaクエリでテーブルにアクセスできないときはテーブルI名を確認する
AthenaでOCSFログをクエリするとき、テーブル名はリージョンとOCSFバージョンを含む形式になります。
-- CloudTrail管理イベントのテーブル名形式 -- テーブル名: amazon_security_lake_table_ap_northeast_1_cloud_trail_mgmt_2_0 -- ハイフンはアンダースコアに変換される点に注意 SELECT eventtime, api.operation, actor.user.name, src_endpoint.ip FROM "amazon_security_lake_table_ap_northeast_1_cloud_trail_mgmt_2_0" WHERE eventday = '20241110' LIMIT 10; -- 出力例（環境により異なります） -- eventtime | api.operation | actor.user.name | src_endpoint.ip -- ...
本記事のまとめ
AWSログ監視をマルチアカウント構成で設計する方法を解説しました。| 設計のポイント | 内容 |
|---|---|
| 委任管理者の設定 | Organizations管理アカウントから専用セキュリティアカウントを委任管理者に設定する |
| データソースの選択 | CloudTrail・VPC Flow Logs・SH_FINDINGSを優先して有効化する |
| サブスクライバー設定 | Athena経由でOCSFログをクエリするか、SIEMに直接連携する |
| コスト管理 | VPC Flow Logsは事前にボリュームを確認し、ライフサイクルを設定する |
| 設計パターン | 初めての場合は専用セキュリティアカウント型が最もシンプル |
＞＞ Amazon Linux 入門・基礎解説はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：EC2インスタンスへのZabbix監視をAWSセキュリティグループで設計する方法｜監視サーバーの冗長化
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます