ポリシー トラブルシューティングを使用した BeyondCorp Enterprise に関するトラブルシューティング

BeyondCorp Enterprise には、管理者がエンドユーザーのアクセスの優先順位付けと分析に使用できるトラブルシューティング ツールが用意されています。

BeyondCorp Enterprise を使用すると、企業はコンテキスト ベースのアプリケーション アクセスを提供する高度なルールを作成できます。ただし、場所の制限やデバイスのルールなど、複数のアクセスルールをリソースに適用すると、ポリシーの評価方法や、エンドユーザーがターゲット リソースにアクセスできる（またはできない）理由を把握しにくくなります。

Policy Troubleshooter を使用して、管理者はアクセスが成功または失敗する理由を特定できます。また、必要に応じてポリシーを変更し、問題なくアクセスできるようコンテキストの変更をエンドユーザーに指示したり、バインディングを削除して予期しないアクセスを拒否したりできます。

ポリシーのトラブルシューティングは、ユーザー グループごとに複数のリソースに複数のルールを適用する必要がある組織にとって有用なツールです。

始める前に

Policy Troubleshooter はプレミアム機能で、BeyondCorp Enterprise ライセンスが必要です。

Policy Troubleshooter で最大の効果を得るには、セキュリティ審査担当者（roles/iam.securityReviewer）のロールが付与されている必要があります。このロールがあれば、該当するすべての Cloud IAM ポリシーを確実に読み取ることができます。

デバイスのアクセスのトラブルシューティングを行うには、デバイスの詳細を表示する権限が必要です。ターゲット リソースに関連付けられたポリシーに、デバイスの暗号化が必要なアクセスレベルなどのデバイス ポリシーが含まれている場合、ターゲット プリンシパルのデバイスの詳細を取得する権限が確認されない限り、正確な結果が得られない可能性があります。Google Workspace 特権管理者、サービス管理者、モバイル管理者は通常、デバイスの詳細を表示するためのアクセス権を持っています。特権管理者、サービス管理者、モバイル管理者ではないユーザーにアクセス権のトラブルシューティングを許可するには、次の手順を行います。

  1. カスタムの Google Workspace 管理者ロールを作成します。このロールには、[サービス] > [モバイル デバイス管理] > [デバイスと設定の管理] 権限が含まれています（[管理コンソール権限] にあります）。
  2. 管理コンソールを使用してユーザーにロールを割り当てます。

Google Cloud グループによって付与されたリソースへのアクセスのトラブルシューティングを行うには、そのメンバーを表示する権限が必要です。ポリシーにグループが含まれている場合は、グループを開く前にグループの詳細を表示する権限が必要です。Google Workspace 特権管理者とグループ管理者は通常、グループ メンバーを表示する権限を持っています。特権管理者またはグループ管理者ではないユーザーにアクセス権のトラブルシューティングを許可するには、次の手順を行います。

  1. カスタムの Google Workspace 管理者ロールを作成します。このロールには、[グループ] > [読み取り] 権限が含まれています（[管理 API 権限] にあります）。
  2. ロールをユーザーに割り当てます。これにより、ユーザーはドメイン内のすべてのグループのメンバーシップを表示し、アクセス権のトラブルシューティングをより効果的に行うことができます。

カスタムロールの権限はオプションです。カスタムロールを表示する権限を付与されていない場合は、プリンシパルがカスタムロールを持つバインディングからアクセスできるかどうかを判断できないことがあります。

トラブルシューティング ワークフローの概要

アクセスの拒否のトラブルシューティング

