AWSのIAMの操作履歴がCloudTrailで表示されない

# はじめに

結論を先に書くと、AWSの **バージニア北部リージョン(us-east-1)** のことも忘れないでください、という話です。

もし東京リージョンしか使っていなくても、大阪リージョンしか使っていなくても、です。

# IAMポリシーによって突然動かなくなるジョブ

AWSでは、IAMユーザーやIAMユーザーグループを最初に作成した後も、利用するサービスの変化や人の役割の変化に応じて、権限を編集することがしばしばあります。

自分がIAMの全てを管理していればいいのですが、他チームの人と共同で管理するケースがあります。

**許可(Allow)** を含むIAMポリシーがユーザー／ユーザーグループから削除されると、その対象のユーザーの操作が制限されて、できることが減ってしまいますし、反対に **拒否(Deny)** を含むIAMポリシーを追加で割り当ててても、できることが減ってしまいます。
拒否(Deny)は強いですからね。
参考:　[AWSガイド - Identity and Access Management - ポリシーの評価論理](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_evaluation-logic.html#AccessPolicyLanguage_Interplay)

DenyによってIAMユーザーのCLIが失敗してしまい、そのCLIを含んだ業務ジョブが突然動かなくなったりもします。
ジョブが止まった原因を調べて、誰かによってIAMポリシーが変更されていることに気付くのです。


↓↓ その時の気持ちはこれ ↓↓

![iam_yuuzan2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/3fab3b7d-bcce-d01e-5104-1867e92978e9.png)


# マネージメントコンソールで犯人探し

まずは急いでIAMポリシーを修正対応して、ジョブは無事に動きました。
そして次に、犯人探しです。

使うサービスは、そう、**CloudTrail** ですね。

```CloudTrail ＞ イベント履歴``` を選択

![iam_3_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/d071f992-55d8-9c20-89e5-d33d1e809c86.png)

IAMとは無関係の大量のログが表示されますので、絞り込みが必要です。

イベントソースを見ると xxx.amazonaws.com の形式です。IAM なら、```iam.amazonaws.com``` なので、これで絞ってみましょう。

フィルター：イベントソース=iam.amazonaws.com
![iam_2_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/ccb42423-3ac4-7ac5-0f2a-d5c667288762.png)

おや、フィルターしたら結果が出なくなりました。おかしい。

確か最近、IAMユーザーを作ったことがあったはず。IAMユーザー作成は、イベント名 が ```CreateUser``` なので、これでフィルターしてみましょう。

フィルター：イベント名=CreateUser
![iam_1_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/18b9e5fb-767d-f4ab-884c-27716c9cc7e2.png)

あれれ、おかしい、これも出てこない。

IAMユーザーの操作の履歴ってCloudTrailに記録されないんだなぁ、、という勘違いをする人が多いようです。（近くの席に座っている同僚もそうでした）

# 原因

最初に結論を書いたので、分かりますね。

![iam_4_2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/a958d933-82ef-8079-9051-32fbcd5db9de.png)

米国東部（バージニア北部）：**us-east-1** リージョンを選びましょう。

# 解決

リージョン=us-east-1
フィルター：イベントソース=iam.amazonaws.com
![iam_5_1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/204490/502bc0ad-9df1-9560-867d-52a607556367.png)

はい、出てきました。

これでポリシーを変更した犯人が特定できますね！

## でも疑問が

> なんでアメリカを選ばなあかんの？　ここ日本やで？

そう思いますよね。
どうやらIAMは特殊なサービスで、IAMの```コントロールプレーン```と呼ばれるものは us-east-1 にあって、各リージョンは```データプレーン```に該当するとのこと。
参考:
[DevelopersIO - AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在しその設定内容は各リージョンのデータプレーンに伝播される](https://dev.classmethod.jp/articles/aws-iam-controlplane-dataplane/)

その関係で、イベント履歴はコントロールプレーンである us-east-1 でのみ参照できるということなのでしょう。
（各リージョンで見る設定があるかもしれませんが）少なくともデフォルト設定では、IAMのイベント履歴は **us-east-1** に切り替えてから見ましょう。

# 早く気づくために

やり方として2つぐらいあります。

- 定期的にListUsers, ListGroups, ListPolicies, ListRoles 等の各APIを実行し、前回との差分情報をチェックするLambda関数を実装する。
- IAMの変更をEventBridgeで拾ってSNS通知（メールとかSlackとか）をする。

まあ普通に考えれば後者ですね。
後者のやり方は、[AWSのドキュメント](https://aws.amazon.com/jp/premiumsupport/knowledge-center/iam-eventbridge-sns-rule/
)にあります。ちなみに、ここに思いっきり **EventBridgeルールは米国東部 (バージニア北部) リージョンに** という注意点が書いてました。

前者の場合は、そこそこのコード記述量が必要です。
が、Lambda + python(boto3) 大好き人間の自分は、トリガーは後者(us-east1 EventBridge)、後続は前者(ap-northeast-1 Lambda)、の方法でやるんですけどね。
https://qiita.com/hayayu0/items/8f4a8cca9b35143699d9