はじめに
結論を先に書くと、AWSの バージニア北部リージョン(us-east-1) のことも忘れないでください、という話です。
もし東京リージョンしか使っていなくても、大阪リージョンしか使っていなくても、です。
IAMポリシーによって突然動かなくなるジョブ
AWSでは、IAMユーザーやIAMユーザーグループを最初に作成した後も、利用するサービスの変化や人の役割の変化に応じて、権限を編集することがしばしばあります。
自分がIAMの全てを管理していればいいのですが、他チームの人と共同で管理するケースがあります。
許可(Allow) を含むIAMポリシーがユーザー／ユーザーグループから削除されると、その対象のユーザーの操作が制限されて、できることが減ってしまいますし、反対に 拒否(Deny) を含むIAMポリシーを追加で割り当ててても、できることが減ってしまいます。
拒否(Deny)は強いですからね。
参考: AWSガイド - Identity and Access Management - ポリシーの評価論理
DenyによってIAMユーザーのCLIが失敗してしまい、そのCLIを含んだ業務ジョブが突然動かなくなったりもします。
ジョブが止まった原因を調べて、誰かによってIAMポリシーが変更されていることに気付くのです。
↓↓ その時の気持ちはこれ ↓↓
マネージメントコンソールで犯人探し
まずは急いでIAMポリシーを修正対応して、ジョブは無事に動きました。
そして次に、犯人探しです。
使うサービスは、そう、CloudTrail ですね。
CloudTrail ＞ イベント履歴 を選択
IAMとは無関係の大量のログが表示されますので、絞り込みが必要です。
イベントソースを見ると xxx.amazonaws.com の形式です。IAM なら、iam.amazonaws.com なので、これで絞ってみましょう。
フィルター：イベントソース=iam.amazonaws.com
おや、フィルターしたら結果が出なくなりました。おかしい。
確か最近、IAMユーザーを作ったことがあったはず。IAMユーザー作成は、イベント名 が CreateUser なので、これでフィルターしてみましょう。
フィルター：イベント名=CreateUser
あれれ、おかしい、これも出てこない。
IAMユーザーの操作の履歴ってCloudTrailに記録されないんだなぁ、、という勘違いをする人が多いようです。（近くの席に座っている同僚もそうでした）
原因
最初に結論を書いたので、分かりますね。
米国東部（バージニア北部）：us-east-1 リージョンを選びましょう。
解決
リージョン=us-east-1
フィルター：イベントソース=iam.amazonaws.com
はい、出てきました。
これでポリシーを変更した犯人が特定できますね！
でも疑問が
なんでアメリカを選ばなあかんの？ ここ日本やで？
そう思いますよね。
どうやらIAMは特殊なサービスで、IAMのコントロールプレーンと呼ばれるものは us-east-1 にあって、各リージョンはデータプレーンに該当するとのこと。
参考:
DevelopersIO - AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在しその設定内容は各リージョンのデータプレーンに伝播される
その関係で、イベント履歴はコントロールプレーンである us-east-1 でのみ参照できるということなのでしょう。
（各リージョンで見る設定があるかもしれませんが）少なくともデフォルト設定では、IAMのイベント履歴は us-east-1 に切り替えてから見ましょう。
早く気づくために
やり方として2つぐらいあります。
- 定期的にListUsers, ListGroups, ListPolicies, ListRoles 等の各APIを実行し、前回との差分情報をチェックするLambda関数を実装する。
- IAMの変更をEventBridgeで拾ってSNS通知（メールとかSlackとか）をする。
まあ普通に考えれば後者ですね。
後者のやり方は、AWSのドキュメントにあります。ちなみに、ここに思いっきり EventBridgeルールは米国東部 (バージニア北部) リージョンに という注意点が書いてました。
前者の場合は、そこそこのコード記述量が必要です。
が、Lambda + python(boto3) 大好き人間の自分は、トリガーは後者(us-east1 EventBridge)、後続は前者(ap-northeast-1 Lambda)、の方法でやるんですけどね。
https://qiita.com/hayayu0/items/8f4a8cca9b35143699d9