セキュリティ & アイデンティティ

Google Cloud で ID とアクセスのガバナンス（IAG）を実現

2020年4月7日

https://storage.googleapis.com/gweb-cloudblog-publish/images/Google_Security-identity-04.max-2600x2600_2uMOIiK.jpg

Google Cloud Japan Team

※この投稿は米国時間 2020 年 4 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。

企業がオンプレミスのみのデプロイメントから、クラウドベースのサービスを使用した環境に移行すると、ID 管理が複雑になる可能性があります。ハイブリットやマルチクラウド環境での ID 管理は、特にその傾向が強くなるといえるでしょう。

Cloud Identity and Access Management（IAM）は、Google Cloud で ID とロールを管理するための方法を複数提供しています。その中でもとりわけ重要なのが、ID とアクセスのガバナンス（IAG）です。IAG は、ユーザーの ID とアクセス権限が安全で適切、かつ効果的に管理できるようにするための機能です。IAG を実現するための重要な一歩は、お客様のビジネスニーズに適合し、コンプライアンス要件を満たすアーキテクチャを設計することです。企業全体の ID ライフサイクルを管理するにあたって、次の主要タスクについて考慮する必要があります。

ユーザーのプロビジョニングとプロビジョニング解除
シングルサインオン（SSO）
アクセスリクエストとロールベースのアクセス制御（RBAC）
職掌分散（SoD）
レポートとアクセス権の見直し

この投稿では、これらのタスクについて取り上げ、Google Cloud の使用時における効果的な ID とアクセスのガバナンスを実現する方法を紹介します。

ユーザーのプロビジョニングとプロビジョニング解除

まずは基本から始めましょう。Google Cloud には、新しいユーザーの追加方法がいくつかあります。Cloud Identity は、Google Cloud と G Suite のユーザーやグループを定義、設定、管理するための一元化されたハブです。Cloud Identity はプロビジョニングと認証のソリューションであるのに対し、Cloud IAM は主に認可のソリューションと考えることができます。新しいユーザーを追加したら、Google Cloud IAM でそのユーザーやグループに権限を割り当てて、リソースへのアクセスを許可できるようになります。

ただし、組織固有の記録システムによって異なりますが、考慮すべきシナリオがいくつか存在します。

一元化された ID ストアとして、オンプレミスの Active Directory または LDAP ディレクトリを使用している場合

組織でのプロビジョニングでは、このパターンが最も一般的です。すべてのユーザーとグループをプロビジョニングするための一元化されたディレクトリサーバーを使用している場合、それを Cloud Identity の信頼できるソースとして使用できます。通常、組織のプロビジョニングソリューションは、信頼できるソースからの ID（HRMS または類似システム）をディレクトリに接続するため、新規採用 / 異動 / 退職（Joiner / Mover / Leaver）のワークフローがすでに備わっています。

オンプレミスのディレクトリを統合するために、Google は Google Cloud Directory Sync（GCDS）というサービスを提供しています。これにより、ユーザー、グループ、その他のユーザーデータを、一元化されたディレクトリサービスから Google Cloud ドメインディレクトリに同期できます（Cloud Identity は Google Cloud ドメインディレクトリを使用）。Cloud Directory Sync では、ユーザーステータス、グループ、グループメンバーを同期できます。これらの同期を行う場合、Active Directory（AD）グループに基づいて Google Cloud の権限を設定可能です。

また、マネージド Active Directory サービスを使用して、Active Directory をクラウドで実行することもできます。マネージド AD サービスを使用して、クラウドベースのワークロード向けにスタンドアロンドメインを複数のリージョンにデプロイしたり、オンプレミスの Active Directory ドメインをクラウドに接続したりできます。このソリューションは以下の場合に推奨されます。

Google Cloud で実行されている複雑な Windows ワークロードがあり、ユーザーとアクセスのニーズに合わせて Active Directory と緊密に統合する必要がある。
最終的には、オンプレミス環境から Google Cloud に完全に移行する予定でいる。この場合には、既存の AD 依存関係の構成方法に最小限の変更を加える必要があります。

主に別の ID 管理ソリューションでユーザーのライフサイクルを管理する場合

