前回はControlTowerのマスターアカウント上でガードレールの追加・削除設定を行いました。
今回は、ControlTowerによって作成されているAuditアカウント、LogArchiveアカウントのリソースの確認を行います。
ControlTower関連リンクまとめ
・ControlTower①マルチアカウント環境をセットアップする
・ControlTower②環境確認
・ControlTower③SSOの確認・アカウントの追加・削除
・ControlTower④ガードレールの設定
・ControlTower⑤Auditアカウントに作成されるリソースについて←今ここ
・ControlTower⑥LogArchiveアカウントに作成されるリソースについて
・ControlTower⑦SecurityHubの有効化
・ControlTower⑧GuardDutyの有効化
・ControlTower⑨CloudWatchクロスアカウントダッシュボードの設定
・ControlTower⑩LogArchiveアカウント内バケットへのCloudWatchLogs集約
現在のアカウント構成の確認
前回まではControlTowerの管理アカウントにてリソース・アカウント・ガードレールの確認や設定を行いました。今回からはAuditアカウント・LogArchiveアカウントについても確認しますが、一旦現在のアカウント構成を整理しました。
現在、ControlTowerで作成したアカウントは下記の構成となります。
前回までは「管理アカウント（Root）」にてControlTowerやOUの管理について確認しました。
今回はAuditアカウントに作成されるリソースについて確認します。
Auditアカウント、LogArchiveアカウントはControlTowerの有効化を行うと自動で追加されるアカウントです。この環境では、セットアップ時にSandboxOUを追加し、ControlTowerによるアカウント追加の手順に従ってSandboxアカウントを追加しています。
Auditアカウントに作成されたリソース
まずはAuditアカウントから確認していきます。
ユーザーズガイドによると、Auditアカウント（監査アカウント）にはConfigアグリゲーターやSNSトピック、Lambdaやリソースに付随するIAMロールなどのリソースが構築されます。AuditアカウントはOU全体のセキュリティ監査を行うことを想定して作られるため、各アカウントのConfigを集約し、構成変更が発生した場合にSNSが発報されるように設定されているようです。
IAMロール
ControlTowerによりいくつかIAMロールが作成されています。リソースの権限設定や、SSOユーザー用の権限設定に必要なものです。各アカウントに作成されるIAMロールについて、詳細は以下のページに記載があります。
・AWS Control Tower がロールと連携してアカウントを作成および管理する方法
・AWS Control Tower 用のアイデンティティベースのポリシー (IAM ポリシー) を使用する
ControlTowerにて自動設定されるAWSControlTowerAdmin ロールについては、不正アクセスを防止するためにIAMポリシーにaws:SourceArnまたはaws:SourceAccount条件を付けることが推奨されています。ControlTowerによりアカウントを作成したら、まずはユーザーガイドの「ロールの信頼関係のオプション条件」を参考にIAMポリシーに制限を追加することをお勧めします。
CloudTrail
ControlTowerによりCloudTrailの証跡が作成されています。
配信先のS3バケットはLogArchiveアカウント内のS3が指定されています。
ちなみに、ログの保持期間は2週間となっています。
AWS Config・Configルール
ControlTowerを有効化すると、各アカウントでConfigが有効化され、いくつかのルールが自動で設定されます。ControlTowerにより設定される初期ルールについては、ユーザーズガイドのリソース一覧のページをご確認ください。また、「検出」タイプのガードレールでもConfigルールが設定されます。こちらについてはガードレールのリファレンスをご確認ください。
AWS Configの配信先もControlTowerにより自動で設定されます。配信先バケットはLogArchiveアカウントのS3、配信先トピックはAuditアカウントの「aws-controltower-AllConfigNotifications」となっています。
Configアグリゲーター
Configアグリゲータはこのような形で見えます。
ステータスが「未完了」となっていますが、東京リージョン以外のリージョンでConfigが有効化されていないためです。今回はControlTowerのLandingZoneを東京リージョンで設定したため、東京リージョンのリソースについてはAuditアカウントのアグリゲーターから各アカウントの状況が確認ができます。
Lambda関数
Configの構成変更を検知し、内容をSNSにpublishするためのLambdaが作成されていました。
LambdaとSNSの動きの詳細については、「SNSトピック」の部分で合わせて確認していきます。
SNSトピック
ControlTowerを有効化すると、AuditアカウントにSNSトピックが3つ作成されます。
ユーザーズガイドによると、3つのトピックは全てConfigの通知に関するもののようです。ただ、それぞれのトピックの用途の違いがはっきりと把握できなかったため、SNSトピックごとに各種AWSリソースとの連携を確認してみました。
- ①aws-controltower-AllConfigNotifications
- Auditアカウントのみに作成されるトピック。各アカウントのConfigの設定画面で配信先として設定されている。サブスクリプションはなし。
- ②aws-controltower-SecurityNotifications
- 各アカウントに作成されるトピック。Configの構成変更を監視しているEventBridgeのルール「aws-controltower-ConfigComplianceChangeEventRule（※ControlTowerにより自動設定）」の連携先として指定されている。サブスクリプションとして「aws-controltower-NotificationForwarder（※ControlTowerにより自動作成）」が設定されている。aws-controltower-NotificationForwarderはSNSの内容をAuditアカウントの「aws-controltower-AggregateSecurityNotifications」に連携する関数。
- ③aws-controltower-AggregateSecurityNotifications
- Auditアカウントのみに作成されるトピック。デフォルトの状態だと、サブスクリプションとしてAuditアカウントの管理用メールアドレスが設定されている。ControlTower配下の各アカウント内のLambda「aws-controltower-AggregateSecurityNotifications」からイベントが連携され、構成変更が検知されるとこのSNSトピックからメールが発報される。
整理すると、下記のイメージになります。
各アカウントの構成変更情報はLambda経由でAuditアカウントに集約され、AuditアカウントのSNSトピックから管理者にメールで通知されます。
デフォルトの状態だと、Configで構成変更が検知されるたびにJSON形式のメールがSNSから発報されます。
ControlTowerから発報される通知のJSONサンプル
{
"version": "0",
"id": "6946971b-302e-3555-45a1-a77ce1cbbc9f",
"detail-type": "Config Rules Compliance Change",
"source": "aws.config",
"account": "***",
"time": "2022-02-03T08:47:08Z",
"region": "ap-northeast-1",
"resources": [],
"detail": {
"resourceId": "***",
"awsRegion": "ap-northeast-1",
"awsAccountId": "***",
"configRuleName": "AWSControlTower_AWS-GR_ENCRYPTED_VOLUMES",
"recordVersion": "1.0",
"configRuleARN": "arn:aws:config:ap-northeast-1:***:config-rule/config-rule-bjngbf",
"messageType": "ComplianceChangeNotification",
"newEvaluationResult": {
"evaluationResultIdentifier": {
"evaluationResultQualifier": {
"configRuleName": "AWSControlTower_AWS-GR_ENCRYPTED_VOLUMES",
"resourceType": "AWS::EC2::Volume",
"resourceId": "***"
},
"orderingTimestamp": "2022-02-03T08:46:55.451Z"
},
"complianceType": "NOT_APPLICABLE",
"resultRecordedTime": "2022-02-03T08:47:08.531Z",
"configRuleInvokedTime": "2022-02-03T08:47:08.366Z"
},
"oldEvaluationResult": {
"evaluationResultIdentifier": {
"evaluationResultQualifier": {
"configRuleName": "AWSControlTower_AWS-GR_ENCRYPTED_VOLUMES",
"resourceType": "AWS::EC2::Volume",
"resourceId": "***"
},
"orderingTimestamp": "2021-10-07T03:29:45.041Z"
},
"complianceType": "NON_COMPLIANT",
"resultRecordedTime": "2021-10-07T03:29:50.819Z",
"configRuleInvokedTime": "2021-10-07T03:29:50.655Z"
},
"notificationCreationTime": "2022-02-03T08:47:08.972Z",
"resourceType": "AWS::EC2::Volume"
}
}
ユーザーズガイドにも「AWS Control Tower の SNS トピックは、設計上、非常にノイズが多いものです。たとえば、AWS Config が新しいリソースを検出するたびに、AWS Config から通知が送信されます。」と記載があり、LambdaやEventBridgeで通知のソートや整形を行う手順も紹介されています。実運用の際はConfigからの通知に対してEventBridgeルールを設定する・SNSトピック「aws-controltower-AggregateSecurityNotifications」のサブスクリプションにメッセージの内容を整形するLambdaを指定するなどの追加設定をご検討ください。
Auditアカウントの役割整理
今回はControlTower配下のAuditアカウントに作成されるリソース状況について確認しました。
ここで一旦、Auditアカウントの役割を図で整理します。
AuditアカウントにはConfigアグリゲータが作成されており、ControlTower配下の各アカウントのConfig情報はすべてAuditアカウントに集約されます。
また、ControlTower配下の各アカウントのConfigから発報される構成変更通知も、全てAuditアカウントに集約されています。ControlTowerによって設定される検知的ガードレールはConfigルールにより検知を行う為、ガードレール違反となっているリソースの通知も、Auditアカウントから確認できます。各アカウントの監視を集約する形ですね。
もしGuardDutyやSecurityHubなどを追加する場合は、Auditアカウントを親として設定することを検討してみてはいかがでしょうか。
ここまでお読みくださりありがとうございました。
次回はLogArchiveアカウント側に作成されたリソースについて確認していこうと思います。