業務利用のためのGoogle Cloud入門（１）

はじめに

LLMの登場により、情報の習得が容易になりました。しかし、適切なプロンプトを作成し、必要な知識を効果的に収集するためには、基礎知識の習得が依然として不可欠です。Google Cloudにおいても、基本的な概念からしっかり学ぶことが重要で、これを経て様々なシステムの設計・構築が可能となります。

そこで今回、業務でGoogle Cloud上のシステム設計・構築が必要な初心者の方を対象に、基礎知識を習得するための参考記事を書いてみました。Google Cloud上のシステム設計に関しては、既に「エンタープライズのためのGoogle Cloud」という優れた書籍がありますが、初心者には少し敷居が高い部分もあります。そのため、同書の構成を参考にしつつ、より基本的な内容に焦点を当ててまとめています。

また、書籍ではサービス名が古くなっているものや、出版後にリリースされた新しいサービスもありますので、それらについての情報を更新しています。

今回の記事では、Google Cloudの基礎概念、アカウント設計、ネットワーク、セキュリティについて解説しています。コンピューティングやデータ基盤、運用監視などのトピックについては、またの機会に取り上げる予定です。

クラウドの一般的概念とGoogle Cloudの概要

クラウドの概念

企業が自社でコンピュータやサーバなどの全ての環境を準備・管理する形態をオンプレミス（オンプレ）と呼びます。これに対し、ネットワークを介してクラウドベンダーが提供するコンピューティングリソースをオンデマンド利用する形態をクラウドコンピューティング（クラウド）^[1]と呼びます。

メリット

オンプレミスに対するクラウドのメリットとしては以下のようなものが挙げられます。

• コスト効率:
  クラウドでは使用したリソースに対して従量課金されるため、オンプレミスのように、過剰なデータ容量を確保する等による無駄なコストが発生しにくい。
• 拡張性・縮小性:
  必要な分だけコンピューティングリソースを使用でき、リソースの拡張や縮小が容易。
• 俊敏性:
  サーバ設置などのインフラ構築が不要で、迅速にシステムを構築可能。
• セキュリティ:
  クラウドプロバイダは高度なセキュリティ専門家によってセキュリティが実装されており、ユーザ側の実装以外に起因するセキュリティリスクは非常に低い。
• 最新技術の利用:
  クラウドプロバイダは最新技術動向を把握・実装して提供しており、それを利用することでユーザは競合優位性を得られる可能性がある。

インフラ構築コストを抑えたい、あるいはビジネスアジリティを要求するスタートアップや、開発リソースの作成と破棄を高速に繰り返すR&D部門など、様々なユースケースで恩恵を受けられます。

デメリット

一方、以下のようなデメリットも考えられます。実際、クラウドからオンプレに回帰する事例も見受けられます。

• 障害時の対応の困難さ:
  プロバイダが管理しているため、インフラに障害が発生した場合、ブロバイダによる解決を待つ必要がある。
• カスタマイズ性の低さ:
  プロバイダが提供する仕様でサービスを利用する必要があるので、独自システムの構築が困難な場合がある。
• ロックイン:
  クラウドプロバイダ固有の技術を利用すると、他の環境への移行が困難になる可能性がある。
• オンプレミスより高コストになる場合も:
  必要な計算リソースやデータ容量などが正確に見積もれ、オンプレミスによる最適化が可能な場合、オンプレミスの方がコストを低く抑えられる可能性がある。

サービスのローンチまでに即時性を求めない大規模プロジェクトなどでは、オンプレミス環境が有力な選択肢になる場合もあります。また、大企業ではセキュリティやコンプライアンス要件から、プライベートクラウドを使用するケースも見られます。

クラウドサービスのモデル

主にユーザが管理する部分が多い順に、 IaaS、PaaS、SaaSというモデルに分類されます。Google Cloudが提供するプロダクトは多岐に渡りますが、それぞれが大きく分けてこれらIaaS、PaaS、SaaSに分類されます。

• IaaS (Infrastructure as a Service):
  コンピューティングリソースやストレージを提供するサービス。ユーザはハードウェアを管理する必要はない。例: Compute Engine
• PaaS (Platform as a Service):
  アプリケーションの実行、管理を行う基盤を提供するサービス。ユーザはハードウェアや、OSやストレージなどのインフラを管理する必要はない。例: App Engine
• SaaS (Software as a Service):
  アプリケーションをクラウドを介して提供するサービス。ユーザはアプリケーションの設定以外、ハードウェアやインフラ、プラットフォームを管理する必要がない。例: Looker

ユーザとプロバイダが管理する範囲

Google Cloudは元々PaaSモデルとしてサービスを開始し、その後ストレージやVMのIaaSサービスが誕生しました。それらが統合されて Google Cloud Platform (GCP) と名付けられ、現在は「Google Cloud」として様々なサービスを提供しています。

他にも様々な XaaS^[2] が存在します、Google Cloudと関係が深いものとしてmBaaSがあります。

• mBaaS (Mobile Backend as a Service)
  モバイルアプリやWebアプリを構築するための包括的なインフラ環境を提供するサービス。GoogleのFirebaseがこれに該当し、Google Cloudと密接な関係がある。

ハイブリッドクラウド/マルチクラウド

ハイブリッドクラウドとマルチクラウドという用語は、場面により様々な使われ方をしますが、一般的には以下のような意味で使用されます。

• ハイブリッドクラウド^[3]:
  パブリッククラウドとオンプレミス、またはパブリッククラウドとプライベートクラウドを組み合わせた構成。
• マルチクラウド^[4]:
  複数のパブリッククラウド（例: AWSとGoogle Cloud）を組み合わせた構成。

Google Cloudでは、ハイブリッドクラウドやマルチクラウド環境を統合的に管理できるように、オープンクラウドという考え方を取り入れています。例えば、オンプレミスや他のクラウドプロバイダー上でも一貫性のあるKubernetes環境を構築できるサービスであるAnthosや、複数環境を統合監視できるOperations Suiteなどのサービスが提供されています。

マネージド/サーバレス

クラウドサービスを利用してアプリケーションを構築する際に、（フル）マネージドサービスあるいはサーバレスサービスという言葉を目にすることがあります。これらはおおよそクラウドプロバイダーがリソースを管理するサービスを指しますが、文脈によって多少意味が変わり、時には混同されることもあります。標準的にはそれぞれ以下の意味を持ちます。

• マネージド: プロバイダーがハードウェアや基盤ソフトウェアを管理するが、サービスの実行環境（マシン）などにアクセスして制御できる
• サーバレス: ユーザーはコードやアプリケーションのみを管理し、その他実行環境を含め全てをプロバイダーが管理する

参考リンク

• クラウド コンピューティングとは
• PaaS、IaaS、SaaS、CaaS の違いとは
• サーバーレスとフルマネージド: その違いとは？

Google Cloud概要

2023年4Q時点で、Google CloudはAWS(31%)とAzure(24%)に次ぐ第３位の市場シェア(11%)を持つパブリッククラウドです。PaaSとしてのサービス開始は2008年と早かったものの、多様なアプケーションを構築する基盤としてのプロダクトリリースは比較的後発であり、現在も堅調に成長しています。

Google Cloudは、AWSやAzureと共に3大クラウドという呼び方をされることもあります。

Google Cloudの強み/弱み

各パブリッククラウドにはそれぞれ異なる特徴があり、Google Cloudの強みと弱みとしては下記ようなことが挙げられます。他のパブリッククラウドと比較検討することで、最適なクラウドサービスを選択するのが良いでしょう。あるいはマルチクラウド構成も選択肢の一つです。例えば、データ領域に強みがあるGoogle Cloudをスポットで利用する等。「参考リンク」に添付したドキュメントやブログ記事なども合わせて参考にしてみてください。

強み

• 大規模データ処理:
  検索エンジンやGmail、YouTubeなど、世界中のユーザが利用するGoogleサービスを支えてきた知見・技術が反映されており、BigQueryなど高い処理能力とコストパフォーマンスを持つプロダクトが提供されている。
• AI/機械学習:
  長年に渡り機械学習分野でトップランナーであるGoogleの技術がプロダクトにも活かされており、Vertex AIなどを通じて高度な機械学習モデルの構築が強力にサポートされる。
• OSSとの親和性:
  Googleが開発したKubernetesを筆頭に、OSSとの親和性が高いプロダクトが提供されており、ベンダーロックインの回避などに繋がる。Google Cloudでは、「オープン標準」の利用が推奨されている。

