概要
AWS環境において、「このIAMロールは本当にこの操作を実行できるのか?」という疑問は日常的に発生します。
IAMポリシーのJSONを目視で確認することも可能ですが、実際の権限評価は以下の複数要素によって決定されます。
- アタッチされたIAMポリシー(マネージド / インライン)
- グループポリシー
- Permission Boundary
- SCP(Service Control Policy)
- 明示的Deny
- Condition条件
また、IAMの評価ロジックは
Allowの集合から、明示的Denyと上位制限(SCP / Boundary)を引いたもの
で決定されるため、目視だけで正確な最終結果を判断するのは困難です。
そこで活用できるのが simulate-principal-policy コマンドです。
このコマンドを使用すると、特定のIAMプリンシパル(ユーザー・ロール・グループ)に対して、特定のアクションが許可されるかどうかをAWS側で評価させることができます。
simulate-principal-policyコマンド
IAMポリシーのテストをするには、simulate-principal-policyコマンドを使います
aws iam simulate-principal-policy \
--policy-source-arn (string) \
--action-names (list[string])
-
--policy-source-arn- 検証したいIAMユーザー・グループ・ロールのARNを指定
-
--action-names- 検証したいアクションを指定
また、以下のようなテストをしたい場合でも、Optionalなコマンド引数を追加することで、対応することができます。
- IAMポリシーの
Conditionの検証をしたい - 引数
--policy-source-arnで指定したIAMポリシーに対して、ポリシーをさらに追加して検証したい
Optionalなコマンド引数については、下記を参照
simulate-principal-policy コマンドの利点
- IAMポリシーに対して、アクションが許可(拒否)されているかどうかは、直接IAMポリシーの内容を見れば確認できるのでは? となりそうですが、
simulate-principal-policyコマンドは、以下の場面で非常に有用です
利点1: 複雑な権限の結果が一発でわかる
-
simulate-principal-policyのテスト結果は、以下の要素すべて参照して評価されます- ユーザー・ロール・グループにアタッチされたIAMポリシー
- インラインポリシー
- SCP
- Permission Boundary
-
上記の1箇所で定義されたものを確認するのは目視でも確認できますが、上記の要素が絡んだ複雑な権限管理をテストするには目視では限界があります
利点2: アクションが許可・拒否された理由・箇所がわかる
-
simulate-principal-policyのテスト結果は、出力項目EvalDecisionに出力されます- 出力の詳細は、AWS Command Reference参照
- 出力パターンは以下の3つ
-
allowed:ポリシー内で、そのアクションが許可されている -
explicitDeny:ポリシー内で、そのアクションが明示的に拒否されている -
implicitDeny:ポリシー内に許可がないため、そのアクションが暗黙的に拒否されている
-
さらに、どのポリシーの記述がEvalDecisionの結果の原因となっているのかも、MatchedStatementsから確認できます
{
"EvaluationResults": [
{
"EvalActionName": "codecommit:ListRepositories",
"EvalResourceName": "*",
"EvalDecision": "allowed",
"MatchedStatements": [
{
"SourcePolicyId": "Grant-Access-To-CodeCommit-ListRepo",
"StartPosition": {
"Line": 3,
"Column": 19
},
"EndPosition": {
"Line": 9,
"Column": 10
}
}
],
"MissingContextValues": []
}
]
}
上記は、AWS Command Reference>Example 1のコマンド出力例です。codecommit:ListRepositories アクションが、どのポリシーの何行目で許可されているのかが一目でわかります
利点3: 複雑な条件を想定したテストができる
コマンドの紹介の際に前述しましたが、複雑な条件下での権限のテストするためにOptionalなコマンド引数が用意されています
例:送信元IPに対する権限を検証する
"Condition": {
"IpAddress": {
"aws:SourceIp": "203.0.113.0/24"
}
}
上記のように、アクセス元のIPが特定のものである時にのみ適用されるポリシーを定義したとして、
--context-entries
key=aws:SourceIp,value=203.0.113.5
--context-entries オプションを使用し、条件を設定してテストができます
利点4: SCPやPermission Boundaryを含めたテストができる
利点1と被る内容ですが、simulate-principal-policyコマンドは、単にIAMポリシーの条件をテストするだけではありません。SCPや、Permission Boundaryといったポリシー外の要素も確認して権限をテストできます
まとめ
simulate-principal-policy コマンドは、
- 複雑なIAM評価結果を即座に確認できる
- 許可/拒否の理由を特定できる
- Conditionを含めた詳細テストができる
- Permission BoundaryやSCPを考慮した確認が可能
という非常に強力な検証ツールです。
特に以下のような場面で真価を発揮します。
- CloudFormationやTerraformでのデプロイ前検証
- Permission Boundary導入時の動作確認
- 「なぜAccessDeniedになるのか?」の原因切り分け
- 最小権限設計の検証
simulate-principal-policy コマンドを活用して、より安全で正確な権限管理を行いましょう!!