はじめに

企業における事業部門や開発部門といったユーザ部門がパブリッククラウドを利用するにあたり、情シス部門(または情シス部門に相当する組織)がパブリッククラウド利用における内部統制やコスト管理を担当するケースは多いかと思います。

AWS といったパブリッククラウドを既に利用している企業であっても Google Cloud を新たに管理することとなった場合、Google Cloud 特有のアーキテクチャや用語の違いに直面し、何から検討を始めて良いか迷うケースも少なくありません。

本記事では、情シス部門がこれから Google Cloud を企業に導入、または既に導入している Google Cloud を統合管理することとなった場合に、最低限知っておくべき管理の基礎知識を説明していきます。これらの知識を身につけることで、企業への Google Cloud 導入のファーストステップとして何を検討すべきか？が理解できるかと思います。

なお、詳細なアーキテクチャや設定手順、サービスの購入方法についての説明はいたしません。しかし、本記事を読んだうえで公式ドキュメントを参照いただくことで、より深く理解ができるよう執筆しました。

本記事が企業への Google Cloud 導入の一助となれば幸いです。

Google Cloud を始めるために

まず、ユーザが Google Cloud の利用を開始するには最低限以下が必要となります。

1. Google アカウント
2. Google Cloud プロジェクト
3. Cloud 請求先アカウント

Google アカウントとは

Google アカウント とは、様々な Google サービスにアクセスするためのアカウントです。Google サービスとは、例えば Gmail や Google ドライブ、Google ドキュメント、Google フォト、YouTube や Gemini アプリなどのことです。これらの Google サービスの中に Google Cloud も含まれます。Google アカウントにログインすることで Google Cloud にアクセスすることができるようになります。

Google アカウントは example@gmail.com や xxxx@example.com といったメールアドレスの形式で表されます。

Google アカウントは、無料で提供されるアカウントと、企業や学校などの組織で管理されるアカウントの大きく2つに分類されます。

無料で提供されるアカウントは @gmail.com ドメインのメールアドレスや、個人が持つ他ドメインのメールアドレス(キャリアメールなど)を Google アカウントとするものです。

企業や学校などの組織で管理されるアカウントは Google Workspace や Cloud Identity のサブスクリプションを購入することによって統合管理できるもので、企業ドメインのメールアドレスを Google アカウントとして利用することができます。

Google Cloud プロジェクトとは

Google Cloud プロジェクト とは、Google Cloud サービスを利用するうえでの最小単位となります。

前述の Google アカウントで Google Cloud にアクセスして Google Cloud プロジェクトを作成し、Google Cloud プロジェクト上にリソースを作成してサービスを利用していきます。

Cloud 請求先アカウントとは

Cloud 請求先アカウント とは、Google Cloud プロジェクトの利用料金を支払いするために管理されるアカウントです。

Cloud 請求先アカウントでは支払い方法を設定し、Google Cloud プロジェクトを紐づけます。

紐づけた Google Cloud プロジェクト は Cloud 請求先アカウントで設定した方法で支払いされます(クレジットカードや請求書払い)。逆に言うと Cloud 請求先アカウントを Google Cloud プロジェクトと紐づけなければ料金の支払いができないため、Google Cloud プロジェクト上にリソースを作成することはできません。

1つの請求先アカウントに複数の Google Cloud プロジェクトを紐づけることができ、企業が管理する Google Cloud プロジェクトの料金を纏めて支払いすることができます。

なお、Google Cloud 販売パートナーの請求代行サービスを利用する場合、販売パートナーが用意する Cloud 請求先アカウントである 請求先サブアカウント をプロジェクトに紐づけることで、プロジェクトで利用した料金は販売パートナーを通じて請求されることとなります。Google Cloud 販売パートナーの請求代行サービスは、割引や円建てでの支払い、テクニカルサポートといった販売パートナー独自のサービス を受けることができるものです。

Google Cloud を始めるために まとめ

一旦纏めますが、Google Cloud を利用するうえで最低限必要なものは以下の3つであることがわかりました。

