AWSでマルチアカウント環境を実装してみた（③CloudTrail編）

# はじめに
前回記載した概要編、Organizations編の続きとなります。今回はCloudTrailを有効化して、セキュリティアカウントにログを収集するところまでを書きます。
※前回記事はこちらを参照ください

https://qiita.com/hiro-tech/items/b9f88efe542ac534637e

https://qiita.com/hiro-tech/items/d7ebd7783e7fbfbc5cbb


# 全体構成
概要図はこんな感じです。Organizations内に複数のアカウントがありますが、これらメンバーアカウントで生成されたCloudTrailnoログを、セキュリティアカウント内のS3バケットに集約して保存する形になります。
![構成図v2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/500bb51c-bc1b-636f-6623-d6a18b9e52b4.png)


# 対応手順
以下、対応手順を記載します。Organizationsコンソールは現時点では画面デザインが新しいものと古いものの両方を使えますが、今回は新しい方を使っていきます。

## ログ集約用のS3バケット作成
メンバーアカウント（セキュリティアカウント）での操作となります。まずは今回必要になるS3バケットを作成します。コンソールからポチポチするだけなので詳細は割愛しますが、バケットポリシーは以下の通り設定ください。

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck20150319",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::バケット名"
        },
        {
            "Sid": "AWSCloudTrailWrite20150319",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::バケット名/AWSLogs/管理アカウントID/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        },
        {
            "Sid": "AWSCloudTrailWrite20150319",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::バケット名/AWSLogs/組織ID/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}
```
上記ポリシー内の置き換え文字は以下の通りです。

- バケット名：今回作成するバケットの名前
- 管理アカウントID：Organizatinsの管理アカウントのIDを指定。例）123456789
- 組織ID：Orgenizationsを有効化した際に割り当てられるID。Organizationコンソールから確認可能。


## 管理アカウントでのCloudTrail有効化
ここから先は管理アカウントで操作を行います。上に記載した通り、Organizaitonsでは新旧デザインのコンソール画面が使えます。旧コンソールの場合、CloudTrailの有効化はOraganizations画面から行えましたが、新コンソールで同じ操作を行おうとすると以下の警告メッセージが表示されます。少なくとも2021年3月現在はCloudTrailコンソールから設定を行うことが推奨されているようなので、今回の手順でもこれに従います。
![010.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/4955bcaa-63f2-108d-1979-b4bd04fc1434.png)



というわけで管理アカウントでCloudTrailのコンソールを開きます。画面内の「証跡の作成」をクリックします。
![020.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/618e8d81-e3a7-21cd-4bf3-c7477cec2cb5.png)



必要な情報を入力して「次へ」をクリックします。「組織内の全てのアカウントについて有効化」がポイントです。必ずチェックしましょう。
ストレージの場所は「既存のS3バケットを使用する」を選び、先ほど作成したS3バケット名を指定します。SSE-KMSの有効化は任意ですが、セキュリティが向上するのでONにしておいた方がいいと思います。
![030.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/cb640c49-c75f-7334-95e4-5ae708537247.png)




次の画面はデフォルトのまま、管理イベントのみ取得するようにしました。このあたりは運用の要件に応じて随時見直してください。設定したら「次へ」をクリックします。
![040.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/9d9a8c5e-ea6e-6b6e-4aab-896e43d03966.png)



続いて確認画面が表示されるので、「証跡の作成」ボタンをクリックします。無事作成されると以下の画面が表示されます。
![050.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/697408bc-d88d-7c43-5145-d6d33a73cafb.png)



Organizations側の設定も確認してみます。左メニューから「サービス」を開くと、CloudTrailの「信頼されたアクセス」が有効になっているのが分かります。
このように、新しコンソールでは各サービス側でOrganizationsのサービスを有効化する手順に変更になっているようです。
![060.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/73be5782-10c7-9510-a501-a57b6c7c4640.png)



メンバーアカウント（セキュリティアカウント）のS3バケットも確認してみます。下記の通り、正しくログ出力が行われることが確認できました。
※メンバアカウントにスイッチして確認してください
![070.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1234157/afed8f1a-9ffa-e824-8d4e-9727d043f5dc.png)




# 最後に
今回はCloudTrailの有効化方法を説明しました。バケットはメンバーアカウントのものを使用していますが、CloudWatchなどでイベント処理を行う場合は、管理アカウント側で設定を行う必要がありますのでご注意ください。
AWS ConfigやGuardDutyはメンバーへの委任機能があるので、CloudTrailでも同様なことができるようアップデートに期待しています。

今回の記事が誰かのお役に立てると幸いです。