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

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

BeyondCorp Enterprise を使用すると、企業はコンテキスト ベースのアプリケーション アクセスを実現する高度なルールを作成できます。ただし、リソースの制限からデバイスのルールまで複数のアクセスルールをリソースに適用すると、エンドユーザーがリソースにアクセスできない理由を理解するのが難しくなる場合があります。

管理者は Policy Troubleshooter を使用して、アクセスが失敗した理由を確認し、必要に応じてポリシーを変更して、エンドユーザーにアクセスを許可するようにコンテキストを変更できます。

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

始める前に

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

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

トラブルシューティング URL は、デフォルトの 403 ページでのみ表示されます。

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

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

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

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

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

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

失敗したアクセス リクエストのリンクを受け取ったら、URL をクリックするとデフォルトのブラウザで開きます。デフォルトのブラウザで Google Cloud Console にログインしていない場合は、別のトラブルシューティング ページにリダイレクトされ、ポリシーに関するトラブルシューティングの分析ページにアクセスできます。

[ポリシー トラブルシューティングによる分析] ページには、ターゲット プリンシパルのメールアドレス、ターゲットの IAP リソース URL、必要な権限など、制限付きアクセスの詳細が表示されます。付与されているかどうかに関係なく、Identity and Access Management(IAM)バインディングの効果的な評価結果のリストビューと、エラーが発生した場所を示す概要ビューも表示されます。プリンシパルはメンバーではなく、条件を満たしていない場合などが例として考えられます。

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

ユーザー インターフェースでは [関連バインディング] セクションがデフォルトで有効になっています。[関連バインディング] セクションに表示されるバインディングは、包括的なリストではなく、特定のアクセスの問題のトラブルシューティングにおいてユーザーが関心を持つ可能性があるバインディングの一例です。特定のリソースに関連付けられた有効なポリシーには、プロジェクト レベルで付与された Cloud Storage 権限など、リソースとは関係のないバインディングが多数含まれている場合があります。関連性のない詳細情報は除外されます。

失敗した条件は、[アクセスレベルの説明] で詳しく調べることができます。アクセスレベルの詳細で障害が起きた場所を示し、障害の解決に向けて修正を提案します。必要に応じて、ユーザーに必要なアクションを反映させるか、ポリシーを修正できます。たとえば、会社所有のデバイスではないため、リクエストが失敗しましたというアクションをユーザーに送信できます。

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

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

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

制限付きアクセスのトラブルシューティング

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

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

  1. MDM 管理者の権限を持つカスタムの Google Workspace 管理者ロールを作成します。
  2. 管理コンソールを使用してユーザーにロールを割り当てます。

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

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

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

トラブルシューティングで想定される動作

制限されたアクセスのトラブルシューティングは、現在のポリシーと現在のタイムスタンプのデバイス情報を使用して行われます。そのため、アクセスを制限した後にデバイスを同期したり、ポリシーを変更したりしても、以前のコンテキストやデータを使用したトラブルシューティングはできません。現在のコンテキストとデータを使用してトラブルシューティングを行っています。

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

認証エラーがあるバインディングのコンポーネント(ロール、プリンシパル、条件)について、このようなバインディングのトラブルシューティングの結果を確認するには、必要な権限を付与してください。

バインディングでロール チェックが失敗した場合は、次のアクションを行います。

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

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

  • メンバーにグループが含まれている場合は、プリンシパルをグループに追加して、権限を付与できます(状況によって障害が発生した場合は修正後)。プリンシパルを既存のグループに追加すると、必要以上の権限がグループに付与される場合があることに注意してください。グループのスコープと運用のリスクを把握しない限り、この操作は行わないでください。
  • メンバーにグループがない場合は、必要に応じて、他のバインディングを確認するか、IAP インターフェースを使用して新しいバインディングを作成します。その際、必要に応じて、アクセスレベルが適用されたプリンシパルに roles/iap.httpsResourceAccessor を付与します。

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