弱み

• 相対的に機能が少ない:
  AWSやAzureと比較すると、エコシステムの未成熟さや未実装の機能がある。複雑な要件がある場合は、実現可能性の検討が必要。
• サービス終了リスク:
  2023年8月にIoT Coreというサービスが終了となった。他のプロバイダでも同様のリスクは存在するが、Googleは比較的大胆に撤退することがある。
• 市場シェアが相対的に小さい:
  AWSやAzureに比べて知見が少ないため、ドキュメントや個人ブログが少なく、慣れた技術者も少ないというデメリットが考えられる。

Google Cloudが提供するプロダクト

コンピューティング、ストレージ、データ分析、機械学習、運用監視など、多岐にわたるプロダクトが提供されており、システムを開発する際に大抵の場合はGoogle Cloudで完結することが可能です。

提供されているプロダクトの全てを把握するのは難しいですが、かなり高いカバー率でDeveloper cheat sheetにまとめられています。ここから各プロダクトのドキュメントを辿ることもできます。

Developer cheat sheetの画面

また、Google Cloudの各プロダクトが、AWSやAzureのどのサービスに対応するか、ドキュメント「AWS サービスや Azure サービスと Google Cloud を比較する」にまとめられています。

設計を行う上で知っておくべきプロダクトは追々解説しますが、使用頻度が高いプロダクトを列挙しておきます。

コンピューティング

• Compute Engine (GCE): 仮想マシン（VM）を提供するIaaS。断りなく「VMインスタンス」と記載がある場合、Compute Engineインスタンスを指す。
• App Engine (GAE): コードをデプロイするだけでスケーリングやインフラを自動で行うPaaS。
• Google Kubernetes Engine (GKE): マネージドなKubernetesサービス。
• Cloud Run: コンテナ化されたアプリケーションを簡単にデプロイ、実行、スケーリングするPaaS。App Engineとどちらを導入すべきかよく比較される。
• Cloud Run関数: イベント駆動型のFaaS（Function as a Service、PaaSの一種）。2024年8月にリブランディングで Cloud Functions から名称変更になっており、本記事を書いた時点でも他の多くの記事でその表記になっている。

ストレージ

• Cloud Storage (GCS): 高可用性・スケーラビリティを持つオブジェクトストレージサービス。断りなく「バケット」と呼ぶ際に、Cloud Storageバケット（1つのデータを格納するコンテナ）

データベース

• Cloud SQL: MySQL、PostgreSQL、SQL Serverのマネージドサービス。

ネットワーキング

• Virtual Private Cloud (VPC): Google Cloud内で仮想ネットワークを構築し、リソース間通信やインターネット接続を管理できる。
• Cloud Load Balancing: トラフィックを複数インスタンスに分散させ、高可用性とスケーラビリティを実現する。

アイデンティティとアクセス管理

• IAM: ユーザーやサービスに対するアクセス権限を制御する。ゼロトラスト的なセキュリティ対策に不可欠なもの。

ビッグデータ・分析

• BigQuery: マネージド・サーバレスなデータウェアハウス。大量データに対する高速クエリ処理、分析を可能にする。

モニタリング/ロギング

• Cloud Monitoring: Google Cloudリソースやアプリケーションのパフォーマンスを監視し、可視化する。
• Cloud Logging: システムやアプリケーションのログを収集、分析し、トラブルシューティングやセキュリティ監査に役立てる。

開発者ツール

• Cloud SDK: Google Cloud各種サービスをコマンドラインから操作するためのツールキット。ローカル開発環境と統合して使用する。

参考リンク

• Cloud Market Gets Its Mojo Back: Q4 Increase in Cloud Spending Reaches New Highs - SRG Research
• クラウド市場シェアランキングと3大クラウド - 株式会社システムエグゼ
• Google Cloudの強みと弱み - Cloud Ace
• 成長市場から突然の撤退　Google CloudがIoTマネージドサービスを終了
• AWS vs Azure vs Google: Comparing The Big Three Cloud Platforms - Cloudwards.net
• 【徹底比較】AWS・GCP・Azureの違い｜3大クラウドサービスの特徴や料金、シェア率、各AI系サービスを紹介
• App Engine と Cloud Run の比較

料金

Google Cloudのさまざまな恩恵を受けられますが、当然ながら使用した分だけ料金が発生します。各種サービスには料金ティアが用意されており、高性能なティアはより高価です。システムの要件を慎重に考慮し、必要以上に高価なサービスやティアを選択しないことが設計上重要な観点です。

また、Google Cloudでは「料金ツール」が提供されており、各種サービスの使用量に応じて料金をシミュレーションできます。設計の際にはこのツールを活用して、コストを予測・最適化すると良いでしょう。

さらに、確約利用割引やプリエンプティブルインスタンスの利用によってコストを抑えられる場合もあります。これらのオプションも検討に入れておくと良いでしょう。

料金計算ツールの画面

参考リンク

• Google Cloud 料金ツール
• 確約利用割引
• プリエンプティブル VM インスタンス

アカウント設計

Google Cloudを効果的に利用するためには、アカウント設計が重要な基礎となります。これは、アカウント設計がセキュリティ、管理効率、コスト管理に直結するためです。ただ、アカウント設計は多岐にわたり、適切に理解し正しく設計することは容易ではありません。

本セクションでは、アカウントの設計を行う上で理解が必要なリソースコンテナやIAMについて説明し、権限の付与方法やベストプラクティスについて解説します。

リソースコンテナ

Google Cloudでは、コンピューティングやストレージといったリソースを階層的に管理するためのリソースコンテナが存在します。これにより、組織全体から個別プロジェクトまで、効率的にリソースを作成・管理できます。

リソースコンテナは上位から順に、組織（Organizations）、フォルダ（Folders）、プロジェクトと呼ばれ、上位階層に対して複数の下位階層を作成できます。

• 組織
  1つの企業に対応するもので、利用企業のドメイン名に紐づけられる。1つのGoogle Workspaceまたは後述するCloud Identityアカウントには、1つの組織リソースがプロビジョニングされる。アカウントドメインのメンバーが新規作成するGoogle Cloudプロジェクトは、デフォルトで組織のリソースに属するようになる。
• フォルダ
  組織内でプロジェクトをグループ化するためのコンテナ。
• プロジェクト
  リソースを作成・管理するための基本単位。

そして、Compute Engineインスタンス、ストレージバケット、といったリソースがプロジェクトの中に属します。

リソースコンテナ階層イメージ

組織
│
├── フォルダ
│   ├── プロジェクト
│   │   ├── リソース
│   │   └── リソース
│   └── プロジェクト
│       └── リソース
└── フォルダ
    └── プロジェクト
        └── リソース

参考リンク

• リソース階層

リソースポリシーの管理

リソースポリシーは、組織内のリソースに対するアクセスや操作を制御するためのルールセットです。これには以下の2つがあります。

• IAMポリシー: 誰が、どのリソースに対して、どのような操作を許可されているかを定義する。
• 組織ポリシー: リソースの作成や設定に対する制約を定義し、組織全体や特定の階層におけるリソース管理を統制する。

IAMポリシーについては後述します。

組織ポリシーは、前述のリソースコンテナ（組織・フォルダ・プロジェクト）単位で適用可能で、そのリソースコンテナにおいて、何かの操作や設定を許可/拒否するポリシー（ルール）を規定するものです。例えば、組織内で作成するリソースをasia-northeast1（東京）とasia-northeast2（大阪）に限定することによって、データの所在を日本に限定するなどの設定が可能です。

組織ポリシーの継承とオーバーライド

組織ポリシーは組織全体や特定の階層におけるリソース管理を統制するであり、基本的にはそのポリシーを下位の階層でも適用するというのは自然な発想であると思います。ただ、フォルダやプロジェクトによっては例外を設けたい場合もあるはずです。組織ポリシーには、以下のように継承と上書きの仕組みがあります。

• 継承の仕組み: リソースコンテナの上位階層で設定したポリシーは、自動的に下位階層（フォルダ、プロジェクト、リソース）に継承される。これにより、全社的なポリシー適用が容易になる。
• オーバーライド: リソースコンテナの下位階層でポリシーを明示的に設定することで、上位のポリシーを上書き（オーバーライド）することが可能。ただし、上位ポリシーで明示的に禁止されている上書き設定はできない。