1. Google アカウント
2. Google Cloud プロジェクト
3. Cloud 請求先アカウント

しかし、企業で Google Cloud を導入する場合、以下のような検討事項が出てきます。

• Google アカウントを自社ドメインで一元管理したい。
• 既に利用しているメールアドレスを Google アカウントとして利用したい。
• 企業で管理してない Google アカウントで Google Cloud にアクセスさせないようにしたい。
• Google Cloud プロジェクトに統一的なセキュリティベースラインを適用したい。
• Google Cloud プロジェクトの料金管理を効率化したい。また、コスト削減を図りたい。

これらの検討は企業の情シス部門(または情シス部門に相当する組織)が検討/導入の担い手になるケースが多いかと思います。
次の章では情シス部門がこれから Google Cloud を企業に導入、または既に導入している Google Cloud を統合管理することとなった場合に、知っておくべき知識について説明します。

企業における Google Cloud の導入

企業に Google Cloud を導入する場合に、まずは以下のトピックについて検討すべきでしょう。

• Google アカウントの ID 統合管理
• Google Cloud のアクセス権管理
• Google Cloud プロジェクトの統合管理
• 組織全体のコスト管理

これらのトピックで利用できるサービスや機能、仕様についての説明をしていきます。

Google アカウントの ID 統合管理

企業で Google アカウントを利用する場合、自社ドメインでのアカウント管理、入社/退社時のアカウント追加/削除、二要素認証の強制といったセキュリティレベルの統一化、ログインログの管理、などを目的とした ID の統合管理は必須となります。もちろんですが、個人で利用するアカウント(@gmail.com など)ではこれらの統合管理はできません。

Google アカウントの ID を統合管理するためには Google Workspace または Cloud Identity のサブスクリプション購入が必要となります(Cloud Identity には無料のエディションもあります)。Google Workspace または Cloud Identity を利用してどのように Google アカウントの ID 管理を行うのか解説していきます。

Google Workspace

Google が提供する組織向けのグループウェアであり、Gmail / Google カレンダー / Google ドライブ / スプレッドシート / Gemini アプリなどが利用可能なサービスです。この Google Workspace で利用できるサービスを管理するためのコンソール画面である 管理コンソール(Admin Console) を利用して、Google アカウントを統合管理することができます。

既に Google Workspace を利用されている企業であれば、 Google Cloud を利用するために必要な Google アカウントは Google Workspace によって既に管理されている ということになります。

Cloud Identity

Microsoft 365 などを導入している企業では Google Workspace のグループウェア機能は不要かと思います。Google アカウントは管理したいけど、Gmail や Google カレンダーといったグループウェアサービスは不要といったケースで利用できるサービスが Cloud Identity です。Cloud Identity は Google Workspace の ID 管理やエンドポイント管理のみを利用できるようにしたサービスです。

Cloud Identity も Google Workspace と同様の管理コンソール から Google アカウントの管理を行います。

Cloud Identity には Free Edition と Premium Edition があります。
Free Edition は無償で利用できますが、サポートの制限やエンドポイント管理などの機能制限に加え、ユーザ数が最大50まで という制限があります。
Premium Edition は利用ユーザ分のライセンス購入が必要となりますが、サポートや高度な管理機能が利用でき、ユーザ数の上限はありません。

Google Cloud にアクセスするユーザは50名以下、高度なアカウント管理機能は不要、であれば Free Edition でも問題無い でしょう。

シングルサインオンの構成

既に Microsoft Entra ID などの IdP(Identity Provider) で ID を一元管理している場合、新たに Google Workspace や Cloud Identity で Google アカウントを作成すると ID 管理が複雑になります。Google Workspace または Cloud Identity は企業で管理する IdP からのユーザ同期と、SAML や OIDC によるシングルサインオンをサポートしています。これにより、既存の IdP で ID を一元管理しながら、これらの ID を Google Cloud などの Google サービスにアクセス可能な Google アカウント とすることができます。

