権限設定の設計

このドキュメントでは、Google Distributed Cloud（GDC）エアギャップ ユニバースでの権限付与設計のベスト プラクティスについて説明します。この記事のトピックは次のとおりです。

次の設計は推奨されますが、厳密に守る必要はありません。各 GDC ユニバースには、個別に満たす必要のある固有の要件と考慮事項があります。

組織ごとに ID プロバイダを構成する

事業者は、組織ごとに 1 つ以上の ID プロバイダを構成する必要があります。管理者は、ID プロバイダに接続して、GDC ユニバースのアプリケーションの認証サービスを管理します。

会社に複数の部門があり、それぞれが個別の組織を持ち、各組織が同じ ID プロバイダに接続して認証を行うシナリオが考えられます。この場合、ユーザーが組織全体で持つ権限の組み合わせを把握し、監査するのはユーザーの責任です。複数の組織で権限を持つユーザーが、ワークロードを個別の組織に分離するための要件に違反しないようにします。

また、複数のベンダーチームが 1 つの組織内で連携している場合など、異なるユーザーセットが異なる ID プロバイダを使用して 1 つの組織内で認証を行うシナリオもあります。ユーザー ID を単一の ID プロバイダに統合するか、個別の ID プロバイダを維持するかが、会社の ID 管理アプローチに最適かどうかを検討します。

ID プロバイダの多要素認証を構成する

GDC は、多要素認証などの追加のセキュリティ設定を含む認証に IAM プラットフォームを使用します。機密リソースにアクセスする可能性のあるユーザーに対しては、物理キーを使用した多要素認証を構成することをおすすめします。

マネージド サービスとマーケットプレイス サービスを制限する

プロジェクトの潜在的な攻撃対象領域を制限したり、承認されていないサービスの使用を回避したりするために、特定のサービスから一部のプロジェクトをブロックすることが望ましい場合があります。デフォルトでは、AI や ML などのマネージド サービスは、どのプロジェクトでも使用できます。マネージド サービスとは異なり、マーケットプレイス サービスはまず組織に対して有効にする必要があります。

プロジェクトからのサービス アクセスを拒否するには、サービスのカスタム リソース定義と Namespace のリストに対して Gatekeeper 制約を適用します。Gatekeeper を使用してアクセスを拒否する方法は、マネージド サービスとマーケットプレイス サービスに適用されます。

複数のクラスタの kubeconfig ファイルを管理する

オペレーション タスクごとに、異なるクラスタへの接続が必要です。たとえば、IAM ロールをプロジェクトにバインドするタスクや、Kubernetes クラスタに Kubernetes Pod リソースをデプロイするタスクなどを行います。

GDC コンソールを使用する場合、クラスタへの接続などの低レベルのオペレーションは GDC コンソールによって抽象化されるため、どの基盤となるクラスタがタスクを実行するかを意識する必要はありません。

ただし、gdcloud CLI または kubectl CLI を使用する場合は、タスクを完了するために複数の kubeconfig ファイルが必要になることがあります。タスクに適したクラスタの kubeconfig 認証情報を使用してログインしていることを確認します。

Kubernetes サービス アカウントのベスト プラクティス

Kubernetes サービス アカウントの場合、承認はシークレット トークンに基づきます。サービス アカウント トークンのリスクを軽減するには、次のベスト プラクティスを検討してください。

  • GDC の外部で使用するために永続サービス アカウント認証情報をダウンロードしないようにします。
  • Pod の作成と編集が可能なユーザーまたはサービス アカウントの Kubernetes エスカレーション パスに注意してください。
  • ワークロードのサービス アカウント トークン プロジェクションの短い期間に expirationSeconds フィールドを設定します。
  • サービス アカウントの認証情報を定期的にローテーションします。

最小権限の原則を検討する

ユーザーにロール バインディングを付与する場合は、最小権限の原則（PoLP）を考慮してください。PoLP に従って、タスクの完了に必要な権限のみを割り当てることを検討してください。

たとえば、単一のプロジェクト内でプロジェクト IAM 管理者のロールをユーザーに付与し、そのユーザーがプロジェクト内でロールを付与する権限を委任できるようにします。このユーザーは、使用する特定のサービスに基づいて、プロジェクト内の他のデベロッパーにきめ細かいロールを付与します。プロジェクト IAM 管理者のロールは、信頼できるリードに制限する必要があります。このロールは、権限を昇格させ、プロジェクトで自分自身または他のユーザーに追加のロールを付与するために使用される可能性があるためです。

過剰な権限がないか定期的に監査する

組織内で付与されているロールを確認し、過剰な権限がないか監査してください。割り当てられたロールが個々のユーザーの職務の遂行に必要であり、プロジェクト間のロールの組み合わせによって権限昇格やデータ漏洩のリスクが生じないようにする必要があります。

会社で複数の組織を使用している場合、複数の組織にわたって高い権限を持つロールを個々のユーザーに割り当てることはおすすめしません。これは、組織を分離した理由に反する可能性があるためです。