ID とアクセスを管理する

Last reviewed 2023-08-08 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、ID とアクセスを管理するためのベスト プラクティスを提供します。

Identity and Access Management（一般に IAM と呼ばれます）を活用すると、適切なユーザーが適切なリソースにアクセスできるようになります。IAM は、認証と認可の次の側面に対処するものです。

  • プロビジョニングを含むアカウント管理
  • ID ガバナンス
  • 認証
  • アクセス制御（認可）
  • ID 連携

環境が異なる場合や、複数の ID プロバイダを使用している場合は、IAM の管理が難しくなることがあります。ただし、リスクを軽減しながらビジネス要件を満たすシステムをセットアップすることが重要です。

このドキュメントの推奨事項は、現在の IAM のポリシーと手順を確認し、Google Cloud のワークロードで変更する必要があるものを判断するうえで役立ちます。たとえば、次の点を確認する必要があります。

  • 既存のグループを使用してアクセスを管理できるかどうか、または新しいグループを作成する必要があるかどうか。
  • 認証要件（トークンを使用した多要素認証（MFA）など）。
  • 現在のポリシーに対するサービス アカウントの影響。
  • 障害復旧に Google Cloud を使用する場合は、適切な職掌分散を維持します。

Google Cloud では、Cloud Identity を使用してユーザーとリソース、および Google の Identity and Access Management（IAM）プロダクトを認証して、リソースへのアクセスを指定します。管理者は、組織レベル、フォルダレベル、プロジェクト レベル、リソースレベルでアクセスを制限できます。Google IAM ポリシーには、「誰がどのリソースに対して何を行えるか」が規定されます。IAM ポリシーを正しく構成することで、リソースへの不正アクセスを防ぐことができます。

詳細については、Identity and Access Management の概要をご覧ください。

単一の ID プロバイダを使用する

多くのお客様のユーザー アカウントは、Google Cloud 外部の ID プロバイダによって管理、プロビジョニングされています。Google Cloud は、ほとんどの ID プロバイダや、Active Directory などのオンプレミス ディレクトリとの連携をサポートしています。

ほとんどの ID プロバイダでは、ユーザーとグループに対してシングル サインオン（SSO）を有効にできます。Google Cloud にデプロイし、外部 ID プロバイダを使用するアプリケーションの場合、ID プロバイダを Google Cloud に拡張できます。詳細については、リファレンス アーキテクチャとハイブリッド環境で企業ユーザーを認証するパターンをご覧ください。

既存の ID プロバイダがない場合は、Cloud Identity Premium または Google Workspace を使用して従業員の ID を管理できます。

特権管理者アカウントを保護する

特権管理者アカウント（Google Workspace または Cloud Identity によって管理）を使用すると、Google Cloud 組織を作成できます。そのため、この管理者アカウントには高い権限が付与されています。このアカウントのベスト プラクティスは次のとおりです。

  • この目的のために新しいアカウントを作成します。既存のユーザー アカウントを使用しないでください。
  • バックアップ アカウントを作成して保護します。
  • MFA を有効にします。

詳しくは、特権管理者アカウントのベスト プラクティスをご覧ください。

サービス アカウントの使用を計画する

サービス アカウントは、アプリケーションがサービスの Google API を呼び出すために使用できる Google アカウントです。

ユーザー アカウントとは異なり、サービス アカウントは Google Cloud 内で作成、管理されます。また、サービス アカウントはユーザー アカウントとは異なる方法で認証されます。

  • Google Cloud で実行されているアプリケーションがサービス アカウントを使用して認証できるようにするには、アプリケーションが実行されているコンピューティング リソースにサービス アカウントを接続します。
  • GKE で実行されているアプリケーションがサービス アカウントを使用して認証できるようにするには、Workload Identity を使用します。
  • Google Cloud の外部で実行されているアプリケーションがサービス アカウントを使用して認証できるようにするには、Workload Identity 連携を使用します。

サービス アカウントを使用する場合は、設計プロセスで適切な職掌分散を考慮する必要があります。必要な API 呼び出しを確認し、API 呼び出しに必要なサービス アカウントと関連するロールを決定します。たとえば、BigQuery データ ウェアハウスを設定する場合は、少なくとも次のプロセスとサービスの ID が必要になります。

  • Cloud Storage または Pub/Sub は、バッチファイルを使用するか、ストリーミング サービスを作成するかによって異なります。
  • Dataflow と Sensitive Data Protection を使用して機密データを匿名化します。

詳しくは、サービス アカウントの使用に関するベスト プラクティスをご覧ください。

クラウドの ID プロセスを更新する

ID ガバナンスを使用すると、アクセス、リスク、ポリシー違反を追跡して、規制要件に対応できます。このガバナンスでは、アクセス制御のロールと権限をユーザーに付与して監査できるように、プロセスとポリシーを導入する必要があります。プロセスとポリシーでは、テスト、開発、本番環境など、環境の要件を反映する必要があります。

Google Cloud にワークロードをデプロイする前に、現在の ID プロセスを確認し、必要に応じて更新します。組織に必要なアカウントの種類について適切に計画し、それらのロールとアクセス権の要件を十分に理解します。

