前回はControlTowerによって作成されるAuditアカウントの内容について確認していきました。今回はLogArchiveアカウントに作成されるリソースを確認していきたいと思います。
ControlTower関連リンクまとめ
・ControlTower①マルチアカウント環境をセットアップする
・ControlTower②環境確認
・ControlTower③SSOの確認・アカウントの追加・削除
・ControlTower④ガードレールの設定
・ControlTower⑤Auditアカウントに作成されるリソースについて
・ControlTower⑥LogArchiveアカウントに作成されるリソースについて ←今ここ
・ControlTower⑦SecurityHubの有効化
・ControlTower⑧GuardDutyの有効化
・ControlTower⑨CloudWatchクロスアカウントダッシュボードの設定
・ControlTower⑩LogArchiveアカウント内バケットへのCloudWatchLogs集約
現在のアカウント構成の確認
各アカウントの主な役割について下記図でおさらいします。
管理アカウントではControlTowerによりガードレールの追加や、アカウントの追加・削除、SSOの設定などを行います。
AuditアカウントはControlTower配下のアカウントのConfigを集約します。検知的ガードレールもConfigルールによりルール違反を検知する為、Configとガードレールの監視が集約されている状態です。また、各アカウントのConfig通知もAuditアカウントに集約されます。
LogArchiveアカウントに作成されるリソース
今回はLogArchiveアカウントのリソースについて確認していきます。
ユーザーガイドによると、LogArchiveアカウントにはConfig（Auditアカウントに集約）、Lambda（AuditアカウントのSNSにConfig通知をPush）、CloudTrailや各リソース・SSOに使用するIAMロール以外に、S3バケットが作成されているようです。ログについてはすべてこのLogArchiveアカウントに集約される形のようです。
S3バケット
IAMロール・Config・CloudTrail・Lambdaなどのサービスは共通設定となるので割愛し、S3バケットを確認していきます。
ControlTowerによって作成されるS3バケットは下記の二つです。
・aws-controltower-logs-[アカウントID]-[リージョン名]
→CloudTrail、Configのログが集約されるバケット
・aws-controltower-s3-access-logs-[アカウントID]-[リージョン名]
→S3のアクセスログが集約されるバケット
※画像ではバケット数が4つと表示されていますが、これは初期に作成されたバケットとは別に後から追加したものです。
aws-controltower-logsバケット
CloudTrail・Configのログが集約されているバケットです。
中を見てみると、Organizationsの組織IDでディレクトリが切られています。
更に進んでいくと「AWSLogs」というディレクトリの下にControlTower配下の各アカウントIDのディレクトリが並んでいます。
各アカウントIDの下には、CloudTrailのログ・ConfigのログとCloudTrailのDigestファイルが格納されています。
例えばCloudTrailはこのような感じで格納されています。
ディレクトリ構成は下記のような形になります。
Organizationsの組織名>AWSLogs>各アカウントID>サービス名>リージョン名>yyyy>mm>dd>各種ログファイル
また、CloudTrailのログにはControlTowerのライフサイクルイベントも記録されています。CloudTrailに記録されるライフサイクルイベントの詳細についてはユーザーガイドをご参照ください。
ライフサイクルルール
バケットはバージョニングが有効化され、ライフサイクルルールも追加されています。
ログは一年で有効期限が切れ、削除される設定になっています。ライフサイクルルールは必須のガードレール「ログアーカイブに AWS Control Tower が作成した Amazon S3 バケットのライフサイクル設定の変更を許可しない」で変更ができないよう設定されており、現時点ではControlTower上からバケットのライフサイクルルールを変更することができません。
そのため、セキュリティポリシーなどでログの保持期間が一年以上に定められている場合は新たに自分でログ取得の設定を行う等、個別の対応が必要となります。
aws-controltower-s3-access-logs
こちらはS3バケットのアクセスログが保管されているバケットです。
バージョニングは有効化されますが、ライフサイクルルールについては未設定となっていました。
ControlTowerにより作成されたS3バケットについては、必須のガードレールで変更が拒否されている為、現状ではここにライフサイクルルールを追加することはできません。
ControlTowerで作成されるS3バケットの注意点
ControlTowerで作成されるこれらのバケットについては、必須のガードレールで下記の操作が制限されています。バケットポリシーの変更が制限されているため、CloudTrailやConfig以外のサービスのログをLogArchiveアカウントのバケットに集約する場合は、新たにバケットを作成する必要があります。また、暗号化設定やライフサイクルルールの設定も変更できない点に注意してください。
・バケットの暗号化設定の変更
・バケットのロギング設定の変更
・バケットのバケットポリシーの変更
・バケットのライフサイクル設定の変更
各アカウントの役割整理
今回はLogArchiveアカウントの中に作成されるS3バケットについて確認しました。これで、ControlTowerを管理する三つのアカウントの中身について把握できたかと思います。
ControlTowerによってできることのまとめ
①～⑥までの記事の中でで、ControlTowerの初期設定でできるリソースや集約設定を確認していきました。
ControlTowerを有効化することで行われる設定の概要は下記のようなイメージです。
- セキュリティ用、その他（※用途によって追加可能）などの役割別のOUの作成
- 必須ガードレールの設定
- 監査用、ログ収集用の用途別のアカウントの作成
- SSO権限セット作成、各アカウントにSSO用のIAMロール作成
- LogArchiveアカウントへのS3バケット作成、ライフサイクルルール設定
- 各アカウントでのConfig有効化（LandingZoneで指定したリージョンのみ）
- Auditアカウントのアグリゲーターへの集約設定、AuditアカウントへのConfig通知の集約設定
- 各アカウントでのCloudTrailの有効化（全リージョン有効化されていました）
- LogArchiveアカウントへのバケットポリシー作成Config、CloudTrailログの集約設定
Configの有効化やCloudTrailの有効化などは、アカウント追加時に必ず必要となる設定です。一つ一つの設定は簡単ですが、アカウントごとにサービスを有効化しログの集約や通知先の設定を行っていると、かなりの時間がとられてしまいます。そのため、監視の設定が一括で行えることで初期構築がかなり楽になりますね。
また、ガードレールではAWSベストプラクティスの内容が反映されている為、ControlTowerのガードレールで一気に検知や禁止の内容を設定できることも魅力です。
ただし、SNSトピックにて配信される通知メッセージのカスタマイズや、GuardDuty・SecurityHubなどの有効化、VPCフローログの設定などはこちらで設定を追加する必要があります。
難点は、ControlTowerのガードレールによりリソースの変更ができなくなってしまうことです。要件がControlTowerの設定内容と合致しない場合は、かえって構築の手間が増えてしまうことも考えられます。今後のアップデートで、内容のカスタマイズが容易になればより使いやすくなりますね。
ここまでお読みくださりありがとうございました。
ControlTowerの基本的な機能確認については今回で終わりになります。
次回以降はSecurityHub・GuardDutyの設定追加や、通知のカスタマイズ方法などについて確認していきたいと思います。