Identity and Access Management の許可ポリシーの Policy Simulator では、変更を commit する前に許可ポリシーへの変更がプリンシパルのアクセス権にどのように影響するかを確認できます。Policy Simulator を使用して、変更を行うことによりプリンシパルが必要なアクセス権を失わないようにできます。
この機能は、許可ポリシーのみを評価します。他のポリシータイプのシミュレーション方法については、以下をご覧ください。
許可ポリシーの Policy Simulator の仕組み
許可ポリシーの Policy Simulator は、許可ポリシーの変更がユーザーに与える影響を判断する際に活用できます。これは、現在の許可ポリシーと提案された許可ポリシーでの権限を比較するだけではありません。それよりも、アクセスログを使用して、権限の変更が実際にユーザーに与える影響について焦点を当てています。
許可ポリシーへの変更がプリンシパルのアクセス権にどのように影響するかを確認するため、Policy Simulator は、提案した許可ポリシーと現在の許可ポリシーで過去 90 日間のどのアクセス試行の結果が異なるかを判断します。その後、その結果がアクセス権の変更のリストとしてレポートされます。
許可ポリシーの変更をシミュレートする場合は、テストする変更を反映した許可ポリシーを提案して指定します。この提案した許可ポリシーは、許可ポリシーを受け入れるリソースで使用できます。
シミュレーションを実行すると、Policy Simulator は次の処理を実行します。
過去 90 日間のサポートされるリソースタイプのアクセスログを取得します。これらのログを収集する場所は、許可ポリシーをシミュレーションしているリソースによって異なります。
- プロジェクトまたは組織の許可ポリシーをシミュレートする場合は、Policy Simulator が対象のプロジェクトまたは組織のアクセスログを取得します。
- 別の種類のリソースに対して許可ポリシーをシミュレートする場合は、Policy Simulator が対象のリソースの親プロジェクトまたは組織のアクセスログを取得します。
- 複数のリソースの許可ポリシーを一度にシミュレートする場合、Policy Simulator は、リソースに最も近い共通のプロジェクトまたは組織のアクセスログを取得します。
親リソースが 90 日間存在していない場合、Policy Simulator は、リソースが作成されてからのすべてのアクセス試行を取得します。
現在の許可ポリシーを使用してアクセスログに記録されたアクセス試行を再評価(リプレイ)し、継承された許可ポリシーと子孫リソースに設定された許可ポリシーを考慮に入れます。
現在の許可ポリシーでアクセス試行をリプレイすると、Policy Simulator は提案された許可ポリシーによって生じたアクセス権の変更のみをレポートし、過去 90 日間に行った他の許可ポリシーの修正によって生じた変更はレポートしません。
提案された許可ポリシーを使用して、再度アクセス試行をリプレイし、継承された許可ポリシーと、子孫リソースに設定された許可ポリシーをもう一度考慮に入れます。
2 つのリプレイの結果を比較し、違いをレポートします。これにより、提案された変更がプリンシパルのアクセス権にどのように影響するかが示されます。
例: ポリシーの変更のテスト
ユーザーの組織閲覧者ロール(roles/resourcemanager.organizationViewer
)を削除し、Policy Simulator を使用してこの変更がユーザーのアクセスに影響しないことを確認するとします。
Google Cloud コンソール、REST API、または Google Cloud CLI を使用して、許可ポリシーの変更をシミュレートします。
シミュレーションを開始すると、Policy Simulator は次の処理を行います。
- 過去 90 日間の組織のアクセスログを取得します。
- ユーザーが組織閲覧者ロールを持つ組織の現在の許可ポリシーを使用して、アクセス試行をリプレイします。
- ユーザーが組織閲覧者ロールを持たない場合は、提案された許可ポリシーを使用してアクセス試行をリプレイします。
- 2 つのリプレイの結果を比較し、違いをレポートします。
その結果をレビューして、提案された変更がユーザーのアクセスにどのように影響するかを理解できます。
例: ポリシー継承
次の構造の組織内のフォルダ Engineering
に対する許可ポリシーの変更をシミュレートする場合を考えてみます。
Engineering
には親リソースである組織 example.com
があり、そこから許可ポリシーを継承することにご注意ください。また、独自の許可ポリシー(example-prod
、example-dev
、example-test
)を持つことができる 3 つの子プロジェクトもあります。
提案された許可ポリシーを指定し、シミュレーションを実行します。シミュレーションを開始すると、Policy Simulator は次の処理を行います。
- 過去 90 日間のすべての関連ログを取得します。
Engineering
はフォルダであるため、Policy Simulator は親組織example.com
からログを取得します。 - フォルダの現在の許可ポリシー、
example.com
から継承された許可ポリシー、子プロジェクトの許可ポリシーを使用して、アクセス試行をリプレイします。 - 提案された許可ポリシー、
example.com
から継承された許可ポリシー、子プロジェクトの許可ポリシーを使用して、各アクセス試行を再度リプレイします。 - リプレイの結果を比較し、違いをレポートします。
その結果をレビューして、提案された変更がユーザーのアクセスにどのように影響するかを理解できます。
Policy Simulator の結果
Policy Simulator は、許可ポリシーに対して提案された変更の影響をアクセス変更のリストとしてレポートします。アクセス権の変更とは、提案された許可ポリシーでは現在の許可ポリシーとは異なる結果となる過去 90 日間のアクセス試行を表します。
Policy Simulator は、シミュレーション中に発生したエラーも一覧表示します。これにより、シミュレーションにおいて可能性のあるギャップを特定できます。
アクセス権の変更には、次に挙げる複数の方法があります。
アクセス権の変更 | 詳細 |
---|---|
アクセス権が取り消されました | プリンシパルは現在の許可ポリシーでアクセス可能ですが、提案された変更の後にアクセスできなくなりました。 |
アクセス権が取り消された可能性があります |
この結果が発生する理由として以下のことが考えられます。 |
アクセス権が付与されました | プリンシパルは現在の許可ポリシーではアクセスできず、提案された変更の後にアクセス可能になります。 |
アクセス権が付与された可能性があります |
この結果が発生する理由として以下のことが考えられます。 |
アクセス権が不明 | 現在の許可ポリシーと提案された許可ポリシーの両方におけるプリンシパルのアクセス権は不明であり、提案された変更がプリンシパルのアクセス権に影響を及ぼす可能性があります。 |
エラー | シミュレーション中にエラーが発生しました。 |
不明な結果
アクセス結果が不明の場合、Policy Simulator では、アクセス試行を完全に評価するための情報が不足していたことを意味します。
結果が不明な場合は、次のような理由が考えられます。
- ロール情報が拒否されました: シミュレーションを実行しているプリンシパルに、シミュレートされている 1 つ以上のロールの詳細を表示する権限がありませんでした。
- ポリシーにアクセスできません: シミュレーションを実行しているプリンシパルに、シミュレーションに関係する 1 つ以上のリソースの許可ポリシーを取得する権限がありませんでした。
- メンバー情報が拒否されました: シミュレーションを実行しているプリンシパルに、シミュレートされた許可ポリシーに含まれる 1 つ以上のグループのメンバーを表示する権限がありませんでした。
- サポートされていない条件: テスト対象の許可ポリシーに条件付きロール バインディングがあります。Policy Simulator は条件をサポートしていないため、バインディングを評価できませんでした。
アクセス結果が不明な場合は、Policy Simulator の結果で、不明であった理由がレポートされます。また、Policy Simulator によってアクセスや評価ができなかった特定のロール、許可ポリシー、メンバーシップ情報、条件がレポートされます。
エラー
Policy Simulator では、シミュレーション中に発生したエラーもレポートされます。シミュレーションで発生する可能性のあるギャップを理解するために、これらのエラーを確認することが重要です。
Policy Simulator のレポートでは、以下のようなさまざまなタイプのエラーが報告される可能性があります。
オペレーション エラー: シミュレーションを実行できなかった場合に発生します。
プロジェクトまたは組織でログが多すぎるため、シミュレーションを実行できなかったことを示すエラー メッセージが表示された場合は、そのリソースでシミュレーションを実行できません。
他の理由でこのエラーが発生した場合は、もう一度シミュレーションを実行してみてください。それでもシミュレーションを実行できない場合は、policy-simulator-feedback@google.com までお問い合わせください。
リプレイエラー: 1 回のアクセス試行のリプレイが失敗したため、Policy Simulator は、アクセス試行の結果が提案された許可ポリシーに基づいて変更されるかどうかを判定できませんでした。
サポートされていないリソースタイプのエラー: 提案された許可ポリシーが、Policy Simulator がシミュレーションできないサポートされていないリソースタイプに関連する権限に影響しています。Policy Simulator では、シミュレーション結果にこれらの権限が一覧表示されるため、シミュレーションができなかった権限がわかります。
最大ログリプレイ サイズ
シミュレーションでリプレイできるアクセスログの最大数は 5,000 件です。過去 90 日間にプロジェクトまたは組織で 5,000 件を超えるアクセスログがある場合、シミュレーションは失敗します。
Policy Simulator がどのアクセスログを取得するかを決定する方法については、このページの Policy Simulator の仕組みをご覧ください。
リソースタイプのサポートレベル
Policy Simulator では、シミュレーション内のすべてのリソースタイプはサポートされていません。これは、シミュレーション可能な権限の変更に影響します。
サポートされるリソースタイプ
Policy Simulator は、次のリソースタイプのみをサポートしています。
サービス | サポートされるリソースタイプ |
---|---|
Cloud Storage |
|
Pub/Sub |
|
Cloud SQL |
|
Spanner |
|
Resource Manager |
|
Compute Engine |
|
サポートされていないリソースタイプ
サポートされていないリソースタイプとは、Policy Simulator がアクセスログを取得できないリソースタイプです。Policy Simulator がリソースに対するアクセスログを取得できない場合、提案された許可ポリシーがこれらのアクセス試行にどのように影響するかを評価できません。
提案された許可ポリシーの変更がサポートされていないリソースタイプに対する権限を含む場合、Policy Simulator はシミュレーションでこれらの権限を一覧表示して、シミュレートできない権限を確認できるようにします。たとえば、Policy Simulator は AI Platform モデルをサポートしていません。したがって、提案された許可ポリシーで aiplatform.models.list
権限を含むロールが削除されると、そのシミュレーションの結果により、aiplatform.models.list
権限をシミュレートできなかったことがわかります。
次のステップ
- 許可ポリシーの変更をシミュレートする方法を確認する。
- その他の Policy Intelligence ツールを調べる。