Google Cloud では、Google IAM アクティビティを監査するために、以下を含む監査ログが作成されます。

  • 管理者のアクティビティ。このロギングは無効にできません。
  • データ アクセス アクティビティ。このロギングは有効にする必要があります。

コンプライアンス上必要な場合、または SIEM システムなどのログ分析を設定する場合は、ログをエクスポートできます。ロギングによってストレージ要件が増大する可能性があるため、費用に影響する場合があります。必要な操作のみをロギングし、適切な保持スケジュールを設定します。

SSO と MFA を設定する

ユーザー アカウントの認証は、ご利用の ID プロバイダによって管理されています。フェデレーション ID は、SSO を使用して Google Cloud に対する認証を行うことができます。特権管理者などの特権アカウントの場合は、MFA を構成する必要があります。Titan セキュリティ キーは、フィッシング攻撃の防止に役立つ 2 要素認証（2FA）に使用可能な物理的トークンです。

Cloud Identity は、さまざまな方法で MFA をサポートしています。詳細については、会社所有のリソースに均一の MFA を適用するをご覧ください。

Google Cloud は、OAuth 2.0 プロトコルまたは自己署名 JSON ウェブトークン（JWT）を使用したワークロード ID の認証をサポートしています。認証の詳細については、認証の概要をご覧ください。

最小権限と職掌分散を実装する

適切なユーザーが、業務の遂行に必要なリソースとサービスのみにアクセスできるようにする必要があります。つまり、最小権限の原則に沿う必要があります。また、適切な職掌分散が存在することを確認する必要があります。

ユーザー アクセスをオーバープロビジョニングすると、内部の脅威、リソースの構成ミス、監査違反のリスクが高まる可能性があります。権限のアンダープロビジョニングでは、ユーザーが自分のタスクの完了に必要なリソースにアクセスできなくなる可能性があります。

オーバープロビジョニングを回避する方法の一つは、ジャストインタイムの特権アクセス（すなわち特権アクセスは必要な場合にのみ付与し、一時的に付与する）を実装することです。

Google Cloud 組織を作成すると、デフォルトでドメイン内のすべてのユーザーに請求先アカウント作成者とプロジェクト作成者のロールが付与されます。これらの職務を行うユーザーを特定し、他のユーザーからこれらのロールを取り消します。詳しくは、組織の作成と管理をご覧ください。

Google Cloud でのロールと権限の仕組みについては、IAM ドキュメントの概要とロールについてをご覧ください。最小権限の適用の詳細については、ロールの推奨事項を使用して最小権限を適用するをご覧ください。

アクセスを監査する

特権アカウントのアクティビティに対して、承認された条件からの逸脱をモニタリングするには、Cloud Audit Logs を使用します。Cloud Audit Logs は、Google Cloud 組織のメンバーが Google Cloud リソースに行ったアクションを記録します。Google サービス全体で、さまざまな監査ログタイプを操作できます。詳細については、Cloud Audit Logs を使用した内部リスクの管理（動画）をご覧ください。

IAM Recommender を使用して使用状況を追跡し、必要に応じて権限を調整します。IAM Recommender が推奨するロールは、ユーザーの過去の行動やその他の条件に基づいて、ユーザーに付与するロールを決定するために役立ちます。詳細については、ロールの推奨事項のベスト プラクティスをご覧ください。

Google のサポート担当者とエンジニアリング担当者によるリソースへのアクセスの監査と制御を行うには、アクセスの透明性を使用します。アクセスの透明性では、Google の担当者による操作が記録されます。アクセスの透明性の一部であるアクセス承認を使用して、お客様のコンテンツにアクセスするたびに明示的な承認を付与します。詳しくは、データへのクラウド管理者のアクセス権を管理するをご覧ください。

ポリシー管理を自動化する

可能な限り、アクセス権をプログラムで設定します。ベスト プラクティスについては、組織のポリシーの制約をご覧ください。エンタープライズ基盤ブループリント用の Terraform スクリプトは、サンプル基盤リポジトリにあります。

Google Cloud には、アクセス権限を自動的に確認および更新できる Policy Intelligence が含まれています。Policy Intelligence には、Recommender、Policy Troubleshooter、Policy Analyzer ツールが含まれています。これらは次の処理を行います。

  • IAM ロールの割り当てに関する最適化案を提供します。
  • モニタリングにより、過剰な権限を付与する IAM ポリシーの設定を阻止します。
  • アクセス制御関連の問題のトラブルシューティングを支援します。

リソースに制限を設定する

Google IAM で重要なのは「誰であるか」です。権限に基づいて特定のリソースを操作できるユーザーを承認します。組織ポリシー サービスでは、内容に重点が置かれており、リソースの制限を設定して構成方法を指定できます。たとえば、組織のポリシーを使用して次のことができます。

これらのタスクに組織のポリシーを使用するだけでなく、次のいずれかの方法でリソースへのアクセスを制限できます。

  • タグを使用して、各リソースのアクセス権限を定義することなく、リソースへのアクセスを管理します。代わりに、タグを追加して、タグ自体のアクセス定義を設定します。
  • IAM Conditions を使用して、リソースへのアクセスを条件付きの属性ベースで制御します。
  • VPC Service Controls を使用して多層防御を実装し、リソースへのアクセスをさらに制限します。

リソース管理の詳細については、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。

次のステップ

IAM の詳細については、次のリソースをご覧ください。