Resource Manager

リソースコンテナの作成・削除・移動を通じて階層構造を管理し、IAMポリシーや組織ポリシーを階層に対して設定するためのサービスとして、Resource Managerがあります。これはコンソールやgcloudコマンドラインから使用できます。

一例ですが、次のような設定ファイルを作成してコマンドを実行すると、東京と大阪にリソースを作成することを許可するというポリシーが作成されます。

restrict_locations.yaml

constraint: constraints/gcp.resourceLocations
listPolicy:
  allowedValues:
    - "in:asia-northeast1"
    - "in:asia-northeast2"

他にも様々な設定が可能で、一般論にアカウント設計の際に検討すべきことは「ベストプラクティス」として後述します。

参考リンク

• 組織のポリシーの作成と管理
• Google Cloudの「組織のポリシー」と「IAMポリシー」の違いを理解する - Zenn

IAM (Identity and Access Management)

誰（ID）が、どのリソースに対して、どのようなアクセス権（ロール）を持つかを、IAMというものによって設定します。リソースに対するアクセス権を直接エンドユーザに付与することはなく、複数権限をロールにまとめてプリンシパル^[5]というものに付与します。

Cloud Identity

IAMのプリンシパルについて説明する前に、ユーザーやグループのアイデンティティ管理を提供するCloud Identityというサービスについて説明します。これは、利用者個人に紐づくアカウントやそのグループといったメンバーシップ、及びそのアクセス制御を一元的に管理し、誰がどのリソースを使用できるかといった認証認可を提供します。

Google Workspace^[6]でもCloud Identityを用いたユーザ管理が行われますが、そのCloud IdentityをそのままGoogle Cloudのものとして使用することができます。

後述の通り、Googleアカウントはgmailなど個人で作成できるのですが、エンタープライズ利用では企業管理のアカウント利用が推奨されるので、まず先にGoogle WorkspaceもしくはCloud Identityのセットアップが必要となります。

プリンシパル

リソースに対する操作の主体をプリンシパルと呼びます。前述の通りCloud Identityで管理するアカウントやグループを含め、以下のプリンシパルタイプがあります。

• Google アカウント: ユーザー（利用者個人）に紐づくアカウント
• Google グループ: Googleアカウントとサービスアカウントをまとめるためのもの
• サービス アカウント: アプリケーションに紐づけるアカウント
• Google Workspace アカウント: Google Workspaceに含まれる任意のGoogleアカウントの仮想グループ
• Cloud Identity ドメイン: 1つの組織内の任意のGoogleアカウントの仮想グループ
• 認証済みのすべてのユーザー: 任意のサービスアカウントやGoogleアカウントで認証されたユーザー^[7]
• すべてのユーザー: インターネット上の全てのユーザー

Googleアカウントには、個人管理のものと企業管理のものがあり、エンタープライズ利用では企業管理のものを使用することが推奨されています。

• 個人管理（非推奨）: gmail.comや他のメールアドレスで作成したアカウント
• 企業管理（推奨）: Cloud IdentityやGoogle Workspaceで管理されるアカウント

企業管理アカウントが推奨される理由として、組織ポリシーによる管理・統制を行うことに加え、個人管理のアカウントでは各種セキュリティ機能を利用できないという理由もあります。また、個人管理アカウントに紐づくプロジェクトに関しては、アカウントが削除された際にプロジェクトも削除されるリスクが生じます。

なお、WindowsのActive Directoryなどの Identity Provider(IdP) を既に使用している場合、Cloud IdentityのIdP機能を外部IdPに委任することで、既存資産を再利用できます。外部IdPとしてActive Directoryを使用する場合は、Google Cloud Directory Syncというサービスが用意されており、ID情報を同期できます。

ロール

複数の権限をまとめた概念をロールと呼びます。ロールには次の3つがあります。

• 基本ロール: オーナー、編集者、閲覧者という、最も基本的なロールで、広範な権限を持つ。
• 事前定義ロール: 特定サービスへのアクセスを細かく制御する。Google Cloud側で作成、管理される。
• カスタムロール: ユーザー指定の権限リストに応じたきめ細かいアクセス権が提供される。

また、各ロールは次のコンポーネントを持ちます。

• タイトル: 人が識別しやすいロール名
• 名前: ロール識別子であり、事前定義ロールroles/SERVICE.IDENTIFIER、プロジェクトレベルカスタムロールprojects/PROJECT_ID/roles/IDENTIFIER、組織レベルカスタムロールorganizations/ORG_ID/roles/IDENTIFIERのいずれかで与えられる。
• ID: ロールの一意の識別子で、基本ロールと事前定義ロールでは、ロール名と同じ。
• 説明
• ステージ: ALPHA、BETA、GAなどのライフサイクルステージ
• 権限: SERVICE.RESOURCE.VERBという形式で表現される。例えば、compute.instances.listはCompute Engineインスタンスの一覧を表示できる権限を表す。
• ETag: ロールのバージョン識別子。基本ロールと事前定義ロールは常にETagAA==が含まれる。

プリンシパルにロールを付与することによって、そのプリンシパルが権限を持つようになります。

IAMポリシー

IAMポリシーは、特定のリソースに対してプリンシパル（ユーザー、グループ、サービスアカウントなど）のアクセス権限を定義する設定です。IAMポリシーには、以下の3種類があります。

• 許可ポリシー: 特定のプリンシパルに対して、特定リソースに対する操作を許可するルールセット
• 拒否ポリシー: 特定のプリンシパルに対して、特定リソースに対する操作を明示的に拒否（禁止）するルールセット
• プリンシパルアクセス境界ポリシー（執筆時点でプレビュー）: プリンシパルが取得できる最大の権限範囲を定義するルールセット

参考リンク

• IAM の概要
• IAM policy types
• Cloud Identity
• Google Workspace とは

請求

Google Cloudでは使用したリソース分量に応じて費用が発生する従量課金モデルが採用されています。課金設定はCloud Billingというサービスによって行います。

まず、Google Cloudに限定しないGoogleお支払いプロファイルを作成し、この中で支払い方法を登録します。次にGoogle Cloudの課金に使用するCloud請求先アカウント^[8]を作成し、Googleお支払いプロファイルに紐づけます。

参考

• 支払い方法の追加、削除、更新

アカウント設計のベストプラクティス

Google Cloudのアカウント設計におけるベストプラクティスは多岐にわたります。以下では、特に重要なポイントをいくつかピックアップして解説します。詳細な情報や追加のベストプラクティスについては、参考リンクなどをご参照ください。

最小権限の原則

各プリンシパルに対して、業務遂行に必要最小限の権限のみを付与するという設計原則を「最小権限の原則」と呼びます。

これは、内部からの不正アクセスや誤操作によるリスクを低減することや、万が一サービスアカウントキーが流出した場合でも、被害の範囲を制限することに繋がります。また、誰がどのリソースにアクセスしているかを把握しやすくなるため、監査やコンプライアンスの向上にも寄与します。

Googleはポリシー情報を自動で分析しており、IAM Recommenderという機能によって、過剰な権限が付与されている場合に権限設定の推奨事項をコンソール上に表示します。その際には推奨事項を確認し、必要に応じて権限設計を見直すことによって最小権限の原則を守った実装に近づけていくことができます。

リソースコンテナの階層構造を作成し、組織ポリシーを作成する

まず、Google WorkspaceやCloud Identityをセットアップします。既に外部IdPを利用している場合は、これを再利用するとシングルサインオンなどを実現できます。セットアップ後、組織リソースが自動的にプロビジョニングされ、この組織に所属するユーザーが作成するフォルダやプロジェクトは自動的に組織配下に配置されます。

そして、組織の満たすべきコンプライアンス要件などを検討の上、下位の階層まで満たすべき組織ポリシーを設計します。要件は企業により様々なものが考えられます。例えば、データの物理的な所在として許可する国や地域を限定する、デフォルトネットワークの作成禁止等セキュリティ観点で企業全体に適用したいルールを設定する、監査の観点で必要な設定をするなど。

また、ユースケースに応じてフォルダやプロジェクトを構成します。例えば部門ごとに組織ポリシーを設定・継承したい場合には、その部門に対応させる形でフォルダを作成することが考えられます。開発や本番といった環境ごとにポリシーを定義したい場合には、環境ごとにフォルダを作成するのが良いでしょう。

