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を、より自動化・動的なやり方で管理せねばなりませんが、設計と運用を今から妄想するのが楽しみです。

一旦、今日はこの辺で。

※本エントリはLayerXエンジニアブログの再掲です。ぜひLayerXエンジニアブログの他の記事もご覧ください