アクセスの拒否のトラブルシューティングを行うには、IAP で保護されたアプリケーションの右側の 3 つのドットをクリックし、[設定] をクリックして、[トラブルシューティング URL を選択します。Policy Troubleshooter で最大の効果を得るには、IAP 設定管理者（roles/iap.settingsAdmin）のロールが付与されている必要があります。これにより、すべての IAP リソースの IAP 設定を取得および更新できるようになります。

トラブルシューティング URL は、有効になっている場合、デフォルトの 403 ページでのみ表示されます。

Policy Troubleshooter は、ターゲット IAP リソースに対して有効なすべてのポリシーの詳細な評価結果を表示するユーザー インターフェースを提供します。ユーザーのアクセスが失敗すると、403 ページにはトラブルシューティングの URL が表示されます。アクセスすると、Policy Troubleshooter により失敗したバインディングの詳細と、バインディングに存在する場合は失敗したアクセスレベルの分析が表示されます。トラブルシューティングを使用して、リソースに対するユーザーのアクセス権の詳細を確認することもできます。

ユーザー アクセスが拒否される

ユーザーに権限がないか、IAP リソースへのアクセスに必要な条件を満たさない場合、403 アクセス拒否のエラーページが表示されます。403 ページには、アプリケーション オーナーまたはセキュリティ管理者に手動でコピーして送信できるトラブルシューティングの URL があります。あるいは、ユーザーがユーザー インターフェースで [メール送信] をクリックすることもできます。

ユーザーが [メールを送信] をクリックすると、OAuth 同意画面で構成されているサポート メールアドレス（supportEmail）にメールが送信されます。OAuth 同意画面の構成の詳細については、IAP 用の OAuth クライアントをプログラムで作成するをご覧ください。

失敗したアクセスのトラブルシューティング

エンドユーザーから失敗したアクセス リクエストのリンクを受け取った場合に、その URL をクリックすると、URL がデフォルトのブラウザで開きます。デフォルトのブラウザで Google Cloud コンソールにログインしていない場合、Policy Troubleshooter の分析ページを表示するために、別のログインページにリダイレクトされることがあります。

Policy Troubleshooter の分析ページには、概要と IAM ポリシーのビューが表示され、ユーザーとデバイスのコンテキスト（プリンシパル アドレス、デバイス ID、アクセス対象の IAP リソースなど）を示すテーブルが表示されます。

概要ビューには、関連するポリシーとメンバーシップのすべての検出結果がまとめて表示されます。IAM ポリシービューには、付与されているかどうかに関係なく、有効な IAM バインディングの評価結果のリストと、エラーが発生した場所の概要が表示されます（プリンシパルはメンバーではなく、条件を満たさないなど）。

失敗したアクセスをさらに分析するには、[バインディングの詳細] を確認します。[バインディングの詳細] には、バインディング コンポーネント、ロール、プリンシパル、条件が表示されます。十分な権限があるコンポーネントには、[対応は不要です] と表示されます。アクセスに失敗したコンポーネントについては、プリンシパルのカテゴリ: プリンシパルを次のグループに追加してくださいなど、権限のギャップが明示的に説明されます。

ユーザー インターフェースの [関連バインディング] セクションはデフォルトでオンになっています。[関連バインディング] セクションに記載されているバインディングは包括的なリストではなく、特定のアクセスに関する問題のトラブルシューティングを行う際に役立つ可能性のある、関連性が最も高いバインディングです。特定のリソースに関連付けられた有効なポリシーには、プロジェクト レベルで付与された Cloud Storage 権限など、リソースに関係のない多くのバインディングが含まれている場合があります。無関係な情報は除外されます。

失敗した条件をさらに調査するには、アクセスレベルの説明を調べます。[アクセスレベル] の詳細は、障害が発生した場所を特定し、その障害を解決するための修正を提案します。必要なアクションをユーザーに返すことや、必要に応じてポリシーを修正することを行えます。たとえば、「デバイスが会社所有ではないため、リクエストを処理できませんでした」というアクションをユーザーに送り返すことができます。

Access Denied エラーのカスタムページ用トラブルシューティング URL を有効にする

ポリシーのトラブルシューティング URL はお客様の Access Denied エラーページに追加できます。手順は次のとおりです。

  1. 以下の手順で、ユーザーをデフォルトの IAP エラーページではなく、カスタムページにリダイレクトします。カスタム アクセス拒否エラーページの設定。
  2. IAP の設定で Policy Troubleshooter の URL 機能を有効にします。

IAP 設定で access denied ページ URL を構成すると、Policy Troubleshooter の URL がエスケープ クエリ パラメータとして埋め込まれます。開く前に、エスケープされたクエリ パラメータをエスケープ解除します。クエリ パラメータのキーは troubleshooting-url です。

ユーザー アクセスの事前トラブルシューティング

BeyondCorp Enterprise ランディング ページの [セキュリティ] パネルにある Policy Troubleshooter を使用して、架空のイベントのトラブルシューティングを行い、セキュリティ ポリシーの分析情報を得ることができます。たとえば、特定の IAP で保護されたリソースへのユーザーのアクセスをチェックし、それが実際に必要かどうかを調べることができます。また、IAP で保護されたリソースに対してポリシーを変更した場合に、特権管理者が引き続きアクセスできるかを確認することができます。Google 管理コンソールのデバイス コンソールに移動して特権管理者が所有するデバイス ID を取得し、トラブルシューティングでそのデバイス ID を使用してアクセス権を確認できます。

架空のリクエストのトラブルシューティングを行うことで、実際の拒否イベントが発生する前に、IAP リソースにアクセスするための適切な権限がユーザーに付与されていることを確認できます。これを行うには、ユーザーのメールアドレス、ターゲットの IAP リソース、および任意のリクエスト コンテキスト（IP アドレス、タイムスタンプ、デバイス ID、デバイス コンテキストなど）を使用します。

デバイス ID を使用して架空のリクエストのトラブルシューティングを行う場合、デバイスが対象のプリンシパルのメールアドレスに属していることを確認します。デバイス ID は、IAP 監査ログから、または [Google 管理コンソール] -> [デバイス] > [モバイルとエンドポイント] > [デバイス] から取得できます。

デバイスのコンテキストを使用して架空のリクエストのトラブルシューティングを行う場合、トラブルシューティングによって次の属性がサポートされます。

  • is_secured_with_screenlock
  • encryption_status
  • os_type
  • os_version
  • verified_chrome_os
  • is_admin_approved_device
  • is_corp_owned_device

一般的なトラブルシューティングのシナリオ

Policy Troubleshooter の使用時に発生する可能性のある一般的なシナリオは次のとおりです。

  • トラブルシューティングの後、エンドユーザーに会社所有デバイスへの切り替えやオペレーティング システムの更新を指示するなど、実行可能な項目を指定します。
  • エンドユーザーに適切な権限を割り当てていないことが判明したため、IAP インターフェース（roles/iap.httpsResourceAccessor）でターゲット プリンシパルの新しいバインディングを作成します。
  • アクセスレベルを誤って作成した理由として、次の例が考えられます。
    • 企業のサブネットワークなど、複雑なネストされた属性の制限を作成しましたが、これは従業員が現在在宅勤務しているため適用されることはなくなりました。
    • 不適切なアクセスレベルのパラメータを適用しました。たとえば、ユーザーがベンダー制限のあるカスタム レベルを作成できるように指定しましたが、属性を異なるタイプと比較しました。例: device.vendors["vendorX"].data.["should_contain_boolean_value"] == "true"左側はブール値を返し、右側は文字列 true を返します。属性が同等ではないため、ポリシー構造のエラーを検出することが困難です。Policy Troubleshooter は、これがエラーとして評価されたことを説明し、両側の詳細な部分的な評価結果を提供します。

トラブルシューティングにおける想定どおりの動作

トラブルシューティングは、現時点のポリシーと、現時点のタイムスタンプを持つデバイス情報を使用して、制限されたアクセスに対して行われます。そのため、アクセス制限の拒否後にデバイスを同期した場合やポリシーを変更した場合は、古いコンテキストとデータを使用したトラブルシューティングは行いません。現時点でのコンテキストとデータを使用してトラブルシューティングを行います。

バインディングのトラブルシューティングに関するヒント

承認エラーがあるバインディングのコンポーネント（ロール、プリンシパル、条件）で、そのようなバインディングのトラブルシューティング結果を確認するには、必要な権限を付与します。

バインディングでロールチェックが失敗した場合は、次の操作を行ってください。

  • 他のバインディングを確認するか、必要に応じて IAP インターフェースを使用して新しいバインディングを作成し、プリンシパルに該当するアクセスレベルの roles/iap.httpsResourceAccessor を付与します。
  • カスタムロールの場合は、ターゲット権限をカスタムロールに追加して権限を付与できます（該当する場合は、プリンシパルの障害および条件の障害を修正した後）。既存のカスタムロールに権限を追加すると、このカスタムロールを持つ他のバインディングに必要以上の権限が付与される可能性があることに注意してください。カスタムロールの範囲とオペレーションのリスクを把握している場合を除き、この操作は行わないでください。
  • カスタムロールでない場合は、他のバインディングを確認するか、必要に応じて IAP インターフェースを使用して新しいバインディングを作成し、プリンシパルに該当するアクセスレベルの roles/iap.httpsResourceAccessor ロールを付与します。

ロールのチェックが成功したにもかかわらず、プリンシパル チェックが失敗した場合は、次の操作を行ってください。

  • メンバーにグループが含まれている場合は、グループにプリンシパルを追加して、権限を付与します（該当する場合、条件のエラーを修正した後）。既存のグループにプリンシパルを追加すると、グループに必要以上の権限が付与される場合があります。グループの範囲とオペレーションのリスクを把握している場合を除き、この操作は行わないでください。
  • メンバーにグループが含まれていない場合は、他のバインディングを確認するか、必要に応じて IAP インターフェースを使用して新しいバインディングを作成し、プリンシパルに該当するアクセスレベルの roles/iap.httpsResourceAccessor を付与します。

ロールとプリンシパルのチェックが成功しても条件が失敗し、条件が OR 論理演算子と接続されたアクセスレベルのみで構成されている場合は、条件の下の一覧に示されている個別のアクセスレベルのトラブルシューティングに関する詳細を確認します。