拒否ポリシーの Policy Simulator では、変更を commit する前に IAM 拒否ポリシーの変更がプリンシパルのアクセス権にどのように影響するかを確認できます。Policy Simulator を使用して、変更を行うことによりプリンシパルが必要なアクセス権を失わないようにできます。
この機能は、拒否ポリシーのみを評価します。他のポリシータイプのシミュレーション方法については、以下をご覧ください。
拒否ポリシーの Policy Simulator の仕組み
拒否ポリシーの Policy Simulator を使用すると、拒否ポリシーの変更によってプリンシパルが使用しているアクセス権がブロックされるかどうかを判断できます。
拒否ポリシーのシミュレーションを実行すると、Policy Simulator は次の処理を行います。
リプレイ期間中に生成された組織のアクセスログを取得します。リプレイ期間は 90 日間です。
組織が 90 日以上存在していない場合、Policy Simulator は組織が作成されてからのすべてのアクセスログを取得します。
シミュレーションに関連するアクセスログを特定します。関連するアクセスログとは、プリンシパルが権限を使用してリソースにアクセスしようとした最新の試行を表すアクセスログです。
関連するアクセスログごとに、現在の拒否ポリシーと提案された変更によって、試行されたアクセスが許可されるかどうかを判断します。このプロセスは、アクセス試行の「リプレイ」と呼ばれます。
アクセスログごとに、リプレイのアクセス状態とアクセスログのアクセス状態を比較します。次に、Policy Simulator は、アクセスログではブロックされなかったが、リプレイではブロックされた過去のアクセス試行をレポートします。これらの違いは「 アクセス権の変更」と呼ばれ、 シミュレートされた拒否ポリシーが試行時に適用されていた場合にブロックされたアクセス試行を示します。
リプレイ期間
リプレイ期間とは、シミュレーションの実行時に Policy Simulator がアクセスログを取得する期間です。リプレイ期間の初日より前またはリプレイ期間の最終日より後のアクセスログは、シミュレーションに含まれません。
通常、リプレイ期間の最終日はシミュレーションの 1 日前です。ただし、場合によっては、リプレイ期間の最終日がシミュレーションの 10 日前になることがあります。リプレイ期間の最終日より後のアクセスログは、シミュレーションに含まれません。
リプレイ期間は 90 日間です。組織が 90 日以上存在していない場合、Policy Simulator は組織が作成されてからのすべてのアクセス試行を取得します。
リプレイ ウィンドウにも結果整合性があります。つまり、シミュレーションを実行すると、一部のデータが他のデータよりも新しい可能性があります。ただし、最終的にはすべてのデータの鮮度が同じになります。
Policy Simulator の結果
Policy Simulator は、拒否ポリシーに対して提案された変更の影響を、アクセス権の変更のリストとしてレポートします。 拒否ポリシーの場合、Policy Simulator がレポートするアクセス権の変更のタイプは、アクセス権の取り消し のアクセス権の変更のみです。
Policy Simulator は、次の条件に該当する場合にアクセス権が取り消されたことをレポートします。
- プリンシパルがリソースにアクセスしようとした最新の試行が成功した
- 提案された変更または別の拒否ポリシーによって、プリンシパルのリソースへのアクセスがブロックされる
アクセス権の変更ごとに、Policy Simulator は次の情報もレポートします。
- アクセス試行に関与したプリンシパル、リソース、権限。
- リプレイ期間中にプリンシパルが権限を使用してリソースにアクセスしようとした日数。この合計には、最新のアクセス試行と同じ結果のアクセス試行のみが含まれます。
- 最新のアクセス試行の日付。
エラー
次のエラーが原因でシミュレーションが失敗する可能性があります。
- 同時シミュレーションの最大数を超えました: ユーザーがすでに 10 個のシミュレーションを実行しています。これは、ユーザーが実行できるシミュレーションの最大数です。この問題を解決するには、実行中のシミュレーションのいずれかが完了するまで待ってから、もう一度シミュレーションを実行します。
- タイムアウト: シミュレーションの実行に時間がかかりすぎたため、タイムアウトしました。この問題を解決するには、もう一度シミュレーションを実行します。
- シミュレーションの構成が無効です: 提案された拒否ポリシーが無効であるか、 サポートされていない拒否ルールが含まれています。無効なポリシーの例としては、無効な条件式が含まれているものがあります。サポートされていない拒否ルールの例としては、Workforce Identity プリンシパル ID を使用するものがあります。この問題を解決するには、ポリシーを修正してもう一度お試しください。
- 権限がありません: シミュレーションを実行する権限がありません。この問題を 解決するには、必要なロールが付与されていることを確認して、もう一度 お試しください。
サポートされているプリンシパル タイプ
拒否ポリシーの Policy Simulator は、次のタイプのプリンシパルのアクセスログのみを確認します。
- Google Workspace アカウント
- サービス アカウント
- サービス アカウント プリンシパル セット（プロジェクト、 フォルダ、組織用）
- サービス エージェント
- サービス エージェント プリンシパル セット（プロジェクト、 フォルダ、組織用）
拒否ポリシーをシミュレートする場合、Policy Simulator は、Workload Identity プール内のフェデレーション ID に基づくプリンシパルなど、他のプリンシパル タイプのアクセスログを確認しません。そのため、Policy Simulator は、ポリシーまたはバインディングに対する提案された変更がこれらのプリンシパルのアクセスに影響するかどうかをレポートしません。
認証情報アクセス境界のシミュレーション
認証情報アクセス境界を使用すると、有効期間が短い認証情報を使用してCloud Storage リソースにアクセスできる IAM 権限の範囲を限定または制限できます。 権限の範囲を限定するには、ユーザーまたはサービス アカウント（トークン ブローカー）が、範囲が限定されたアクセス トークンの一連のリソースで使用可能な権限を定義し、そのアクセス トークンを別のユーザーまたはサービス アカウント（トークン コンシューマー）に提供します。
トークン ブローカーには、範囲が限定されたアクセス トークンでトークン コンシューマーに付与された権限を含むロールが必要です。トークン ブローカーでそのロールを拒否すると、トークン コンシューマーのアクセス権も削除されます。ただし、Policy Simulator は、トークン ブローカーの権限の変更がトークン コンシューマーのアクセスにどのように影響するかを評価しません。
たとえば、認証情報アクセス境界で作成された範囲が限定されたアクセス トークンを使用して、リソースに対するストレージのレガシー
バケット閲覧者 （roles/storage.legacyBucketReader）ロールが付与されているユーザーを考えてみましょう。
そのユーザーに対するストレージのレガシー バケット閲覧者 ロールの拒否をシミュレートすると、Policy Simulator はアクセス権の喪失をレポートできません。
トークン ブローカーに対するストレージのレガシー バケット閲覧者 ロールの拒否をシミュレートすると、Policy Simulator はユーザーのアクセス権の喪失をレポートできません。同様に、トークン ブローカーのアクセス権が 90 日以内に使用されない場合、そのアクセス権はシミュレーションに含まれません。
詳細については、 Cloud Storage の認証情報アクセス境界をご覧ください。
次のステップ
- 拒否ポリシーの変更をシミュレートする方法を確認する。
- 他の ポリシー インテリジェンス ツール を確認する。