G-gen の杉村です。当記事では Google Cloud（旧称 GCP）の認定試験の中でも基本的なレベルの内容である Associate Cloud Engineer 試験 の合格に役立つ情報を記載します。 はじめに 当記事について 試験の概要 試験の難易度 推奨の勉強法 対策書籍 更新試験 出題傾向 組織とリソース リソース階層の概念 プロジェクトと API 有効化 組織のポリシー IAM IAM の基本概念 IAM ロールはアカウントではなくグループに付与 基本ロールと事前定義ロール サービスアカウント VPC VPC とサブネットの基本 セグメントとファイアウォールルール 限定公開の Google アクセス Cloud DNS Cloud Load Balancing Compute Engine 基礎知識 ディスク・バックアップ・リストア 購入オプション コンピューティングサービス App Engine Google Kubernetes Engine（GKE） Cloud Run コンピューティングサービスの使い分け Cloud Storage データベース、データ分析 Cloud SQL BigQuery Spanner データベースのベストな選択 データパイプライン Google Cloud Observability Cloud Monitoring Cloud Logging Cloud Audit Logs 料金 請求先アカウント 予算アラート 利用料金の見積とアーキテクチャ 利用料金データの BigQuery へのエクスポート Access Approval その他 Google Cloud の哲学 受験環境 はじめに 当記事について 当記事では Google Cloud（旧称 GCP）の認定試験の中でも基本的なレベルの内容である Associate Cloud Engineer 試験 の合格に役立つ情報を記載します。 試験の 利用規約 において、試験の内容を公開することは禁じられています。本投稿では試験問題そのものを書くこと等はせず、 合格するためには何を知っているべきか 、を中心に記載します。 なお当記事に記載されていることで試験範囲をすべてカバーできているわけではない点、ご了承ください。公式で発表されている 試験ガイド や 模擬試験 も駆使して、学習を進めてください。 また当試験は、2024年8月26日に試験内容が改訂されています（2024年11月時点では英語版のみ。日本語版には未反映）。当記事は新旧どちらの試験にも対応できる Tips を記載していますが、どちらかというと新試験寄りの内容が記載されていることにご留意ください（当記事は、2024年11月に最新化されました）。 試験の概要 Associate Cloud Engineer 試験 は、 Google Cloud の認定試験の中でも基本的な試験です。 Google Cloud のインフラ系サービスを中心に、セキュリティ、アプリケーションホスティング、データベース、モニタリングなど、幅広い範囲が対象です。試験時間は120分、試験問題数は50問です。 試験は日本語、英語、スペイン語、ポルトガル語で提供されています。 参考 : Associate Cloud Engineer 他の試験一覧は以下をご参照ください。 参考 : Google Cloud 認定資格 試験の難易度 当試験の難易度としては、他の Google Cloud 認定資格と比較して、 比較的簡単である と言えます。 前提知識として、IPA の基本情報技術者試験程度の基本的な IT の知識があり、かつ Google Cloud に関する多少の業務経験を持っていることが望ましいです。公式ガイドには「6ヶ月以上の Google Cloud における実務経験」が推奨であると記載されていますが、必ずしもこれを満たしていなくても、十分合格を狙えます。 また普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、「Google の考えるクラウドらしさ」という、一種の「クラウド哲学」に慣れておくことが重要です。これに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。 推奨の勉強法 書籍や公式のトレーニングを受け Google Cloud の基本を理解する 試験ガイド を読み出題範囲を理解する 当記事を読み、出題傾向を理解する 理解した試験範囲・出題傾向をもとに勉強する 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする 上記のうち 1. の基礎学習については、書籍が日本語でいくつか出版されているのに加え、 Google Cloud Japan 社が定期的にセミナーなどを開催しています。 参考として、 Google Cloud Certification Jumpstart プログラム というプログラムがあります。以下のサイトでは、過去のセッション内容を動画で閲覧することができます。 参考 : 第 2 回 Google Cloud Certification Jumpstart プログラム 対策書籍 試験対策の書籍を使って学習するのも有用です。G-gen のエンジニアが執筆した、Associate Cloud Engineer 試験の対策書籍が出版されています。 合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 作者: 杉村 勇馬 , 佐々木 駿太 , 藤岡 里美 リックテレコム Amazon 更新試験 当試験には、初めて受験するときに受ける試験のほかに、更新時に受験できる 更新試験 があります。更新試験は、資格の有効期限の 60 日前から 30 日後までの間に受けることができます。 更新試験では、問題数、試験時間、受験費用が、初回試験に比べて小さくなっています。 項目 初回試験 更新試験 問題数 50～60問 20問 試験時間 120分 60分 受験費用 $125（税別） $75（税別） 更新試験は英語と日本語で受験することが可能です。 試験範囲については、初回試験と更新試験でほぼ同じですが、試験ガイドの「セクション 1: クラウド ソリューション環境の設定」は出題されません。 出題傾向 Associate Cloud Engineer 試験では以下のようなサービスが主題範囲です。 組織 / リソース アカウント（Cloud Identity / Google Workspace） Identity and Access Management（IAM） Virtual Private Cloud（VPC） Cloud DNS Google Cloud CLI（gcloud、bq） Compute Engine App Engine Cloud Run Google Kubernetes Engine（GKE） Cloud Storage データベース系サービス（Cloud SQL、Cloud Spanner、Bigtable、BigQuery) Cloud Monitoring / Cloud Logging 利用料金 当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきますので、参考にして各サービスの内容を押さえてください。わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。そのように勉強すれば、試験に合格できるのに加え、実践的な知識にもなります。 組織とリソース リソース階層の概念 Google リソースが階層構造となっていることを押さえておきましょう。最上位に 組織 があり、その下に フォルダ （入れ子構造も可能）、 プロジェクト 、そして個々の仮想マシン（VM）や BigQuery テーブルといった個別リソースが配置されるツリー構造となっています。 当社の内部資料から抜粋 組織やプロジェクト自体も、リソースの一種です。リソースは IAM ポリシーを持っていること、また IAM 権限は継承されることに留意しましょう。以下の記事も参照してください。 blog.g-gen.co.jp プロジェクトと API 有効化 Google Cloud を利用開始するには何が必要か、と考えたとき、少なくともプロジェクトを作成することは 必須 です。 また、 各サービスの API の有効化 の概念を理解してください。例えば Google Cloud プロジェクトで Spanner を利用開始するとき、最初にプロジェクトで API を有効化する必要があります。 参考 : Google Cloud プロジェクトでの API の有効化 組織のポリシー 組織のポリシー 機能を使うと、Google Cloud 組織全体で一定のルールを強制することができます。 blog.g-gen.co.jp 特に サービスアカウントキーの発行を禁止するポリシー は、よく用いられます。 参考 : 新しいサービス アカウント キーの作成を停止する制御を適用する IAM IAM の基本概念 Google Cloud の IAM （Identity and Access Management）は「 リソースに紐づけて設定する 」ものであり、また 継承の概念がある ことを正確に理解しましょう。IAM の概念については、以下の記事を参考にしてください。 blog.g-gen.co.jp これが理解できれば、例えば VM にアタッチされたサービスアカウントが プロジェクトを跨いで別のプロジェクトのリソースにアクセスするにはどうすればいいか という質問にも回答できます。 IAM ロールはアカウントではなくグループに付与 複数のドキュメントで繰り返し述べられているベストプラクティスとして、「 IAM ロールは、個別の Google アカウントではなく Google グループに付与するべきである 」というものがあります。 Google グループ は、Google アカウントをグルーピングするための仕組みで、Google Workspace または Cloud Identity に備わっています。 個別のアカウントにロールを付与してしまうと、その人が退職したり異動になるたびに多くのリソースに対して IAM のメンテナンスが必要になってしまいます。グループにアカウントを所属させて、そのグループに IAM ロールを付与するようにしましょう。 参考 : ポリシーの管理 基本ロールと事前定義ロール 基本ロールと事前定義ロールのいくつかを押さえておきましょう。基本ロールは以下の3つです。 閲覧者（ roles/viewer ） 編集者（ roles/editor ） オーナー（ roles/owner ） 基本ロールは権限が大きいため、 可能な限り利用を避けます 。事前定義ロールや、カスタムロールを使ってきめ細かい権限制御をしましょう。事前定義ロールは以下のドキュメントで確認できます。数が多すぎるので、もちろん全てを覚える必要はありません。 参考 : ロールについて サービスアカウント Compute Engine VM 上で稼働するプログラムから Google Cloud リソースにアクセスする際の認証・認可は、 サービスアカウント に権限を付与し、そのサービスアカウントを VM にアタッチすることで実現します。 Compute Engine にはデフォルトサービスアカウントが存在しますが、このデフォルトサービスアカウントよりも、ユーザー管理のサービスアカウントを新規作成して使用することが推奨されます。 参考 : ユーザー管理のサービス アカウントを使用する VM を作成する VPC VPC とサブネットの基本 VPC （Virtual Private Cloud）と サブネット の概念をきちんと理解します。以下の記事もご参考にお願いします。 Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い Google CloudのVPCを徹底解説！(基本編) 前者の記事で VPC の全体概要を掴み、後者の記事で詳細を深堀りして理解いただければ役に立つかと思います。 VPC の特に重要な仕様として、以下が挙げられます。 VPC の中に作ったサブネット間は自動的にルートが交換されるので、互いに通信できる サブネットはリージョンリソースである リージョンAに作ったサブネットAと、リージョンBに作ったサブネットBは互いに通信できる（ファイアウォールによる制限は可能） また、 VPC 自体は IP アドレス帯を持たず、サブネットが持ちます。VPC へのサブネット追加は容易にできますし、既存サブネットを拡張することができる（IP アドレス帯の追加）ということを押さえましょう。 セグメントとファイアウォールルール Google Cloud では、よく比較される Amazon Web Services（AWS）と比べると、細かく VPC やサブネットを分割しない傾向にあります。 ファイアウォールルールとネットワークタグを駆使して、いわゆる DMZ と内部ネットワークを分けることが第1選択肢です。とはいえ、全く通信させたくない環境同士は VPC を分けます。まずは、ファイアウォールルールの仕組みを正確に理解しておきましょう。 以下のようなことに回答できるようにしておいてください。 上り（Ingress）ルールと下り（Egress）ルールの概念 サービスアカウントまたはネットワークタグを使ってファイアウォールルールの適用対象インスタンスを指定する方法 デフォルト状態ではファイアウォールルールはどのような挙動をするのか ファイアウォールルールの適用対象 VM は、サービスアカウントまたはネットワークタグを使って指定できます。より厳密な制御のためには、ネットワークタグよりも サービスアカウントを使うことが推奨 されます。 参考 : サービス アカウントによるフィルタリングとネットワーク タグによるフィルタリング 限定公開の Google アクセス 限定公開の Google アクセス や Private Service Connect で何ができるかを押さえましょう。 blog.g-gen.co.jp blog.g-gen.co.jp 特にハイブリッドネットワーク（オンプレとクラウドを併用したネットワーク）でのユースケースを押さえます。Private Service Connect を使うと、Cloud Run services のような非 VPC リソースにも、オンプレミスから専用線経由でリクエストを受信することができます。 参考 : オンプレミスや他のクラウドからリクエストを受信する Cloud DNS Cloud DNS の基本的な機能を押さえてください。また Cloud DNS 以前に、一般的な DNS の仕組み、各レコードタイプの意味などは理解してください。 Cloud DNS では一般公開ゾーン（Public Zone）や限定公開ゾーン（Private Zone）を使うことができます。前者はインターネットから名前解決ができるゾーンであり、後者は Google Cloud の VPC の中などプライベートネットワークからのみ名前解決できるゾーンです。 参考 : 一般的な DNS の概要 Cloud Load Balancing Cloud Load Balancing は、フルマネージドのロードバランサーです。用途の異なる10種類のロードバランサーが存在しますので、どんなケースでどのロードバランサーを選択すべきかを押さえます。「外部 vs 内部」「グローバル vs リージョナル」「HTTP(S) vs TCP/UDP」などの観点で、適切なロードバランサーを選択してください。以下のドキュメントのディシジョン・ツリーの図が分かりやすいです。 参考 : ロードバランサを選択する また、ロードバランサーを実際にセットアップするときの、DNS との関係性を理解しましょう。ロードバランサーを作成すると、IP アドレスが払い出されます。その IP アドレスに対して DNS に A レコードを設定することで、ドメイン名でロードバランサーにアクセスできます。 参考 : ドメインをロードバランサに接続する Compute Engine 基礎知識 Compute Engine の基礎的な知識は、以下の記事を参考にして理解してください。 blog.g-gen.co.jp ディスク・バックアップ・リストア Persistent Disk （永続ディスク）に関する理解を深めておきましょう。 Persistent Disk からのインスタンス作成はどうすればよいのか、バックアップをスケジュールするにはどうすればよいか、などを公式ドキュメントから理解しておきます。 参考 : ディスク スナップショットのスケジュールを作成する 永続ディスクにはリージョン永続ディスクと、ゾーン永続ディスクがあります。これらの違いとユースケースも理解しておいてください。 参考 : Persistent Disk 購入オプション Compute Engine にはいくつかの購入方法があります。以下を、人に説明できるまで理解しておきます。 オンデマンド VM Spot VM 確約利用割引（CUD） 継続利用割引 Spot VM は非常にお得に見えますが、 強制終了 （プリエンプト）があることに留意します。 確約利用割引（CUD）や継続利用割引については、以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp コンピューティングサービス App Engine App Engine の強みが何かを押さえましょう。細かい仕様まで覚える必要はなく、どのようなサービスで、何を強みとしているかを理解してください。 リリースした複数のバージョン間でユーザトラフィックの割合を調整できるのも優れた機能の一つです。 参考 : トラフィックの分割 Google Kubernetes Engine（GKE） Google Kubernetes Engine （GKE） の基本的な概念と、操作方法（クラスタの操作や Depoloyment や Pod のデプロイ）を理解することが望ましいです。 クラスタ、ノードプール、ノード、Pod、Deployment、Service などの概念を理解してください。また、以下のような操作をコマンドラインで行う方法を把握しておいてください。 単一ゾーンのクラスタをマルチゾーンクラスタに変更する（ゾーンの追加） 既存クラスタに、従来と異なるマシンタイプのノードを追加する（新規ノードプールの追加） Horizontal Pod Autoscaling と Vertical Pod Autoscaling（recommendation）の使い方 以下の記事も参考にしてください。 blog.g-gen.co.jp Cloud Run Cloud Run の基本的な概念と、使うべきシーンを理解してください。 Cloud Run は、利用が小規模または散発的なワークロード、特に API バックエンドや Web アプリ（Single Page Application、SPA）などで利用できます。 以下の記事も参考にしてください。 blog.g-gen.co.jp また、 コールドスタート の概念も理解してください。コールドスタートを防ぐ最も簡単な方法は、最小インスタンス数を増やすことです。 blog.g-gen.co.jp コンピューティングサービスの使い分け App Engine、Cloud Run、Google Kubernetes Engine（GKE）はいずれもアプリケーションをホストするためのサービスです。 コンピューティングサービス と総称されることもあります。 どのようなときに 、 どのサービスを利用するのか を考えられるようにしておきましょう。 以下の記事を一読し、各サービスの特徴と使うべき場面を理解しておきましょう。 blog.g-gen.co.jp Cloud Storage Cloud Storage のユースケースも押さえてください。Cloud Storage はオブジェクトストレージですので、通常のファイルシステムとは特性も用途も異なります。安価でスケーラブルなので、非構造化データを含め、フォーマットもサイズも異なる多様なデータをクラウドに保存するために適した選択となります。 また、データの保存期間やアクセス頻度によって、どのストレージクラスを選ぶべきかを、しっかり押さえておきます。 頻繁にアクセスされる : Standard 1か月に1度 : Nearline 四半期に1度 : Coldline 年に1回未満 : Archive 以下のドキュメントが参考になります。 参考 : ストレージ クラス また以下の記事で Cloud Storage の詳細を解説していますので、是非参考にしてください。 blog.g-gen.co.jp データベース、データ分析 Cloud SQL 以下の当社記事を読んで、 Cloud SQL の基本的な機能を押さえます。 blog.g-gen.co.jp BigQuery 以下の記事を参考にして、 BigQuery の機能を一通り押さえておきます。 blog.g-gen.co.jp Spanner 以下の記事を参考にして、 Spanner の機能を一通り押さえておきます。「世界中からの大量のアクセスが見込まれる」「トランザクション処理が必要」「SQL の使用」などのキーワードがある場合は、Spanner のユースケースです。 blog.g-gen.co.jp データベースのベストな選択 以下の問いに答えられるようにしておきます。Google Cloud のデータベースサービスの特徴とユースケースを必ず押さえておきましょう。 大量の IoT センサーデータを格納し、低レイテンシで読み出すのに適したデータベースは？（BigTable） 複数のリージョンにまたがるトランザクションワークロードに適したデータベースは？ (Cloud Spanner) Web アプリケーションから使う NoSQL データベースは？（Firestore） 一般的なアプリケーションから MySQL や PostgreSQL などのリレーショナルデータベースを使いたいときは？（Cloud SQL） 大量のデータに対して SQL を使って分析を行いたいときは？（BigQuery） データパイプライン データパイプラインを実現するサービスである Dataflow の概要を理解しておきましょう。 blog.g-gen.co.jp Google Cloud Observability Cloud Monitoring Cloud Monitoring の基本機能は以下の記事で押さえることができます。 blog.g-gen.co.jp メトリクスを監視し、しきい値を超えたらアクションを起こす、という基本的な使い方を押さえます。アラートの通知先は「通知チャネル」として設定できます。 参考 : 通知チャネルの管理 Pub/Sub を通知先として設定できるので、アラートを契機にメッセージを Pub/Sub に送り、それをトリガに Cloud Functions を起動し、任意の宛先に通知を送ることもできます。 Cloud Logging 以下の記事で Cloud Logging の機能を把握する必要があります。 blog.g-gen.co.jp 特に Log Analytics 機能や シンク （ログルーター）の機能を把握してください。 Cloud Audit Logs 証跡管理機能である Cloud Audit Logs の基本を、以下の記事で押さえておきましょう。 blog.g-gen.co.jp Cloud Audit Logs には、Google Cloud APIs へのリクエストの履歴が記録されます。例えば Bigtable のように、API でデータの読み書きをするサービスの場合、設定によっては データの読み書き履歴を記録 することができます。 料金 請求先アカウント 請求先アカウント の概念は以下の記事で押さえておきましょう。 blog.g-gen.co.jp 予算アラート 請求先アカウントに対し、 予算アラート を仕掛けることができます。 参考 : 予算と予算アラートの作成、編集、削除 利用料金の見積とアーキテクチャ Google Cloud's pricing calculator を使って料金を見積もることができます。 ‐ 参考 : Google Cloud's pricing calculator パブリッククラウドでは、最適な利用料金となるよう考慮してアーキテクチャを設計するのも、アーキテクトの仕事になります。ある目的を達成するためのアーキテクチャは無数にありますが、その中でも最もコスト効率良く（Cost-effective に）実現する方法を編み出すことが求められます。 アーキテクチャを考えるとき、原則的には「マネージドサービスが使えるときは、マネージドサービスを使う。次点でコンテナ等、最後の選択肢として仮想サーバを選択する」と考えれば良いです。Cloud Run functions（旧 Cloud Functions）でアーキテクチャを実現すれば、Compute Engine の VM を常時起動させる必要がないのでコスト効率が良くなる、などが一例です。 利用料金データの BigQuery へのエクスポート 請求先アカウントから BigQuery へ請求データを自動エクスポートすることができます。 そのデータを、Looker Studio（旧称データポータル）で可視化して分析することもセオリーです。 参考 : Cloud Billing データを BigQuery にエクスポートする Access Approval Access Approval が何をするためのサービスなのか、また必要な IAM ロールは何かを押さえておきましょう。 Access Approval は Google のテクニカルサポート等がユーザーのコンテンツにアクセスする必要がある場合に、明示的な承認を経ないとアクセスできないようにすることができるサービスです。有効化すると、メールや Pub/Sub 通知で承認依頼が行われます。 Access Approval 承認者（ roles/accessapproval.approver ）ロールが付与されているアカウントのみが、承認を行うことができます。 参考 : Access Approval の概要 その他 Google Cloud の哲学 全体を通して、選択肢の絞り込みに迷った際は 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

