はじめに
本記事は プロもくチャット Adevent Calendar 2023 の 22 日目です！！
この記事のゴール
-
AWS S3に新規バケットが作成された時、通知を受け取ることができるようになります。 -
AWS CloudTrailにより証跡情報を監視することができるようになります。 -
Amazon CloudWatchでカスタムメトリクスを作成できるようになります。 -
Amazon CloudWatch Alermを作成できるようになります。
背景
AWS のリソースを扱うハンズオンを実施していると、いつの間にか S3 バケットが作成されていることがあり、後々「何のためのバケットなのかわからなくなる」という事態に直面しました。
これを回避するため、S3 バケットが新規作成されたら僕のメールアドレスに通知されるようにしたいと考えた次第です。
なお、通知を受け取るだけでは根本的な回避策にはならないため、今後実装を深掘りしたいと考えています。（「今後の展望」を参照のこと）
前提条件
- 利用端末 :
MacBook AirApple M1macOS Sonoma 14.2 - AWS アカウントにて、 IAM ユーザーを作成済み
もしまだ IAM ユーザーを作成されていない方は、こちらの記事を参照ください（宣伝🙄）
Notion の利用情報を Slack に定期送信したいんだ！ - AWS CDK, Amazon EventBridge, AWS Lambda でつくるバッチ処理アプリケーション -
やることサマリ
-
AWS CloudTrailにて AWS アカウントのアクティビティを監視する証跡を作成 - 証跡情報を記録するロググループにて、S3 バケットの作成イベントを監視するカスタムメトリクスを作成
- カスタムメトリクスをもとに SNS トピックをトリガーする
CloudWatch Alermを作成 - 動作確認
手順詳細
1. AWS CloudTrail にて AWS アカウントのアクティビティを監視する証跡を作成
公式ドキュメントはこちら。
1. 「証跡」をクリック
今回は東京リージョンで作成します。
2. 「証跡の作成」をクリック
3. 「証跡名」を入力
今回、チェックボックス「組織内のすべてのアカウントについて有効化」は選択しません。
複数の AWS アカウントを横断して証跡情報を監視したいわけではないので。
4. 証跡ログを保存するバケットを選択
今回は本記事のためのバケットを新規作成しました。
もちろん、既存の S3 バケットを使用することもできます。
ただ、既存のバケットを使用する場合、当該バケットのバケットポリシーを編集して、AWS CloudTrail のアクセスを許可する必要があると思います。
そのため、変に躓きたくなければ新しくバケットを作成してしまうのが無難かと思います。
僕の勘違いだったらすみません。。
多分ここで一回躓いたので、合っていると思うのですが。
指摘等ございましたらコメント頂けますと幸いです。
5. ログファイルの暗号化を設定
S3 バケットに保存されるログファイルの暗号化設定を指定します。
今回は暗号化を有効に設定しました。
その場合は暗号化に利用する KMS キーを指定する必要があります。
今回は本記事のために「cloudtrail-logs-qiita-tutorial」というキーを新規作成するようにしています。
もちろん、既存の KMS キーを指定することも可能です。
ただ、S3 バケットと同様に、AWS CloudTrail が KMS キーを利用できるようキーポリシーを編集する必要があると思います。
そのため、変に躓きたくなければ新しく KMS キーをさくs..(省略)
6. AWS CloudWatch Logs の指定
チェックボックス「有効」を選択し、CloudWatch Logs を有効にします。
7. 本証跡のために利用するロググループを設定
本証跡でキャプチャされた情報を記録するロググループを指定します。
今回は「aws-cloudtrail-logs-qiita-tutorial」という新規ロググループを指定しました。
もちろん、既存のロググループを指定することもできます。
今回は既存のロググループでも躓くことはないと思っているのですが、試してはいません🫣
なお、許可設定はこの後の IAM ロール設定で実施するため、そこで躓く可能性があるのではないかと考えています。
8. AWS CloudTrail にアタッチする IAM ロールを設定
ここでも既存の IAM ロールを使用することができます。
ただ、信頼ポリシーと IAM ポリシーが適切に設定されていることを確認する必要があります。
そのため、変に躓きたくなけれb..(省略)
9. ベージ最下部の「次へ」をクリック
10. 監視するログイベントを選択
S3 バケットの新規作成イベントを監視するためには、「管理イベント」を選択する必要があります。
今回は当該イベント監視専用の証跡を作成する想定で、「管理イベント」のみ選択しました。
11. 記録する API アクティビティを選択
S3 バケットの新規作成イベントを監視するためには、「書き込み」を選択する必要があります。
(S3 バケットの新規作成が「書き込み」イベントであることは後々確認できます！）
なお、 AWS KMS イベント、Amazon RDS イベントは今回必要ないので除外設定を選択しました。
AWS CloudTrail によって記録される Amazon S3 のバケットレベルのイベントはこちらを参照。
CloudTrail ログ記録によって追跡される Amazon S3 バケットレベルのアクション
12. ページ最下部にて「次へ」をクリック
13. 確認画面にて「証跡の作成」をクリック
2. 証跡情報を記録するロググループにて、S3 バケットの作成イベントを監視するカスタムメトリクスを作成
1. Amazon CloudWatch にて「ロググループ」をクリック
2. 今回作成したロググループ「aws-cloudtrail-logs-qiita-tutorial」をクリック
3. 画面右上の「アクション」ボタンから、「メトリクスフィルターを作成」をクリック
4. 「フィルターパターン」に下記パターンを入力
{ ($.eventName = "CreateBucket") }
フィルターパターンで利用できる構文は下記公式ドキュメントを参照。
上記構文は「Match terms in JSON log events using simple expressions」の項目を参照。
5. ページ下部にある「Next」をクリック。
ここだけいきなり英語なんですよね笑
毎回こうなります🫢
6. フィルター名を入力
7. メトリクスの詳細情報を設定
設定項目の情報はこちらの公式ドキュメントを参照
-
メトリクス名前空間
メトリクスを分類する名称？という認識です。
正直、あまり詳しく理解していないです。。 -
メトリクス名
本メトリクス単体を識別する名称？という認識です。
正直、こちらもあまり理解していないです。。。 -
メトリクス値
フィルターパターンによって監視しているアクション（今回は S3 バケットの新規作成）が発生した際にメトリクスへ配信される数値です。
今回「1」を設定したため、S3 バケットが新規作成されるために1ずつインクリメントされることになります。 -
デフォルト値（オプション）
フィルターパターンによって監視しているアクションが発生していない時にメトリクスへ配信される数値です。 -
Unit(オプション）
「メトリクス値」「デフォルト値」の単位です。
今回は「カウント」を設定しました。
上記、さも理解しているように記載しましたが、正直あまり自信がありません😮💨
ぜひコメント等でご指摘いただけますと幸いです。
色々とカスタムメトリクスを作成しだすと、この項目の恩恵を理解ですんですかね〜
8. ページ下部の「Next」をクリック
9. 設定した内容を確認し、「メトリクスフィルターを作成」をクリック
(補足) S3 バケットの新規作成イベントを確認する
S3 バケットの新規作成イベントの詳細情報を AWS CloudTrail で確認してみようと思います。
1. Amazon S3 にて適当なバケットを作成
2. AWS CloudTrailにて「イベント履歴」をクリック
3. 「CreateBucket」をクリック
4. 表示された詳細画面にて、イベントレコードを確認
表示されている内容を抜粋した�ものを以下に示します。
{
"eventVersion": "1.09",
"userIdentity": {
"type": "IAMUser",
"principalId": "hogehoge",
"arn": "hogehoge",
"accountId": "hogehoge",
"accessKeyId": "hogehoge",
"userName": "hogehoge",
"sessionContext": {
"attributes": {
"creationDate": "2023-12-21T11:30:05Z",
"mfaAuthenticated": "true"
}
}
},
"eventTime": "2023-12-21T11:35:14Z",
"eventSource": "s3.amazonaws.com",
"eventName": "CreateBucket",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "hogehoge",
// 中略
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "hogehoge",
"vpcEndpointId": "hogehoge",
"eventCategory": "Management",
// 省略
}
すべて記載するとセキュリティ面で良くないかと思い、省略等行なっています。
確認していただきたいのは下記 3 箇所です。
"eventName": "CreateBucket"
"readOnly": false
"managementEvent": true
CreateBuketというイベントが、「管理イベント」かつ「書き込み」であることを読み取ることができます。
3. カスタムメトリクスをもとに SNS トピックをトリガーする CloudWatch Alerm を作成
1. 作成したロググループにて、「メトリクスフィルター」タグをクリック
2. 今回作成したカスタムメトリクスをクリックし選択
3. 「アラームの作成」をクリック
4. 「統計」と「期間」を設定
収集したい統計情報の種別と期間を設定します。
今回は「合計」「1分」に設定しました。
バケットが新規作成される度に本アラームを「アラーム状態」にしたいのですが、ベストな方法がわかりませんでした
5. 「条件」を指定
現在、デフォルト値は「0」、S3 バケットが作成されると1ずつインクリメントされるようにメトリクスを設定しているため、メトリクス値が「0」以上になった時に本アラームが「アラーム状態」になるよう設定したいと思います。
6. ページ下部の「次へ」をクリック
7. 「アラーム状態のトリガー」で「アラーム状態」を選択
指定したメトリクス条件を満たした際に本アラームが「アラーム状態」となるよう、「アラーム状態」を選択しました。
8. 本アラームが「アラーム状態」となった際に通知を送る SNS トピックを設定
今回、すでに僕が利用している既存の SNS トピックを指定しました。
まだ用意されていない場合は「新しいトピックの作成」にて新規トピックを作成してください。
もし新規トピックを作成した場合、トピックに登録したメールアドレスを認証する必要があります。
トピックを作成し、サブスクリプションにメールアドレスを登録したタイミングで認証用メールが届くなずなので、認証を済ませるようにしましょう。
9. ページ下部にて「次へ」をクリック
10. アラーム名を入力
11. ページ下部にて「次へ」をクリック
12. ページ下部にて「アラームの作成」をクリック
4. 動作確認
実際に通知が来るか確認します。
任意のリージョンにて S3 バケットを新規作成してみましょう。
1, 2分後、 SNS トピックに登録したメールアドレスに通知が来ることと思います。
なお、AWS CloudTrail のコンソール画面で証跡を作成した場合、各種イベントの監視範囲は全リージョンとなるそうです。
つまり、バージニア北部にて S3 バケットを作成しても、東京リージョンで作成した証跡がそのイベントを監視してくれるということです。
今後の展望
上記内容により、「S3 バケットがいつの間にか作成されている」という事態は回避できるようになりました。
ただ、現状新規作成に気づけるようになっただけ、というのが正直なところです。
今後は、「通知メールのボタンをクリックすると、当該バケットにオブジェクトロックをかける」ような処理を実装したいなと考えています！