あけましておめでとうございます。2021年1つ目のブログは、Organizationsシリーズ第三弾です。今回はCloudTrailです。
Organizationsの紹介（はじめに編）はコチラ
前回はコチラ
CloudTrailとは
AWS上の操作履歴を保存し、可視化できるサービスです。デフォルト状態で、特に何もしなくても過去90日分は操作履歴を確認できます。追加で証跡という設定を行うことで、すべての操作履歴をS3バケットに保存して確認できるようになります。
シングルアカウントの場合、当たり前ですが有効にすると自アカウントの操作証跡が指定したS3バケットに保存されます。
Organizationsを使用した証跡の有効
Organizationsを使用すると、組織内のすべてのアカウントに対してCloudTrailの証跡を有効にして、指定したS3バケットにすべてのアカウントの証跡が保存されます。
なお、現時点でCloudTrailはアカウントの委任機能に対応していないため、組織単位の証跡有効および保存先の設定はマネジメントアカウントで実行する必要があります。
設定方法
実際の設定方法は簡単です。CloudTrailの証跡を有効化する際に、「組織内のすべてのアカウントについて有効化」にチェックを入れればOKです。その他の設定項目はシングルアカウントの設定時と同様のため詳細手順は割愛します。基本は画面のとおり進めていけばOKです。
作成が完了すると、以下のように組織の証跡が「はい」の状態で表示されます。
連結（メンバー）アカウントからの見え方
Organization配下の連結アカウントからCloudTrailの証跡を見ると、マネジメントアカウントと同じように証跡が設定されています。
ただし、証跡の削除や設定変更ができない旨も合わせて表示されます。強制的にマネジメントアカウントによって証跡が残るのは良いですね。
S3バケット内の証跡ファイルを確認しようとすると、以下のようにエラーとなります。これはバケットポリシーでマネジメントアカウント外のアカウントから許可がされていないためです。
連結アカウントから自アカウントの証跡を確認するためには、別途追加の設定が必要になります。方法はいくつかあるため後ほど考察してみます。
ひとまず、全アカウントでの証跡強制有効、マネジメントアカウントでの一元管理ができました。
監査アカウント上のバケットに保存
マネジメントアカウント上のS3バケットではなく、ログやセキュリティ情報を格納する監査（audit）アカウントのS3バケットにCloudTrailの証跡を集約してみます。
まず、監査アカウントにログインしてS3バケットを作成します。名前以外はデフォルトで設定しておきます。
今回はバケット名に「202012cloudtrail-audit-organization」という名前を設定しています。
アクセス許可のタブに移動し、
バケットポリシーを編集します。
ポリシーは以下のとおり設定します。マネジメントアカウントで証跡有効をした際に自動設定されたバケットポリシーを参考にしています。
※[ManagementAccountID]と[OrganizationID]は置き換えが必要です。OrganizationIDは、Organizations>アカウントの整理画面で右側のARN情報に見える、「o-」で始まる文字列です。
※バケット名は今回「202012cloudtrail-audit-organization」としているのでそのまま記載していますが、ここも実環境に応じて変更が必要です。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AWSCloudTrailAclCheck20150319",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:GetBucketAcl",
"Resource": "arn:aws:s3:::202012cloudtrail-audit-organization"
},
{
"Sid": "AWSCloudTrailWrite20150319",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::202012cloudtrail-audit-organization/AWSLogs/[ManagementAccountID]/*",
"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:::202012cloudtrail-audit-organization/AWSLogs/[OrganizationID]/*",
"Condition": {
"StringEquals": {
"s3:x-amz-acl": "bucket-owner-full-control"
}
}
}
]
}
バケットポリシーの設定が完了したら、マネジメントアカウントに戻ります。
※アカウントを行ったり来たりするので間違えないように注意です。
先ほどの手順と同じく、組織のCloudTrail証跡を作成します。
このとき、バケット名に先ほど監査アカウントで作成したバケット名「202012cloudtrail-audit-organization」を既存のバケットとして指定します。
作成が完了すると以下のようにauditと名前のついた証跡が作成されていることが確認できます。比較用に先ほどマネジメントアカウント上で作成した証跡も残しています。
以下のように、監査アカウントにCloudTrail証跡を集約することができました。バケット内のオブジェクトは、監査アカウント内からしか見えません。マネジメントアカウントからも見えなくなります。
CloudTrailはサービスとしてアカウントの委任機能に未対応ですが、このようにバケットを意図的に他アカウントに指定することで委任のような設定を行うことができます。
他アカウントでの証跡の確認方法
1アカウントに証跡を集約できましたが、集約されたアカウント以外はS3バケット内の証跡を確認できませんでした。これを確認できるようにするにはどうすれば良いでしょうか。いくつか考えてみます。
1. 証跡確認用IAMロールを作成する
これはAWSの公式ドキュメントにも記載のある方法です。図もそこから引用させてもらいます。
集約されたアカウントにIAMロールを作成し、そのロールに別アカウントからスイッチしてくるという運用ですね。
アカウントが増えるたびに、専用のロールも合わせて作成する必要があります。
2. バケットポリシーを変更する
集約されたS3バケットのバケットポリシーで他アカウントからのs3:GetObjectとs3:ListBucketを許可すれば参照が可能です。アカウントIDで許可する必要があるため、こちらもアカウントが増えるたびにバケットポリシーの変更が必要になります。
もしくは、組織内全体でログが確認できてOK（自分のアカウント以外のログが見えてもOK）であれば、OrganizationのIDを指定してアクセス許可することも可能です。
運用ポリシーとして全てのログが見えてOKであれば、おススメの設定です。
具体的には以下のようにバケットポリシーに追加すればOKです。
※Statementの1ブロックを抜粋しています
※[OrganizationID]にはご自身のOrganizationID（o-で始まる文字列）の入力が必要です。バケット名も環境に合わせて修正してください
{
"Sid": "FromOrganization",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::202012cloudtrail-audit-organization",
"arn:aws:s3:::202012cloudtrail-audit-organization/*"
],
"Condition": {
"StringEquals": {
"aws:PrincipalOrgID": "[OrganizationID]"
}
}
},
設定が完了すると組織内のすべてのアカウントから以下のようにS3内のオブジェクトが確認できます。
3. 各アカウントごとに証跡を作成する
CloudTrailの証跡は複数作成できるので、組織設定で全体として取得しつつ、各アカウントごとに単独で設定することも可能です。
こうすることで、各アカウント内で自分のアカウントのみ証跡を確認できるといった運用も可能です。
証跡が重複して作成されますので、S3の料金が多くなる点には注意が必要です。個人的には、S3の料金は高くないので大きく気にするほどでもないかと思います。
アカウント単位の設定が必要にもなりますが、これはCloudFormationのStaclSetsを活用することでアカウント作成時に自動化することも可能です。
アカウント単独で証跡の運用が必要な場合は、おススメな構成です。
他アカウントからの参照方法は以上３パターンです。どれにするかは私としても悩みどころですが、マッチするパターンがあれば幸いです。
さいごに
セキュリティおよび監査要件ではとても重要であるCloudTrail。証跡機能は基本的に有効化するものとして、それをどう運用していくか検討が必要ですね。
特にマルチアカウントになった場合は一元管理の方法も要検討です。
今回はS3に集約するところまで確認しましたが、実際の運用ではAmazon Athenaなどを使用して、可視化を行って運用していく必要があります。
今回はここまで。次回はConfigの予定です。
次回はコチラ