さらに、プロジェクトの作成をTerraformなどで自動化しておくと、命名規則や各種設定を保った展開が容易になります。

利用者の役割に応じてグループを作成する

組織内の利用者を効率的に管理するために、役割に応じたグループを作成します。例えば、業務委託の開発者、特定部門のデータアナリスト等のペルソナごとにグループを作成します。そしてそれに応じた権限を付与して、必要なアカウントをグループに所属させるようにします。このようにして必要な権限を付与していくことで、各アカウントごとに都度必要な権限を付与するより管理が容易になります。

サービスアカウントキーの使用を回避する

サービスアカウントは、JSONのキーファイルを使用することによっても認証され使用可能ですが、極力これを回避することが推奨されます。具体的には、Workload Identity連携等を使用します。

これは、JSONキーファイルの管理の手間を省き、キー流出リスクを排除するためです。

コスト管理

予算設定を行い、その50%、80%、100%を超えた場合にアラート通知する等の設定が可能です。またそのメッセージをキューイングして自動的にリソースを停止する仕組みを構築することも可能です。このような設定を行うことによって、想定外のコスト^[9]が発生することを防ぐことができます。

また、定期的に費用内訳レポートなどを確認しておくことも有効です。

費用内訳レポートの例（出典:公式ドキュメント）

参考リンク

• IAMを安全に使用する
• プロジェクト、フォルダ、組織に対するロールの推奨事項を確認して適用する
• 費用内訳レポートでコスト削減を確認する
• 確約利用割引
• プリエンプティブル VM インスタンス

まとめ

このセクションでは、アカウント設計の基礎知識を説明し、ベストプラクティスを紹介しました。適切に設計されたアカウント環境は、組織のセキュリティレベルを向上させるだけでなく、開発者が考慮すべき点を減らし、開発に集中できるようになる効果もあります。組織内での運用を促進することにも繋がります。そのため、アカウント設計は非常に重要です。

ネットワーク

Google Cloudを用いてシステムを構築する際、ネットワークの設計が不可欠です。ネットワークはシステムのセキュリティやパフォーマンスに直接影響を与えるため、非常に重要な要素となります。このセクションでは、ネットワーク設計に必要な基礎知識と、設計時に考慮すべきポイントについて解説します。

Google Cloudのネットワーク基礎

Googleのネットワーク

Google Cloudを使用するユーザーは VPC (Virtual Private Cloud) と呼ばれる、仮想的に分離されたネットワーク環境を利用します。このVPCは、Google検索やYouTubeで使用されているのと同じ、世界中に広がる専用のネットワークインフラ上で運用されています

Google CloudのVPCを利用することで、ユーザーはGoogle検索やYouTubeと同じレベルの、高速・低遅延かつ高い可用性と信頼性を備えたネットワークを利用できます。

Googleのネットワーク（出典:Google Cloudブログ）

VPCの基本構造

VPC は、Google Cloud上で仮想的に分離されたネットワーク環境を作るための仕組みです。これを使って、企業や開発者がプロジェクトごとに独立したネットワークを構築し、セキュアにリソースを管理・運用できます。

Google Cloudのプロダクトのうち、APIサービスとしてGoogleがエンドポイントを公開しているものもありますが、VPC内にユーザー自身で構築するサービスに関しては、基本的にユーザー自身でIPアドレスを管理・設定することで通信を実現します。IPアドレスには以下の分類があります。

• 内部(プライベート)IPアドレス: VPC内で使用するIPアドレス。RFCで定められているプライベートIPアドレスや特定のパブリックIPアドレスを使用する。
• 外部(パブリック、グローバル)IPアドレス: インターネット上でGoogle Cloud内外と通信するために使用される公開IPアドレス。

なお、VMインスタンスを起動した際に自動的に割り当てられる（外部）IPアドレスをエフェメラル（一時的）なIPアドレスと呼び、これはインスタンスを削除した際に解放されてしまいます。固定のIPアドレスを使用したい場合、静的IPアドレスを予約する必要があります。

VPCで稼働するリソースは基本的にプライベートIPアドレスを使用しますが、必要に応じてGoogle Cloudのサービスを通じて外部公開やインターネット接続が可能です。

また、VPCは、サブネットと呼ばれるIPアドレス範囲に分割され、細かい通信制御やネットワークセグメンテーションを実現します。各サブネットはリージョンやゾーンという地理的ロケーションに属しており、これにより地理的に分散したリソース配置が可能です。

さらに、VPC内には自動的にルーティングテーブルが作成され、VPC内のサブネット間の通信経路が設定されます。

ファイアウォールルールは、特定のサブネットやIPアドレス範囲に対して、どの通信を許可し、どの通信を拒否するかを詳細に設定することで、ネットワークのセキュリティを強化します。例えば、WebサーバーへのHTTP（ポート80）およびHTTPS（ポート443）アクセスのみを許可し、他のポートへのアクセスを拒否するルールを設定できます。

VPCピアリングとは、異なるVPCネットワーク間で直接通信を可能にする接続方法です。これにより、VPC間で安全かつ高速なデータ転送が実現します。

なお、組織ポリシーなどで特に設定されていない場合、Google Cloudプロジェクトを作成したすると、default という名前のVPCネットワークが作成されます。これは初期の試験運用のためのものであり、本番運用はカスタムVPCを使用することが推奨されています^[10]。

リージョン、ゾーン、エッジロケーション

Google Cloudのリソースは、東京や大阪といった地理的なエリア（リージョン）と、その中の個々のデータセンター（ゾーン）単位でグルーピングされます。このグルーピングや利用範囲に応じて、Google Cloudのリソースは以下のように分類されます。

• グローバルリソース: 全リージョン及びゾーンにまたがって存在し、利用可能なリソース
• リージョンリソース: 特定のリージョンで利用可能なリソースで、複数のゾーンで構成されるもの。GCSバケットなどサービスによっては、リージョン内の複数ゾーンに冗長構成され、可用性が実現される
• ゾーンリソース: 1つのゾーンに限定されたリソース

例えば、GCEのVMインスタンスはゾーンリソースであり、起動する際にどのゾーンで起動するかを指定します。

また、エッジロケーション（エッジPoP） と呼ばれる、データの配信を行う物理的ロケーションを示すものもあります。

リージョン、ゾーン、エッジロケーションの数には以下の関係があります。

リージョン < ゾーン < エッジロケーション

サブネット

前述のように、サブネットはVPCを分割するものです。VPCはグローバルリソースであり、Google Cloud内で1つのVPCが作成されます。一方、サブネットはリージョンリソースであり、1つのリージョンごとに複数のサブネットを定義できます。

サブネットを作成することによって、VPC内のリソースを異なるネットワークセグメントに分割し、ネットワークトラフィックを各サブネットの目的に応じて明確に分離することで、管理のしやすさやセキュリティを実現します。例えば、外部に公開するアプリケーションを外部IPアドレスを持つパブリックサブネットに配置し、データベースやバックエンドサービスを外部IPアドレスを持たないプライベートサブネットに置くことで、外部からの直接アクセスを防ぎセキュリティを強化します。

また、後述のファイアウォールルールをサブネットごとに適用することで、特定の目的での通信を許可しつつその他の通信を拒否する設定が可能になります。

Cloud NAT (Network Address Translation) を使用することで、プライベートサブネット内のリソースがインターネットにアクセスできます。例えば、ソフトウェアアップデートのダウンロードや外部APIへのリクエストを行う際に利用します。一方で、インターネットからの直接アクセスは防ぐことができるため、セキュリティを維持しながら必要な通信を実現できます。

IPv4 のみ（単一スタック）のサブネットと、IPv4とIPv6（デュアルスタック）のサブネットが提供されています。それぞれのサブネット範囲に関して制約があるため、実際に設定する際にはドキュメントをご参照ください。

サービスプロデューサーネットワーク

Cloud SQLなどGoogle Cloudの特定のサービスは、サービスプロデューサーネットワークと呼ばれるGoogle側が所有・管理するVPC内にホストされます。

このサービスプロデューサーネットワークに対して、Private Service Connect もしくは Private Service Access というアクセス手段を使用することで、プライベートアクセスが可能となります^[11]。

DNS

Cloud DNS はグローバルなドメインネームシステム（DNS）を提供するサービスです。グローバルなユーザーに対して高速な名前解決を提供します。

Cloud DNSは、公開ゾーンと限定公開ゾーンの2つのホスティングがあります。