このシナリオ例では、一元化されたハブとしてのディレクトリを持っていません。代わりに、Okta、Ping、SailPoint などのリアルタイムのプロビジョニングソリューションを使用してユーザーのライフサイクルを管理します。これらのソリューションにより、Cloud Identity や User Management の API を使用してユーザーやグループメンバーの管理を行う、コネクタベースのインターフェース（通常「アプリケーション」または「アプリ」と呼ばれる）が提供されます。

新規採用 / 異動 / 退職（Joiner / Mover / Leaver）のワークフローはこれらのソリューションから直接管理されます。Google Cloud へのユーザーのアクセスと同様に、Cloud Identity アカウントは退職ワークフローによって終了イベントが処理されるとすぐに無効になります。異動ワークフローの場合、ユーザーが職責を変更すると、その変更は新しい Google Cloud 権限を定義する Cloud Identity のグループメンバーに反映されます。

自社製の ID 管理システムを使用している場合

カスタムの自社製 ID システムは、組織の複雑さを既成のサービスで処理できない場合や、商用サービスよりも高い柔軟性を組織が求めている場合によく見られます。このシナリオの場合、最も簡単なのはディレクトリを使用することです。LDAP に準拠するディレクトリシステムを使用して Cloud Identity と連動できます。カスタムの ID 管理システムを介してプロビジョニングされたユーザーとグループは、Cloud Identity のカスタムプロビジョニングソリューションを作成しなくても Cloud Directory Sync を使用して Cloud Identity と同期できます。

シングルサインオン

シングルサインオン（SSO）を使用すると、再認証したり別のパスワードを維持したりせずにアプリケーションにアクセスできます。認可は通常、認証されたユーザーが特定のリソースへのアクセスを許可されていることを確認するための 2 番目のレイヤとして提供されます。ユーザーのプロビジョニングやプロビジョニング解除と同様に、SSO の使用方法も環境に応じて異なります。

Google 認証システムで G Suite を使用する場合の SSO: この場合、Google Cloud ログインに特別な変更はありません。Google Cloud と G Suite の両方で同じログインが使用されているため、適切なアクセスがプロビジョニングされている限り、ユーザーは通常の認証情報を使用して Google Cloud Console にログインできます。
サードパーティの ID 管理ソリューションで G Suite を使用する場合の SSO: G Suite のサインオンがすでに有効になっていれば、Google Cloud のサインオンも動作します。新しい G Suite と Google Cloud ドメインが確立された場合、ID 管理プロバイダと Cloud Identity を使用して新しい SAML 2.0 準拠の統合を作成できます。たとえば、Okta と OneLogin は、すぐに使えるアプリを使用して構成可能な SAML 2.0 の統合を提供しています。
オンプレミスの ID ソリューションを使用した場合の SSO: Cloud Identity は、Google Cloud のプロビジョニングと認証を制御し、オンプレミスの ID プロバイダとの SAML 2.0 準拠の統合を構成する方法を提供します。
マルチクラウドモデルを使用した場合の SSO: 複数のクラウドサービスプロバイダを使用する場合、Cloud Identity を使用するか、サードパーティの ID プロバイダに投資して、ID の信頼できる単一のソースを取得できます。

アクセスリクエストとロールベースのアクセス制御

Google Cloud では「プロジェクト」がリソースとワークロードをホストする最上位のエンティティです。ユーザーやグループを使用して、プロジェクトへのアクセスを提供するために使用されるロールのメンバーを定義します。編成を容易にし、制御の分離を維持するために、プロジェクトをフォルダにグループ化し、フォルダレベルでアクセス権を付与できますが、原則は変わりません。Google Cloud 内には、ワークロードに基づくいくつかのロールがあります。たとえば BigQuery を使用している場合、BigQuery 管理者、BigQuery データ編集者、BigQuery ユーザーなどの事前定義されたロールをユーザーに割り当てられます。おすすめの方法は、常に Google グループにロールを割り当てることです。

Google グループは、ディレクトリ環境または ID 管理ソリューションから Cloud Identity に同期されます。ここでも、Cloud Identity を認証システム、Cloud IAM を認可システムと考えることができます。これらのグループは、プロジェクト要件に基づいてモデル化し、ID 管理システムに公開できます。その後、エンドユーザーが要求したり、エンタープライズロールを使用してジョブ要件に基づいて自動的に割り当てたりすることができます。

Google Cloud の組織を、ワークロードを分離するように構成する方法の一つは、組織のビジネス構造を反映するフォルダを設定し、組織内のさまざまなチームにアクセス権を付与するやり方と一致させることです。