G-gen の杉村です。 Google Cloud（旧称 GCP）の Security Command Center は、Google Cloud 環境の構成ミス、脆弱性、脅威を特定するための統合セキュリティプラットフォームサービスです。今回はこの Security Command Center を徹底解説します。 Security Command Center とは 料金ティア スタンダードティア プレミアムティア エンタープライズティア ティア別の機能一覧 料金 概要 プレミアムティアの料金 エンタープライズティアの料金 運用 運用体制 無効化とミュート Pub/Sub エクスポート Cloud Logging へのエクスポート Security Health Analytics Security Health Analytics とは 検出機能の例 3 つのスキャン Web Security Scanner Web Security Scanner とは 2 つのスキャン 検出結果 注意点 Anomaly Detection Event Threat Detection Event Threat Detection とは 検知内容の例 検査対象のログの有効化 カスタムモジュール Container Threat Detection Container Threat Detection とは 検知できる内容 Cloud Run Threat Detection Cloud Run Threat Detection とは 検知できる内容 Virtual Machine Threat Detection Virtual Machine Threat Detection とは 検知できる内容 VM の脆弱性レポート Cryptomining Protection Program Gemini（生成 AI）の利用 コンプライアンス評価 コンプライアンス標準とのマッピング 代表的なコンプライアンス標準 エンタープライズティアの機能 Compliance Manager Data Security Posture Management（DSPM） Security Command Center とは Security Command Center は Google Cloud 環境を自動的にスキャンして、構成ミスなどを自動検知して一覧化してくれる統合セキュリティプラットフォームサービスです。Security Command Center は SCC と略称される場合もあります。 Security Command Center は生成 AI とも統合されており、また有償の最上位プランであるエンタープライズティアでは、Google Cloud のみならず、Amazon Web Services（AWS）、Microsoft Azure も保護対象とすることができます。 参考 : Security Command Center の概要 参考 : Security Command Center の有効化の概要 Security Command Center は、無償で使える スタンダードティア 、有償の プレミアムティア 、マルチクラウドに対応し SIEM や SOAR の機能も付帯した エンタープライズティア の3種類の料金体系があります。 スタンダードティアとプレミアムティアの有効化範囲は「組織レベル」または「プロジェクトレベル」から選択することができます。なお Security Command Center を利用するには、Google Cloud 環境で組織（Organization）を構成している必要があります。 参考 : Security Command Center のサービスティア 料金ティア スタンダードティア 無償版であるスタンダードティアには、以下のような機能が含まれています。 機能名 種類 概要 Security Health Analytics 脆弱性 Google Cloud の ID（アカウント）や権限（IAM）、ネットワーク、データ管理などに関する設定ミス、危険な設定などを検知 Web Security Scanner 脆弱性 Web アプリケーションに対してクロールを行い、脆弱性を検知 Anomaly Detection 脆弱性 異常検知。サービスアカウントの漏洩や VM での不正な暗号通貨マイニングなど、通常と異なる挙動を特定 Sensitive Actions Service 脅威 Google Cloud 組織に対して行われたセンシティブなアクションを検知 継続的エクスポート 管理 Security Command Center の検知事項を Pub/Sub にエクスポート。自動通知や後続アクションに繋げる BigQuery との統合 管理 検出結果を BigQuery にエクスポート。分析に繋げる 上記は一部であり、詳細な一覧は以下のドキュメントをご参照ください。 参考 : スタンダード ティア プレミアムティア プレミアムティアでは、スタンダードティアのすべての機能に加えて、以下のような機能が含まれています。 機能名 種類 概要 強化された Security Health Analytics 脆弱性 Security Health Analytics の追加の検知事項と、CIS ベンチマークや PCI DSS などの業界標準への準拠機能が追加 攻撃パスシミュレーション 脆弱性 攻撃や情報の抜き取りが試みられる可能性のある経路を特定し、スコア付けして可視化 CVE 評価 脆弱性 検知された脆弱性に対して Mandiant（Google のセキュリティチーム）が評価する CVE 評価が付与される Notebook Security Scanner 脆弱性 Colab Enterprise ノートブックで使われている Python パッケージの脆弱性を検知 Event Threat Detection 脅威 機械学習等を活用して Cloud Logging や Google Workspace を監視し、マルウェア活動やデータ抜き取りなどの異常挙動を検知 Container Threat Detection 脅威 Google Kubernetes Engine（GKE）のコンテナに関する、不審なバイナリ実行やライブラリの読み込みなどの挙動を検知 Cloud Run Threat Detection 脅威 Cloud Run のコンテナに関する、不審なバイナリ実行やライブラリの読み込みなどの挙動を検知 Virtual Machine Threat Detection 脅威 ハイパーバイザレイヤからのメモリ検査等により、Compute Engine VM 内の悪意あるアプリケーションを検知 セキュリティポスチャー ポスチャー Google Cloud 環境全体のセキュリティステータスを、定義した基準に基づいてモニタリング コンプライアンス評価 管理 Google Cloud 環境を CIS Benchmark、ISO 27001、PCI DSS 等のコンプライアンス基準に基づいて適合状況を一覧化 Cloud Logging へのエクスポート 管理 検知事項を Cloud Logging に出力 上記は一部であり、詳細な一覧は以下のドキュメントをご参照ください。 参考 : プレミアム ティア エンタープライズティア Google Cloud はエンタープライズティアの Security Command Center を、 クラウドネイティブ アプリケーション保護プラットフォーム （CNAPP）と呼称しています。有償の最上位プランであるエンタープライズティアでは、Google Cloud のみならず、Amazon Web Services（AWS）、Microsoft Azure も保護対象とすることができ、1つのプラットフォームで複数クラウドのセキュリティ情報を統合管理できます。 エンタープライズティアには、スタンダードティアとプレミアムティアのすべてのサービスと機能に加えて、SIEM、SOAR、ケース管理機能、ハンドブック機能などが利用可能です。これらの追加機能は、 Google Security Operations （Google SecOps）によって提供されます。 SIEM は Security Information and Event Management の略です。各種 IT 製品やアプリケーションからログやイベント情報を集約し、リアルタイム分析を行うことでセキュリティ情報の収集、検知を行う仕組みのことです。 また SOAR は Security Orchestration, Automation and Response の略であり、セキュリティ運用の自動化を行う仕組みのことです。検知された脆弱性や不審な挙動に対して、Playbooks と呼ばれる自動ワークフローを用いた対処を行うことができます。 いずれも近年、情報セキュリティの分野で注目されているソリューションですが、これらを実装した Google 製品が Google SecOps です。本来は Google Cloud とは別製品として提供されている Google SecOps がバンドルされ、様々な機能と統合して利用できるのが、 Security Command Center のエンタープライズティアです。 参考 : エンタープライズ ティア ティア別の機能一覧 各ティアで利用できる機能の一覧と比較表は、以下の公式ドキュメントを参照してください。 参考 : Security Command Center のサービスティア - サービスティアの比較 料金 概要 Security Command Center のスタンダードティアは 無料 であり、プレミアムティアとエンタープライズティアは 有償 です。 スタンダードティアとプレミアムティアは 組織全体で有効化 するか、 プロジェクトレベルで有効化 するかを選択でき、プロジェクトレベルで有効化した場合は課金対象のリソース範囲を調整することができます。エンタープライズティアは、組織全体で有効化する必要があります。 参考 : Security Command Center pricing プレミアムティアの料金 Security Command Center プレミアムティアの料金は、対象のリソース数によって決定する従量課金です。以下のようなサービスの使用ボリューム（リソース数）に応じて課金が発生します。 サービス名 課金対象リソース Compute Engine CPU vCore / 時間 Google Kubernetes Engine（Autopilot） CPU vCore / 時間 Cloud SQL CPU vCore / 時間 App Engine（Standard） インスタンス / 時間 App Engine（Flex） CPU vCore / 時間 Cloud Storage Class A/B オペレーション数 BigQuery（オンデマンド） スキャンデータ TB 数 BigQuery（Editions） スロット / 時間 料金単価は、Security Command Center を組織レベルで有効化するかプロジェクトレベルで有効化するかによって異なります。例えば Compute Engine の vCPU コア数あたりの単価は、組織レベルでは $0.0057/hour、プロジェクトレベルでは $0.0071/hour です（いずれも2025年5月現在）。 最新の料金は以下の公式ページでご確認ください。 参考 : Security Command Center pricing なお上記の料金体系は、2023年6月8日のアップデートに伴い制定されたものです。それ以前は、プレミアムティアを組織レベルで有効化する場合「Google Cloud 全体の利用料金の 5 % または $15,000/年 の高い方」「1年または複数年のサブスクリプション」というものでした。2025年5月現在では、使用量ベースの課金が唯一の課金方法です。 参考 : Security Command Center release notes - June 08, 2023 エンタープライズティアの料金 エンタープライズティアの料金は、最低1年間のサブスクリプションです。 アセットという単位でクラウドリソースをカウントし、アセット数に応じた課金が発生します。ただし、最小課金金額は年間で $15,000 です。 見積もり方法については、以下の公式ドキュメントを参照し、必要に応じて Google Cloud や販売パートナーのの営業担当者と情報連携をしてください。 参考 : Pricing for the Enterprise tier 運用 運用体制 原則的に、Security Command Center を有効化しただけではセキュリティリスクを 検知することしかでき ません。 検知内容を正しく理解して Google Cloud の設定をセキュアな状態に変更するなど、 通知されたリスクに具体的に対処する運用体制 が必要になります。 しっかりしたスキルに基づく運用体制を築いたり、自動対処の仕組みを構築しない限り、Security Command Center が「オオカミ少年」（通知が繰り返されることでノイズとして捉えられてしまい、本当にリスクが高い検知が行われたときにも必要な対処が取られなくなってしまう状態の比喩）になってしまうことに注意が必要です。 適切な運用体制とフローを確保し、通知内容に対する適切な対処を継続的に行うことで初めて、Security Command Center は価値を発揮します。 無効化とミュート Security Command Center の検出結果は、 無効化 または ミュート できます。 検知された脆弱性や脅威への対処が完了した場合、その検知結果を 無効化する （ Inactive 状態にする）ことで、検知結果が表示されなくなります。一度無効化しても、同じ項目が再度検知されると、検知結果は再び有効化され（ Active 状態になり）ます。 なお検知結果への対処が完了しても、自動的に無効化されるのは Security Health Analytics と VM Manager の検知事項 だけ です。ただし、次回のスキャンで脆弱性が修復されたことが検知されるまで時間がかかる場合があります。また、それ以外の多くの脆弱性や脅威の検知結果は自動的に無効化されることはないため、 手動で無効化 する必要があります。 参考 : 検出結果の状態 参考 : コンソールで検出結果を確認して管理する - 検出結果の状態を変更する 参考 : 脅威の調査と対処 - 脅威の検出の無効化 一方で、検知結果が偽陽性だった場合、つまり実際には無害もしくは無視して良いにも関わらず検知された場合は、検知結果を ミュートする こともできます。検知結果をミュートすると、無効化した場合と同様に一覧に表示されなくなりますが、検知結果は有効化（ Active ）状態として残り、手動操作により再表示させることができます。 また、 ミュートルール を作成することで、所定の条件を満たした検知結果を自動的にミュートすることができます。またミュートルールでは、ミュートを永続的にしたり、あるいは期限を決めた一時的なミュートとすることもできます。 参考 : Security Command Center の検出結果をミュートする Pub/Sub エクスポート Pub/Sub への 継続エクスポート 機能を利用することで、Security Command Center の検出結果を Pub/Sub に自動的にエクスポートすることができます。Pub/Sub へのエクスポートは、すべてのティアで利用できます。 ほぼリアルタイムで指定した Pub/Sub トピックに検出結果がエクスポートされ、外部ツールなどに連携したり、オペレーターへの発報に使用できます。 参考 : 継続的エクスポート Cloud Logging へのエクスポート 検知事項を Cloud Logging にログとしてエクスポートできます。検知事項を Cloud Logging にエクスポートすることで、後々の Cloud Logging での分析や、ログアラートを用いた発報を容易に実装できます。 Cloud Logging へのエクスポートは、 プレミアムティア以上 で使用できます。 参考 : ログを Cloud Logging にエクスポートする Security Health Analytics Security Health Analytics とは Security Health Analytics は、Google Cloud 環境を自動的にスキャンし、設定ミスやセキュアでない設定など、攻撃対象となる可能性となる構成を検知する機能です。 Security Health Analytics は、スタンダードティアを含む すべてのティアで利用可能 ですが、すべての検知項目を利用するにはプレミアムティア以上への登録が必要です。 また、プレミアムティア以上では、カスタム検出モジュールを作成したり、攻撃パスシミュレーション（想定される攻撃ルートや発生可能性スコア等）を表示できます。 参考 : Security Health Analytics の概要 検出機能の一覧は、以下の公式ドキュメントに記載されています。以下のドキュメントでは検出機能ごとに、どのような機能なのか、スタンダードティアで利用可能なのか、プレミアムティアへの登録が必要なのか、またリアルタイムスキャンが行われるのか、などが一覧化されています。 参考 : Security Health Analytics の検出結果 なおバックエンドでは Google Cloud リソースのメタデータを管理する仕組みである Cloud Asset Inventory という仕組みが使われています。また、Security Health Analytics で検査対象の対象となるサービスは以下の通りです。 Cloud Monitoring and Cloud Logging Compute Engine Google Kubernetes Engine containers and networks Cloud Storage Cloud SQL Identity and Access Management（IAM） Cloud Key Management Service（Cloud KMS） Cloud DNS 参考 : サポートされている Google Cloud クラウド サービス 検出機能の例 以下に、スタンダードティアで検知可能な項目の例をリストアップします。プレミアムティアではさらに多数の検出機能があります。 項目名 概要 PUBLIC_COMPUTE_IMAGE Compute Engine イメージが一般公開されてしまっている OPEN_SSH_PORT VPC ファイアウォールで 22/TCP や 22/SCTP ポートが開いている NON_ORG_IAM_MEMBER @gmail.com メールアドレスのアカウントに IAM 権限が付与されている MFA_NOT_ENFORCED Google Workspace（Cloud Identity）に MFA が有効になっていないユーザーが存在 PUBLIC_BUCKET_ACL 一般公開されている Cloud Storage バケットが存在する PUBLIC_DATASET 一般公開されている BigQuery データセットが存在する 上記は例であり、検出機能の一覧は、以下の公式ドキュメントに記載されています。 参考 : Security Health Analytics の検出結果 3 つのスキャン Security Health Analytics は以下の 3 つのモードでスキャンを実行します。 バッチスキャン（1日に1回、自動で組織またはプロジェクトがスキャン） リアルタイムスキャン（リソースの変更を検出してスキャン） 混合モード（バッチとリアルタイムの混合） 検出項目によって、どのスキャンが用いられるかが異なりますが、いずれも自動的に行われます。前掲の検出機能一覧ドキュメントに、対応しているスキャンタイミングが記載されています。 Web Security Scanner Web Security Scanner とは Web Security Scanner は Compute Engine や App Engine（GAE）、Google Kubernetes Engine（GKE）でホストされている Web アプリケーションに対して、アプリケーションレベルの脆弱性スキャンをかける機能です。 ただし、スキャンできる対象はインターネットに公開されている Web アプリのみであり、ローカルネットワーク内で使われる社内システム等には使用できません。 参考 : Web Security Scanner の概要 2 つのスキャン Web Security Scanner には、 マネージドスキャン と カスタムスキャン の2種類があります。 マネージドスキャンは、週に1回実行される自動的なスキャンです。認証なし、 GET リクエストのみ、という制限があります。マネージドスキャンは、 プレミアムティア以上 で利用できます。 カスタムスキャンは、手動実行によるスキャンです。認証情報を用いて検査ができます。 スタンダードティアでも使用できます が、一部機能が制限されています。 検出結果 OWASP Top 10 に準じた検出を行うことができます。以下のドキュメントに、検出結果の一覧があります。 参考 : 検出結果のタイプ 例として以下のようなものがあります。 項目名 概要 OUTDATED_LIBRARY 既知の脆弱性があるライブラリが検出された SERVER_SIDE_REQUEST_FORGERY サーバー側のリクエスト フォージェリ（SSRF）の脆弱性が検出された XSS このウェブ アプリケーションのフィールドは、クロスサイト スクリプティング（XSS）攻撃に対して脆弱である 注意点 スキャンを実行すると、フォームへの入力、ボタン押下、リンクへのアクセスなど、一般ユーザーの動きを模したリクエストが行われます。そのため、 本番環境に思わぬ破壊的な結果 を及ぼすおそれもゼロではありません。ただし、これは Security Command Center だけに言えることではなく、通常の脆弱性診断でも同じです。 公式ドキュメントでは、ベストプラクティスとして以下が紹介されています。 まず、テスト環境でスキャンを実行 テストアカウントの利用すること CSS クラス inq-no-click の利用 スキャン前にバックアップを取得すること テストを行わない URL パターンを明示的に指定すること 参考 : ベスト プラクティス Anomaly Detection Anomaly Detection （異常検出）とは、認証情報の漏洩など、異常な挙動を検知できる仕組みです。 組織レベル で Security Command Center を有効化すると、 すべてのティア で自動的に Anomaly Detection が有効化されます。プロジェクトレベルでの有効化では、異常検出はサポートされません。 例として、 account_has_leaked_credentials という検知項目では、サービスアカウントの認証情報がオンラインに流出したことを検知してくれます。 参考 : 検出サービス - 異常検出 Event Threat Detection Event Threat Detection とは Event Threat Detection は、Cloud Logging および Google Workspace ログを監視し、機械学習等により検査することで、ニアリアルタイムで脅威を検知する仕組みです。 Event Threat Detection は プレミアムティア以上 で利用することができます。 参考 : Event Threat Detection の概要 「BigQuery からのデータの持ち出し」「VM 上のマルウェアによる通信」「Google Workspace グループの安全でない権限設定」「政府に支援された攻撃と疑われるアクション」などを検知することができます。 検出結果は Security Command Center コンソール等で確認できる他、Cloud Logging に出力されたり、Pub/Sub にパブリッシュしたりできるため、後続アクションの自動化などにも繋げられます。 前述の Security Health Analytics が Cloud Asset Inventory の構成情報を元に検査するのに対して、Event Threat Detection は、Cloud Logging や Google Workspace のログを検査してアクティビティを検知する点が異なります。 検知内容の例 以下のドキュメントに、検知可能な内容がリストされています。 参考 : Event Threat Detection のルール 以下は、検知事項の一部抜粋です。 項目名 概要 DATA_EXFILTRATION_BIG_QUERY BigQuery からデータが組織外へコピーされる等。 Cloud Audit Logs から検知 MALWARE_BAD_DOMAIN マルウェア通信と疑われるドメインへの通信。 Cloud DNS のログから検知 ANOMALOUS_ACCESS Tor など匿名化されたプロキシの IP から Google Cloud リソースが変更された。 Cloud Audit Logs から検知 BRUTE_FORCE_SSH VM の SSH にブルートフォース攻撃。 Cloud Logging にエクスポートされた syslog から検知 SUSPICIOUS_LOGIN 疑わしいログインが発生。 Google Workspace ログから検知 2SV_DISABLE ユーザーが 2 段階認証を無効化した。 Google Workspace ログから検知 検査対象のログの有効化 Event Threat Detection は、 Google Workspace のログや Cloud Logging のログを使って脅威を検知します。 Cloud Audit Logs の管理アクティビティ監査ログ（Admin Activity audit logs）がデフォルトで有効化されており Cloud Logging に出力されるので、何も設定しなくても自動的に検知対象になります。 しかし、以下のようなログは必要に応じて ON にする必要があります。 SSH logs、syslog（Ops Agent / Cloud Logging Agent 経由で Cloud Logging にエクスポート） データアクセス監査ログ（Cloud Audit Logs） VPC flow logs Cloud DNS logs Firewall Rules logs Cloud NAT logs これらのログは明示的に有効化しないと出力されません。出力されていない場合は、 Event Threat Detection の検査対象にもなりません。出力により Cloud Logging の料金が増える可能性を理解しつつ、必要に応じて有効化を検討します。 Cloud Audit Logs については以下の記事で解説していますので、ご参照ください。 blog.g-gen.co.jp またログ出力先となる Cloud Logging については以下の記事で解説していますので、ご参照ください。 blog.g-gen.co.jp カスタムモジュール Event Threat Detection の カスタムモジュール （Custom modules）は、ユーザーが独自の脅威検出ロジックを定義し、Event Threat Detection に組み込むことができる機能です。 参考 : Event Threat Detection 用カスタム モジュールの概要 Event Threat Detection では、マルウェア、クリプトマイニング、不正な権限昇格、データ抜き取りの試みなど、さまざまな脅威を検出するための 組み込みモジュール が提供されるものの、組み込みで提供されていない要件の検知を行いたい場合に、このカスタムモジュールを使います。詳細は以下の記事も参照してください。 blog.g-gen.co.jp Container Threat Detection Container Threat Detection とは Container Threat Detection は、Google Kubernetes Engine（GKE）ノードのモニタリングを行い、ノード上の変更やコンテナランタイム上の不審な挙動をニアリアルタイムで検知します。コンテナノードで実行されるバイナリやコンテナにロードされるライブラリを検査したり、 NLP（自然言語処理）による bash スクリプトや Python コードの検査などが行われます。 Container Threat Detection は プレミアムティア以上 で利用できます。 参考 : Container Threat Detection の概要 サポートしている GKE のバージョン等は、以下のドキュメントを参照してください。 参考 : サポートされている GKE バージョンの使用 検知できる内容 Container Threat Detection では、以下のような内容を検知できます。 項目名 概要 Added Malicious Binary Executed オリジナルのコンテナイメージに無く、既知の悪意あるバイナリが実行された Added Malicious Library Loaded オリジナルのコンテナイメージに無く、既知の悪意あるライブラリがロードされた Malicious Script Executed 悪意ある bash スクリプトが実行された Reverse Shell リモートのソケットへのストリームリダイレクションを行うプロセスが開始された Malicious URL Observed 悪意ある URL を引数とするプロセスが起動している 参考 : Container Threat Detection の概要 - Container Threat Detection 検出器 Cloud Run Threat Detection Cloud Run Threat Detection とは Cloud Run Threat Detection は、Cloud Run のコンテナランタイム上の不審な挙動を検知します。Container Threat Detection と同様、コンテナノードで実行されるバイナリやコンテナにロードされるライブラリが検査されます。 Cloud Run Threat Detection は プレミアムティア以上 で利用できます。 Cloud Run Threat Detection は、Cloud Run services と Cloud Run jobs に対応しています。 参考 : Cloud Run の脅威検出の概要 以下の記事も参考にしてください。 blog.g-gen.co.jp 検知できる内容 Cloud Run Threat Detection では、以下のような内容を検知できます。 項目名 概要 Added Malicious Binary Executed オリジナルのコンテナイメージに無く、既知の悪意あるバイナリが実行された Added Malicious Library Loaded オリジナルのコンテナイメージに無く、既知の悪意あるライブラリがロードされた Malicious Script Executed 悪意ある bash スクリプトが実行された Reverse Shell リモートのソケットへのストリームリダイレクションを行うプロセスが開始された Malicious URL Observed 悪意ある URL を引数とするプロセスが起動している 参考 : Cloud Run の脅威検出の概要 - 検出項目 Virtual Machine Threat Detection Virtual Machine Threat Detection とは Virtual Machine Threat Detection とは、ハイパーバイザレイヤからのメモリ検査や、ディスククローンの検査により、Compute Engine VM 内のマルウェアや仮想通貨マイニングを検知できる機能です。 Virtual Machine Threat Detection は、 プレミアムティア以上 で利用できます。 参考 : Virtual Machine Threat Detection の概要 検知できる内容 Virtual Machine Threat Detection で検知可能なのは、暗号通貨マイニング、カーネルモードルートキット、マルウェアです。 詳細は以下のドキュメントを参照してください。 参考 : 検出 VM の脆弱性レポート VM Manager の脆弱性レポート 機能では、Security Command Center と Compute Engine の運用自動化ツールである VM Manager が連携して、エージェントにより VM 内をスキャンすることで OS レベルの脆弱性を検知することができます。 VM Manager の脆弱性レポートは プレミアムティア以上 で利用できます。 2025年5月現在では Preview 公開であることにご留意ください。 詳細は、以下のドキュメントを参照してください。 参考 : 脆弱性の検出結果 - VM Manager Cryptomining Protection Program Security Command Center Cryptomining Protection Program は、Security Command Center プレミアムティアおよびエンタープライズティアのユーザに Google から提供される、補償プログラムです。 このプログラムに参加すると、Compute Engine VM 環境や Google Kubernetes Engine 環境において万が一クリプトマイニング（Crypto Mining、仮想通貨をマイニングするために不正にコンピュートリソースを使用する攻撃）が行われてしまった場合において、Security Command Center Premium を適切に設定していたのにも関わらず検知されなかった場合、Google Cloud クレジットでの補填を受けることができます。 プログラムの参加要件などの詳細は、以下のドキュメントをご参照ください。 参考 : Security Command Center Cryptomining Protection Program Gemini（生成 AI）の利用 Security Command Center には、Google が開発した生成 AI ソリューションである Gemini が組み込まれています。 Gemini との連携機能が使えるのは、 プレミアムティア以上 です。 機能名 利用可能なティア 概要 検出結果と攻撃パスの Gemini の概要 プレミアム、 エンタープライズ 検知事項に対して攻撃経路のシミュレーションを動的に生成、提示 自然言語検索による 脅威調査 エンタープライズ Google SecOps 上で検出結果、アラート、その他の情報を自然言語で検索 ケースの AI 調査ウィジェット エンタープライズ Google SecOps 上でインシデントケースの概要と次のステップの表示 参考 : Security Command Center の Gemini の機能 コンプライアンス評価 コンプライアンス標準とのマッピング プレミアムティア以上 の Security Command Center では、検知機能により検出された結果を、以下のようなコンプライアンス標準規格にマッピングすることができます（一部抜粋）。 CIS Benchmark ISO 27001 PCI DSS OWASP Top 10 NIST 800-53 検出結果がどのセキュリティ標準規格に違反している可能性があるかは、コンソール画面に表示されます。 検知内容がどの標準規格に関係するか右側の列に表示されている また以下のスクリーンショットのように、コンプライアンス標準の項目と検知事項の対照表も表示できます。検知事項を1つずつ消し込んでいくことで、標準に準拠した状態に近づけることができます。 コンプライアンス標準の項目と検知事項の対照表 参考 : セキュリティ標準のコンプライアンスを評価して報告する 代表的なコンプライアンス標準 CIS ベンチマーク は、 CIS (Center for Internet Security 、米国の 国家安全保障局 (NSA) や米国立標準技術研究所 (NIST) 、学術団体などが設立した非営利団体) が定義するベンチマークです。 Amazon Web Services (AWS) における Security Command Center の類似サービスである AWS Security Hub でも、セキュリティ基準として利用されています。 PCI DSS はクレジットカード情報を扱うためのグローバルなセキュリティ基準です。 クレジットカードを扱うシステムに関わった方であれば、一度は耳にし、認証取得に苦労したこともあるでしょう。 OWASP Top 10 は米国の非営利団体である OWASP Foundation が定期的に発行しているセキュリティレポートで、日本でも広く参照されています。 この団体から提供されているオープンソースの脆弱性診断ツールである OWASP ZAP は、セキュリティの教則本でもハンズオンに利用されているのをよく目にします。 NIST 800-53 は米国の政府機関である米国立標準技術研究所 (NIST) が、米国連邦政府の情報システムのセキュリティ基準として定義したものです。 ISO 27001 は日本で ISMS として知られる認証の国際規格として有名ですね。 Security Command Center では各種の検知結果がこのようなコンプライアンス標準にマッピングされるので、認証取得などに向けて環境を整備したり、継続的なモニタリングを行うことができます。 エンタープライズティアの機能 Compliance Manager Compliance Manager は、CIS Benchmark、ISO 27001、NIST などのコンプライアンス標準に基づき、設定のデプロイを行ったり、標準への準拠状況をダッシュボード化したり、監査レポートを出力するための機能です。 Compliance Manager は組織レベルで有効化された エンタープライズティア でのみ利用可能であり、プレミアムティア以上で使用可能なコンプライアンス評価機能の上位版の位置づけです。 管理画面から Compliance Manager を有効化すると、併せて Sensitive Data Protection、Event Threat Detection、Data Security Posture Management（DSPM）なども有効化され、多くの Security Command Center 機能と連携して動作します。 詳細は以下の公式ドキュメントを参照してください。 参考 : Compliance Manager overview Data Security Posture Management（DSPM） Data Security Posture Management （DSPM）は、Google Cloud 上のデータの種類、保存場所、セキュリティ基準やベストプラクティスへの準拠状況を把握するための機能です。 DSPM には データセキュリティダッシュボード が含まれています。このダッシュボードでは、組織のデータがセキュリティやコンプライアンスの要件に適合しているかを確認できます。データのロケーション（リージョン）、プロジェクト、Google Cloud プロダクトなどでフィルタリングして一覧表示することもできます。 また データセキュリティフレームワーク では、BigQuery での CMEK（顧客管理の秘密鍵）の利用状況や、Cloud SQL インスタンスの公開アクセスの状況などの基本的な設定状況を監視・検出できるほか、指定したプリンシパル以外のデータへのアクセス状況、国外からのアクセス状況、最大保持期間ポリシーの違反状況などを検出できます。 DSPM には、その他にもデータのセキュリティを維持するための機能があります。詳細は以下の公式ドキュメントを参照してください。 参考 : Data Security Posture Management (DSPM) overview 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。Google Cloud（旧称 GCP）のクラウド型 WAF である Google Cloud Armor について、概要や特徴を記載します。 Cloud Armor とは Cloud Armor の概要 WAF 機能 料金 料金ティア Standard ティア Enterprise ティア セキュリティポリシー セキュリティポリシーとは セキュリティポリシーをアタッチできる対象 3種類のセキュリティポリシー ルールとは ルールのプレビューモード 名前付き IP アドレスリスト ルールの記述 階層型セキュリティポリシー DDoS 対策 DDoS 保護機能 DDoS 対応サポート DDoS 請求保護 Adaptive Protection（適応型保護） Adaptive Protection とは アラート 自動生成ルールの適用 DDoS 攻撃の可視化 レート制限 Bot 管理 運用・ロギング WAF の運用作業 Cloud Armor のログ出力 運用のベストプラクティス Cloud Armor とは Cloud Armor の概要 Google Cloud Armor （以下、Cloud Armor）はクラウド型の Web Application Firewall （以下、WAF）であり、フルマネージドサービスです。 WAF とは Web アプリケーションに対する SQL インジェクション、クロスサイトスクリプティングといったアプリケーションレイヤの攻撃を検知し、防御するための仕組みです。加えて、Cloud Armor には DDoS 攻撃への防御機能も持っています。 Cloud Armor が保護できるのは、原則として Google Cloud のロードバランサーである Cloud Load Balancing の背後にある Web アプリケーション です。対応しているロードバランサーの種類は後述します。また、一定の制限のもとであればパブリック IP を持っている VM に直接ルールをアタッチすることもできます（ネットワークエッジセキュリティポリシー）。こちらについても後述します。 参考 : Google Cloud Armor の概要 WAF 機能 Cloud Armor の最も基本的な機能は「セキュリティポリシー」を設定することで、Web アプリケーションをアプリケーションレイヤ（L7）の攻撃から保護することです。 WAF ルールは Common Expression Language （CEL）と呼ばれるカスタムルール言語で記述します。 簡単な記述で OWASP Top 10 などの攻撃を緩和する事前構成ルールを呼び出すことができるため、複雑なシグネチャを自前で書く必要はありません。 なお OWASP Top 10 とは、米国の非営利団体である Open Worldwide Application Security Project（OWASP）が定期的に公開している、Web アプリケーションに関する重大なリスクのランキングです。Web アプリのセキュリティリスクを評価する際に、広く参照されています。 参考 : OWASP Top Ten 料金 料金ティア Cloud Armor には Cloud Armor Standard と Cloud Armor Enterprise の2つの料金ティアがあります（Enterprise は以前は Managed Protection Plus と呼ばれていましたが、2024年4月に改称しました）。 Standard ティアでは通常の WAF の機能であるアプリケーションレイヤ（レイヤ 7）へのルールベースの防御機能に加え、一部の Cloud Load Balancing に対する DDoS 攻撃への防御機能を備えています。 Enterprise ティアでは Standard ティアの機能に加えて、以下のような機能を備えています。 Google が管理するサードパーティの IP アドレスリスト Google が管理する Threat Intelligence（脅威情報）による防御機能 Adaptive Protection（適応型防御。機械学習を活用した脅威検知） 追加の DDoS 防御機能 詳細については、以下の公式ドキュメントも参考にしてください。 参考 : Cloud Armor Enterprise overview Standard ティア Cloud Armor の Standard ティアは、以下の 3 軸で料金が計算される、従量課金制です。 処理するリクエスト数（グローバルスコープのポリシーの場合、$0.75/100 万件） セキュリティポリシー数（$5/件） ルール数（$1/件） 上記に記載の料金は2025年7月現在の単価です。最新の料金は、以下の公式ドキュメントをご参照ください。 参考 : Google Cloud Armor pricing Enterprise ティア Enterprise ティアには、 Paygo （Pay as you go、従量課金）と Annual （年間サブスクリプション）の2種類から、課金方法を選択できます。この2つの間では受けられるサービスが一部異なります。 PayGo では、プロジェクトごとに$200/月の基本料金が発生し、さらに保護対象リソースごとに追加の料金が発生します。Annual だと、請求先アカウントごとに $3000/月の基本料金と、保護対象リソースごとの追加料金が発生します。 料金や課金方法の詳細は、以下の公式ドキュメントをご参照ください。 参考 : Google Cloud Armor pricing 参考 : Cloud Armor Enterprise overview セキュリティポリシー セキュリティポリシーとは Cloud Armor の セキュリティポリシー とは、防御ルールの定義のことです。セキュリティポリシーを作成して、外部 HTTP(S) ロードバランサの バックエンドサービス にアタッチすることで、ルールが効果を発揮します。 参考 : セキュリティ ポリシーの概要 セキュリティポリシーには、以下のような設定を持たせることができます。 個別ルール（IPアドレス範囲リスト / カスタムルール言語） デフォルトアクション（拒否 / 許可） Adaptive Protection の有効 / 無効 アタッチ先のバックエンドサービス セキュリティポリシーをアタッチできる対象 セキュリティポリシーは、ロードバランサー（Cloud Load Balancing）を使っている VM 等を保護対象にすることができます。 セキュリティポリシーの位置づけ 後述するようにセキュリティポリシーには「バックエンドセキュリティポリシー」「エッジセキュリティポリシー」「ネットワークエッジセキュリティポリシー」の3種類あります。それぞれポリシーをアタッチ可能な対象リソースが決まっており、例として、バックエンドセキュリティポリシーは以下のリソースにアタッチすることができます。 Global external Application Load Balancer Classic Application Load Balancer Global external proxy Network Load Balancer Classic proxy Network Load Balancer Regional external Application Load Balancer Regional internal Application Load Balancer 3種類のセキュリティポリシー セキュリティポリシーには以下の3種類があります。 バックエンドセキュリティポリシー エッジセキュリティポリシー ネットワークエッジセキュリティポリシー バックエンドセキュリティポリシー は、エッジロケーション (Google のキャッシュサーバー) からバックエンドにルーティングされたリクエストを評価します。つまり、キャッシュヒットしなかったリクエストや動的コンテンツなどが対象です。エッジからキャッシュで返されるリクエストは評価対象になりません。 エッジセキュリティポリシー は、エッジからキャッシュを 返す前 に評価され、ルールが適用されます。Cloud CDN を有効化したバックエンドや Cloud Storage バケットが対象となります。 ネットワークエッジセキュリティポリシー は、ロードバランサーを使わない VM にも利用可能なポリシーです。接続元 IP アドレスなどによる制限をかけ、Google のネットワークのエッジでブロックすることができます。これにより不正アクセスや DDoS が VM のネットワークリソースを消費することを防ぐことができます。 これら3つのポリシーは併用することも可能です。 またそれぞれのポリシーで利用可能な機能が異なっています。詳細は公式ガイドをご参照ください。 参考 : セキュリティ ポリシーの種類 ルールとは セキュリティポリシー内には複数の ルール を設定できます。ルールは優先度順に評価され、ルールに合致するとそれより低い優先度のルールは評価されません。 ルールには、基本モードと詳細モードの2つのモードがあります。 モード名 概要 基本モード IP アドレスに基づいてトラフィックを許可または拒否 詳細モード Common Expression Language（CEL）で記述したカスタムルールに基づいてトラフィックを許可または拒否 IP アドレスによる制限であれば基本モードのルールを、SQL インジェクションなどの L7 攻撃を防ぐには詳細モードのルールを作成します。 詳細モードのルールではカスタムルール言語を使って記述する必要がありますが、 Google が作成・管理する 事前構成 WAF ルール （または事前構成されたルール、Preconfigured rules）を呼び出すことで、簡単な記述で防御ルールを作成することができます。 また詳細モードのルールでは、IP アドレスから推測する地理的情報や、bot を防ぐためのルール、レート制限など、多様なルールが定義可能です。 参考 : セキュリティ ポリシーのルールを管理する 参考 : ルールの種類 Google 事前構成ルールはオープンソースの ModSecurity Core Rule Set が元になっています。 参考 : GitHub - coreruleset ルールのプレビューモード ルールは プレビュー モードにすることができ、実際にトラフィックを拒否せずに、ログの記録だけをさせることもできます。一般的にドライランやロギングモードと呼ばれる機能です。 参考 : プレビュー モード 名前付き IP アドレスリスト 名前付き IP アドレスリストとは、サードパーティの CDN (Contents Delivery Network) プロバイダが管理する IP アドレスのリストです。2025年7月現在では Fastly、CloudFlare、Imperva が名前付き IP アドレスリストを提供しています。 これらの CDN を利用している場合は、セキュリティポリシーにて名前付き IP アドレスリストを許可対象として指定し、その他をブロックすることで、 CDN 以外からのアクセスをブロックすることができます。 ただし、名前付き IP アドレスリストは通常版（Standard）では使用できません。追加料金を支払い、Cloud Armor Enterprise ティアに登録する必要があります。 参考 : 名前付き IP アドレスリストの可用性 参考 : IP アドレスリスト プロバイダ ルールの記述 詳細モードのルールでは前述の通り、カスタムルール言語を使ってルールを記述する必要があります。 この言語を使って、 Google の 事前構成 WAF ルール （または事前構成されたルール、Preconfigured rules）を呼び出すのが基本的な使い方となります。 以下は、最も簡単な例です。 SQL インジェクションを防ぐ事前構成ルールを呼び出しています。 evaluatePreconfiguredExpr('sqli-stable') ただし、この書き方だと、事前構成ルール sqli-stable に含まれている全ての SQL インジェクション対策のシグネチャが反応してしまいます。偽陽性（正当なリクエストであるのにも関わらず、不正リクエストとして検知されてしまうこと）が起こりやすい状態です。偽陽性の可能性を下げるために、感度レベルの高いシグネチャを無効化するよう指定することができます。 # ルール名の後に無効化するシグネチャ名を入力 evaluatePreconfiguredExpr('sqli-stable', ['owasp-crs-v030001-id942421-sqli', 'owasp-crs-v030001-id942432-sqli']) また || （2つのパイプ）を使ってルールを OR 条件で繋げることができます。以下のようにルールを数珠つなぎにしてアクションを ブロック にすれば、1つのルールの中で複数の事前構成ルールを呼び出すことができます。 evaluatePreconfiguredExpr('xss-stable') || evaluatePreconfiguredExpr('sqli-stable') 事前構成 WAF ルールの一覧や設定方法は、以下のドキュメントを参照してください。 参考 : Google Cloud Armor の事前構成 WAF ルールの概要 参考 : 事前構成された WAF ルールを設定する 参考 : Google Cloud Armor の事前構成 WAF ルールを調整する 階層型セキュリティポリシー 階層型セキュリティポリシー （階層型バックエンドセキュリティポリシー）は、組織、フォルダ、プロジェクトなどの組織階層に紐づけることで、その階層の配下にあるバックエンドサービスをすべて保護できるポリシーです。 通常のセキュリティポリシーポリシーはプロジェクトに作成してバックエンドサービスに紐づけますが、階層型セキュリティポリシーは、 組織またはフォルダのレベル に作成し、組織、フォルダ、プロジェクトのいずれかに紐づけます。紐づけると、その配下にあるすべてのバックエンドサービスにポリシーが適用されます。対象は、グローバル外部アプリケーションロードバランサと、従来の（Classic）アプリケーションロードバランサです。紐づけ時に、適用対象から除外するプロジェクトを指定することも可能です。 階層型セキュリティポリシーは Google Cloud Armor Enterprise の機能です。階層型セキュリティポリシーが適用されたプロジェクトは、自動的に Google Cloud Armor Enterprise の PayGo（従量課金）に登録されますので、費用に注意が必要です。 参考 : Hierarchical security policies overview DDoS 対策 DDoS 保護機能 Cloud Armor には DDoS 保護機能 が備わっています。Standard ティアと Enterprise ティアの両方で DDoS 対策機能が利用可能ですが、Enterprise ティアではより保護範囲が広くなり、また Adaptive Protection（適応型保護）などの機能が提供されます。 各ティアの DDoS 対策の範囲は以下のとおりです。 Standard Enterprise ・External Application Load Balancer ・External proxy Network Load Balancer ・External Application Load Balancer ・External proxy Network Load Balancer ・External passthrough Network Load Balancer ・Protocol forwarding ・Public IP addresses (VMs) 参考 : Cloud Armor Enterprise の概要 DDoS 対応サポート Cloud Armor Enterprise の年間サブスクリプションへの登録に加え、Google Cloud カスタマーケアのプレミアムにも登録している場合、 DDoS 対応サポート （DDoS response support）を利用することができます。 DDoS 対応サポートでは Google の DDoS 対策チームと連絡を取り、支援を受けることができます。 参考 : DDoS 対応サポート DDoS 請求保護 Cloud Armor Enterprise の年間サブスクリプションへ登録している場合、 DDoS 請求保護 （DDoS bill protection）を受けることができます。 万が一、 Web アプリケーションが DDoS 攻撃を受けてしまい、多大なトラフィックが発生してしまった影響で Cloud Load Balancing、Google Cloud Armor、ネットワーク下りトラフィックなどに大量の課金が発生してしまった場合、 Google に申請することで該当の利用料金に充当できるクレジットを受けられる場合があります。 詳細は以下を確認してください。 参考 : DDoS 請求対策 Adaptive Protection（適応型保護） Adaptive Protection とは Adaptive Protection （適応型保護）とは、HTTP Flood などのレイヤ 7 の DDoS 攻撃と思われる怪しい挙動を検知し、機械学習モデルによってアラートを出したり、防御のためのシグネチャを自動生成する機能です。 Adaptive Protection のフル機能を利用するためには Cloud Armor Enterprise に登録する必要があります。一方の Standard だと、アラートの一部（基本アラート）のみを受け取ることができます。基本アラートには、攻撃シグネチャや推奨ルールが含まれません。 Adaptive Protection はセキュリティポリシー単位で有効化できます。 有効化後、機械学習によってベースラインが確立され、アラート生成ができるようになるまで最低でも 1 時間のトレーニング期間が必要とされています。 参考 : Google Cloud Armor 適応型保護の概要 アラート Adaptive Protection では、一定の学習期間中にトラフィックパターンが学習されます。学習後に高頻度または大容量の異常トラフィックが検出されると、 Cloud Logging にアラートが生成されるようになります。 アラートには 信頼度レベル , 攻撃シグネチャ , 推奨ルール , ベースラインのうち影響を受ける割合の予測値 が含まれます。 信頼度レベル とは、機械学習モデルが予測した結果の確からしさ (確率。 0 〜 1 の数値) です。 ベースラインのうち影響を受ける割合の予測値 とは、自動生成されるルールが実際に適用された場合にベースラインのうちどれくらいの割合のトラフィックが影響を受けるか、という予測値です。 自動生成ルールの適用 自動生成ルールを適用するには以下の 2 つの方法があります。 Cloud Logging に出力されたアラートにルール名が出力されるので、それを使ってセキュリティポリシーにルールを記述する（CEL の記述） コンソール画面の Adaptive Protection ダッシュボードから GUI で適用する（自動適用） このように簡単にルールを適用することができますが、実際にはプレビューモードで試運転することが推奨されます。プレビュー期間を設けずに実稼働させると、正しいトラフィックにまで予想外の影響が出る（偽陽性）可能性があるためです。 参考 : 推奨ルールのデプロイ 参考 : 推奨ルールを自動でデプロイする DDoS 攻撃の可視化 Cloud Armor の Enterprise ティアに登録すると、Cloud Logging と Cloud Monitoring を使い、DDoS 攻撃の状況を可視化することができます。 通常ですと、Cloud Armor の DDoS 保護はセキュリティポリシー適用前に行われてしまうため、DDoS 攻撃の状況はログやメトリクスに残りません。しかし Enterprise ティアに登録していると、Global external Application Load balancers に限り、Cloud Logging ログと Cloud Monitoring メトリクスにおいて DDoS 保護機能によりブロックされたトラフィックを確認することができます。 参考 : DDoS 攻撃の可視性テレメトリーにアクセスする レート制限 Cloud Armor には レート制限機能 があります。この機能では、少数のクライアントからの大量アクセスを検知して、 スロットル （アクセス数の上限）をかけたり、そのクライアントを Ban （禁止）することができます。 例えば、 20 分間で 2000 リクエスト という上限をルールに設定し、それを超えた場合はアクセス数を制限したり、あるいはそのクライアントを指定した秒数の間、アクセス禁止にすることができます。 「IP アドレス」「HTTP ヘッダ」「Cookie」「リクエストのパス」などの属性のうちから1〜3個までを組み合わせて、それらのキーが一致するリクエストを合算してレート制限をかけることができます。 ルールの作成方法等は以下ドキュメントを参照してください。 参考 : レート制限の概要 参考 : レート制限ルールの構成 Bot 管理 Cloud Armor では、 reCAPTCHA Enterprise との統合により、bot 対策が可能です。 トラフィックを reCAPTCHA の確認画面（ 私はロボットではありません など）へリダイレクトするなどして bot からのアクセスを拒否することができます。 アプリケーションのフロントエンドに Javascript で reCAPTCHA のコードを埋め込むことで、アプリへのリクエストにトークンを埋め込み、Cloud Armor がそのトークンをチェックしてリスク評価を行う「フリクションレス評価」と呼ばれる手法も実装可能です。 詳細は、以下を参照してください。 参考 : Google Cloud Armor bot 管理の概要 なお reCAPTCHA Enterprise は Cloud Armor とは別サービスであり、別途費用が発生することに留意してください。 参考 : reCAPTCHA の概要 参考 : reCAPTCHA の料金 運用・ロギング WAF の運用作業 Cloud Armor に限らず、 WAF 製品には運用が必要です。例として、以下のような作業が発生します。 誤検知（偽陽性）への対応 新たに見つかった脆弱性への対応 誤検知 （ 偽陽性 ）への対応とは、Web アプリケーションの仕様変更や、ルールのシグネチャの更新等をきっかけとして、正当なトラフィックが不正アクセスとして WAF にブロックされてしまうようなときに、明示的にトラフィックを許可したり、誤検知しているルールを無効化したりする作業です。 トラフィックがブロックされた場合は、Cloud Logging のログを確認して、原因となったトラフィックやシグネチャを確認して対応を検討します。 後者の 新たに見つかった脆弱性への対応 では、日頃から脆弱性に関する情報収集を適切に行い、ルールを管理していきます。Google の事前構成ルールを使用していれば、基本的にはルールが自動的に更新されていきます。しかし、ニュースとなるような深刻な脆弱性が発生した直後には、手動でルールを追加する必要性が出てくるかもしれません。 例として2021年12月には、広く利用されている Java 用のログ出力ライブラリである log4j の脆弱性が見つかり、各社は対応に追われました。そのときには Google が新しい事前構成ルール cve-canary を迅速に開発・アップデートしたため、対策を行うことができました。 参考 : Cloud Armor の WAF ルールで Apache Log4j 2 の脆弱性対策 Cloud Armor のログ出力 Cloud Armor による検知のログを確認するためには、 Cloud Load Balancing 側でログを有効化 する必要がある点に注意してください。 デフォルトで Cloud Armor 自体の監査ログは出力されます。しかし、これにはセキュリティポリシーの設定変更など管理的なログが記録されるだけで、トラフィックがブロックされた場合のログなどは 出力されません 。 実際の攻撃に対する対処や、誤検知（偽陽性）対応などを行うためにも、 WAF のログ出力は必須と言っていいでしょう。 これにはロードバランサー側のログを有効化する必要がある、ということを覚えておきましょう。 参考 : リクエスト ロギングの使用 運用のベストプラクティス Cloud Armor の運用や設定値に関するベストプラクティスについては、以下の記事も参照してください。 blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは、@norryです。自分は九州は熊本からフルリモートで東京本社の株式会社G-genにジョインしています。 G-genはGoogle Cloudの専業ベンダーである事から、自らの実力向上の為Google Cloudの認定資格取得に取り組んでいます。 Googleの認定資格は KRYTERION で受験可能なのですが、国内ではあまり対応している試験会場がなく今回は福岡の試験会場で受験しました。 その際に受験会場周辺で少し迷ったので九州で唯一の会場ですので受験される人の参考になれば幸いです。ちなみに自宅からオンラインでの受験も可能なのですが気分転換も兼ねて今回は会場で受験しています。 Google Cloud認定資格とは 試験会場へのアクセス Google Cloud認定資格とは Google Cloudの認定資格とは Google Cloud の職務ベースの認定資格は、Google Cloud テクノロジーを使用した特定の職務の遂行能力を評価するものです。厳正に開発された業界標準の手法を使用して、各職務の知識、スキル、能力の評価が行われます。Google Cloud 認定資格は、個人のキャリア開発の促進と、高いスキルと実践力を備えたチームの構築に役立ちます。 とあります。 自分は今回は Professional Cloud Architect 試験を受験しました。AWSで言うところの Solutions Architect - Professionalにあたるでしょうか、Google Cloudのサービス全般的な内容が問われます。 Google Cloud 認定資格については、以下の当社記事もご参照ください。 blog.g-gen.co.jp 試験会場へのアクセス 電車で行く場合は地下鉄赤坂駅で下車してください。徒歩３分ほどになります。 試験会場へは15分前への入場になりますので余裕を持って試験会場の近くへ行きましょう。 幸いにも会場の近くにはカフェや喫茶店が多数ありますので試験勉強の仕上げに持ってこいです。 時間になりましたら会場へ向かうのですがこちらの建物が少し複雑で地図で書きますとこの場所になります。 自分は間違ってこの周辺をグルグルしてしまいました。 下の写真のラーメン屋さんから左折 ここが入り口です。 入り口入って「左側」のエレベーターで12Fまで上がってください、ここを間違って右側に乗ると12Fでぐるっと遠回りする事になります。 エレベーターをおりた右手に会場入口があります。 入って受付を済ませ試験です、出題数50問の制限時間120分でしたが60分ほどで終了し何とか合格しました。クラウド系資格全般そうなのですが「合格」「不合格」の表示が分かりにくくてドキドキします。 さて試験が終わったらご褒美に覚王山フルーツ大福を食べましょう〜 ※お店に撮影許可をいただいています 大福を食べた後は腹ごなしとお礼参りに福岡縣護国神社へ 以上福岡受験日記でした、皆さんも良い試験ライフを！ 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの杉村です。Google Cloud（旧称 GCP）のフルマネージドのデータウェアハウスである BigQuery には、パフォーマンス向上やコスト削減に当たり、 パーティション と クラスタリング という重要な概念があります。それぞれの仕組みや使い分けを解説していきます。 パフォーマンスのためのテーブル設計 パーティション パーティションとは 使用方法 パーティションフィルタ要件 メリット パーティションの分割基準 時間の列 取り込み時間 整数範囲の列 パーティションの管理 パーティションの上限と注意点 クラスタリング クラスタリングとは 使用方法 クラスタ化に指定する列 自動再クラスタリング パーティション vs クラスタリング パーティションとクラスタリングの違い パーティションとクラスタリングの使い分けと併用 パーティション・クラスターのレコメンデーション 参考情報 パフォーマンスのためのテーブル設計 BigQuery において、最適なパフォーマンスを出すためのテーブル設計として、最も重要なのが パーティショニング と クラスタリング です。 一般的な RDBMS（リレーショナルデータベースマネジメントシステム）では、テーブルに対してインデックスを作成することで、検索パフォーマンスを向上させます。BigQuery には検索インデックス（search index）機能があるものの、これは主に特定の文字列を特定のフィールドから高速に検索するために使用する機能であり、基本的には分析や可視化のパフォーマンス向上に寄与するものではありません。 blog.g-gen.co.jp 検索インデックスは、システムログの検索、セキュリティ監査などの文字列検索のパフォーマンスを向上させるために使います。一方で、当記事で紹介するパーティショニングやクラスタリングは、スキャン効率や速度、コストパフォーマンスを向上させるために有用です。そのため多くの機会で、パーティショニングやクラスタリングは、BigQuery のテーブル設計における基本的な考えであるといえます。 パーティション パーティションとは パーティション とは、 BigQuery の一つのテーブルを、特定の列の値を基準にして内部的に複数の部位に分割する機能です。これによりクエリ時にスキャンする範囲を狭め、パフォーマンス向上とスキャン料金の節約ができます。 参考 : パーティション分割テーブルの概要 分割基準として使う列をテーブル作成時に指定することで、パーティション分割されたテーブルを作成することができます。1つのテーブルには、パーティション列は1つしか指定できません。 パーティションで分割されたテーブル 使用方法 テーブル作成方法は以下のドキュメントの通りです。 参考 : パーティション分割テーブルの作成 例として、以下のような DDL で、パーティション分割されたテーブルを作成することができます。 CREATE TABLE mydataset.purchase_tran ( purchase_dt DATE , prod_id STRING, prod_name STRING, store_id INT64, store_name STRING ) PARTITION BY purchase_dt このように作成されたテーブルで以下のようにクエリを実行すると、 BigQuery は当該の値を含んだパーティションだけをスキャンします。 SELECT * FROM mydataset.purchase_tran WHERE purchase_dt = " 2025-04-01 " パーティションフィルタ要件 パーティション分割テーブルの作成時に、 パーティションフィルタ要件 （Partition filter requirements）を有効化することで、WHERE 句でパーティション列が指定されていないクエリを、エラーとして拒否することができます。 これを設定することで、テーブルの利用者は、パーティションによるスキャン範囲を指定したクエリしか投げられなくなりますので、テーブルに対する不用意なフルスキャンを予防することができます。 メリット パーティションが無い場合、BigQuery はテーブル全体をフルスキャンします。パーティションによる範囲スキャンは、フルスキャンに比べて大幅にスキャン範囲を節約でき、料金と時間の節約となります。 また前述のパーティションフィルタ要件を使えば、ユーザーが大規模なテーブル全体に対して誤ってクエリを実行する等の、費用の急増を防ぐ効果もあります。 パーティションの分割基準 時間の列 TIMESTAMP 型 、 DATE 型 、 DATETIME 型 のいずれかの列をパーティション列として指定可能です。 TIMESTAMP 列と DATETIME 列では、パーティションを時間単位、日単位、月単位、年単位のいずれかで作成できます。 DATE 列の場合、パーティションは日単位、月単位、年単位で作成できます。 いずれも、分割単位を指定しない場合、デフォルトは日単位となります。 以下は、DDL の例です。DATE 型の列をパーティション列に指定すると、デフォルトでは日単位での分割になりますが、以下の例のように DATE_TRUNC 関数を使って月単位で切り捨てることで、月単位の分割になります。 CREATE TABLE mydataset.newtable ( transaction_id INT64, transaction_date DATE ) PARTITION BY DATE_TRUNC(transaction_date, MONTH) OPTIONS ( require_partition_filter = TRUE ); 取り込み時間 取り込み時間をパーティション基準として選択すると、BigQuery がデータを取り込んだタイムスタンプに基づいてテーブルが分割されます。 分割粒度は、時間単位、日単位、月単位、年単位から選択できます。デフォルトは日単位です。 テーブル作成時には、 _PARTITIONTIME という疑似列（仮想列）をパーティション列として指定します。 以下は、DDL の例です。 CREATE TABLE mydataset.newtable ( transaction_id INT64 ) PARTITION BY _PARTITIONDATE 整数範囲の列 パーティション分割の基準列として、INTEGER 型の列を指定可能です。またこの場合、分割の開始値・終了値と分割の間隔を指定できます。 以下は、DDL の例です。 CREATE TABLE mydataset.newtable ( customer_id INT64, date1 DATE ) PARTITION BY RANGE_BUCKET( customer_id, GENERATE_ARRAY( 0 , 100 , 10 ) ); この例では customer_id 列でパーティショニングし、開始値 0、終了値 100、間隔 10 としています。 このように設定した場合、customer_id が 0 から 9 の行が最初の パーティションに入り、10 から 19 が次のパーティションに入ります。この処理が 99 まで続きます。この範囲外の値は、 __UNPARTITIONED__ という名前のパーティションに入ります。customer_id が NULL の行は、 __NULL__ という名前のパーティションに入ります。 テーブルにどんなパーティションが存在しているかは、テーブルのメタデータから確認できます。 参考 : パーティション分割テーブルの管理 - パーティション メタデータの取得 パーティションの管理 時間単位または取り込み時間で分割したテーブルの場合、パーティションの 有効期限 を設定できます。 指定した有効期限が過ぎたらデータは自動的に削除されます。このとき BigQuery のユーザーに割り当てれたリソースは消費されません。有効期限をうまく使うことで、ハウスキーピング用のジョブをユーザーが作成する必要がなくなります。 参考 : パーティション分割テーブルの管理 - パーティションの有効期限を設定する デフォルトのパーティション有効期限をデータセットで設定できるほか、テーブル単位で有効期限を設定することもできます。テーブルで有効期限が設定されている場合は、テーブルの有効期限が優先されます。 パーティションの有効期限はテーブル作成時に指定するほか、作成後にも変更できます。 パーティションの上限と注意点 1テーブルが持てるパーティション数には上限があり、 1テーブルにつき10,000パーティションまで です。従来は4,000が最大値でしたが、2024年5月29日のアップデートで10,000に変更されました。 これは、時間単位であれば 10,000 時間 = 約416日 = 約13ヶ月間であり、日単位での分割であれば 10,000日 = 約322ヶ月 = 約27年です。 パーティション数の上限に達すると、 ジョブがエラーとなります 。パーティションのデータのバックアップを取得する仕組みを用意したうえで、パーティションに有効期限を設けてデータが自動削除されるようにする等、運用上の考慮を検討する必要があります。 また「1 つのジョブで変更されるパーティションの数」や「1 日の取り込み時間パーティション分割テーブルあたりのパーティションの変更回数」「1 日の列パーティション分割テーブルあたりのパーティション変更数」などにも上限があります。バッチ処理がこれに抵触していないかは、十分注意する必要があります。 参考 : 割り当てと上限 - パーティション分割テーブル 以下は、10,001 個目のパーティションを追加しようとした場合のエラーメッセージです。 Resources exceeded during query execution: Table my-project:my_dataset.my_table will have 10001 partitions when the job finishes, exceeding limit 10000. If partitions were recently expired, it may take some time to be reflected unless explicitly deleted. パーティション上限を超えた際のエラーメッセージ また、1回のジョブで変更可能なパーティション数は4,000です。これを超えるようなクエリを発行した場合、以下のようなメッセージが表示されます。 Too many partitions produced by query, allowed 4000, query produces at least 10000 partitions クラスタリング クラスタリングとは クラスタリング とは、 BigQuery のテーブルの特定の列の値に基づいてテーブルのデータをソートし、内部的に近い位置に配置しすることで、フィルタや集計クエリを高速化する機能です。 テーブル作成時に、列をクラスタ化列として指定します。 クラスタリングを利用すると、指定した列の値に基づいて行がソートされるため、 WHERE 句でこの列に基づいてフィルタするクエリを投げた際、不要なデータのスキャンをスキップすることができます。また、クラスタ化した列で GROUP BY して集計するクエリの場合、行がソートされ近い位置に配置されているので、パフォーマンスが向上します。 参考 : クラスタ化テーブルの概要 クラスタは パーティションと併用する ことも可能です。クラスタリングとパーティショニングを併用すると、データはパーティション分割された後に、クラスタ化されます。 またクラスタ化列は、1つのテーブルで複数（最大 4 列まで）指定可能です。複数指定した場合、指定の順番が重要になります。まず最初に指定した列で行がソートされ、次にその中で2番めに指定した列でソート、次に3番目... というように、順番にソートされます。 クラスタ化されたテーブル 使用方法 クラスタリングされたテーブルを作成する方法は、以下のドキュメントのとおりです。 参考 : クラスタ化テーブルの作成と使用 例として以下のような DDL で、クラスタリングされたテーブルを作成できます。例では、パーティショニングも併用しています。 CREATE TABLE mydataset.purchase_tran_cls ( purchase_dt DATE , prod_id STRING, prod_name STRING, store_id INT64, store_name STRING ) PARTITION BY purchase_dt CLUSTER BY prod_id また、既存のテーブルをクラスタリングしたり、列の指定を変更することも可能です。 参考 : クラスタ化テーブルの作成と使用 - クラスタリング仕様を変更する クラスタ化に指定する列 クラスタ化に指定する列は、一意の値を多く含む（カーディナリティの高い）列が推奨されます。そのほうが、ソートによるスキャン範囲のスキップの効果が高く期待されるためです。 また、組み合わせて使われることの多い複数の列をクラスタ化すると効果が期待できます。先の記述の通り、順番に注意して、頻繁に WHERE で指定あるいは GROUP BY される複数列をクラスタ化列として指定すると、効果が大きくなります。 参考 : BigQuery 特集: ストレージの概要 参考 : BigQuery のクラスタリングで メンテナンスの手間を省いて クエリを高速化 自動再クラスタリング クラスタリングのメンテナンスは自動で行われます。データが新規で追加されたり、変更されたりした場合でも、自動で再クラスタリングが行われます。一般的なデータベース製品で必要とされる VACUUM といった処理は不要です。 再クラスタリングは、スロットなどのリソースが消費されることもなく、自動的かつ透過的に行われるため、ユーザーが意識する必要はありません。 パーティション vs クラスタリング パーティションとクラスタリングの違い パーティションとクラスタリングは併用できますが、どのようなケースでどちらを使えばいいのか、またどのような列を指定すればいいのか、使い分けに迷うときもあります。 パーティションとクラスタリングの違いは、以下のような点にあります。 パーティショニングでは実際のクエリ実行前に ドライラン でスキャン量の試算ができる（料金試算が可能）。一方のクラスタリングでは、試算はテーブル単位、パーティション単位で行われるためドライランに反映されず、実際のスキャン量は見積もりより小さくなる可能性がある 参考 : クエリの実行 - ドライラン パーティショニングでは有効期限の設定ができる パーティショニングでは分割粒度（時間・日・月・年・整数範囲）の選択ができる パーティショニングでは1つの列しか指定できない。クラスタリングでは4列まで指定できる パーティショニングでは特定の型の列しか指定できないが、クラスタリングには型の制限はない パーティションとクラスタリングの使い分けと併用 まずはパーティションを適用できる列があるかどうかを検討します。以下のような場合、パーティションの利用を検討します。 日付または時間 の型の列があり、 それらの列でフィルタ するクエリがある パーティションの 有効期限設定 を使ってテーブルのメンテナンスをしたい ドライラン でスキャン量（費用）の見積もりを行いたい 1個のパーティションあたりのデータ量が およそ 10 GB 以上 になる見込み（それ未満の場合はオーバーヘッドにより 逆に非効率 になる可能性があるためクラスタリングの使用を検討する） 上記の観点でパーティショニングを適用する列を検討をした後、以下のようにクラスタリングを適用する列を検討します。 よくフィルタ対象になる列だが、パーティショニングは既に別の列に適用している よくフィルタ対象になる列だが、データサイズが 10 GB 未満 になる見込み よくフィルタ対象になる列であり、値の カーディナリティが大きい （クラスタ化により速度改善の可能性あり） よくフィルタ対象になる列だが、パーティションを使うと分割粒度が小さくなりすぎ、1テーブルの 上限である 10,000 パーティション を超えてしまう テーブル内の大部分のパーティションが頻繁に（たとえば、数分ごとに）変更されるオペレーションがある。この場合、パーティションは避けてクラスタリングを利用する。1日あたりのパーティション変更数の上限があるため 結合に使われている列。クラスタ化によって 結合が高速化 する可能性がある（データが同じカラムナファイルに記録されスロット間のデータ移動が押さえられる） ただし 64 MB 未満のテーブルやパーティションではクラスタ化のメリットは小さい サイズがある程度大きいテーブルの場合は上記のように検討し、パーティションとクラスタリングを併用することで、スキャン料を節減してパフォーマンスとコスト効率を向上させられる可能性があります。 以下の公式ドキュメントも参照してください。 参考 : パーティション分割テーブルの概要 - クラスタ化テーブルとパーティション分割テーブルを組み合わせる 参考 : クラスタ化テーブルの概要 - クラスタリングを使用する場合 参考 : クラスタ化テーブルの概要 - クラスタ化テーブルとパーティション分割テーブルを組み合わせる パーティション・クラスターのレコメンデーション BigQuery には、過去のワークロードに基づいてテーブルの適切なパーティショニングやクラスタリングを推奨する機能があります。 Recommender API が過去30日間の実績を機械学習で分析し、テーブルの適切なパーティショニング・クラスタリング設定を提示します。対象テーブル、対象列、またどのくらいのスロット時間が節約できるかの見込みが表示されます。 推奨の対象となるテーブルは「パーティショニング無し・クラスタリング無し」「パーティショニング有り・クラスタリング無し」のテーブルです。 一方で 10 GB 以下のテーブルや既にパーティションとクラスターを両方設定済みのテーブル、また過去30日以内に読み取りされていないテーブルなどは対象外となります。 推奨はコンソール、gcloud、REST API で確認可能です。コンソールでは、画面右上の電球マークから確認できます。 参考 : パーティションとクラスタの推奨事項を管理する 参考情報 以下の公式記事では、パーティションやクラスタリングの仕組みが詳細に解説されていますので、是非参考にしてください。 参考 : BigQuery 特集: ストレージの概要 参考 : BigQuery のクラスタリングで メンテナンスの手間を省いて クエリを高速化 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 Google Workspaceにおいてオーナー権限というのをご存知でしょうか？ その名の通り、ファイルやフォルダのオーナー権限になるのですが、例えばそのオーナーがGoogle Workspaceから削除された場合など、オーナーが作成したドキュメントも一緒に削除されてしまいます。また、ファイルの変更履歴なども消えてしまうことがあるので、確実に実施する方法としては”オーナー権限を別のユーザーに移す”という作業が必要になります。 例えば 退職者が出た場合 等には必要になるので、ご活用ください。 それではその方法を簡単に説明していきます。 ユーザーが操作可能な場合(退職前など) 一括でオーナー権限を付け替える方法(退職後など) ユーザーが操作可能な場合(退職前など) まだユーザーが退職しておらず、またファイル数も少ない場合には以下の手順で簡単に実施可能です。 ファイルを右クリック＞共有のメニューから編集者のプルダウンにて オーナー権限の譲渡 にて操作可能です。 ファイル単位の譲渡方法 ただこちら、一個一個実施するのは相当めんどくさいですよね。退職者がでた。ということはおそらくファイルも多く存在すると思いますし。 では次項にて 一括で譲渡する方法 をお試しください。 一括でオーナー権限を付け替える方法(退職後など) こちらの方法は管理者のみが実行できる方法になるのですが、管理メニューから以下のように選択いたします。 「アプリ」＞「Google Workspace」＞「ドライブとドキュメント」＞「オーナー権限の譲渡」 オーナー権限の譲渡 ここで譲渡前のユーザー、及び譲渡後のユーザーを入力することで、簡単に一括でオーナー権限を譲渡することが可能です。 今回は佐藤さんから鈴木さんに譲渡してみましょう。 オーナー権限の譲渡操作(1) オーナー権限の譲渡操作(2) 上記操作を実施すると、以下の画面のように、佐藤さんが保持していたオーナー権限が、鈴木に譲渡されている。ということがわかるかと思います。 譲渡後のオーナー権限 ただしここで注意なのが本操作が可能なのは 同じ組織内で管理されているユーザーのみ になりますので、別組織等に共有しているものに関してはオーナー権限を一括で変更することはできません。 こちらに関しては引き続きGoogleサポートを利用しつつ調査していきたいと思います。 今回の記事はライトにここまでとさせていただこうと思います。 追伸：11月29日にGoogle Cloud - Professional Collaboration Engineerを取得させていただきました。この件に関してはまた何かの機会で。 Professional Collaboration Engineer 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-gen の杉村です。Google Cloud (旧称 GCP) のセキュリティサービスである Cloud IDS について解説していきます。 Cloud IDS とは アーキテクチャ 構成図 IDS エンドポイント Packet mirroring policy 脅威検知 Application-ID シグネチャーセット 重要度 シグネチャーの更新頻度 料金 上限 セットアップ セットアップ手順 動作確認 Cloud IDS Cloud IDS とは Cloud IDS とは Google Cloud (旧称 GCP) のセキュリティサービスであり、Google Cloud 上のネットワークにおける侵入、マルウェアによる通信、コマンド&コントロール通信等を検知する仕組みです。 IDS とは Intrusion Detection System の略語であり 侵入検知システム のことです。主にネットワークトラフィックを検査することで有害なアクセスを検知することを目的とした仕組みを指します。しばしば IPS/IDS のように侵入 防止 システムとセットで語られることが多いものです。 そのため Cloud IDS で提供されるのは侵入の 検知だけ であり侵入を 防ぐ機能はありません 。 Cloud IDS は、VPC からトラフィックをミラーリング (複製) し Palo Alto Networks の脅威検知技術 で検査します。 また、利用時間と処理データ量に応じて料金が発生します。全トラフィックを検査することも、サブネット単位なインスタンス単位で検査対象パケットを指定することも可能です。 参考 : Cloud IDS の概要 アーキテクチャ 構成図 Cloud IDS のアーキテクチャは、以下のように図示されます。 Cloud IDS のアーキテクチャ IDS エンドポイント Cloud IDS では IDS エンドポイント というリソースを作成します。 IDS エンドポイント自体はゾーンリソースですが、1つ作れば同じリージョン内の全ゾーンのトラフィックを検査できます。 IDS エンドポイントは Private services access の機能を使って、ユーザの VM と Google が管理する検査用 VM の間を接続します。 パラメータとして以下を持ちます。 最小のアラート (アラートとして扱う最小の重要度。 Critical > High > Medium > Low > Informational) トラフィックログ (ON or OFF) トラフィックログ は、検知された脅威とは別に、ミラーリングしたトラフィックのログを JSON で生成します。 大量のログが Cloud Logging へ送信され利用料金が大きくなることが想定されますので、特に必要な理由がある場合を除いて、オフとすることが望ましいでしょう。 Packet mirroring policy IDS エンドポイントを作成すると Packet mirroring policy をアタッチする必要があります。 このポリシーが、どのトラフィックを検査対象とするかを決定します。 Packet mirroring policy では以下のパラメータを持っています。 ポリシーの状態 (有効 or 無効) ミラーリングの対象 (サブネット単位 or ネットワークタグ単位 or インスタンス単位) ミラーリングのフィルタ (プロトコル / IP レンジ / トラフィックの方向) 脅威検知 Application-ID 検査されるネットワークトラフィックは Palo Alto Networks がメンテナンスする Application-ID (App-ID) という ID により、どのアプリのトラフィックであるかが判断されます。 脅威検知された際、そのトラフィックが何のアプリケーションにより生成されたものなのかが、この App-ID によって分類されます。 App-ID は週次程度の頻度で更新されていき、 Cloud IDS のユーザーが意識しなくとも、自動でアップデートされていきます。 シグネチャーセット Cloud IDS は シグネチャー によりトラフィックを検査します。 例として、以下のような挙動となります。 バッファオーバーフロー、コードの不正実行、その他の脆弱性を突いたアクセスなどを検知 スパイウェアからコマンド & コントロール (C&C) サーバへの通信を検知 重要度 検知された脅威は 5段階に分類 されます。 IDS エンドポイントの設定でどのレベルまでを検知対象とするかを指定できます。 重要度 説明 Critical 深刻。 サーバに深刻なダメージを与えるもの。またエクスプロイトコードが広く知られている、攻撃者が攻撃対象に関して認証情報や深い情報を必要としないなど、危険度が高い脅威 High 高。危険ではあるものの、エクスプロイトの難易度が高い、特権昇格に繋がらない、攻撃対象となり得る範囲が狭いなどの理由で "深刻" には分類されない脅威 Medium 中。インパクトは中程度で、攻撃者が同じローカルネットワークにいる必要があったり、標準的でない設定に対してのみ危険であったり、限定的な対象に対してのみ危険な脅威 Low 低。インパクトが小さく、ローカルネットワークもしくは物理的なアクセスが可能な場合のみ危険となりえるなどの理由で、警告レベルとされる脅威 Informational 情報レベル。直ちに脅威にはなり得ないが潜在的に危険な、疑わしい挙動など シグネチャーの更新頻度 App-ID やシグネチャーは、ユーザーが意識する必要なく、 自動的にアップデート されます。 Palo Alto Networks によるアップデートは、日次で Cloud IDS に反映されます。反映の遅れは、最大でも 48 時間とされています。 料金 Cloud IDS の料金は エンドポイントの存在する時間 単位の課金 + 処理したトラフィックの GB 単位の課金 の2軸となっています。 2021/11時点で料金は以下のようになっています。 エンドポイント時間あたり: $1.50 / hour 処理データ量あたり: $0.07 / GB 最新の料金は必ず以下のドキュメントを参照してください。 参考: Pricing 上限 Cloud IDS には以下の上限 (Quotas) が設定されています。 コンソールの 割り当て 画面から緩和リクエストを送信することが可能です。 ゾーンあたりの IDS エンドポイント数: デフォルト 10 分あたりの API リクエスト数: デフォルト 1,200 セットアップ セットアップ手順 セットアップ方法は以下のドキュメントを参考にしてください。 cloud.google.com 大まかな流れは以下のとおりです。 IDS エンドポイントの作成時に待ち時間が 10 分ほどありますが、全体としては 30 分程度で構築することができます。 Private service access を作成 (Cloud SQL などで既存のものがあれば利用可能) IDS エンドポイントを作成 Packet mirroring policy を作成 動作確認 Google Compute Engine (GCE) のコンソールで対象 VM を選択し オブザーバビリティ タブを選択すると対象 VM の Cloud Monitoring メトリクス (指標) を見ることができます。 その中に Packet Monitoring という項目があります。 ここを見ると、対象 VM からパケットが IDS エンドポイントを通じてミラーリングされていることが分かります。 パケットミラーリングが有効化されている また、脅威が確実に検知されることを確かめるため、以下のコマンドを VM 上で実行しましょう。 curl http://example.com/cgi-bin/../../../..//bin/cat%%20/etc/passwd しばらくすると Cloud IDS のコンソール画面で検知が High として脅威されていることが表示されます。 対象アラートをクリックすると、詳細を表示することができます。 テストで実行した curl が検知された 参考: Troubleshooting 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは株式会社G-genの渡邉（@norry）です。 Google Workspace (以下、GWS)を利用するにあたって組織の端末に対してセキュリティーをどう担保していくのか？気にされるのではないでしょうか、その時にGWSだけでどの程度管理可能なのかも気になる部分かと思います。 今回は利用人数1〜300名までのBusinessエディションの各プランで「これぐらいの管理がしたいからこのプランが必要」と判断する時にお役に立てれば幸いです。 各プランのおおまかな全体比較はこちらを参考にしてください blog.g-gen.co.jp どのプランがオススメか Business Starter及びBusiness Standardがオススメなケース Business Plusがオススメなケース 上記だけでは要件を満たさないケース 混同しがちなキーワード GWS上のデバイス管理のコンソールで良く目にするキーワード Businessエディション、デバイス管理の各プラン機能比較 機能比較の補足 基本のエンドポイント管理 セキュリティ設定 デバイスの管理 アプリの管理 デバイスの詳細 高度なエンドポイント管理 セキュリティ設定 デバイスの管理 アプリの管理 デバイスの詳細 Google Workspaceを導入するなら株式会社G-genにご相談ください。 どのプランがオススメか デバイス管理のBusinessエディションでの各プラン機能比較はこちらのようになります。 Business Starter Business Standard Business Plus 基本のエンドポイント管理 ✔ ✔ ✔ Android アプリの管理 ✔ 高度なエンドポイント管理 ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ デバイス監査ログ ✔ 使われていない会社所有デバイスに関するレポート ✔ 会社所有の Android デバイス ✔ 上記を参考にしながら最初にオススメのプランをご紹介いたします。 Business Starter 及び Business Standard がオススメなケース デバイス管理をしない、または最低限の管理だけを考えている方におすすめです。 後述しますがデバイス管理だけを考慮した場合、「Business Starter」「Business Standard」には差異がありません。 基本的なモバイルデバイス管理 が利用可能です 主な機能としてパスコード使用の必須化、デバイスの一覧取得、Google アカウントのリモート ワイプ、Android デバイスへのアプリケーションのリモート インストールが可能です。 基本的な管理のデバイス情報画面 また、ユーザーが Windows、Mac、Chrome、Linux デバイスのどのブラウザを使用して GWSにログインした場合でも、そのデバイスがエンドポイント管理に自動登録されます。 程度として、ユーザーに制限をかけたくない、どんなモバイルデバイスがアクセスしたのかな？あたりを知ることが出来ればOKでしたら、こちらを選択ください。 Business Plus がオススメなケース Andoroid、iOSのBYODデバイスに対してより細かく制御、Windows端末も管理対象にしたい場合にBusiness Plusプランがおすすめです。 Business Plusプランでは 高度なモバイルデバイス管理 が利用可能になります。 Android では仕事用プロファイルで個人データを仕事用データから分離して、プライバシーを守ることができます。iOS デバイスと Android デバイスで仕事用アプリの使用を許可、管理する事が可能です。 Windows デバイス管理ではGWSアカウントでのWindowsログインやデバイスからのデータのワイプ（消去）、デバイスの詳細情報を表示させる事が可能となっています。 上記だけでは要件を満たさないケース そもそも許可された端末以外はGWSにアクセスさせたくない場合は他の方法もご検討ください。 会社所有以外の端末からアクセスした時に管理者の承認を必須にする場合、Enterpriseエディションやその他のMDMツールをご検討ください。 基本的、高度なモバイルデバイスではユーザーは端末で一度はGWSにログインする事が出来てしまいますが、ログイン後に管理コンソールから状況の確認やワイプの操作は可能です。 混同しがちなキーワード GWS上のデバイス管理のコンソールで良く目にするキーワード GWS管理コンソール プランによってモバイルデバイスにはポリシー適用出来るがエンドポイントには出来ないみたいな事があります。検討しているうちにどの種類の端末なのか分からなくなってくるのでよく使うワードだけまとめておきます。 モバイルデバイス Android、iOS、Google sync デバイス（所謂携帯端末） エンドポイント 管理コンソール上ではパソコン(Windows、Mac、Linux)とスマートホームデバイス、プラン説明の時には端末全般を指す事が多い Chromeデバイス Chromebook とその他の Chrome OS 搭載デバイス 管理対象ブラウザ 各OS（Windows、Mac、Linux）から登録トークンを使用して登録された Chromeブラウザ のこと またGoogleエンドポイント管理のデバイス要件は こちら になります Businessエディション、デバイス管理の各プラン機能比較 機能比較の補足 先にオススメプランの結論はお伝えしましたが、もう少し機能について詳しく知りたい方向けに補足をさせていただきます。 再度になりますが、デバイス管理のBusinessエディションでの各プラン機能比較はこちらのようになります。 Business Starter Business Standard Business Plus 基本のエンドポイント管理 ✔ ✔ ✔ Android アプリの管理 ✔ 高度なエンドポイント管理 ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ デバイス監査ログ ✔ 使われていない会社所有デバイスに関するレポート ✔ 会社所有の Android デバイス ✔ 事項から補足していきます。 基本のエンドポイント管理 基本のエンドポイント管理 はGWSのBusiness StarterプランからBusiness Plusまで全てのプランで利用可能です。 また、基本のエンドポイント管理には以下の機能が含まれます。 セキュリティ設定 セキュリティ設定ではモバイルデバイスに対してパスコードの使用を必須化や、WindowsPCにエージェントをインストールする事によってGWSのアカウントでログインする事が可能になります。 基本的なパスコードの適用（モバイル） Windows 用 Google 認証情報プロバイダ デバイスの管理 デバイスの管理ではモバイル デバイスからユーザーのアカウントをワイプや、自組織のChromeを利用しているユーザーをリモートでログアウト、デバイス上のパソコン版ドライブに関する情報を確認などが可能です。 基本的なモバイル デバイス管理 パソコンの基本管理 エンドポイントの確認 パソコン版ドライブ デバイスのブロック アカウントのリモートワイプ（モバイル） リモート ログアウト（パソコン） アプリの管理 アプリの管理では管理者が設定したアプリをユーザーが見つけてインストールする事ができ、仕事用または学校用としてアプリ管理できます。 ただしBusiness Starterでは管理対象アプリを自動インストールしたりブロックしたりする機能はありません。 一般公開および限定公開の Android アプリの選択 デバイスの詳細 デバイスの詳細ではモバイルデバイス、エンドポイントの基本的な情報（種類、オペレーティングシステム、デバイスID）、管理対象デバイスの数の推移などが確認出来ます。 基本的な モバイル デバイス と エンドポイント の詳細 デバイス レポート 会社所有のパソコンのインベントリ 高度なエンドポイント管理 高度なエンドポイント管理 はBusiness Plus以上のプランで利用可能です。 高度なエンドポイント管理では端末の監視だけでなく制御をするMobile Device Management (MDM)の要素が加わってきます。 機能としては以下のようになります。 セキュリティ設定 セキュリティーポリシーによるカメラの使用許可の制御や、AndroidでBYODを実施する場合に会社利用のアプリケーションを別ける 仕事用プロファイル を利用可能です。 標準型と強化型のパスコードの適用 モバイル デバイスのセキュリティ ポリシー Android の仕事用プロファイル ネットワーク管理 （モバイル） デバイスの管理 詳細管理により、ロック画面通知などのモバイル デバイス機能の制限、デバイスの暗号化の強制、Android デバイス / iPhone / iPad 上のアプリの管理、デバイスからのデータワイプを行えます。 iPhone / iPadを詳細管理するには Apple プッシュ証明書 を設定しましょう。 モバイルの詳細管理 Windows デバイス管理 * デバイスの承認 デバイスのリモートワイプ アプリの管理 一部の Android アプリでは 管理対象アプリ として設定を保存する事が可能で、例えばWi-Fi に接続されているときにのみデータを同期するかどうかの制御が可能です。 iOS アプリの管理 限定公開の Android ウェブアプリ モバイルアプリを個別に配布する † Android アプリの設定 デバイスの詳細 デバイスのデバイスIDだけでなくシリアル番号などの取得などより細かい部分の情報も取得する事が可能です。 会社所有のモバイル デバイスのインベントリ モバイル デバイスの詳細レポート デバイス管理については機能も多くプランによっての違いが分かりにくい部分があるかもしれません そんな時は弊社にお気軽にお声がけくださいね。 Google Workspaceを導入するなら株式会社G-genにご相談ください。 株式会社G-genではGoogle Workspace / Google Cloud（GCP）を5%割引でご提供しております。 g-gen.co.jp また、Google Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 お問い合わせはこちらから docs.google.com

