G-genの杉村です。BigQuery への認証・認可は Cloud IAM によって制御されますが、その仕組みは複雑です。当記事では、仕組みを詳細に解説します。 はじめに BigQuery と認証・認可 IAM の基本概念 BigQuery 関連の IAM 権限の理解 ジョブ実行とデータアクセス ジョブ実行権限 データへのアクセス権限 読み取り権限 読み取り権限の検証 書き込み権限 メタデータへのアクセス権限 ロールが持つ IAM 権限 ユースケース別 IAM 設定 プロジェクトのすべてのデータセットに対する閲覧権限を与えたい 設定 説明 特定のデータセットにだけ閲覧・編集権限を与えたい 設定 説明 特定のプロジェクトの BigQuery 全体管理者 設定 説明 BigQuery のデータを含むプロジェクト内の全リソースの閲覧権限を与えたい 設定 説明 閲覧者ロールに関する考察 その他のユースケース はじめに BigQuery と認証・認可 Google Cloud（旧称 GCP）のデータウェアハウスサービスである BigQuery では、認証・認可が Identity and Access Management（IAM）によって制御されます。 Google Cloud の IAM の仕組み自体が難しいことに加えて、BigQuery では ジョブ実行権限 と データ取得・編集権限 が別れていたり、「基本ロール」には 特殊な仕組みで 権限が与えられていたり、と難解です。 当記事では、実環境での検証結果も交えて解説します。 IAM の基本概念 まずは Google Cloud の IAM の基本的な仕組みを理解する必要があります。本投稿では以下の記事の内容が理解されている前提で記載しておりますので、先にご参照ください。 特に「リソースの持つ許可ポリシー」「ロール」「継承」などの用語理解が必須です。 blog.g-gen.co.jp BigQuery 関連の IAM 権限の理解 ジョブ実行とデータアクセス BigQuery の ジョブ とは、BigQuery のコンピューティングリソースを使って行われる以下のような操作を指します。 クエリ（テーブルの読み取り、書き込み） ロード（テーブルへのデータ投入） エクスポート（Cloud Storage バケットなどにデータを出力） コピー（テーブルを複製する） これらの操作がユーザーやプログラムにより行われると、ジョブが作成され、バックグラウンドで処理が行われます。例として、コンソールに SQL を入力して実行したり、bq コマンドによって Cloud Storage からのデータロードなどを行う際に、ジョブが実行されます。 参考 : ジョブを管理する BigQuery では、この「 ジョブを実行する権限 」と「 テーブルのデータにアクセスする権限 」が区別されています。 普段仕事で使うパソコンに例えると、パソコンにログインをする権限と、ファイルサーバへのアクセス権限とは別になっている、というようなイメージです。 ジョブ実行権限とデータへのアクセス権限 別れている理由は、以下の例を考えると理解しやすくなります。 Google が公開しているパブリックデータセットを使って分析を行うケースを考えます。データセットへのアクセス権限は全世界に公開されており、データの保管料金は、データを保持している会社（プロジェクト）に課金されています。しかしクエリジョブはデータ利用者側の Google Cloud プロジェクトに投入する必要があり、コンピュート料金もデータを利用する側が負担します。 他プロジェクトのデータを使う場合 このようにデータを保管するユーザーと、クエリを実行するユーザーがわかれているとき、IAM 権限が別々に管理されているために、責任範囲や費用負担を分割することができます。 ジョブ実行権限 ジョブ実行関連の IAM 権限には bigquery.jobs.create 、 bigquery.jobs.get 、 bigquery.jobs.list といったものがあります。 ジョブを実行するには bigquery.jobs.create の権限が必要です。この権限は、以下のような事前定義ロールに含まれています。 BigQuery 管理者 （ roles/bigquery.admin ） BigQuery ジョブユーザー （ roles/bigquery.jobUser ） BigQuery ユーザー （ roles/bigquery.user ） BigQuery Studio ユーザー （ roles/bigquery.studioUser ） これらのロールは、 プロジェクト レベル以上（組織、フォルダ、プロジェクト）で付与する必要があります。ジョブはプロジェクトの API に対して投入するものなので、これらのロールをデータセットのレベルに付与しても効果がないか、ロールによっては付与できない仕様になっています。 ただし、ジョブの実行権限だけを持っていても、データにアクセスすることはできません。次に記載するデータへのアクセス権限が必要です。 データへのアクセス権限 読み取り権限 BigQuery のテーブルへクエリ等を行うには、ジョブ実行権限に加えて、 データへのアクセス権限 が必要です。先ほどの仕事用パソコンの例えを使うと、こちらはファイルサーバへのアクセス権限です。 テーブル内のデータに読み取りアクセスするには、 bigquery.tables.getData の権限が必要です。この権限は、以下のような事前定義ロールに含まれています。 BigQuery 管理者 （ roles/bigquery.admin ） BigQuery データオーナー （ roles/bigquery.dataOwner ） BigQuery データ編集者 （ roles/bigquery.dataEditor ） BigQuery データ閲覧者 （ roles/bigquery.dataViewer ） これらのロールは プロジェクト レベル、 データセット レベル、あるいは テーブル レベルで付与することができます。親リソースにロールを付与すれば、その配下にある子リソースすべてに権限が継承されます。 例えばあるデータセット内のデータに読み取りクエリを実行したい場合、そのユーザーのアカウントに、 プロジェクト レベルで BigQuery ジョブユーザー （ roles/bigquery.jobUser ）を付与するのに加えて、該当のデータセットレベルで BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）を付与します。これにより、このユーザーはプロジェクトレベルでのジョブ実行権限と、データセットレベルでのデータ読み取り権限を得ることになり、SELECT 文等を実行することができます。 読み取り権限の検証 「ジョブ実行権限はプロジェクトレベルで付与する必要がある」そして「データへのアクセス権限はデータセットレベルもしくはテーブルレベルで付与する」と記載したことについて、検証します。 BigQueryの権限のディシジョンテーブル BigQuery ジョブユーザー（ roles/bigquery.jobUser ）ロールはデータセット単位では付与できない仕様のため、上記の表では N/A となっています。 表のとおり、プロジェクトレベルにジョブ実行権限がない場合にはクエリが実行不可（N）という結果になりました。 またジョブ実行権限さえあれば、データ読み取り権限はデータセットレベルで付与することでデータが読み取れる、という結果が確かめられました。なお、データセットレベルでなく、テーブルレベルで権限を付与することでも、データを読み取ることができます。 書き込み権限 書き込み権限について、基本的な考え方は読み取り権限と同様です。 書き込みアクセスに必要な権限は bigquery.tables.updateData です。この権限は、以下のような事前定義ロールに含まれています。 BigQuery 管理者 （ roles/bigquery.admin ） BigQuery データオーナー （ roles/bigquery.dataOwner ） BigQuery データ編集者 （ roles/bigquery.dataEditor ） メタデータへのアクセス権限 メタデータはデータセットやテーブルの持つ付随的な属性情報です。テーブルのスキーマ情報などがこれに当たります。 仕事場のパソコンの例えを使うと、ファイルサーバのデータ容量の使用状況やディスクのドライブ名、またファイルシステムの設定値などが当たります。 データセットのメタデータに対する権限として bigquery.datasets.get 、 bigquery.datasets.update があり、テーブルのメタデータに対する権限として bigquery.tables.get 、 bigquery.tables.update などがあります。 メタデータの閲覧・編集権限があれば、テーブル名やカラム情報を得ることができますが、テーブル内のデータ（レコード）を閲覧したり、編集することはできません。 事前定義ロールである BigQuery データ編集者 （ roles/bigquery.dataEditor ）や BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）などは、データに対する権限に加えて、メタデータに対する権限も持っています。 一方で、 BigQuery メタデータ閲覧者 （ roles/bigquery.metadataViewer ）ロールはメタデータに対する読み取り権限を持っていますがデータ自体への権限はないので、 BigQuery 基盤の管理者・運用者などが使うことが想定されます。 ロールが持つ IAM 権限 どの IAM ロールがどのような権限を持っているかを確認したい場合、以下のドキュメントを参照します。 テキストボックスに権限名を入力して検索することで、ある権限を持つロールの一覧が確認できます。また逆に、ロール名を検索することで、そのロールが持つ権限の一覧を確認できます。 参考 : IAM roles and permissions index ユースケース別 IAM 設定 プロジェクトのすべてのデータセットに対する閲覧権限を与えたい 設定 付与対象リソース プロジェクト 付与する IAM ロール BigQuery Studio ユーザー （ roles/bigquery.studioUser ） BigQuery データ閲覧者 （ roles/bigquery.dataViewer ） 説明 プロジェクトレベルで、Google アカウントに対して上記の2つのロールを付与することで、そのアカウントはプロジェクト内のすべてのデータセット・テーブルに対して読み取りクエリを実行することができるようになります。 BigQuery Studio ユーザー（ roles/bigquery.studioUser ）ロールをプロジェクトレベルで設定することにより、アカウントは BigQuery ジョブを実行する権限を得ます。 BigQuery Studio ユーザーロールの代わりに BigQuery ジョブユーザー（ roles/bigquery.jobUser ）ロールでも構いませんが、BigQuery Studio ユーザーロールを付与することで Gemini in BigQuery を含む、BigQuery Studio（BigQuery の Web コンソール）のほとんどすべての機能を利用することができます。Gemini in BigQuery は生成 AI が SQL コーディングの補助等をしてくれる機能であり、制限付きながら無償で利用できます。 もしロールの付与対象が人間のユーザーではなくサービスアカウントである場合、BigQuery Studio ユーザーロールよりも BigQuery ジョブユーザーロールの方が適しています。 上記に加え、BigQuery データ閲覧者（ roles/bigquery.dataViewer ）をプロジェクトレベルに設定することで、アカウントはプロジェクト内の全てのデータセットとテーブルに対して閲覧権限を持ちます。 特定のデータセットにだけ閲覧・編集権限を与えたい 設定 IAM 設定 1 付与対象リソース プロジェクト 付与する IAM ロール BigQuery Studio ユーザー （ roles/bigquery.studioUser ） IAM 設定 2 付与対象リソース データセット 付与する IAM ロール BigQuery データ編集者 （ roles/bigquery.dataEditor ） 説明 上記の IAM 設定 1 と 2 の両方、すなわちプロジェクトレベルとデータセットレベルの両方で、アカウントに対してロールを付与することで、特定のデータセットに対してのみ、INSERT や UPDATE、SELECT の実行などデータの読み取り・編集権限を得ることができます。 BigQuery Studio ユーザー（ roles/bigquery.studioUser ）ロールなどをプロジェクトレベルで付与することで、アカウントはジョブを実行できるようになります。なお同ロールはデータセットレベルには付与できない仕様であり、必ずプロジェクトレベル以上にしか付与できません。 また BigQuery データ編集者（ roles/bigquery.dataEditor ）をデータセットレベルで付与することで、そのデータセットに対してのみ、データの編集権限を持つことができます。一方でプロジェクトレベルに設定すると、プロジェクト内の全てのデータセットとテーブルに対して編集権限を持つことができます。 特定のプロジェクトの BigQuery 全体管理者 設定 付与対象リソース プロジェクト 付与する IAM ロール BigQuery 管理者 （ roles/bigquery.admin ） 説明 プロジェクトレベルで BigQuery 管理者（ roles/bigquery.admin ）ロールを付与すれば、そのアカウントはジョブの実行、データへのアクセス、データセットやテーブルの作成、など BigQuery に関する全ての操作を行うことができます。 BigQuery のデータを含むプロジェクト内の全リソースの閲覧権限を与えたい 設定 付与対象リソース プロジェクト 付与する IAM ロール 閲覧者 （ roles/viewer ） 説明 ある Google アカウントが 閲覧者 （ roles/viewer ）ロールをプロジェクトレベルで持っていると、BigQuery の全データセット・テーブルのデータとメタデータを閲覧することができます。 閲覧者は、BigQuery 以外のほとんどすべての情報に対する閲覧権限も持つため、注意が必要です。 閲覧者ロールに関する考察 閲覧者（ roles/viewer ）ロールと BigQuery の関係性について、詳細に解説します。 閲覧者（ roles/viewer ）ロールの持つ BigQuery 関係の権限を一覧化すると、以下のようになります。 sugimura@cloudshell:~ ( gcp-dev-yuma-sugimura ) $ gcloud iam roles describe roles/viewer | grep bigquery - bigquery.bireservations.get - bigquery.capacityCommitments.get - bigquery.capacityCommitments.list - bigquery.config.get - bigquery.connections.get - bigquery.connections.getIamPolicy - bigquery.connections.list - bigquery.connections.use - bigquery.datasets.get - bigquery.datasets.getIamPolicy - bigquery. jobs .create - bigquery. jobs .get - bigquery. jobs .list - bigquery.models. export - bigquery.models.getData - bigquery.models.getMetadata - bigquery.models.list - bigquery.readsessions.create - bigquery.readsessions.getData - bigquery.readsessions.update - bigquery.reservationAssignments.list - bigquery.reservationAssignments.search - bigquery.reservations.get - bigquery.reservations.list - bigquery.routines.get - bigquery.routines.list - bigquery.rowAccessPolicies.getIamPolicy - bigquery.rowAccessPolicies.list - bigquery.savedqueries.get - bigquery.savedqueries.list - bigquery.tables.createSnapshot - bigquery.tables.getIamPolicy - bigquery.transfers.get 上記から抜粋すると、BigQuery のテーブルに関する権限は以下の2つだけです。 - bigquery.tables.createSnapshot - bigquery.tables.getIamPolicy これでは、閲覧者ロールはテーブルのメタデータやデータに対するアクセス権限は持たないはずです。前述の通り、データにアクセスするには bigquery.tables.getData の権限が必要です。 bigquery.jobs.create 権限はあるのでジョブ実行はできますが、テーブルのデータは読み取れず、Access Denied エラーになるはずです。 しかし実際には、テーブルのデータを取得することができます。これは、BigQuery が新規データセットに対してデフォルトで付与する、以下の設定が関係しています。 閲覧者ロールを持つことは BigQuery データ閲覧者ロールを持つことと同義 上のスクリーンショットの通り、プロジェクトレベルで閲覧者（ roles/viewer ）ロールが付与されている人は、データセットに対して BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）相当の権限を持つように設定されています。これは IAM の仕組みとは異なる、レガシーなアクセス権限の仕組みに起因しています。 これは、データセットを新規作成するときに自動で設定される、BigQuery 特有の設定です。これにより、閲覧者（ roles/viewer ）ロール自体は bigquery.tables.getData 権限を持っていないため、本来はデータにアクセスできないはずですが、データセット側の個別設定で BigQuery データ閲覧者 （ roles/bigquery.dataViewer ）相当の権限を与えられていたためアクセスができるようになっています。 参考 : Basic roles and permissions 同様にプロジェクトレベルの オーナー （ roles/owner ）には BigQuery データオーナー （ roles/bigquery.dataOwner ）相当の権限が、プロジェクトレベルの 編集者 （ roles/editor ）には BigQuery データ編集者 （ roles/bigquery.dataEditor ）権限が割り当てられます。 これらの自動で割り当てられる権限は、削除することも可能です。 その他のユースケース 以下の公式ドキュメントに、BigQuery 関連の事前定義ロールがどのような権限を持っていて、どのリソースに付与可能なのかが一覧化されています。 当記事の内容を理解したあとは、以下のページを参照し、きめ細かい権限設定を検討してください。 参考 : BigQuery の IAM ロールと権限 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud（旧称 GCP）の証跡管理の仕組みである Cloud Audit Logs （Cloud Audit Logging）について解説します。 Cloud Audit Logs の基本 Cloud Audit Logs とは API リクエストとは Cloud Audit Logs で記録できるログ ログの出力先 料金 考え方 監査ログの料金 監査ログの種類 4 つの監査ログ No 1. 管理アクティビティ監査ログ No 2. データアクセス監査ログ No 3. システム イベント監査ログ No 4. ポリシー拒否監査ログ ログの保存期間 データアクセス監査ログの有効化 有効化手順 3つの種類 除外するプリンシパル 監査ログの集約 集約の必要性 設定手順 データアクセス監査ログと Cloud Storage の認証済み URL Cloud Audit Logs の基本 Cloud Audit Logs とは Cloud Audit Logs とは、Google Cloud（旧称 GCP）の API リクエスト履歴を記録する仕組みです。 監査対応やトラブルシューティングに活用することができます。この仕組みにより Google Cloud で「いつ、誰が、どこから、何をしたか」が自動的に記録されます。 一部の記録はデフォルトでオンになっており、設定変更によってさらに広い範囲のログが記録されるようになります。 参考 : Cloud Audit Logs overview API リクエストとは まず、必要な前提知識を確認します。Cloud Audit Logs は、 Google Cloud に対する API リクエストを証跡管理の目的で記録するサービスです。では、ここでいう「API リクエスト」とは何でしょうか？ Amazon Web Services（AWS）を始め、多くのパブリッククラウドは、インターネットに公開された Web API で操作されます。Google Cloud もほぼ全てのリソースが Web API 経由で操作 （閲覧、作成、更新、削除）されます。例えば、以下のような操作は全て Web API リクエストで行われます。 VM の閲覧、作成、起動、停止 Cloud Storage へのオブジェクトのList、Get、Put、Delete BigQuery へのクエリ、メタデータの閲覧、更新 API リクエストと履歴の記録 AWS や Google Cloud を Web コンソール画面で操作したとしても、その Web 画面のバックエンドでは、 Web API リクエストが発行されている と考えてください。 パブリッククラウドの Web API はインターネットに公開されていますが、誰でも API を実行できるわけではなく、IAM の仕組み等で認証・認可されていますので、セキュリティが保たれます。 Google Cloud では、各サービスごとに Web API のエンドポイントが用意されています。なおこれらの API を総称して Google Cloud APIs と呼びます。 一方で、以下のようなアクセスは Web API リクエストとは別です。 VM への SSH アクセス VM でホストされた Web サイトへの HTTP（S）リクエスト これらは Virtual Private Cloud（VPC）という仮想ネットワーク内の VM に対して、TCP/IP 的にリーチするアクセスですので、クラウドの Web API とは別の経路でアクセスすることになります。 Google Cloud APIs の詳細については、以下の記事も参照してください。 blog.g-gen.co.jp Cloud Audit Logs で記録できるログ Cloud Audit Logs により、いつ誰が Google Cloud サービスに対して Web API リクエストを行い、リソースの閲覧、作成、編集、削除等を行ったかが記録されます。 これらの記録は「監査証跡として」「オペレーションミスやセキュリティインシデントの事後調査」「内部的の抑止」「利用状況の分析」などに用いられます。 Cloud Audit Logs に記録されるのは、 Google Cloud APIs に対するリクエスト です。一方で、前の小見出しで最後に示した、 VPC への TCP/IP 的なアクセスは記録されません 。 後者の履歴を記録するのは、VPC の機能である VPC Flow Logs やファイアウォールログ、もしくはアプリケーション側のロギングの役割です。 なお、Cloud Audit Logs に対応している Google Cloud サービスの一覧は、以下のドキュメントに示されています。 参考 : 監査ログを使用する Google Cloud サービス ほとんどすべての Google Cloud サービスが Cloud Audit Logs でカバーされている一方、Google AI Studio（ generativelanguage.googleapis.com ）など、Google Cloud ではないサービスは対象になっていません。 ログの出力先 Cloud Audit Logs により記録されたログは、 Google Cloud のログ管理サービスである Cloud Logging に保存されます。 Cloud Logging については以下の記事で詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp 料金 考え方 Cloud Audit Logs 自体に料金は発生しません。しかし、ログの 保存先である Cloud Logging の料金 が発生します。 Cloud Logging の料金は、「ログの取り込み量」「ログの保管量」のそれぞれに対する従量課金です。前者は、月に 50 GiB まで無料で、それを超える量に対して料金が発生します。後者は、デフォルトの保管期間であれば無料であり、ログの保管期間を長くした場合に発生します。 参考 : Google Cloud Observability の料金 - Cloud Logging の料金概要 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - G-gen Tech Blog - 料金 監査ログの料金 デフォルトで出力される監査ログ（管理アクティビティ監査ログなど）については、デフォルトで Cloud Logging ログバケットである _Required ログバケットに保管されます。特に設定を変更しなければ「ログの保管量」に対する課金は発生せず、無料で保管できます。また、プロジェクト全体のログの取り込みボリュームの合計が無料枠である 50 GiB を超えないうちは、「ログの取り込み量」に対する料金も発生しません。 参考 : 転送とストレージの概要 - _Required ログバケット データアクセス監査ログを明示的に有効化した場合や VPC Service Controls を有効化してポリシー拒否監査ログが発生した場合、特に設定を変更しなければこれらのログは _Default ログバケットに出力され、デフォルトの保管期間である「30日間」を変更しない限り、「ログの保管量」に対する課金は発生しません。また、プロジェクト全体のログの取り込みボリュームの合計が 50 GiB を超えなければ、「ログの取り込み量」に対する料金も発生しません。ただし、使用状況や設定内容にもよりますが、データアクセス監査ログは大量に発生する傾向があります。ログの発生量には注意が必要です。 参考 : 転送とストレージの概要 - _Default ログバケット 監査ログの種類 4 つの監査ログ Cloud Audit Logs では前述の通り、 Google Cloud サービスに対する Web API リクエストの履歴が記録されますが、記録されるログにはいくつかの種類があります。それらのうちには、デフォルトで有効化されているログもあれば、任意で利用者が有効化する必要があるものもあります。 No 名称 説明 料金 デフォルト 1 管理アクティビティ監査ログ (Admin Activity audit logs) リソースに対する管理的な更新系の API リクエストが記録される 無料 有効 (無効化できない) 2 データアクセス監査ログ (Data Access audit logs) リソースやデータに対する更新系・読み取り系の API リクエストが記録される。有効化するとログ容量が大きくなる可能性があるため注意 有料 無効 (BigQueryのみデフォルト有効) 3 システム イベント監査ログ (System Event audit logs) ユーザではなくGoogle Cloudサービスによって行われたリソース構成変更が記録される 無料 有効 (無効化できない) 4 ポリシー拒否監査ログ (Policy Denied audit logs) VPC Service Controls 機能で拒否された API リクエストが記録される 有料 有効 (除外フィルタ設定可能) 参考: 監査ログの種類 No 1. 管理アクティビティ監査ログ 管理アクティビティ監査ログ は、 更新系 の API リクエストのことです。組織やプロジェクトで、デフォルトで有効化されています。 Compute Engine VM が作成されたり、Cloud Storage のバケットが作成・削除されたりする際に、このログが出力されます。 更新系操作は証跡管理上の重要度が高いため、デフォルトで有効となっており、400日間保存されます。無効化はできませんが、料金も発生しません。 No 2. データアクセス監査ログ データアクセス監査ログ は、 データに対する読み取り系および更新系のログ が記録されます。BigQuery を除き、デフォルトではオフになっています。一般的に、データの更新・読み取りアクセスは書き込みに比べて頻度が多いことから、データ量が大きくなり、利用ボリュームによっては料金が高額になる可能性があります。 BigQuery のみ、デフォルトでデータアクセス監査ログが有効化されており、無効化はできません。 データアクセス監査ログとして記録されるオペレーションの例として、Cloud Storage のオブジェクトの作成、削除、オブジェクトの一覧表示、オブジェクトの取得などがあります。どのオペレーションがデータアクセス監査ログに当たるかは、サービスごとのドキュメントに記載されています。 参考 : Cloud Storage での Cloud Audit Logs データアクセス監査ログは Google Cloud サービス単位で有効化することができます。有効化すると、ログの取り込み量、保存量、保存期間に応じて Cloud Logging の料金が発生します。 データの読み取りや更新の頻度が多いと、データアクセス監査ログに対して多額の利用料金が発生する可能性があるため、特に重要なデータを扱う可能性があるサービスを選定し、必要性とコストのトレードオフを検討してから有効化してください。 例として、個人情報を格納している Cloud Storage バケットが存在するプロジェクトなどで、データアクセス監査ログを有効化することを検討します。 また、Cloud Logging の除外フィルタ設定により、記録されるログをフィルタすることで料金を節約することができます。 参考 : 除外フィルタ No 3. システム イベント監査ログ システム イベント監査ログ は、人間のユーザーによる API リクエストではなく、 Google Cloud サービス側のリクエストによりリソースに変更があった際に記録されます。 システム イベント監査ログはデフォルトで有効化されており、無効化はできません。また、料金も発生しません。 No 4. ポリシー拒否監査ログ ポリシー拒否監査ログ は、VPC Service Controls のポリシーが違反されたときに記録されるログです。 ポリシー拒否監査ログの記録と保存には Cloud Logging 料金が発生します。料金を節約したい場合、Cloud Logging の除外フィルタ設定によるフィルタを検討してください。 VPC Service Controls については、以下をご参照ください。 blog.g-gen.co.jp ログの保存期間 デフォルトで有効化されている監査ログは、組織、各フォルダ、各プロジェクトにデフォルトで存在するログバケット _Required に保存され、 400日間 保持されます。 ログバケット とは、ログを保存するための Cloud Logging 専用ストレージであり、Cloud Storage バケットとは名前が似ていますが、別物です。 _Required ログバケットの保存期間は変更することができないため、400日間以上ログを保持したい場合、Cloud Logging でシンク（ログを選別して保存先へルーティングするための仕組み）を作成して、より長い保存期間を設定した別のログバケットや Cloud Storage バケット、BigQuery 等にログを保存します。 また、データアクセス監査ログを有効化すると _Default ログバケットに保存されます。 _Default ログバケットの保持期間は 30日間 です。 _Default ログバケットの保存期間は変更できるため、より長い保存期間が求められる場合は保存期間を変更するか、シンクを作成して別のストレージにログを保存します。 データアクセス監査ログの有効化 有効化手順 データアクセス監査ログを有効化するには、Google Cloud の Web コンソール、gcloud コマンドライン、REST API などを利用します。詳細な手順は以下の記事を参照してください。 参考 : データアクセス監査ログを有効にする 3つの種類 データアクセス監査ログには、3種類の有効化オプションがあります。 名称 説明 ADMIN_READ メタデータや構成情報に対する読み取りオペレーションを記録 DATA_READ ユーザー提供のデータに対する読み取るオペレーションを記録 DATA_WRITE ユーザー提供のデータに対する書き込みオペレーションを記録 Cloud Storage を例に取ると、オブジェクトのメタデータ（保存日時、データサイズ、名称の取得等）を取得するリクエストは ADMIN_READ に分類されます。データ自体をダウンロードするリクエストは DATA_READ に分類されます。 Google Cloud プロジェクトにおいて、各 Google Cloud サービスごとに、上記のうち有効化するログを選択して有効化します。すべて有効化することもできますし、一部のみを有効化することもできます。また、全サービスのすべてのログを取得するように設定することもできます。 参考 : 構成の概要 除外するプリンシパル 特定の プリンシパル （Google アカウントやサービスアカウントなど）を指定して、そのプリンシパルだけはデータアクセス監査ログを生成しないように設定できます。 例えば、イベントドリブンで頻繁に起動する Cloud Run functions があるとします。この関数は、数秒に1度、オブジェクトがバケットにアップロードされるたびに起動して、サービスアカウントの権限を使ってオブジェクトを取得し、短い処理を行ってから終了する、とします。この関数は頻繁に起動して Cloud Storage オブジェクトにアクセスするため、データアクセス監査ログが膨大になることが想定されます。このような場合に、関数が使うサービスアカウントを Cloud Storage のデータアクセス監査ログの除外プリンシパルとして設定すれば、関数からのアクセスはログに記録されません。 除外するプリンシパルは、Google Cloud サービスごとに指定できます。 参考 : 除外を設定する 監査ログの集約 集約の必要性 前述の通り、デフォルトでは監査ログは組織、各フォルダ、各プロジェクトのログバケット _Required に保存されます。 しかし、以下のような要件がある場合、 ログ集約用のプロジェクト を作成し、その中にログ集約用ログバケットを作成したあと、組織レベルで 集約シンク を作成することで、組織配下の全ての監査ログを1か所に集約することができます。 複数プロジェクトのログを集約して SIEM で分析したい 監査のために監査ログをエクスポートして第3者に提出する必要がある 複数プロジェクトを横断して監査ログをクエリしたい 集約シンクを使ってログを集約する場合、ログバケットへのデータ取り込みに対して、ログの取り込み量、保存量、保存期間に応じて料金が発生する点に留意しましょう。 シンクによるログの集約 なお、単純に複数プロジェクトを横断して監査ログをクエリしたいだけであれば、Cloud Logging のログスコープ機能を使うことで実現できますが、この機能を使ってログを閲覧するにはログを保持する各プロジェクトに対してログの閲覧権限が必要です。ログをログ集約プロジェクトに集約することで、ログの閲覧者が各プロジェクト側に権限を持つ必要がなくなります。 参考 : Cloud Loggingの概念と仕組みをしっかり解説 - ログスコープ 設定手順 組織で監査ログを集約するには、以下のような流れで設定作業を行います。 ログ集約用の Google Cloud プロジェクトを用意 ログを保存するためのログバケットまたは BigQuery テーブル等を用意 組織レベル（フォルダレベル）で集約シンクを作成 シンクのサービスアカウントに、ログ保存先に書き込むための IAM 権限を付与 場合によってはログのボリュームが膨大になり利用料金がかさむため、必要に応じて最小限のログが収集されるよう、除外フィルタ設定を検討してください。 手順の詳細は、以下の公式ドキュメントを参照してください。 参考 : 組織のログをログバケットに保存する データアクセス監査ログと Cloud Storage の認証済み URL プロジェクトで Cloud Storage に対してデータアクセス監査ログを有効化すると、Cloud Storage オブジェクトの認証済み URL が使用できなくなります。 この事象を回避するには、Cloud Storage のデータアクセス監査ログのうち「データ読み取り」ログを無効化するか、URL を利用するアカウントを除外プリンシパルとして設定します。 参考 : 認証によるブラウザでのダウンロード 参考 : トラブルシューティング - 403: Forbidden トラブルシューティングの事例として、以下もご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。 限定公開の Google アクセス （Private Google Access）機能を使うと、External IP アドエスを持っていない VM から、Google Cloud サービスの API にアクセスできるようになります。 限定公開の Google アクセスとは 仕様 利用するドメイン名 前提知識 デフォルトのドメイン名を利用する 特殊なドメインを利用する private と restricted の違い 2つのドメイン名の違い private.googleapis.com restricted.googleapis.com 選択フローチャート 有効化の手順 概要 デフォルトのドメインの場合 private.googleapis.com restricted.googleapis.com オンプレミスから利用する 限定公開の Google アクセス vs Private Service Connect 限定公開の Google アクセスとは 限定公開の Google アクセス （Private Google Access）とは、Google Cloud（旧称GCP）の API に対して、External IP（Public IP）アドレスを持たない VM や、オンプレミスのクライアントから、プライベートネットワークのみでアクセスできるようにする仕組みです。 Google Cloud の API は、通常はインターネット経由でアクセスされることを想定しています。しかし、インターネットを介さず、プライベートネットワークでのアクセスを可能にするのが当機能です。 参考 : 限定公開の Google アクセス なお、類似の機能として Private Service Connect があります。どちらの機能を利用したら良いのかについては、Private Service Connect について解説した以下の記事で説明していますので、ご参照ください。 blog.g-gen.co.jp 仕様 イメージ 限定公開の Google アクセスの仕様と特徴は、以下のとおりです。 サブネット単位で有効化 する 有効化すると、 External IP を持たない VM やオンプレミスのノードが Google の API へアクセスできるように なる Cloud Storage や BigQuery などの Google Cloud サービスに加え、Google Map、Google 広告なども対象 利用するドメイン名の選択肢 として以下の3つがある。アクセス可能な API、必要なファイアウォール設定、DNS 設定などが異なる デフォルトのドメイン名を利用する private.googleapis.com を利用する restricted.googleapis.com を利用する 利用するドメイン名 前提知識 限定公開の Google アクセスを理解するには、前提として、 Google Cloud サービスは API によって操作され るものである、ということの理解が必要です。 これは、Amazon Web Services（AWS）などの他のパブリッククラウドでも同様です。VM の起動・停止や、 BigQuery のテーブルへのクエリなどは、 Web API を通じて行われます。Web ブラウザで Google Cloud コンソール画面を操作する際や、gcloud コマンドラインを実行する際も、内部的には HTTPS プロトコルにより Web API へのリクエストが実行されています。 Google Cloud API とクライアント これについては、以下の記事で詳細に解説しています。 参考 : Google Cloudの根幹を成すGoogle Cloud APIsとは何か - G-gen Tech Blog 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - G-gen Tech Blog - API リクエストとは 例えば、Cloud Storage API のエンドポイントは https://storage.googleapis.com/ であり、BigQuery API のエンドポイントは https://bigquery.googleapis.com/ です。これらの API エンドポイントは、インターネットに公開されています。そのため、Compute Engine VM から Cloud Storage や BigQuery を利用する場合、本来は External IP アドレスを使って、インターネット経由でアクセスする必要があります。 デフォルトのドメイン名を利用する 限定公開の Google アクセスで利用するドメイン名として、以下の3種類から選択できます。 デフォルトのドメイン名を利用する private.googleapis.com を利用する restricted.googleapis.com を利用する 選択肢 1. デフォルトのドメイン名を利用する は、もともとの Web API エンドポイントをそのまま利用する選択肢です。サブネットで限定公開の Google アクセスを有効化した場合、この状態になり、すぐに利用することができます。 この方法で VM から Google Cloud APIs へアクセスするには、VPC ルートで 0.0.0.0/0 をデフォルトインターネットゲートウェイに向ける必要があり ます。さらに、 ファイアウォールの下り（Egress）ルールで 0.0.0.0/0 に対する HTTPS（443/TCP）を許可する必要があり ます。 上記のような設定をすると、トラフィックがインターネットに出ていくようにも思えますが、この設定により External IP アドレスを持っていない VM でも、Google Cloud APIs へのアクセスができるようになります。また、通信は Google のネットワーク内に閉じたものになります。 参考 : 限定公開の Google アクセスを構成する - 構成オプションの概要 この設定では、VPC ネットワーク単位でデフォルトルートを 0.0.0.0/0 に向ける必要がありますし、ファイアウォール設定も空ける必要があります。設定ミス等により、意図せず VM が External IP アドレスを持ってしまった際などに、VM からはインターネットへのアウトバウンド通信が可能な環境になってしまいます。 これを防ぎたい場合は、他の選択肢が検討されます。 特殊なドメインを利用する 選択肢 2. private.googleapis.com を利用する と、 3. restricted.googleapis.com を利用する は、これらのドメイン名を、 デフォルトのドメイン名の CNAME として登録することでこれらを Web API エンドポイントとして利用 し、アクセス先 IP アドレスを変える方法です。 これらの選択肢では、VPC ネットワークに、 199.36.153.8/30 や 199.36.153.4/30 といったIP アドレス帯に対しての通信を許可するファイアウォールやルートを設定します。 理解しやすくするため、 restricted.googleapis.com の場合を例にとって、設定の流れを以下に記載します。 サブネットで 限定公開の Google アクセスを有効化 199.36.153.4/30 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（デフォルトでは 0.0.0.0/0 のネクストホップがインターネットゲートウェイになっているため、条件を満たしている） VPC ファイアウォールで、 199.36.153.4/30 への 443/TCP の 下り（Egress）通信が拒否されていないことを確認（デフォルトでは許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : restricted.googleapis.com タイプ : A IPv4アドレス : 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : restricted.googleapis.com 上記の手順で Cloud DNS が設定された状態 上記を設定すると挙動がどう変わるのでしょうか。例として、Compute Engine VM 内から gcloud storage コマンドを実行して、Cloud Storage へのアクセスが発生するときの内部的な動作を考えます。gcloud storage コマンドは、Cloud Storage API へリクエストするために、 storage.googleapis.com へ HTTPS でアクセスしようとします。すると VM は Cloud DNS を参照しますので、限定公開ゾーンを優先的に使って名前解決します。内部的には、以下のような処理が行われます。 VM が storage.googleapis.com を名前解決するため、Cloud DNS へクエリする クエリは *.googleapis.com に一致しているので、CNAME で restricted.googleapis.com へ解決される restricted.googleapis.com は A レコードにより 199.36.153.4 、 199.36.153.5 、 199.36.153.6 、 199.36.153.7 のどれかへ解決される VM がクエリへのレスポンスを受け取る gcloud コマンドは、 199.36.153.4 、 199.36.153.5 、 199.36.153.6 、 199.36.153.7 のいずれかへアクセス VPC ネットワークの設定で、これらの IP アドレスへのルートがデフォルトインターネットゲートウェイへ向いており、かつファイアウォールで 443/TCP が許可されていれば、上記の処理の結果として、Google の内部ネットワークを通って API リクエストができます。 解決先の IP アドレスとして、 private.googleapis.com では 199.36.153.8/30 を（上記の4つの IP アドレス）、 restricted.googleapis.com では 199.36.153.4/30 を使う必要があります。 これらの IP アドレスは、インターネットに広報されていない、限定公開の Google アクセス専用の IP アドレスです。 参考 : 名前解決の結果 private と restricted の違い 2つのドメイン名の違い 限定公開の Google アクセスでデフォルトのドメイン名を使わないパターンには、 private.googleapis.com を利用するパターンと、 restricted.googleapis.com を利用するパターンの2種類があります。いずれの場合も、基本的な仕組みは同様です。相違点は、 アクセスできる API の種類 と、 利用する IP アドレス です。 この相違点については、Google Cloud 認定資格である Professional Cloud Network Engineer 試験や Professional Cloud Security Engineer試験でも問われますので、受験予定がある方は restricted.googleapis.com と private.googleapis.com の違いについて、正しく理解することが推奨されます。 参考 : Professional Cloud Network Engineer試験対策マニュアル - G-gen Tech Blog 参考 : Professional Cloud Security Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog private.googleapis.com private.googleapis.com を使うパターンでは、ほとんどの Google API へのアクセスが可能です。 次に説明する restricted.googleapis.com では、 VPC Service Controls でサポートされている API にだけしかアクセスできませんが、 private.googleapis.com では、VPC Service Controls のサポート有無は関係ありません。 参考 : VPC Service Controlsを分かりやすく解説 - G-gen Tech Blog private.googleapis.com を使うと、多くの API にアクセス可能な一方で、VPC Service Controls で VM からの API アクセスを厳密にコントロールしたい場合には適していません。 VPC Service Controls を使用ておらず、使用する予定もない場合や、VPC Service Controls を使用するものの、サポート対象でない API へのアクセスを許可する場合に、 private.googleapis.com を選択することになります。 サポートされているアクセス先の一覧は、以下のドキュメントを参照してください。 参考 : 限定公開の Google アクセスを構成する - ドメイン オプション DNS に登録する専用 IP アドレスは、 199.36.153.8/30 です（ 199.36.153.8 、 199.36.153.9 、 199.36.153.10 、 199.36.153.11 ）。 restricted.googleapis.com restricted.googleapis.com を使うパターンでは、VPC Service Controls でサポートされている Google API に のみ 、アクセスできるようになります。それ以外の API へのアクセスは拒否されます。 VPC Service Controls を利用している、または利用する予定があり、かつ VM からは VPC Service Controls でサポートされていない API へのアクセスを禁止したい場合は、こちらを選択します。 サポートされているアクセス先の一覧は、以下のドキュメントを参照してください。 参考 : VPC Service Controls - サポートされているプロダクトと制限事項 DNS に登録する専用 IP アドレスは 199.36.153.4/30 （ 199.36.153.4 、 199.36.153.5 、 199.36.153.6 、 199.36.153.7 ）です。 選択フローチャート どのドメインを選択すればいいか、簡単なフローチャートで見てみましょう。 ドメイン名決定フローチャート 一番左の、デフォルトのドメイン名を選択すると、図中にあるように VM が External IP アドレス持っていると、インターネットへアクセスできてしまう などのリスクがあります。これを十分理解して選択しましょう。 有効化の手順 概要 当記事では、設定手順の概要だけを記載しています。詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : 限定公開の Google アクセスを構成する デフォルトのドメインの場合 対象のサブネットで 限定公開の Google アクセスを有効化 VPC ネットワークのルート設定で、 0.0.0.0/0 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（デフォルトでは設定済み） VPC ファイアウォールで、 0.0.0.0/0 への 443/TCP の下り（Egress）通信が拒否されていない ことを確認（デフォルトでは暗黙的に許可） private.googleapis.com 対象のサブネットで 限定公開の Google アクセスを有効化 VPC ネットワークのルート設定で、 199.36.153.8/30 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（ 0.0.0.0/0 がデフォルトインターネットゲートウェイに向いている設定でも問題ない） VPC ファイアウォールで、 199.36.153.8/30 への 443/TCP の 下り（Egress）通信が拒否されていない ことを確認（デフォルトでは暗黙的に許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : private.googleapis.com タイプ : A IPv4アドレス : 199.36.153.8 199.36.153.9 199.36.153.10 199.36.153.11 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : private.googleapis.com restricted.googleapis.com 対象のサブネットで 限定公開の Google アクセスを有効化 VPC ネットワークのルート設定で、 199.36.153.4/30 のネクストホップが デフォルトのインターネットゲートウェイへ向いている ことを確認（ 0.0.0.0/0 がデフォルトインターネットゲートウェイに向いている設定でも問題ない） VPC ファイアウォールで、 199.36.153.4/30 への 443/TCP の 下り（Egress）通信が拒否されていない ことを確認（デフォルトでは暗黙的に許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : restricted.googleapis.com タイプ : A IPv4アドレス : 199.36.153.4 199.36.153.5 199.36.153.6 199.36.153.7 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : restricted.googleapis.com オンプレミスから利用する Cloud Interconnect や Cloud DNS で Google Cloud に接続されたオンプレミス環境から、限定公開の Google アクセスを利用するには、以下の設定が必要です。 限定公開の Google アクセスの IP アドレス（ 199.36.153.8/30 等）を Cloud Router からオンプレミス側に広報する オンプレミスノードが参照する DNS に、フォワーダー設定を追加して、 Google Cloud APIs の名前解決を Cloud DNS の限定公開ゾーンに転送する 1つ目は、Cloud Router の カスタムルートアドバタイズ を使うことで実現可能です。2つ目は、Cloud DNS の 受信サーバーポリシー で実現可能です。 2つ目については、オンプレミスのクライアントが、限定公開の Google アクセスの IP アドレス（ 199.36.153.8/30 や 199.36.153.4/30 ）を向きさえすれば良いので、オンプレミスの DNS に Cloud DNS と同じレコードを追加しても構いません。 より詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : オンプレミス ホストの限定公開の Google アクセスを構成する 限定公開の Google アクセス vs Private Service Connect 類似の機能として、 Private Service Connect があります。 どちらの機能を利用したら良いのかについて以下の記事で説明していますので、ご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。当記事では Google Cloud APIs にプライベートネットワーク経由でアクセスするための機能である Private Service Connect について解説します。 概要 Private Service Connect とは Google Cloud APIs とは Private Service Connect のユースケース 必要性 機能のポイント Private Service Connect でマネージドサービスを公開する Private Service Connect vs 限定公開の Google アクセス 機能の違い どちらを使えばよいのか？ 設計のポイント エンドポイントの種類 エンドポイントの IP アドレス DNS 設定 設定手順 はじめに 設定手順の概要 DNS 設定の意味 オンプレミスから利用する 概要 Private Service Connect とは Private Service Connect とは、 External IP（Public IP）アドレスを持たない VM や、オンプレミスのクライアントから、プライベートネットワーク経由で Google Cloud の API 群や、ユーザーの独自サービスへアクセスできるようにするための仕組みです。 この機能では、VPC ネットワーク内に Internal IP（Private IP）アドレスを持つエンドポイントが作成され、このエンドポイント経由で Google Cloud APIs や独自サービスにアクセスできるようになります。 参考 : Private Service Connect 参考 : エンドポイントを介した Google API へのアクセスについて 当記事では、Private Service Connect で Google Cloud API にアクセスする方法について紹介します。 Google Cloud ドキュメント より引用 Google Cloud APIs とは 前提知識として、Google Cloud APIs とは何かについておさらいします。 ほとんどの Google Cloud リソースに対する閲覧、作成、更新、削除などは、すべて Web API によって操作され ます。これは、Amazon Web Services（AWS）などの他のパブリッククラウドでも同様です。 これについては、以下の記事で詳細に解説しています。 参考 : Google Cloudの根幹を成すGoogle Cloud APIsとは何か - G-gen Tech Blog 参考 : Cloud Audit Logsを解説。Google Cloud(GCP)の証跡管理 - G-gen Tech Blog - API リクエストとは Private Service Connect のユースケース セキュリティ上の理由から、Google Cloud APIs へのアクセスを、インターネット経由でなくプライベートネットワーク内で行いたいというケースがあります。 限定公開の Google アクセス 機能を使うことで、External IP アドレスを持たない VM やオンプレミスのノードから、Google Cloud APIs にアクセスできるようになります。 参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 しかし、限定公開の Google アクセスでは、 199.36.153.4/30 や 199.36.153.8/30 といった、RFC 1918 範囲（※）ではない IP アドレスを使う必要があるため、 Cloud Interconnect や Cloud VPN 経由でオンプレミス環境から利用する際などに、ルーティングが複雑化するなどの弊害が出る可能性があります。 ※ 10.0.0.0/8 、 172.16.0.0/12 、 192.168.0.0/16 一方で当記事で解説する Private Service Connect を利用すれば、 VPC ネットワーク内に Internal IP アドレスを持つエンドポイントを作成し、このエンドポイント経由で Google Cloud APIs にアクセスできます。 このエンドポイントには任意の IP アドレスを割り当てることができ、RFC 1918 で定義された IP アドレスでも、そうでなくても構いません。 必要性 Google Cloud APIs はインターネット経由でアクセスする必要があるため、これをセキュアでないと考える方もいるかもしれません。しかし、API リクエストは HTTPS（SSL/TLS）で暗号化 されます。そのため、鍵情報の漏洩がなければ、パケットが盗聴されても内容は解読されません。Google から SSL/TLS 証明書の鍵情報が漏洩し、さらにパケットが盗聴・復号されて情報が漏洩する可能性は、一般的には低いと考えられます。 そのため、Private Service Connect や限定公開の Google アクセスを用いる主たる理由は「インターネットへのルーティングができないクライアントを、Google Cloud APIs へアクセスできるようにするため」あるいは「会社（組織）のセキュリティポリシーに準拠するため」であるともいえます。 機能のポイント Private Service Connect 機能のポイントは以下の通りです。 Private Service Connect エンドポイント（Internal IP アドレスが割り当てられる）を作成し、オンプレミスのノードや VPC ネットワーク内の VM は、そのエンドポイント経由で Google Cloud APIs へアクセスできる エンドポイント作成時に、以下の種類のいずれかを選択 all-apis vpc-sc エンドポイントは時間ごとに料金が発生（$7.44/月程度） イメージ Private Service Connect エンドポイントの料金は、以下の公式の単価表を参照してください。 参考 : Virtual Private Cloud の料金 - Private Service Connect Private Service Connect でマネージドサービスを公開する 当記事では詳しく紹介しませんが、もう1つの Private Service Connect の機能として、自環境でホストするサービスを他の Google Cloud ユーザー向けに公開する機能があります。これは、 マネージドサービスの公開 と呼ばれます。なお、Amazon Web Services（AWS）の AWS PrivateLink でも類似のことが実現可能です。 以下の記事でご紹介していますので、ご参照ください。 blog.g-gen.co.jp Private Service Connect vs 限定公開の Google アクセス 機能の違い Private Service Connect に似た機能として、 限定公開の Google アクセス があります。 これら2つの機能は、以下のような違いがあります。 限定公開の Google アクセス機能では API エンドポイントとして利用する仮想 IP アドレスとして 199.36.153.4/30 や 199.36.153.8/30 といった RFC 1918 定義外の IP アドレスを使う必要がある 限定公開の Google アクセス機能では、デフォルトのドメイン名を使う場合に限り、DNS の追加設定が不要で手軽に利用できる しかしこのパターンでは 0.0.0.0/0 へのデフォルトルートと、ファイアウォール許可設定を追加する必要がある 限定公開の Google アクセス機能では料金が発生しない なお、Private Service Connect を設定する際には、限定公開の Google アクセスを有効化する必要がありますので、Private Service Connect 機能は限定公開の Google アクセスの拡張版と考えることもできます。 どちらを使えばよいのか？ Private Service Connect vs 限定公開の Google アクセス を考える時、どのように判断したらよいでしょうか。以下のような観点で検討します。 以下の全てに当てはまる場合は、 Private Service Connect を選択する オンプレミスからのプライベートネットワーク経由での Google Cloud APIs 利用がある 限定公開の Google アクセスで使われる 199.36.153.4/30 または 199.36.153.8/30 を使うにあたり、経路交換や経路制御で不都合がある 例: オンプレミス側のクライアントによって異なる通信先 VPC ネットワークや使用する回線を変えるため、複数のエンドポイントを使用したい 例: RFC 1918 以外の IP アドレスが広報されてくることが望ましくない それ以外の場合、無料で使える 限定公開の Google アクセス を選択する 利用する IP アドレスとして、 199.36.153.4/30 または 199.36.153.8/30 が許容できる場合は、無償で利用できる限定公開の Google アクセスを選択するのがよいでしょう。 限定公開の Google アクセス機能については、以下の解説記事で紹介していますので、ぜひご参照ください。 blog.g-gen.co.jp 設計のポイント エンドポイントの種類 エンドポイントの種類によって、アクセス可能な API が異なります。 all-apis の場合、 Google Cloud のほとんどのサービスや、Google Map、Google 広告など、多くのサービスへ接続することができます。 vpc-sc の場合、接続できるのは VPC Service Controls でサポートされているサービスだけです。 VPC Service Controls を使用しておらず、将来的に使用する予定も全く無い場合は前者を選択します。一方で VPC Service Controls を使用している、または使用する予定がある場合で、かつ VPC Service Controls がサポートしていないサービスへのアクセスが不要な場合は、後者を利用するとよいでしょう。 エンドポイントがサポートしている接続先の API については、以下の公式ドキュメントを参照してください。 参考 : エンドポイントを介した Google API へのアクセスについて - サポートされている API エンドポイントの IP アドレス Private Service Connect エンドポイント作成時には、1つの Internal IP アドレスを割り当てます。IP アドレスは、RFC 1918 アドレス（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）でもそうでなくても構いませんが、 IPv6 アドレスは使えません。 エンドポイントの IP アドレスは、 サブネットの IP アドレスとは重複できません 。また、VPC ネットワークと、ネットワークピアリングや Cloud Interconnect、Cloud VPN 等で接続されているネットワークと重複してもいけません。 将来的な VPC ネットワークやサブネットの拡張などを考慮して、 重複が起きない、かつ IP リソースの無駄使いにならない ような IP アドレスを指定しましょう。 また、もしオンプレミス環境から Cloud Interconnect や Cloud VPN 経由で Private Service Connect エンドポイントを利用したい場合、Google Cloud から広報するルートの集約性を考慮して、VPC サブネットの IP アドレス帯と隣り合った IP アドレスにするのが望ましいでしょう。 参考 : エンドポイントを介した Google API へのアクセスについて - IP アドレスの要件 DNS 設定 例として、Cloud Storage API のエンドポイントは https://storage.googleapis.com/ であり、BigQuery API のエンドポイントは https://bigquery.googleapis.com/ です。これらのドメイン名の IP アドレスを名前解決すると、パブリック IP が返ります。 storage.googleapis.comの名前解決の結果 Private Service Connect エンドポイントを作成しても、このままでは、gcloud コマンドなどのクライアントは、これらのパブリック IP アドレスを目指してパケットを発送してしまいます。 そこで、以下のいずれかの方法で、クライアントが Private Service Connect エンドポイントのプライベート IP アドレスを向くようにする必要があります。 クライアント（SDK）側の設定で、Private Service Connect エンドポイントを参照するよう明示的に設定する プライベートな DNS 名前解決により、クライアントが Private Service Connect エンドポイントを向くように設定する 1.は、クライアントへの明示的な設定により、向き先を変える方法です。Private Service Connect エンドポイントを作成すると、プロジェクトの Cloud DNS に <サービス名>.<エンドポイント名>.p.googleapis.com という DNS ゾーンが自動的に作成されます。gcloud や Python SDK など、クライアント側では、向き先の API エンドポイント URL を明示的に指定することができます。この方法では、DNS 設定を変更することなく Private Service Connect エンドポイントを使うことができます。 参考 : p.googleapis.com DNS 名を使用する 2.は、VM やオンプレミスのクライアント PC 等が参照する DNS サーバー、あるいは Cloud DNS のプライベートゾーンで、 *.googleapis.com に対する CNAME レコードを作成し、それを Private Service Connect エンドポイントの IP アドレスへ解決させる方法です。この方法では、クライアント側の設定やプログラムのソースコードを変更することなく、Private Service Connect エンドポイントを使うことができます。 参考 : デフォルトの DNS 名を使用して DNS レコードを作成する 当記事では続けて、2. の設定手順を紹介します。 設定手順 はじめに 当記事では、設定手順の概要のみを記載しています。より詳細な設定手順は、以下の公式ドキュメントをご参照ください。 参考 : エンドポイントから Google API にアクセスする 設定手順の概要 Private Service Connect の設定手順のおおまかな流れを以下に記載します。 必要な API を有効化 Compute Engine API Service Directory API Cloud DNS API Private Service Connect エンドポイントを作成 対象のサブネットで限定公開の Google アクセスを有効化 VPC ファイアウォールで、エンドポイント IP アドレスへの 443/TCP の 下り（Egress）通信が拒否されていないことを確認（デフォルトでは許可） Cloud DNS に googleapis.com という限定公開 DNS ゾーンを作成 同ゾーンに以下を追加 DNS名 : googleapis.com タイプ : A IPv4アドレス : (エンドポイントの IP アドレス) 同ゾーンに以下を追加 DNS名 : *.googleapis.com タイプ : CNAME 正規名 : googleapis.com DNS 設定の意味 上記のうち、5. 以降の DNS 設定について解説します。 例えば、VM の中で gcloud storage コマンドを実行して、Cloud Storage へのアクセスが発生したとします。gcloud コマンドは Cloud Storage API へリクエストをするために、 storage.googleapis.com へ HTTPS プロトコルでアクセスしようとします。VM はデフォルトでは Cloud DNS を参照するので、限定公開ゾーンを優先的に使って名前解決をします。 クライアントの動作の流れは、以下のとおりです。 VM が storage.googleapis.com を名前解決するため Cloud DNS へクエリする クエリは *.googleapis.com に一致しているので、CNAME で googleapis.com へ解決される googleapis.com は A レコードにより Private Service Connect エンドポイントの IP アドレスに解決される VM は 名前解決の結果を受け取る gcloud コマンドは Private Service Connect エンドポイントの IP アドレスへ API リクエストを実行する 参考として、Cloud DNS でのレコード追加済みの画面のスクリーンショットと、実際に VM の中から名前解決を試みた結果を以下に貼付します。 Cloud DNSでレコードが設定されている VMからCloud Storageを名前解決するとエンドポイントURLが返る オンプレミスから利用する ここまで、Compute Engine VM から Private Service Connect エンドポイントを利用するための設定手順を説明しました。 一方、Cloud Interconnect や Cloud DNS で接続されたオンプレミスネットワークから Private Service Connect エンドポイントを利用するには、以下の設定が追加で必要です。 Private Service Connect エンドポイントの IP アドレスを、Cloud Router からオンプレミス側に広報する オンプレミスノードが参照する DNS にフォワーダー設定を追加して、Google Cloud APIs の名前解決を Cloud DNS プライベートゾーンに転送する 1つ目は、Cloud Router の カスタムルート アドバタイズ で実現可能です。2つ目は、Cloud DNS の 受信サーバー ポリシー で実現可能です。 2つ目については、オンプレミスのクライアントが Private Service Connect エンドポイントに向けば良いので、オンプレミスノードが参照する DNS に直接 Cloud DNS と同じレコードを追加しても構いません。 詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : エンドポイントから Google API にアクセスする - オンプレミス ホストからエンドポイントにアクセスする 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）の 請求やの仕組み や 請求先アカウント について解説します。 基本的な概念 概念と用語 請求先アカウントとは お支払いプロファイル 複数のプロジェクトと請求 無料枠 プロジェクトとの紐づけ 紐づけの基本 必要な IAM 権限 Google Cloud パートナーによる請求代行（請求代行） 請求代行の仕組み Marketplace に関する注意点 課金レポート 課金レポートとは レポートのコツ Tips 管理機能 予算アラート 異常検知（Anomaly Detection） 課金データの BigQuery エクスポート プロジェクトと請求先アカウントのリンクを保護 AWS との違い 基本的な概念 概念と用語 当記事では Google Cloud（旧称 GCP）の 請求の仕組み 、また 請求先アカウント という言葉を、Amazon Web Services（以下、AWS）と比較しつつ解説します。 まずは請求先アカウントの仕組み、概念を図示します。 請求の概念 図の中にある、3つの用語を簡単に説明すると、以下のとおりです。 用語 説明 請求先アカウント 請求先情報を定義する設定オブジェクト。プロジェクトと紐づける お支払いプロファイル クレジットカード番号など、支払い情報を定義する設定オブジェクト。請求先アカウントと紐づける プロジェクト Google Cloud のリソースを収容する、いわゆる「テナント」 参考 : Cloud Billing について 請求先アカウントとは Google Cloud を利用するためには プロジェクト の作成が必要ですが、プロジェクトごとに請求先を設定する必要があります。その請求先を定義する設定オブジェクトが、 請求先アカウント です。請求先アカウントでは、以下のような情報を設定したり、情報を閲覧したりできます。 請求先（お支払いプロファイル） 請求書の表示、ダウンロード 課金の分析 予算アラート（利用料金が一定値を超えると警告メールを発信する） 一度、請求先アカウントを作ると、その請求先アカウントは再利用ができ、複数のプロジェクトと紐づけることができます。つまり、請求先アカウントとプロジェクトは 1:n の関係です。 お支払いプロファイル お支払いプロファイル には、クレジットカード情報や請求書送付先など、具体的な支払い情報が含まれています。 なお、お支払いプロファイルを表示したり編集したりする権限は、請求先アカウントの権限とは独立して設定可能です。お支払いプロファイルは一度設定すると、編集したり閲覧したりする頻度は低いはずですので、権限を持つべき人は請求先アカウントよりもごく少なくなるはずです。クレジットカード番号などの情報が入っていますので、より厳密に権限管理しましょう。 複数のプロジェクトと請求 以下のように、Google Cloud 組織の中には複数の請求先アカウントを作成することができます。 また、プロジェクトごとに違う請求先アカウントを設定できます。 請求の概念 (複数請求先アカウント) 請求先アカウントを複数作成すると、管理が煩雑になります。「利用内訳が分かるだけではダメで、請求書を完全に分割したい」「プロジェクトごとにクレジットカードを分けたい」など、特別な理由がなければ複数の請求先アカウントを作成する必要はありません。 1つの請求先アカウントに複数のプロジェクトが紐づいていても、コンソールの費用内訳画面で「プロジェクトごと」「サービスごと」「フォルダごと」など 詳細に課金の内訳を閲覧することが可能 です。 部署ごとやシステムごとの課金内訳を知りたいときは、まずはその方法を検討します。 無料枠 Google Cloud には、サービスごとに無料枠が存在しています。例えば BigQuery は、1ヶ月あたり「10 GiB のデータ保存」「1 TiB のスキャン」までが無料で利用できます。 ただし、これらの Google Cloud 無料枠は、特記がない場合は「請求先アカウント」の単位でカウントされます。Google Cloud プロジェクトが複数あっても、それらのプロジェクトが 同じ請求先アカウントに紐づいていれば、1つの無料枠を共有する ことになります。 参考 : 無料枠 プロジェクトとの紐づけ 紐づけの基本 Google Cloud プロジェクトを請求先アカウントと紐づけると、そのプロジェクトのクラウド利用料は、その請求先アカウントに対して課金されます。 後述する Google Cloud パートナーによる請求代行サービスを利用する等の理由で、すでに利用中の Google Cloud 環境において、ある請求先アカウントから別の請求先アカウントに紐づけを変更することも可能です。 その場合、紐づけ変更の 実施以降 に発生したクラウド利用料金だけが、新しく紐づけた請求先アカウントに課金されるようになります。つまり、紐づけを行った翌月の請求は、2つの請求先アカウントに分かれて発生することに留意してください。 必要な IAM 権限 Google Cloud プロジェクトと請求先アカウントとの紐づけ操作を行うには、操作者の Google アカウントに、以下の 両方の権限 が必要です。 プロジェクトに対する resourcemanager.projects.createBillingAssignment 権限 請求先アカウントに対する billing.resourceAssociations.create 権限 上記のうち 1. を満たすには、プロジェクトに対して以下のいずれかのロールが必要です（例示であり、他にも必要な権限を含んだロールは存在します）。 オーナー（ roles/owner ） プロジェクト請求管理者（ roles/billing.projectManager ） また、上記のうち2. を満たすには、請求先アカウントに対して以下のいずれかのロールが必要です（同様に、例示です）。｀ 請求先アカウント管理者 （ roles/billing.admin ） 請求先アカウント ユーザー （ roles/billing.user ） アクセス制御に関する詳細や請求先アカウントに対して IAM ロールを付与する方法については、以下の公式ドキュメントもご参照ください。｀ 参考 : Cloud Billing のアクセス制御と権限  |  Google Cloud 参考 : Cloud 請求先アカウントへのアクセスを管理する  |  Cloud Billing  |  Google Cloud Google Cloud パートナーによる請求代行（請求代行） 請求代行の仕組み Google Cloud パートナーによる請求代行サービス（課金代行サービス）を利用することで、 Google Cloud を割引料金で利用できるなどのメリットがあります。 パートナー経由で Google Cloud を利用する場合の請求の仕組みはパートナーごとに様々ですが、ここでは Google Cloud 専業パートナーである G-gen （ジージェン）社のケースをご紹介します。 参考 : 株式会社G-gen - Google Cloud 請求代行 G-gen 請求代行サービスの仕組み G-gen の請求代行サービスに申し込むと、 G-gen から利用者に対して 請求先アカウントが払い出され ます。利用者は、この請求先アカウントを自由にプロジェクトに紐づけて使用することができます。 この請求先アカウントをプロジェクトに紐づけた時点から、Google Cloud の利用料金は Google から G-gen に請求されます。G-gen は利用者の代わりに Google に料金を支払い、その後で、G-gen から利用者に対して割引料金で請求をします。 このような仕組みですから、すでに Google Cloud を自社のクレジットカード等で利用していても、プロジェクトの紐づけ先を G-gen の請求先アカウントに切り替えるだけで、請求代行サービスを利用することができます。このとき、原則的に システムの中断や利用可能な機能差などはなく 、G-gen 経由の支払いに切り替えて、 割引の恩恵を受ける ことができます。 また G-gen の請求代行サービスでは、当記事で紹介する課金レポートや予算アラートなど、請求先アカウントの管理機能も、制限なくご利用頂けます。 当記事では G-gen 社のケースを紹介しましたが、パートナーによって仕組みが異なりますので、詳細はパートナーの営業担当者にお問い合わせください。 G-gen 社の請求代行サービスの詳細は、以下をご参照ください。 g-gen.co.jp Marketplace に関する注意点 Google Cloud Marketplace 経由で購入するサードパーティ製品は、再販の規定の関係でパートナー経由での販売ができない場合があります。 また Google 製品の中でも Google Maps Platform や Firebase など再販規定が少し特殊なサービスもあります。これらのサービスを利用している場合は、パートナーの営業担当者にお問い合わせください。 一方で、株式会社 G-gen の場合は MCPO（Marketplace Channel Private Offer）という仕組みにより、サードパーティ製品を Google Cloud Marketplace 経由で購入する際に割引の恩恵を得られる場合もあります。以下の記事も参照してください。 blog.g-gen.co.jp 課金レポート 課金レポートとは Google Cloud の課金情報を閲覧できる 課金レポート 機能があります。Google Cloud コンソールで お支払い > レポート へ遷移することで、請求先アカウントごとに詳細に課金内容を可視化できます。なお、G-gen の請求代行サービスでは、お客様は自由に課金レポートを閲覧できます。 参考 : Cloud Billing レポート 課金レポート このレポート画面では、以下のような切り口で課金額をグラフィカルに表示できます。 プロジェクトごと サービスごと SKU（課金単位）ごと リソースに付与したラベルごと リージョンごと 上記の掛け合わせ レポートのコツ Google Cloud コンソール画面で お支払い > レポート に遷移して課金レポートを表示した際、初期状態では画面右部分の「グループ条件」フィルタで「サービス」が選択されている場合があります。 「サービス」でグルーピングした表示 この状態では、課金額がサービスごと（Vertex AI、BigQuery、Compute Engine など）に表示されます。この表示方法だと、それぞれのサービスで「なぜ」課金が発生しているのか、理解することができません。BigQuery の料金を節約したいと考えた時、スキャン量に対する課金が発生しているのか、ストレージ料金に対する課金が発生しているのかを確認しなければ、適切な対処を打つことができません。 「グループ条件」フィルタで「SKU」を選択することで、より細かい軸で課金額を表示できます。 SKU とは、Google Cloud の最小の課金単位です。例えば BigQuery であれば、 Analysis (asia-northeast1) という SKU は東京リージョンにおけるオンデマンド課金モードでのスキャン料金を示しており、一方で Active Logical Storage (asia-northeast1) は東京リージョンにおけるストレージ料金を示しています。 参考 : SKU Groups - BigQuery 参考 : SKU Groups 「SKU」でグルーピングした表示 レポートを SKU 単位で表示することで、コスト削減などにおける適切な打ち手を検討することができます。 また、グループ条件では他にも「プロジェクト」「プロジェクト階層（組織、フォルダ等）「ロケーション（リージョン）」の単位でのグルーピングを指定できるようになっています。また表示対象の SKU やプロジェクトを指定して表示対象を絞ることもできるなど、詳細に表示をコントロールできます。 課金レポートをうまく使うと、以下のような流れで、Google Cloud のコスト削減施策を検討することができます。 グループ条件を「SKU」にして課金レポートを表示 特に料金のかかっている SKU を特定 SKU フィルタで、特定した SKU だけに料金表示を絞る グループ条件を「プロジェクト」にして課金レポートを再表示 これにより、その SKU での課金が特に多く発生しているプロジェクトを特定 プロジェクトの担当者に対策を指示 Tips 課金レポートに関する Tips として、以下の記事も参考にしてください。 blog.g-gen.co.jp 管理機能 予算アラート 請求先アカウントに対して 予算 を設定し、その金額の n % に達したらメール通知する、などのアラート設定が可能です。 予算の粒度も、月ごと、四半期ごと、年間など任意の期間にできますし、予算の適用範囲プロジェクトやサービスも細かく選択できます。 例えば 「1ヶ月でXXXプロジェクトとYYYプロジェクトの合計予算を ￥2,000,000 とする。この予算に対し 50% に達したときと 75% に達したときにメールを発報する」 などの設定が可能です。 参考 : 予算と予算アラートを作成、編集、削除する 予算アラートの設定方法については、以下の記事もご参照ください。 blog.g-gen.co.jp 異常検知（Anomaly Detection） 請求先アカウントには、 異常検知 （Anomaly Detection）機能があります。 異常検知は、Google Cloud の突発課金を検知できる機能です。請求先アカウント単位で、過去の使用傾向が機械学習により学習され、通常パターンと異なる課金が発生すると異常（anomaly）として検知されます。 参考 : View and manage cost anomalies 当機能の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp 課金データの BigQuery エクスポート 請求先アカウントの課金履歴を、 BigQuery へ自動エクスポート することができます。BigQuery により課金データの詳細な分析を行いたいときに活用できます。 エクスポートする内容は以下の3つから選択でき、それぞれ出力されるデータの粒度が違います。 標準の使用料金（Standard usage cost data） 詳細な使用料金（Detailed usage cost data） 料金（Pricing data） 「標準の使用料金（Standard usage cost data）」には、請求月、サービス、 SKU 、プロジェクト、ラベル、リージョン、費用、使用量、クレジット（割引）などの情報が含まれます。 「詳細な使用料金（Detailed usage cost data）」には「標準の使用料金」に含まれる情報に加えて、その料金を発生させたリソース名など個別リソースの情報が含まれます。リソースレベルでの分析が必要な場合に利用できます。 「料金（Pricing data）」をエクスポートすると、Google Cloud の最新の料金単価がエクスポートされます。Google Cloud の利用料金単価は変更されることがあるので、ここから最新の料金単価を取得することで、分析に活用できます。 詳細な仕様については、以下のドキュメントをご参照ください。 参考 : Cloud Billing データを BigQuery にエクスポートする 参考 : BigQuery 内の Cloud Billing データテーブルについて なお、これらの機能によって生成されたテーブルは自動的に「取り込み日付によるパーティション」が設定されます。BigQuery ではテーブルあたりのパーティションの最大数は 10,000 であり、これは日単位でのパーティションでは およそ27年で枯渇 することを意味しています。これを超えた場合、エクスポートがエラーとなることが考えられますので、長期利用が想定される場合はパーティションに27年程度の期限を設定し、データが自動削除されるように設定することが望ましいでしょう。その場合は、データのバックアップなどは別途、検討する必要があります。 プロジェクトと請求先アカウントのリンクを保護 プロジェクトと請求先アカウント間のリンクが誤って解除されないよう、ロックすることができます。 プロジェクトと請求先アカウントの紐づけが解除され、プロジェクトに請求先アカウントが紐づけられていない状態になると、一部の Google Cloud リソースが削除され、復元不能になる可能性があります。これに伴い、プロジェクト内のデータが消失するおそれがあります。 参考 : プロジェクトの課金を無効にする 誤操作等で紐づけが解除されてしまったり、異なる請求先アカウントに紐づけが変わることを防ぐため、リンクをロックすることが可能です。ロックするには Google Cloud コンソールの「課金」画面で「マイプロジェクト」タブへ遷移し、対象プロジェクトの三点リーダーから「請求をロック」を選択します。 参考 : プロジェクトと請求先アカウント間のリンクを保護する 請求先アカウントのロック AWS との違い Google Cloud と Amazon Web Services（AWS）の請求の仕組みとの違いも、簡単にご紹介します。 AWS では、クレジットカード等の請求先情報は AWS アカウントごとに定義 します。「AWS アカウント」とはいわゆる「テナント」と言い換えることができ、 Google Cloud でこれに最も近い概念は「プロジェクト」です。 AWS では AWS アカウントごと に請求情報を設定するのが基本です。複数の AWS アカウントの請求をまとめるには Consolidated Billing という機能を利用します。ある AWS アカウントを 管理アカウント （旧称マスターアカウント）とすることで、管理アカウントに請求をまとめることができます。 AWSの請求の概念 一方で、Google Cloud は請求先情報の設定が 請求先アカウント として独立していて再利用可能です。 Google Cloudの請求の概念 まとめると、AWS では「請求先情報の設定は AWS アカウントの持つ属性」であり、Google Cloud では「請求先情報の設定はプロジェクトとは独立している」ということができます。これが、これら2つのクラウドの請求の仕組みにおける、大きな違いです。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 みなさまの会社や、コミュニティではタスク管理をどのように行っていますでしょうか？ 人によってはなにか独自のソフトウェア/クラウドサービスを導入して管理してる人もいるかと思います。 しかし！ Google Workspaceにはすでにその機能がある ので、今回はそちらを解説してゆきましょう。 この機能を利用することで、例えばお客様サポートであったり、社内のプロジェクトのタスク管理など、忘れやすいタスクを管理可能！ 共同タスクとは？ 共同タスクの利用方法 共同タスクの実際の利用 作業を割り当てる 作業をラベルで管理する 作業を完了させる 共同タスクとは？ まずはじめに、共同タスクに関して簡単に説明しますと、以下のようにメーリングリストで受信したメールを、メールとして処理するのではなく、 一つのタスクとして受信 する機能です。 受信したタスクは、メンバーによって各個人に割り当てることが可能で、そのタスクの進捗管理することでぬけもれを防止することができる機能です。 本機能はGoogle Groupの機能を応用したものになります。Google Groupというのは以下のように一言でいうと メーリングリストのようなもの です。 Google Groupとは 共同タスクの利用方法 実際に共同タスクを利用する場合、初期設定が必要になります。以下のグループ設定から「追加の Google グループの機能を有効にする」で 共同トレイを有効に しましょう。 ついでにそのすぐ下にある 共有ラベル も有効にしておくと便利ですので、このタイミングでONにしてしまいましょう。 共同タスクの設定方法(1) 共同タスクの設定方法(2) たったこれだけで共同タスクの設定方法は終わりです。 共同タスクの実際の利用 それでは早速利用していきましょう！ 大まかな作業としては以下になります。 ・作業を割り当てる ・作業をラベルで管理する ・作業を完了させる その前に、ではどうやったらこのグループに作業として追加できるのか？ それは簡単！この グループにメールを送信するだけ です。今回の場合はtask-mgmt@suzutatsu.onlineをメールアドレスに指定してますので、ここにメールを送信することで新しいタスクが追加されます。 これを応用することで例えばお客様からのご質問やサポートなど、きっちりとタスクとして管理可能なため、 ぬけもれ防止に繋がり、ひいてはお客様の信頼獲得へ！ 作業を割り当てる まずはじめに受信したタスクに関して担当を割り当ててみましょう。 以下のようにタスクをクリックし、右上のアイコンより担当者を指名することが可能です。 これでタスクが個人に割り当てられました。 タスクの割り当て 作業をラベルで管理する タスクが多くなってきたときに、 重要度で管理 したり、どの 部門で対応すべき事項 かなど、様々なラベルが必要になる場合があるかと思います。 その場合に役に立つのが最初に有効化しておいた共有ラベルになります。こちらを利用することで各タスクが一目瞭然！ 今回は緊急対応が必要という想定で設定してみましょう。 共有ラベルの設定(1) 共有ラベルの設定(2) 以下のように 緊急対応が必要 だということが一目瞭然ですね。 共有ラベルの設定(3) 作業を完了させる 受領したタスクの実施事項を完了したときにタスクの状態を完了にし、もう何もすることがないことを明らかにしましょう。 また、このときに共有ラベルを対応済み。などにしておくとよりわかりやすいですね。 タスクの完了(1) タスクの完了(2) これで共同タスクの一連の利用方法の解説は終わりになります。思ったよりも簡単だったのではないでしょうか？ Google Workspaceにはこのように実は簡単に使えるのだけども知られてない機能が沢山あります。 弊社ではGoogle Workspaceの使い方からサポートさせていただきますので、お気軽にお声がけください！ Google Cloud(旧GCP) / Google Workspace導入に関するお問い合わせ Google Workspace 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-genの杉村です。管理対象の Compute Engine インスタンス（VM）が多いと、課題になるのがログインユーザーの管理です。Google Cloud（旧称 GCP）のサービス Google Compute Engine（GCE）には OS Login 機能 があり、SSH ログインユーザーを効率的に管理できます。 OS Login について OS Login とは ポイント メリット 設定手順 Step 1. OS Login 有効化（メタデータ設定） Step 2. IAM ロールの付与 ログイン手順 OS Login について OS Login とは OS Login は Compute Engine の SSH ログイン時の認証を IAM で管理するための仕組みです。 OS Login 機能では、 VM へ SSH ログインするユーザを Google アカウントと連動して管理 できます。なお、当機能で管理できるのは SSH ログインであるため、対象は Linux VM のみであり、Windows Server は対象外です。 OS Login 機能をプロジェクトごとに、またはインスタンスごとに有効化すると、SSH ユーザーを Google アカウントやグループと紐づけて管理できます。Google アカウント（グループ）に付与する IAM ロールによって、 VM へのログイン可否 と、 sudo 可否 を指定できます。 なお OS Login は、無料で使用できます。 参考 : OS Login の概要 OS Login機能の概念 ポイント 有効化 / 無効化は Compute Engine のメタデータ（インスタンス単位 / プロジェクト単位）で指定する 公開鍵 / 秘密鍵は自動生成されインスタンスの中に連携される OS Login では OS ユーザーが <アカウント名>_<ドメイン名> という名称で自動作成される 例: john@g-gen.co.jp → john_g_gen_co_jp 2段階認証が設定可能 メリット VM にログインできる利用者を Google アカウント（グループ）で管理できるため、 OS ユーザー統制の改善 や 管理・運用の工数削減 が期待できます。 ログイン時の2段階認証も簡単に設定できるので、セキュリティレベルの向上も見込めます。 反対に OS Login 機能を利用しないで SSH ユーザーを管理する方法には、 メタデータマネージド SSH 接続 があります。こちらの場合、例えば gcloud compute ssh でログインが行われると、操作した PC 環境のローカルユーザーの名称で、OS ユーザーが VM 上に自動作成されます。この方法では、VM に OS ユーザーが乱立してしまうおそれがあります。 参考 : メタデータ マネージド SSH 接続 設定手順 参考 : OS Login を設定する Step 1. OS Login 有効化（メタデータ設定） まず、OS Login 機能を プロジェクト単位 で有効化するのか、あるいは インスタンス単位 で有効化するのかを決定します。 OS Login を有効化するには、指定のキー・バリューをメタデータに設定する必要があります。Compute Engine メタデータは、プロジェクト単位のメタデータとインスタンス単位のメタデータあります。 プロジェクト全体で有効化するには、プロジェクトの Compute Engine メタデータに enable-oslogin = TRUE を設定します。 プロジェクトレベルのメタデータ 一方でインスタンス単位で有効化するには、個々のインスタンスの 編集 画面から、メタデータに enable-oslogin = TRUE を設定します。 インスタンスレベルのメタデータ 2段階認証を有効化したい場合は、この時点でメタデータに enable-oslogin-2fa = TRUE も併せて設定してください。 OS Login 機能の2段階認証は、 Google アカウントに設定された二段階認証の要素を利用します。たとえば、Google Authenticator の OTP 入力を促されたり、スマホの Google アプリの承認ボタンを押すことを促されたりするなどです。 Step 2. IAM ロールの付与 OS にログインさせたい Google アカウントまたは Google グループに、IAM ロールを付与します。 なお IAM のベストプラクティスとして、IAM ロールはアカウントに直接付与するのではなく、グループに付与することが推奨されています。 OS Login を使うには、以下の いずれか の IAM ロールを付与します。 sudo 権限なしの場合 roles/compute.osLogin （日本語名: Compute OS ログイン ） sudo 権限ありの場合 roles/compute.osAdminLogin （日本語名: Compute OS 管理者ログイン ） IAM ロールは 組織レベル プロジェクトレベル 個別インスタンスレベル のいずれかで付与することで、その Google アカウント（グループ）がどのインスタンスにログインできるか、が決まります。 組織レベルで付与すれば組織配下の全てのインスタンスに、プロジェクトレベルで付与すればプロジェクト内の全てのインスタンスに、インスタンスレベルで付与すればそのインスタンスだけに、SSH ログインできるようになります。 IAM の基本的な仕組みについては、以下の記事も参照してください。 blog.g-gen.co.jp ログイン手順 OS Login を有効化すると、コンソールから SSH ボタンを押下したり、gcloud コマンドを使って VM にログインする際に、自動的に OS Login による認証が行われ、ログインできるようになります。 コンソールからのSSHログイン gcloud コマンドであれば、通常の SSH ログイン時と同じように、以下のように実行するだけです。 gcloud compute ssh --project=${PROJECT_ID} --zone=${ZONE} ${VM_NAME} もしメタデータに enable-oslogin-2fa = TRUE が設定されていれば、このタイミングで2段階認証が求められます。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは！G-genの小林です。みなさんGoogle Cloudはご利用されてますでしょうか？お客様とお話ししている中でGoogle Cloudを使ってみているけど、最初に何を設定しておくべきなのか分からなくて困っている、という声をよく伺います。当記事では、Google Cloudをセキュアに使うためにはどうするべきなのかについて説明します。 はじめに 最初に対応すべきチェックリストの確認方法 組織と ID ユーザーとグループ 管理者アクセス お支払い リソース階層 リソースのアクセス ネットワーキング モニタリングとロギング セキュリティ サポート（カスタマーケア） はじめに 当記事では、Google Cloudを利用開始したばかりの方が、セキュアに利用するために必要なことを説明します。 「Google Cloudを社内で使ってみようとしているけど、必要最低限の設定をした状態でユーザーに使わせたい」「本番利用する場合のこれだけは設定しておくべき項目を把握しておきたい」と考えているクラウド管理者の方向けの内容です。 なお、当記事で紹介する Google Cloud コンソール画面は2021年10月現在のものです。最新の状態とは異なる場合がある点にご留意ください。 最初に対応すべきチェックリストの確認方法 Web ブラウザで Google Cloud にログインし、[IAMと管理] -> [IDと組織] にアクセスします。画面上部のプロジェクトセレクタで組織を選択すると、以下の表示になります。 この画面では、Google Cloudを利用する際の推奨設定が案内されます。[チェックリストに移動] をクリックすると、以下の画面になります。 ここに記載されている項目を1つずつ対応することで、Google が推奨する本番ワークロードに適した環境設定を行うことができます。 なお、見ていただくと分かる通り非常に多くの対応項目があります。Google Cloudを初めて利用する人にとっては分からない用語や理解に時間がかかる項目がちらほら...。 そのため、以降の本投稿では具体的にどのような設定が必要か簡単かつわかりやすく解説したいと思います。 組織と ID Google Cloud を管理したり、Google Cloud 上で開発したりする人のアカウントは、Cloud Identity もしくは Google Workspace で管理されます。 Google Workspace をすでに利用している組織の方は、そのアカウントを使って Google Cloud を利用することが可能です。Google Workspace を利用していない組織の方は、Cloud Identity の新しい組織（テナント）を開設する必要があります。Cloud Identity Free edition は、50アカウントまで無料で利用することができます。 実施内容 Cloud Identity もしくは Google Workspace を利用している場合 ドメインの所有権の証明が完了しているかチェック Cloud Identity もしくは Google Workspace をまだ利用していない場合 Cloud Identity の新規登録 ドメインの所有権の証明が完了しているかチェック 組織についての詳細は、以下の記事を参照してください。 blog.g-gen.co.jp ユーザーとグループ ユーザーやグループを作成します。 Google Cloud で使用するユーザーアカウントやグループは、Google Cloud コンソールで作成するのではありません。前述のとおり、Cloud Identity もしくは Google Workspace の管理コンソールで作成します。Google Workspace で作成したユーザーアカウントやグループを、そのままGoogle Cloud でも使用するイメージです。 実施内容 ユーザーの追加 グループの作成 ユーザーをグループに追加 このとき、Google Cloud の組織管理者、請求管理者、プロジェクトごとの管理者など、役割ごとにグループを作ることが推奨されます。 管理者アクセス この項目では、1つ前の項目で作成したグループに対して IAM ロールを割り当てます。 なお、この作業は Cloud Identity または Google Workspace の特権管理者が行う必要があります。Cloud Identity または Google Workspace アカウントの特権管理者は、最初から Google Cloud の「組織の管理者」ロールの権限を持っています。 実施内容 グループへの IAM ロールの割り当て IAM の仕組みについては、以下の記事も参照してください。特に、クラウドを管理する役割の方は IAM の仕組みを正確に理解することが強く推奨されます。 blog.g-gen.co.jp お支払い この項目では Google Cloud の支払いを行う請求先アカウントの作成をします。Google Cloud は支払いの設定がなくても一部の機能を利用できますが、すべての機能を利用するには Google Cloud プロジェクトに対して 請求先アカウント の紐付けが必須になります。 実施内容 請求先アカウントの作成 請求先アカウントをユーザーが自ら作成すると、Google と直接契約することになります。G-gen のようなリセラー（代理店）と契約し、請求先アカウントを発行してもらうことも可能です。リセラー経由で請求先アカウントを発行してもらうと、 割引 や 無料の技術サポート窓口 、日本円・請求書払いができるなど、リセラー独自のサービスを受けることができます。 請求先アカウントについては、以下の記事も参照してください。 blog.g-gen.co.jp リソース階層 Google Cloudは以下のようなリソース階層で成り立っています。 この項目では、フォルダとプロジェクトを作成します。 Google Cloud プロジェクト は最下層の管理単位であり、Compute Engine VM や BigQuery テーブルなど個々のリソースを配置する管理オブジェクトです。Amazon Web Services（AWS）でいうところの「AWS アカウント」といえます。 フォルダ は、プロジェクトをグループピングするための管理オブジェクトです。 Google Cloud のフォルダやプロジェクトの詳細は、以下の記事を参照してください。 blog.g-gen.co.jp 実施内容 リソース階層の計画 フォルダの作成 プロジェクトの作成 プロジェクト作成時に、紐づける請求先アカウントを選択します。そのプロジェクトで発生した課金は、紐づけた請求先アカウントに対して発生します。1つの請求先アカウントには複数のプロジェクトを紐づけることができます。どのプロジェクトでどのような課金が発生したかは、請求先アカウントの課金レポートで詳細に確認できます。 リソースのアクセス Google Cloud では、個々のリソースが持つ IAM 設定値（このリソースに対して、誰がどのような権限を持っているか）のことを IAM ポリシー と呼びます。例えば、ある Compute Engine VM の IAM ポリシーには「 user01@example.com が管理者権限を持つ」のように定義できます。 この項目では上記のような IAM ポリシーの設定を実施します。IAM ポリシーなどの概念については、以下の記事をご参照ください。 blog.g-gen.co.jp 実施内容 組織レベルの IAM ポリシー設定 フォルダレベルの IAM ポリシー設定 プロジェクトレベルの IAM ポリシー設定 ネットワーキング VPC ネットワーク、Cloud VPN、Cloud NAT、VPC ファイアウォール等、主にネットワークに関連する初期設定を行う項目です。 すぐには設定が不要な項目もあるはずですので、必要に応じて作業を行ってください。 実施内容 VPC 設定 共有 VPC 設定 IPSec VPN 設定 Cloud NAT 設定 ファイアウォール設定 Cloud Load Balancing 設定 Google Cloud のネットワークの基本的な知識については、以下の記事も参照してください。 blog.g-gen.co.jp モニタリングとロギング この項目ではモニタリングとロギングの設定を行います。モニタリングは Cloud Monitoring、ロギングには Cloud Logging を利用します。 Cloud Monitoring は Google Cloud サービスからパフォーマンス指標を取得、保管、閲覧するサービスです。この項目では、モニタリング用のプロジェクトを作成し、そのプロジェクトでパフォーマンス指標を一括管理するために、他のプロジェクトを登録するための設定を行います。 Cloud Logging は Google Cloud サービスからログを収集、保管、閲覧するサービスです。この項目では、ログ集約用のプロジェクトを作成し、複数のプロジェクトから取得されたログをロギング用プロジェクトの BigQuery に一括収集する設定を行います。 実施内容 モニタリングの設定 ロギングの設定 Cloud Monitoring や Cloud Logging については、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp セキュリティ プロジェクトの保護に役立つセキュリティ設定を行います。 Security Command Center とは、Google Cloud サービスの構成ミスや脆弱な設定がないかチェックする脅威検出サービスです。スタンダードティアは無料で利用できます。 組織ポリシー は、組織内で利用可能なサービスや実施可能な操作、適用可能な設定などを制限する強制的なルールを定義できる仕組みです。例えば、特定のリージョン以外の使用を制限することや、利用可能な Google Cloud APIs を制限することが可能です。 実施内容 Security Command Center の設定 組織ポリシーの設定 Security Command Center や組織ポリシーについての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp サポート（カスタマーケア） 障害時等に備えて、公式の技術サポートを利用したいと思うことがあるはずです。Google Cloud には カスタマーケア と呼ばれるサポートサービスがあり、無償のプランと有償のプランがあります。 無償プラン（ベーシック）の場合、課金に関する質問のみを問い合わせることができます。技術的な質問が可能な有償プランには複数あり、プランによって日本語対応の有無や、回答時間の差異があります。 実施内容 カスタマーケアの申し込み このときカスタマーケアを申し込む操作者は、組織レベルで「組織の管理者（ roles/resourcemanager.organizationAdmin ）ロール」と「サポート アカウント管理者（ roles/cloudsupport.admin ）ロール」が必要です。さらに、請求先アカウントに対する「請求先アカウント管理者（ roles/billing.admin ）ロール」などが必要です。 カスタマーケアのプランについては、以下の公式ページを参照してください。 参考 : Google Cloud カスタマーケア 小林 あゆみ (記事一覧) クラウドソリューション部 営業チーム AWSエンジニアからGoogle Cloud営業に転向 福井からリモートワーク中 趣味はMonkey125でツーリング、Netflix鑑賞、旅行