• 公開ゾーン: インターネットに公開されるゾーンをホストする。Webサービスを公開するなど、外部むけのDNS権威サーバーとして利用する。DNSSECを有効化できる。
• 限定公開ゾーン: VPC内部からのみ参照可能なゾーンをホストする。特定のゾーンに対する名前解決のリクエストを別のDNSサーバーニ転送する、DNS転送などを使用できる。

参考リンク

• Google Cloud ネットワーキングの概要
• 地域とリージョン
• ネットワーク エッジのロケーション
• グローバル リソース、リージョン リソース、ゾーンリソース
• VPC ネットワーク
• サブネット
• ルート
• 静的外部 IP アドレスの予約
• Cloud NAT の概要
• サービス プロデューサー ネットワーク
• Private Service Connect
• プライベート サービス アクセス
• Cloud DNS の概要
• DNS ゾーンの概要

ネットワークセキュリティ

Google Cloudのネットワークセキュリティを考える上で、従来型のネットワーク境界^[12]を定めるセキュリティモデルと、内部も外部も信頼せず常に検証を行うゼロトラストセキュリティモデルを融合して、セキュリティ対策することが望まれます。

従来型の対策としては以下のようなものがあります。

• ファイアウォール: ネットワークレベルで、IPアドレスやポート番号に応じて通信の許可や拒否を設定する。
• ウェブアプリケーションファイアウォール（WAF）: アプリケーションレベルで、脆弱性を突く攻撃を防ぐ
• パケット解析: ネットワーク上のトラフィックをキャプチャし、解析することによって不正なアクセスを検知したり防止したりする

ゼロトラストモデルでは、ネットワークの内外に関わらず、ユーザーやデバイスなどアクセス主体のコンテキストを認証・検証することでアクセスを許可します。

ファイアウォール

Google Cloudでは、Cloud NGFW (Next Generation Firewall) というファイアウォールサービスが提供されています。以前はCloud Firewallという名前で提供されていましたが、2024年4月に名称変更となっています。

このサービスには、Essentials、Standard、Enterprise の3つの階層があり、それぞれ機能と料金が異なります。機能が充実するほど高価になりますので、事業の規模やセキュリティ要件、予算によって適切なティア（階層）を選定されるのが良いでしょう。

• Essentials: 無償。基本的なネットワークレベルのセキュリティを提供する
• Standard: 有償。Essentialsの内容に加え、FQDNや位置情報に基づくフィルタリング、Googleの脅威インテリジェンスに基づく保護が提供される
• Enterprise: 有償。侵入防止サービス（IPS(Intrusion Prevention System)）が追加される。これは対象ネットワークのトラフィックをキャプチャし、パケットを解析して脅威から保護する機能

また、ファイアウォールには VPCファイアウォールルール という特定VPC内のみで適用されるルールと、ファイアウォールポリシーという複数のファイアウォールルールをグループ化して設定・管理する組織向けの設定があります。

VPCファイアウォールルール

VPCファイアウォールルールのスコープは、特定の1つのVPCネットワークに限定されます。ルールは、以下の2種類があります。

• Ingress（上り）ルール: VPCネットワーク内へのトラフィックを制御
• Egress（下り）ルール: VPCネットワークから外部へのトラフィックを制御

ルールには優先度が設定されており、低い数値ほど優先度が高いです。また、特定のターゲット（ネットワーク）タグやサービスアカウントをターゲットに指定することも可能です。

フィルタにはIP範囲を指定し、プロトコルとポートをtcp:80,443のように指定できます。そしてAllow（許可）/Deny（拒否）を指定します。

これを使うことによって、例えば web-server タグを付けたインスタンスに対して、内向きの tcp:80,443 を許可することにより、WebサーバへのHTTP(S)アクセスが実行できるようになります。

VPCファイアウォールルール

また、無設定で番兵的に暗黙のルールが2つ、優先度最低として設定されています。

• 任意のEgress許可
• 任意のIngress拒否

ファイアウォールポリシー

多数のVPCを運用する場合には、それぞれのVPCファイアウォールルールを管理するのが煩雑になりがちです。この対策として、一定のまとまりに対し一貫したアクセス制御を実施するために、ファイアウォールポリシーが用意されています。

ファイアウォールポリシーには以下の種類があります。

• 階層型ファイアウォールポリシー: スコープは組織、フォルダ、プロジェクトで、「アカウント設計」で記載したものと同様に、階層構造に基づいた継承を行える。
• グローバルネットワークファイアウォールポリシー: スコープはVPCネットワーク。全てのリージョンに適用されるポリシーオブジェクトにルールをまとめられる。
• リージョンネットワークファイアウォールポリシー: スコープはVPCネットワーク。特定のリージョンに適用されるポリシーオブジェクトにルールをまとめられる。

ファイアウォールインサイト

ファイアウォールルールの使用状況に関する分析情報、推奨事項、指標が提供され、最適化に役立てることができます。これはGoogle Cloudコンソールから確認できます。

ファイアウォールルールロギング

この機能は有効化することで使用できます。有効化すると、ファイアウォールルールにトラフィックが適合する度に、接続レコードと呼ばれるレコードが記録され、Cloud Loggingでルールの使用状況を閲覧できます。

WAFの設定

ここまで説明したファイアウォールは、主にネットワークレベルでセキュリティを確保するものでした。アプリケーションレベルでセキュリティを確保するために、ウェブアプリケーションファイアウォール(WAF) を使用できます。

Google Cloudでは、Cloud Armorというサービスが提供されています。これは、DDoS攻撃、XSS、SQLインジェクションなどの攻撃パターンを検知し、システムを保護します。

WAFルール

セキュリティポリシー（保護ルール）を設定する機能で、Cookie、HTTPヘッダ、ユーザーエージェントなど様々な要素を用いてルールを記述できます。

最も重要なWebアプリケーションセキュリティリスクのリストとして知られる、OWASP Top Tenへの対策のための事前ルールなどが提供されており、手動でシグニチャを定義することなく簡単に一般的な攻撃へのセキュリティ対策が可能です。

パケット解析 / IPS(侵入防止システム) / IDS(侵入検知システム)

パケット解析

ネットワーク上のトラフィックを収集することをパケットキャプチャと呼びます。パケットには転送されるデータや送信元、宛先、プロトコルなどの情報が含まれます。この情報を解析し、パフォーマンスやセキュリティのために役立てることをパケット解析と呼びます。

Google Cloudでは、Packet Mirroringというサービスが提供されており、VMインスタンスのトラフィックをミラーリングし、OSSのパケット解析ツールなどを使用することで解析が可能です^[13]。上り/下りの両方もしくはいずれかのみのトラフィックを収集できます。

ユースケースとしては、OSSと組み合わせてセキュリティ対策に使用したり、ネットワーク上の問題を検知してアプリケーションパフォーマンスのモニタリングを行うなどがあります。

IPS / IDS

IPS（Intrusion Prevention System）としてGoogle Cloudで提供されるものとしては、前述のCloud NGFW Enterpriseがあります。

また、Cloud IDSというIDS（Intrusion Detection System）サービスが提供されています。これは前述の Packet Mirroring を使用してトラフィックデータを収集し、不正なアクティビティや脅威を検知してセキュリティを強化します。

シグニチャや検出ルールが自動更新されるため、最新の脅威に対応できます。脅威は、重大、高、中といったレベルで評価され、最小の重大度レベルを選択してアラートを生成できます。

VPC Service Controls

VPC Service Controls（VPC SC） とは、従来型のネットワークレベルでのアクセス制御に加えて、より厳格なセキュリティ境界を定めてアクセス制御するサービスです。

これは主に情報漏洩への対策となります。例えば、社員による不正なデータの持ち出しや、サービスアカウントの漏洩によるデータの持ち出しなどを防ぐことができます。

また、「セキュリティ」のセクションで述べる「機密データの保護」と組み合わせて使用することで、高度なデータ保護を実現できます。

構成要素

• サービス境界: 境界内に含めるサービスを指定し、境界内での通信を許可し、デフォルトでは境界外からの通信を全て拒否する
• アクセスレベル: IPアドレス範囲、デバイス状況、ユーザー属性に基づき、適切なユーザーやデバイスの境界外からアクセス許可する
• 境界ブリッジ: 別の境界にあるサービスとの通信やデータ共有を実現する

注意点