G-gen の杉村です。Google Cloud (旧称 GCP) のマネージドな DNS サービスである Cloud DNS で、先日困ったことが発生しました。同じことが起きたときに誰かの助けになるよう、顛末と解決法を記載します。 やりたかったこと エラーメッセージ 解決方法 注意点 やりたかったこと Google Cloud (旧称 GCP) のフルマネージドな DNS サービスである Cloud DNS で、あるドメインを管理しています。これを仮に example.com とします。 ある日、とある理由からパブリックゾーンである example.com を別の Google Cloud プロジェクトの Cloud DNS に移動する必要性が出てきました。 当初考えた移行方法は、以下の通りです。 移行先プロジェクトにパブリックゾーン example.com を作成する 移行元ゾーンから gcloud コマンドによりレコードの内容を エクスポート し、移行先ゾーンに インポート する お名前ドットコム側に、移行先ゾーンの新しい NS レコードを登録する エラーメッセージ しかしながら、先ほどの手順 1. で移行先プロジェクトにパブリックゾーンを作成しようとしたところ、以下のようなエラーメッセージが出てしまいました。 http://www.google.com/webmasters/verification/ で「(ドメイン名)」ドメイン（または親）の所有権を確認してから、もう一度お試しください エラーメッセージ このエラーですが、以下のような条件のときに出てしまうようです。 既に Cloud DNS あるいは Google Domains でドメイン名の DNS を管理している この状態で Cloud DNS に同じドメイン名のパブリックゾーンを作成する うっかり英語版のエラーメッセージを取ることを失念していたのですが、 この公式ドキュメント に記載されている Verify ownership of the example.com domain (or a parent), and then try again. に該当しているようです。 解決方法 このエラーメッセージは、ドメイン名の悪用を防止するために Google の DNS で既に管理中のドメイン名について、パブリックゾーンが作成されたときに Google 側がドメインの所有権を確認するために出すメッセージです。 エラーメッセージにある http://www.google.com/webmasters/verification/ にアクセスし Google の ウェブマスター セントラル にてドメイン名を登録します。 ウェブマスター セントラル は Google 検索結果の順位の監視、管理、改善などのために Google によって提供されている Google Search Console の一部です。 ウェブマスターセントラル プロパティを追加 を押下してドメイン名の登録を進めます。 ドメインの所有権の確認には、 Google の指定する HTML ファイルを同ドメインを持つウェブサイトにアップロードするなどの方法もありますが、ドメインのゾーンに TXT レコードや CNAME レコードを追加する方法が選択できます。 ドメイン名の所有権の確認 指示された TXT レコードを移行元ゾーンに登録して所有権を確認したところ、それ以降は移行先プロジェクトに同じドメイン名でパブリックゾーンを作成することが可能になり、無事 DNS ゾーンを移行することができました。 注意点 一連の作業は、同じ作業者の Google アカウントで実施する必要があります。 ドメイン名の所有権の確認は Google アカウントに紐付いているようですので、所有権を確認された Google アカウントでゾーンの作成等を行う必要があります。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