G-gen の杉村です。 Google Cloud Next '21 の What's new with BigQuery セッションで発表された新機能を、速報としてご紹介します。 BigQuery はじめに BigQuery Omni (GA) BigQuery Security & Governance for Data Lakes (Coming soon) BigQuery External Functions Analytics Hub (Preview) BigQuery Migration Service (Preview) BigQuery 管理系機能 Admin hub & Resource charts (GA) Slot estimator (Preview) BigQuery Slots Autoscaling (Coming soon) Table Snaphosts and Clones BigQuery Storage Write API (GA) Search Indexes with BigQuery (Preview) BigQuery ML 関連 Explainable AI Integration with Vertex (Coming soon) Advanced Models & Techniques BigQuery BI Engine (GA) はじめに 2021年10月12日〜から14日の日程で Google Cloud Next '21 が開催されています。 What's new with BigQuery というセッションの中で、 Google Cloud のデータウェアハウスサービスである BigQuery の新機能の数々が発表されました。 特に BigQuery Migration Service という移行に活用できる機能や、 Table Snaphosts and Clones , Search Indexes with BigQuery といった BigQuery のユースケースを変えてしまう可能性すらある機能は注目です。 本投稿では、当該セッションで発表された新機能をご紹介します。なお記載の内容は セッションの発表があった 2021年10月13日現在の内容となっております 。 リリース状態や機能の内容は常に変化しておりますので、本投稿はあくまで速報記事であることをご理解ください。 BigQuery Omni (GA) AWS, Azure, Google に分散されているデータをSQLで横断クエリできる機能。 Google Cloud (GCP) 上のこれまでと同じ BigQuery のインターフェースで、Google Cloud や AWS、Azure に保存したデータを、クラウド間を移動したりコピーしたりすることなくクエリが可能となる。 Anthos の技術をバックエンドとして使い、例えば AWS 上で BigQuery のクエリエンジンが稼働し、 Amazon S3 等に保存されているデータにクエリを実行する。 参考: BigQuery Omni - マルチクラウド の分析でデータを活用 BigQuery Security & Governance for Data Lakes (Coming soon) BigQuery では Cloud Storage や Spanner など BigQuery の外部に存在するデータを外部テーブルとして定義することができるが、この外部テーブルに対する権限設定をきめ細かくできるようになる模様。 データレイクのセキュリティ向上が見込めるはずだ。 ※同機能は BigLake として 2022/01/25 に GA となりました。 BigQuery External Functions UDF (ユーザ定義の関数) を BigQuery の外部で定義できるようになった。 これまでも BigQuery では UDF を定義することはできたが、標準 SQL か Javascript で記述する必要があり、関数は BigQuery の内部に定義された。 今回のアップデートでは UDF が BigQuery の外部に定義できるようになり、そのランタイムにはご存知 Cloud Functions を利用しているので node.js / Python / Go / Java / .net / PHP などで記述できる。 参考 : リモート関数の操作 Analytics Hub (Preview) 組織 (Organization) をまたいでデータをやりとりできる仕組み。 Publisher (データ公開側) は Analytics Hub を通じてデータセットを公開でき、 Subscriber (データ利用者側) がこれを利用できる。 公開データをキュレーションしたり検索する仕組みが提供される模様。 Publisher がデータの利用状況を分析できるような仕組みも存在しているようだ。 参考 : Analytics Hub のご紹介 -- 簡単、安全、スケーラブルにデータ分析を共有 ※ Analytics Hub は 2022/10/11 にGA となりました。 BigQuery Migration Service (Preview) 他のデータウェアハウス製品から BigQuery への移行を支援するツールであるの Preview が発表された。 ソース DB へのアセスメント、 SQL (DDL, DML, BTEQ で書かれた PL) の変換、 移行先 BigQuery へのバリデーションを行う。 Walmart や Mercado Libre などで既に SQL 変換にこれを利用した実績があるという。 現在のところ、 Teradata がサポート対象となることが判明しているが、他の移行元も Coming soon としている。 参考 : BigQuery Migration Service の概要 BigQuery 管理系機能 Admin hub & Resource charts (GA) BigQuery 環境の詳細なモニタリング、管理、トラブルシュート、ボトルネック特定などに活用できる新しい管理コンソールが使えるようになった。 Slot Reservation (コンピューティング容量の事前購入。定額・大容量で BigQuery を利用できるようになる) を使用してワークロード管理を行っているユーザーにとって、強力な機能となるだろう。 Slot estimator (Preview) こちらも Slot Reservation を使っているユーザー向けの機能だ。 組織内でプロジェクトを横断してスロットの利用状況を確認できる他、スロットを追加購入すべきかどうかの判断の助けになる情報を提供する。 ※ Slot estimator は 2022/11/14 にGA となりました。 BigQuery Slots Autoscaling (Coming soon) 事前に定義した予算に基づいてスロットを自動でスケーリングする機能だ。 従来のオンデマンドモードだと、基本的にスロットは 2,000 が上限であり、ベストエフォートでのバーストを期待することができた。 当該機能がリリースされれば、ある程度の予測が難しいワークロードでもコストの無駄ナシで高いパフォーマンスを維持できるだろう。 ※当機能は BigQuery Editions の一機能として 2023/03/29 にGA となりました。 Table Snaphosts and Clones BigQuery でのデータの持ち方が大きく変わるかもしれない機能も発表された。 Snapshots (スナップショット) は読み取り専用のデータコピーであり、論理バックアップ目的やタイムトラベル機能 (7日間しか保持されない) 以上の保持期間で特定時刻のテーブル状態を保持したい場合に利用できる。しかもデータは、オリジナルテーブルから即座にコピーするのではなく、基本的にはオリジナルテーブルを参照したまま、変更や削除された場合のみデータが複製される (いわゆるコピー・オン・ライト) のためコストを抑えることが可能だ。 ※ Snapshot 機能は 2021/10/28 に GA となりました。 Clone (クローン) は Snapshots のデータ変更が可能なバージョンと考えればいいだろう。同じくコピー・オン・ライトでテーブルのクローンを作成する。発表ではアプリケーションに対する変更をテストする環境として利用するユースケースが挙げられた。 ※ Clone 機能は 2022/02/15 に Preview 公開 され、その後 2023/05/03 に GA となりました。 BigQuery Storage Write API (GA) BigQuery のストレージに直接 API を発行し、高スループットでのデータの書き込み等が可能になる。 費用も通常の INSERT より低く押さえられるため、大量データの投入では検討すべき選択肢だ。 参考 : BigQuery Storage Write API の使用 Search Indexes with BigQuery (Preview) なんと、 BigQuery でインデックスが使えるようになった ( Preview 公開の予定の発表であり 2022 年 1 月現在でまだ利用可能になっていない → 2022/04/07 に Preview 公開され 2022/10/27 に GA となった) 。 2022/04/11 更新 : 以下の当ブログ記事にて詳細を解説している。 blog.g-gen.co.jp 従来では BigQuery においてはインデックスは使えなかった。これが BigQuery のメンテナンス工数を減らす利点でもあった。 とはいえこれは BigQuery がテーブル単位・パーティション単位でのフルスキャンを行うことを意味しており、数ペタバイトにおよぶデータの中から特定のキーでデータを抜き出すようなワークロードに対して大量のスキャンが発生してしまうため、金銭的・時間的コストがかかってしまうことも意味していた。 本機能ではテーブルにテキストインデックスを作成し、特定の文字列を検索する性能を向上させることができる。 インデックスは自動的に更新されるため、いわゆる VACUUM のようなメンテナンスは依然として不要だ。 同じくプレビュー発表されたネイティブJSONタイプにも使用できる。 以下のようなユースケースが挙げられた。 選択範囲が非常に狭いフィルタを使ったダッシュボード (スライシング/ダイシングが必要) 目的となるデータのサブセットを大きなデータセットから見つけ出す (特定の情報を持った患者群を抜き出す) GDPR準拠のため特定ユーザのデータだけを抜き出して削除する ログから特定 IP アドレスを抜き出す BigQuery ML 関連 Explainable AI AI/ML 関連でよく話題になる「説明可能なAI」を実現するための機能だ。 学習データのうちどのような要素が結果に影響したのかを理解することを助ける。 Integration with Vertex (Coming soon) BigQuery ML が Vertex AI と連携する。 Vertex AI のパイプラインと連携することで BigQuery ML のモデルの学習やデプロイが強化される模様だ。 Advanced Models & Techniques XGBoost, Wide & Deep DNN (ディープニューラルネットワーク), AutoML Tables などがサポートされ、強化される。 BigQuery BI Engine (GA) プレビュー版で用意されていた機能が GA となった。 データポータル等の BI ツールから利用可能なキャッシュ機構で、利用には追加料金が発生する。 インメモリキャッシュ機構であり、有効化するだけで効果を発揮する。 参考 : BI Engine とは 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。本投稿では、 Google Cloud（旧称 GCP）のセキュリティ系サービスの中でも特に重要な VPC Service Controls について解説します。 概要 VPC Service Controls とは できること できないこと API リクエストとは 仕様 想定構成図 サービス境界 内向きルール 外向きルール 内向きルールと外向きルールの詳細 境界ブリッジ VPC 内のクライアントからの API リクエスト オンプレミスからの API リクエスト 実践 ユースケースと設定例 対応している Google Cloud サービス ドライラン構成 アクセスポリシー アクセスポリシーとは アクセスポリシーの使い方 トラブルシューティング 違反アナライザー 違反ダッシュボード 概要 VPC Service Controls とは VPC Service Controls は Google Cloud（旧称 GCP）のアクセス制御機能です。 サービス境界 （service perimeters、または単に perimeter）と呼ばれる論理的な囲いを作り、その囲いの外から中へのアクセスを防いだり、逆に囲いの中から外へのデータ流出等を防ぐことができます。 VPC Service Controls には「できること」と「そうでないこと」があり、当機能だけを使えば Google Cloud のセキュリティが万全になるという訳ではありません。 当記事ではこの「境界（囲い）」とは何を示しているのか、どのような仕組みでデータの流出等を防いでいるのかについて開設します。 参考 : VPC Service Controls の概要 できること VPC Service Controls では、 Google Cloud サービスに対する API リクエストの接続元を制限する ことができます。 そもそも API リクエストが何なのかについては、後述します。 できることの例 BigQuery に対するクエリの発行元を制限 Cloud Storage からのオブジェクト読み取りのアクセス元を制限 Google Kubernetes Engine（GKE）クラスターの設定変更のアクセス元を制限 できないこと VPC Service Controls では、例として VPC へのネットワーク的なアクセスを制限する ことはできません。VPC における TCP/IP 的なアクセス制御や、Web アプリケーションレベルのセキュリティは、VPC ファイアウォールや WAF（Cloud Armor）といった仕組みが担います。 できないことの例 VM への SSH ログインの接続元 IP アドレスを制限 Webサイトの管理画面へのアクセスの接続元 IP アドレスを制限 Web アプリへの攻撃を防御 API リクエストとは Google Cloud における API リクエストについては、以下の記事で図を使って解説しています。「API リクエストとは」の欄をご参照ください。 参考 : Cloud Audit Logsを解説。Google Cloudの証跡管理 - API リクエストとは 当記事では、簡略化した図を再掲します。 Google Cloud の API 例えば Google Cloud を Web コンソール画面から操作したとき、バックエンドでは Web API へのリクエストが発生 しています。Google Cloud の Web API はインターネットに公開されていますが、誰でも API へリクエストできるわけではなく、Google アカウントと IAM により認証・認可が行われます。 一方で、以下のようなアクセスは Web API とは関係ありません。 VM への SSH ログイン VM でホストされた Web サイトへの HTTP(S) アクセス 上記の2つの例では、接続元ネットワークから VPC 内のリソースに TCP/IP 的にリーチしています。この違いが、前述の「VPC Service Controls でできること、できないこと」の差に関係しています。 VPC 内のリソースに TCP/IP 的に通信するようなアクセス制御は、VPC ファイアウォールや Cloud Armor が行います。一方で、 Google Cloud API へのアクセスの制御 を行うのが、当記事で紹介する VPC Service Controls です。VPC Service Controls は Google Cloud API へのアクセスを制御しますので、Google Cloud コンソールでの操作や gcloud コマンド、また各プログラミング言語用のクライアントライブラリによる Google Cloud の操作を制御することができます。 仕様 想定構成図 以下の構成を例にとって、 VPC Service Controls でできることを説明してます。 VPC Service Controlsの構成例 サービス境界 VPC Service Controls では サービス境界 （service perimeters）を定義することで、境界外からの API リクエストを制御します。境界には、 任意の Google Cloud プロジェクト の 任意の Google サービス を入れることができます。 参考 : サービス境界の詳細と構成 参考 : サポートされているプロダクトと制限事項 サービス境界は、組織レベルのリソースとして作成します。作成の際、どのプロジェクトのどの Google サービスを境界に入れるかを選択します。例えば「対象プロジェクトは XXX 」「対象サービスは BigQuery と Cloud Storage 」のように設定できます。 このように設定したとき、 XXX プロジェクト内部の BigQuery と Cloud Storage は同じ境界の中に含まれているので、 お互いにデータのやりとりをすることができます 。例として、Cloud Storage 上の CSV ファイルを、BigQuery テーブルへロードすることができます。 サービス間のAPIコール 一方でこの設定では、 別のプロジェクトにある BigQuery から 境界内の BigQuery や Cloud Storage へのアクセスは拒否されます。 別の Google Cloud プロジェクトである YYY の BigQuery からは、 XXX プロジェクトの Cloud Storage の CSV ファイルをロードできません。 内向きルール 前述の設定では、例えば開発者が自分のオフィスや自宅から BigQuery にアクセスしようとしても、アクセスは拒否されることになります。 ここで使用するのが 内向きルール （Ingress rules や上りルールとも呼称）です。アクセスが内向きルールで定義した条件に合致した場合、境界外からの API リクエストは許可されます。 参考 : 上り（内向き）と下り（外向き）のルール 境界外からのアクセス このときの許可条件を定義するオブジェクトを アクセスレベル といいます。アクセスレベルに定義できるのは、IP アドレス、接続元の地域などです。例として「特定の IP アドレスからのアクセスだけを許可」などと設定することができます。このアクセスレベルを作成し、サービス境界内の内向きルールと紐づけることで、アクセス許可します。 有償の Chrome Enterprise Premium（旧称 BeyondCorp Enterprise）ライセンスを購入すれば、PC や iOS、Android デバイスにインストールされた Chrome 拡張機能等から収集される情報をもとにして、デバイスの設定情報などに基づいた条件をアクセスレベルに設定することもできます。 参考 : アクセスレベル 参考 : アクセスレベルを設計する 内向きルールの設定画面 また内向きルールには、特定の Google アカウント（グループ）であればアクセスを許可するなど、ID ベースでの許可設定を定義することもできます。ただし、内向きルールで許可されていても、Google Cloud API へリクエストを行うには IAM 権限が引き続き必要です。 外向きルール 逆に、境界内のサービスから外のサービスへの API リクエストをする必要がある場合は 外向きルール （Egress rules や下りルールとも呼称）を作成します。 例えば、サービス境界内にある Cloud Run Functions 上で動作するスクリプトが、境界外のプロジェクトの Compute Engine API をコールするときには、外向きルールの定義が必要です。 参考 : 上り（内向き）と下り（外向き）の定義 内向きルールと外向きルールの詳細 以下の記事では、内向きルールと外向きルールの詳細について解説しています。どういったときにどちらのルールを使うのか、またそれぞれのルールの詳細な仕様を解説していますので、ご参照ください。 blog.g-gen.co.jp 境界ブリッジ 境界ブリッジ （perimeter bridges）は、複数の Google Cloud プロジェクト同士を橋渡しするサービス境界です。 1つの Google Cloud プロジェクトに設定できる通常のサービス境界は1つだけです。そのためプロジェクト XXX と YYY にそれぞれ別の境界を定義しているとき、この2つのプロジェクト間での通信は拒否されます。 このようなとき、境界ブリッジを作成することで、2プロジェクト間の通信を許可できます。 境界ブリッジの設定はシンプルで、所属させる複数のプロジェクトを選択するだけです。同じ境界ブリッジに所属するプロジェクト同士は、通信することができるようになります。 参考 : ブリッジを使用して境界を越えて共有する VPC 内のクライアントからの API リクエスト VPC の VM 等から境界内サービスへの API リクエストも必要になる場合があります。 例えば、 VM インスタンス上のアプリから Cloud Storage へデータをアップロードするというケースを考えます。 VMからGoogle CloudサービスへのAPIコール このような API リクエストは、以下の両方が満たされた場合に可能です。 境界内の Google Cloud プロジェクト に所属する VPC 内部からリクエストすること VPC のアクセス可能なサービス（VPC accessible services） でサービスが許可設定されていること VPC のアクセス可能なサービス は、サービス境界に設定する設定値の1つです。設定値は、以下のいずれかから選択することができます。 No 名称 意味 1 すべてのサービス 全サービスにアクセス可能 2 サービスなし どの Google サービスにもアクセスできない 3 すべての制限付きサービス 境界内のサービスにだけアクセスできる 4 選択したサービス アクセス可能な境界内サービスを明示的に選択する VPCのアクセス可能なサービスの設定画面 例えば、サービス境界の保護対象サービスとして XXX プロジェクトの Cloud Storage だけが選択されているとします。このとき、 XXX プロジェクトの VPC 内の VM から、Google サービスへの API リクエストの成否は以下のようになります。 VPC のアクセス可能なサービスの設定値が すべてのサービス の場合 VM からは、サービス境界の保護対象サービスとして選択されているか否かに関わらず、すべてのサービスにアクセスできます。 No 接続先サービス APIコール成否 1 Cloud Storage OK 2 BigQuery OK VPC のアクセス可能なサービスの設定値が サービスなし の場合 VM からは、境界に関係なくどの Google サービスにもアクセスできません。 No 接続先サービス APIコール成否 1 Cloud Storage NG 2 BigQuery NG VPC のアクセス可能なサービスの設定値が すべての制限付きサービス の場合 VM からは、境界の保護対象サービスとして指定したサービスにだけアクセスできます。 No 接続先サービス APIコール成否 1 Cloud Storage OK 2 BigQuery NG VPC のアクセス可能なサービスの設定値が 選択したサービス の場合 明示的に選択したサービスへの API リクエストだけが成功します。 オンプレミスからの API リクエスト 内向きルールで定義することにより、オンプレミスサイトから接続元 IP を固定したうえで、インターネット経由でサービス境界内のサービスへアクセスすることができます。 しかし VPC と オンプレミスサイトが VPN や Cloud Interconnect で接続している場合に、 プライベートネットワーク経由でアクセスしたい ときはどうすればいいでしょうか。 VPN や Cloud Interconnect 経由で、VPC の 限定公開の Google アクセス や Private Service Connect の仮想 IP アドレス経由でアクセスすることで、オンプレミスから境界内のサービスへプライベートアクセスすることができます。同時に、前述の VPC 内からのアクセスの条件も満たしている必要があります。 オンプレミスからGoogle CloudへのAPIコール 限定公開の Google アクセス や Private Service Connect とは、 VPC 内から Google の内部ネットワーク経由でかつ プライベート IP による接続で Google サービスの API へアクセスできる仕組みです。以下の記事で紹介していますので、ご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp このようなケースでは、オンプレミスからは「サービス境界内の VPC を経由して Google Cloud API へアクセスさせる」ことになります。 なおオンプレミスから限定公開の Google アクセス経由で API リクエストをする際に、クライアント側から利用する API エンドポイントとして restricted.googleapis.com を使うことで、VPC Service Controls の サポート対象外のサービスに対するアクセスを拒否する ことができます。 逆にこのドメイン名を使わないと、VPC Service Controls サポート対象外のサービスへのアクセスが可能になってしまい、統制に抜け・漏れが出るおそれがあります。この仕様は、認定試験である Professional Cloud Network Engineer などでも頻出です。 実践 ユースケースと設定例 VPC Service Controls のユースケースと具体的な設定例をいくつか列挙します。 Cloud Storage に工場の計測データを保存している。プロジェクトにサービス境界を設定し、 社内拠点の固定 IP アドレスからのみアクセスできるように、内向きルールを設定 する BigQuery に個人情報を含む顧客データを保存している。この BigQuery には VPC 内の VM にホストした BI ツール以外からアクセスされることはない。 プロジェクトに境界を設定し、内向きルールは設定しない 他社プロジェクトの BigQuery テーブル上の機密データを、自社プロジェクトの BigQuery テーブルにコピーしたい。2社でアクセス制御要件が違うため、2つのプロジェクトで別々のサービス境界を作成する。その後、 2つのサービス境界を境界ブリッジで接続する 対応している Google Cloud サービス VPC Service Controls が対応している Google Cloud サービスの一覧は、以下のドキュメントに記載されています。同ドキュメントには、VPC Service Controls が適用された場合、Google Cloud サービスにどのような影響があるのかも記載されています。 参考 : サポートされているプロダクトと制限事項 特殊な影響の例として次のようなものが挙げられます。VPC Service Controls 境界が適用されたプロジェクトでは、Pub/Subの push サブスクリプションは、一部の例外を除いて作成できなくなります。しかし、一時的にプロジェクトを境界の保護から外し、push サブスクリプションを作成した後に再度保護を有効化すると、サブスクリプションは問題なく動作します。 参考 : サポートされているプロダクトと制限事項 - Pub/Sub ドライラン構成 既に稼働中の環境に新しく VPC Service Controls を設定するときや、境界の設定に手を加えるときなどに、テストなしで変更を適用すると、予期せぬ不具合が発生するかもしれません。境界には通常の構成に加えて、 ドライラン 構成を設定できます。 ドライラン構成を適用すると、サービス境界への違反が発生したときにはそのアクションは拒否されず、Cloud Logging へ ログのみが記録 されます。これは、一般的な WAF 製品等のドライラン機能と似ています。 ドライランを使って事前に影響範囲の確認をしておくことで、設定変更の影響を見極めてから実際の適用をすることができます。 参考 : サービス境界のドライラン モード ドライランモードで事前確認 ドライランの使用方法については、以下の記事もご参照ください。 blog.g-gen.co.jp アクセスポリシー アクセスポリシーとは VPC Service Controls には、 アクセスポリシー （Access policies）という管理用オブジェクトがあります。アクセスポリシーは、前述のサービス境界やアクセスレベルなどの設定オブジェクトをグルーピングするためのオブジェクトです。 アクセスポリシーは、scoped access policy や scoped policy と呼ばれる場合もあります。 サービス境界やアクセスレベルを作成する先、格納する先のアクセスポリシーを選択します。意識していない場合、 default アクセスポリシーに格納されます。 default アクセスポリシーは、Google Cloud の Web コンソールから初めてサービス境界を作成すると、自動的に作成されます。 アクセスポリシーには、管理を委任するフォルダやプロジェクトを指定できます。これにより、フォルダまたはプロジェクトの管理者に、VPC Service Controls の管理を委任することができます。 参考 : アクセス ポリシー 参考 : スコープ ポリシーの概要 アクセスポリシーの使い方 例えば、アクセスポリシー development を作成して、以下のように設定したとします。 アクセスポリシー development 設定項目 設定値 管理スコープ フォルダ dev 管理プリンシパル xxx@example.com : Access Context Manager Admin このように設定すると、 xxx@example.com はフォルダ dev の範囲内において、VPC Service Controls 境界を作成したり、設定を変更したりできるようになります。 このような設定は、組織全体の VPC Service Controls は情報システム部門で管理し、開発チームには、各チームごとの範囲で VPC Service Controls を管理させたいときなどに利用できます。 トラブルシューティング 違反アナライザー 境界に対する違反が発生すると、Cloud Logging にログ（ポリシー拒否監査ログ）が記録されます。このログには、ID である トラブルシューティングトークン （ vpcServiceControlsUniqueId ）が記録されています。 Google Cloud コンソールの VPC Service Controls > VIOLATION ANALYZER 画面へ遷移し、このトラブルシューティングトークンを入力することで、そのアクセスがどういった理由で拒否されたのかを確認することができます。 これにより、本来違反とみなされるべきではないアクセスが拒否されてしまったときなどに、原因を調査することができます。 違反アナライザーの画面 違反ダッシュボード 組織で 違反ダッシュボード を有効化することで、境界に対する違反を一覧化することができます。 ダッシュボードでは、指定した期間内の違反が一覧化されており、さまざまなフィルタを使うことができます。トラブルシューティングトークンも表示されており、リンクをクリックすることで違反アナライザーの分析画面へすぐに遷移することができます。 参考 : Set up and view the violation dashboard 詳細は、以下の記事も参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの鈴木ことすずたつです。 Google Workspaceなどをトライアルで利用はしてみたものの、メールが実際どう送受信されるか、実際の運用とは違うからイメージがわかない。 段階的にユーザーをGoogle Workspaceへ移行したいが方法がわからない。 など思ったことはありませんでしょうか？ とはいえ、MXレコードを新しいGoogle Workspace側に向けてしまうと既存のメールに影響がでるし・・・ ということで今日はトライアルで利用した、もしくは一部のユーザーのみGoogle Workspaceのメール環境を 本番同様に利用する ための方法について解説いたします。 ※MXレコードとは メール配送用のドメインレコード。本レコードを向けた方向にメールが送信される 例：MXレコードがg-gen.co.jpの場合にxxxx@g-gen.co.jpにメールが正しく送信されます。 一部ユーザーのみの移行とは？ 前提条件 設定方法 Google Workspaceの申し込み ドメインの所有権の確認 メールの転送設定 一部ユーザーのみの移行とは？ そもそもなぜこのような一部移行が必要になるのでしょうか？まずは通常のメールルーティングの仕組みを簡単に説明させていただきます。 メール送信の仕組み 上記のように、メールを送信するとDNSサーバーにチェックが入り、そのDNSサーバーが@の後ろをチェックしてメールを送信先メールサーバーに届き、受信者に正しくメールが送信される。 という仕組みになります。 では例えば 段階的にGoogle Workspaceに移行したい 場合どうなるでしょうか？ 本番のドメインが@g-gen.co.jpであった場合に、ほかに利用可能なドメインを利用して登録するとメールアドレスが本番とは異なってしまい、本番運用となかなか言えない状態に。 かといって本番ドメインを利用して、MXレコードを切り替えてしまうと全員分のメールがGoogle Workspaceに送信されることになってしまいます。 このような状況を回避し、一部のユーザーはいままで通りの方法でメールを送受信、一部のユーザーはGoogle Workspaceでメールを送受信が可能な環境を構築する方法に関して解説いたします。 前提条件 一部ユーザーのみを移行する前提条件として 「既存のメールサーバーが受信したメールを指定アドレスに自動転送可能であること」 があげられますので、ご注意ください。 この条件が必要な理由としては、以下のような設定が必要となるためです。 (1)本番ドメイン (XXXX@g-gen.co.jp)でメールを受信 (2)受診したメールをGoogleWorkspaceに自動転送 設定方法 前述の環境を実現するステップとしては以下になります。 ・Google Workspaceの申し込み(この時に、本番環境のドメインを入力。) ・TXTレコードを利用して、ドメインの所有権の確認 　 ※この時絶対にMXレコードはいじらないでください。 ・既存メールサーバー上で、移行対象のユーザーのメール転送設定を行う。 事項より詳細を説明いたします。 Google Workspaceの申し込み 以下のURLよりトライアルをお申込みください。パートナーからの購入でも問題ありません。 お申込みの際にドメインの入力画面で、本番環境のドメインを入力してください。 ※G-genの場合には@g-gen.co.jp この時点ではメールがGoogle Workspaceにルーティングされることはありません。 Google Workspace のお申し込み Google Workspace申し込み画面(ドメイン登録) ドメインの所有権の確認 ログイン直後に以下の画面になりますが、 こちらではMXレコードを利用したドメインの所有権の確認のため、絶対に実施しないでください。 ログイン直後の画面 かならず左上の[ メインメニュー＞アカウント＞ドメイン＞ドメインの管理 ]から開く、以下の画面から TXTレコード を利用して実施してください。 ドメイン所有権の確認画面 以下の画面からTXTレコードを利用した所有権の証明を実施してください。 TXTレコードを利用した所有権の確認 所有権の証明が終わり以下のような画面になればGoogle Workspace上での設定は完了です。「Gmailを有効にする。」をクリックして設定を実施してください。 その際、 「MX レコードの設定をスキップ」を必ず選択 してください。 ドメインの所有権確認済み画面 メールの転送設定 現時点ですでにGoogle Workspace上でメールの送受信が可能です。本番ドメインがg-gen.co.jpの場合、Google Workspace上のメール送受信は以下のような状態になります。 メール送信：XXXX@g-gen.co.jp メール受信：XXXX@g-gen.co.jp.test-google-a.com お客様のメールサーバー上の設定にて該当ユーザーが受信したメールを上記の受信可能なメールアドレスに転送する設定をします。 上記の例の場合には ・XXXX@g-gen.co.jpでメールを受信。 ※ただしこの時点では旧メール環境でメールを受信してしまう。 ・XXXX@g-gen.co.jpに来たメールをXXXX@g-gen.co.jp.test-google-a.comに転送。 設定が完了すると以下のような環境になり、転送設定を行ったGoogle Workspaceを利用しているユーザーはGoogle Workspaceでメールを送受信。 転送設定をしていないユーザーはいままで通りの方法でメールを送受信することが可能です。 一部ユーザーのみメール環境の移行 これで一部ユーザーのみの移行設定は完了です。 今回はGoogle Workspaceで記載しましたが、原理としては他のクラウドサービスでも実施可能ですので、トライアル等でクラウドサービスを利用してみたい方はご検討ください！ また、ちょっと技術的に難しくて・・・という方はG-genにお気軽にお声がけください。 Google Cloud(旧GCP) / Google Workspace導入に関するお問い合わせ 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-genの小林です。当記事では、Google Cloud（旧称 GCP）の VPC の基本機能をご紹介します。 はじめに VPC ネットワークとサブネット VPC ネットワーク サブネット イメージ図 VPC の作成モード ルート Cloud NAT VPC ネットワークピアリング 共有 VPC その他 VPC の詳細 はじめに Virtual Private Cloud （VPC）は、仮想ネットワークを構築するためのサービスです。Google Cloud の Compute Engine や Google Kubernetes Engine（GKE）といったサービスを使う上で重要です。VPC に所属するサービスをセキュアに使用するためには、VPC の設計が非常に重要になりますので、基本的な VPC の機能を覚えていきましょう！ また当記事では、Google Cloud と Amazon Web Services（以下、AWS）で類似の機能を並べて紹介します。AWSの VPC は知っているけど、Google Cloud の VPC がわからないという方は是非、参考にしてください。 VPC ネットワークとサブネット VPC ネットワーク VPC ネットワーク は、プライベートな仮想ネットワークです。作成された個々のネットワークのことを指し、単にネットワークと呼ばれることもあります。 Google Cloud の VPC ネットワークの最大の特徴は、 複数のリージョンをまたいだグローバルリソース である点です。AWS の VPC は、単一のリージョンに作成するリージョンリソースですが、Google Cloud の VPC ネットワークは、Google Cloud が提供するすべてのリージョンにまたがります。 また AWS では VPC 作成時に IP アドレス範囲を CIDR 形式で指定しますが、Google Cloud では VPC ネットワークは IP アドレス範囲を持ちません。VPC ネットワークの配下に作成されるサブネットが IP アドレス範囲を持ちます。 参考 : VPC ネットワーク サブネット VPC ネットワークの配下には、Compute Engine VM 等のリソースを配置するネットワーク単位である サブネット を作成します。サブネットは、単一リージョン内に作成するリージョンリソースです。サブネットは、リージョン内のすべてのゾーンにまたがっています。 参考 : サブネット イメージ図 VPC ネットワークとサブネットを模式図にすると、以下のようになります。 Google Cloudネットワーク AWS の VPC をご存知の方のために、AWS の VPC とサブネットの関係を表した図も掲載します。 AWSネットワーク VPC の作成モード Google Cloud では、VPC ネットワークの作成時、サブネット作成モードとして、 自動モード と カスタムモード の2つから選択します。 自動モード を選択すると、Google Cloud が提供するすべてのリージョンに、所定の IP アドレス範囲のサブネットが作成されます。検証用途などの利用に最適です。 一方の カスタムモード は、自動でサブネットは作成されません。ユーザー自ら、リージョンや IP アドレス範囲を指定してサブネットを作成します。本番環境で利用する場合は、こちらが推奨です。 参考 : サブネット作成モード ルート Google Cloud では、パケットをルーティングするための経路として ルート を登録します。AWS ではサブネットごとにルートテーブルを紐づけますが、Google Cloud では VPC ネットワークが1つのルートテーブルを持ち、VPC 内のすべての VM がこのルートテーブルを参照します。 デフォルトで、すべてのサブネット同士が互いに通信できるルートと、インターネットへのルートが作成されます。そのほかのルートはユーザー自身で登録する必要があります。 また、それぞれのルートにはプライオリティを設定します。プライオリティの数字が若いルートから、優先的に評価されます。 ルート 参考 : ルート Cloud NAT 外部 IP アドレスを持たないインスタンスがインターネットへのアクセスをするために利用するのが、 Cloud NAT です。Cloud NAT はフルマネージドの NAT インスタンスです。 CloudNAT なお、AWS の場合は NAT Gateway 作成後に、ルートテーブルで NAT Gateway をターゲットとしたルートを追加する必要がありますが、Google Cloud では必要ありません。 参考 : Cloud NAT の概要 VPC ネットワークピアリング VPC ネットワークピアリング は、2つの VPC ネットワーク同士を接続し、内部 IP アドレスでの接続を可能にする機能です。 AWS と同様、ピアリングは VPC ネットワークを 1:1で接続 します。以下のように、直接ピアリングしていない VPC ネットワーク同士はパケットが到達しません（2ホップ制限、もしくは推移的ピアリングの禁止）。 VPCPeering また、ピアリングする VPC ネットワーク配下のサブネットは、IP アドレス範囲が重複してはいけません。 参考 : VPC ネットワーク ピアリング 共有 VPC 通常、VPC ネットワークは1つのプロジェクトに閉じるリソースです。しかし 共有 VPC 機能を使うと、VPC ネットワークを他のプロジェクトに共有することができます。 以下のようなユースケースが考えられます。 ルート、ファイアウォール、Cloud VPN 等のリソースはネットワーク管理者が集中管理したい VM の管理権限を開発チームに与えるが、ネットワークは設定変更させたくない こういった際に共有 VPC を使うことで、セキュアな権限設計や、ネットワークの一元管理が実現できます。 共有 VPC 参考 : 共有 VPC その他 VPC の詳細 以下の記事では、VPC の仕組みを詳細に解説しています。より詳しく知りたい場合は、参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp 小林 あゆみ (記事一覧) クラウドソリューション部 営業チーム AWSエンジニアからGoogle Cloud営業に転向 福井からリモートワーク中 趣味はMonkey125でツーリング、Netflix鑑賞、旅行