サポートされている、つまりサービス境界の内部に置くことのできるプロダクトが限定的です。例えばCloud Shellなどがサポート外なので、Cloud Shellを使ってVPC SCで保護されたデータへのアクセスを試みると、拒否されてしまいます。サポート対象外のサービスに対しては、従来型のネットワーク境界を設けるなどVPC SC以外の対策を講じなければなりません。

また、設定が煩雑になりがちで、運用コストの増大や、場合によってはトラブルシュートが難しくなることもあります。

このため、IAMなどによってシンプルにアクセス制御できないかを検討し、必要と判断する場合にも適用したいプロダクトがサポートされているかを確認した上で使用する必要があります。

なお、以下のgcloudコマンドを使用すると、VPC SCでサポートされているサービスの一覧を確認できます。

gcloud access-context-manager supported-services list

ゼロトラストセキュリティ

従来のネットワーク境界モデルと異なり、ユーザーやデバイスといったアクセス元を常に検証し、アクセス元のコンテキストに基づいてアクセス権を動的かつ細かく制御するセキュリティモデルをゼロトラストモデルと呼びます。

前述のIAMに基づくアクセス制御は一種のゼロトラストモデルです。Google Cloudで他に典型的なゼロトラストモデルに基づくサービスとして、Chrome Enterprise Premiumというサービスがあります。

Chrome Enterprise Premium

Chrome Enterprise Premiumは、Googleが提供するゼロトラストセキュリティモデルに基づくセキュリティソリューションで、柔軟かつ安全なアクセス管理を実現できます。このサービスは、以前はBeyondCorp Enterpriseという名称で提供されており、執筆時点ではドキュメントなどにその名前が多く残っています。

これは以下のような特徴を持ちます。

• アクセス元を常に検証する
• コンテキストベースのアクセス制御を行う。例えば、ユーザーのアイデンティティ、アクセス元のデバイス、アクセス時の位置情報などが考慮される
• VPNが不要。このため、VPNの逼迫などの問題から解放される
• アクセスログを記録できる

これを上手く利用することで、以下のようなことが実現できます。

• 場所に依存せず従業員はどこからでも安全に企業リソースにアクセスでき、リモートワークが可能になる
• 従業員が機密データを持ち出すなど内部脅威への対応
• システムへのアクセスを、社用端末に限定する
• アクセスログを使用した監査やコンプライアンスチェック

Chrome Enterprise Premiumは以下の構成要素から成ります。

• Cloud Identity: 「アカウント設計」のセクションで説明したCloud Identityで、アクセス元ユーザーのアイデンティティを管理する
• Endpoint Verification: Chrome拡張機能を利用し、デバイスの暗号化状況、OSバージョンなどデバイス情報を収集し、アクセス可否を判定するための情報を後続サービスに渡す
• Access Context Manager: アクセス元のコンテキストに基づいてアクセス可否を判定するルールを定義するルールエンジン
• Identity Aware Proxy (IAP) や VPC SC: ここでAccess Context Managerのルールに基づきアクセス可否を判定する。IAPはHTTP(S)アクセスに対するリバースプロキシサービス

IAPを使用する際の注意点として、IAPを前段においているアプリケーションに関して、IAPを迂回するリクエストを許可しない設定が必要となります。

参考リンク

• サービス境界の詳細と構成
• Cloud NGFW の概要
• Cloud 次世代ファイアウォールの料金 VPC ファイアウォール ルール
• VPC ファイアウォール ルール
• ファイアウォール ポリシー
• ファイアウォール インサイトの概要
• ファイアウォール ルールのロギング
• Cloud Armorの概要
• Packet Mirroring
• Cloud IDS の概要
• VPC Service Controls の概要
• ブリッジを使用して境界を越えて共有する
• BeyondCorp Enterprise の概要
• Identity-Aware Proxy の概要

ハイブリッド接続

企業のオンプレミス環境とGoogle Cloudを統合し、一貫したネットワークインフラを持つハイブリッドクラウド環境を構築するためのオプションが提供されています。

これには、インターネットを介して仮想プライベートネットワークを構築するもの（Cloud VPN）、専用回線やパートナーを介した直接接続を確立するもの（Cloud Interconnect）、ピアリング接続するものがあります。

Cloud VPN

Cloud VPNは、オンプレミス環境とGoogle CloudのVPCをIPsecトンネルでセキュアに接続する仮想プライベートネットワークを提供するサービスです。インターネットを経由して接続する、中小規模、あるいはテスト等の簡易な要件で使用するものです。

Dedicated Interconnect

Dedicated Interconnectは、オンプレミスデータセンターとGoogleネットワークを直接接続するための専用回線サービスで、高帯域幅、低レイテンシ、セキュアな回線を提供します。これは大規模なデータセンターや高頻度・リアルタイムを要求するアプリケーションを構築するために使用されます。

Partner Interconnect

Partner Interconnectは、Google Cloudのパートナーの通信サービスプロバイダを介して、オンプレミス環境とVPCを接続するオプションです。常時高帯域幅の専用回線を必要としないようなケースで使用します。

Dedicated InterconnectとPartner InterconnectをまとめてCloud Interconnectと呼びます。なお、Cloud Interconnectには、別のクラウドのネットワークと直接接続するためのCross-Cloud Interconnectというものも提供されています。

ダイレクトピアリング

2つのネットワークを直接物理的に接続して、低遅延で安定したネットワーク環境を構築するプロダクトです。

ダイレクトピアリングとCloud Interconnectの比較表が提供されています。

注意点として、SLAを提供していないため、SLA要件がある場合は Cloud Interconnect を使用する必要があります。

キャリアピアリング

対応しているISP（インターネットサービスプロバイダー）を経由して直接ピアリング接続するオプションです。帯域幅やレイテンシはダイレクトピアリングに劣るものの、低コストになる傾向があります。

Cloud Router

Cloud Router は、 BGP (Border Gateway Protocol) を使用して動的ルーティングを提供するサービスです。これは Cloud VPN や Cloud Interconnect で使用し、オンプレミスのLANとVPCの間で経路情報を交換します。

参考リンク

• Cloud VPN の概要
• Dedicated Interconnect の概要
• Partner Interconnect の概要
• ダイレクト ピアリングの概要
• キャリア ピアリングの概要
• Cloud Router の概要

トラフィック管理

Google Cloud上に構築するアプリケーションへのアクセスを最適化し、パフォーマンスと可用性を向上させるために、ネットワーク内外のデータフローを制御するトラフィック管理も重要な設計要素になります。

ここでは、トラフィック管理のために重要なロードバランシングとCDNについて解説します。

ロードバランシング

ロードバランシング（ロードバランサ、負荷分散） は、バックエンドの複数のサーバーにトラフィックを分散させることで、単一のポイントへの負荷を軽減し、システム全体の可用性とパフォーマンスを向上させます。

Google Cloudでは、Cloud Load Balancing というサービスが提供されています。Cloud Load Balancingは、VPC外部からのトラフィック、あるいはVPC内部のトラフィックに対して負荷分散を行う多くの種類のロードバランサを提供しています。Cloud Load Balancingは、まずアプリケーションロードバランサとネットワークロードバランサの2つに大別されます。

• アプリケーションロードバランサ (ALB): レイヤ7ロードバランサで、HTTP / HTTPSトラフィックを分散する
• ネットワークロードバランサ (NLB): レイヤ4ロードバランサで、TCP / UDPトラフィックなどを分散する

また、負荷分散するトラフィックの出所がネットワークの内外いずれかによって、外部ALB / 内部ALBのように分類されます。

Webアプリケーションなどにおいて頻繁に使用するものは外部ALBであり、まずはこれをしっかりと把握するのが良いでしょう。

外部アプリケーションロードバランサ

外部アプリケーションロードバランサ (外部ALB) は、Google Cloudの外部ネットワークからのHTTP(S)トラフィックを分散してバックエンドに伝えるものです。このバックエンドは、特に後述のCDNとの連携の文脈ではオリジンと読んだりもします。

バックエンド（オリジン）として設定可能なものは以下の通りです。基本的にGoogle Cloud内部のサーバーを想定することが多いですが、Google Cloud外部のエンドポイントに対しても使えます。

