Google Cloud へのアクセス制御方法とソリューション

はじめに

こんにちは、入社式初日に会社から貸与されたpcの初期名が hen.ekiken になっていた 潘 (Han) と申します (ekiken は下の名前です) 。私事ですが、Cloud Ace に新卒入社して2年が経過したところで初の zenn 記事投稿になります。拙い文書ではありますが、皆様の一助になれば幸いです。

概要

Google Cloud（旧 Google Cloud Platform）環境にアクセスする際に、どう言った要件でアクセス制御するのかは会社それぞれです。今回はアクセス制御の要件と、それを実現する Google Cloud のソリューションをご紹介致します。

アジェンダ

今回は以下の4つの要件によってどういったソリューションが最適かご紹介致します。 (必要に応じて今後アップデートする予定です。)
1. アカウントでアクセス制御したい
2. アクセス元 IP アドレスでアクセス制御したい
3. 特定のドメインでアクセス制御したい
4. 特定のドメイン+アクセス元 IP アドレスでアクセス制御したい

前提

• 想定読者
  Google Cloud を導入し立てでセキュリティをどう高めれば良いかわからない、という初学者 ~Google Cloud 導入直後の開発者向けの記事となっています。
• Google Cloud における組織を理解している
  今回紹介するサービスはほとんど Google Cloud の組織を導入することによって使用可能になるサービスです。まずは組織について理解を深めた上で読んでいただけるとすんなり理解できるかと思います。
• アクセスプロセス
  Google Cloud におけるアクセス制御には Google Cloud 環境に対するアクセス制御と、各種プロダクトに対するアクセス制御 があり、基本的には Google Cloud 環境に対するアクセス制御が各種プロダクトへのアクセス制御に先んじる物になります (Google Cloud の用語としてアクセスプロセスという概念があるわけではありませんが、初学者が理解する際にこのように切り分けると分かりやすくなると思います) 。すなわち、そもそも Google Cloud 環境に対するアクセスができないユーザーは各種プロダクトにアクセスすることはできないはずです。今回ご紹介するのは、前者の Google Cloud 環境に対するアクセス制御 になります。
  

説明すること、しないこと

• 説明すること
  各種ソリューションについて概略図を用いながら、どういった制御をするかに応じて最適なサービスのご紹介を致します。加えて、各サービスのメリットと注意事項について表でまとめて比較します。また、個人の所感ベースにはなりますが、各サービスの適用優先度も示そうと思います。

• 説明しないこと
  各種機能の詳細な仕様や細かな実装手順については省略させていただきます。詳細な仕様については公式ドキュメントのリンクを添付しているのでそちらをご参照ください。本記事はあくまで概要レベルでイメージを持っていただくことを目的としたものとなっております。

1. アカウントでアクセス制御したい

一つ目はアカウントでアクセス制御したい場合についてです。こちらについては、言わずと知れた Google Cloud の IAM の機能が最適です。最も基本的なアクセス管理のツールで、基本的には IAM でアクセス制御を行うことになります。
IAM ではアカウント(プリンシパル) と、そのアカウントに許可する権限(またはロール) を紐づけることでアカウントベースでのアクセス制御を可能にします。Google のベストプラクティスでは事前定義されたロールをアカウントに付与することが推奨されていますが、中には過剰な権限も含まれている場合もあるので、設定するロールは慎重に選定しましょう。

IAM メリット	注意事項	適用優先度
アカウントベースでの制御が可能	最小権限の法則に則ること	高

2. アクセス元 IP アドレスでアクセス制御したい

続いて、アクセス元 IP アドレスでアクセス制御したい場合についてです。会社の IP アドレスのみから Google Cloud 環境にアクセスできるようにしたい場合などを想定しています。こちらについては、VPC Service Controls(以下 VPC-SC ) というサービスが最適です。VPC-SC とはプロジェクトに境界を敷き、グローバルなエンドポイントを持つ Google Cloud の API を保護することで外部からのアクセスを制御する仕組みになります。 VPC-SC の細かな仕様については割愛しますが、ここではアクセス元 IP アドレスレベルでアクセス制御ができるサービスとしてご認識いただければと思います。こちらは組織を導入することによって使用可能になるサービスです。
簡単に設定手順を説明すると、まず Access Context Manager というサービスでアクセスレベル(アクセス元をホワイトリスト形式で記述してグルーピングしたもの) を定義します。この記事で想定しているケースではアクセス元の IP アドレスを指定しますが、他にもアクセス元のユーザーアカウント、サービスアカウント、デバイスを指定することが可能です。その後、プロジェクトに対して VPC-SC の境界を設定します。この境界はアクセスレベルからのアクセスしか許可しないように設定することが可能になっています。
考慮事項としては VPC-SC での制御はIAMよりも先んじて適用されるため、たとえ IAM でアクセス権が付与されているユーザーでも、 VPC-SC で制限がかけられている環境においてはアクセス制御の対象となるということです。IAM とは独立したアクセス管理になるため管理の煩雑さは増えますが、 IAM と併用することでセキュリティレベルとしてはかなり高いものになります。以下に概略図を示します。