最上位のフォルダに事業（LOB）を反映させる
LOB フォルダの下には部門フォルダがある
部門フォルダの下にはチームフォルダがある
チームフォルダの下には本番環境用のフォルダがある（例: 開発、テスト、ステージング、本番）

このように構造化したら、この階層に基づいてアクセス制御用の Active Directory または ID 管理プロバイダのグループをモデル化し、それらをロールに基づいて割り当てるか、アクセス要求と承認のために公開します。また、発生しうる緊急事態を管理するためにユーザーに付与できる、「非常時用」アカウントの要求手順と事前承認されたロールも必要となります。

再編成が頻繁に起こる組織では、フォルダのネストを制限できます。柔軟性とセキュリティのバランスを保てる限り、フォルダの構造を抽象化したり深めたりすることができます。このバランスを実現する方法の 2 つの例を見てみましょう。

以下の図は、事業単位ベースの階層アプローチを使用して Google Cloud の組織を構造化する例を示したものです。この構造の利点は、必要に応じてきめ細かくできることですが、再編成などの組織の変更をサポートしていないため、構造を維持していくことが困難です。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_-_example_granular_access-oriented_hiera.max-1700x1700.jpg

次は、環境ベースの階層アプローチを Google Cloud の組織に使用する例を示します。この構造では、ワークロードを細かく制御して実装できるだけでなく、Infrastructure-as-a-Code（例: Terraform）を使用して簡単に実装できます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_-_example_granular_access-oriented_heira.max-1700x1700.jpg

職掌分散

職掌分散（SoD）は、少なくとも 2 人のユーザーがタスクに責任を負うようにすることで、エラーや不正行為を防止するように設計された制御です。Google Cloud では SoD を実現するために複数の方法を提供しています。

前のセクションで示したように、Google Cloud のリソース階層により、職責と役職に基づいて分離を提供する構造が作成可能。例として、ある業務部門で作業を行う運用エンジニアは、通常、別の業務部門のプロジェクトにアクセスできない、財務アナリストはデータ分析を扱うプロジェクトにアクセスできない、などが挙げられます。
IAM カスタムロールが定義可能。これは、すぐに使えるロールとしてまとめることができます。
リソース階層のさまざまなレベルでグループにロールをバインドすることが可能。この強力な機能により、バインドの作成方法に基づいて、グループを組織レベル、フォルダレベル、プロジェクトレベルに設定できます。

組織レベルでロールを定義する方法の例を次に示します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_-_example_org-level_groups.max-1400x1400.jpg

次の図では、「セキュリティ管理者グループ」を定義し、組織レベルで IAM ロールを割り当てています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_-_example_security_admin_group.max-1700x1700.jpg

同じようにして、フォルダレベルまたはプロジェクトレベルで定義できるグループについて考えることができます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_-_example_folder_and_project-level_groups.max-800x800.jpg

たとば、以下では「サイト信頼性エンジニア」グループを定義し、フォルダレベルまたはプロジェクトレベルで適切な IAM ロールを割り当てています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/6_-_example_site_reliability_engineers.max-1700x1700.jpg

レポートとアクセス権の見直し

ユーザーは、直接アクセス権を付与されるか、組織レベルまたはフォルダレベルから継承することによって、プロジェクトにアクセスできます。これにより、Google Cloud 内で「誰が何にアクセスできるのか」に関するレポートのコンプライアンス要件を満たすのが少し難しくなる場合があります。

このマスターリストは、Cloud Asset Manager API や、gcloud の search-all-iam-policy コマンドを使用して取得できますが、より適切なのは Asset Manager API のエクスポート機能を使用して IAM ポリシーを BigQuery にエクスポートする方法です。このデータが BigQuery で利用可能になったら、データポータルで分析することも、任意のツールにインポートすることもできます。

すべてを組み合わせる

ID とアクセスのガバナンスは容易な作業ではありません。このブログを読み終えた後、Google Cloud で対処する必要がある問題において解決方法を明確に理解できるようになっていれば幸いです。Google Cloud での IAM の詳細については、テクニカルドキュメントもしくは Cloud Next ‘19 でのプレゼンテーションをご覧ください。

- By セキュリティとコンプライアンス担当スペシャリスト Prashant Kulkarni

投稿先