• Compute Engineの インスタンスグループ : マネージドと非マネージドのどちらも可能。
• ゾーンネットワークエンドポイントグループ（ゾーンNEG） : 内部IPアドレスで構成されるエンドポイントのグループ。GCEのVMやGKEのPod。
• サーバレスネットワークエンドポイントグループ(サーバレスNEG) : App Engine、CloudRun関数（グループ）、Cloud Runサービス、API Gatewayのエンドポイント。
• インターネットネットワークエンドポイントグループ(インターネットNEG) : Google Cloudの外部でホストされる、インターネット経由で到達可能なエンドポイント。
• ハイブリッドネットワークエンドポイントグループ(ハイブリッドNEG) : クラウド、オンプレミス、他クラウドなど、異なる環境のエンドポイントのハイブリッド環境に存在するエンドポイント。
• Private Service Connect NEG : Private Service Connectを利用してプライベートアクセスするためのNEG。
• GCS

これを使用することで、例えば負荷の大きさに応じたバックエンドのオートスケールの仕組みを構築したり、あるいはバックエンドの移行の仕組みを構築したりできます。

外部ALBにおいて、さらに実装上知っておくべき点としては、HTTPS通信のSSL/TLSの終端をロードバランサが担当し、バックエンドには平文トラフィックを送信することが可能な点です。

また、外部ALBには3つのモードがあります。基本的には、バックエンドがグローバルに存在するかどうか、およびCDNを使用するかどうかに応じて、グローバルまたはリージョン外部ALBを選択します。従来のALBはこれらのALBの後継にあたるため、特別な要件がない限り、新規開発において使用する必要はありません。

• グローバル外部ALB: 複数リージョンに分散したバックエンドがある場合に使用。Cloud CDNをサポートしている
• リージョン外部ALB: 単一リージョンにバックエンドがある場合に使用。
• 従来のALB: Cloud CDNをサポートしている

外部ALBが扱うHTTP(S)やWebSocket等とは別のプロトコルを扱う場合、あるいは内部トラフィックを負荷分散する場合には、他のロードバランサを選択する必要があります。「ロードバランサを選択する」などの資料を活用し、適切なものを選択してください。

CDN

Cloud CDN はエッジロケーションに静的ウェブコンテンツ（HTML、画像、JavaScriptなど）や一部の動的コンテンツをキャッシュして、ユーザーに高速に配信するサービスです。これによって、グローバルに分散したエッジロケーションの、ユーザーに近い場所からコンテンツが配信されます。

このCloud CDNは、グローバル外部ALBまたは従来のALBと連携して動作します。

出典:公式ドキュメント

キャッシュ最適化

Cloud CDNを利用する場合、キャッシュからの応答を試み、キャッシュにコンテンツが存在しない場合はバックエンドからコンテンツを取得してキャッシュに保存します。キャッシュに対象コンテンツが存在することをキャッシュヒット、存在しないことをキャッシュミス、バックエンドから取得してキャッシュに保存することをキャッシュフィルと呼びます。

基本的にはキャッシュヒット率を向上させることにより、コンテンツ配信の配信を高速化させることが望ましいです。ただし、データの新鮮さが重要なものに関しては注意が必要です。また、キャッシュ可能なデータ量にも制限があるため、動画など容量が大きいコンテンツを配信する際には注意が必要です。

キャッシュ最適化をするにあたり重要な、キャッシュモード及びキャッシュキーについて説明します。

• キャッシュモード: キャッシュにコンテンツを保存する方針を決めるパラメータで以下の3つがある
  • CACHE_ALL_STATIC: 全ての静的コンテンツをキャッシュする
  • USE_ORIGIN_HEADERS: 送信元が付与したヘッダでキャッシュが指示されたコンテンツをキャッシュする
  • FORCE_CACHE_ALL: 全ての応答をキャッシュする
• キャッシュキー: キャッシュされるコンテンツのエントリを一意に識別するためのもの。バックエンドサービスの場合、初期状態ではコンテンツのURI(プロトコル、ドメインを含むフルパス)が使用されるが、以下を組み合わせてカスタマイズ可能。バケットに関しては少し違うのでドキュメント参照
  • プロトコル
  • ホスト
  • クエリ文字列

参考リンク

• Cloud Load Balancing の概要
• 外部アプリケーション ロードバランサの概要
• ロードバランサを選択する
• Cloud CDN の概要
• キャッシュの概要

まとめ

このセクションでは、ネットワーク設計の基礎からセキュリティ対策、トラフィック管理まで、最低限必要な知識事項を述べてきました。ここまでの知識を応用することで、ネットワークの設計・構築が可能になるでしょう。

実際の要件に応じてネットワーク環境を構築するうえで参考となるよう、「参考リンク」にベストプラクティスやアーキテクチャの参考ドキュメントを添付しておきます。

参考リンク

• VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャ
• エンタープライズ ワークロードを移行するためのネットワーク設計: アーキテクチャのアプローチ

セキュリティ

コンプライアンス・ホワイトペーパー・規約

Google Cloudでは、規制遵守の証明、安全な利用のためのベストプラクティス、そしてGoogleが実施しているセキュリティ対策の透明化を目的とした多様なドキュメントを提供しています。これらの資料は、安全かつ効率的にシステム開発を支援するだけではなく、企業がGoogle Cloudを導入する際の意思決定の参考にもなります。詳細は添付のリンクからご参照ください。

コンプライアンス状況

エンタープライズがGoogle Cloudを利用する際には、様々な規制・法的要件を遵守することが求められます。Google Cloudはこれらの要件を満たすために、独立した機関による監査を定期的に実施し、世界基準の各種認証を取得しています。

コンプライアンス状況

ベストプラクティスガイドとセキュリティホワイトペーパー

Google Cloudでは、安全にサービスを利用するためのガイダンスや詳細なホワイトペーパーを提供しています。これらはデプロイの参考や、Google Cloudの採用判断のために適用性やセキュリティ体制を評価する参考資料としても使用できます。

Google Cloud セキュリティ ベスト プラクティス センター

規約

Google Cloudでは、各サービスやプロダクトに固有の利用規約、サービスレベルアグリーメント（SLA）、およびセキュリティ規約を提供しています。

Google Cloud 利用規約のディレクトリ

Google Cloudセキュリティ概要

責任共有モデルと運命共有モデル

Google Cloudを含むパブリッククラウドでは、クラウドプロバイダーとユーザーでセキュリティ責任を共有する「責任共有モデル」が採用されています。このモデルでは、クラウドプロバイダーとユーザーそれぞれが管理する範囲でのセキュリティを担当し、システム全体のセキュリティを確保します。

前述通り、Google CloudはIaaS、PaaS、SaaSといった様々なモデルのサービスを提供しており、それぞれのモデルのユーザーとプロバイダーの管理範囲に応じて、セキュリティ責任の範囲が異なります。

責任共有モデル

Google Cloudでは、この責任共有モデルを補完するために、独自に「運命共有モデル」という考え方を導入しています。このモデルでは、責任共有モデルで果たすべきセキュリティ対策を講じることを前提に、ユーザーとGoogle Cloudが共同でセキュリティ対策を実施します。また、セキュリティ対応やインシデント対応についてGoogle側が透明性を持って情報を提供することなども含まれます。

例えば、Security Command Centerは運命共有モデルの一環として提供されるセキュリティ管理ツールで、これによりクラウドプロバイダーとユーザーは共同でセキュリティリスクを監視し、対策を講じることができます。

参考リンク

• Google Cloud における責任の共有と運命の共有
• Security Command Center のドキュメント

Google側で実施しているセキュリティ概要

責任共有モデルの「プロバイダー管理」で実施されている概要について説明します。詳細については、前述の「ベストプラクティスセンター」をご参照ください。

物理的セキュリティ/ハードウェアセキュリティ

• 世界中に配置されているデータセンターは大規模な多層セキュリティモデルを採用して、不正侵入が非常に困難になっている
• データセンタの施設、専用サーバ、ネットワーク機器、セキュリティチップ、マシンの低レベルソフトウェアスタックなど、Googleが制御しセキュリティが保護されている。例えば、ルートオブトラストを確立するハードウェアが使用されるなど、低レイヤからセキュリティ機能を実装している

ネットワークセキュリティ

• データ転送時の暗号化（TLS）を標準で実施
• ネットワーク内のデータも暗号化して保護される
  • 自動的に暗号化されないものもありユーザー側での設定が必要になるものもあるので注意が必要（参照:ロードバランサからバックエンドへの暗号化^[14]）
• DoS攻撃から保護するための多層防御の仕組みが用意されている

ストレージの暗号化

