CTO室の@ken5scal (鈴木）です。
2021/04/08にAWS IAM Access Analyzerの新機能として、CloudTrailのログをもとにIAM Roleのポリシーを生成するリリースが発表されました。
ところで、やはりというべきか、さすがというべきか、すでにクラスメソッドさんからブログがリリースされています。
しかしながら、statementの単位でｳﾝｳﾝ唸ったり、下手なポリシーをつけて撃ち抜いた足の数など数え切れない一介のIAMマンとしては、歓喜をもってこのリリースを迎えざるを得ません。その昂りは、ブログネタ被りの羞恥心など容易に吹き飛ばすほどのものです。というわけで、早速、今回のリリースについて書いていこうとおもいます。
IAM運用のつらみ
Identity is new perimeterといわれ、早10年弱。セキュリティの一番一丁目であるIAMを確実に運用するのは重要です。
最小権限の原則はその最たるものですが、果たして声を大にして、原則に沿った運用をしている！といえる組織はどれほどあるしょうか。
その原則は全くもって正論ですが、AWS Serviceの数 x Serviceに紐づくActionの数 x Effectの数 ✕ Conditionの数をすべて把握するには大きな労力を要し、Resourceを “*” にしない等にとどまってる方も多いのではないでしょうか。
最近はConftestなどの登場でテストが可能になってきてはいるものの、基本的にはAWSにデプロイしないと結果はわかりません。 特に、CodeDeployなど暗黙的に複数のサービスを利用したりしている場合もあり、一層、デプロイ前の設計・実装を難しくしています。
このような事情もある中で、公式自体がある意味、最小権限ではないManaged Policyの利用を推奨をしています。
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
そのため、多くの方はまずはManaged Policyの利用あるいはザックリしたIAM Policyを設定して、それからIAMのAccess AdviserやCloudTrailの集計といった実績から逆算する地道な努力をして、徐々に権限を絞っている方が多かったのではないかと思われます。
この労力をはらってくれるのが、今回リリースされた「IAM Access Analyzer - Policy Generation」です。
IAM Access Analyzer - Policy Generationの現在
次の画面は実際につかって表示された画面です。
もし、調査対象のRole/Userにアタッチされたサービスが、Policy with action-level informationに含まれていれば、実際に利用されたサービスとアクションの組み合わせまで表示してくれます。上記の例でいうと、KMSです。この場合、実際に使われていたActionはDecryptのみであったことがわかります。おかげで、Describe Key Actionを除外することができました。うーん、最高。AWS大好き。
しかし、まだまだリリースさればかりのサービスですので、ちょいちょいと制限があります。例えば、公式のドキュメントにもある通り、ポリシー生成に使われるCloudTrailのログのファイル数およびデータ量、並列実行数、一日最大実行数などです。また、現時点ではクロスアカウントのCloudTrailはできないとの記述もあります。詳しくはクオータに関するドキュメントを御覧ください。
IAM and STS quotas - AWS Identity and Access Management
↑色々ためして、出力されたエラー
処理もそこまで早いわけではなく、90日間のタイムレンジを指定したポリシー生成には約20minほどかかりました。また、当然ですが、Iam:PassRoleのようなCloudTrailに記録されないものは自分たちでよしなに対応せねばなりません。同時に、ABACとの相性もあまりよくないのではないかな、という気がします。
というわけで、まだ実運用でバリバリ使うにはつらそうですが、とはいえ、APIがすでに用意されているなど、今後の改善に疑いの余地はありません。 処理パフォーマンスやキャパシティが広がった場合、IAM運用は大きく変わるでしょう。今まで DSLなどで静的に管理していたInline PolicyやIAM Policyを、より自動化・動的なやり方で管理せねばなりませんが、設計と運用を今から妄想するのが楽しみです。
一旦、今日はこの辺で。
