こんにちは!クラウド事業部の中根です。
AWS認定のSAPやSCS等で、組織内アカウントのCloudTrailログを1つのアカウントに集約して通知する、みたいな構成をよく見かける気がします。
なんとなくイメージはできるのですが、理解を深めるため、実際にやってみました!
画面キャプチャ多めでお届けするので、実際作業するのはちょっと、、、という方にも参考になれば幸いです!
前提条件
組織構成は以下です。
作り方はこちらの記事で紹介しているので、実際に動かす方は参考にしてください!
続いて、作成する構成のイメージ図です。
1. CloudTrailの設定
組織の管理アカウントに集約するパターンと、組織内のログ用メンバーアカウント(ログアカウント)に集約するパターンがあります。
今回は、ログアカウントに集約するパターンをご紹介します。
組織の管理アカウントに集約するパターンより手順が少し複雑になるので、こちらができれば両パターンに対応できるかと思います。
1-1. CloudTrailの有効化
Organizationsを開き、左メニューから「サービス」を押下します。
一覧から「CloudTrail」を探して、押下します。
「信頼されたアクセスを有効にする」を押下します。
画像だと既に有効になっていますが、最初は無効になっています。
「信頼されたアクセスが有効」になっていることを確認しましょう。
1-2. 委任された管理者を追加
CloudTrailの委任された管理者を設定します。
デフォルトだと、組織のCloudTrail証跡を作成したりするのは、管理アカウントしかできません。
委任された管理者に設定することで、ログアカウントでもそれらの操作が可能になります。
管理アカウントのまま、CloudTrailに移動し、左メニューから「設定」を押下します。
「管理者を登録」を押下します。
ログアカウントのIDを入力して、「管理者を登録」を押下します。
アカウントが追加されていることを確認しましょう。
1-3. ログ集約バケットの作成
ここからは、ログアカウントに切り替えて作業を行います。
S3を開き、「バケットを作成」を押下します。
バケット名を入力し、「バケットを作成」を押下します。
その他はデフォルトのままにしています。
お試しではないなら、暗号化等をしっかり設定しましょう。
1-4. 証跡の作成
CloudTrailの画面を開き、左メニューから、「証跡」を押下します。
「証跡の作成」を押下します。
証跡の設定をして、「次へ」を押下します。
- 証跡名:任意
- 組織内のすべてのアカウントについて有効化:ON
- ストレージの場所:既存の S3 バケットを使用する
- 証跡ログバケット名:作成したログバケット名を入力
- プレフィックス:任意(下に出力例が出ます)
- ログファイルの SSE-KMS 暗号化:任意(実運用ならONですが、お試しだけならOFFがおすすめ)
- ログファイルの検証:任意
- SNS 通知の配信:任意
- CloudWatch Logs:そのままでOK(後述)
ログイベントの選択をして「次へ」を押下します。
今回の手順では、デフォルトの管理イベントだけでOKです。
いろいろ試したいなら、データイベント等をONにすることを検討しましょう。
設定内容を確認して、「証跡の作成」を押下すると、証跡が作成されます。
表示されない場合は、更新してみましょう。
ログバケットを確認してみましょう。
黒く塗ってますが、組織の各アカウントIDでフォルダが分かれています。
(反映までやや時間がかかるかもしれません)
2. CloudWatch Logsの有効化
ログ集約はできましたが、通知機構を作ったり、コンソール上で簡単にログを見られるようにするため、CloudWatch Logsを有効にしてみます。
先ほどの証跡の設定画面では、グレーアウトしていて、設定ができませんでした。
これは、コンソールからは、管理アカウントからでないと有効にできないからです。
管理アカウントのみが、コンソールを使用して組織の証跡の CloudWatch Logs ロググループを設定できます。委任管理者は、 AWS CLIまたは CloudTrail CreateTrail UpdateTrail API オペレーションを使用して Logs CloudWatch ロググループを設定できます。
引用元:https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/creating-an-organizational-trail-in-the-console.html
引用に従い、CLIを使って設定します。
下準備として、ロググループとIAMロールの作成が必要です。
ついでにCLIで作った方がスマートですが、わかりやすさ重視でコンソール操作で解説します。
2-1. ロググループの作成
CloudWatchに移動し、左メニューから「ロググループ」を押下し、「ロググループを作成」を押下します。
ロググループ名を設定し、「作成」を押下します。
ロググループのARNは後で使います。
2-2. IAMロールの作成
IAMに移動し、左メニューから「ポリシー」を押下し、「ポリシーの作成」を押下します。
ポリシーエディタをJSONに切り替え、以下のJSONを張り付けます。(こちらを元に作成)
各値は環境に合わせて修正してください。(管理アカウントIDと委任された管理アカウントIDの違いに注意)
組織のIDは、Organizationsのダッシュボードから確認できます。(下に画像付)
{ "Version": "2012-10-17", "Statement": [ { "Sid": "AWSCloudTrailCreateLogStream20141101", "Effect": "Allow", "Action": [ "logs:CreateLogStream" ], "Resource": [ "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織の管理アカウントID>_CloudTrail_ap-northeast-1*", "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織のID>_*" ] }, { "Sid": "AWSCloudTrailPutLogEvents20141101", "Effect": "Allow", "Action": [ "logs:PutLogEvents" ], "Resource": [ "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織の管理アカウントID>_CloudTrail_ap-northeast-1*", "arn:aws:logs:ap-northeast-1:<委任された管理アカウントID>:log-group:<ロググループ名>:log-stream:<組織のID>_*" ] } ] }
組織のID
ポリシー名をつけて、「ポリシーの作成」を押下します。
続いて、左メニューから「ロール」を押下し、「ロールを作成」を押下します。
「カスタム信頼ポリシー」を選択し、下の欄に下記のJSONを張り付け、「次へ」を押下します。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "Statement1", "Effect": "Allow", "Principal": { "Service": "cloudtrail.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
先ほど作成したポリシーを選択し、「次へ」を押下します。
ロール名をつけて、「ロールを作成」を押下します。
ロールのARNは後で使います。
2-3. 証跡のCloudWatch Logsの有効化
CloudShellでCloudWatch Logsを有効にします。
CloudShellを開き、以下のコマンドを実行します。
aws cloudtrail update-trail \ --name <証跡名> \ --cloud-watch-logs-log-group-arn <ロググループのARN> \ --cloud-watch-logs-role-arn <IAMロールのARN>
「An error occurred (TrailNotFoundException) when calling the UpdateTrail operation: Unknown trail」というエラーになってしまった場合、以下のコマンドを実行します。
aws cloudtrail describe-trails
出力された証跡情報のTrailARNを、<証跡名>に置き換えて再度実行します。
他のエラーが出た場合は、エラーメッセージを読んで、コマンドの各ARNや、IAMポリシーのResourceが正しいかを確認しましょう。
私はIAMポリシーのResourceに謎のコロンが入っていて、ハマりました。。。(InvalidCloudWatchLogsLogGroupArnExceptionのAccess Denied)
CloudTrailのイベント履歴から、より詳細な情報を拾うこともできます。
成功すると、証跡のロググループとIAMロールが設定できたことが確認できます。
CloudWatch Logsのロググループを確認すると、各アカウントのログストリームができていることが確認できます。
<組織ID><アカウントID>CloudTrail~という形式になっています。
2-4. 動作確認
せっかくなので、他のアカウントでのイベントがCloudWatch Logsから見れることも確認してみます。
別のメンバーアカウントに切り替え、S3バケットを作成します。
バケットを作成しました。
ログアカウントに戻ります。
作業をしたアカウントのログストリームを見てみます。
検索窓に「CreateBucket」と入力すると、S3バケットを作成した時のログが出力されています。
出てこない場合は、少し待つか(15分以内には連携されるはず)、他のログストリームも確認してください。
今回はここまでにしますが、メトリクスフィルターを使った通知や、サブスクリプションフィルターを使ったLambda呼び出しなど、いろいろ試してみてください!
3. お掃除
動作確認したアカウント
動作確認で使ったS3バケットを削除します。
ログアカウント
CloudTrailの画面を開き、左メニューから「証跡」を選択します。
作成した証跡を選択し、「削除」を押下します。
S3で、ログバケットを空にしてから、削除します。
CloudWatchのロググループも削除します。
作成したIAMロールとIAMポリシーも削除します。
ログバケットを作成した時など、KMSキーを作成していた場合は、KMSキーの削除も忘れずにしましょう。
管理アカウント
任意ですが、委任された管理アカウントの削除がしたい場合は、管理アカウントから行ってください。
まとめ
今回は、AWS認定試験でよく見る構成を実際に試してみました。
コンソールからだと有効化できなかったり、IAMポリシーの設定で少しハマったりと、地味な苦戦ポイントがあって勉強になりました!
皆様の参考になれば幸いです!
お知らせ
APCはAWS Advanced Tier Services(アドバンストティアサービスパートナー)認定を受けております。
その中で私達クラウド事業部はAWSなどのクラウド技術を活用したSI/SESのご支援をしております。
www.ap-com.co.jp
https://www.ap-com.co.jp/service/utilize-aws/
また、一緒に働いていただける仲間も募集中です!
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。