• Googleインフラストラクチャに保存されるデータは、デフォルトで暗号化処理が行われる
• データセンタ間の冗長性を確保し、可用性・信頼性を高めている（障害発生時にもサービスを継続できる）

ソフトウェアとプラットフォームの安全性確保

• インフラストラクチャは、設計初期よりマルチテナントでの利用を想定している
• VMや物理サーバ起動時に信頼できるソフトウェアのみが実行されるよう、セキュアブートの仕組みがある
• 最新のセキュリティパッチを自動的に適用することで、継続的にOSやソフトウェアが安全な状態に保つ
• 定期的な脆弱性スキャン・評価を行い、潜在的リスクの特定や修正を行う

ユーザーの識別

• Google Cloudのインフラストラクチャにアクセスする際に、利用者を識別するための厳密な認証が行われる。これはフィッシング耐性のあるセキュリティキーなど高度な仕組みで保護されている

参考リンク

• Google セキュリティの概要
• Google Cloud におけるインフラストラクチャのセキュリティ

ユーザーが考慮すべきセキュリティ

責任共有モデルにおけるユーザー管理部分のセキュリティは、ネットワークセキュリティが重要な要素を占めます。ネットワークセキュリティに関しては、ネットワークセキュリティのセクションをご参照ください。また、IAMに関しては、最小権限の原則を遵守し、不用意にサービスアカウントキーを発行・管理しないなどの対策が必要です。kちらに関してはアカウント設計のセクションをご覧ください。

その他、ユーザーが考慮すべき点として、データの暗号化や機密データの保護が挙げられます。

アプリケーションレベルで不正なアクセスを防ぐことも重要です。これには前述のWAFが提供されていますが、ボットや不正な自動アクセスを排除する reCAPTCHA のサービスも提供されています。ただし、これらのサービスを使う以前に、アプリケーションコードをセキュアに実装することが重要です。

データ暗号化

Google Cloudでは、データの保護を強化するために以下の暗号化手法を提供しています。

Confidential VMs

Confidential VMsは、データ処理時にメモリを含むすべてのCPU外の場所でデータが暗号化された状態を維持します。これにより、アプリケーションコードを変更することなく、高度なセキュリティが実現されます。

KMS

次にストレージ（GCS、GCEのディスク、BigQuery、CloudSQL等）の暗号化についてです。Google Cloudに保存されるデータは全てデフォルトで透過的な（ユーザーに見えないところで）暗号化されます。多くの場合、このデフォルトの鍵を使用しておけば十分です。ただし、暗号化鍵の地理的な所在を指定したり、鍵の無効化やローテーションをユーザー側で行うなどの要件がある場合は Cloud Key Management Service (KMS) を使用して 顧客管理の暗号鍵（CMEK） による暗号化を行うことで対応可能です。

エンベロープ暗号化

まず、KMSにおいてデータがどのように暗号化されストレージに格納されるかを簡単に紹介します。

暗号化の際に使用される鍵には、データ暗号化鍵（Data Encryption Key: DEK）とキー暗号化鍵（Key Encryption Key: KEK）の2種類があります。

暗号化の際、

1. DEKでデータを暗号化
2. KEKでDEKを暗号化
3. 暗号化DEKと暗号化データをストレージに格納
4. KEKをKMSに格納

します。そして復号の際に、

1. KEKで暗号化DEKを復号
2. DEKで暗号化データを復号

します。このようにデータ暗号化のための鍵を別の鍵で暗号化することをエンベロープ暗号化と呼びます。

ユーザー管理鍵の種類

KMSでユーザーが管理する鍵には次の3種類があります。

• 生成された鍵: Google Cloud上で生成し、Google Cloud上で管理するKEK
• インポートされた鍵: 外部で生成し、Google Cloud上で管理するKEK
• 外部で管理する鍵: 外部の鍵管理システムで管理し、暗号化が必要な際に Cloud External Key Manager (EKM) を通してGoogle Cloud内に取り込むことなく使用する

その他KMSに関して

KMSで管理する鍵は、キーリングという鍵をグループ化するためのコンテナを指定して管理します。

また、執筆時点ではプレビューですが、フォルダレベルで設定を行うことにより、Autokey という機能によって鍵の管理を自動化することもできます。

機密データの保護

機密データの保護（Sensitive Data Protection） というサービスによって、ストレージに格納されている構造化/非構造化データ内の機密データを検出・マスキング処理などが行えます。以前はData Loss Prevention (DLP)というサービスが提供されていましたが、これは「機密データの保護」に統合されました。API名にはこの名前が残っています。

GCS、DatastoreモードのFirestore、BigQueryに対して、人名、住所、クレジットカード番号、メールアドレスといったなどの機密情報を機械学習によって検出し、設定によってマスキングやトークナイゼーションします。なお、機密情報のうち、個人を特定できる情報を PII (Personally Identifiable Information) と呼びます。

注意する点としては、以下があります。

• DLPの検出は高精度ではあるが、完全に全ての機密情報を検出できる訳ではない
• 全てをすぐにスキャンはできないため、アクセス頻度やリスクの大きさ等からスキャン対象の優先順位をつけ、最初のジョブでスキャンする範囲を制限する

reCAPTCHA

reCAPTCHA とは、悪意あるボットや自動アクセスを検出し、Webサイトを保護する技術です。これにはv1からv3があり、v2の「私はロボットではありません」というチェックボックスに見覚えがある方は多いでしょう。

このreCAPTCHAのv3をベースとし、詳細なカスタマイズを可能として提供しているサービスが reCAPTCHA Enterprise です。

reCAPTCHA（出典:https://www.google.com/recaptcha/about/ ）

参考リンク

• Cloud Key Management Service の概要
• デフォルトの保存データの暗号化
• Confidential VM overview
• エンベロープ暗号化
• Cloud External Key Manager
• Cloud KMS with Autokey
• 機密データの保護の概要
• Google Cloud のストレージとデータベースに含まれる機密データの検査
• reCAPTCHA overview

まとめ

このセクションでは、Google Cloud を安全に利用してアプリケーションを構築するための基本的な知識を説明しました。

実際の構築にあたっては、「コンプライアンス・ホワイトペーパー・規約」にリンクされているドキュメントやベストプラクティスを参照しながら進めることをお勧めします。

脚注

1. クラウドには、不特定多数のユーザが共有するパブリッククラウドと、特定ユーザが占有するプライベートクラウドがあります。この記事ではパブリッククラウドを単にクラウドと呼びます。

2. IaaS、PaaS、SaaSのように、インターネットを介してクラウドサービスとして提供する形態をXaaSと表現します。

3. ユースケースとしては、オンプレミスリソースにクラウドリソースを追加してスケーラビリティを向上する、オンプレミスのデータをGoogleCloudにバックアップするDR(DisasterRecovery)、アプリケーションの段階的な移行など、様々なものがあります

4. ユースケースとしては、複数のクラウドで得意な領域を組み合わせて使用する、特殊なサービスをスポットで使用するなどがあります。例えば、WebやモバイルのバックエンドをAWSで構築し、データ分析基盤をGoogleCloudに構築するなど。

5. 以前はメンバーという用語が使用されており、一部APIではその用語が残っているようです。Terraformのgoogle_project_iam_memberもこの名残でしょうか？

6. GmailやGoogleドライブなどのGoogleが提供するツール群及びコラボレーションサービスのスイート

7. 「すべてのユーザー」の利用を検討するよう、ドキュメントに注意書きがあります

8. 「アカウント」と名前がつくが、プリンシパルのアカウントとは別の概念

9. 予期せず高額な請求額が発生した場合、まずはGoogleCloudに事情を説明してみるのが良いでしょう。

10. https://cloud.google.com/architecture/best-practices-vpc-design?hl=ja#custom-mode

11. 名前が紛らわしいと思いますが、それぞれの違いについて、こちらの記事などをご参照ください

12. ネットワーク境界とは、異なるネットワークセグメントやシステム間の接点や分岐点のことです。ファイアウォールやルーターなどによってこの境界を定めます。

13. ネットワークではなくVMインスタンスでミラーリングが行われるので、VM上の帯域幅が消費されます。

14. ロードバランサからバックエンドへの通信を暗号化するには、SSL証明書の設定やバックエンドでのTLS終端の設定が必要です。ただし、ロードバランサがSSL終端となり、バックエンドへの通信は暗号化されない構成は一般的です。