みなさん、こんにちは。AWS CLI が好きなテクニカルサポート課の市野です。
IAM ポリシーの設計と評価は煩雑で難しい問題ですが、従来から IAM ポリシーシミュレーターが提供されており、ポリシーのテストを行うことができました。
ただ、今回、現地時間 2026年7月31日 のアップデートで「ポリシーシミュレーター」として AWS マネジメントコンソールに統合されました。
加えて機能的にもアップデートされていますので合わせて見てみます。
クリックで目次が表示されます。
- 公式発表
- 最初にまとめ
- 旧 IAM ポリシーシミュレーター 側の表示
- 新しいポリシーシミュレーターの画面構成
- 検証してみる - 前提
- 検証してみる - プリンシパルモード
- 検証してみる - カスタムモード
- 検証してみる - PolicyExclusionList オプション
- 実行コマンド
- レスポンス
- 条件キーなし SCP の基本確認
- まとめ(再掲)
- おわりに
公式発表
最初にまとめ
- IAM コンソールに「ポリシーシミュレータ」として統合され、AWS マネジメントコンソール内で直接アクセスできるようになった
- 従来の IAM Policy Simulator( https://policysim.aws.amazon.com/ ) は legacy Policy Simulator として位置付けられ、廃止されるまで利用可能
- API レベルでのアップデートも行われ、以下のリクエストパラメータが追加されている
iam:SimulateCustomPolicyにおいてOrderedOrganizationPolicyInputListの追加iam:SimulatePrincipalPolicyにおいてPolicyExclusionListの追加
- これらのリクエストパラメータの追加により SCP(Service Control Policy)の条件キーのシミュレーションや、特定のポリシーをシミュレーションから除外したシナリオをテストできるようになった
旧 IAM ポリシーシミュレーター 側の表示
アクセスするとページ上部に "New Experience Available: A new and improved IAM Policy Simulator is now available in the AWS Console." と案内があり、新しいポリシーシミュレータへ誘導するボタンが用意されています。

新しいポリシーシミュレーターの画面構成
新しいポリシーシミュレーターは IAM コンソールのナビゲーションペインから「ポリシーシミュレーター」を選択してアクセスします。
画面上部で プリンシパル モードと カスタム モードを切り替えることができます。
プリンシパルモード
API アクションの SimulatePrincipalPolicy に相当し、アカウント内の既存の IAM ユーザー、IAM ロール、IAM ユーザーグループを選択した上で、アタッチ済みのポリシーを評価可能です。

カスタムモード
API アクションの SimulateCustomPolicy に相当し、ポリシー JSON を手動で入力し、アタッチ前のポリシーをテスト可能です。

検証してみる - 前提
以下のような SCP が Organizations の Root に割り当てられている環境で検証します。
この SCP は強めの AWS マネージドポリシー(AdministratorAccess 等)のアタッチを条件付きで拒否するものを想定しています。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDangerousAWSManagedPolicies", "Effect": "Deny", "Action": [ "iam:AttachUserPolicy", "iam:AttachGroupPolicy" ], "Resource": "*", "Condition": { "ArnEquals": { "iam:PolicyArn": [ "arn:aws:iam::aws:policy/AdministratorAccess", "arn:aws:iam::aws:policy/IAMFullAccess", "arn:aws:iam::aws:policy/PowerUserAccess", "arn:aws:iam::aws:policy/AmazonEC2FullAccess" ] } } }, { "Sid": "DenyIAMCreation", "Effect": "Deny", "Action": [ "iam:CreateAccessKey", "iam:CreateUser", "iam:CreateLoginProfile", "iam:UpdateLoginProfile" ], "Resource": "*" }, { "Sid": "ProtectOrgRole", "Effect": "Deny", "Action": "iam:UpdateAssumeRolePolicy", "Resource": "arn:aws:iam::*:role/OrganizationAccountAccessRole", "Condition": { "ArnNotLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/Serverworks*" } } } ] }
検証してみる - プリンシパルモード
GUI での検証
プリンシパルモードでは、左ペインの「組織ポリシー」セクションに「サービスコントロールポリシー (SCP)」のトグルスイッチがあり、ON にするとアカウントに実際に適用・波及されている SCP が自動的にシミュレーションに含まれます。

前提で設定されている SCP があるため iam:AttachUserPolicy をシミュレーションすると、「拒否済み - AWS Organizations によって拒否されました」という結果が得られます。

ただし、結果の詳細をクリックしても「アクセス許可は、このアカウントに関連付けられている AWS Organizations SCP によって拒否されました。」という情報のみで、どの SCP のどのステートメントが原因かは表示されません。

これはセキュリティ上の理由による仕様です。
また、SCP の Condition 句でのみ参照される条件キー(例: iam:PolicyArn)は GUI 上に表示されず、値を設定することもできません。
そのため GUI では「AdministratorAccess をアタッチしようとした場合」と「ReadOnlyAccess をアタッチしようとした場合」の差分を比較することはできません。
また、SCP に AWS グローバル条件コンテキストキーが書かれていたとしても「グローバルなリクエストの条件」セクションで指定することができませんでした。
下の図は、意図的に ID ベースのポリシー から "ProtectOrgRole" のチェックを外していますが、IAM ポリシーとしての "ProtectOrgRole" には SCP の ProtectOrgRole と同等の記述をしています。

そのため、選択した ID とその ID にアタッチされている IAM ポリシーに「グローバルなリクエストの条件」が存在する場合には、それらの条件を踏まえた調査ができることを確認しました。

なお、GUI 操作でリソースを指定する場合は、以下、いずれかの方法で実行が可能でした。
- 対象のアクションの左側のチェックボックスにチェックを入れ、「アクション」プルダウンから「リソースを編集」を選択する
- 対象のアクションのリソースフィールド内を直接クリックする。上記の方法で展開されるものと同一のポップアップが表示される
CLI での検証
GUI のプリンシパルモードでは SCP 専用の条件キーを設定できませんでしたが、CLI の SimulatePrincipalPolicy では --context-entries を使って自由に条件キーの値を指定できます。
SimulatePrincipalPolicy は既存のプリンシパルを指定してシミュレーションを行います。アカウントに適用されている SCP が自動的に評価対象に含まれるため、SCP を手動で渡す必要はありません。
既存の SCP の影響を考慮した検証
実行コマンド
aws iam simulate-principal-policy \ --policy-source-arn arn:aws:iam::123456789012:role/AdministratorAccess \ --action-names iam:CreateUser
実行後のレスポンス
{ "EvaluationResults": [ { "EvalActionName": "iam:CreateUser", "EvalResourceName": "*", "EvalDecision": "explicitDeny", "MatchedStatements": [], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": false } } ] }
SCP が自動的に評価され、explicitDeny が返りました。--ordered-organization-policy-input-list のようなオプションを渡さなくても SCP が考慮されていることがわかります。
--context-entries の検証
次に SCP で条件キー付きで表現していた Sid DenyDangerousAWSManagedPolicies を --context-entries で検証します。
実行コマンド - AdministratorAccess のアタッチを試みる
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:role/AdministratorAccess \
--action-names iam:AttachUserPolicy \
--context-entries '[{"ContextKeyName":"iam:PolicyArn","ContextKeyType":"string","ContextKeyValues":["arn:aws:iam::aws:policy/AdministratorAccess"]}]'
実行後のレスポンス
{ "EvaluationResults": [ { "EvalActionName": "iam:AttachUserPolicy", "EvalResourceName": "*", "EvalDecision": "explicitDeny", "MatchedStatements": [], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": false } } ] }
実行コマンド - ReadOnlyAccess のアタッチを試みる
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:role/AdministratorAccess \
--action-names iam:AttachUserPolicy \
--context-entries '[{"ContextKeyName":"iam:PolicyArn","ContextKeyType":"string","ContextKeyValues":["arn:aws:iam::aws:policy/ReadOnlyAccess"]}]'
実行後のレスポンス
{ "EvaluationResults": [ { "EvalActionName": "iam:AttachUserPolicy", "EvalResourceName": "*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "AdministratorAccess", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 3, "Column": 17 }, "EndPosition": { "Line": 8, "Column": 6 } } ], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true } } ] }
GUI のプリンシパルモードではできなかった、条件キーの値ごとの比較テストが CLI では可能です。
--context-entries の iam:PolicyArn |
結果 | OrganizationsDecisionDetail |
|---|---|---|
AdministratorAccess |
explicitDeny | AllowedByOrganizations: false |
ReadOnlyAccess |
allowed | AllowedByOrganizations: true |
参考:GUI では以下のように「条件を編集」が非活性となり「特定のポリシーだった場合」のような評価ができませんでした。

検証してみる - カスタムモード
GUI での SCP シミュレーション
カスタムモードの画面を見ると、左ペインには以下のセクションのみが表示されます。
- ID ベースのポリシー — 「+ ポリシーを追加」で手動入力
- アクセス許可の境界 — 「+ 境界を追加」
プリンシパルモードにあった「組織ポリシー」セクションが存在しません。つまり、GUI のカスタムモードでは SCP をシミュレーションに含めることができません。

公式ドキュメントにも以下のように明記されています。
In Custom mode, the console does not support passing in custom SCPs or simulating resource-based policies. To simulate custom SCPs or resource-based policies, use the AWS CLI or AWS API.
つまり、カスタムモードで SCP を含めたテストを行いたい場合は、CLI の SimulateCustomPolicy + --ordered-organization-policy-input-list を使用する必要があります。
CLI での検証
SimulateCustomPolicy では、ポリシーも SCP もすべて手動で渡します。アカウントに実際に適用されている SCP は参照されない、完全にサンドボックス的な動作です。
新パラメータ --ordered-organization-policy-input-list を使って SCP の階層を手動で渡し、条件キー付き SCP の評価を確認します。
CLI での検証 1 - AdministratorAccess をアタッチしようとした場合
aws iam simulate-custom-policy \
--policy-input-list '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"iam:AttachUserPolicy","Resource":"*"}]}' \
--action-names iam:AttachUserPolicy \
--context-entries '[{"ContextKeyName":"iam:PolicyArn","ContextKeyType":"string","ContextKeyValues":["arn:aws:iam::aws:policy/AdministratorAccess"]}]' \
--ordered-organization-policy-input-list '[{"ServiceControlPolicyInputList":["{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Action\":\"*\",\"Resource\":\"*\"}]}","{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"DenyDangerousAWSManagedPolicies\",\"Effect\":\"Deny\",\"Action\":[\"iam:AttachUserPolicy\",\"iam:AttachGroupPolicy\"],\"Resource\":\"*\",\"Condition\":{\"ArnEquals\":{\"iam:PolicyArn\":[\"arn:aws:iam::aws:policy/AdministratorAccess\",\"arn:aws:iam::aws:policy/IAMFullAccess\",\"arn:aws:iam::aws:policy/PowerUserAccess\",\"arn:aws:iam::aws:policy/AmazonEC2FullAccess\"]}}}]}"]}]'
各オプションに渡しているパラメータを展開すると以下の通りです。
--policy-input-list オプション
シミュレーション対象のアイデンティティベースポリシー(プリンシパルに付与されている想定の権限):
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:AttachUserPolicy", "Resource": "*" } ] }
「iam:AttachUserPolicy を全リソースに対して許可する」というシンプルなポリシーです。SCP がなければこのアクションは許可されます。
--context-entries オプション
シミュレーション時に渡す条件キーの値:
[ { "ContextKeyName": "iam:PolicyArn", "ContextKeyType": "string", "ContextKeyValues": ["arn:aws:iam::aws:policy/AdministratorAccess"] } ]
「アタッチしようとしているポリシーの ARN は AdministratorAccess である」というリクエストコンテキストを模しています。SCP の Condition 句でこの値が評価されます。
--ordered-organization-policy-input-list オプション
Organizations の SCP 階層を指定しつつ、アタッチする SCP ポリシーを定義します。
以下の 2 つの SCP を Root レベルに配置する意図としています。
1つ目(FullAWSAccess 相当)
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" } ] }
2つ目(制限用 SCP)
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDangerousAWSManagedPolicies", "Effect": "Deny", "Action": ["iam:AttachUserPolicy", "iam:AttachGroupPolicy"], "Resource": "*", "Condition": { "ArnEquals": { "iam:PolicyArn": [ "arn:aws:iam::aws:policy/AdministratorAccess", "arn:aws:iam::aws:policy/IAMFullAccess", "arn:aws:iam::aws:policy/PowerUserAccess", "arn:aws:iam::aws:policy/AmazonEC2FullAccess" ] } } } ] }
FullAWSAccess がないと SCP が暗黙的に全拒否してしまうため、実環境と同じく両方を含める必要がある点に注意してください。
実行結果
{ "EvaluationResults": [ { "EvalActionName": "iam:AttachUserPolicy", "EvalResourceName": "*", "EvalDecision": "explicitDeny", "MatchedStatements": [], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": false } } ] }
EvalDecision: "explicitDeny" かつ AllowedByOrganizations: false と出力されました。
SCP の条件キー iam:PolicyArn が正しく評価され、AdministratorAccess のアタッチを拒否しています。
なお、MatchedStatements が空となるのは GUI と同様に、セキュリティ上の理由で SCP のステートメント詳細は返却されない仕様のためです。
CLI での検証 2 - ReadOnlyAccess をアタッチしようとした場合
条件キーの値を ReadOnlyAccess に変えて同じシミュレーションを実行します。
aws iam simulate-custom-policy \
--policy-input-list '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"iam:AttachUserPolicy","Resource":"*"}]}' \
--action-names iam:AttachUserPolicy \
--context-entries '[{"ContextKeyName":"iam:PolicyArn","ContextKeyType":"string","ContextKeyValues":["arn:aws:iam::aws:policy/ReadOnlyAccess"]}]' \
--ordered-organization-policy-input-list '[{"ServiceControlPolicyInputList":["{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Action\":\"*\",\"Resource\":\"*\"}]}","{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"DenyDangerousAWSManagedPolicies\",\"Effect\":\"Deny\",\"Action\":[\"iam:AttachUserPolicy\",\"iam:AttachGroupPolicy\"],\"Resource\":\"*\",\"Condition\":{\"ArnEquals\":{\"iam:PolicyArn\":[\"arn:aws:iam::aws:policy/AdministratorAccess\",\"arn:aws:iam::aws:policy/IAMFullAccess\",\"arn:aws:iam::aws:policy/PowerUserAccess\",\"arn:aws:iam::aws:policy/AmazonEC2FullAccess\"]}}}]}"]}]'
先ほどの実行例との違いは --context-entries の値のみです。
--context-entries オプション
条件キーの値を ReadOnlyAccess に変更しています。
[ { "ContextKeyName": "iam:PolicyArn", "ContextKeyType": "string", "ContextKeyValues": ["arn:aws:iam::aws:policy/ReadOnlyAccess"] } ]
ReadOnlyAccess は SCP の ArnEquals 条件に列挙されていないため、Deny ステートメントの条件に合致せず、SCP による拒否が発動しないことを期待します。
--policy-input-list と --ordered-organization-policy-input-list は先ほどと同一です。
実行結果
{ "EvaluationResults": [ { "EvalActionName": "iam:AttachUserPolicy", "EvalResourceName": "*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "PolicyInputList.1", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 1, "Column": 38 }, "EndPosition": { "Line": 1, "Column": 103 } } ], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true } } ] }
EvalDecision: "allowed" かつ AllowedByOrganizations: true と出力されました。
SCP の条件に合致しない ReadOnlyAccess のアタッチは許可されます。
条件キーの値を変えるだけで Deny / Allow が切り替わることが確認でき、SCP の Condition 句が正しく評価されていることがわかります。
OrderedOrganizationPolicyInputList の構造
このパラメータの構造は以下のようになっています。
[ { "ServiceControlPolicyInputList": ["SCP の JSON 文字列", ...] }, ... ]
配列の各要素が Organizations 階層の 1 レベル(Root → OU → Account)に対応し、最大 7 階層まで指定可能です。各レベルに複数の SCP を含めることができます。
実環境では FullAWSAccess と制限用の SCP が同じレベルにアタッチされているため、両方を ServiceControlPolicyInputList に含める必要があります。
複数の階層に SCP が適用されている場合は、配列の要素を増やすことで表現します。
[ { "ServiceControlPolicyInputList": ["Root の SCP 群"] }, { "ServiceControlPolicyInputList": ["OU の SCP 群"] }, { "ServiceControlPolicyInputList": ["Account の SCP 群"] } ]
API リファレンスには以下のように記載されています。
The first element must represent the organization root, and the last element must represent the account. Any elements between them represent organizational units (OUs) in descending order.
今回の検証では Root レベルにのみ SCP をアタッチしている構成のため、配列の要素は 1 つです。
また、何番目に書いたものが OU かアカウントか?を区別するような挙動はしていないものと理解しています。(単純に OrderedOrganizationPolicyInputList の配列として複数列記しているだけ)
これは、Root を基点に OU が階層化できる 5 レベル+アカウント を配列として表現しているだけとなり、最大 7 つ書き連ねることができるだけ、と言えます。
SimulateCustomPolicy と SimulatePrincipalPolicy の SCP の扱いの違い
重要な点として、SimulateCustomPolicy は --ordered-organization-policy-input-list で渡した SCP のみを評価し、アカウントに実際に適用されている SCP は参照しません。
このオプションを省略した場合、SCP は一切評価されず、結果には OrganizationsDecisionDetail フィールド自体が含まれません。
実際に、--ordered-organization-policy-input-list を省略して同じコマンドを実行すると、アカウントに SCP が適用されているにもかかわらず allowed が返ります。
実行コマンド
aws iam simulate-custom-policy \
--policy-input-list '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"iam:AttachUserPolicy","Resource":"*"}]}' \
--action-names iam:AttachUserPolicy \
--context-entries '[{"ContextKeyName":"iam:PolicyArn","ContextKeyType":"string","ContextKeyValues":["arn:aws:iam::aws:policy/AdministratorAccess"]}]'
レスポンス
{ "EvaluationResults": [ { "EvalActionName": "iam:AttachUserPolicy", "EvalResourceName": "*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "PolicyInputList.1", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 1, "Column": 38 }, "EndPosition": { "Line": 1, "Column": 103 } } ], "MissingContextValues": [] } ] }
レスポンスに OrganizationsDecisionDetail が存在しないことからも、SCP が評価対象に含まれていないことが確認できます。
一方、SimulatePrincipalPolicy(GUI のプリンシパルモードに相当)は、指定したプリンシパルが所属するアカウントに実際に適用されている SCP を自動的に取得して評価に含めます。
| API | SCP の扱い |
|---|---|
SimulateCustomPolicy |
--ordered-organization-policy-input-list で渡したものだけを評価。省略すれば SCP は一切考慮されない |
SimulatePrincipalPolicy |
アカウントに実際に適用されている SCP が自動的に含まれる |
つまり SimulateCustomPolicy は完全にサンドボックス的な動作であり、「渡したもの以外は何も見ない」という設計です。
これは、まだデプロイしていない SCP を事前にテストしたい場合や、CI/CD パイプラインでポリシーのユニットテストを行いたい場合に適していると考えられます。
GUI の制約事項まとめ
公式ドキュメント(How to simulate policies)には以下のように明記されています。
プリンシパルモードについて
For security reasons, the simulator does not surface the details of SCP evaluation. Condition keys that are referenced only by SCPs are not listed for you to set values, and the matched statements returned for a result do not include statements from SCPs.
カスタムモードについて
In Custom mode, the console does not support passing in custom SCPs or simulating resource-based policies. To simulate custom SCPs or resource-based policies, use the AWS CLI or AWS API.
GUI と CLI の機能比較
| 観点 | GUI プリンシパルモード | GUI カスタムモード | CLI / API |
|---|---|---|---|
| SCP の取得 | 自動(Organizations から読込) | 不可 | SimulatePrincipalPolicy: 自動 / SimulateCustomPolicy: OrderedOrganizationPolicyInputList で手動指定 |
| SCP 専用の条件キー設定 | 不可(表示されない) | 不可(SCP 自体を含められない) | --context-entries で自由に指定可能 |
| 条件の差による比較テスト | 不可 | 不可 | 値を変えて複数回実行すれば対比可能 |
| Deny の原因特定 | 「SCP によって拒否」のみ | — | OrganizationsDecisionDetail で判定可能(ステートメント特定は不可) |
| 用途 | 「SCP で止められるか?」の簡易確認 | アタッチ前のポリシーの事前テスト | 条件キー付き SCP の精密なテスト、CI/CD での自動化 |
条件キー付き SCP の評価を検証する場合は CLI / API が必須です。
GUI のプリンシパルモードは「この操作は SCP で止められているか」の簡易確認に適していますが、「どの条件の場合に止められるか」の精密なテストには対応していません。
検証してみる - PolicyExclusionList オプション
SimulatePrincipalPolicy の新パラメータ --policy-exclusion-list を使うと、実際にポリシーをデタッチすることなく「このポリシーを外したらどうなるか?」をシミュレーションできます。権限の棚卸しや最小権限化の検討に直結するユースケースです。
現在 AdministratorAccess ロールには AdministratorAccess ポリシー、および ProtectOrgRole ポリシーがアタッチされています。
これを AdministratorAccess ポリシーを除外した場合にどうなるか?という観点で検証します。
現状の確認コマンド
aws iam list-attached-role-policies --role-name AdministratorAccess
レスポンス
{ "AttachedPolicies": [ { "PolicyName": "ProtectOrgRole", "PolicyArn": "arn:aws:iam::123456789012:policy/ProtectOrgRole" }, { "PolicyName": "AdministratorAccess", "PolicyArn": "arn:aws:iam::aws:policy/AdministratorAccess" } ] }
まず、除外なし(通常のシミュレーション)で S3 操作の許可を確認します。
実行コマンド
aws iam simulate-principal-policy \ --policy-source-arn arn:aws:iam::123456789012:role/AdministratorAccess \ --action-names s3:GetObject s3:PutObject \ --resource-arns 'arn:aws:s3:::example-bucket/*'
レスポンス
{ "EvaluationResults": [ { "EvalActionName": "s3:GetObject", "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "AdministratorAccess", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 3, "Column": 17 }, "EndPosition": { "Line": 8, "Column": 6 } } ], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true }, "EvalDecisionDetails": {}, "ResourceSpecificResults": [ { "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalResourceDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "AdministratorAccess", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 3, "Column": 17 }, "EndPosition": { "Line": 8, "Column": 6 } } ] } ] }, { "EvalActionName": "s3:PutObject", "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "AdministratorAccess", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 3, "Column": 17 }, "EndPosition": { "Line": 8, "Column": 6 } } ], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true }, "EvalDecisionDetails": {}, "ResourceSpecificResults": [ { "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalResourceDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "AdministratorAccess", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 3, "Column": 17 }, "EndPosition": { "Line": 8, "Column": 6 } } ] } ] } ] }
当然ながら AdministratorAccess ポリシーによって両方とも allowed です。
次に、--policy-exclusion-list で AdministratorAccess ポリシーを除外します。
実行コマンド
aws iam simulate-principal-policy \
--policy-source-arn arn:aws:iam::123456789012:role/AdministratorAccess \
--action-names s3:GetObject s3:PutObject \
--resource-arns 'arn:aws:s3:::example-bucket/*' \
--policy-exclusion-list '[{"PolicyArn":"arn:aws:iam::aws:policy/AdministratorAccess"}]'
レスポンス
{ "EvaluationResults": [ { "EvalActionName": "s3:GetObject", "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalDecision": "implicitDeny", "MatchedStatements": [], "MissingContextValues": [ "aws:PrincipalArn" ], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true }, "EvalDecisionDetails": {}, "ResourceSpecificResults": [ { "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalResourceDecision": "implicitDeny", "MissingContextValues": [ "aws:PrincipalArn" ] } ] }, { "EvalActionName": "s3:PutObject", "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalDecision": "implicitDeny", "MatchedStatements": [], "MissingContextValues": [ "aws:PrincipalArn" ], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true }, "EvalDecisionDetails": {}, "ResourceSpecificResults": [ { "EvalResourceName": "arn:aws:s3:::example-bucket/*", "EvalResourceDecision": "implicitDeny", "MissingContextValues": [ "aws:PrincipalArn" ] } ] } ] }
AdministratorAccess を除外した結果、許可を与えるポリシーがなくなり implicitDeny になりました。OrganizationsDecisionDetail は AllowedByOrganizations: true のまま(SCP は拒否していない)なので、Deny の原因がアイデンティティベースポリシーの不在であることが明確です。
PolicyExclusionList の活用シーン
このパラメータは以下のような運用シーンで活用できます。
- 最小権限化の検討: 「AdministratorAccess を外して、代わりにスコープを絞ったポリシーに置き換えたい。外した場合に影響を受けるアクションはどれか?」
- 不要ポリシーの特定: 複数ポリシーがアタッチされている場合に、1 つずつ除外してシミュレーションし、実際に使われているポリシーを特定する
- 変更のリスク評価: デタッチ操作を行う前に、影響範囲を安全に事前確認する
条件キーなし SCP の基本確認
最後に、条件キーを持たない単純な Deny ステートメントのシミュレーションも確認しておきます。
SCP の DenyIAMCreation ステートメントは以下のように、Condition 句を持たない無条件の Deny です。
{ "Sid": "DenyIAMCreation", "Effect": "Deny", "Action": [ "iam:CreateAccessKey", "iam:CreateUser", "iam:CreateLoginProfile", "iam:UpdateLoginProfile" ], "Resource": "*" }
SCP で Deny されるアクション(iam:CreateUser、iam:CreateAccessKey)と、Deny されないアクション(iam:GetUser)を同時にシミュレーションします。
実行コマンド
aws iam simulate-custom-policy \
--policy-input-list '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"iam:*","Resource":"*"}]}' \
--action-names iam:CreateUser iam:CreateAccessKey iam:GetUser \
--ordered-organization-policy-input-list '[{"ServiceControlPolicyInputList":["{\"Version\":\"2012-10-17\",\"Statement\":[{\"Effect\":\"Allow\",\"Action\":\"*\",\"Resource\":\"*\"}]}","{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"DenyIAMCreation\",\"Effect\":\"Deny\",\"Action\":[\"iam:CreateAccessKey\",\"iam:CreateUser\",\"iam:CreateLoginProfile\",\"iam:UpdateLoginProfile\"],\"Resource\":\"*\"}]}"]}]'
レスポンス
{ "EvaluationResults": [ { "EvalActionName": "iam:CreateUser", "EvalResourceName": "*", "EvalDecision": "explicitDeny", "MatchedStatements": [], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": false } }, { "EvalActionName": "iam:CreateAccessKey", "EvalResourceName": "*", "EvalDecision": "explicitDeny", "MatchedStatements": [], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": false } }, { "EvalActionName": "iam:GetUser", "EvalResourceName": "*", "EvalDecision": "allowed", "MatchedStatements": [ { "SourcePolicyId": "PolicyInputList.1", "SourcePolicyType": "IAM Policy", "StartPosition": { "Line": 1, "Column": 38 }, "EndPosition": { "Line": 1, "Column": 88 } } ], "MissingContextValues": [], "OrganizationsDecisionDetail": { "AllowedByOrganizations": true } } ] }
| アクション | SCP に該当 | 結果 |
|---|---|---|
iam:CreateUser |
DenyIAMCreation に該当 | explicitDeny |
iam:CreateAccessKey |
DenyIAMCreation に該当 | explicitDeny |
iam:GetUser |
どの Deny にも該当しない | allowed |
条件キーを持たない SCP のシミュレーションは --context-entries が不要で、SCP のアクションリストに含まれるか否かだけで結果が決まります。
条件キー付き SCP の評価が今回のアップデートで新たに可能になっていることがわかります。
まとめ(再掲)
- IAM コンソールに「ポリシーシミュレータ」として統合され、AWS マネジメントコンソール内で直接アクセスできるようになった
- 従来の IAM Policy Simulator( https://policysim.aws.amazon.com/ ) は legacy Policy Simulator として位置付けられ、廃止されるまで利用可能
- API レベルでのアップデートも行われ、以下のリクエストパラメータが追加されている
iam:SimulateCustomPolicyにおいてOrderedOrganizationPolicyInputListの追加iam:SimulatePrincipalPolicyにおいてPolicyExclusionListの追加
- これらのリクエストパラメータの追加により SCP(Service Control Policy)の条件キーのシミュレーションや、特定のポリシーをシミュレーションから除外したシナリオをテストできるようになった
おわりに
GUI でできること、CLI でできることの差分が多く、長いエントリになってしまいました。
ただ、CLI(API)レベルで実行することで、SCP による影響を精緻にシミュレーションできるようになりました。
黒い画面が苦手な方も多いと思いますが、うまく活用して最小権限の模索に役立ててみてはいかがでしょうか。
本エントリがどなたかのお役に立てば幸いです。
市野 和明 (記事一覧)
マネージドサービス部・テクニカルサポート課
お客様から寄せられたご質問や技術検証を通じて得られた気づきを投稿していきます。
情シスだった前職までの経験で、UI がコロコロ変わる AWS においては GUI で手順を残していると画面構成が変わってしまって後々まごつくことが多かった経験から、極力変わりにくい AWS CLI での記事が多めです。
X(Twitter):@kazzpapa3(AWS Community Builder)