Google アカウントは Google Cloud で管理するわけではない

ここまでの説明でお分かりの通り、Google アカウントの ID 管理は Google Cloud で行うわけではありません。 Google サービスの中で Google Cloud しか使わないユーザにはややこしいと思いますが、Google Workspace または Cloud Identity の ID 管理機能で Google アカウントを管理し、Google Cloud に対するアクセス権を Google Cloud の Identity and Access Management(IAM) で管理する、というのが正しいです。

次章では Google Cloud にアクセスする Google アカウントに対するアクセス権の管理について説明していきます。

Google Cloud のアクセス権管理

Google Cloud にアクセスできるユーザにおいても、管理者以外のユーザには操作できるリソースを制限するといった適切なアクセス権管理によって、情報セキュリティ事故や操作ミスによる障害といったリスクを軽減することができます。例えば以下のように細かなアクセス権の管理を実装することで、企業の役割や責任に応じたアクセス制御が可能になります。

• 管理者は全ての操作が可能
• 開発チームはサーバレスサービスへのデプロイ操作が可能、インフラサービスの操作は不可
• インフラメンバーはデータベースやストレージの操作が可能だが、サーバレスサービスの操作は不可
• その他ユーザは閲覧のみ可能

Identity and Access Management(IAM)

Google Cloud でこのようなアクセス権の管理を実現するのが Identity and Access Management(IAM) です。IAM は Google アカウントを持つユーザに対し、どのリソースに対しどのような操作を許可(拒否)するか、を定義することができます。IAM では権限ひとつひとつをユーザに設定するのではなく、権限のセットである IAM ロール を適用することでアクセス権を管理します。AWS の IAM ロールとは定義が全く違いますのでご注意ください。

IAM に設定するユーザは Google アカウントである必要があります。Google アカウントであれば、企業の Google Workspace や Cloud Identity で管理している Google アカウントでなくても構いません。 gmail.com といった個人アカウントや他の企業で管理している Google アカウントでも IAM に設定することができます。

しかし、自社で管理していないユーザを自由に IAM に追加できるということは、ガバナンスが利かせられず意図しない利用を招くリスクがあります。後述しますが、IAM に追加するユーザを自社ドメインの Google アカウントに制限する こともできますので、情シス部門ではこのような制限を設定して適切なアクセス権の管理体制を構築することが重要となります。

Google Cloud プロジェクトの統合管理

企業の事業部門や開発部門といったユーザ部門は、Google アカウントを利用することで Google Cloud プロジェクトを自由に作成し利用を開始することができます。しかし、企業利用において適切なガバナンスやセキュリティ管理が必要であり、無秩序なプロジェクト作成はコスト超過やセキュリティリスクを招く恐れがあります。このようなケースで有効活用できるのが Google Cloud の 組織 というリソースです。

組織リソース

組織リソースは プロジェクトのルートリソース であり、組織で設定した IAM やセキュリティ、「組織ポリシー」 と呼ばれるリソースの利用に対する制限などの設定を、組織配下のプロジェクトに対して継承させることができます。組織で設定を集中管理することによって、容易に管理対象プロジェクトに対するガバナンスを利かせることができるようになります。

フォルダリソース

組織を作成すると フォルダ というリソースを作成することができます。フォルダはプロジェクトをグループ化することができます。たとえば、部門ごとに複数のプロジェクトが存在する場合、部門単位でフォルダを作成してグループ化できます。

フォルダに設定した IAM などの設定も配下のプロジェクトに継承されます。部門ごとのフォルダに対し、個別のIAM 設定や組織ポリシーを適用することで、対象部門配下のフォルダやプロジェクトに対して設定を継承させることができるため、プロジェクトのグループ管理を容易にすることができます。

IAM の継承

