【Google Cloudでセキュリティの柱を築く】Cloud Identityでのセキュリティ
こんにちは。今回はCloud IdentityおよびGoogle Workspaceでできるセキュリティ設定について触れたいと思います。Google Cloudを使う上で組織を用いる場合に必須になるのがCloud IdentityまたはGWSになります。既にドメインやディレクトリをEntra IDやLDAPなどで所有していた場合でもIDプロバイダーがGoogleCloudでは必須となります。Cloud IdentityはGoogle Cloudとは別に存在するものになります。
イメージとしてはAzureに近く、Entra IDテナントがCloud Identityに相当し、サブスクリプション以下が請求先アカウントやフォルダ/プロジェクトに相当するものです。ID払い出し元/管理先が別途構成されます。
Cloud Identityと組織の関係性
Google CloudはCloud Identityと組織が1対1で紐づく関係性になります。そのため、複数の組織を用意することは同数のCloud Identityを用意することと同義になります。その度にドメインを新規で取得し、組織を作成していきます。
組織を複数作成する背景としてあるのが、Cloud IdentityとGoogle管理コンソールで組織毎に異なる設定をしたい場合です。例えば、ある組織ではGoogle Cloudのみ利用できるようにして、ある組織ではGWSなどGoogle Cloudではないサービスだけ利用できるようにするといった使い分けがあります。Google Cloud側も同様になります。過去の記事で触れてきたChrome Enterprise Premium(旧Beyondcorp)や組織ポリシー、Access Context Managerを別設定で構成したい場合などもあげられます。
他にはQuotaの問題があります。組織で作成できるフォルダ/プロジェクト数には限界があり、それを上回るような規模で環境払い出しが行われると足りなく可能性があります。(ただし、非常に大規模な利用や全社的な展開がない限り、この問題は発生しにくいでしょう)
また、やむをえず企業買収や合併によって別の組織を管理しないといけなくなってしまった場合もあるでしょう。
IDと組織の紐付けを考える
複数のCloud IdentityとGoogle Cloud組織があった場合、どうすれば良いのかはIDをどこで管理したいかによって構成が変わります。というのも異なるIDをそれぞれ管理するのは煩雑かつ、別のセキュリティリスクを招くためです。ケースを考えていきます。
ケース：IdPがGoogle Cloudではないところにある
Entra ID, LDAP, OktaのようなIDプロバイダーから連携されるのは良くあるケースかと思います。社内でGWSでなく、Office365を使っていてGoogleCloudを利用したい場合やSSO基盤を別に構成していてIDを統一したい場合に取る構成です。IDプロバイダー側でMFAを有効化したり、特定のIPアドレスでないと認証させない条件付きアクセスのような機能で強固にすることができます。
しかし、IDプロバイダーから連携できるCloud Identityはひとつのみになります。そのため、複数のCloud Identityに対してIDを連携することが出来ません。一つのCloud Identityを管理せざるを得ないのがこの構成パターンです。IDプロバイダーがそもそも別なのであればCloud Identityを分けることも可能ですが、統制の観点からよろしくはありません。分けざるを得ない場合のみ検討しましょう。
ケース：IDは一つに統一したいが組織は複数構成したい
上記のケースのようにIDプロバイダーの制約や画一化のために一つのCloud IdentityでのみGoogleアカウントの払い出しを行いたい場合もあるかと思います。その時に取れる選択はCloud IdentityからのみGoogleアカウント払い出しを行い、他のCloud Identityは利用しないことです。こうすることでGoogleCloudの組織は2つ以上構成でき、IDプロバイダー(ここではX)からそれぞれの組織やプロジェクトにロールバインドすればよくなります。
IDプロバイダーと同じドメインの組織(ここではX)は同じドメインでロールバインドすればよいので特に気を付ける必要がありません。しかし、別ドメインの組織(ここでは組織Y)でロールバインドする対象はプロバイダーXから払い出されたGoogleアカウントと組織Yに属するサービスアカウントになります。プロバイダーXから払い出されたGoogleアカウントと、組織Yに属するサービスアカウントの両方に対してロールバインドが必要になります。これは、サービスアカウントが組織Yのドメインで管理されるためです。
組織Y内でサービスアカウントを使えるように、プロバイダーXのGoogleアカウントを使えるように組織ポリシーで両ドメインを追加する設定を入れる必要があります。
ちなみにこの設定がないとGmailのような個人アカウントや別Cloud Identityで払い出されたGoogleアカウントにもロールバインドできてしまいます。設定の有効化を強く推奨します。
ケース：IDも組織も別で構成したい(または別で構わない)
企業買収で2つ以上Cloud Identityを構成することになった場合や、GWSとGoogleCloudで2つCloud Identityを分けていた場合、検証用やシステム毎に組織を分ける構成の場合に取りうる構成です。ここは上記2つと違ってシンプルです。それぞれのCloudIdentiyからGoogleアカウントを払い出して、それぞれの組織にロールバインドします。
ここで気をつけたいのは別々でCloud Identityを構成するためにそれぞれの設定やIDプロバイダー連携が画一化されないことです。片方はMFA必須/アクセス制限がされているのに、片方は何も制約なし。そのような状態で双方の組織へロールバインドし合える関係だった場合、制限のないCloud Identityを経由して組織へアクセスされてしまう危険性があります。
また、いわゆる野良クラウドを許容してしまうことにもつながるためCloud Identityを複数構成する場合はその全てを把握し、セキュリティ設定がきちんと行われているのがわかる場合のみとするのが最善かと思います。
Cloud Identityの認証/認可
Cloud Identityの認証/認可に関わるセキュリティ設定は管理コンソールのセキュリティ画面から確認/設定することができます。いくつか主要なものを以下に記載します。
MFA設定
端末によるMFA認証をCloud Identity側で設定することができます。IDプロバイダーがOktaやEntra IDなどであればそちらでMFAを有効化して、こちらは有効にしないというのも全然ありです。プロセスが煩雑なだけなのとMFAデバイスをわざわざ分けるようなケースでないなら意味がないためです。MFAが突破されないように端末を分ける場合や、IDプロバイダーがCloudIdentityからなのであれば有効にすべきです。
高度な保護機能プログラム
MFAのように個別の端末でQRコードやアプリに登録されたパスキーを入力しないとログインできないよう設定できるものです。パスワードが漏れたとしてもパスキーを求められるようにすることでアカウントを保護できます。パスワード保護に相当するもののため厳密にはMFAとは異なるものとなります。そのため、MFAと二重で設定することもできます。
パスワードレス/パスワードの管理
パスワード入力の代わりに高度な保護機能プログラムで設定したパスキーのみで認証を許可する方法です。また、パスワード入力とする場合に文字数や有効期限の制限を指定することも可能です。ただし、これらはCloud Identityのみの構成パターンのみで外部のIDプロバイダーからID連携される場合はパスワードはIDプロバイダー側で管理されます。
Cloud Identityのライセンス
最後にCloud Identityは無償版と有償版があります。無償版でも多くの機能が利用可能ですが、アカウント発行数に上限があり大規模に利用する場合はほぼ強制でPremiumの有償版となります。
また、有償版の特徴としてPC端末やモバイル端末のChrome Enterprise機能との連携が強化されています。アクセス元の端末からの認証やセキュリティ機能が拡充されています。また、GWSとの連携でドライブ上のデータについてDLP処理を行うような機能も利用できます。
ただ、これらはいずれもIDプロバイダーが外部の場合だと必ずしも有用ではないため、、一定数のGoogleアカウント発行が必要で上限引き上げも難しい場合に有償版を利用するのがほとんどのケースかと思います。IDプロバイダーがCloud Identityのみだったり、GWSをメインで利用されている方は有償版を使うのは全然ありです。ただ、料金が人数単位の課金なので高額にならないよう注意が必要です。
まとめ
Google Cloud環境のセキュリティを考える上で、ID管理の基盤となるCloud Identityの役割と、その複雑な構成パターンについて触れてきました。
特に重要なポイントは、Cloud IdentityとGoogle Cloud組織が1対1で紐づくという基本原則と、複数の組織を扱う際のID管理の考え方です。外部のIDプロバイダーを利用する場合、または複数の組織を運用する場合、ドメイン制限付き共有などの組織ポリシーを活用して、一貫したセキュリティを保つことが不可欠です。
セキュリティを確保するためには、まずIDと組織の関係性を正しく理解し、自社の要件に合った構成を選択することが非常に重要です。
Discussion