ID とアクセスを管理する

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

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

ID とアクセス管理(一般的に 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 の概要をご覧ください。

単一のアイデンティティ プロバイダを使用します

多くのお客様は、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 呼び出しを確認し、サービス アカウントと関連する役割を決定します。たとえば、BigQuery データ ウェアハウスを設定する場合は、少なくとも次のプロセスとサービスの ID が必要になります。

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

詳しくは、サービス アカウントの操作のベスト プラクティスをご覧ください。

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

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

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

Google IAM のアクティビティを監査できるように、Google Cloud は次のような監査ログを作成します。

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

コンプライアンス上必要な場合、または 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 監査ログを使用します。Cloud 監査ログは、Google Cloud 組織のメンバーが Google Cloud リソースに対して行った操作を記録します。Google サービス間で、さまざまな監査ログタイプを使用できます。詳細については、Cloud Audit Logging を使用した内部リスクの管理(動画)をご覧ください。

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

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

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

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

Google Cloud には Policy Intelligence が含まれており、アクセス権を自動的に確認、更新できます。Policy Intelligence には、RecommenderPolicy TroubleshooterPolicy Analyzer の各ツールが含まれます。これは、次の処理を行います。

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

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

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

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

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

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

次のステップ

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