VPC-SCメリット	注意事項	適用優先度
IAMと併用することで よりセキュアな制御が可能	管理が煩雑になることにより 管理工数が増大する	中

3. 特定のドメインでアクセス制御したい

続いて、特定のドメインからのアクセスのみ受け付けるように設定したい場合についてです。例えば、自分が所属している会社のアカウントのドメインを持つ組織に属する人にしかアクセス権を付与したくない場合などを想定しています。こういったケースでは 組織のポリシー を使用するのが良いでしょう。組織のポリシーとは組織のリソース階層に対して適用する制約のことで、組織・フォルダ・プロジェクトレベルで制約を適用することができます。こちらの機能も組織を導入することによって使用可能になるサービスとなります。
組織ポリシーの制約の中に、ドメイン別の ID の制限 というものがあり、こちらを適用すると IAM ポリシーを適用する ID を特定の組織に属する ID または、一つ以上のドメインセットを指定して絞ることが可能になります。こちらで許可されたユーザーアカウントまたはドメインを持つ ID のみが、この制約が適用された環境に対してアクセスできるようになります。
こちらも簡単な設定方法を説明すると、組織ポリシーのドメイン制限はリスト型制約になっているため、 allowed_values リストに許可値の ID またはドメイン (例. example.corp.com) を追加・削除していくといったものになります。拒否値はサポートされていないため、 denied_values リストに ID を保存することはできません。また、VPC-SC 同様 IAM よりも先んじて適用されるため、設定事項や設定値をしっかりと管理しておける体制を整えておかないと、疎通エラーなどにより開発速度に遅れが生じる可能性があります。以下に簡単な概略図を掲載します。

組織ポリシーメリット	注意事項	適用優先度
ドメインレベルや ID レベルで アクセス制御が可能	・管理が煩雑になることにより 管理工数が増大する ・組織ポリシーの継承を考慮して、 適切なスコープに制約を適用する。	下

4. 特定のドメイン+アクセス元IPアドレスでアクセス制御したい

最後は少し応用になりますが、特定のドメインを持つ ID かつ特定の IP アドレス範囲のアクセス元からのみアクセスを許可する場合についてです。こちらを実現するには先述した VPC-SC と Beyondcorp Enterprise の機能を組み合わせます。Beyondcorp Enterprise は、　VPN を使わずに、インターネット経由で安全に社内システムや SaaS などへアクセスさせるゼロトラストネットワークを実現するサービスです。ただし、デバイスがブラウザとして Google Chorome を使用していることが必要 になります。Beyondcorpd Enterprise の細かい各種機能については割愛しますが、アクセスレベルとグループアカウントを紐づけてアクセス制御する機能があり、こちらを使用するとそのグループアカウントに所属しているユーザーに対してはアクセスレベルの IP アドレス範囲からのみアクセスを許可するという制御を実施する事ができます。この機能でアクセス制御した際、アクセス権のないユーザーが Chrome のブラウザ経由でコンソールにアクセスしようとすると以下のような画面になります。

この機能もコンソール画面から簡単に設定可能ですが、いくつか注意点があります。以下は Beyondcorp Enterprise の設定画面の抜粋です。
上記にあるように、ただ Beyondcorp Enterprise を使用しただけでは、グループアカウントに所属していないユーザーおよび、グループアカウントに所属していても組織のドメインに含まれないユーザーは制御の対象外となります。(以下画像をご参照ください。)

この状態だと、組織のドメインを持っているかつグループアカウントに所属しているユーザーについてはセキュアなアクセス制御を実施できますが、そうでないユーザーについては IAM で許可してしまえば Google Cloud のコンソールにアクセスできてしまうということになります。そこで先述した VPC-SC と組み合わせることで、グループアカウントに所属している組織のドメインを持っているユーザーかつ、特定の IP アドレス範囲のアクセス元からのみのアクセスを許可するという非常にセキュアなアクセス制御が実施できます。以下の概略図のように、アクセスレベルに所属していないユーザーは VPC-SC の境界に弾かれてアクセスができなくなります。ただし、アクセスレベル内に入っており、グループアカウントに所属していないユーザーは引き続き Beyondcorp Enterprise の制御の範囲外になるのでここは注意が必要です。

アクセス管理の場所が IAM 、アクセスレベル、Beyondcorp Enterprise の3つになり構造としてもかなり複雑になるので、ここまでのアクセス制御をするにはかなり緻密な事前設計が必要になると思いますが、非常にセキュリティ要件が厳しいプロジェクトに対してもこの方法でセキュアなアクセス制御が実現できます。

Beyondcorp Enterprise + VPC-SC メリット	注意事項	適用優先度
ドメインとアクセス元 IP アドレスの 両方を考慮したセキュアな制御が可能	・管理が煩雑になることにより 管理工数が増大する ・構造が複雑なため、緻密な事前設計が必要	中

まとめ

今回は、 Google Cloud 環境に対する各種アクセス要件を実現するためのソリューションをご紹介いたしました。アカウントベースでアクセス制御できる IAM が基本のソリューションにはなりますが、プラス α でさらにセキュアなアクセス制御を実施したい場合は、開発工数なども考慮しつつ上記の方法をご検討いただければと思います。