IAM はプロジェクトだけでなく、組織とフォルダに対しても設定することができます。組織やフォルダに設定した IAM 設定は上位リソースから継承されます。上位リソースで設定した IAM は、下位リソースで変更することができません。 例えば、組織リソースに対して「オーナー」の IAM ロールを付与したユーザは、組織配下のフォルダとプロジェクトでも「オーナー」が継承して付与されています。組織配下のフォルダとプロジェクトで、組織リソースから継承されたユーザの「オーナー」ロールは削除したり、変更することはできません(追加することは可能です)。

たとえば、情シス部門はプロジェクト全体を管理対象としつつ、フォルダ単位で必要なユーザに対し必要な権限だけを付与する、などといった柔軟なアクセス権管理を IAM の継承によって容易に導入することができます。

組織ポリシーの継承

組織ポリシー とはリソースの利用に対する制限を強制する設定です。たとえば、物理的なロケーションを制限したり、セキュリティ上リスクのある操作を制限することなどが可能です。この組織ポリシーは組織/フォルダ/プロジェクトに対して設定することができ、上位リソースから下位リソースに設定が継承されます。組織ポリシーの継承により、情シス部門はプロジェクトに対して、Google Cloud の利用におけるルールを強制し統合管理できるようになります。

例えば、組織リソースで「東京リージョン以外のリソース作成を拒否」という組織ポリシーを設定すると、配下のフォルダとプロジェクトでも同様の設定が継承されます。ただし、配下のリソースで「オーナー」の IAM ロールを持つユーザなどは、そのリソースで組織ポリシーを書き換えできてしまうので注意が必要です。

また、IAM の章で、

IAM に追加するユーザを自社ドメインの Google アカウントに制限することもできます

と説明しましたが、これは Domain restricted sharing(constraints/iam.allowedPolicyMemberDomains) という組織ポリシーの設定によって実現できます。 この設定は IAM に追加するユーザを自社ドメインの Google アカウントのみに制限することができます。

組織リソースの作成方法

組織リソースを作成することは、Google Cloud を利用するうえで必須ではありません。 しかし、組織を作ることで Google Cloud プロジェクトを統合的に管理しやすくなる点はここまでの説明でご理解いただけたかと思います。

では、組織リソースはどのように作成できるのでしょうか。実は組織を作成するためには Google アカウントの ID 管理の章で説明した Google Workspace または Cloud Identity が必要となります。これらのサービスは ID 管理で必要となるものですが、組織を作成するためにも必要となります。

組織リソースは Google Workspace または Cloud Identity で ドメインの関連付け を行うことで作成されます。ドメインの関連付けとは、企業が所有するドメイン(example.com など) を Google Workspace または Cloud Identity に紐づける作業です。この関連付けが完了すると、関連付けしたドメイン名の組織リソース(example.com を関連付けした場合、組織リソース名は example.com となる)が自動的に Google Cloud 上に作成されます。また、そのドメインのユーザーが作成するすべてのプロジェクトは、この組織リソース配下に作成されるようになります。

ドメインの関連付けは Google Workspace のコンソールである 管理コンソール(Admin Console) で行います。少しややこしいですが、ドメインの関連付けによって作成された組織リソースは、Google Workspace や Cloud Identity のリソースではなく Google Cloud のリソースとなります。そのため、作成された組織リソースに対して IAM や組織ポリシーの設定を行う場合は、Google Workspace の管理コンソールではなく、Google Cloud のコンソール画面から管理します。

組織全体のコスト管理

情シス部門として、企業全体の Google Cloud プロジェクトで発生した費用を管理するケースもあるかと思います。企業で利用している Google Cloud のコストを把握し、必要に応じてコストの効率化を行っていく必要もあります。ここからはコスト管理をする上で知っておくべき知識を身につけていきます。

Cloud 請求先アカウントのアクセス権

Cloud 請求先アカウントは Cloud Billing と呼ばれる料金管理のためのツールセットで管理することができます。Cloud Billing で Cloud 請求先アカウントにアクセスし、請求レポート、予算アラート、確約利用割引といったサービスを利用してコスト管理します。Cloud 請求先アカウントにアクセスするには、Cloud 請求先アカウントリソースに対するユーザへの Billing 専用の IAM ロール(請求先アカウント管理者など) の付与が必要となります。

