Google の FAQ (よくある質問) とトラブルシューティング

回答

1. コンソールで、[設定] > [統合] に移動します。
2. 組織の横にある三点リーダーアイコンをクリックし、[編集] をクリックします。
3. [次へ] をクリックしてウィザード (スコープ) の最後のステップに移動します。
4. [特定のフォルダーとプロジェクトを除外する] を選択してから、対象のフォルダーまたはプロジェクトを選択します。
5. [終了] をクリックします。ご使用の環境内で Tenable が次回 データの同期と更新の頻度 ときに、コンソールから削除されます。

回答: 関連するすべてのロールバインディングを表示するために、Tenable に親レベルの範囲 (組織) でアクセス許可を付与する必要があります。この機能がないと、Tenable は GCP リソースに関する重要なセキュリティ情報 (有効なアクセス許可など) を提供できません。ロールバインディングは組織レベルで付与されますが、Tenable は組織自体、または組織内の特定のプロジェクトが Tenable にオンボーディングされていない限り、他の組織レベルのデータにアクセスすることができません。

GCP でプロジェクトを削除した後、そのプロジェクトが完全に削除されるまでに 30 日かかります。30 日が経過すると、Tenable はプロジェクトをシステムから自動的にオフボーディングします。Google Cloud ではこの期間中の削除を取り消すことができるため、必要に応じて GCP でプロジェクトを復元できるよう、Tenable では 30 日を経過するまでシステムからデータを削除しません。詳細については、関連する Google ドキュメント{target=_blank}を参照してください。

組織のメンバーが、組織のドメインを使用して、独自に Google アカウントを作成した可能性があります。このようなアカウントは、Google によって管理されていないユーザーアカウントと見なされ、Tenable はそれを外部アカウントとして分類します。詳細については、Google ドキュメント{target=_blank} を参照してください。

Terraform は GCP 組織の接続でのみサポートされています。

回答: このロールの名前で誤解を招くかもしれませんが、このロールによって Tenable は、クエリ経由で環境とやり取りを行うサービスアカウントに効果的になりすます{target=_blank} こと (権限の借用) ができます。

これは、サードパーティの GCP 環境に接続するうえで最も安全な方法であると Tenable は考えています。

他のベンダーが使用する別の方法として、ユーザーマネージドアクセスキーの作成があります。この場合は手動のローテーションが必要なため、危険にさらされる可能性があります。ここで権限借用を使用する利点は、Tenable のサービスアカウントに静的な認証情報を関連付けないことで、サイバーエクスポージャーのリスクを軽減できることです。サービスアカウントの権限借用とサービスアカウントキーを参照してください。

回答: GCP ドキュメント{target=_blank}によると、サービスアカウントの権限借用は、権限借用に事前に認証されたアイデンティティが必要であり、作成された認証情報は保持されないため、サービスアカウントキーを使用する場合よりも安全です。これに対し、サービスアカウントキーによる認証では事前の認証は必要ありませんが、永続的なキーが漏洩した場合は、リスクの高い認証情報となります。

回答: Tenable はお使いの環境でスーパー管理者ユーザーを必要とする、特定の Google API にアクセスする必要があります。これは、アイデンティティおよびその他の一般的なクラウドセキュリティ機能に必要です。以下は API のリストの一部です。

• https://developers.google.com/admin-sdk/reference-overview
• https://cloud.google.com/identity/docs/ja/apis

ただし、Tenable に実際に付与されるアクセス許可は、お使いのワークスペースを追加する際に付与される OAuth スコープに制限されます。これらのアクセス許可はすべて読み取り専用です。したがって、Tenable には必要な API にアクセスできるスーパー管理者の権限が必要ですが、実際には読み取り専用のアクセス許可のみが付与されるため、リスクを抑制できます。

Tenable Google Workspace のオブジェクトをクエリする唯一の方法は、ドメイン全体の委任とユーザーのなりすましを使用することであり、これにはユーザーのメールアドレスが求められるため、Tenable にメールアドレスが必要となります。サービスアカウントが Google Workspace にアクセスする方法の詳細については、Google のドキュメント{target=_blank}を参照してください。このユーザーにメールボックスは必要ありません。

回答: ドメイン全体の委任は、アプリケーションに関連ユーザーデータへのドメイン全体のアクセス権を付与するために使用される Google Workspace のメカニズムです。この権限の委任は、OAuth 2.0 のサービスアカウントを使用して行われます。Google Workspace は本質的に GCP に接続されているため、この委任を通じて付与されるアクセスにより、Tenable は GCP 資産を理解するための基本的な情報を収集および提供できるようになります。

このアクセスがない場合、Tenable は以下を実行できません。

• Google Workspace ユーザーを、使用する GCP リソースにマッピングする。
• GCP のアクセス許可はグループに付与できるため、Google Workspace ユーザーをグループにマッピングする。
• ユーザー/グループのアクセス許可グラフを作成する。
• GCP で権限を昇格できる強力な Google Workspace アクセス許可を持つユーザーを特定する (スーパー管理者など)。

ドメイン全体の委任により、Tenable は管理者を含む、任意の Google Workspace ユーザーの権限を借用できます。厳密に言うと、Tenable にスーパー管理者のアクセス許可があるように見えるかもしれませんが、実際にはそうではありません。Tenable には Google Workspace 内での管理者のアクセス許可がありません。Tenable に付与される実際の権限は、ドメイン全体の委任の設定時に定義された特定の OAuth スコープに制限されます。これらのアクセス許可は Google Workspace への読み取りアクセスのみを Tenable に付与します。

詳細については、関連する Google Workspace のドキュメントを参照してください。https://developers.google.com/admin-sdk/directory/v1/guides/delegation

回答: このロールには、Tenable が以下を行うために必要な Tenable サービスアカウントの API アクセスを管理する権限が含まれています。

• お使いの環境で現在使用している一部のサービスについてクエリを実行する
• 新しい GCP サービスがリリースされ次第、自動的にサポートする

このロールの名前で誤解を招く恐れがあるものの、このロールによって Tenable は GCP 環境から設定データを収集するために必要な API を効果的に有効化できます。この機能がないと、Tenable は上記の機能を実行できません。

割り当てはプロジェクトごとに GCP で管理され{target=_blank}、Tenable のサービスアカウントは単一のプロジェクトに割り当てられるため、このロールに含まれるアクセス許可の範囲は制限されます。別のプロジェクトでサービスの API アクセスを明示的に有効にしない限り、Tenable はそれにアクセスできません。Tenable のサービスアカウントは、オンボーディングプロセス中に追加された専用プロジェクトから新しいサービスをクエリできますが、環境のクォータを変更することはできません。

クラウドサイバーエクスポージャー は現在、GCP 環境のすべてのサービスとアクセス許可をプログラムでマッピングしています。つまり、新しい GCP サービスがリリースされるとすぐに、基本的なアクセス許可を付与され Tenable で確認できます。