G-genの杉村です。Google Cloud（旧称 GCP）の Cloud Identity-Aware Proxy （以下、Cloud IAP）についてご紹介します。 IAP とは 料金 VM にアクセスするための踏み台として使う 設定方法 VPC のファイアウォール設定 IAM 権限の付与 アクセス方法 SSH の場合 Google Cloud コンソールから gcloud コマンドから SSH ターミナルソフトウェアから リモートデスクトップ（RDP） Chromebook で IAP Tunnel を作成する方法 IAP とは IAPの概念 Identity-Aware Proxy （IAP、または Cloud IAP）は、Google Cloud（旧称 GCP）が提供する フルマネージドのリバースプロキシ です。フルマネージドですので、利用者は IAP を構築したり、運用、保守をする必要はありません。 図のように、IAP を経由して VPC にある各種リソースへアクセスしたり、IAP Connector というコンポーネントをデプロイすれば、オンプレミスのリソースへのアクセスも中継することができます。 参考 : Identity-Aware Proxy の概要 また、IAP は Cloud Run サービス等でデプロイされた、Web アプリケーションに、簡単に認証機構を実装するためにも利用できます。 参考 : Configure Identity-Aware Proxy for Cloud Run 参考 : Identity-Aware Proxy(IAP)とCloud Armorを使用してCloud Runサービスへのアクセス制御を実装する - G-gen Tech Blog なお、IAP は BeyondCorp Enterprise の1つの要素にもなっています。当記事では BeyondCorp Enterprise には触れませんが、ご興味のある方は以下の記事をご参照ください。 参考 : Chrome Enterprise Premium（旧BeyondCorp Enterprise）を徹底解説 - G-gen Tech Blog Google Cloud の IAP には様々な機能がありますが、当記事でご紹介するのは Compute Engine のインスタンス（VM）へ、SSH/RDP ログインのための機能です。 料金 IAP の料金は、原則無料です。 ただし、デバイス制限をかけるなど、詳細なアクセス制御をかける場合は BeyondCorp Enterprise の機能となり、有償となります。詳細は以下をご参照ください。 参考 : Identity-Aware Proxy の料金 VM にアクセスするための踏み台として使う セキュリティ上、Compute Engine VM には、できるだけ外部 IP アドレス（External IP address）を付与せずにおきたいものです。外部 IP アドレスがないインスタンスにログインするためには、踏み台サーバを用意する必要があると思われるかもしれません。 しかし、IAP を使えば、 踏み台サーバは不要 です。 VMログインのためのIAP 図のように、利用者はまずインターネット経由（HTTPS）で IAP へアクセスし、トンネルを作成します。このとき、利用者は Google アカウントで認証します。また IAP を利用できるのは、Identity and Access Management（IAM）で適切なロールを付与された人だけです。 VPC のファイアウォールルールでは、IAP の接続元 IP アドレスである 35.235.240.0/20 からの 22/TCP（SSH）もしくは 3389/TCP（RDP）接続を許可します。 参考 : TCP 転送での IAP の使用 これで、利用者は IAP 経由で外部 IP アドレスを持たない VM にログインすることができます。また、外部 IP アドレスを持っている VM へのログインにも、IAP を利用できます。 設定方法 設定方法は簡単です。以下の2つを実施すれば、IAP が利用できます。 VPC のファイアウォール設定 対象インスタンスの存在する VPC ネットワークのファイアウォールの上り（Ingress）ルールで、 35.235.240.0/20 からの 22/TCP（SSH）もしくは 3389/TCP（RDP）接続を許可します。 IAM 権限の付与 IAP を利用させる Google アカウントやグループに、必要な IAM ロールを付与します。 まず、以下の IAM ロールを、プロジェクトのレベルでアタッチします。 Compute 閲覧者（ roles/compute.viewer ）や Compute OS ログイン（ roles/compute.osLogin ）等の compute.instances.get 権限を持つロール さらに、以下の IAM ロールを、プロジェクトレベルまたは VM の IAP トンネルリソースにアタッチします。 IAP で保護された トンネル ユーザー（ roles/iap.tunnelResourceAccessor ） 手順は、以下のドキュメントを参考にしてください。 参考 : TCP 転送での IAP の使用 - IAP TCP 転送のロールを付与する なお利用できるポート番号を制限したり、 Access Context Manager で定義したアクセスレベルを満たしていることをアクセスの条件として追加することもできます。 また先述の プロジェクトのレベルでアタッチ の意味がピンと来ない場合は、以下の記事をぜひご参照ください。 blog.g-gen.co.jp アクセス方法 SSH の場合 Google Cloud コンソールから Google Cloud コンソール画面からの SSH であれば、 VM のコンソールで SSH ボタンを押すだけです。 コンソールのSSHボタン Google Cloud コンソールでは、IAP が利用可能な条件が満たされていれば、自動的に IAP 経由でアクセスしてくれます。 gcloud コマンドから gcloud コマンドでアクセスする場合も簡単です。インスタンスに外部 IP アドレスが付与されていなければ、gcloud compute ssh コマンドを実行するだけで、自動的に IAP 経由でアクセスしてくれます。 gcloud compute ssh ${INSTANCE_NAME} ※ ${INSTANCE_NAME} はインスタンス名に置き換えてください。 対象インスタンスに外部 IP アドレスが付与されている場合でも、明示的に --tunnel-through-iap オプションをつけることで、IAP 経由でアクセスしてくれます。 gcloud compute ssh --tunnel-through-iap ${INSTANCE_NAME} 参考 : TCP 転送での IAP の使用 - SSH 接続のトンネリング SSH ターミナルソフトウェアから Tera Term / PuTTY 等の、使い慣れた SSH ターミナルソフトウェアから IAP を利用することもできます。 まず、以下のコマンドを実行して、localhost と VM の間に IAP 経由でトンネルを作成します。 gcloud compute start-iap-tunnel ${INSTANCE_NAME} 22 \ --local-host-port = localhost:10022 \ --zone = ${ZONE} ※ ${INSTANCE_NAME} はインスタンス名に置き換え ※ ${ZONE} はインスタンスが配置されているゾーン名に置き換え 例: asia-northeast1-b ※ 例では 10022 ポートだが任意のポートで問題ない この後、localhost:10022 に対して Tera Term / PuTTY 等 から SSH アクセスすることで VM へログインすることができます。ただし、事前に VM へ公開鍵の登録が必要です。 リモートデスクトップ（RDP） リモートデスクトップ（RDP）の場合は、いったんクライアントソフトを使って利用者の PC から IAP までトンネルを作成します。前述の「SSH ターミナルソフトウェアから」と同じ要領です。 gcloud compute start-iap-tunnel ${INSTANCE_NAME} 3389 \ --local-host-port = localhost:13389 \ --zone = ${ZONE} ※ ${INSTANCE_NAME} はインスタンス名に置き換え ※ ${ZONE} はインスタンスが配置されているゾーン名に置き換え 例: asia-northeast1-b ※ 例では 10022 ポートだが任意のポートで問題ない このコマンドを実行することで、ローカル PC と IAP の間でトンネルが作成されます。この状態でローカルの 13389 ポートへアクセスすると、IAP へ通信がルートされます。 RDP ツールを開いて localhost:13389 へアクセスすれば、インスタンスへ RDP できます。 参考 : TCP 転送での IAP の使用 - RDP 接続のトンネリング Chromebook で IAP Tunnel を作成する方法 お使いの端末が Chromebook の場合、IAP を利用してトンネルを作成し、SSH や RDP を行う方法について、以下の記事もご参照ください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）の Identity and Access Management （略称 IAM）は Google Cloud のアクセス制御を司る仕組みです。本記事では、IAM の基本的な仕組みを解説し、詳細な仕様を解き明かしていきます。 IAM とは ID（アカウント） Google Cloud におけるアカウント管理 AWS の IAM ユーザーとの違い Google アカウント Google グループ サービスアカウント IAM の仕組み IAM とリソースの関係 継承 ロールバインディング（role bindings） 許可と拒否 プリンシパルアクセス境界ポリシー IAM ポリシーの構造 gcloud コマンドによる許可ポリシー編集 IAM ロール IAM ロールとは 基本ロール 事前定義ロール カスタムロール ロールの持つ権限 ロールの探し方 トラブルシューティング 新しい基本ロール サービスアカウント サービスアカウントとは サービスアカウントの利用 サービスアカウントキーの注意点 サービスアカウントの権限借用 サービスエージェント PAM による特権管理 AWS IAM との比較と連携 概要 ID（IAM ユーザー） 概念の違い 用語の違い AWS IAM と Google Cloud IAM の連携 IAM とは Identity and Access Management （IAM）とは Google Cloud リソースに対するアクセス制御を司る仕組みです。 IAM は、Google Cloud リソースに対して、 誰が、どういう条件で、何をできるか を管理します。 ここでの リソース とは、Compute Engine の VM や BigQuery のテーブルなど、Google Cloud のオブジェクトの1つ1つを指しています。これらに対する操作権限を定義する仕組みが IAM です。 参考 : IAM の概要 ID（アカウント） Google Cloud におけるアカウント管理 IAM を理解するには Google Cloud における ID 管理（アカウント管理）を理解する必要があります。 Google Cloud の管理コンソールにログインしたり CLI ツールを実行するためのユーザーアカウントは、Google Cloud では Google アカウント と呼ばれます。 管理用アカウントとして、無償の Gmail アカウントを使うことも、Google Workspace（旧 GSuite）や Cloud Identity といった仕組みで集中管理されたアカウントを使うこともできます。 AWS の IAM ユーザーとの違い Amazon Web Services（以下、AWS）をご存知の方のために、Google でのアカウント管理と、AWS の IAM ユーザーとの違いをご紹介します。 AWS における ID は IAM ユーザー と呼ばれ、 AWS アカウント（テナント）の中で管理されます。つまり AWS では、IAM ユーザー自体もクラウドリソースです。一方の Google Cloud では、アカウントはクラウドリソースではなく、Google Cloud から分離されており、Google Workspace や Cloud Identity といった別サービスで管理されます。 ですから、既に Google Workspace を使っている場合、Google Workspace のユーザーアカウントをそのまま Google Cloud の管理用アカウントとして利用できます。 Google Workspace を使っていない場合は、Cloud Identity というサービス（Free エディションでは50アカウントまで無償）で 組織 を作り、アカウントを管理することができます。 ID 管理の違い Google アカウント Google Workspace でも Cloud Identity でも、アカウント名は john@example.com のようにメールアドレス形式です。 Google アカウントは 1人に対して1個ずつ 、発行されることが原則です。複数人で使い回す共用アカウントを作成してしまうと、「パスワードの漏洩」「インシデントの際に監査ログから実行者が特定できない（それによる内部犯に対する抑止力低下）」などのリスクがあります。 なお、個人の Google アカウント（Gmail アカウント）も Google Cloud 用アカウントとして権限を持たせることが可能です。 ただし企業で Google Cloud を利用する場合は、無償アカウントではなく、 Google Workspace か Cloud Identity の利用が強く推奨 されます。無償 Google アカウントだと、グループによる権限管理や、組織のポリシーなどの強力なセキュリティ機能が利用できないためです。 Google アカウントについての詳細は、以下の記事も参照してください。 blog.g-gen.co.jp Google グループ Google Workspace か Cloud Identity では、 Google グループ （または単に グループ ）を作成して、アカウントをグループに所属させることができます。 グループは admin-grp@example.com のようにメールアドレス形式であり、アカウントと同様に、Google Cloud リソースに権限を紐づけることができます。なおグループは、Google Workspace においてはメーリングリストとしても利用できます。 グループは、Google Workspace（Cloud Identity）の管理コンソール（ https://admin.google.com/ ）や、Google Workspace の「Google グループ」画面（ https://groups.google.com/ ）で管理できるほか、適切な権限を持っていれば Google Cloud コンソールから管理することも可能です。 参考 : グループを作成し、グループ設定を選択する 参考 : Google Cloud コンソールで Google グループを作成して管理する サービスアカウント Google Cloud には サービスアカウント という概念があります。 サービスアカウントは、Google アカウントとは異なり、人間ではなくプログラムが利用するアカウントです。プログラムから Google Cloud の各種サービスを操作する際は、サービスアカウントに権限を持たせて、サービスアカウントの認証情報で認証・認可を行います。 また、サービスアカウントはGoogle アカウントとは異なり、 Google Cloud リソース です。サービスアカウントはいずれかの Google Cloud プロジェクト内に、リソースとして作成されます。 サービスアカウントの詳細については後述します。 参考 : サービス アカウントの概要 IAM の仕組み IAM とリソースの関係 Google Cloud の IAM で最も重要なのは、 IAM 権限はプリンシパル（主体）とリソースの間に紐づくものである という点です。 リソースとIAMの関係 Google Cloud では、「誰が（Googleアカウント、グループ等。総称してプリンシパルと呼ばれる）」「何をできるか（IAM ロール）」という権限設定情報を、 リソースが持ち ます。個々のリソースが持つこの権限設定を、 IAM ポリシー といいます。 リソースとは Compute Engine VM や、BigQuery データセットなどを指します。Google Cloud プロジェクトもリソースですし、組織もリソースである点に注意が必要です。 後に詳しく記述しますが、一方の AWS では、個々の プリンシパルが 、「何に対して」「何をできるか」という権限設定情報を持ちます。つまり、 主語は IAM ユーザーなどの主体 です。ここが Google Cloud と AWS の大きな相違点です。 継承 上位のリソースに権限を紐づけると、下位のリソースに 継承 （inherit）されます。 例えば、 Google Cloud 組織 のトップノード（組織ツリーの最上位のこと。ルートとも言う）に対して、「 プリンシパル : XXX@example.com 」「 IAM ロール : オーナー 」という権限を紐づけたとします。このとき XXX@example.com さんはその組織の配下にある全てのリソース（フォルダ、プロジェクト、VM インスタンスや BigQuery データセット）にオーナー権限を行使することができます。 一方で、あるプロジェクトに対して「 プリンシパル : XXX@example.com 」「 IAM ロール : オーナー 」という権限を紐づけると、XXX@example.com さんはそのプロジェクト配下にある全てのリソース（VM インスタンスや BigQuery データセット）にオーナー権限を行使することができますが、他のプロジェクトに対しては権限が及びません。 継承 また例えば、ある VM インスタンスにオーナー権限を付与すると、XXX@example.com さんは その VM にだけオーナー権限を行使でき ます。他のリソースを操作したり閲覧することはできません。 この仕組みを理解できれば、 何にどんな権限付与すると、どこまで効果が及ぶのか を理解できます。 参考 : リソース階層を使用したアクセス制御 Google Cloud の組織の詳細については、以下の記事を参照してください。 blog.g-gen.co.jp ロールバインディング（role bindings） Google Cloud の IAM では、前述のように、リソースに対して、誰が何をできるかを設定します。例えばあるプロジェクトに対して「 プリンシパル : XXX@example.com 」「 IAM ロール : オーナー 」のように、権限を紐づけます。この紐づけを ロールバインディング （role bindings）、または単にバインディングと呼びます。binding とは、「紐づき」「結合」といった意味の英単語です。 あるリソースには、複数のロールバインディングを設定できます。例えば、あるプロジェクトに、以下のように複数のバインディングを作成できます。 あるプロジェクトのバインディング一覧 プリンシパル ロール XXX@example.com オーナー（ roles/owner ） YYY@example.com Compute 管理者（ roles/compute.admin ） YYY@example.com ストレージ管理者（ roles/storage.admin ） Google Cloud コンソールで、あるプロジェクトを選択している状態で「IAM と管理 > IAM」画面へ遷移すると表示される一覧は、そのプロジェクトのバインディングの一覧です。ここに設定されたバインディングは、そのプロジェクトの配下にあるすべてのリソースに継承されます。 あるプロジェクトのバインディング一覧 許可と拒否 Google Cloud の IAM では、すべてのリソースは、デフォルトで すべてのアカウントからの操作を拒否 します（ 暗黙の Deny ）。リソースの IAM ポリシーに対してバインディングを追加することで、プリンシパルに対して、アクション実行の 許可 を明示的に与えることができます（ 明示的な Allow ）。 また、 拒否ポリシー （Deny policies）を IAM ポリシー（許可ポリシー）とは別に作成することで、 明示的な Deny を設定することが可能です。ポリシーの評価順は「 明示的な Deny > 明示的な Allow > 暗黙の Deny 」であり、明示的な Deny が最も強いです。 そのためポリシー設計時は、基本的には 「明示的な Allow」を付与するかしないで管理することを基本 とし、どうしても強い権限で拒否したいときだけ、明示的な Deny を使う、といった手法が良いでしょう。 拒否ポリシーは強力なため、安易に使うと後から修正が難しくなる場合があります。拒否ポリシーの設定は必須ではありません。原則はまず許可ポリシー（IAM ポリシー）だけでアクセス制御を設計するよう検討してください。 拒否ポリシーの詳細については以下の記事で解説しています。 blog.g-gen.co.jp プリンシパルアクセス境界ポリシー プリンシパルアクセス境界ポリシー （Principal access boundary policies）は、許可ポリシーと拒否ポリシーに続く3つ目のポリシーです。 自組織のアカウントが、他の Google Cloud 組織のリソースにアクセスできないよう制限をかけることができます。設定は必須ではありません。詳細は、以下の記事を参照してください。 blog.g-gen.co.jp IAM ポリシーの構造 IAM ポリシー（許可ポリシー）の構造もご紹介します。 全てのリソース（組織、フォルダ、プロジェクト、VM インスタンスや BigQuery データセット）は 許可ポリシー を1つだけ持っています。許可ポリシーは、単に IAM ポリシーと呼ばれることもありますが、AWS の IAM ポリシーとは全く別物のため、注意が必要です。 許可ポリシーの構造 許可ポリシーは 1つのリソースが1つだけ 持っています。許可ポリシーはその中に、複数のロールバインディング（または単にバインディング）を持つことができます。 バインディングは「 誰が （Google アカウントやグループ、サービスアカウント等。総称してプリンシパルやメンバーと呼ばれる）」「 何を （IAM ロール）」「 どういう条件のときに （condition）」実行できるのか、という情報を持ちます。 上記の図では、 it-grp@example.com は、組織とその配下のすべてのリソースに対して、オーナー（ roles/owner ）ロールの権限を持ちます。また、 john@example.com は、instance-01 に対してのみ、コンピュート管理者（ roles/compute.admin ）の権限を持ちます。条件（condition）の記述に従い、2025年4月30日に権限は無効になります。 あるリソースの IAM ポリシーを JSON フォーマットで出力すると、以下のようになります。 { " bindings ": [ { " members ": [ " user:jie@example.com " ] , " role ": " roles/resourcemanager.organizationAdmin " } , { " members ": [ " user:divya@example.com ", " user:jie@example.com " ] , " role ": " roles/resourcemanager.projectCreator ", " condition ": { " title ": " Expires_July_1_2022 ", " description ": " Expires on July 1, 2022 ", " expression ": " request.time < timestamp('2022-07-01T00:00:00.000Z') " } } ] , " etag ": " ******** ", " version ": 1 } このように、1つの許可ポリシーの中に、配列で複数のバインディングが入っています。バインディングの中には、どういう条件（condition）で誰が（メンバー）何をできる（IAM ロール）のかが記述されている、ということが分かります。 参考 : 許可ポリシーについて gcloud コマンドによる許可ポリシー編集 ここまで分かれば、コマンドラインツール gcloud で IAM 権限を付与するときは、以下のようにする理由が分かるでしょう。 プロジェクトレベルで IAM 権限を付与するとき gcloud projects add-iam-policy-binding my-project-id --member =' user:test-user@gmail.com ' --role = roles/resourcemanager.projectCreator ` VM インスタンスに IAM 権限を付与するとき gcloud compute instances add-iam-policy-binding my-instance --zone = asia-northeast1-b --member =' user:test-user@gmail.com ' --role =' roles/compute.securityAdmin ' 上記のコマンドでは、各リソースの許可ポリシーに対して add-iam-policy-binding をすることで、バインディングを追加しているのです。 IAM ロール IAM ロールとは IAM ロール とは、Google Cloud リソースへのアクションに対する許可権限をまとめた、 権限セット です。AWS にも「IAM ロール」という用語がありますが、まったく別物ですので、注意が必要です。 ほんの一部の抜粋ですが、Google Cloud の IAM ロールには、以下のようなものがあります。 名称 ID 権限の内容 オーナー roles/owner ほとんどの Google Cloud リソースに対する編集・読み取り Compute 管理者 roles/compute.admin 多くの Compute Engine リソースに対する編集・読み取り ストレージ管理者 roles/storage.admin Cloud Storage バケットやオブジェクトに対する編集・読み取り Storage オブジェクト閲覧者 roles/storage.objectViewer Cloud Storage オブジェクトのデータやメタデータに対する読み取り 上記のようなロールを、許可ポリシーにおいてプリンシパルと紐づけることで、プリンシパルはリソースに対して、ロールに定義された権限を持つことができます。 大きく分けて、IAM ロールには以下の3種類があります。 種類 概要 基本ロール オーナー、編集者、閲覧者の3つ。広範な権限を持つロール 事前定義ロール 特定の Google Cloud サービスに限定された権限を持つロール カスタムロール ユーザーが独自に定義できるロール 参考 : ロールと権限 基本ロール 基本ロール は、オーナー、編集者、閲覧者の3つを指します。基本ロールは、多くの Google Cloud サービスに対して広い権限を持ちます。 オーナー （ roles/owner ）は、ほとんどの Google Cloud サービスに対して、編集や読み取りの権限を持っています。プロジェクトに対してプリンシパルをオーナーロールとして紐づけると、プリンシパルはプロジェクトやその配下のリソースに対して、ほとんどの操作を実行できるようになります。また、リソースの IAM ポリシーを編集する権限もあります。 編集者 （ roles/editor ）は、オーナーと同様、ほとんどの Google Cloud サービスに対して、編集や読み取りの権限を持っています。ただし、IAM ポリシーの編集権限を持たないため、オーナーよりは権限範囲が狭くなります。 閲覧者 （ roles/editor ）は、ほとんどの Google Cloud サービスに対する読み取り権限を持ちます。リソースの状態を変更する権限は持ちません。ただし、Cloud Storage や BigQuery など、機密情報を持ち得るリソースのデータも読み取ることができるため、広い権限範囲を持つことに変わりはありません。 このように基本ロールは、広範な権限を持つため、 最初権限の原則 に従うと、本番環境ではできるだけ利用を控えたほうがよい場合もあります。 参考 : ロールと権限 - 基本ロール 事前定義ロール 事前定義ロール は、Google によって事前定義された、Google Cloud サービスごとのロールです。以下のようなロールが当てはまります。 名称 ID 権限の内容 Compute 管理者 roles/compute.admin 多くの Compute Engine リソースに対する編集・読み取り ストレージ管理者 roles/storage.admin Cloud Storage バケットやオブジェクトに対する編集・読み取り Storage オブジェクト閲覧者 roles/storage.objectViewer Cloud Storage オブジェクトのデータやメタデータに対する読み取り Cloud Run 管理者 roles/run.admin Cloud Run リソースに関するすべての操作 Cloud Run デベロッパー roles/run.developer Cloud Run リソースのデプロイ、閲覧など 事前定義ロールは多くの場合、Google Cloud サービスごとに定義されており、管理者、開発者、閲覧者のロールが容易されていることがほとんどです。本番環境できめ細かい権限管理を行うには、事前定義ロールを使うことが一般的です。 参考 : ロールと権限 - 事前定義ロール カスタムロール カスタムロール は、ユーザーが独自に定義できるロールです。きめ細かい権限管理が必要な場合で、適切な事前定義ロールが存在しない際は、ユーザー独自のロールを定義することができます。 カスタムロールは組織またはプロジェクトに所属するリソースであり、ロールを作成した組織またはプロジェクトにのみ付与できます。 参考 : ロールと権限 - カスタムロール ロールの持つ権限 ロールの中には、 権限 （permissions）が定義されています。例えば、Compute 管理者（ roles/compute.admin ）ロールには、以下のような権限が含まれています。 compute.instances.create compute.instances.get compute.instances.list compute.instances.delete compute.instances.start compute.instances.stop ロールに含まれる権限により、そのロールを付与されたプリンシパルが実行可能なアクションが決まります。 ロールの探し方 事前定義ロールの一覧は、以下のリファレンスドキュメントに記載されています。一連のリファレンスドキュメントでは、Google Cloud サービスごとに IAM ロールが整理されており、またロールが持つ権限（permissions）も記載されています。 参考 : IAM roles and permissions index また各 Google Cloud サービスの公式ガイドには、そのサービスに関連する IAM ロールのドキュメントが用意されています。こちらには、上記のリファレンスよりも詳しいユースケースなどが記載されている場合があります。 参考 : Compute Engine IAM のロールと権限 参考 : Cloud Storage に適用される IAM のロール 参考 : Cloud Run IAM roles また、Google Cloud コンソールの「IAM と管理 > ロール」画面でも、基本ロール、事前定義ロール、カスタムロールの一覧を確認できます。この画面では、ロールの名称、ID、持っている権限を確認することができます。 参考 : Google Cloud コンソール - IAM と管理 > ロール トラブルシューティング Google Cloud リソースへの操作時に権限不足（Permission denied）で操作が失敗した場合は、多くの場合、足りない権限がエラーメッセージに記載されます。 前述のドキュメントを使って、必要な権限を持つロールを探し出して、プリンシパルに付与することで対処します。 以下の記事も参考にしてください。 blog.g-gen.co.jp 新しい基本ロール 2025年5月現在ではプレビューですが、3つの基本ロールが新しいものに刷新されます。将来的には、これらの新しい基本ロールが標準になります。 名称 ID 権限の内容 管理者 roles/admin ほとんどの Google Cloud サービスに対する編集や読み取り 書き込み roles/writer ほとんどの Google Cloud サービスに対する編集や読み取り。ただし IAM 編集を除く 読み取り roles/reader ほとんどの Google Cloud サービスに対する読み取り 参考 : ロールと権限 - 基本ロール 従来の基本ロールと、新しい基本ロールでは、権限の内容はほとんど同じですが、微妙な違いがあります。詳細は、以下の記事をご参照ください。 blog.g-gen.co.jp なお、プレビュー段階のサービスや機能は、サポートや SLA の対象外であるほか、一般公開（GA）までに仕様が変更される可能性があるため、本番環境での利用は推奨されません。新しい基本ロールが一般公開されるまでは、本番環境での利用は控えることが推奨されます。 詳細は以下の記事も参照してください。 blog.g-gen.co.jp サービスアカウント サービスアカウントとは サービスアカウント とは、人間ではなくプログラムが利用するアカウントです。プログラムから Google Cloud APIs を利用する際は、サービスアカウントを使って認証・認可を行います。サービスアカウントは Google アカウントとは異なり、Google Cloud プロジェクトの中に作成するクラウドリソースです。 サービスアカウントはメールアドレスの形式の名称を持ちます。以下は、サービスアカウント名の例です。 my-service-account@my-project-id.iam.gserviceaccount.com 参考 : サービス アカウントの概要 サービスアカウントの利用 プログラムから API 経由で Google Cloud サービスを操作する際は、以下のいずれかの方法で、サービスアカウントの認証情報を使って認証します。 サービスアカウントキー（JSON 形式等）を読み込ませる プログラムが動作する実行環境（VM 等）にサービスアカウントをアタッチする 前者の方法は、サービスアカウントの秘密鍵を JSON 形式でダウンロードし、実行環境に配置して、それをプログラムから読み込ませる方法です。 後者の方法は、プログラムの実行環境が Google Cloud 環境である場合にのみ使えます。Compute Engine VM や Cloud Run サービス、Cloud Functions 関数などにはサービスアカウントを アタッチ することができます。Cloud SDK（クライアントライブラリ）や gcloud コマンドは、認証情報を明示的に指定しなければ、自動的に実行環境にアタッチされたサービスアカウントの認証情報を利用します。 参考 : サービス アカウントとして認証する サービスアカウントキーの注意点 サービスアカウントキーを利用するプログラムの実行環境が Google Cloud 環境であれば、前掲の2つの方法のうち、 後者の方が強く推奨 されます。 サービスアカウントキーは JSON 形式のテキストファイルであり、漏洩の危険性があります。キーファイルが漏洩すれば、サービスアカウントが持つ権限を自由に行使して、Google Cloud 環境への侵害が可能になってしまいます。 後者のサービスアカウントをアタッチする方法であれば、キーの漏洩はありません。 参考 : 他に有効な方法がない場合にサービス アカウント キーを使用する また、組織のポリシー機能により、サービスアカウントキーの発行自体を禁止させることも可能です。以下の記事も参照してください。 blog.g-gen.co.jp サービスアカウントの権限借用 サービスアカウントの応用技として、 権限借用 があります。 他のプリンシパル（Google アカウントや他のサービスアカウント）からサービスアカウントの権限を借用して Google Cloud API を実行することが可能です。詳細は以下の記事も参考にしてください。 参考 : サービス アカウントに有効期間の短い認証情報を作成する 以下の記事では Terraform のセキュアな利用のためにサービスアカウントからの権限借用を活用する例を紹介しています。 blog.g-gen.co.jp サービスエージェント サービスエージェント は、Google Cloud サービスが内部的に用いる、特別なサービスアカウントです。プロダクトの API を有効化したときなどに自動的に作成されるため、ユーザーが意識することはあまりありませんが、初期設定時や仕組みの構築の際に、サービスエージェントに対して権限の付与が必要になることがあります。 参考 : Service agents サービスエージェントについては、以下の記事で詳細に解説しています。 blog.g-gen.co.jp PAM による特権管理 Privileged Access Manager （PAM）は、承認フローを通して時限付きの権限管理をするための仕組みです。IAM の1機能として無料で提供されています。 所定の承認者が承認したときに作業者に IAM 権限が付与され、設定時間が経過すると、権限が自動的に剥奪されます。「ジャスト・イン・タイム」な権限管理が可能になる仕組みです。 詳細は以下の記事を参照してください。 blog.g-gen.co.jp AWS IAM との比較と連携 概要 この章では、Google Cloud の IAM の仕組みをより正しく理解するため、AWS の IAM との違いに着目して解説します。また、AWS との IAM の連携方法についても紹介します。 AWS を利用したことがなく、これから利用する予定も無い方は、読み飛ばしても問題ありません。 ID（IAM ユーザー） マネジメントコンソールにログインしたり、 CLI ツールを実行するための ID は、 AWS では IAM ユーザー と呼ばれ、 AWS アカウント（テナント）の中で管理されます。 Google Cloud の ID が、Google Cloud とは分離されており、Google Workspace や Cloud Identity で管理されることとは対照的です。 概念の違い AWS IAM では IAM ポリシーで権限セット（できること）を定義し、それを 権限主体 （IAM ユーザーやグループ。総称して プリンシパル ） に紐づけ ます。 別の言葉で言うと、「どのリソースに対して」「何ができるか」という権限定義を 人に 紐づけるのです。 これは Google Cloud の IAM が、「誰が」「何をできるか」を リソースに 紐づけるのとは考えが異なります。 用語の違い IAM ポリシー、IAM ロールといった用語は両クラウドで共通していますが、意味は大きく異なっています。混同しないように気を付けましょう。 意味 AWSでの用語 Google Cloud の用語 権限セット IAM ポリシー IAM ロール 権限を実行する IAM 主体（人間） IAM ユーザー Google アカウント 権限を実行する IAM 主体（サービス） IAM ロール サービスアカウント IAM 主体をまとめるグループ IAM グループ Google グループ 個々のリソースが持つ権限設定 (対応概念なし) IAM ポリシー AWS IAM と Google Cloud IAM の連携 Google Cloud の IAM には Workforce Identity および Workload Identity という仕組みがあります。これらの仕組みでは、OpenID Connect（OIDC）や SAML 2.0 を使って、外部の ID プロバイダ（IdP）と Google Cloud の IAM を連携させることができます。 人間のユーザー向けの連携機能が Workforce Identity、プログラムなどワークロード向けの連携機能が Workload Identity です。 これらの仕組みを使うと、Google Cloud 側から AWS の IAM Role を信頼することで、Google Cloud への API 実行を認可することができます。 詳細は以下を参照してください。 参考 : ワークロードの ID 参考 : Workforce Identity の連携 また、以下の当社記事で実際に AWS から Workload Identity によって Google Cloud へ認証・認可させた実例を紹介しています。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it