Google Cloud のアクセス管理をおさらいしよう 2020アップデート版
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2020 の 2日目の記事です。
TL;DR
本記事ではGoogle Cloud でのアクセス管理について整理していきます。
はじめに
Google Cloud Japan Customer Engineer Advent Calendar 2019 で、Google Cloud の IAM をおさらいしよう という記事を書いたのですが、多くの方に読んでいただいたのですが、逆に多くの方が悩まれるトピックなのだなと感じました。2020年も多くのアップデートがありましたので、改めて Google Cloud の アクセス管理をおさらいしていきましょう。
クラウドを使う上で、ユーザー管理や権限管理は非常に重要です。Google Cloud を使う際に、どのようにユーザー管理できるのか、権限管理や認証認可を整理しつつ2020年のアップデートも含めていきます。関連するプロダクトが非常に多岐に渡るので、全部を紹介することはできないのですが、今回は、以下のプロダクトをピックアップしていきたいと思います。
Identity and Access Management（ 以下、IAM ）：権限付与を管理
Cloud Identity：ユーザー管理に使用
Resource Manager：権限制御の階層構造を提供
Identity and Access Management のユーザーと権限
Google Cloud では権限管理を Identity and Access Management というもので管理することができます。IAMでは、誰が、どのような操作を、何に対して行うことが出来るかというものを定義・管理します。これによりアカウントの追加・削除や権限付与がシンプルになり、管理が容易になります。
Google Cloud で利用できるアイデンティティ
Google Cloud で権限を付与できるアイデンティティには、Google アカウントや、Google アカウントを束ねた Google グループ、またサービスアカウントといったものがあります。
まずは人が実際に利用するアイデンティティである Google アカウントについておさらいしましょう。
1. 個人利用の Google アカウント
こちらはいわゆる「Gmail アカウント」となります。また知らない人も多いのですが、既存の会社ドメインのメールアドレスでも「個人利用の Google アカウント」が取得できます。この場合、Gmail 機能は利用できません。どちらも個人で利用開始できてとても便利な反面、企業として利用する場合に管理が行き届かないことが多く発生すると思います。Google Cloud を利用する方々は、企業のみとは限らないと思うのですが、ここでは「共通の目的をもって協働する人々のグループ／組織」を企業と表現します。Google Cloud のリソースに「組織」というものがあり、混同しやすいためです。この記事の中で、「組織」と表現した場合はGoogle Cloud の組織リソースを指します。
2. 企業管理のユーザーアカウント
企業で Google Workspace を導入している場合、そのユーザをそのまま利用することができます。パートナーなど、社外のユーザーが Google Cloud 環境にアクセスする場合もあるかもしれません。そのときは Cloud Identity を利用して、メール機能を利用しないユーザーを管理することができます。よりエンタープライズな機能を利用したい場合は、Cloud Identity Premium が利用できます。Cloud Identity と Cloud Identity Premium の違いはこちらを参照してください。
私は企業で Google Cloud を利用する場合には、企業管理のユーザーを使うようにおすすめしています。それはセキュリティやディレクトリ管理、監査など多くのメリットがあるためです。例えば
- パスワード ポリシー
- セキュリティ キーを用した2要素認証の強制
- Active Directory との連携
- SAML 対応
- ログイン監査ログ
- アクティビティレポート
などがあります。企業管理のユーザーを使う（＝”組織”を利用する）際に、ドメイン認証を行う必要があるのですが、ドメイン認証を行うことで、技術サポートに問い合わせ可能になります。組織を使うことで Google Cloud のリソースに組織ポリシーを適用し、セキュリティの強化にも繋がります。
Cloud Identity や Google Workspace で払い出された Google アカウントは Cloud 以外の Google サービスでも利用することが可能です。Cloud のユーザー管理はできていても、それ以外のサービスは管理できていなかった、というケースもあるのではないでしょうか。
これらのGoogleアカウントに加え、以下のアイデンティティに対しても権限付与を行うことが可能です。
3. ビジネス向けGoogle グループ（以下、単にGoogle グループ）
Google Workspace や Cloud Identity では、ビジネス向けのGoogle グループを利用できます。こちらは独自ドメインで利用でき、かつユーザーをまとめる機能として活用できます。また Cloud Identity のベータ機能(2020/12/02)である、動的グループを使うことで、役職や勤務地などの従業員属性のクエリにより自動的にグループのメンバーを管理することが可能です。
4. サービスアカウント
システムなどの利用で、人以外が使うアカウントとして、サービスアカウントというものがあります。こちらは例えば Google Cloud のAPI を VM instance などから利用する場合に必要になってきます。サービスアカウントはリソースとしてもアカウントとしても扱うことができるため、アカウントのように権限を付与するだけではなく、ユーザー扱えるサービスアカウントを制限することが可能です。詳細はこちらを参照してください。
サービスアカウントの種類と管理
サービスアカウントにも実は種類があります。
1. ユーザー管理のサービスアカウント
こちらはユーザーにより作成されるサービスアカウントです。チュートリアルやハンズオンでよく作成しているのはこちらになります。こちらはユーザー自身で最小権限にカスタマイズしたり、異なるアプリケーションごとに利用できますが、ユーザー自身が管理する必要があります。
2. Google 管理のサービスアカウント(サービスエージェント)
こちらは Google により作成されるサービスアカウントで、様々な Google サービスと Google Cloud を連携する時に使われたりします。サービスエージェントと呼び方が変わりました。Google Cloud プロジェクトにアクセスするための IAM 役割が自動的に付与されます。こちらはユーザーでカスタムすることは出来ません。
3. デフォルトのサービスアカウント
こちらはリソースを有効化した時に、自動で作成されるものになります。こちらは自動で作成されますが、管理はユーザーで行う必要があります。デフォルトで編集者権限が付与されており、強い権限となっています。エンタープライズで利用する際には、組織ポリシーの「デフォルトのサービス アカウントへの自動的なロール付与を無効にする」を利用することをおすすめしています。
さらにサービスアカウントを表すサービスアカウント キーにも2種類あります。
1. Google Cloud 管理のサービスアカウント キー
こちらは Google Cloud 内部でアプリケーションを実行している時に利用可能なもので、ダウンロードしたりすることは出来ません。キーのローテーションは自動で行われます。App Engine や Compute Engine 上で実行されているアプリケーションなどが利用するケースが代表的かと思います。
2. ユーザー管理キー
こちらはユーザー自身で管理するサービスアカウント キーですが、Google Cloud の外から Google Cloudの API を利用できるようになります。例えば「オンプレミスのシステムから BigQuery にデータをロードするとき」といった利用シーンが想像しやすいかもしれません。
ユーザー自身がキーを作成し、ダウンロードし、管理します。配布や取り消し、ローテーションもユーザー自身で行う必要があります。
サービスアカウントに対する権限付与ですが、Google アカウント同様に権限付与することが可能で、もちろんプロジェクトをまたぐことも出来ます。サービスアカウントへの権限付与は、テクニックがあり、そちらを紹介します。たとえば、Google スプレッドシート（以下、単にスプレッドシート）でマスターデータを管理していて、サービスアカウントを用いて Google Cloud のシステムからスプレッドシートのマスターデータにアクセスして読み込ませているユーザーの方も多いのではないでしょうか？ 従来では、Domain-Wide Delegation と呼ばれる Google Workspace ドメイン全体の権限を与える機能を利用し、サービスアカウントに強い権限を付与しなければなりませんでした。
Cloud Identity Groups（Beta）を利用するとサービスアカウントを Google グループに所属させることが可能です。サービスアカウントがメンバーに含まれたグループに対してスプレッドシートのアクセス権を付与することが出来るので、スプレッドシート レベルの権限管理が簡単に利用できるメリットがあります。
付与できる操作の権限
ここまで「誰が」というところを紹介してきました。ここから「どのような操作を」について紹介していきます。Google Cloud では権限は全て API で管理されており、サービス名、リソース、動詞という命名規則をもって定義されています。 基本的にはサービスの動作と API は一対一の関係にあります。
例えば、GCEであれば、
compute.instances.delete
compute.instances.get
compute.instances.list
compute.instances.setMachineType
compute.instances.start
compute.instances.stop
といった形です。しかし、これらを一つ一つ権限付与していくのは大変なので、特定の操作でまとめて付与できるようにしたものが、役割、となります。
役割と権限の関係
役割は事前定義されたものや、カスタムで細かく設定したものを付与する事ができますが、あまり細かく設定すると、管理面で煩雑さが増してしまうので、事前定義されたもので間に合うのであれば、そちらの利用をおすすめします。
役割を付与する際に、おすすめしているのが Google グループに役割を付与する方法です。これにより、ユーザーを抽象化し、グループの管理をするだけでプロジェクトやリソースにアクセスできるユーザーを管理できます。
権限の対象
「何に対して」権限の対象は、組織、フォルダ、プロジェクトに設定でき、一部のサービスリソース、請求先アカウントは個別に、さらに権限を設定していくことができます。権限は、プロジェクト、もしくはフォルダに設定していくケースが多いかと思います。Google Cloud のリソースを企業で利用する場合は、こちらの図のように、階層構造を作ることができ、上位階層で付与した権限は下位の階層に継承されます。上位で設定された権限は、下位のリソースで剥奪することができないので、マネージャーがフォルダ全体の閲覧権限をもっていて、見られたくないプロジェクトからその閲覧権限を剥奪することは出来ません。また、サンドボックスフォルダに対して、全デベロッパーがプロジェクト作成権限を持つことで自由に検証をする環境を整えておく、こともできます。また部署ごとのフォルダ配下し、管理者のみプロジェクトを作成することができる、といった運用にすることも可能です。
フォルダとプロジェクトの階層構造
Google Cloud の利用料は請求アカウントと呼ばれるリソースに紐づき課金されます。請求アカウントに関しても個別の権限の付与ができます。そのため経理の管理者とプロジェクトの管理者を切り分けることが可能です。詳しく知りたい方は、こちらを参考にしてみてください。
組織利用の際のフォルダ戦略
企業で利用する際、「どのようにフォルダを構成するか」はよく悩む問題かと思います。企業／部署の中で、権限を移譲できる単位で分けましょう、とご案内していますが、いくつかのパターンがありますので、利用する企業／部署の規模や仕組みにあわせて検討してください。障害時の影響範囲を限定するため、基本的に本番環境と開発環境のプロジェクトは分けるようにしましょう。
環境で分ける
開発環境と本番環境などでフォルダを構成するパターンです。本番環境と開発環境は、利用する人・チームの権限が分かれることが多いと思いますので、権限管理がやりやすいメリットがあります。
機能ごとに分ける
企業／部署や開発スタイルがマイクロサービスになっている場合は、機能ごとに構成するのが良いかも知れません。この場合、機能を開発するチームが開発環境・本番環境を利用できる方が、生産効率はあがりそうです。
チームで分ける
企業／部署が大きくなってきてチームの中でも更に権限が分散する必要がある場合は、チーム単位で構成することもよいでしょう。この場合コストもフォルダごとに参照でき、わかりやすいです。その配下に上記のような環境ごと、機能ごと、の構成を追加していくことも可能です。
またフォルダには以下のような制限があります。リソース設計の際に参考にしてみてください。
- フォルダのネストレベルは 10 個まで。
- 親フォルダ内に作成できるフォルダは 300 個まで
- フォルダの表示名は、階層内の同じレベルでユニーク
組織ポリシーの適用
組織ポリシーを利用すると、ドメインに紐づくリソースの使用方法に制限を適用することが可能になります。例えば、どこのロケーションを利用するか、どのプロダクトの利用を許可するか、サービスアカウントの作成を制限する、といった制御が可能です。適用可能なポリシーはこちらを参照ください。
組織ポリシーは、こちらも IAM の権限同様に、組織、フォルダ、プロジェクトに設定することにより、そのリソースと子リソースに制限を適用します。
より柔軟なアクセス制御のために
ちょっと企業でのアクセス管理とは話がそれてしまいますが、Google Cloud には以下のような便利な機能もありますのでご紹介します。
Identity-Aware Proxy
Identity-Aware Proxy（IAP）は App Engine、Compute Engine、 Google Cloud Load Balancing へのアクセス（HTTP、SSH、TCP）をユーザー単位で許可する仕組みを提供します。また Identity Platform と連携し、管理されているユーザーのみアクセスさせることも可能です（Google アカウントのアクセス許可と共存はできません）。Access Context Manager のアクセスレベルと連携して、アクセスするユーザーの Context を条件にすることが出来ます。
IAM Conditions
去年時点ではベータだった IAM Conditions も GA となりました。こちらはどのような条件下で実行できるか、という更に細かい設定が可能になります。たとえば日中時間帯からのアクセスは管理者権限、それ以外からのアクセスの場合は閲覧者権限で操作を制限するといったことが可能です。
Access Context Manager
Access Context Managerを使用すると、Google Cloud のプロジェクトとリソースに対するきめ細かい属性ベースのアクセス制御を定義できます。例えばアクセス元のデバイスやOS、IPアドレス、ユーザーIDなどの属性によって制御できます。Access Context Managerで定義するルールは、「アクセスレベル」と呼ばれ、IAP のアクセス許可の条件の1つとしても利用できます。
VPC Service Controls
Google Cloud のAPIに対して、境界と呼ばれる仮想境界を作りアクセスとデータの流れを制御します。アクセスに関しては、VPC におけるFirewallみたいなものをイメージしやすいかもしれません。データの流れに関しては、BigQuery や Cloud Storage などに保管されているデータの、プロジェクトからの持ち出し防止として機能します。アクセス制限には、Access Context Manager で定義したアクセスレベルを適用できます。
アップデートまとめ
Resource Manager（リリースノート）
アップデートは組織ポリシーに関連するものがほとんどでした。
[10/12] Essential Contacts がプレビューとなりました。重要な情報の通知先を、ここでカスタマイズできます。
Identity and Access Management（ IAM ）（リリースノート）
[2/13]IAM Recommender がGAしました。こちらは付与されているロールと、過去 90 日間に使用した権限とを比較し不要な権限を推奨する機能になります。
[2/18]IAM Conditions が GAしています。上記で説明したやつです。
[4/1]サービスアカウントキーを使用してGoogleCloud にアクセスすると、監査ログで使用されたキーが識別されるようになりました(エイプリルフールではないです)。企業／部署で利用している場合にこの機能は嬉しいんじゃないでしょうか？
[8/14] Cloud Monitoring でサービス アカウントとキーの使用状況のモニタリングがベータで利用できるようになりました。不要となったサービスアカウントやそのキーの識別に役立つかと思います！
[8/15] サービス アカウントの公開鍵のアップロードがGAになっています。ユーザーが管理する鍵ペアの公開鍵の部分を、サービス アカウントにアップロードでき、サービス アカウントに永続的に関連付けられます、他のユーザー管理サービス アカウント キーと同じように使用されます。
[8/28] Credential Access Boundaries が Beta になっています。有効期限の短い認証情報でアクセスできるスコープの境界を定義するものです。
さいごに
本記事ではアクセス管理に関して概要を説明してきました。少しでも権限管理・フォルダ設計など、役に立ちましたら幸いです。今年の Google Cloud 環境の権限整理は今年のうちに。
明日 2020–12–03 は gossy さんによる “Firebase update summary 2020” です。乞うご期待を!!