Google Cloud 販売パートナーの請求代行サービスを利用する場合、Cloud 請求先アカウントは販売パートナーから発行されます(請求先サブアカウントと呼ぶ)。請求先サブアカウントは販売パートナーが管理するリソースとなるためアクセス権の管理も販売パートナーが行います。必要な権限は販売パートナーに付与してもらうよう依頼しましょう。

請求の最小単位は「プロジェクト」

冒頭で説明したとおり、Cloud 請求先アカウントはプロジェクトに紐づけします。紐づけされたプロジェクトの費用は Cloud 請求先アカウントに対して請求されます。

組織とフォルダは費用が発生しないため、Cloud 請求先アカウントに紐づけできません。請求の最小単位はプロジェクトであり、プロジェクトのみ Cloud 請求先アカウントに紐づけができます。

Cloud 請求先アカウントを分割する

前述の通り、プロジェクト単位で Cloud 請求先アカウントに紐づけを行うため、組織配下のプロジェクトであってもプロジェクトごとに紐づける Cloud 請求先アカウントを選ぶことができます。

たとえば、同じ組織配下であっても、部門Aのプロジェクトは販売パートナーA、部門Bは販売パートナーB、部門CはGoogle 直接契約といった支払い設定とすることができます。これにより、プロジェクトの利用における内部統制は組織リソースで管理しつつ、コスト管理は部門単位に委任するといった運用が可能になります。

Cloud 請求先アカウントを纏める

前述の説明に対し、Cloud 請求先を纏めることで一元的なコスト管理ができるようになります。 支払先を統一することで支払い管理を効率化でき、すべてのプロジェクトのレポートや分析が容易となります。

また、確約利用割引(CUD) という長期利用を確約することで受けられる割引は、Cloud 請求先アカウント単位で購入できるため、一つの Cloud 請求先アカウントに紐づくリソースボリュームが多いほど割引の恩恵を受けられます。特に大規模な組織や多くのプロジェクトを運用する企業にとっては、請求先アカウントの統合によるコスト削減効果が大きくなる傾向があります。

おわりに

本記事では、企業の情シス部門が Google Cloud を導入または管理する際に最低限知っておくべき知識について解説してきました。

まず、Google Cloud を利用するために必要な基本要素として、Google アカウント、Google Cloud プロジェクト、Cloud 請求先アカウントの3つを説明しました。これらは個人利用であっても企業利用であっても必須の要素となります。

次に、企業での Google Cloud 導入において検討すべき主要トピックとして、以下の4つを詳しく解説しました。

• Google アカウントの ID 統合管理： Google Workspace や Cloud Identity を活用した ID 管理の方法
• Google Cloud のアクセス権管理： IAM を使った適切なアクセス制御の実装方法
• Google Cloud プロジェクトの統合管理： 組織リソースやフォルダを活用した効率的なプロジェクト管理
• 組織全体のコスト管理： Cloud 請求先アカウントの適切な設計によるコスト最適化

これらの知識を身につけることで、情シス部門は Google Cloud の導入において適切な意思決定を行い、セキュリティとコスト効率の両面で最適な環境を構築することができるでしょう。

企業における Google Cloud の導入は、単にサービスを利用開始するだけでなく、組織全体のガバナンスやセキュリティ、コスト管理を考慮した設計が重要です。本記事で解説した基本的な知識をベースに、自社の要件に合わせた Google Cloud 環境の構築を進めていただければ幸いです。

なお、本記事では触れなかった詳細な設定手順やアーキテクチャの設計、各サービスの購入方法などについては、Google Cloud の公式ドキュメントを参照いただくことをお勧めします。

なお、弊社も Google Cloud の販売パートナーであり、請求代行サービスを提供しています。弊社独自のサービスも提供していますのでご興味ありましたらお問い合わせください。
https://classmethod.jp/partner/google-cloud/