御社のAWSアカウントは何個ありますか。
サービス単位、部門単位などでアカウントを分けているのをよく見かけます。
IT管理者はそれらの複数アカウントに対し、ある程度の統制・監視をする必要があります。
マルチアカウントを一つの組織という単位にまとめるサービスはAWS Organizationsです。
今回はOrganizationsを使って、AWSの監査ログであるCloudTrailの証跡を一元管理して見ました。
1.CloudTrail証跡の保存構成の比較
1-1.アカウントごとに証跡管理をする場合（デフォルト設定）
各アカウントのS3バケットとCloudWatchLogsロググループに保存されます。
1-2.Organizationsで証跡を一元管理する場合（今回はこちら）
マスターアカウントのS3バケットとCloudWatchLogsロググループに保存されます。
2.設定してみよう
2-1.マスターアカウントで有効化
マスターアカウント > AWS Organizations > 設定
AWS CloudTrailというのがあるので、下記のように有効化します。
2-2.マスターアカウントでCloudTrailの設定
マスターアカウント > CloudTrail > 証跡情報
証跡設定を作成、または修正します。
「組織に証跡を適用」を有効にする以外は、特別な設定はありません。
設定後は、下記のように表示されます。
2-3.子アカウントでCloudTrailの設定は不要
子アカウントでは設定は不要です。
CloudTrailの画面をみると、自動的に設定されているのがわかります。
通常よりも文字の色が薄くなっています。
なお、これ以降に子アカウントを作成した場合も、その子アカウントには自動的に設定されます。
3.保存されているか確認しよう
3-1. S3の確認
マスターアカウントの証跡設定で指定したS3バケットに、AWSアカウントごとにフォルダ分けされて保存されます。
3-2. CloudWatch Logsの確認
マスターアカウントの証跡設定で指定したロググループに、[組織ID][AWSアカウントID]_CloudTrail[リージョン]とストリーム分けされて保存されます。
念のため、ログの中身も確認してみました。
テストとして、子アカウントのセキュリティグループで0.0.0.0/0からの通信を許可する設定変更を加えました。
マスターアカウントのロググループで検索したところ、しっかりと確認できました。
なお、ロググループの検索フィルタは以下を使いました。
{ ( $.eventName="CreateSecurityGroup" ) || ( $.eventName="DeleteSecurityGroup" ) || ( $.eventName="AuthorizeSecurityGroupEgress") || ( $.eventName="AuthorizeSecurityGroupIngress" ) || ( $.eventName="RevokeSecurityGroupEgress" ) || ( $.eventName="RevokeSecurityGroupIngress" ) }
参考ページ
- CloudTrail イベント履歴を検索して、セキュリティグループまたはリソースがどのように変更されたかを調べるにはどうすればよいですか ?
- CloudWatch Logsのメトリクスフィルターの書き方を整理してみた
4. まとめ
とても簡単にCloudTrailの証跡を一元管理できるようになりました。
単一のS3バケット、CloudWatchLogsロググループから参照できるようになったので、ここからさらに別の検知・分析系サービスに連携させるのも容易になったと思います。
また、子アカウント作成時に強制的に自動的に設定されるので、作業負荷や監査の観点でとても有効です。