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

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

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

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

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

始める前に

ポリシーのトラブルシューティングはプレミアム機能であり、BeyondCorp Enterprise ライセンスが必要です。

ポリシーのトラブルシューティングで最大の効果を得るには、セキュリティ審査担当者のロール(roles/iam.securityReviewer)が必要です。この役割を持っていれば、適用可能なすべての Cloud IAM ポリシーを確実に参照できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ポリシーに関するトラブルシューティング分析ページには、要約ビュー、IAM ポリシービュー、ユーザーとデバイスのコンテキスト(プリンシパル アドレス、デバイス ID、アクセスする IAP リソースなど)を示す表があります。

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

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

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

失敗した条件を詳しく調べるには、アクセスレベルの説明を確認します。アクセスレベルの詳細で障害が起きた場所を示し、障害の解決に向けて修正を提案します。必要なアクションをユーザーに戻したり、必要に応じてポリシーを修正したりできます。例えば、以下のようなアクションをユーザーに送り返すことができます。デバイスが企業で所有されていないため、リクエストが失敗しました

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

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

  1. 以下の手順で、ユーザーをデフォルトの IAP エラーページではなく、カスタムページにリダイレクトします。カスタム アクセス拒否エラーページの設定
  2. IAP 設定でポリシーに関するトラブルシューティングの URL 機能をオンにします。

IAP で access denied ページの URL を構成すると、ポリシーに関するトラブルシューティングの URL がエスケープクエリ パラメータとして埋め込まれます。クエリ パラメータのキーは troubleshooting-url です。

ユーザー アクセスを積極的にトラブルシューティングする

BeyondCorp Enterprise ランディング ページの [セキュリティ] パネルにあるポリシー トラブルシューティングを使用すると、架空のイベントをトラブルシューティングしたり、セキュリティ ポリシーに関する分析情報を得たりすることができます。たとえば、特定の IAP 保護リソースに対するユーザーのアクセス権を確認し、本当に必要かどうかを判断できます。もう 1 つの例として、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

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

ポリシーのトラブルシューティングでは、次のようなシナリオが考えられます。

  • トラブルシューティングの後、エンドユーザーに会社所有デバイスへの切り替えやオペレーティング システムの更新を指示するなど、実行可能な項目を指定します。
  • エンドユーザーに適切な権限が割り当てられていないことが判明したため、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 論理演算子と接続されたアクセスレベルのみで構成されている場合は、条件の下の一覧に示されている個別のアクセスレベルのトラブルシューティングに関する詳細を確認します。