今回は皆さんご存知Google Workspace(旧G Suite)のオススメプラン比較になります。 個人でGmailは使ってるけど会社やチームで利用した事は無い、検討しているけどどのプランを選べばいいのかな？BusinessやEnterpriseってあるけど各エディションの違いって何だろう？そういう方へご参考になれば幸いです。 Google Workspace 概要 エディション Business と Enterprise の比較 アカウント数上限 主要な機能比較 Business エディション内の比較 比較表 Businessプランの選び方 Business Starter を選択するケース Business Standard を選択する場合 Business Plus を選択する場合 Google Workspace の導入 概要 Google Workspace の 公式サイト には「あらゆる働き方に対応する生産性向上とコラボレーションのツール。」とあり、また従業員の生産性 = チーム x 会社の文化 = コミュニケーション + コラボレーションと言い換える事が出来ます。 その組織のコミュニケーションとコラボレーションを下支えし促進するツールが Google Workspace です。 Google Workspace の特徴として各ツールが独立して存在するのでは無く、チームの力を最大化する為に各々のツールが密に連携している事にあります。 例えば通常はチャットとドキュメント作成は別々の会社のツールを利用している場合があるでしょう、Google Workspaceではチャットやビデオ会議などでコミュニケーションを取りながらシームレスに資料作成をする事が可能です。 G-gen 社は、全員フルリモートで勤務しています。PC 端末は Chromebook、ツールとして Google Workspace を使って仕事をしています。リクルートの面においてもこういった働き方がアピール出来るというのは企業にとって大きなアドバンテージになるのではないでしょうか。 Google Workspace の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp エディション 以下は、公式のプラン・料金ページです。 workspace.google.co.jp エディションを大きく分けると Business と Enterprise に分かれます。Enterprise エディションは Business エディションの上位エディションです。 Business と Enterprise の比較 アカウント数上限 まずは Businessの最上位エディションである Business Plus と Enterprise を比較してみます。まずは一番分かりやすい点として、アカウント数の上限があります。 　 Business Plus Enterprise 利用可能人数 300人まで 無制限 上記では Enterprise エディションはひと括りになっていますが、実際には Enterprise Essentials 、 Enterprise Standard 、Enterprise Plus** に分かれています。 Google Workspace を利用する人数が 300名以上でしたらEnterpriseを利用 することになります。 また300名以下の場合でも、PC 端末やスマートフォンを管理下に置いて監視や制限をかけたい場合にも Enterprise が検討対象になります。 主要な機能比較 参考として Business エディションの最上位プランである Business Plus と Enterprise の各プランでの、主な機能比較を記載します。 2011年11月現在の情報ですので、最新情報は以下の公式ドキュメントをご参照ください。 参考 : Google Workspace の各エディションの比較 Business Plus Enterprise Essentials Enterprise Standard Enterprise Plus 基本情報 月額料金（1ユーザーあたり※税別） 2,040円 お問い合わせ お問い合わせ お問い合わせ ユーザー上限数 300人 指定なし 指定なし 指定なし ストレージの容量 5 TB *5人以上のユーザーが必要 （4人以下の場合は１TB） 1TB 必要に応じて拡張可能 必要に応じて拡張可能 メール Gmail ✔ ✔ ✔ IMAP クライアントと POP クライアント ✔ ✔ ✔ Google Meet 会議あたりの参加者数の上限 250 150 250 250 ドメイン内および信頼できるドメインのライブ ストリーミング 1万人 10万人 Google Chat Chat でのファイルの共有を管理する ✔ ✔ ✔ Chat とサードパーティ製アーカイブ ソリューションとの連携 ✔ ✔ Google グループ グループ メンバーを精査する ✔ ✔ グループ メンバーを制限する ✔ ✔ 動的グループ（メンバーシップを自動的に管理） ✔ ✔ ネストしたグループのメンバーを確認（間接的なメンバー） ✔ ✔ セキュリティと データ保護 信頼できる外部ドメインとの連携 ✔ ✔ ✔ データ損失防止（DLP） ✔ ✔ ユーザーとデバイスの状況に基づくアクセス制御 ✔ ✔ Google サービスのセッション継続時間を設定する ✔ ✔ ✔ Cloud Identity Premium ✔ ✔ セキュリティ センター: セキュリティ ダッシュボード ✔ ✔ セキュリティ センター: セキュリティ調査ツール ✔ ✔ セキュリティ センター: セキュリティの状況ページ ✔ ✔ Fundamental データ リージョン ✔ ✔ Enterprise データ リージョン ✔ クライアントサイド暗号化（ベータ版） ✔ 移行プロダクト HCL Notes から移行する ✔ ✔ ✔ レポートと監査ログ ドライブの詳細な監査とレポート ✔ ✔ ✔ BigQuery へのレポートのエクスポート ✔ ✔ 管理アクティビティのアクセスの透明性ログ ✔ ユーザーに関するワーク インサイト レポート ✔ サードパーティ製 アプリとの連携 セキュア LDAP: LDAP ベースのアプリやサービスを接続する ✔ ✔ ✔ パスワードが保管されたアプリへのアクセスを管理する ✔ ✔ デバイス管理 モバイルアプリを個別に配布する ✔ ✔ ✔ デバイス監査ログ ✔ ✔ ✔ 使われていない会社所有デバイスに関するレポート ✔ ✔ ✔ 会社所有の Android デバイス ✔ ✔ ✔ 会社所有の iOS デバイス ✔ ✔ Windows デバイス管理 ✔ ✔ iOS データの保護 ✔ ✔ デバイスのリモートワイプ（Windows） ✔ ✔ モバイル デバイスの証明書 ✔ ✔ 管理ルール ✔ ✔ ドライブ ドキュメントエディタ コネクテッド シート ✔ ✔ ✔ 組織のブランディング（カスタム テンプレート） ✔ ✔ ✔ Chrome ブラウザでドライブのファイル候補の使用を許可する ✔ 前述のとおり Business Plus でも主要な機能はサポートされていますが、ライブストリーミングやデバイス制御や管理、レポーティングと言った機能は利用出来ません。 また Enterprise Essentials は「300名以上で Google Workspace を利用したいが、メールシステムは他に持っているため直ちに移行することは難しい」「まずはコミュニケーション（Google Chat）やコラボレーション（ドライブ、ドキュメントエディタ）だけ利用したい」といったユースケースでおすすめです。HCL Notes からの移行が含まれているのも Enterprise ならではと言えるでしょう。 Enterprise のエディションに関しては検討すべき要件も多いため、ぜひ当社までご相談ください。 g-gen.co.jp Business エディション内の比較 比較表 次に Business に分類される3つのエディション Business Starter 、 Business Standard 、 Business Plus を比較します。 Business Starter Business Standard Business Plus 基本情報 月額料金（1ユーザーあたり※税別） 680円 1,360円 2,040円 利用可能人数 1〜300名 1〜300名 1〜300名 ストレージ容量 30GB 2TB 5TB 24時間365日の電話サポート ✔ ✔ ✔ コアサービス Gmailとカレンダー ✔ ✔ ✔ Cloud Searchによるドメイン内検索 ✔ ✔ Google Vault ✔ Google Chat ✔ ✔ ✔ ドライブと ドキュメント ドキュメントの作成 ✔ ✔ ✔ チーム向け共有ドライブ ✔ ✔ ✔ Google Meet 会議あたりの参加者数の上限 100名 150名 250名 会議の録画とドライブへの保存 ✔ ✔ ノイズ キャンセル ✔ ✔ ブレイクアウト ルーム ✔ ✔ セキュリティと データ保護 信頼できる外部ドメインとの連携 ✔ ✔ データリージョンの選択 ✔ ✔ デバイス管理 基本のエンドポイント管理 ✔ ✔ ✔ 高度なエンドポイント管理 ✔ モバイルアプリの個別配布 ✔ Businessプランの選び方 Business Starter を選択するケース まずは少人数（10名以下）でコストを抑えて Google Workspace を使った働き方にチャレンジしたい場合にオススメします。 主要な機能であるドキュメント作成、メール、カレンダー、ビデオ会議、チャットなどを利用する事が出来ます。 例えば全社に導入する前に少人数でテスト的に利用してみるのも良いでしょう。 Business Standard を選択する場合 より共同作業（コラボレーション）を促進し、生産性向上をはかりたい場合にオススメします。 Business Standard からはストレージの容量が一気に1ユーザーあたり２TBまで増えます。 またビデオ会議では「会議の録画」「ノイズキャンセル」「ブレイクアウトルーム」など、オンライン会議だからこそのコラボレーション機能が強化されます。 また同一ドメイン内の Gmail、ドライブ、ドキュメント、カレンダーなどに含まれるデータを包括的に検索し提案する「Cloud Search」を利用する事が可能となります。 Business Plus を選択する場合 大容量のストレージと更にセキュリティを高めたい場合にオススメします。 Business Plus ではストレージの容量が1ユーザーあたり５TBになります。 さらに Business Standard の機能に加えて Google Workspace のあらゆるデータの保持、検索、書き出しを行うことができる情報開示・ガバナンスの為の「Google Vault」、エンドポイント管理などよりセキュリティに重点を置いた機能が強化されます。 安全に Google サービスを活用したい場合にはぜひ活用ください。 Google Workspace の導入 Google Workspace を導入するなら株式会社G-genにご相談ください。Google Workspace を使った働き方に変えると本当に組織のコミュニケーションとコラボレーションのあり方が変わって、驚くはずです。 この感動をより多くの人に体感してもらいたいですね。 株式会社 G-gen では Google Workspace / Google Cloud (旧称 GCP) を5%割引でご提供しております。 g-gen.co.jp また Google Workspace / Google Cloud / Chromebook の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの杉村です。 Cloud Logging は Google Cloud（旧称 GCP）上のシステム等が生成したログを収集・保管・管理する仕組みです。基本的な概念や仕組みを解説していきます。 Cloud Logging 概要 Cloud Logging とは 対象のログ ログの保存先 Cloud Logging が扱うログ プラットフォーム ログ、コンポーネント ログ 監査ログ ユーザー作成のログ マルチクラウドとハイブリッド クラウドのログ 料金 Cloud Logging の料金 最初から存在するログバケットの料金 取り込み料金の節約 ログの閲覧 閲覧方法 クエリ言語 インデックス ログの閲覧可能範囲を定義する ログビュー ログスコープ ログルーティングとログの保存 ログルーティングとは シンクとは 初期設定で存在するシンクとログバケット 書き込み ID プロジェクトをまたいだログの集約 別プロジェクトのストレージにログを送る 組織全体でログを集約する 集約シンクの種類 ログ監視 ログベースの指標 ログベースのアラート Log Analytics Log Analytics とは 利用方法 BigQuery データセットとのリンク ユースケース 制限 Log Analytics の料金 サービス間連携 Cloud Run functions のログ Compute Engine VM（Windows）のログ Tips Cloud Logging 概要 Cloud Logging とは Cloud Logging （旧称 Stackdriver Logging）は Google Cloud 上のシステム等が生成したログを収集・保管・管理する仕組みです。 各 Google Cloud サービスが出力するログは自動的に Cloud Logging に集約されます。また、Cloud Logging の Web API やエージェントソフトウェアを通じて、任意のログを収集することもできます。 収集されたログは ログバケット と呼ばれるストレージで保管され、期限が過ぎたら廃棄する等の設定を簡単に行うことができます。ログバケットの他にも、Cloud Logging や BigQuery など他のストレージにログを転送することも容易です。 ログは Web コンソールである ログエクスプローラ で閲覧・クエリすることができます。さらに、指定の文字列がログに出力された際にアラートを発報する設定も可能です。 対象のログ Cloud Logging で収集・管理可能なログには、以下の種類があります。 参考 : Cloud Logging の概要 - ログのカテゴリ 種別名 説明 プラットフォームログ BigQuery や Cloud Run 等、ほとんどの Google Cloud サービスのログ コンポーネントログ Google が提供するソフトウェア コンポーネントが生成するログ。Google Kubernetes Engine（GKE）の管理機構が出力するログなど 監査ログ Cloud Audit Logs やアクセスの透明性ログ（Google サポート等がユーザのコンテンツにアクセスした際に出るログ） ユーザー作成のログ ユーザーのアプリケーションなどによって出力したログ。エージェントや API 経由で収集 マルチクラウドとハイブリッド クラウドのログ Microsoft Azure や Amazon Web Services（AWS）から取り込んだログやオンプレミスから取り込んだログ ログの保存先 Cloud Logging の保存先ストレージは以下から選択できます。 ログバケット Cloud Storage バケット BigQuery データセット Pub/Sub トピック Splunk 他の Google Cloud プロジェクト ログバケット は Cloud Logging 独自の専用ストレージです。Cloud Storage バケットと名称が似ていますが、 全く別のもの です。ログバケットに保管されているログだけが、 Cloud Logging コンソールのログエクスプローラから閲覧できます。 ログバケットへのログ保管料金は、以下の公式ドキュメント「Google Cloud Observability の料金」の「Cloud Logging の料金概要」部分に記載されている「ロギング保持」がそれにあたり、$0.01/GiB（2025年2月現在）であり、Cloud Storage バケットの Standard Storage や Nearline Storage よりも少し安い価格設定です。 参考 : Google Cloud Observability の料金 - Cloud Logging の料金概要 参考 : Cloud Storage の料金 - 料金表 Cloud Logging が扱うログ プラットフォーム ログ、コンポーネント ログ ユーザーが意識しなくとも、様々な Google Cloud サービスが Cloud Logging にログを出力しています。 これにより、利用者は Web コンソール画面でいちいち各 Google Cloud サービスの画面へ遷移しなくても、Cloud Logging で集中的にログを管理・閲覧することができます。 Cloud Run や Cloud Run functions 等の Google Cloud サービスで稼働するプログラムは、何も設定しなくても、標準出力が Cloud Logging にログエントリとして連携されます。ただし、適切なフォーマットで出力することで Severity（重要度）などの属性値を、閲覧しやすい形で出力できます。以下の記事も参考にしてください。 blog.g-gen.co.jp 監査ログ Cloud Audit Logs サービスによって生成されるログです。 Cloud Audit Logs については以下の投稿で解説していますので、そちらを参照してください。 blog.g-gen.co.jp ユーザー作成のログ ユーザーが明示的に Cloud Logging に投入したログです。 Google Compute Engine（GCE）の VM 等から Ops エージェント などを通して投入することができます。 Cloud Logging にログを投入することで以下のようなメリットを享受できます。 ログ閲覧の際にサーバにログインする必要がない サーバ障害やスケールインした際にもログが失われない 分析目的でログを BigQuery に投入できる ログの保管と保管期限の管理（ハウスキーピング）が容易に実装できる VM に Ops エージェントをインストールするとデフォルトで、Linux では /var/log/messages や /var/log/syslog が、 Windows では System 、 Application 、 Security のイベントログが収集されます。 デフォルトで収集されるログ以外にも、設定ファイルを変更することで、任意のアプリケーションのログを収集することができます。 詳細は公式 ドキュメント を参照ください。 Compute Engine の VM から Cloud Logging にログを送出する方法については、以下の記事もご参照ください。 blog.g-gen.co.jp マルチクラウドとハイブリッド クラウドのログ Microsoft Azure や Amazon Web Services（AWS）から取り込んだログやオンプレミスから取り込んだログです。 Ops エージェント等を通じて、Google Cloud 以外のプラットフォームからもログを収集し、管理することができます。 料金 Cloud Logging の料金 Cloud Logging の料金はログの 取り込み処理量 と ストレージ保管量 の2軸での従量課金です。 「取り込み処理量」への課金は、Cloud Logging ログバケットに取り込むログのサイズに応じて、ワンショットの料金が発生します。 「ストレージ保管量」への課金は、ログバケットで保管しているログのサイズに応じて、継続的に発生する料金です。 2025年2月現在の料金単価は、以下のとおりです。 料金名 単価 説明 取り込み処理量 $0.50 / GiB ・Cloud Logging ログバケットに投入されたログのデータサイズに応じて一度だけ課金 ・毎月、プロジェクトごとに最初の 50 GiB は無料 ストレージ保管量 $0.01 / GiB ・ログバケット上に30日間以上保管されたログにのみ適用（30日間以内は無料） ・ログを BigQuery や Cloud Storage 等、他サービスに転送する場合はそちらの料金が発生 最新の料金単価は以下のページを参照してください。なお以下のドキュメントでは、前者の「取り込み処理量」は「Logging ストレージ」、後者の「ストレージ保管量」は「ロギング保持」と表現されています。 参考 : Google Cloud Observability の料金 - Cloud Logging の料金概要 最初から存在するログバケットの料金 Google Cloud プロジェクトを作成すると、デフォルトで _Required と _Default という2つのログバケットが存在しています。 _Required は、Google Cloud が必須で取得する監査系のログが投入される特殊なログバケットです。ここに保存されるログは、取り込み料金もストレージ料金も発生しません。 _Default は、 _Required に保存されるログ 以外のログ がすべて保存されるログバケットです。このログバケットは、初期設定で保持期限が30日ですので、保持期限を変更しなければストレージ料金は発生しません。ただし、取り込み処理料金は発生することに注意してください。 取り込み料金には、プロジェクトごとに最初の50GiBまでが無料枠として用意されていますので、相当のサイズまでは無料で取り込むことができます。 取り込み料金の節約 ログのボリュームが大きくなると、$0.50 / GiB の取り込み料金はコストとして重くのしかかってきます。 この取り込み料金は Cloud Logging ログバケットに対して取り込むログサイズに対してのみ 発生します。つまり、以下のログに対しては料金が発生しません。 シンク（後述）により Cloud Storage バケット、BigQuery データセット、Pub/Sub トピック等にルーティングされたログ シンクの除外フィルタで除外したログ ログ量が莫大になり、取り込み料金が多く発生している場合、除外フィルタで取り込むログをフィルタリングしたり、Cloud Storage や BigQuery に逃がすことで、取り込み料金を節約できます。ただし、ルーティング先の取り込み料金は発生しますので、そちらを確認する必要はあります。 参考 : クラウド管理者向けの Cloud Logging の料金: そのアプローチと費用を削減する方法 例として Cloud Logging ログバケットへの取り込みと BigQuery へのエクスポートで料金を比較すると、以下の通りです。 Cloud Logging ( 取り込み料金 ) : $0.5 /GB (2023年5月時点) BigQuery ( Streaming inserts 料金 ) : $0.06 /GB ($0.012 per 200 MBと表記。東京リージョン、2023年5月時点) BigQuery へログをエクスポートすると Streaming inserts 料金が発生しますが、Cloud Logging ログバケットへの取り込み料金と比較して、10分の1近くの料金設定となっています。 ログの閲覧 閲覧方法 Cloud Logging のログバケットに保存されたログは、Google Cloud の Web コンソール内に存在する ログエクスプローラ と呼ばれる画面で閲覧することができます。 ログエクスプローラ また他にも、gcloud コマンドラインツール等を用いてログを取得することも可能です。 参考 : ログ エクスプローラを使用してログを表示する 参考 : gcloud CLI を使用してログエントリをリスト表示する クエリ言語 ログエクスプローラや gcloud コマンドでは、独自のクエリ言語である Logging query language を用いて、ログをフィルタして表示させることができます。 Logging query language は、ログエクスプローラから直感的に生成することもできますので、ゼロから時間をかけて学習する必要性はありません。公式のリファレンスは以下のリンクから参照できます。 参考 : Logging のクエリ言語 以下は、クエリの例です。 my-project というプロジェクトにおける Cloud KMS 関連のログだけを抽出しています。 protoPayload.serviceName="cloudkms.googleapis.com" resource.labels.project_id="my-project" 以下の当社記事では、Logging query language について詳細に解説しています。 blog.g-gen.co.jp インデックス Cloud Logging には インデックス の概念があります。 以下のフィールドにはデフォルトでインデックスが作成されており、クエリに含めることで、ログ抽出を高速化できます。 resource.type resource.labels.* logName severity timestamp insertId operation.id trace httpRequest.status labels.* split.uid またログバケットごとに、フィールドに対して カスタムインデックス を明示的に指定することができます。 参考 : Configure custom indexing ログの閲覧可能範囲を定義する ログビュー ログビュー とは、ログバケットに保存されているログの一部のみ（ログのサブセット、と表現します）を利用者に閲覧させたい場合に、事前に定義したログ範囲のみの閲覧権限を付与できる機能です。 ログビューでは、対象のログバケットと、Logging query language で記述するフィルタを定義します。管理者はログ閲覧者のために、このログビューに対する閲覧権限を付与します。これにより、閲覧者は定義されたログバケット内のフィルタされたログだけを閲覧できるようになります。 詳細と具体的な手順は以下のドキュメントを参照してください。 参考 : ログバケットのログビューを構成する ログスコープ ログスコープ とは、複数の Google Cloud プロジェクトの Cloud Logging ログを、横断して閲覧するための機能です。 通常、ログエクスプローラでは、単一のプロジェクトのログバケットを対象としたログのクエリ・閲覧しかできません。 ログスコープを使うと、複数のプロジェクトやログビューをグルーピングすることができます。ログエクスプローラ上でログスコープを対象にしてクエリを投入すると、複数のプロジェクトやログビューを横断してログが検索されます。 ログスコープ自体は、プロジェクトレベルのリソースとしてプロジェクト内に作成します。 当機能を使って各プロジェクトのログを閲覧するには、閲覧者が対象のプロジェクトにログの閲覧権限を持っている必要があります。 参考 : Create and manage log scopes ログスコープ機能は2025年2月現在、Preview 段階です。 ログルーティングとログの保存 ログルーティングとは Cloud Logging で特に重要な概念が ログルーティング および シンク （sink）です。おおまかな概念を以下に図示します。 参考 : 転送とストレージの概要 参考 : サポートされている宛先にログをルーティングする ログルーティングの概念 図の最上部は、ログの発生元を表しています。ここからログが Cloud Logging API に向けて投入されます。 投入されたログは ログルーター という Cloud Logging の内部機構により、振り分け先を決定されます。ログルーターは シンク という個別設定を持っており、ログはシンクに定義された設定に応じて保存先に振り分けられます。 ログの振り分け先としてログバケット 、Cloud Storage バケット、BigQuery データセット、Pub/Sub トピック、他の Google Cloud プロジェクト、Splunk を指定することができます。 シンクとは シンク は Cloud Logging に入ってきたログの振り分けをするコンポーネントです。 API を通じて Cloud Logging に入ってきたログは、シンクによって宛先であるログバケットや BigQuery などに振り分けられます。 シンクは設定値として 1. ログの保存先 、2. 包含フィルタ 、3. 除外フィルタ を持ちます。 まず 1. ログの保存先 は前述の通り「ログバケット」、「Cloud Storage バケット」、「BigQuery データセット」、「Pub/Sub トピック」等からいずれかを指定します。 そして 2. 包含フィルタ と 3. 除外フィルタ は、そのシンクがどのログを ログの保存先 に振り分けるかを決定するためのフィルタであり、 Logging query language で定義します。以下のようなものです。 resource.type="bigquery_dataset" AND LOG_ID("cloudaudit.googleapis.com/activity") AND protoPayload.methodName="google.cloud.bigquery.v2.DatasetService.UpdateDataset" 上記は「BigQuery データセットが UpdateDataset により更新されたときに発生したアクティビティログをキャッチせよ」という意味です。 参考 : フィルタの例 なお、複数のシンクでフィルタの設定が重複していて、同じログをキャッチするようになっている場合、それら全てのシンクにログが 複製されて振り分けられ ます。 たとえばシンク A はあるログをあるログバケットに転送する設定になっており、シンク B は同じログを BigQuery に投入する設定になっているとします。この場合は、ログバケットと BigQuery の両方に、同じログが投入されます。 初期設定で存在するシンクとログバケット 初期設定で _Required と _Default というシンクが存在しています。それぞれのシンクは _Required と _Default というログバケットにログをルーティングする設定になっています。 _Required ログバケットには「管理アクティビティ監査ログ」「システム イベント監査ログ」「アクセスの透明性ログ」が保存され、400日間保存されます。なお「管理アクティビティ監査ログ」「システム イベント監査ログ」は Cloud Audit Logs という監査ログの仕組みによって取得されるログです。 _Default ログバケットには、 _Required に入らない全てのログが入るように初期設定されています。この設定は変更可能です。 これらのバケットに発生する料金は前述の 最初から存在するログバケットの料金 をご参照ください。 参考 : ログバケット 書き込み ID シンクを作成した際、ログの振り分け先が「そのシンクが所属するプロジェクトのログバケット 以外 」である場合、 書き込み ID （Writer Identity）と呼ばれるサービスアカウントが生成されます。 ログをルーティングするには、この書き込み ID に対して、書き込み先への権限を付与する必要があります。 書き込み ID の名称はコンソールでログシンクを選択し「シンクの詳細を表示する」を押下したり、gcloud で gcloud logging sinks describe ${SINK_NAME} を実行することで確認できます。 書き込み ID の確認 例えば書き込み先が BigQuery データセットの場合、当該のプロジェクトや BigQuery データセットにおいて、書き込み ID に BigQuery データ編集者 権限を付与する必要があります。 参考 : エクスポート先の権限を設定する なおシンクと同じプロジェクト内のログバケットへログを送る際は、書き込み ID は不要であり、作成されません。 書き込み ID はシンクを作成するごとに一意に生成されます。後述する集約シンクを作成する際には組織レベルやフォルダレベルでシンクを作成しますが、シンクが作成されるレベルによって書き込み ID の命名規則が異なります。 No シンクのレベル 書き込み ID の名称 1 プロジェクトに作成されたシンクの書き込み ID p(プロジェクト番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com 2 フォルダレベルで作成されたシンクの書き込み ID f(フォルダ番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com 3 組織レベルで作成されたシンクの書き込み ID o(組織番号)-(6桁数字)@gcp-sa-logging.iam.gserviceaccount.com プロジェクトをまたいだログの集約 別プロジェクトのストレージにログを送る Cloud Logging のシンクを使い、別のプロジェクトのログバケットや BigQuery データセットにログをルーティングすることができます。 この場合、シンクの書き込み ID が宛先のストレージに対して書き込み権限を持っている必要があります。 またシンクの宛先を「他の Google Cloud プロジェクト」にした場合、宛先プロジェクト内のログシンクに処理を委任することができます。次の項で説明するような組織構成を使わない場合でも、この方法でログの処理を1プロジェクトに集約することが可能です。 組織全体でログを集約する 以下のような理由で、組織全体でログを一つのプロジェクトのログバケットや BigQuery に集約したい要件が出てくるかもしれません。 複数プロジェクトのログを集約して SIEM 等で分析したい 監査などの理由で監査ログを第三者に提出する必要がある 複数プロジェクトでアプリケーションが稼働しておりログを横断して確認したい その際は、シンクを組織やフォルダのレベルで作成し、配下の全てのプロジェクトのログを収集することが可能です。このように複数プロジェクトのログを集約するためのシンクを 集約シンク （Aggregated sinks）といいます。 参考 : 組織レベルとフォルダレベルのログをサポートされている宛先に照合して転送する シンクを作成する際に「 このリソースとすべての子リソースによって取り込まれたログを含める 」オプションを有効化することで、その組織/フォルダ配下の全てのプロジェクトに対してシンクが有効になり、ログ集約用のプロジェクトにログを収集できます。 詳細な手順は、以下を参考にしてください。 参考 : 組織のログをログバケットに保存する シンクによるログの集約 なお、単純に複数のプロジェクトを横断してログを確認したい場合、前述のログスコープ機能を使うこともできます。 集約シンクの種類 集約シンクの作成時、 非インターセプト型集約シンク （non-intercepting aggregated sink）と インターセプト型集約シンク （intercepting aggregated sink）の2種類から選択可能です。 前述の通り、組織の上流（組織のルートやフォルダ）で集約シンクを使用すれば、下流の子リソース（プロジェクト等）で発生するログを集約することが可能ですが、非インターセプト型集約シンクの場合は、親リソースの非傍受型集約シンクで収集したログは、子リソースでも収集することができます。一方のインターセプト型集約シンクの場合、上流のシンクで収集したログはそれより下流の子リソースでは収集できません。 インターセプト型シンクを使えば、子リソースでログを重複して収集し、ログ収集コストが肥大化することを避けることができます。逆に、子リソースでもログを自由に収集できるようにしたい場合は、非インターセプト型のシンクを利用します。 なおインターセプト型シンクは子リソース（プロジェクト）からも閲覧できます（コンソールのログルーター画面に表示されます）。 参考 : Overview ログ監視 ログベースの指標 Cloud Logging でログの特定文字列を正規表現で検知し、その検知数を Cloud Monitoring に指標（メトリクス）として送信することができます。これを ログベースの指標 と呼びます。 この指標を Cloud Monitoring のアラートポリシー機能により検知・発報することで「XXログで Error という文字列を5分間で3個以上検知したらメール通知する」のようなログ監視が可能になります。 手順は以下をご参照ください。 参考 : ログベースの指標の概要 参考 : 指標ベースのアラート ポリシーを作成する アラートポリシーについては、以下の記事もご参照ください。 blog.g-gen.co.jp ログベースのアラート ログベースのアラート は、Cloud Logging に出力されたログエントリの文字列を検知して、E メールや Slack 等に対して通知を発報する機能です。 検知対象の文字列を指定してログベースのアラートを設定することで、アプリケーションや Google Cloud サービスのエラー等を検知して、運用者や管理者に対してアラートを発報することができます。 前述のログベースの指標による発報方法は、いったんログ文字列の検知数を Cloud Monitoring の指標としてカウントしますが、この「ログベースのアラート」では特定の文字列を検知すると直接、アラートを発報できます。 この「ログベースのアラート」は前述の「ログベースの指標 + アラートポリシー」とほとんど同じことが可能ではありますが、「ログベースのアラート」では文字列検知数を指標化しないため、数値として後から統計が取れない代わりに、より少ないステップで設定可能であり、後から見ても設定がわかりやすいという違いがあります。 参考 : ログベースのアラートを構成する Log Analytics Log Analytics とは Log Analytics （ログ分析）は、Cloud Logging ログバケットに格納されているログに対して SQL でクエリすることができる機能です。 当機能リリース以前は、ログに対して SQL でクエリをかけるにはログルーター (シンク) を使って BigQuery へログをエクスポートする必要がありました。2023年1月に当機能が GA されて以降は、当機能により Cloud Logging ログバケットに直接 SQL を実行することが可能になりました。 またもう一つの機能としてログバケットを BigQuery データセットとリンク することができます。 BigQuery データセットとリンクされたログバケットは BigQuery 側からビューとして使うことができます。これにより BigQuery の他のデータと結合しての分析も可能になります。 参考 : ログ分析 利用方法 ログに SQL を実行するには、ログバケットごとに Log Analytics を 有効化 する必要があります。 有効化されたログバケットに対して Google Cloud コンソールの Log Analytics ページから BigQuery 標準 SQL を実行することができます。 コンソール画面 BigQuery データセットとのリンク ログバケットごとに BigQuery データセットとのリンク を行うことができます。 リンクすると BigQuery に新規データセットが作成され、その中に _AllLogs というビューが生成されます。このビューに対してクエリを実行することでログを抽出できます。 BigQuery を使って _AllLogs ビューに対してクエリを実行すると、スキャンしたデータ量に応じて BigQuery のクエリ料金が発生します。一方で Log Analytics 画面からのクエリは無料です。 ユースケース Log Analytic は、アプリケーションのトラブルシューティングや、アプリログを BigQuery の自社データやパブリックデータセット等と結合する等の用途が想定されます。 従来、こういった分析をするためにログルーター（シンク）を使って BigQuery にログをエクスポートして長期保存することもありました。しかし Log Analytics 登場後は、事情が変わります。 Cloud Logging のログバケットの保存料金は、 BigQuery のストレージ料金（アクティブ/長期保存）と同等あるいは安価なためです。最終的に Cloud Logging ログバケットに保存したほうが安価になるのか、あるいは BigQuery の方が安価になるのか、については後述します。 参考 : Cloud Logging pricing summary 参考 : BigQuery - Storage pricing 制限 代表的な制限のみを記載します。 クエリできるのは Log Analytics 有効化後に発生したログのみ ログバケットが CMEK 暗号化されていない ログバケットがロックされていない その他の制限や最新情報は以下の公式ドキュメントをご参照ください。 参考 : 制限事項 Log Analytics の料金 Log Analytics では通常の Cloud Logging 以外に発生する追加料金はありません。Log Analytics 画面からクエリした場合、クエリ料金も無料です。 一方でログバケットを BigQuery データセットとリンクして BigQuery からクエリした場合 BigQuery のクエリ料金が発生します。 ログをログバケットに保存するのと、BigQuery にエクスポートするのでは、最終的にどちらが安価になるのでしょうか。それには、以下の要素が関わってきます。 ログ取り込み時の料金 Cloud Logging ( 取り込み料金 ) : $0.5 /GB (2023年5月時点) BigQuery ( Streaming inserts 料金 ) : $0.06 /GB ($0.012 per 200 MBと表記。東京リージョン、2023年5月時点) クエリ時の料金 Cloud Logging (Log Analytics 画面) でのクエリ : 無料 BigQuery でのクエリ ( オンデマンド料金 ) : $6 /TB (最初の 1TB は無料) (東京リージョン、2023年5月時点) つまり、ログ取り込みの料金は BigQuery の方が安価ですが、クエリ時の料金は Cloud Logging（Log Analytics 画面）のほうが安価（無料）ということで、一長一短です。利用実績を確認し、どちらのほうが安価になるかを判断してから決定することになります。 サービス間連携 Cloud Run functions のログ 以下は、Cloud Run functions から Cloud Logging へログを投入する方法について解説した記事です。Cloud Run functions では、標準出力に文字列を出力するだけで Cloud Logging へログとして投入されますが、特定の設定をすることで 重要度（Severity）等を設定することができます。 blog.g-gen.co.jp Compute Engine VM（Windows）のログ 以下の記事では、Compute Engine VM から Cloud Logging へ任意のログファイルを取り込むための方法を紹介しています。Ops Agent という Cloud Monitoring のエージェントソフトウェアをインストールすることで実現できます。 blog.g-gen.co.jp Tips 以下の記事では、Cloud Logging の運用上の Tips が紹介されています。 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 Keepを利用したタスク管理について説明していきたいと思います。 Google Keepとは Google Keepの基本操作 ラベルの作成 色の変更とリマインダーの設定 担当者の割り当て Googleカレンダーとの連携 Google Keepとは Google Keep Google Keepとは、Google Workspace(旧 G Suite)に無料で含まれている 多機能メモアプリケーション になります。携帯用のアプリケーションも提供されていますので、外出先からなにか忘れてはいけないことをメモしたりすることができます。 では今回はそんなGoogle Keepを利用して 組織のメンバーとタスク管理 する方法を紹介いたします。しかも、はやりの 看板管理 で。 Google Keepの基本操作 はじめに、Google Keepの基本操作をみていきましょう。初期画面は、以下のような画面になります。 Google Keepの初期画面 画面中央の左から以下のようなイメージなります。 ・単純なリスト ・ホワイトボードのような描画入り ・写真入り Google Keepの基本的な使い方 それでは次の項目より以下を説明いたします。 ・タスクを識別するラベルの作成 ・色の変更とリマインダーの設定 ・担当者の割り当て ・Google カレンダーとの連携 ラベルの作成 でははじめに準備として、タスクをわかりやすく識別するために、左側のペインの ラベルの編集 よりラベルを作成していきましょう。 今回は「新規開発プロジェクト」というラベルを作成してみます。 ラベルの作成 すると、上記画像のようにいままであったタスクがなくなりました。これは最初に作成した3つのタスクに「新規開発プロジェクト」といラベルが貼られていないためです。 このように、ラベルを使ってプロジェクトごと、業務種別ごと。など、さまざまな角度からタスクをグルーピングすることができます。 色の変更とリマインダーの設定 すべてのタスクが白だと、わかりにくいですよね。そんなときは各看板の パレット の絵をクリックして、以下のように色を変えてみましょう。 色の変更 また、各タスクに対してリマインダーを設定することも可能です。以下のように、ベルのマークからリマインドを設定してみましょう。 リマインダーの設定 このように設定することで、各タスクを一覧でみることができ。かつ、納期管理もできるようになりました。 担当者の割り当て 実際のプロジェクトとなると、一人で進めることはあまりないかと思います。他のメンバーとタスクを共有しながら進めることが一般的です。 その場合には各タスクに担当者を割り当ててみましょう。 以下のように 人のマーク から組織内の別のメンバーを割り当てることが可能です。 担当者の割り当て(1) 担当者の割り当て(2) これで他のメンバーとタスクを共有することができました。 Googleカレンダーとの連携 Google Workspaceは様々な機能が自動的に連携しています。そのため何もせずとも他のアプリケーションで状況を確認することが可能です。 では実際に Googleカレンダーからタスクを見る方法 を説明いたします。 それは簡単。以下のようにGoogleカレンダーのマイカレンダーより「リマインダー」を選択することでタスクで設定したリマインドの日に表示することが可能です。 Google カレンダーとの連携 とっても簡単ですね。全体的に管理すると以下のようなイメージになります。 Google Keep利用イメージ このように、Google Keepをうまく利用することでタスクを看板管理することが可能になります。ぜひ、ご利用ください！ Google Cloud(旧GCP) / Google Workspace導入に関するお問い合わせ Google Workspace 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-gen の杉村です。Google Cloud のリソースモニタリングのためのプロダクトである、 Cloud Monitoring を解説します。 Cloud Monitoring の概要 Cloud Monitoring とは Cloud Monitoring の料金 リソースモニタリング Google Cloud の指標 カスタム指標 複数のプロジェクトの指標を表示する Ops エージェント Ops エージェントの指標 Ops エージェントのセットアップ VM の要件 トラブルシューティング ダッシュボード アラート 概要 通知チャネル 設定方法 稼働時間チェック 稼働時間チェックとは 公開の稼働時間チェック 非公開の稼働時間チェック Prometheus Query Language（PromQL） Cloud Monitoring の概要 Cloud Monitoring とは Cloud Monitoring は Google Cloud（旧称 GCP）の Google Cloud Observability と呼ばれるサービス群の1つで、各種 Google Cloud サービスからパフォーマンスデータ等を収集して保存・閲覧可能にするサービスです。データ収集元として、Google Cloud の各種サービスのほか、オンプレミスや Amazon Web Services （AWS）上の仮想サーバなども対象にすることができます。 参考 : Cloud Monitoring の概要 Cloud Monitoring では、デフォルトで収集するデータ（後述の「Google Cloud の指標」など）に対しては課金されず、基本機能は無料で使用することができます。 なお Google Cloud Observability はかつてはオペレーションスイート、その前は Google Stackdriver と呼称されていましたが、改称されました。 参考 : Google Cloud のオブザーバビリティ Cloud Monitoring の料金 Cloud Monitoring は、多くの場合で無料で利用することができます。 Google Cloud がデフォルトで収集する指標（メトリクス）については、課金は発生しません。ユーザーが Ops Agent で収集する追加指標やカスタム指標は、収集したバイト数あるいはサンプル数に応じて課金されます。 課金対象メトリクスも、最初の 150 MB は毎月無料ですが、それ移行は $0.2580/MB が発生します（2025年4月現在の単価）。数台〜十数台の VM の Ops Agent 追加指標程度であれば、無料範囲内に収まる可能性があります。 また、Cloud Monitoring API にリクエストした階数や、稼働時間チェック機能などにも、料金が設定されています。 最新の料金は、以下のドキュメントを参照してください。 参考 : Google Cloud Observability の料金 リソースモニタリング Google Cloud の指標 Cloud Moniitoring は、Compute Engine や Cloud SQL、 Cloud Storage のバケットなど、あらゆる Google Cloud リソースから 指標 （メトリクス）を収集します。 取得できる指標は、Compute Engine や Cloud SQL の場合、CPU 使用率やネットワーク I/O、Cloud Storage ならば API リクエスト数や総使用バイト数などです。 標準的な指標は、利用者が何も設定しなくても、 自動的に収集 されます。自動的に収集される指標については、課金は発生しません。このような自動的に収集される指標を、 Google Cloud の指標 といいます。 収集された指標は、Cloud Monitoring コンソール画面の Metrics Explorer 画面や、各サービス側のリソースの画面等で閲覧することができます。 参考 : Metrics Explorer でグラフを作成する Metrics Explorer 画面 Google Cloud の指標の一覧は、以下の公式ドキュメントを参照してください。 参考 : Google Cloud metrics カスタム指標 ユーザー独自の指標として カスタム指標 を収集して、Cloud Monitoring API に送信することができます。 Google Cloudの指標や Ops エージェントの指標は画一的なものであり、アプリケーションの負荷やユーザー体験の状況を正確に反映していない可能性があります。 CPU 使用率やメモリ使用率が上がっているからといって、ユーザーが処理を待たされていることを確実に示しているわけではないですし、逆に CPU 使用率やメモリ使用率に余裕があっても逆のことがありえます。システムのパフォーマンス実態を示す独自の指標があれば、正確に状況を反映し、スケールアクションなどに繋げることができます。 カスタム指標を収集するには、Cloud Monitoring の Web API に直接データを送信する方法と、オープンソースのライブラリである OpenCensus を使って Cloud Monitoring に送信する方法があります。詳細は以下のドキュメントをご参照ください。 参考 : ユーザー定義指標の概要 複数のプロジェクトの指標を表示する 指標スコープ を構成することで、複数のプロジェクトの指標を単一の画面で表示することができます。 ある Google Cloud プロジェクトを、複数プロジェクトの Cloud Monitoring 指標を横断して表示するためのハブとして決めて、そのプロジェクトの指標スコープに、監視対象のプロジェクトを追加することで、複数プロジェクトの指標を横断して閲覧できます。このとき、ハブとなるプロジェクトを スコーピングプロジェクト と呼びます。また、監視対象となる個々のプロジェクトを リソースコンテナ と呼びます。 参考 : 指標スコープの概要 指標を閲覧する Google アカウント（グループ）は、スコーピングプロジェクトに対してのみ、モニタリング閲覧者（ roles/monitoring.viewer ）ロール等の IAM ロールを持つことで、監視対象となるすべてのプロジェクトの指標を閲覧できるようになります。個々の監視対象プロジェクトに対する IAM 権限は必要ありません。 参考 : 指標スコープの概要 - Cloud Monitoring へのアクセス権を付与する スコーピングプロジェクトと権限 公式ドキュメントでは、スコーピングプロジェクトとして専用のプロジェクトを作成し、そこにはリソースを何も作成しないことを推奨しています。そのほうが権限管理上もシンプルですし、スコーピングプロジェクト自体で指標が生成されないため、管理が容易になるためです。 参考 : 指標スコープの概要 - ベスト プラクティス Ops エージェント Ops エージェントの指標 Compute Engine VM に、 Ops エージェント をインストールすると、Google Cloud の指標の他に、追加の指標を収集できます。 参考 : Ops エージェントの概要 Compute Engine の場合、Google Cloud の指標では、メモリ使用率、ディスク使用率、スワップ利用率などの重要な指標は収集されません。これは、Google Cloud の指標は、 VM のハイパーバイザから取得できる情報 をもとに構成されているからだと考えられます。 Ops エージェントは、VM のゲスト OS 上で稼働し、情報を収集して、Cloud Monitoring の API エンドポイントに対してその情報を送信します。これにより、 メモリ使用率 、 ディスク使用率 、 スワップ利用率 などの指標が取得できます。 Ops エージェントによって収集される指標の一覧は、以下の公式ドキュメントを参照してください。 参考 : Ops エージェントの指標 なお、Ops エージェントの指標は取り込みボリュームに応じて料金が発生します。インスタンス数が数台〜十数台といったレベルでは無料枠に収まるか、安価になる可能性が高いですが、数百台のインスタンスを管理する場合は、コストに関する試算も重要になります。 Ops エージェントのセットアップ エージェントのインストール手順は、以下の公式ドキュメントを参照してください。 参考 : Ops エージェントをインストールする VM の要件 Ops エージェントが稼働する VM では、以下の条件1〜3をすべて満たしている必要があることに注意してください。どれか1つでも満たせていない状態だと、Ops エージェントは指標の送信に失敗します。エージェントが稼働してから数分が経つと、Memory Utilization（ agent.googleapis.com/memory/percent_used ）といった Ops エージェントの指標が VM の詳細画面等で確認できます。エージェントのインストール後には、正しく指標が収集できているかを確認しましょう。 条件1 : VM が Cloud Monitoring の API エンドポイントに到達できる 例1 ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている VM が外部 IP アドレスを持っている 例2 ファイアウォールで 443/tcp が 0.0.0.0/0 (※) に対して空いている VPC のルート設定で 0.0.0.0/0 (※) がデフォルトインターネットゲートウェイに向いている VM が Cloud NAT でインターネットへアクセスできる 例3 サブネットで限定公開の Google アクセスが有効になっている VM が限定公開の Google アクセス経由で Google Cloud API にアクセスできる設定ができている 限定公開の Google アクセスについては、以下の記事も参照してください。 参考 : 限定公開の Google アクセスの仕組みと手順をきっちり解説 - G-gen Tech Blog 条件2 : VM にアタッチされているサービスアカウントがプロジェクトレベルで以下のロールを付与されている モニタリング指標の書き込み（ roles/monitoring.metricWriter ）ロール 条件3 : VM のアクセススコープ設定で Cloud Monitoring への書き込みが許可されている "デフォルト" もしくは "全て許可" になっていれば問題ない アクセススコープについては、以下の公式ドキュメントや、当社記事も参照してください。 参考 : サービス アカウント - アクセス スコープ 参考 : 改めてサービスアカウントとVMのアクセススコープを理解する - G-gen Tech Blog トラブルシューティング 指標が表示されない場合は、何らかのエラーが出力されている可能性があります。Linux インスタンスであれば、以下のようなパスにエージェントのログが出力されているので、ログを確認して原因を調査します。 /var/log/google-cloud-ops-agent/subagents/logging-module.log 以下はエラーの例です。この例では、VPC ファイアウォールルールでインターネットへのアウトバウンドの 443/TCP 通信が拒否されていたため、エージェントは API エンドポイントにリーチできず、エラーになっていました。 [2021/10/14 10:07:46] [error] [upstream] connection #272 to logging.googleapis.com:443 timed out after 10 seconds なお上記のエラーメッセージで logging.googleapis.com と出ていることからもわかるように、Ops エージェントは Cloud Logging にログを送信するエージェントの役割も兼務しています。かつては Monitoring エージェントと Logging エージェントの2つの異なる役割のエージェントソフトウェアがありましたが、現在では Ops エージェントに統合されています。 ダッシュボード Cloud Monitoring 指標を閲覧するには、Metrics Explorer の他、 ダッシュボード 機能を使うこともできます。ダッシュボードはカスタマイズ可能で、さまざまなチャート（グラフ）を配置して、運用上必要なリソースの指標を閲覧することができます。 ダッシュボードは運用の要件に合わせて自在に作成が可能であることに加えて、Google Cloud プロダクトごとにプリセットで用意されているダッシュボードをそのまま利用したり、複製してカスタマイズして利用することもできます。また、ダッシュボード定義は JSON 形式でエクスポートしたり、インポートすることができます。 参考 : ダッシュボードの概要 参考 : カスタム ダッシュボードの作成と管理 プリセットのVM用ダッシュボード アラート 概要 Cloud Monitoring では、指標にしきい値を設定して、しきい値を超過した際にメールを発信するなど、 アラート の設定が可能です。アラート機能で作成された個々の設定を、 アラートポリシー と呼びます。 参考 : アラートの概要 例えば、以下のようなアラートポリシーが作成可能です。 指標 : CPU使用率 対象 : あるインスタンスグループ全体 期間 : 5分間 しきい値 : 80%を超過 アクション : E メールを送信 アラートの設定画面 通知チャネル Cloud Monitoring のアラートでは、以下の通知先への通知が可能です。これらのような通知先のことを 通知チャンネル （notification channels）と呼びます。 Eメール Google Cloud のモバイルアプリ Google チャット PagerDuty Services PagerDuty Sync Slack Webhook（HTTP エンドポイント） SMS Pub/Sub 通知先チャンネルを使った運用の例として、指標のしきい値超過をトリガーにして Pub/Sub にメッセージを送信し、Pub/Sub トリガの Cloud Run functions を起動して、対処アクションを自動実行するといったことが実現可能です。 参考 : 通知チャンネルを作成して管理する 設定方法 アラートポリシーは、しきい値超過時の発報のほか、指標が収集できなくなった時や、指標がある数値に到達されると予測される際に発報させることもできます。アラートポリシーの設定方法は、以下の公式ドキュメントを参照してください。 参考 : 指標しきい値のアラート ポリシーを作成する 参考 : 指標なしのアラート ポリシーを作成する 参考 : 予測指標値のアラート ポリシーを作成する また、以下の記事もご参照ください。 blog.g-gen.co.jp 稼働時間チェック 稼働時間チェックとは 稼働時間チェック （uptime checks）とは、一般的に URL 監視、あるいは外形監視等と呼ばれる監視を設定できる機能です。 HTTP、HTTPS、TCP（任意のポート）のいずれかのトラフィックを Google から対象リソースに送信し、そのレスポンスが想定状態と異なっていればアラートを発報することができます。 インターネットからアクセス可能なエンドポイントを対象とする 公開の稼働時間チェック （Public uptime checks）と、VPC ネットワーク内のプライベートなエンドポイントを対象とする 非公開の稼働時間チェック （Private uptime checks）の2種類があります。 チェックが失敗した際の通知先として、Cloud Monitoring の通知チャンネルが選択できます。 参考 : 公開の稼働時間チェックを作成する 参考 : 非公開稼働時間チェックを作成する 稼働時間チェックには、チェック実行回数あたりの料金が発生します。料金単価は、1,000 回の実行ごとに $0.30 です（2025年4月現在）。また、Google Cloud プロジェクトあたり、月に100万回までが無料です。 参考 : Google Cloud Observability の料金 公開の稼働時間チェック 公開の稼働時間チェック （Public uptime checks）は、インターネットからアクセスできるエンドポイントを対象とする稼働時間チェックです。 以下を監視対象として設定できます。 URL Compute Engine VM App Engine アプリケーション Kubernetes サービス Amazon EC2 インスタンス Amazon Elastic Load Balancers Cloud Run リビジョン 監視対象が Google Cloud の VPC ネットワーク内のリソースの場合、稼働時間チェックが正しくエンドポイントに到達できるようにするためには、VPC ネットワークのファイアウォール等を適切に設定する必要があります。 0.0.0.0/0 からのトラフィックが許可されていれば問題ありませんが、稼働時間チェックが利用する接続元 IP アドレスだけを許可することもできます。IP アドレスのリストは、Google Cloud コンソールからダウンロードしたり、API 経由で取得することができます。 参考 : 稼働時間チェック サーバーの IP アドレスを一覧表示する 上記で取得した接続元 IP アドレスの範囲だけを VPC ファイアウォールルールで許可することも可能ですが、クラウドサービスの IP アドレス範囲は変更される可能性もあるため、変更を定期的に検知してファイアウォールルールに反映するような仕組みを用意することが望ましいでしょう。 公開の稼働時間チェックの設定手順の詳細は、以下の公式ドキュメントを参照してください。 参考 : 公開の稼働時間チェックを作成する 非公開の稼働時間チェック 非公開の稼働時間チェック （Private uptime checks）は、インターネットに公開されていない、 VPC ネットワーク内部のリソースのエンドポイントを対象とする 稼働時間チェックです。 社内向けシステムをホストする Compute Engine VM や、自組織の内部ネットワーク向けの API エンドポイント等を監視する目的で利用できます。 非公開稼働時間チェックでは、ターゲットとして Service Directory リソース と呼ばれるリソースを作成する必要があります。Service Directory リソースには、エンドポイント、サービス、名前空間といったリソースが含まれます。これらのリソースにより、Compute Engine VM や、Cloud Load Balancing の IP アドレスを抽象化し、稼働時間チェックはそれに対してチェックを行います。 詳細な設定手順は、以下の公式ドキュメントを参照してください。 参考 : 非公開稼働時間チェックを作成する Prometheus Query Language（PromQL） Cloud Monitoring では、 Prometheus Query Language （PromQL）という言語で、指標をクエリしたり、グラフを作成することができます。 PromQL は、主に Kubernetes 向けのオープンソースの監視ツールである Prometheus で用いられる、時系列データに対するクエリ言語です。 Prometheus を利用しており、運用を共通化したい場合は、Cloud Monitoring でも PromQL を使うことができます。Metrics Explorer や、カスタムダッシュボードへのグラフ追加時に、PromQL を利用できます。 参考 : Cloud Monitoring の PromQL 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-genの杉村です。2021年10月26日、デジタル庁が公募していた デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供 の公募結果が公開されました。 結果として Amazon Web Services (AWS) と Google Cloud (旧称 GCP) が対象として 発表 されました。 これに関連して本投稿では、 Google が公開している海外の政府・自治体による Google Cloud 利用事例を簡単にご紹介します。 日本でも行政によるクラウド利用が進み、国民がより便利に、効率的に行政サービスを受けられるようになることを願います。 デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供 政府および行政機関向け Google Cloud 概要 Google Cloud のコンプライアンス情報 行政向けの事例 1. アメリカ国立老化研究所: パーキンソン病対策を加速 2. NYC Cyber Command: ニューヨーク市の大規模デジタル サービスの安全を守る 3. ロサンゼルス市: Google Map で市民への情報公開と利便性の向上を実現 4. イタリア・ベネト州: 500万人向けの地方自治体サービスの変革 5. チリ: 医療ケアのモダナイゼーション 6. アリゾナ州: クラウドコラボレーションで生産性とセキュリティを向上 デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供 2021年10月4日、日本のデジタル庁は デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和3年度地方公共団体による先行事業及びデジタル庁WEBサイト構築業務－ と題した公募を発出した。 デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供－令和3年度地方公共団体による先行事業及びデジタル庁WEBサイト構築業務－ (デジタル庁) 公募の目的は以下のように記載されている。 本公告はクラウドサービスの適正かつ確実な提供を確保するため、公募参加者に対し、 その確実なサービスの提供を証明する書類等の提出を求めるものであり、デジタル庁が 当該提出された書類等の審査においてクラウドサービスの提供が可能と判断した者すべ てと契約の締結を行うものである。 また応募要項の事業概要の項に記載されているように、今後デジタル庁の Web サービス基盤はこれらのパブリッククラウド上に構築され、他省庁や自治体のシステムもこれに続くことが想定される。 (1) 地方公共団体による先行事業に向けたクラウドサービスの整備 (中略) (2) デジタル庁 WEB サイトに向けたクラウドサービスの整備 (中略) 本件は、上記（1）、（2）を実施するために、その基盤となるクラウドサービスの提 供を公募するものである。 2021年10月26日には、 Amazon Web Services (AWS) と Google Cloud (旧称 GCP) が選定されたことが発表された。 公募結果について (デジタル庁) 政府および行政機関向け Google Cloud 概要 Google Cloud の公式 Web サイトには、政府・行政機関による Google Cloud 利用事例が公開されている。 政府および行政機関向け Google Cloud (Google) 同ページではGoogle Cloud の IaaS 系ソリューションの他、 AI/ML (人工知能・機械学習) 系ソリューションや Google Workspace による業務効率化がソリューションとして紹介され、またいくつかの事例が公開されている。 ただし2021年10月末現在のところ、同ページで紹介されている事例はいずれもアメリカ合衆国や南米など、海外の事例に留まっている。 同ページで紹介される海外事例は一部が日本語訳されているものの、英語版しか公開されていない事例もあることから、これらを抄訳してごく簡単に紹介したい。 Google Cloud のコンプライアンス情報 事例を紹介する前に、同ページで紹介されている Google Cloud のコンプライアンス情報に関しての記述に触れたい。 行政・自治体に限らず一般企業でも注目すべきポイントは、 Google Cloud が受けている第三者認証だ。 以下のページでは、 Google Cloud が受けた認証に関する資料に加え、各国の公的認証やガイドラインへの準拠に向けた補助資料が配置されている。 コンプライアンス リソース センター 日本でも知名度が高い ISO/IEC 27001 や SOC 、PCIDSS はもちろん、日本の通称「3省2ガイドライン (厚生労働省、経済産業省、総務省の3省が発行する医療機関向けの情報システムガイドラインの総称)」に準拠するためのホワイトペーパー等も公開されている点が興味深い。 さてここからは、同ページで紹介されている海外での行政・自治体における Google Cloud や Google Workspace の活用事例を紹介する。 行政向けの事例 1. アメリカ国立老化研究所: パーキンソン病対策を加速 cloud.google.com アメリカ国立老化研究所 (National Institute on Aging) において Google Cloud が利用された事例が紹介されている。 Cloud Life Sciences (旧 Google Genomics: 生物医学データ処理のためのコンピューティングリソース管理プラットフォーム) の利用 オンプレ基盤では数ヶ月かかる200 TB のエクソームデータの処理を 3.5 週間で実現 世界中の50を超える機関の研究者にデータを共有 (アクセスコントロールによりセキュリティを担保) Cloud Life Sciences (旧 Google Genomics) を使うことで大量のコンピューティングリソースを効率的に管理して膨大な遺伝子解析を実現した事例だ。 また Google Cloud のきめ細やかなアクセス制御の特性を利用して、米国内や欧州の各機関に散らばる研究者たちにデータを速やかに共有できたことを紹介している。 2. NYC Cyber Command: ニューヨーク市の大規模デジタル サービスの安全を守る cloud.google.com NYC Cyber Command は米国・ニューヨーク市の公的機関で、市のサイバーディフェンスを任務とする機関だ。 Google はこの事例を以下のように要約している。 高パフォーマンスのクラウド サービスでより迅速に脅威を検知 100 以上のすべての都市機関のオンボーディングにかかる時間を短縮 小規模なチームでクラウド インフラストラクチャを安全に管理 ペタバイト規模のデータを分析できる、ほぼ無限のスケーラビリティ 都市機関や市民に最大の価値を提供 本事例では、市の職員が BeyondCorp セキュリティモデルによるシステム利用をしていることが述べられている。 Google Workspace により ID 管理をベースに Cloud IAM による認可制御をし、 Cloud Identity-Aware Proxy (IAP) を利用して非 VPN による Google Cloud アクセスを実現したようだ。 また各行政システムからデータ収集を行うデータパイプラインを以下のようなアーキテクチャで構築したことが記載されている。 データの受け口として Cloud Pub/Sub を利用 Cloud Dataflow または Cloud Functions がそのデータを処理する BigQuery 等のダウンストリームでデータを分析 これらのサービスを利用した理由として、サーバレスゆえに高い処理能力が容易に調達・実装できることが理由として挙げられている。 またアプリケーション基盤としては Google Kubernetes Engine (GKE) を採用しモニタリングに オペレーション スイート (旧称 Stackdriver) を利用していることを明らかにしている。 3. ロサンゼルス市: Google Map で市民への情報公開と利便性の向上を実現 workspace.google.com 同事例では Google Cloud による以下の成果が記載されている。 緊急時に重要となる情報を使い慣れた Google Map のインターフェイスで提供 Google Map での情報提供を1時間以内に セキュリティよりも機能開発へ注力できるように ロサンゼルス市情報技術局 (ITA, Information Technology Agency) は 2016 年まで、緊急情報提供をウェブサイト上でのテキストにより行われ、地図情報が必要な際には手動で作られた地図がPDF配布されていた。 2016 年前半、エル・ニーニョ現象によって引き起こされた異常気象の際、 Google Map を使った新システムが活用された。 Google Map を活用して市の地図と気象情報をレイヤで重ねたエル・ニーニョ・ウォッチ・ページが公開された。 このページでは警報情報、浸水した市街地、地滑り、停電、渋滞情報、避難シェルターなどの情報が提供されたという。 このエル・ニーニョ・ウォッチ・ページでは Google Map の提供する地理情報の他、地域のホームセンター等の情報も活用した。住民がその情報を活かして、大雨に備えた準備ができるようにしたのだ。 また ITA はカリフォルニア州で頻発する山火事の対応にも Google Map を活用している。 火事の発生場所や避難場所等を表示するようにしたのだ。 またロサンゼルス市は Google Workspace (旧 GSuite) も利用している。 2009 年から Gmail とカレンダーを使っており、これは米国内の自治体でも最も早い部類だったという。 現在では Google Drive や Google Meet の利用を含め 30,000 ユーザーが利用している。 ロサンゼルス市は東京23区のおよそ2倍の面積 (1214.7 平方 km) であるため、点在する職員のコミュニケーションに Google Drive 等が利用されている。 ロサンゼルス市では 2028 年のオリンピック開催に向け、さらにバーチャルアシスタント (Google Assistant) の活用や 5G 活用などを模索している。 4. イタリア・ベネト州: 500万人向けの地方自治体サービスの変革 cloud.google.com ヴェネチア市を擁するイタリア・ベネト州の地方公共サービスでは以下の成果が報告されている。 85,000 人の従業員を Google Workspace で管理。人の移動の必要性を 60% 削減 オンプレソリューションに比べ保健医療当局の運用コストを 90% 削減 地方自治体を跨いだ統合デジタルエコシステムを構築。機械学習を活用した革新的な管理ツールを利用 同州ではデジタル戦略の一環として、ヘルスケアシステムのICTインフラの更改を決定した。 同州には 13 の地方医療当局が存在し、それぞれにデータセンターやEメールプロバイダーを持っていた。 入札を経て、構築パートナーの力を借りたうえで、 50 を超える医療機関の 70,000 人の従業員を Google Workspace に移行した。 Google Workspace のサービスである Drive, Document, Spreadsheet, Meet の利用により、職員の地域間の移動が半分以下に削減できたという。 また同市は Vertex AI (旧 Cloud Machine Learning Engine), Cloud Natural Language および Cloud Storage を活用し、機械学習向けライブラリである TensorFlow を使った機械学習も活用している。なお TensorFlow も Google が開発したオープンソースだ。 医療機関の診断書の管理のために機械学習が活用されており、解析により正確な診断に活用するとされている。 また Apigee API Management Platform も利用されており、これにより各地の 4,000 人以上の開業医の診察予約情報が収集されている。 Google Cloud と Google Workspace の活用により、データセンターの管理運用に比べて 90% の運用コスト削減になったことを当局 CIO が明らかにしている。 5. チリ: 医療ケアのモダナイゼーション www.youtube.com チリ厚生省のヘルスケアシステムに関する事例が動画で紹介されている。 同省では、患者の医療情報の統合に課題があったという。 法的レギュレーションのもと、パブリックな情報とプライベートな情報を API ガバナンスのもとで統合し、臨床現場で利用できるようにするため Apigee を利用した。 同省が Apigee を採択した理由として「シンプルなアーキテクチャ」「ステークホルダに情報を共有する際のセキュリティ」の2つを上げている。 Apigee により 2017 年、住民票と患者情報の照合や、ワクチン情報の共有、パブリックとプライベートなセクターを跨いだ医療情報の共有などに役立てたという。 こういった情報の相互運用を、公的な基準に準拠したうえで実現するために Apigee を活用した。 今後、テクノロジーをベースとして、国民が自ら予防的な健康維持をできるような施策を実施することが今後の課題だとしている。 6. アリゾナ州: クラウドコラボレーションで生産性とセキュリティを向上 workspace.google.com 米国アリゾナ州でも Google Workspace を使って生産性向上を図った事例が公開されている。 リアルタイムなコラボレーションで生産性を向上 月あたり10万7千件あった有害なメールを排除し、セキュリティを向上 3年で数百万ドルのストレージ、ライセンス、管理コストを節約 アリゾナ州のクラウドファーストポリシーを実現 米国の州の中で IT 技術のリーダー的ポジションに位置するアリゾナ州は、 2018 年にクラウドファースト方針を決定。 セキュリティの観点から Google Workspace を選択した。 同州は既に Microsoft 365 を利用していたが、当時は同州が求めていたリアルタイムのコラボレーションやビデオ通話の要件を満たさず、代わりに Google Workspace の採用を決定した。 Okta により Active Directory と Google Workspace を統合してシングルサインオン (SSO) を実現したことが紹介されている。 ブラウザとして Chrome を採用しているほか、 Vault の機能を使って電子情報開示 (eDiscovery) に対応している。 Vault とは、 Google Workspace の Business / Enterprise プランに組み込まれている機能で、 Gmail や Drive といった各サービスのデータを保持、検索、書き出しを行うことができる機能だ。 同州では1年以内に 22,000 人の職員が Google Workspace へ移行し、最終的には 36,000 の職員や関係者が利用することになるという。 導入にはパートナーの他、 Google のプロフェッショナルサービスが協力した。 Gmail ではプロアクティブな保護により、毎月1千万を超えるスパムメールを排除している。同州の従来型のオンプレミスの仕組みでは検知できなかった10万件以上の有害メールを、 Gmail は自動検知して排除したという。 同州ではほとんどのファイルサーバを廃止して Google Drive に移行した。また Google Meet や各種サービスを使った遠隔・リアルタイムの働き方にも慣れ、強い嵐によってデータセンターが機能停止に陥った際も、職員は自宅から働くことができたという。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

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 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 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 に関する注意点 課金レポート 課金レポートとは レポートの見方とコツ 管理機能 予算アラート 異常検知（Anomaly Detection） 課金データの BigQuery エクスポート プロジェクトと請求先アカウントのリンクを保護 AWS との違い 基本的な概念 概念と用語 当記事では Google Cloud の 請求の仕組み 、また 請求先アカウント という言葉を、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 Documentation 参考 : Cloud 請求先アカウントへのアクセスを管理する  |  Cloud Billing  |  Google Cloud Documentation 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 の請求代行サービスでは特殊な制限はかかっておらず、IAM 権限さえ持っていればレポートを閲覧できます。 参考 : Cloud Billing レポート 課金レポート このレポート画面では、以下のような切り口で課金額をグラフィカルに表示できます。 プロジェクトごと サービスごと SKU（課金単位）ごと リソースに付与したラベルごと リージョンごと 上記の掛け合わせ レポートの見方とコツ 課金レポートへアクセスする手順は、以下のとおりです。 Google Cloud コンソール（ https://console.cloud.google.com/ ）にログイン 左上のプロジェクトセレクタで対象のプロジェクトを選択 検索ボックスに「課金」と入力 サジェストされた「課金 / プロダクト・さまざまな課金とコストの管理ツール」をクリック 「リンクされた請求先アカウントに移動」をクリック 上記の手順 2. で、課金を確認したい対象プロジェクトを正しく選択するように注意してください。手順 4. のあとでプロジェクトを選択しなおしても構いません。 4. サジェストされた「課金 / プロダクト・さまざまな課金とコストの管理ツール」をクリック 5. 「リンクされた請求先アカウントに移動」をクリック 上記の手順は、自分がオーナー（ roles/owner ）ロールや閲覧者（ roles/viewer ）ロールを持っているプロジェクトに対する課金レポートの閲覧手順です。請求先アカウントに対して適切な権限を持っていれば、複数のプロジェクトに対する横断した課金レポートを閲覧することができます。また課金レポートでは、プロジェクトごと、サービスごと、SKU ごとなど、詳細に発生した料金を閲覧できます。 レポートの閲覧に必要な権限や分析のコツなどについては、以下の記事で詳細に解説しています。 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のみ保持していますがそろそろ失効してしまいそうな予感。