こんにちは、G-genの荒井（@arapote）です。みなさん、パブリッククラウドはご利用でしょうか？！既に利用されている企業様も多いかと思いますが、全国的にはまだまだオンプレミスを運用している企業も多くいらっしゃると思います。今回はそんな方々でも、かんたんにクラウドを体験していただけるよう、無料で Google Cloud（旧称 GCP）をご利用いただける方法をご紹介いたします。 Google Cloud って無料で使えるの？ 「無料枠」と「無料トライアル」 無料枠とは 無料枠の適用範囲 無料トライアルとは 利用イメージ 利用料金の例 Google Cloud 利用開始準備 手順の概要 必要なもの Googleアカウントの準備 無料 Google アカウントの作成 後編へ ※本記事に記載の情報は2024年11月時点のものです。 Google Cloud って無料で使えるの？ 早速本題の「 Google Cloud を無料で使えるか？ 」ですが、結論からお伝えしますと Yes です。とはいえ、もちろん完全に無料というわけではありません。いくつか条件がありますのでご紹介いたします。 Google Cloud には、 無料枠 と 無料トライアル があります。これらを利用することで、Google Cloud を無料で利用することができます。それでは、それぞれの内容を確認していきましょう。 無料枠と無料クレジットの詳細は、以下の公式ドキュメントをご確認ください。 参考 : Google Cloud の無料プログラム 「無料枠」と「無料トライアル」 無料枠とは 無料枠 とは、Google Cloud のプロダクトごとに設けられた、 一定量まで毎月無料 で利用することができる仕組みです。 この無料枠は後述の無料トライアル期間とは関係なく設けられており、毎月、定められた量を無料で利用できます。この無料枠を超えた分については、通常どおり課金されます。人気のプロダクトにも無料枠が設定されていますので、Google Cloud を無料で、あるいは安価に利用することができます。無料枠の例は、以下の通りです。 プロダクト名 無料枠 BigQuery ・1TB のクエリ ・10GB のストレージ Cloud Storage ・5 GB の保管料金（ us-west1 、 us-central1 、 us-east1 のみ。Standard Storage） Compute Engine ・e2-micro タイプの VM 1台（ us-west1 、 us-central1 、 us-east1 のみ。Standard Storage）ほか 適用リージョンの指定など、制限については以下のドキュメントをご確認ください。 参考 : 無料枠の使用量上限 無料枠の適用範囲 Google Cloud の無料枠は、特記がない場合は「請求先アカウント」の単位でカウントされます。Google Cloud プロジェクトが複数あっても、 同じ請求先アカウントに紐づいていれば、1つの無料枠を共有する ことになります。 参考 : 無料枠 請求先アカウントについては、以下の記事も参照してください。 blog.g-gen.co.jp 無料トライアルとは 無料トライアル は、Google Cloud を初めて利用される方向けに $300のクレジット が付与される仕組みです。こちらのクレジットには、 90日間 という有効期間があります。90日経過後、クレジットは消滅してしまいます。 このクレジットを使うことで、$300 分までは無料で Google Cloud を試用できます。 無料トライアルの対象となる条件などについて、以下のドキュメントに記載がありますのでご確認ください。 参考 : 90 日間 $300 分無料トライアル 利用イメージ 無料枠 と 無料トライアル をご紹介しましたが、文字だけだと少しわかりにくいと思うので利用例を図にしてみましょう。わかりやすくするために、1ヵ月を30日としています。 課金が発生するケースは、以下のどちらか（もしくは両方）を満たした場合となります。 $300のクレジットを超過した 90日経過後も利用を継続している しかし重要なポイントとして、 $300を超えた 、あるいは 90日間が経過した からといって勝手に課金が開始されるわけではありません。サービス利用開始時にクレジットカードの情報登録作業があるものの、自動課金にはなりません。（これ、良心的ですよね！） コンソール画面上にこのような親切な表示があり、利用者が自身で課金を有効にしない限り、クレジットカードを登録しても課金は始まりません。 なお、無料クレジットを使い切ってもGoogle Cloud を継続的に使いたいという方向けに、G-genではGoogle Cloud を3%OFF〜でお得にご利用いただけるサービスがあります。詳細は以下の記事を参照してください。 g-gen.co.jp 利用料金の例 無料クレジットが$300付与されるとご紹介しましたが、これって多いの？少ないの？そんな疑問が出てきた方がいらっしゃるのではないでしょうか。 一例ですが、Google Cloud で仮想サーバーを運用した場合の利用料金の例を記載します。 マシンタイプ : e2-standard-4（vCPU 4、RAM 16 GiB） ストレージ : 100 GiB OS : Windows Server または Ubuntu 上記のようなスペックの場合、Windows Server では $272.83 、Ubuntu（あるいはライセンス料のかからない OS）の場合は $138.51 / 月 です（いずれも2024年11月現在、東京リージョン）。 1ヵ月間、仮想サーバーを起動し続けてもこの料金です。Compute Engine は従量課金制（マシンが起動している間のみ料金が発生）なので、利用していないときはマシンを停止するなど工夫すると、さらに効率的に利用できるのではないでしょうか。 Google Cloud 利用開始準備 手順の概要 Google Cloud は使い方次第で無料で利用できることがわかりましたので、利用の準備を進めましょう。利用開始までの大きな流れは、以下の通りです。 Google アカウントの準備 Google Cloud 利用情報登録 Google Cloud 初期設定 必要なもの Google Cloud を利用するために必要な環境を事前に準備しておきましょう。 インターネットに接続できる PC Google アカウント SMS が受信できる電話番号 クレジットカード（登録は必須ですが、課金は任意） Googleアカウントの準備 Google Cloud を利用するためには、Google アカウントが必要です。Google アカウントは大きく分けて、3つの準備方法があります。 Cloud Identity で Google アカウントを管理する（自社ドメインが必要、無償または有償） Google Workspace で Google アカウントを管理する（自社ドメインが必要、有償） 無料 Gmail アカウント を利用する Google アカウントに関する詳細は、以下の記事もご参照ください。 blog.g-gen.co.jp 無料 Google アカウントの作成 すでに Gmail などを利用されている方は、そのアカウントでも利用が開始できます。Gmail も Google アカウントも持っていない方は、 Google アカウントのログインページ で「アカウントを作成」をクリックし、指示に従って入力を進めることで無料の Google アカウント（Gmail アカウント）を作成できます。 ただし、企業や官公庁などの組織で Google Cloud を使う場合は、Cloud Identity や Google Workspace で Google アカウントを管理することが強く推奨されます。無料で Cloud Identity 組織を作成する方法は、以下をご参照ください。 blog.g-gen.co.jp 後編へ ここまで準備ができたら、あとは Google Cloud にアクセスして利用開始手順を進めることができます。利用開始手順は、後編でご紹介いたします。 blog.g-gen.co.jp また、以下のリンク集では各プロダクトをわかりやすく解説した当社記事がまとまっています。ブックマーク必須です！！ blog.g-gen.co.jp 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

こんにちは、G-genの渡邉@norry です。 皆さんCloud Logging は活用されていますか？ Cloud Logging は Google Cloud (GCP) 上のシステム等が生成したログを収集・保管・管理する仕組みです。 まずはCloud Logging とは何か？ をしっかり理解したい方は以下の記事をおすすめします。 blog.g-gen.co.jp 本項では GCP 上の Windows VM より Google Cloud オペレーションスイートのエージェント ( Ops Agent ) を利用して Cloud Logging にログファイルを収集する方法をご案内します。 Ops エージェント概要 Ops エージェントとは サポートされるOS Ops エージェントの機能 標準対応しているサードパーティアプリ Ops エージェントのインストールと起動確認 インストール方法 起動確認 任意のログの取得方法 Ops エージェントの構成 Windows VM での設定手順実例 Ops エージェント概要 Ops エージェントとは Ops エージェントは、Compute Engine インスタンスから テレメトリー (稼働データ) を収集して Cloud Monitoring や Cloud Logging に送信するエージェントソフトウェアです。 公式ガイドは コチラ を参照くだい。 Ops エージェントではログの取得と指標 を 一つのエージェント に統合している部分がポイントです。以前は指標の収集送信に "Cloud Monitoring エージェント" を、ログの収集には "Cloud Logging エージェント" を、というように別々のエージェントが存在していました。現在ではこれらが Ops エージェントとして統合されています。 また、ここで言う ログ はシステムから出力される何らかのイベントログやアプリケーションから出力されるテキスト形式のログのこと、 指標 は例えば1秒間あたりにどのくらいのCPUやメモリの使用率があったかと言うような 稼働状況 と捉えていただいても問題ないかと思います。 Ops エージェントはログに Fluent Bit を使用しており、高スループット ロギングと指標の OpenTelemetry Collector がサポートされています。 サポートされるOS エージェントは標準的な Linux 及び Windows ディストリビューションで稼働します。 サポート対象 OS の一覧は コチラ です。 Ops エージェントの機能 ロギング関連の主要な機能は次のとおりです。 設定なしで標準のシステムログ（Linux の /var/log/syslog と /var/log/messages、Windows のイベントログ）を収集 カスタム ログファイル JSON ログ。 書式なしテキストのログ 正規表現を使用した解析。 JSON ベースの解析 任意の形式のログを取得する際に、正規表現でログを抽出しJSON 形式に変換し Cloud Logging に送信する事が可能です。 標準対応しているサードパーティアプリ Ops エージェントではサポートされているサードパーティ アプリケーションの自動ログ解析が可能となっています。その場合にはファイル解析をする為に Ops エージェントを構成します。この構成については後述します。 2022年2月時点での対応サードパーティアプリは次のとおりです。 Apache Tomcat Cassandra Elasticsearch IIS (WIndows のみ) JVM MariaDB Memcached MS SQL Server (WIndows のみ) MySQL Nginx PostgreSQL Redis なお、ここにリストされているソフトウェア以外の収集も、カスタム構成を行うことで 実現できます のでご安心ください (後述) 。 さらに参考として、モニタリング機能は次のとおりです (当記事では詳しく扱いません) 。 CPU 指標 ディスク指標 iis 指標（Windows のみ） インターフェース指標 メモリ指標 mssql 指標（Windows のみ） pagefile 指標（Windows のみ） スワップ指標 ネットワーク指標 プロセス指標 内部エージェント指標の選択: api_request_count memory_usage monitoring/point_count 稼働時間 Ops エージェントのインストールと起動確認 インストール方法 インストール方法については大きく下記 3つの方法 があります。 gcloud / エージェント ポリシーを使用して VM フリートにエージェントをインストール 自動化ツール (Ansible、Chef、Puppet、Terraform ) を使用して VM フリートにエージェントをインストールする 個々の VM に Ops エージェントをインストールする 今回は Windows VM で任意のログを取得する事を目的としていますので、さくっと 個々のVM に Ops エージェントをインストールする 方法で、インストールを行います。 Compute Engine ＞ 該当のWindows インスタンス ＞ インスタンスの編集 よりメタデータに以下の内容を記載します。 Ops エージェントインストール キー1 : windows-startup-script-ps1 値1: (New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1") Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall" 上記を記述し WIndows VM を起動すると自動的にインストールが開始されます、インストールは初回のみで良いのでインストールが終了したらメタデータの記述は消去しても大丈夫です。 起動確認 VM 起動後にOps エージェントが正常起動すると、 Google Cloud Ops Agent 、 Google Cloud Ops Agent - Logging Agent 、 Google Cloud Ops Agent - Metrics Agent のサービスが実行されている事が確認できます。 サービス起動確認 またGCP 管理コンソール ＞ ロギング ＞ ログエクスプローラー で RESOURCE TYPE にVM Instance が表示されWindows のイベントログが取得出来ている事が確認出来ます。 Cloud Logging 任意のログの取得方法 Ops エージェントの構成 前項で表記したデフォルトで取得するログ以外を取得する場合にはOps エージェントの構成の変更が必要になります。それ以外にも下記のような目的の時に変更が必要になります。 デフォルトのロギングや指標の取り込みをオフにする ログ収集元のファイルパスをカスタマイズする ログをJSON や正規表現で解析し構造を変更する 指標のサンプリングレートの変更 (60秒周期から30秒など) Ops エージェントはデフォルトの構成があり、その構成は直接操作する事は出来ません。そのかわりにユーザー側で追加・変更の構成ファイルを作成しデフォルトの構成にマージ・上書きします。適用にはOps エージェントのサービス再起動が必要になります。 把握しておくべき構成要素は次の通りです。 receivers: この要素はエージェントによって収集される内容を表します。(ログの場所の指定など) processors: この要素は、エージェントが収集した情報を変更する方法を記述します。(ログを正規表現で抽出、JSON形式で格納など) service: この要素は、レシーバーとプロセッサをリンクして、パイプラインというデータフローを作成します。service 要素には、複数のパイプラインを含めることができる pipelines 要素が含まれます。 Windows のOps エージェントではデフォルトの構成では次の通りです。デフォルトの内容を変更したい場合にはユーザー側で新たに設定ファイルを作成します。 logging: receivers: windows_event_log: type: windows_event_log channels: [System, Application, Security] service: pipelines: default_pipeline: receivers: [windows_event_log] metrics: receivers: hostmetrics: type: hostmetrics collection_interval: 60s iis: type: iis collection_interval: 60s mssql: type: mssql collection_interval: 60s processors: metrics_filter: type: exclude_metrics metrics_pattern: [] service: pipelines: default_pipeline: receivers: [hostmetrics, iis, mssql] processors: [metrics_filter] 詳しくは コチラ を参照ください。 Windows VM での設定手順実例 ユーザーがデフォルトで収集されないログ、例えばベンダーのパッケージ製品のテキストログを Cloud Loggingに集約する場合を想定して設定確認をしてみます。 今回は コチラ の簡易的なWeb サーバーを利用してそのログを Ops エージェントを通じて Cloud Logging へ送信します。 Webサーバーの構成は次の通りです、実行ファイルと同一フォルダにHTTDir.log というログファイルが出力されました。 log Web サーバー起動時のログはこのような内容です。 [2/17/2022 12:22:51 AM] awdss_1 [2/17/2022 12:22:51 AM] awdss_2 [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\Get.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\HTT.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\HTTDir.exe [2/17/2022 12:22:51 AM] awdss_self_noop [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_exeFile: C:\HTTDir\MimeType.exe [2/17/2022 12:22:51 AM] awdss_OK [2/17/2022 12:22:51 AM] awdss_3 [2/17/2022 12:22:51 AM] awdss_4 Windows では以下のパスにある yaml ファイルをメモ帳などで編集します。 C:\Program Files\Google\Cloud Operations\Ops Agent\config\config.yaml 今回は次のように設定しました。 logging: receivers: HTTDir_general: type: files include_paths: [C:\HTTDir\*.log] service: pipelines: HTTDir_general: receivers: - HTTDir_general 内容について詳述します。 logging: ログを収集して送信します、指標を取得する場合は metrics: で記述します。 receivers: どのデータを収集するかの指定 HTTDir_general: RECEIVER_ID と呼ばれるIDです、任意のIDを設定します。 type: どの形式で取得するかを指定します、 files syslog windows_event_log などが指定可能です。 include_paths: type が files の場合、取得するログが保存されている場所を指定します。 service: receivers: と processors: を紐づけて Cloud Logging へ送信します。重要度に応じてレベル分けも可能となっています。 pipelines: パイブライン名を HTTDir_general: としています。 receivers: レシーバー名 HTTDir_general の内容を Cloud Logging へ出力します。 Cloud Logging ＞ [VM Instance] ＞ [Log Name] で確認すると次のようになります。 IDで設定した名前でログが登録されている事が分かります。 Cloud Logging への出力 また、ログの中はこのようになりました。 jsonPayload 内にログが、まるっと格納されている事が確認できます。 jsonPayLoad の内容 jsonPayload の中にそのままメッセージ内容を入れるだけであればこのままで良いですが、フィールドとして表記したい場合やタイムスタンプとしてjsonPayload 外に値として取り入れたい事もあるかもしれません その場合は config.yaml に processors: を追記、正規表現を用いてフィールドに格納します。 今回は単純なログですので簡単に time フィールドと msg フィールドに分けてみました。 logging: receivers: HTTDir_general: type: files include_paths: [C:\HTTDir\*.log] + processors: + HTTDir_general: + type: parse_regex + regex: "\[(?<time>[^\]]+)]\s+(?<msg>.*)$" service: pipelines: HTTDir_general: receivers: - HTTDir_general + processors: + - HTTDir_general 追記部分の補足をします。 processors: レシーバーで得たデータを操作します。 HTTDir_general: PROCESSOR_ID を指定します。今回はRECEIVER_ID と同一名にしています。 type: ログの内容を解析・変換方法を指定します。 parse_regex では正規表現を使って解析し、JSON形式に変換します。元々のログ形式がJSON の場合は parse_json を利用します。 regex: type に parse_regex を指定した場合必須、正規表現で内容を解析し各キーにあてます。今回は正規表現を用いて 時間とメッセージで抽出しています。 service: processors: のPROCESSOR_IDを追記しています。 上記内容にconfig.yaml を変更しOps Agent サービスを再起動した後の jsonPayload の内容は次の通りになりました。 jsonPayload 内でtime キー と msg キーでログの値が抽出されている事が分かります。 key:value に分割 サポートされているサードパーティアプリであれば正規表現等は使わずとも良い感じにCloud Loggingへ収集してくれますので興味がある方は 公式ドキュメント を読んでみてください。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-gen の杉村です。当記事では、Google Cloud の認定資格である Professional Cloud Security Engineer 試験 の出題傾向や対策、知っておくべき技術領域などについて紹介します。 概要 Professional Cloud Security Engineer とは 難易度 推奨の勉強法 出題傾向 責任共有モデル 組織のポリシー 基本的な知識 把握しておくべき制約 Cloud Identity と ID 連携 アカウントとグループの管理 アカウント連携（プロビジョニング） Workload Identity Identity and Access Management（IAM） 基本的な知識 基本ロールと事前定義ロール コンピュートリソースと IAM ネットワークセキュリティ Virtual Private Cloud（VPC） VPC に関する参考記事 ハイブリッドネットワーク Cloud Armor、Cloud IDS Cloud Logging と Cloud Audit Logs 暗号化 Cloud KMS（Key Management Service） エンベロープ暗号化 デフォルトの暗号化と CMEK 暗号化 Sensitive Data Protection Sensitive Data Protection とは PII の発見と保護 DevSecOps（CI/CD） VPC Service Controls Security Command Center Compute Engine Confidential Computing Shielded VM その他のプロダクト Network Intelligence Center Secret Manager 概要 Professional Cloud Security Engineer とは Professional Cloud Security Engineer は、Google Cloud（旧称 GCP）のセキュリティ関連の知識と実務能力を問う認定資格です。 試験時間は120分、出題は50問〜60問の多肢選択式です。問題文はそこまで長くないため、落ち着いて解ければ十分な余裕があります。 なお、当試験は2022年2月までは英語版のみの提供でしたが、2022年3月より日本語での提供が開始されました。 参考 : Professional Cloud Security Engineer 当記事では、Professional Cloud Security Engineer 試験の出題傾向について紹介します。当記事で学習の方向性を決定し、実務にも応用可能な知識を習得してください。 難易度 当試験の難易度は、 中程度〜比較的高い と言えます。「応用情報技術者試験」程度の IT 基礎知識があり、かつ Google Cloud をある程度業務で使用した経験がベースとしてあることが望ましいです。 これに加えて、ネットワークセキュリティや Web アプリケーションセキュリティに関する基本知識を持っていることが望ましいです。IPA のネットワークスペシャリストや、情報処理安全確保支援士（旧セキュリティスペシャリスト）の知識も役立ちます。 なお Associate Cloud Engineer や Professional Cloud Architect 試験を先に取得しておくと、Google Cloud の基本知識が事前に習得できるため、学習コストが下がります。逆にいうと、これらの資格を既に取得済みの方であれば、あとは当記事を参考にして知識をアドオンしていけば、合格は難しくありません。 参考 : Associate Cloud Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog 参考 : Professional Cloud Architect試験対策マニュアル - G-gen Tech Blog 推奨の勉強法 Associate Cloud Engineer を取得する ただし Professional Cloud Security Engineer の受験手続きにあたっての必須要件ではありません 書籍、各社のブログ記事、公式ドキュメント等で Google Cloud のセキュリティ関係サービスの概要を理解する。特に以下のサービスに着目する IAM、組織（Organization）、組織のポリシー、VPC、Cloud Identity、Cloud KMS、Cloud DLP 試験ガイド を読み、出題範囲を理解 当記事を読み、出題傾向を把握 把握した試験範囲・出題傾向をもとに勉強 Google Cloud に限らない一般的なセキュリティ系知識（暗号化、ネットワーク、 Web アプリセキュリティ等）もこれを機に勉強し、理解する 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする 出題傾向 当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。そのように勉強すれば、試験に合格できるだけでなく、実践的な知識となるでしょう。 また、責任共有モデルや最小権限の原則をはじめ、多くのセキュリティの概念は、 Google Cloud に限らず情報セキュリティにおける一般的な知識です。この試験勉強を機に、セキュリティの基本的な知識を身につけ、実践できるようにしていくことが重要です。 なお、当記事の内容は2026年1月時点の、G-gen 従業員の受験体験に基づいています。 責任共有モデル クラウドユーザーが意識しておくべき最も重要なセキュリティの考え方として、 責任共有モデル があります。 どこまでがクラウド提供事業者（Google）の責任で、どこからが私たちクラウド利用者の責任なのか、自分の言葉で人に説明できるまで理解している必要があります。以下に、参考となるドキュメントへのリンクを記載します。 参考 : Google Cloud における責任と運命の共有 参考 : AWS クラウドセキュリティ - 責任共有モデル 責任共有モデルを理解しておけば、例えば Web アプリを Google Kubernetes Engine（GKE）などにホストした際に、私たちクラウド利用者が どの部分のセキュリティに責任を持つべきか 、という問いに答えられるようになります。 簡単に言うと、「データセンターの物理機器の管理は Google の責任」「マネージドサービスであれば概ね OS レイヤまでが Google の責任」であり、それ以外は私たちユーザーの責任です。つまり、Web アプリケーションのセキュリティ、すなわちセキュアコーディングであったり、 WAF（Web Application Firewall）がカバーすべきL7レイヤの脅威への対処は、私たち ユーザーの責任 です。 一方で、App Engine や Cloud Run のようなマネージドサービスでは、OS レイヤ以下は、 Google の責任 となります。 組織のポリシー 基本的な知識 当試験では、 組織のポリシー についての問題が頻繁に出題されます。 blog.g-gen.co.jp 以下のようなキーワードで、理解を深めてください。 制約 、 ブール型とリスト型 継承 （API パラメータとしては inheritFromParent : true または false ） 代表的な組織ポリシー（制約）の使い方 把握しておくべき制約 以下のような代表的な制約について、概要を把握してください。 参考 : ドメイン別の ID の制限 参考 : サービス アカウントの使用の制限 参考 : リソース ロケーションの制限 参考 : 公開アクセス防止を使用する Cloud Identity と ID 連携 アカウントとグループの管理 Cloud Identity（または Google Workspace）によるアカウントやグループの管理手法に関する質問に答えられるようにしてください。 あまり知られていない事実として、Cloud Identity のグループメンバーは、Cloud Identity の管理コンソールだけでなく、Google Cloud コンソールの「IAM と管理 > グループ」画面でも編集できます。操作者がグループ内で「マネージャー」や「オーナー」のロールを持っていれば、Cloud Identity 管理コンソールにアクセスすることなく、Google Cloud コンソール上でグループメンバーの追加や削除が可能です。セキュリティ維持のため、 組織外部のユーザー をグループに追加できないようにするには、Cloud Identity 管理コンソールで「 グループ オーナーは外部メンバーを許可できる 」のチェックボックスを外しておくことで禁止できます。また、グループごとに設定を変更することも可能です。 参考 : グループを使用するための組織全体のポリシーを設定する またアカウントのログインパスワードのポリシーに関する理解も必要です。Cloud Identity（または Google Workspace）では、脆弱なパスワードを使用できないようにパスワード要件を設定できます。「次回ログイン時にパスワードポリシーを適用する」のチェックボックスをオンにすることで、安全にポリシーを適用できます。 参考 : ユーザーのパスワード要件を適用、モニタリングする アカウント連携（プロビジョニング） 当試験では、Active Directory や Microsoft Entra ID と、Cloud Identity（または Google Workspace）の間でアカウントを同期する（プロビジョニングする）方法について、十分に理解しておく必要があります。 オンプレミスやクラウドの VM 上の Active Directory（AD）から Cloud Identity へアカウントをプロビジョニングするには、 Google Cloud Directory Sync （略称 GCDS）が使用できます。GCDS はサーバーにインストールするタイプのソフトウェアで、AD のアカウントを Cloud Identity に自動プロビジョニングできます。 参考 : Google Cloud Directory Sync について またクラウド型の Directory Sync 機能を使うと、GDCS と同様に、AD から Cloud Identity へアカウントをプロビジョニングできます。Directory Sync は、Entra ID にも対応しています。 参考 : Directory Sync のスタートガイド Entra ID の場合は、上記の Directory Sync を使う方法のほか、Entra ID に備わっている自動プロビジョニング機能を用いることができます。 参考 : Microsoft Entra ID（旧 Azure AD）のユーザー プロビジョニングとシングル サインオン Workload Identity Active Directory や Entra ID を始めとする外部の Identity Provider（IdP）から Google Cloud へシングルサインオン（SSO）する方法を、十分に理解してください。SAML や OAuth 2.0（OIDC）といった仕組みを使ったシングルサインオンについての一般的な知識が無い方は、まずはそちらを調べて、概要を理解したほうが良いでしょう。 そのうえで、SAML や OAuth 2.0（OIDC）に準拠した権限連携の仕組みである Workload Identity を理解してください。Workload Identity は、外部 IdP のアカウントを Cloud Identity にプロビジョニング することなく 、外部 IdP のアカウントに Google Cloud の IAM 権限を付与できる仕組みです。 Workload Identity を使うことで、例えば Entra ID（Active Directory）などの外部 IdP のユーザーに、Google Cloud 上で開発を行う権限を付与できます。こうしておけば、アカウントの管理自体は外部 IdP で行われるため、退職者等の権限は 外部 IdP 側でアカウントが削除された時点で消失 します。これで Google Cloud 側で権限を変更する必要がなく、運用が簡素になります。 参考 : Workload Identity 連携 Identity and Access Management（IAM） 基本的な知識 Identity and Access Management （IAM）の概念と仕組みを正しく理解しておく必要があります。以下の記事を参照して、IAM の仕組みを詳細に理解してください。 blog.g-gen.co.jp 以下の問いに、自分の言葉で答えられるようになっていれば、IAM の基礎知識が身についているといえます。 IAM 許可ポリシーとは何か IAM の継承とは何か プリンシパルにロールを紐づける、とはどういうことか 基本ロールと事前定義ロール 以下の基本ロールや事前定義ロールの仕様は、特に注意して把握しておくべきです。 基本ロール（閲覧者、編集者、オーナー） Resource Manager（組織、フォルダ関係） Cloud Logging Cloud Billing Cloud Storage 以下の公式ドキュメントを確認したり、あるいは Google Cloud プロダクトごとの IAM 関連のガイドを確認し、事前定義ロールを理解しておきます。 参考 : IAM roles and permissions index 参考 : IAM を使用したプロジェクトのアクセス制御 - Resource Manager 参考 : IAM によるアクセス制御 - Cloud Logging 参考 : Cloud Billing のアクセス制御と権限 - Cloud Billing 参考 : Cloud Storage に適用される IAM のロール - Cloud Storage コンピュートリソースと IAM Compute Engine、Cloud Run、Google Kubernetes Engine（GKE）などのコンピュートリソース上のプログラムから、Google Cloud APIs にアクセスするには、サービスアカウントの IAM 権限を使用します。これらの実行環境にサービスアカウントをアタッチすることで、プログラム上から権限を使用できます。サービスアカウント キー を発行することは、ほとんどの場合でベストプラクティスに反しているため、 選択肢になりません 。 Google Kubernetes Engine（GKE）の Pod からサービスアカウントの権限を使うには、 Workload Identity Federation for GKE という仕組みを使い、Kubernetes の世界のサービスアカウントと、Google Cloud の IAM の世界のサービスアカウントをマッピングする手法が一般的に行われます。 参考 : Workload Identity Federation for GKE について 最小権限を維持し、かつ権限を持つ時間を最短にするためには、サービスアカウントの 権限借用 （impersonation）という手法が使われることもあります。 参考 : サービス アカウントの権限借用 参考 : サービスアカウントの権限を借用して Terraform を実行する方法 - G-gen Tech Blog ネットワークセキュリティ Virtual Private Cloud（VPC） 基本的な Virtual Private Cloud（VPC）の仕組みはもちろん、応用レベルの仕様も理解しておきましょう。例えば、以下のような概念です。 VPC Flow Logs VPC Peering 共有 VPC VPC のルーティング（ 参考 ） 同一 VPC 内のサブネット同士のルート交換の仕様 VPC ネットワークピアリングを接続した際の VPC 同士のルート交換 VPC ファイアウォール Cloud NAT 上記の用語の意味を理解したうえで、以下のような少し複雑な VPC の仕様が具体的にイメージでき、設計に活かせるくらいの知識があると、問題にも回答できます。 VPC ネットワーク内に複数サブネットを作成すると、 全てのサブネット同士は通信できる （サブネット同士の通信のためのルートは、編集したり削除したりできない） VPC ネットワーク同士をピアリングすると、 VPC ネットワーク内の 全サブネットのルートが自動的に交換される （ルートは編集したり削除したりできない） VM は複数の VPC ネットワークの 複数のサブネットに足を伸ばせる （NIC を作ることができる） ファイアウォールにおいて、あるパケットが複数のルールに該当する場合、どのルールが適用されるか、 優先度 を理解する VPC に関する参考記事 VPC の詳細な仕様については、以下の記事も参照してください。 参考 : Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い - G-gen Tech Blog 参考 : Google CloudのVPCを徹底解説！(基本編) - G-gen Tech Blog 参考 : Google CloudのVPCを徹底解説！(応用編) - G-gen Tech Blog 参考 : Professional Cloud Network Engineer試験対策マニュアル - G-gen Tech Blog ハイブリッドネットワーク ハイブリッドネットワーク とは、オンプレミスと Google Cloud の VPC ネットワークを接続して、相互運用を行うようなアーキテクチャのネットワークのことです。 Cloud Interconnect 、 Cloud VPN 、 限定公開の Google アクセス などがキーワードとなります。 以下の公式ドキュメントを確認して、オンプレミスと VPC ネットワークを接続する際には、適切なプロダクトを選択できるようにしておきます。 参考 : Network Connectivity プロダクトの選択 これに関連して、 限定公開の Google アクセス （Private Google Access）機能を使い、オンプレミスからプライベートネットワーク経由で Google Cloud APIs を利用する方法も理解してください。以下の記事も参考にしてください。 blog.g-gen.co.jp Cloud Armor、Cloud IDS Google Cloud が提供するフルマネージドな WAF（Web Application Firewall）である Cloud Armor については、概要を理解してください。 blog.g-gen.co.jp Cloud IDS は、VPC ネットワーク内のパケットを検査し、マルウェアによる通信、コマンド&コントロール通信等を検知する仕組みです。VM に出入りするパケットの中身を検査することができます。 blog.g-gen.co.jp もしも「WAF が保護できる対象の脅威（攻撃手法）は何か」「IDS や IPS が保護できる対象の脅威（攻撃手法）は何か」「WAF、IDS、ファイアウォールの守備範囲の違いは何で、それぞれ目的は何か」といった一般的な問いに答えられない場合は、これを機に知識を再確認しておきましょう。 上記は Google Cloud に限定されない一般的な IT セキュリティの知識ですが、これが分かっていれば回答できる問題が、当試験では出題されます。 Cloud Logging と Cloud Audit Logs Cloud Logging と Cloud Audit Logs の仕組みも頻出です。監査ログを適切に出力し、保存する方法に関係しているためです。 blog.g-gen.co.jp blog.g-gen.co.jp 上記の記事を読み、以下の概念を正確に把握してください。 Cloud Logging のログシンクとログバケット、包含フィルター Cloud Audit Logs 管理アクティビティ監査ログと、データアクセス監査ログ 暗号化 Cloud KMS（Key Management Service） 当試験でも最も重要なのが、暗号化や鍵情報の扱いです。その中核にあるのが Cloud KMS です。Cloud KMS は FIPS 140-2 と呼ばれる、米国政府により規定されたセキュリティ要件仕様の規格に準拠した Google Cloud サービスです。 参考 : Cloud Key Management Service の概要 Cloud KMS のサービス詳細については以下の記事を参照してください。 blog.g-gen.co.jp さらに Cloud KMS 関連の以下の単語については、それぞれの違い、役割、仕組みを理解する必要があります。 顧客管理の暗号鍵（CMEK、Customer-Managed Encryption Key） 顧客指定の暗号鍵（CSEK、Customer-Supplied Encryption Key） Cloud EKM（External Key Manager） Cloud HSM（Hardware Security Module） エンベロープ暗号化 エンベロープ暗号化 （Envelope Encryption）という仕組みの理解が重要です。エンベロープ暗号化は Google Cloud の KMS に独自の技術というわけではなく、暗号化の世界ではしばしば用いられます。 Envelope Encryption という言葉で検索して解説を読んだり、以下のドキュメントを参考にするなどしてください。 参考 : エンベロープ暗号化 - Google Cloud 参考 : Concepts in the AWS Encryption SDK - Amazon Web Services デフォルトの暗号化と CMEK 暗号化 Google Cloud ではストレージ上のデータは、 デフォルト で 透過的に暗号化されている という点も重要です。 データの暗号化の基本的な考え方として at-rest （保存時）の暗号化 と in-transit （転送中。in-flight とも）の暗号化に分けることができます。それぞれについて Google Cloud の物理基盤ではどのような実装がされているか、以下のドキュメントを確認してください。 参考 : デフォルトの保存データの暗号化 参考 : Google Cloud の転送中データの暗号化 Google Cloud のデータはデフォルトで暗号化されているのにも関わらず、CMEK（顧客管理鍵での暗号化）が必要になる理由は、鍵の管理に関する要件への対応です。デフォルトの暗号化では、鍵の管理やローテーションは Google によって管理されています。暗号鍵を自組織で管理する要件や、ローテーション日数の厳密な指定がある場合は、Cloud KMS を利用して、CMEK を用います。 Sensitive Data Protection Sensitive Data Protection とは Sensitive Data Protection （旧称 Cloud DLP）の問題は頻出です。Sensitive Data Protection は PII（個人識別情報）等のセンシティブなデータを発見、分類、保護するためのフルマネージドサービスです。 参考 : Sensitive Data Protection の概要 PII の発見と保護 Sensitive Data Protection の主要な機能は、センシティブなデータの 「 発見 」と「 保護 （de-identification = 匿名化、redaction = 削除）」に大きく分けられます。 前者の「発見」については、 Cloud Storage や BigQuery 内のテキストや画像データの中に PII が含まれていないかどうかをスキャンできます。また、API 経由で Sensitive Data Protection に検査を指示することもできるため、例えば生成 AI の入出力テキストを検査して、PII の入力や出力を防止することもできます（現在では、この機能は Model Armor に統合されています）。 参考 : Google Cloud のストレージとデータベースに含まれる機密データの検査 参考 : テキストに含まれる機密データの検査 後者の「保護」については、特に匿名化（de-identification）機能の一種である 仮名化 （pseudonymization）を理解してください。仮名化とは、情報流出を防ぐため、PII を違う文字列に置き換える機能のことです。 参考 : 仮名化 仮名化には AES-SIV を使用した確定的暗号化 、 フォーマット保持暗号化 、 暗号ハッシュ という3つの手法があります。それぞれの違いと、ユースケースを把握しておいてください。 方式名 AES-SIV を使用した確定的暗号化 フォーマット保持暗号化 暗号ハッシュ サロゲートアノテーション 使用可 使用可 非対応 フォーマット保持 いいえ はい いいえ 復元可能 はい はい いいえ 参照整合性 はい はい はい AES-SIV を使用した確定的暗号化は、特定のアルゴリズムに準じて文字列を変換します。暗号鍵への適切な権限をもっていれば、暗号化後の文字列を復号して元の文字列を得ることもできます。「従業員の個人情報を、人事部署のみが参照できるようにする」などに適しています。 フォーマット保持暗号化は、復号が可能であることに加え、変換後の文字列を、元の文字列と同じ文字セットや長さで出力します。「開発部署がテストのためにユーザーデータを欲しがっている。クレジットカード番号や E メールアドレスは、本物と同じフォーマットにして欲しい。しかし、これらは個人情報であるため、本当の値を渡したくはない」といったユースケースで使用できます。 「暗号ハッシュ」はハッシュ化であるため、一度 PII を変換したら、元に戻すことはできません。ただし、入力が同じであれば出力も一意に決まるため、参照整合性はあります。つまり、仮名化した文字列と他のカラムのデータの関係性が保持されるため、分析用途で使用できます。 DevSecOps（CI/CD） Google Cloud で CI/CD パイプライン を実装し、パイプライン内にセキュリティを組み込む方法についても把握することが望ましいです。 参考 : Google Cloud 上での DevOps と CI / CD について フルマネージドのコンテナリポジトリサービスである Artifact Registry には、 コンテナスキャン 機能があります。コンテナスキャンを有効化すると、サポートされているベースイメー-じの OS やプログラミング言語のパッケージの依存関係をスキャンして、脆弱性を検知してくれます。 参考 : コンテナ スキャンの概要 また Binary Authorization を用いると、Google Kubernetes Engine（GKE）や Cloud Run といったコンテナ実行基盤に、 証明書 （attestations、署名とも訳される）のついた安全なコンテナイメージだけがデプロイされるように制限することができます。 参考 : Binary Authorization の概要 VPC Service Controls VPC Service Controls の基本については、以下の記事を参照して把握してください。 blog.g-gen.co.jp 境界 （perimeter）の考えや、境界の保護下に VPC ネットワーク内の VM インスタンスを組み入れるにはどうすればよいか、などを回答できるようにしてください。 境界内のリソースと、境界外のリソースが通信する方法も理解してください。 境界ブリッジ （perimeter bridges）を使うことで、異なる境界内のリソース同士でデータのやり取りが可能になります。 ただ、一方のリソースが VPC Service Controls の境界を使用していない場合は、境界ブリッジではなく、 内向きルール や 外向きルール を適切に設定する必要があります。それぞれをどういったときに、どのように設定すべきなのかについて、以下の記事を読み込んで把握してください。 blog.g-gen.co.jp Security Command Center Security Command Center （SCC）は、Google Cloud 環境の脆弱性や構成ミス、不審な挙動などを検知してリストアップしたり、通知するサービスです。SCC は複数の機能を擁していますので、どのような機能があるのか、どのように使うべきなのかを、公式ドキュメントや以下の記事を参考に把握してください。 blog.g-gen.co.jp SCC のどの機能がどのレイヤの脆弱性を検知できるのか、適切に答えられるようにしましょう。 Security Health Analytics は Compute Engine や VPC ファイアウォール、Cloud Storage などの不適切な設定や設定ミスを検知することができます。 Web Security Scanner は Web アプリに対する L7 レベルの脆弱性スキャンを定期的に実行することが可能です。 Virtual Machine Threat Detection は、VM をスキャンして クリプトマイニング （暗号通貨採掘）、カーネルモードルートキット、マルウェアなどを検出します。VM のゲストメモリからメタデータを読み取って検査するので、エージェントソフトウェアは不要です。 Compute Engine Confidential Computing 近年では at-rest / in-transit のデータ暗号化に加えて、 メモリ上のデータ暗号化 も加える場合があります。Google Cloud の Confidential Computing の考え方では、ストレージ上や通信経路上のデータだけでなく、メモリ上のデータも暗号化します。これを実現する VM を、Confidential VM と呼びます。 参考 : Confidential Computing のご紹介 参考 : Confidential Computing の概要 Shielded VM Shielded VM は、VM がセキュアに起動することを担保するために高度な設定を有効化した Compute Engine VM のことです。 セキュアブート 、 vTPM 、 整合性モニタリング といったオプションを有効化して VM を起動することで、ブートレベルやカーネルレベルなど低レイヤで動作するマルウェアやルートキットなどに対処できます。この3つのキーワードを覚えてください。以下のドキュメントや記事も参照してください。 参考 : Compute Engineを徹底解説！（応用編） - G-gen Tech Blog - Shielded VM 参考 : Shielded VM の概要 その他のプロダクト Network Intelligence Center Network Intelligence Center の概要を把握しておいてください。 参考 : Network Intelligence Centerを徹底解説！ - G-gen Tech Blog Firewall Insights 機能など、ネットワークセキュリティとガバナンスの維持に有用な機能が利用できます。Firewall Insights ではその Firewall ルールが何回ヒットした（実際に使われた）か、また最後に使われたのはいつか、などを確認することができます。また優先度のせいで別のルールの影に隠れて使われていない Shadowed rules を見つけることもできます。増えすぎたファイアウォールルールを棚卸しするときに便利な機能です。 Secret Manager Secret Manager はアプリケーションが利用するパスワード、証明書、 API キーなどの機密情報を格納するためのセキュアなストレージサービスです。 参考 : Secret Manager の概要 API 呼び出しでシークレット（機密情報）を格納したり、取り出したりできるほか、バージョニングやローテーションといった管理機能があります。Secret Manager に格納されたシークレットはデフォルトで暗号化されており、オプションで前述の Cloud KMS の CMEK を利用することもできます。 試験の傾向として、サービスアカウントのシークレットキーを発行して Secret Manager に格納するような選択肢は、 ほぼ誤り であると考えてください。なぜなら、Secret Manager にアクセスすること自体に権限が必要になるため、ではその権限はどう管理するのか、という話になるからです。試験の世界においては、サービスアカウントは VM や Cloud Run などの実行環境にアタッチして使うものであり、キーを発行するという選択肢が正答になることはほとんどないといえます。また、それが Google Cloud のベストプラクティスであることを示しています。 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは G-gen の渡邉@norry です。 Goole Workspace を運用する際に管理者が特に気になる事の一つとして、セキュリティー関連のレポートや監査ログがあるかと思います。 常日頃のガバナンス管理、有事の際での証跡として...今回は Google Workspace でどういったログが取れるのかのご案内と、プランによっては取得出来ないログもありますのでその点にも触れます。 Google Workspace の機能比較やプラン一覧はこちらをご覧ください。 blog.g-gen.co.jp レポート レポートの表示方法 レポートの種類 監査ログ 監査ログの表示 Google Workspace で利用可能な監査ログ プラン別の違い Google Workspace プラン別項目一覧 ログ出力のタイムラグ 保持期限 ログのエクスポート エクスポートについて スプレッドシート、CSV へエクスポート BigQuery へのエクスポート Reports API を利用したログ取得 アラート レポート レポートの表示方法 Google Workspace 管理コンソールにて「 レポート ＞ レポート 」を選択することで各種レポートを表示することができます。 レポートではグラフやチャート、表を用いてアプレケーションやアカウント情報などを閲覧者に対し、どういう状況にあるかを視覚的に分かりやすく表示します。 アカウントのレポート レポートの種類 管理コンソールから確認可能なレポートの種類は以下のようなものがあります。 レポート 内容 重要ポイント レポート 組織の主な指標と傾向の概要を確認できます。サービスの使用状況、ドキュメント公開設定、保存容量、ファイル共有アクティビティ、基本的なセキュリティ指標などが含まれます。 組織全体のアプリレポート ドメイン内のすべてのユーザーと管理者に関するチャートとグラフを閲覧できます。組織全体の傾向と管理情報の概要も含まれます。 ユーザー レポート: アカウント セキュリティとアプリの使用状況に関するアクティビティ情報の重要ポイントがマスター レポートとして示されます。 ユーザー レポート: アプリの使用状況 組織での Gmail とドライブの使用状況が示されます。メール アクティビティの種類、作成および共有されたドキュメントの数、各チームメンバーによるドライブ ストレージの使用容量などが含まれます。 ユーザー レポート: セキュリティ ドメイン全体でのデータ漏洩リスクを評価できます。また、チームの 2 段階認証プロセスの使用状況、モバイル デバイスにサードパーティ製アプリをインストールしているユーザー、ドメイン外のユーザーとのドキュメント共有状況などを確認できます。 監査ログ 管理者のアクティビティ、モバイル アクティビティなど、特定のイベントに関する情報を入手できます。 監査ログ 監査ログの表示 Google Workspace 管理コンソールにて「 レポート ＞ 監査 」を選択することで各種レポートを表示することができます。 監査ログには 「誰が」 「いつ」 「何に対して」 「どのような操作」 を行ったかが記録されます。 例えば 管理者の監査ログ では、Google 管理コンソールで行われた操作の記録を確認できます。管理者がユーザーを追加した日時や Google Workspace サービスを有効にした日時などですね。 また、Google Drive であれば下図のようにどの種類のファイルをいつ誰が操作したのか分かるようになっています。 先のレポートの項目ではビジュアル的にどの程度かを把握するのに適しており、監査ログではより詳細な内容について把握する事が可能です。 ドライブの監査ログ Google Workspace で利用可能な監査ログ Google Workspace で利用可能な監査ログは こちら になります。代表的な物として以下のようなものがあります。 管理者の監査ログ ログインの監査ログ デバイス監査ログ メールログ検索 Google Chat の監査ログ Google Meet の監査ログ プラン別の違い Google Workspace プラン別項目一覧 どのプランでどういったレポートや監査ログが取得出来るのかを一覧にしてみました。 Frontline Business Starter Business Standard Business Plus Enterprise Essentials Enterprise Standard Enterprise Plus アプリとユーザーのレポート ✔ ✔ ✔ ✔ ✔ ✔ ✔ 監査ログ ✔ ✔ ✔ ✔ ✔ ✔ ✔ ドライブ監査 ✔ ✔ ✔ ✔ ✔ Meet の出席レポート ✔ ✔ ✔ ✔ BigQuery へのエクスポート ✔ ✔ アクセス透明性ログ ✔ インサイト レポート ✔ 大きな違いとしてプランの中に ドライブ が含まれるか？がポイントになります。 Business Starter 及び Enterprise Essentials にはドライブ (共有ドライブ) が含まれていません。 従って監査ログにもドライブの項目が存在せず、レポートとしては表示が可能ですが詳細な操作ログを閲覧するには適していない為、ドライブの操作ログを取得したい場合には Business Standard 、Enterprise Standard 以上のプランをおすすめします。 アクセス透明性のログは社内のデータに Google のスタッフがアクセスしたときの操作情報を把握することができるとあり、インサイトレポートではダッシュボードを作成し組織での Google Workspace の使用に関する詳細な指標を得ることができます。 特に Enterprise 環境において必要になる場合があるでしょう。 ログ出力のタイムラグ Google Workspace のログには保持期間とレポートやログに反映されるまでのタイムラグがあります。 詳しくは こちら を見ていただければと思いますが、大まかに下記のようになります。 項目 期間 備考 レポート 1～3 日 監査ログ ほぼリアルタイム（数分以内） 項目によっては1～3 日 データの保持期間 6ヶ月 項目によっては12 か月 アカウントログやドライブの操作ログなど一般的に即時性が求められるようなログに関してはほぼリアルタイムに反映されます。 保持期限 データの保持期間が 6ヶ月の為、特に監査ログなど6ヶ月以上保持する必要がある場合にはエクスポートする等の対応が必要になります。 後述しますが、ログを参照するための API をGoogle では提供していますので、リアルタイムにログを検知、通知を行う機能を利用者側で実装も可能となっています。 ログのエクスポート エクスポートについて 前項でデータの保持期間が6ヶ月 (項目によっては12ヶ月) と述べました。 ではそれ以上の期間のログを取得したい場合にどうするか？大きく別けて以下の3パターンになります。 スプレッドシート、CSV へエクスポート BigQuery へエクスポート Reports API を利用したログ取得 スプレッドシート、CSV へエクスポート Google Workspace 管理コンソール ＞ レポート ＞ レポート ＞ アプリレポート の各項目より、スプレッドシートまたは CSV でダウンロードする事が可能です。 例としてアプリレポート ＞ アカウント の「2 段階認証プロセスの登録と適用」に遷移し画面右上にあるダウンロードアイコンを押下します。 2 段階認証プロセスの登録と適用 スプレッドシートまたは CSV でのダウンロードが確認できます。 ダウンロード 実際にダウンロードしたスプレッドシートは以下のようになります。 スプレッドシートへのエクスポート 注意点として、一度にダウンロード可能なレコード数は 100,000行 という制限が存在するため、制限を超えて取得する為には BigQuery Export を利用するといった対応も必要になります。 BigQuery へのエクスポート Google Workspace 管理コンソール ＞ レポート ＞ BigQuery Export から Google Cloud (GCP) の BigQuery へ出力する事が可能です。分析用データベースに出力する事により SQL を利用した抽出が行えます。 BigQuery Export BigQuery へのエクスポートでは次のようなデータを利用可能です。 使用状況レポート - ライセンスの有無にかかわらずドメイン内のすべてのユーザー（使用状況テーブル）。 監査ログ - Google Workspace Enterprise を利用している組織は、ドライブとモバイルの監査ログを書き出すことができます。管理者、Google カレンダー、Google グループなどのその他のログについては、すべてのユーザー（全エディション）のデータが BigQuery に書き出されます。 ただし BigQuery のエクスポートを利用する為には Google Workspace の Enterpriseエディション、もしくはEducation Standard / Plusエディション の契約が必要になりますのでご注意ください。 Google Workspace の管理者ヘルプには SQL の抽出クエリの例、例えば以下のように「Gmail の 30 日間のアクティブ ユーザー数に対する 1 日あたりのアクティブ ユーザー数の割合」の取得方法等も示されています。 BigQuery にエクスポートされる内容は多岐にわたる為、一度目を通してどのような抽出が出来るのかを把握しておくことをおすすめいたします。 #1 日あたりのアクティブ ユーザー SELECT date, gmail.num_1day_active_users FROM api_project_name.dataset_name.usage WHERE gmail.num_1day_active_users > 0 ORDER BY 1 DESC; # 7 日間のアクティブ ユーザー SELECT date, gmail.num_7day_active_users FROM api_project_name.dataset_name.usage WHERE gmail.num_7day_active_users > 0 ORDER BY 1 DESC; # 30 日間のアクティブ ユーザー SELECT date, gmail.num_30day_active_users FROM api_project_name.dataset_name.usage WHERE gmail.num_30day_active_users > 0 ORDER BY 1 DESC; 抽出例について知りたい方は コチラ を参考にしてみてください。 Reports API を利用したログ取得 Google Workspace には Google Workspace Admin SDK (ソフトウェア開発キット) が用意されています。 Google Workspace の Reports API を利用して手組みで実装する事も可能ですが、監査ログの仕様は幅が広く少し敷居が高いと言えます。ご興味があられる方は Reports API に関するドキュメント コチラ をご参照ください。 アラート アラートの設定は Google Workspace 管理コンソールの「 ルール 」から行えます。 Google Workspace の管理者は「ルール」作成する事により、特定の条件下においてユーザーにメール通知が可能です。 ルール 作成可能なルールの主な種類は以下になります。 アクティビティ - ドメイン内のアクティビティに応じた操作 データの保護 - ドメイン内のドライブ ファイルの使用に関連する特定のアクティビティが発生したときに通知 レポート - 組織の監査ログに基づいてカスタム アラートを作成、管理 例えば監査ログのイベントに基づいてアラート設定する場合には、 管理コンソール ＞ ルール ＞ ルールを作成 を押下し レポート を選択します。 ルールを作成 監査ログに遷移しますので +フィルタを追加 ＞ 「イベント」 を選択し、検索欄に通知を行いたいイベントを入力し、適用します。今回は ドライブの設定の変更 を適用しました。 イベントを検索 画面右上のベルのマークを押下します。 ルールの名前、受信者 (アラートセンター、特権管理者、追加の宛先)を選択、作成して完了となります。 レポートルールを作成 作成したルールは、 管理コンソール ＞ ルール の一覧の中に表示されます。 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-gen の杉村です。Google Cloud (旧称 GCP) 認定資格である Looker LookML Developer 試験 は、他の Google Cloud 認定試験とは一線を画し、かつては Google Cloud とは別プロダクトであった Looker の開発者向け認定資格です。 本投稿では試験の合格に役立つ情報を記載します。 ※ 当試験は 2022/04/01 をもって 廃止 となりました。しかしながら当記事は Looker の製品知識の取得に役立ててもらう意味を込めて、公開のままとさせていただきます。 はじめに 本投稿の想定読者 Looker LookML Developer 試験の難易度 推奨の勉強法 出題傾向 フィルタとアクセス制御 フィルタを強制する アクセス制御 Dimension & Measure フィールドタイプ 持続可能な LookML Explore / View Derived Table (派生テーブル) ユーザーの利便性向上 開発と Git トラブルシューティング ベストプラクティス その他 日本語版試験と英語版試験 受験環境 Looker LookML Developer はじめに 本投稿の想定読者 本投稿は以下のような方向けです。 Looker LookML Developer 試験を受けるために勉強をしており出題傾向を知りたい Looker の基本的な知識は習得済み、もしくはある程度実務で使ったことがある 近日中に試験を受けようと思っているので、最後の勉強をしている Looker LookML Developer 試験の難易度 当試験の難易度としては、中程度だと言えます。 Looker を通常業務で用いており、 LookML を日常的に扱っている人にとっては、当記事を参考にポイントを押さえた追加学習を行うことで十分合格できます。 ただし LookML の初心者であったり、 Looker をあまり扱った経験のない人にとっては、まずはトレーニング等で基本を押さえてからでないと当試験の合格は難しいでしょう。 推奨の勉強法 Google (Looker チーム) の実施している公式トレーニングなどを受けて、基礎的なスキルを習得する (ここが最も重要であり取っ掛かりになります) 試験ガイド を読み出題範囲を理解する 当記事を読み、出題傾向を理解する 理解を深めたいパラメータについては公式ドキュメントを読んだり、インターネット検索して各社の公開する技術ブログを読む。実際に Looker 環境で使ってみることも重要 最後にまた、当記事で復習する なお当試験は 2022 年 1 月現在、 英語でのみ提供 されています。 他の Google Cloud 試験と比べても 1 問の問題文が長い傾向があるため、英語ドキュメントを読むことに慣れていないと、まず問題文を理解することに脳のリソースを使ってしまうことになりかねません。 Looker ドキュメントは普段から英語で読む ように癖づけましょう。 また試験時間は 100 分であり、先述の通り問題文が長いため、他の Google Cloud 試験に比べて時間的余裕がありません。 筆者も、当試験の受験時点で 4 つの Google Cloud 試験を合格済みでしたが、もっとも時間的に焦りを感じた試験となりました。 時間配分は、普段以上に気をつける必要がありそうです。 出題傾向 当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。 わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。 そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。 フィルタとアクセス制御 フィルタを強制する ソースデータベースから取得するデータを適切に絞ることは、とても重要です。 BigQuery を始め、多くのカラムナ (列志向) のデータウェアハウス製品では、適切なクエリを書かなければ テーブルにフルスキャンがかかってしまう 可能性があります。 これは不要な負荷をデータベースにかけることになるだけでなく、製品によってはスキャン量に応じた課金となるため、コスト的なデメリットもあります。 Looker では以下のようなパラメータが用意されており、 LookML の工夫次第でユーザーが不用意に巨大なクエリを投げてしまうことを防ぐことができます。 ※ (凡例) [利用箇所] パラメータ名 [Explore] sql_always_where [Explore] always_filter [Explore] conditionally_filter これらのパラメータについては、サブパラメータの書き方も含めてしっかり押さえておく必要があります。 ただドキュメントを眺めるのではなく「実業務ではどういうときにこのパラメータを使うのか？」「似たパラメータ名だが、違いは何なのか？」を理解すると良いでしょう。 アクセス制御 Looker のユーザーには User Attribute という属性を持たせることができます。 例えば department という Attribute を持たせ、ユーザーごとに executive, sales, store-manager のように役職・部署名を持たせます。 Looker ではこの User Attribute ごとに、見せるデータを変えることができます。 Explore ごと、 Join/View ごと、フィールドごとに見せ方を変えることができますし、行単位で制御することも可能です。 以下のパラメータを用います。 [Explore] access_filter [Model] access_grant [ Explore / Join / View / Field ] required_access_grants これらのパラメータについても、やはりサブパラメータの書き方も含めてしっかり押さえておく必要があります。 繰り返しになりますが「実業務ではどういうときにこのパラメータを使うのか？」「似たパラメータ名だが、違いは何なのか？」を考えつつ勉強します。 access_filter は User Attribute の値をもとに行をフィルタします。強制的に SQL の WHERE 句が追加されます。 access_grant と required_access_grants はセットです。 User Attribute の値に応じて Explore / Join / View / Field の閲覧を許可するかどうかを設定できます。 Dimension & Measure フィールドタイプ Dimension や Measure の各タイプやその特徴を押さえておきます。 Measure では sum や number といった頻繁に使われるタイプはもちろん、 sum_distinct や percent_of_total など、様々なタイプの用法、サブパラメータも押さえておきましょう。 持続可能な LookML 持続可能な LookML (運用を崩壊させず、継続でき、かつスケールできるような LookML の書き方) に関する問題は多く出てきます。 例えばフィールドを set でまとめて Explore 側の fields パラメータで指定できるようにしておく、であったり、万一フィールド名を変えたときのために alias を使ったり、などというテクニックです。 これは後述する ベストプラクティス にも記載があります。 Extends の利用などもこれに含まれるでしょう。 Explore / View Explore の各パラメータを把握しておきます。 特に重要になるのが、 View 同士の 結合 に関する知識です。 Looker では 対称集計 (Symmetric Aggregates) が可能であり、これを適切に働かせるには join において relationship パラメータを適切に設定する必要があります。 なお対称集計に関連して Explore には symmetric_aggregates というパラメータがありますが通常は省略され、デフォルトは yes です。 そもそも対称集計とは何か、そしてそれが集計結果にどう影響を及ぼすのか、についてまずはキャッチアップしましょう。 Derived Table (派生テーブル) 試験にあたり Looker の Derived Table (派生テーブル) 機能を使いこなせるようになっている必要があります。 Looker における View を一般的なデータベース用語における「テーブル」に見立てると、 Derived Table は「ビュー」に当たります。 日単位→月単位のように粒度を変えたり、 Measure を Dimension 化したり、複雑なロジックを事前に入れ込んだりするために用います。 Derived Table の種類は "Persistent / Temporary" の軸と "Native / SQL" の軸があり、都合 4 種類あるといえます。 試験では、特に Persistent Derived Table (PDT) の扱いが注目されます。 そもそも、 PDT を使いたいときはどんなときなのかを把握しましょう。 一般的なデータベース用語における「ビュー」が Temporary Derived Table だとすると、 Persistent Derived Table は「マテリアライズド・ビュー」に当たります。 指定したデータベースに物理テーブルとしてデータを事前に永続化するので、パフォーマンスの向上が見込めます。 また PDT はデータベースに物理テーブルとして永続化されるので、リフレッシュのタイミングの指定方法が重要です。 datagroup の使い方をしっかり説明できるようにしておきましょう。 「 sql_trigger と max_cache_age の違いや使い方」「ソーステーブルの ETL プロセスと PDT リフレッシュのタイミングを合わせるにはどうするか」などの理解は必須です。 sql_trigger の書き方はドキュメントの「 Examples 」が参考になります。 またキャッシュ周りは似たようなパラメータが多いのでドキュメント Persistence strategies を読んでおきましょう。 ユーザーの利便性向上 LookML Developer 試験は開発者向けの試験ですが、ユーザー目線を意識させる問題が多いです。 どのように実装すれば利用者にとって嬉しいか、を考えさせます。 以下のようなベストプラクティスを覚えておきましょう。 必要最小限のフィールドだけが見えるようにする 不要なフィールドは Explore/Join の fields パラメータで除外 見せる必要のないフィールドは hidden パラメータで隠す 似たフィールドは group_label パラメータでグルーピングする group_label は explore にもある 分かりやすい名前を付けるため view_label パラメータを使う view_label は explore / view / join にもある 開発と Git Looker は Git と統合 できます。 GitHub などの外部レポジトリを用いるのが推奨です。 Bare Git repository と呼ばれる Looker サーバに配置するレポジトリのみを利用するモードもあり、これを利用すれば外部の Git を用意しなくてよいのですが、これだと開発者は Looker のブラウザベース IDE からローカルレポジトリのみを編集するような形になり、推奨されていません。 外部レポジトリを使う場合 HTTPS と SSH の 2 通りの接続方法が利用できますが、認証方法に違いがあるため、ドキュメントをそれぞれ確認しておきましょう。 例えば HTTPS 接続にした場合でも Single account HTTPS authentication と Multiple account HTTPS authentication の 2 種類があり、前者だと Git ログインに使われる認証情報を一つだけ設定する、など違いがあります。 トラブルシューティング 試験ガイドにあるように Content Validator で何ができるのかはよく確認しておきましょう。 壊れた参照などを検知する機能に加え、これを修正する機能も備わっています。 また LookML を開発していると様々なエラーメッセージに直面します。 Looker error catalog というドキュメントには、エラーメッセージと考えられる原因がまとめられています。 この一覧はチェックしておきましょう。もちろん、すべて覚える必要などありませんが [IDE] のマークが付いているメッセージは要確認です。 ベストプラクティス 公式の Looker Help Center に掲載されている、以下のベストプラクティスは読んでおきましょう。 試験問題だけでなく、業務に直結する知見が得られるかもしれません。 Best Practice: LookML Dos and Don'ts Best Practice: Optimize Looker Performance Best Practice: Create a Positive Experience for Looker Users Best Practice: Writing Sustainable, Maintainable LookML その他 日本語版試験と英語版試験 Google Cloud 認定資格の試験を申込みする際は KRYTERION の Webassessor の Web サイトでアカウントを作成して申し込みます。 しかし、アカウント作成時に言語を 日本語 として作成すると、日本語版の Google Cloud 認定資格しか申し込むことができません。 英語版しか提供されていない Looker 試験を申し込むには 2022 年 2 月現在、 言語を英語とした新しいアカウントを作成 する必要があります。 Webassessor のログイン画面が以下のように日本語表記の場合、英語版に切り替えてから新しいアカウントを作成し、そのアカウントで申し込みます。 別言語でアカウントを作成 受験環境 当社メンバーの Google Cloud 認定試験の受験環境に関する実体験が以下の記事で紹介されています。 ぜひご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の渡邉@norry です。Compute Engine VM にアタッチする サービスアカウント と、VM の アクセススコープ の概念について整理しました。 はじめに 前提知識 サービスアカウントとアクセススコープ IAM 検証 「デフォルトのアクセス権を許可」の場合 「すべての Cloud API に完全アクセス権を許可」の場合 まとめと補足 IAM の権限とアクセススコープ 最小権限の原則を意識する はじめに Google Cloud（旧称 GCP）の Compute Engine では、VM を作成する時にデフォルトで Compute Engine のデフォルトサービスアカウントがアタッチされます。 参考 : サービス アカウント - Compute Engine のデフォルトのサービス アカウント このサービスアカウントの権限とアクセススコープの範囲によっては、意図しないセキュリティホールが生まれる可能性があります。例えば、悪意を持った第三者が仮想マシンから gcloud コマンドを操作して新たな仮想マシンを起動し、暗号通貨の採掘（クリプトマイニング）を行うなどの事故が考えられます。 今回の記事では、改めて Compute Engine における サービスアカウント と アクセススコープ の概念を整理します。 前提知識 サービスアカウントとアクセススコープ Compute Engine における サービスアカウント と アクセススコープ の基礎知識については、以下の記事の サービスアカウントとアクセススコープ の項をご参照ください。 参考 : Compute Engineを徹底解説！（応用編） - G-gen Tech Blog - サービスアカウントとアクセススコープ アクセススコープは、サービスアカウントの権限に「フタをする」ような挙動をすると考えれば分かりやすくなります。 当記事では、上記の点について検証します。 IAM Google Cloud のリソースと IAM の関係性については、以下の記事を参照してください。 blog.g-gen.co.jp 検証 「デフォルトのアクセス権を許可」の場合 VM を新規作成します。アタッチするサービスアカウントとして、 Compute Engine default service account を選択します。アクセススコープ設定は デフォルトのアクセス権を許可 を選択します。 アクセス スコープ デフォルトのアクセス権を許可 VM 作成後に、詳細画面の セキュリティとアクセス のブロックの下にある、 API と ID の管理 の項目で、VM にアタッチされているサービスアカウントと、設定されているアクセススコープが確認できます。さらに、Show detials を押下すると、アクセススコープの詳細が確認できます。 サービスアカウントとアクセススコープ デフォルトのアクセス権を許可 だと、Compute Engine API や BigQuery API へのアクセス許可は無効となっている事が分かります。反対に、許可されているのは Cloud Logging（旧称 Stackdriver Logging）や、Cloud Monitoring（旧称 Stackdriver Monitoring）への書き込みです。これは、Cloud Logging へログを送信したり、Cloud Monitoring へメトリクスを送信できることを意味しています。また、Cloud Storage（画面上は「ストレージ」と記載）への読み取りも許可されています。 この状態で VM に SSH 接続し、gcloud コマンドで VM を作成することを試みます。 norry@instance-1:~$ gcloud compute instances create instance-2 Did you mean zone [ asia-northeast2 -a] for instance: [ instance -2] ( Y/n ) ? Y ERROR: ( gcloud.compute.instances.create ) Could not fetch resource: - Request had insufficient authentication scopes. リクエストの認証スコープが不足している（ Request had insufficient authentication scopes. ）と表示され、VM が作成出来ませんでした。アクセススコープで制限されているため、このようなエラーとなります。 「すべての Cloud API に完全アクセス権を許可」の場合 次にアクセススコープを すべての Cloud API に完全アクセス権を許可 にします。この設定では、アクセススコープではアクセス先 API を制限しない状態になります。この設定にした場合、サービスアカウントが権限を持ってさえいれば、すべての操作が実行できます。 VM のアクセススコープを変更するには一度 VM を停止する必要があります。 サービスアカウントとアクセススコープ 設定変更が完了したら、再度 VM に SSH 接続し、gcloud コマンドで VM を作成してみます。 norry@instance-1:~$ gcloud compute instances create instance-2 Did you mean zone [ asia-northeast2 -a] for instance: [ instance -2] ( Y/n ) ? Y Created [ https://www.googleapis.com/compute/v1/projects/xxxxxx/zones/asia-northeast2 -a /instances/instance -2] . NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS instance -2 asia-northeast2 -a n1-standard -1 RUNNING 上記のように、VM の作成が成功しました。アクセススコープではアクセス先 API が絞られていないためです。サービスアカウントが VM 作成権限を持っているので、操作が成功しました。 次に、アクセススコープが すべての Cloud API に完全アクセス権を許可 であっても、サービスアカウントが権限を持っていない操作は行えないことを、念のために確認します。 VM のアクセススコープは すべての Cloud API に完全アクセス権を許可 のままで、サービスアカウントの IAM ロールを編集者から閲覧者へ変更します。 編集権限から閲覧権限へ 再度 VM に SSH 接続し、gcloud コマンドにて VM を作成してみます。 norry@instance-1:~$ gcloud compute instances create instance-3 Did you mean zone [ asia-northeast2 -a] for instance: [ instance -3] ( Y/n ) ? ERROR: ( gcloud.compute.instances.create ) Could not fetch resource: 上記のように、サービスアカウントが権限を持っていない操作が拒否されることが確認できました。 まとめと補足 IAM の権限とアクセススコープ サービスアカウントの持つ権限と、VM のアクセススコープ設定の状態ごとの、操作実行可否を表に表すと以下のとおりです。 アクセススコープ : デフォルト アクセススコープ : すべての Cloud API サービスアカウント : 編集者 ✕ (アクセススコープで拒否) ◯ (両方で許可) サービスアカウント : 閲覧者 ✕ (アクセススコープで拒否) ✕ (IAM で拒否) VM のアクセススコープ設定が デフォルトのアクセス権を許可 では Compute Engine API への操作が無効なので、サービスアカウントに十分な権限があっても新たに VM を作成する事が出来ませんでした。 反対に、VM のアクセススコープ設定が すべての Cloud API に完全アクセス権を許可 であっても、サービスアカウントに権限がなければ VM を作ることはできません。 VM のアクセススコープ設定は、サービスアカウントの権限に「 フタをする 」ような挙動をすると考えればよいでしょう。 最小権限の原則を意識する 情報システムの権限管理においては、アカウントに対しては必要最小限の権限だけ与えるべきだという「 最小権限の原則 」が基本となります。 しかしながら、Compute Engine デフォルトのサービスアカウントが自動的に作成される際には、プロジェクトレベルで 編集者 （roles/editor）ロールが付与されてしまいます。 編集者は、強力なロールです。何も意識しなければ、VM のアクセススコープは デフォルトのアクセス権を許可 のはずなので、操作可能範囲はある程度制限されていますが、意図せずアクセススコープを すべての Cloud API に完全アクセス権を許可 などに設定してしまうと、かなり広い範囲の操作が可能になってしまいますため、十分注意が必要です。 この仕様への対処として、 組織のポリシー で以下を設定することができます。 制約名 ID 説明 デフォルトのサービス アカウントに対する IAM ロールの自動付与の無効化 constraints/iam.automaticIamGrantsForDefaultServiceAccounts 有効化することでデフォルト Compute Engine サービスアカウント作成時に編集者権限が付与されなくなる なお上記の制約は、2024年初頭以降に新しく作成された Google Cloud 組織では、はじめから有効化されている場合があります。 組織のポリシーについては、以下の記事も参照してください。 blog.g-gen.co.jp 渡邉 宣之 (記事一覧) クラウドソリューション部 AI/ML、アプリケーションモダナイゼーション、データ分析基盤の構築、クラウド管理運用やネットワークなどインフラ系は何でも、Google Workspace 活用も推進中 週末フォトグラファーで、観葉植物や塊根植物にハマっていて種から育ててます。

G-genの荒井です。当記事では Google Cloud 認定資格 の一覧や、各試験の概要をご紹介します。Google Cloud を仕事で取り扱う方や、興味があって調べている方向けに資格の概要をご紹介しますので、どんな資格が自分に必要か見定めて資格取得を目指していただければと思います。 はじめに Google Cloud 認定資格とは 資格の種類 認定資格のメリット ルール・受験方法 言語・試験時間・料金 受験場所 有効期限と再認定 資格取得の順番 再試験 Google Cloud 認定資格の詳細 Foundational レベル Cloud Digital Leader Generative AI Leader Associate レベル Associate Cloud Engineer Associate Google Workspace Administrator Associate Data Practitioner Professional レベル Professional Cloud Architect Professional Cloud Database Engineer Professional Cloud Developer Professional Data Engineer Professional Cloud DevOps Engineer Professional Cloud Security Engineer Professional Cloud Network Engineer Professional Machine Learning Engineer Professional Security Operations Engineer 番外編 Professional ChromeOS Administrator 廃止された試験 Looker LookML Developer Looker Business Analyst Professional Google Workspace Administrator はじめに Google Cloud 認定資格とは Google Cloud 認定資格とは、Google Cloud に関する公式の認定資格です。Google Cloud に関する知識やスキルが評価されます。 2025年11月現在、Google Cloud 認定資格は 14個 あります。テクノロジー分野ごとに資格が用意されているため、資格を取得することでその分野における知識・スキルを保持していることが証明できます。 以下は、Google Cloud 認定資格の公式案内ページと、詳細なヘルプドキュメントです。日本語のページは最新情報に更新されていない場合がありますので、最新情報を得るためには、ページ最下部右側のセレクタで英語版に切り替えてください。 参考 : 認定資格 | Google Cloud 参考 : Google Cloud 認定資格 ヘルプ 資格の種類 Google Cloud 認定資格には、どのようなものがあるか確認してみましょう。 Google Cloud 認定資格は、Foundational（基礎）、Associate（アソシエイト）、Professional（プロフェッショナル）の3段階に別れています。 Foundational レベル Associate レベル Professional レベル Foundational レベル Cloud Digital Leader Generative AI Leader Associate レベル Associate Cloud Engineer Associate Google Workspace Administrator Associate Data Practitioner Professional レベル Professional Cloud Architect Professional Cloud Database Engineer Professional Cloud Developer Professional Data Engineer Professional Cloud DevOps Engineer Professional Cloud Security Engineer Professional Cloud Network Engineer Professional Machine Learning Engineer Professional Security Operations Engineer 認定資格のメリット Google Cloud 認定資格を取得すると、以下のようなメリットがあります。もちろん一番は自身の知識・スキル向上ですが、その他にもたくさんの特典があります！ 学習の きっかけ になる 知識の 客観的 な証明になる Google Cloud Next などのイベントで 有資格者特典 が得られる Google の 限定グッズ が手に入る ルール・受験方法 言語・試験時間・料金 一部の試験は日本語では受験できません。全資格を制覇するには、一部の試験を英語で受験する必要があります。また受験料は $（USD）での支払いとなります。 ※ 受験料の記載は税別です 資格名 試験時間 受験料 言語 Cloud Digital Leader 90分 $99 日本語/英語/スペイン語/ポルトガル語/フランス語 Generative AI Leader 90分 $99 日本語/英語 Associate Cloud Engineer 2時間 $125 日本語/英語/スペイン語/ポルトガル語 Associate Google Workspace Administrator 2時間 $125 日本語/英語 Associate Data Practitioner 2時間 $125 日本語/英語 Professional Cloud Architect 2時間 $200 日本語/英語 Professional Cloud Database Engineer 2時間 $200 英語 Professional Cloud Developer 2時間 $200 日本語/英語 Professional Data Engineer 2時間 $200 日本語/英語 Professional Cloud DevOps Engineer 2時間 $200 日本語/英語 Professional Cloud Security Engineer 2時間 $200 日本語/英語 Professional Cloud Network Engineer 2時間 $200 日本語/英語 Professional Machine Learning Engineer 2時間 $200 日本語/英語 Professional Security Operations Engineer 2時間 $200 英語 受験場所 Google Cloud 認定資格は、テストセンターでの現地受験のほか、オンラインでの受験が可能です。 テストセンターでの現地受験の場合、日本全国に提携試験会場（テストセンター）があり、会場に設置されたパソコンを使って受験します。 福岡県近辺の方向けですが、テストセンターへの行き方についての記事も参考にしてください。 参考 : 「Google Cloud認定試験」福岡会場への行き方 - G-gen Tech Blog オンラインでの受験については、当社のメンバーによる記事も参考にしてください。 参考 : Google Cloud 認定資格オンライン受験の準備と注意点 - G-gen Tech Blog 参考 : 3ヶ月前までGoogle Cloud(旧GCP)の素人だった私がGoogle Cloudの試験を遠隔(オンライン)で受験する話 - G-gen Tech Blog 有効期限と再認定 Google Cloud 認定資格には、有効期限が設定されています。 Foundational レベルと Associate レベルの試験の有効期限は 3年間 、Professional レベルの試験の有効期限は 2年間 です。 Foundational レベルと Associate レベルの試験では、有効期限日の 180 日前以降に再度、試験に合格することで、資格を更新する（再認定される）ことができます。Professional レベルの試験では、60日前以降に再度合格する必要があります。 参考 : Google Cloud 認定資格試験のポリシーと試験の利用規約 また、Associate Cloud Engineer と Professional Cloud Architect のみ、 更新試験 が用意されています。更新試験は標準試験より問題数、受験費用、試験時間などが低く設定されており、小さい負担で資格を更新することができます。 資格取得の順番 Google Cloud 認定資格では「Aの資格を取得しないと、Bの資格を取得できない」といったような資格取得の順番指定はありません。いきなり Professional レベルの試験を受験しても構いません。 とはいえ、 Google Cloud の知識を順当に身につけていくためには、おすすめの順番があります。 エンジニアであれば、 Cloud Digital Leader もしくは Associate Cloud Engineer から始めるのが推奨されます。Cloud Digital Leader → Associate Cloud Engineer → Professional Cloud Architect → その他の Professional 試験、という順番で受験することで、順を追って Google Cloud 活用の知見が身につけられます。 一方、エンジニアとしてではなく、 経営目線やバックオフィス目線 で Google Cloud を捉える必要のある方は、 Cloud Digital Leader に挑戦 することが望ましいでしょう。 再試験 もしGoogle Cloud 認定試験に不合格となってしまったら、再試験ポリシーに則って再度受験することができます。 Cloud Digital Leader 試験は、1年間に10回まで受験できます。もし試験に不合格となった場合、再受験まで14日のインターバルを空ける必要があります。 Associate レベルと Professional レベルの試験には、以下のようにインターバルが設定されています。 受験回数 再受験までのインターバル 1回 2回目の再試験までに14日間のインターバルが必要 2回 3回目の再試験までに60日間のインターバルが必要 3回 4回目の再試験までに365日間のインターバルが必要 Associate レベルと Professional レベルの試験の場合、受験回数は2年間で最大4回まで、という制限があります。受験がオンサイトかオンラインかにかかわらず、受験回数にカウントされます。 参考 : 再受験ポリシー Google Cloud 認定資格の詳細 Foundational レベル Cloud Digital Leader Cloud Digital Leader 試験は、Google Cloud に関する最も基礎的な資格です。推奨の実務経験期間などはありません。 Google Cloud を理解するための最初のステップとして最適な資格であり、 エンジニアでない方も取得を目指せ ます。 以下の記事で、難易度や試験対策方法について詳細に解説していますので、ぜひご参照ください。 blog.g-gen.co.jp また、以下は G-gen 社のセールスメンバーが当試験を受験した体験記です。非エンジニアが当試験を勉強するためのヒントにしてください。 blog.g-gen.co.jp G-gen のエンジニアが執筆した書籍「合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題」は、Cloud Digital Leader 試験の参考書です。こちらも、参考にしてください。 合格対策 Google Cloud認定資格Cloud Digital Leader テキスト＆演習問題 作者: 杉村 勇馬 , 又吉 佑樹 リックテレコム Amazon Generative AI Leader Generative AI Leader 試験は、 生成 AI に関する基礎的な知識 や、 Google Cloud や Google Workspace の生成 AI 関連サービス・機能の知識 が問われます。非技術系のビジネスパーソンも対象としている試験です。当試験は、2025年5月14日（米国時間）に一般公開されました。 この試験取得に向けて、Google は無料のオンライントレーニングコースを提供しています。当試験の合格に向けて有用なほか、ビジネスにおける生成 AI 活用のために重要な知識を学ぶことができます。 試験対策方法については、以下の記事をご参照ください。 blog.g-gen.co.jp Associate レベル Associate Cloud Engineer Associate Cloud Engineer 試験では、Google Cloud の基礎スキルが評価されます。 クラウドエンジニアの出発点 となる資格です。 公式ガイドには「Google Cloud での構築経験 6 か月以上を推奨」と記載されていますが、必ずしもそれを満たしていなくてもチャレンジできる資格です。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp G-gen のエンジニアが、試験対策書籍である「合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 」を執筆しています。こちらも学習にあたりご参照ください。 合格対策 Google Cloud認定資格Associate Cloud Engineer テキスト＆演習問題 作者: 杉村 勇馬 , 佐々木 駿太 , 藤岡 里美 リックテレコム Amazon Associate Google Workspace Administrator Associate Google Workspace Administrator 試験は、Google Workspace の基礎的な管理業務に関するスキルが評価されます。企業の情報システム部員などにおすすめの資格です。2024年10月末に Beta 版として公開され、2025年1月に GA（一般公開）されました。 基本情報技術者試験レベルの IT 基礎知識（DNS、E メール基盤、特権管理など）に加えて、Google Workspace の管理画面に日常的に触れている方であれば、追加の学習を数日〜1ヶ月程度行うことで十分に合格を狙えます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Associate Data Practitioner Associate Data Practitioner 試験は、Google Cloud 上のデータの保護や管理のためのスキルが評価される試験です。データパイプラインの管理、分析、可視化、機械学習などのタスクを Google Cloud 上で行った経験が問われます。2024年10月末に Beta 版として公開され、2025年1月に GA（一般公開）されました。 Google Cloud 上でのデータ取り込み、変換、パイプライン管理、分析、機械学習、および可視化等に関する知識や技能が問われます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional レベル Professional Cloud Architect Professional Cloud Architect 試験は、Google Cloud や関連テクノロジーに関する、設計、実装、管理に必要な高度なスキルを保持していることを示す資格です。 IT インフラとアプリケーション開発に対する、バランスの取れた知識 が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Database Engineer Professional Cloud Database Engineer 試験は、Google Cloud における データベース系サービスの知見 を問う試験です。Professional Data Engineer 試験がデータエンジニアリングに関する知識を問う試験であるのに対し、当試験は運用データベースに関する知識を問います。 アプリケーションからのデータへのアクセスユースケースに応じて適切なデータベースサービスを選定・設計し、管理・トラブルシューティングなどを行うことができることを示す資格です。 Cloud SQL、Firestore、Bigtable、Spanner 等に関する知見が求められます。反対に BigQuery など分析系データベースに関する出題はありません。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Developer Professional Cloud Developer 試験は、Google 推奨の手法を理解して、スケーラブルで高可用な アプリケーションを開発 できるエンジニアであることを示す資格です。 クラウドネイティブなアプリ、開発者ツール、マネージドサービス、次世代データベースの使用経験が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Data Engineer Professional Data Engineer 試験は、データの収集、変換、可視化など、 データエンジニアリングに関する技能 を持つエンジニアであることを示す資格です。 データ処理システムの設計、構築、運用、セキュリティ保護、監視に加え、機械学習に関する問題も出題範囲です。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud DevOps Engineer Professional Cloud DevOps Engineer 試験は、Google Cloud でアプリ開発を行ったり、 CI/CD パイプラインを構築したり、サービス監視・インシデント管理など、 IT サービスを安定稼働 させるためにはどうすればよいかといった知見が求められます。 Google の提唱する SRE （サイト・リライアビリティ・エンジニアリング）がその根底にあります。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Security Engineer Professional Cloud Security Engineer 試験は、Google Cloud 上で安全なインフラを設計、実装するできるエンジニアであることを示す、 セキュリティに特化 した認定資格です。 ネットワークセキュリティ、アプリケーションセキュリティ、認証認可、監査証跡等に関する知識が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Cloud Network Engineer Professional Cloud Network Engineer 試験は、Google Cloud の ネットワークアーキテクチャに関する深い知見 が求められる資格です。 Google Cloud のネットワーク系サービス、コンテナ（GKE）に関するネットワークキング、ハイブリッドクラウド等に関する知見が求められます。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Machine Learning Engineer Professional Machine Learning Engineer 試験は、 Google Cloud の AI/ML 系サービス を活用して、ビジネス課題を解決するための機械学習モデルの設計、構築、利用を推進できる 機械学習エンジニア であることを示す資格です。 機械学習モデルのアーキテクチャ、データパイプラインの相互作用、およびメトリックの解釈に熟達している必要があります。 Google Cloud の試験ではありますが、Google Cloud の知識に加えて、機械学習に関する知見が深く求められる試験です。机上の理論だけでなく比較的実践的な知識も求められるため、難易度は高いものとなっています。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp Professional Security Operations Engineer Professional Security Operations Engineer 試験は、Google Cloud プロダクトを中心とした セキュリティオペレーション担当者向け の認定資格です。 攻撃の検知や防衛・対応に関する技術的な知識からインシデント管理の体制に関するものまで、包括的に問われます。 特に、Google Security Operations（略称 Google SecOps）と Security Command Center が中心となります。 試験対策方法は以下の記事をご参照ください。 blog.g-gen.co.jp 番外編 Professional ChromeOS Administrator Professional ChromeOS Administrator 試験は、Google の提供するコラボレーションツールである Google Workspace や ChromeOS デバイスの運用、管理に関する知識を問う試験です。 Google Cloud の公式ブログ で紹介されているものの、 Google Cloud 認定試験一覧 の公式ページには記載されておらず、Google 関連試験ではあるが Google Cloud 認定試験の扱いにはなっていません。 以下の記事で詳細に解説していますので、ご参照ください。 blog.g-gen.co.jp 廃止された試験 Looker LookML Developer Google の提供するデータプラットフォームツールである Looker における開発 (LookML) に関する知見 を問う認定資格です。 当試験は2022年4月1日をもって終了しました。参考までに、以下の記事で、どんな試験だったのかを確認することができます。 blog.g-gen.co.jp Looker Business Analyst Google の提供するデータプラットフォームツールである Looker のビジネスユースに関する知見 を問う認定資格です。 当試験は2021年12月31日で廃止となりました。 Professional Google Workspace Administrator Professional Google Workspace Administrator 試験は、 Google Workspace （旧称 GSuite） の導入や運用に関する知見 を求められる認定資格です。Active Directory と連携した認証・認可やシングルサインオンなど、企業 IT の周辺知識も求められます。 当試験は、2022年4月29日より以前は Professional Collaboration Engineer 試験 と呼称されていましたが、名称変更されました。また、2025年1月に後継の認定資格である Associate Google Workspace Administrator 試験が GA（一般公開）になり、当試験は廃止されました。参考までに、以下の記事で、試験の内容を確認することができます。 blog.g-gen.co.jp 荒井 雄基 (記事一覧) クラウドソリューション部 クラウドサポート課 オンプレ環境のネットワーク・サーバーシステムを主戦場としていたが、クラウド領域にシフト。現在は Google Workspace を中心に企業の DX 推進をサポート。 ・ Google Cloud Partner Top Engineer 2025 ・Google Cloud 認定資格 7冠 最近ハマっていることは、息子とのポケモンカード Follow @arapote_tweet

G-gen の杉村です。 BigQuery の Scheduled Query (スケジュールされたクエリ) で自動実行するクエリの、ジョブ失敗通知を行う方法について解説します。 はじめに 3つの方法 1. メール通知機能 2. Pub/Sub 3. ログベースの指標 ログベースの指標とアラートの作成手順 ログベースの指標とは 手順 1: ログベースの指標作成 手順 2: アラートの作成 メール通知の例と課題 Scheduled Query の限界 Cloud Monitoring と Cloud Logging はじめに Google Cloud (旧称 GCP) のデータウェアハウスサービスである BigQuery には Scheduled Query という機能が存在します。別名をスケジュールされたクエリ、あるいはクエリのスケジューリングと言います。この機能では定期的に BigQuery 上で SQL を実行することができ、この機能の利用自体に料金は発生しません (通常通りの BigQuery 料金のみが発生します)。 この機能では、前後関係や分岐のある複雑なジョブ管理はできないものの、日時を指定して定期的に SQL が実行できるため、簡易的な ELT 処理やデータマートテーブル作成などを行わせることができます。 しかしこの機能を使うに当たって課題となるのが、ジョブが失敗したときの通知です。当記事では、 Scheduled Query を使った際の失敗通知について解説します。 参考 : クエリのスケジューリング 3つの方法 1. メール通知機能 Scheduled Query には、ジョブが失敗した際にメールを送信する機能が備わっています。 デフォルトのメール通知機能 多くの方が、これを第一の選択肢として考えるはずです。 しかしながら、この機能は ジョブ作成者の Google アカウントのメールにしかメールが送信できない という仕様があります。 ドキュメントではワークアラウンドとしてメールを自動転送する方法が記載されていますが、これだとジョブ作成者のアカウントが退職等で削除されたときに通知ができなくなってしまいます。 メール通知 (このリンクは BigQuery Data Transfer Service のドキュメントですが、 Scheduled Query は同サービスの一部です) ジョブの失敗通知は、監視チームのメーリングリストであったり、インシデント管理ツールやチャットツールへの通知が必要になってくるでしょう。 そのようなニーズに、このデフォルト通知機能では答えることができません。 2. Pub/Sub もう一つの方法として、 Pub/Sub への通知が挙げられます。 前掲のスクリーンショットにあるように、ジョブの成功/失敗通知は Cloud Pub/Sub に通知することができます。 しかしながら Pub/Sub からメッセージを読み出すには、 Cloud SDK 等を用いる必要があり、基本的にはノーコードで実現できません。 Pub/Sub から Push 型で直接メール通知を発出する方法は 2022 年 1 月現在では存在しないため、例えば Pub/Sub トリガの Cloud Functions を作成してメール/チャットへ連携するなど、通知の仕組みを別途作成する必要があります。 Scheduled Query をそもそも、手軽にデータ変換を行うために利用しているのだとすれば、このような手間のかかる実装は選択肢としては選びづらいかもしれません。 その場合は次に挙げる代替案を検討します。 3. ログベースの指標 次の方法は、ログベースの指標とアラートを用いることです。 Scheduled Query (BigQuery Data Transfer Service) はジョブ実行の結果を Cloud Logging へ出力しています。 成功時・失敗時ともにログを出力します。エラー時のログは以下のようなものです。 Scheduled Queryのエラーログ このエラーログを検知して通知することが一つのワークアラウンドになりそうです。 この方法は簡単に実装できるため、以降当記事では、ログベースの指標とアラートを用いた通知の実装方法を紹介していきます。 ※なお特定ログを検知してアラートを発報する方法としては、今回ご紹介する「ログベースの指標 + アラート」よりもさらに簡単に実装できる ログベースのアラート 機能があります。こちらは執筆当時の 2021 年 12 月現在ではプレビュー機能だったため採用しませんでしたが、現在は GA されています。 ログベースのアラートを構成する ログベースの指標とアラートの作成手順 ログベースの指標とは ログベースの指標とは、 Cloud Logging に出力されたログにフィルタをかけて、その検出数を Cloud Monitoring の指標 (メトリクス) として利用する機能です。 今回は Cloud Logging に出力されたエラーログを、以下のようなフィルタで検知してみます。 resource.type="bigquery_dts_config" AND severity = "ERROR" 上記のフィルタは重要度が ERROR である Scheduled Query (BigQuery Data Transfer Service) ログを抽出するものです。 このフィルタを使ってログベースの指標を作成すると、 該当するログレコードの数を Cloud Monitoring に数値メトリクスとして送る ことができます。 そのメトリクスがしきい値を超えたときにアラートを発報するよう設定すれば、エラーログ出力を契機にメール通知や Slack 通知などを行うことができます。 ここからは、ログベースの指標と、それを元に通知を発報するアラートを Google Cloud コンソールで作成する手順をご紹介します。 手順 1: ログベースの指標作成 Google Cloud コンソールで ロギング > ログベースの指標 画面へ遷移します。 ボタン 指標を作成 を押下します。 指標を作成を押下 指標の設定値は以下のようにします。 指標タイプ: Counter ログ指標の名前: (任意) 説明: (任意) 単位: 空白 フィルタの作成: 以下の通り resource.type="bigquery_dts_config" AND severity = "ERROR" 指標の情報を入力 入力後、ボタン 指標の作成 を押下すると指標が作成されます。 以後は Cloud Monitoring の Metrics Explorer で、検出数をメトリクス (指標) として確認できます。 メトリクス名は logging/user/(指定した指標名) となります。 手順 2: アラートの作成 指標作成後に現れる以下の画面から「指標に基づくアラートを作成する」を押下します。 指標作成後の画面 この画面を閉じてしまっている場合は、 Google Cloud コンソールで Monitoring > アラート 画面へ遷移してボタン + CREATE POLICY を押下します。 次の画面で ADD CONDITION を押下し、 Target として logging/user/(指定した指標名) を指定します。 (指標作成後の画面から遷移した場合は、ここまでは自動で入力されます) アラート作成画面 Period として、メトリクスを集計する時間単位を指定します。 Configuration のブロックで、発報の条件を指定します。 Configurationブロック 例えば Period が 10 minutes で Aggregator が Sum 、 Configuration にて is above 10 for most recent value のように設定した場合、 10 分間で検知されたログ数の合計が 10 を超えた場合に発報がトリガーされます。 is above 0 としておけば、 1 個でもエラーが出れば発報されるようになります。 ボタン ADD を押下してしきい値設定画面を閉じたら 次へ を押下して、通知先設定へ遷移します。 通知先設定 通知先は Cloud Monitoring の Notification Channel という設定値として管理することができます。 メールや Slack の他、 Webhook で外部 API を呼び出したり、 Pub/Sub へメッセージを Publish することもできます。 Notification Channel を事前に作っていない場合、この画面で新規作成が可能です。 なおアラートが発生すると Cloud Monitoring 内で「インシデント」が起票されますが、インシデントの自動クローズ期限などもここで設定できます。 ボタン NEXT を押下して、最後にアラート名を設定し、ボタン SAVE を押下します。 アラート名の設定 ここまで設定すると、しきい値を超えた際に Notification Channel へ通知が行われます。 メール通知の例と課題 通知先をメールとした場合、以下のようなメールが届きます。 メールの例 課題として、メール本文からは 「どのジョブがコケたか」「どのようにコケたか」は分からない 点があります。 その代わりメール内の VIEW LOGS ボタンを押下して Google Cloud コンソールへログインして該当するログを閲覧すれば、エラー本文や該当する Scheduled Query ジョブの ID が確認できます。 しかしこれでは、 Google Cloud コンソールへログインする権限を持たないメンバーがメールを受け取る場合、対処が取れません。 メール本文からどのジョブがこけたかを把握するには、例えばフィルタを以下のようにして、ジョブごとにログベース指標とアラートを作成する方法が挙げられます。 resource.type="bigquery_dts_config" AND severity = "ERROR" AND resource.labels.config_id="xxxxxxxx-0000-0xxx-0000-xxxxxxxxxxxx" resource.labels.config_id として指定している xxxxxxxx-0000-0xxx-0000-xxxxxxxxxxxx の部分は、各 Scheduled Query の詳細画面の 構成 タブで確認できる「リソース名」の末尾部分の英数字です。 config_id こうしてジョブごとにログベース指標とアラートを作成すれば、メール本文にはアラート名や指標名が記載されるため、メール本文から「どのジョブがコケたか」までは把握することができます。 ただし、依然として「どのようにコケたか」までは分からないうえ、ジョブ数 (Scheduled Query 数) が多くなると、ジョブごとに指標とアラートを作成しなければならず、現実的ではありません。 メールによる通知はあくまで簡易的な通知に留め 、実際の対処はコンソールにログインしてログを確認する、というオペレーションが現実的でしょう。 Scheduled Query の限界 Scheduled Query では、前述の通知の課題に加えて、前後関係や分岐のあるジョブネットを組むことに限界があります。 ジョブ失敗時のリトライ処理なども、うまく管理することが難しいでしょう。 一定以上複雑なジョブの場合は Scheduled Query だけでジョブを構成することを諦めて、 ワークフロー管理ツールを導入することを検討 しましょう。 3rd party 製品の検討はもちろん、 Google Cloud サービスであれば Cloud Composer などが該当します。 また Cloud Data Fusion や Dataprep といったツールも検討対象です。 Cloud Monitoring と Cloud Logging 当記事でご紹介した Cloud Logging の使い方や、 Cloud Monitoring の指標やアラートの概念については以下の記事で紹介していますので、ご参考にお願いいたします。 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の渡邉@norryです。 皆さんコラボレーションツールのGoogle Workspaceは利用されていますか？ 今現在企業で利用されているGoogle WorkspaceのエディションとしてはGoogle Workspace BusinessやEnterpriseエディションを利用されている方も多いのでは無いかと思います。 全社でGmailを全員利用したいけど、現場スタッフ全員にライセンスを割り当てるには料金が...利用する端末どうしよう...どうやって契約すればいいの...などといった事はありませんか？ そういった方に向けてGoogle Workspace Frontline のご紹介になります。 Google Workspaceとは？ Frontlineエディションについて Frontlineエディションとは 現場スタッフの定義 利用可能なサービス 仕様についての注意点 契約に際しての注意点 ユースケース審査 エディション混在のみで利用可能 契約期間と支払い 申込み方法 最後に Google Workspaceとは？ Google Workspaceの 公式サイト には「あらゆる働き方に対応する生産性向上とコラボレーションのツール。」とあり、また従業員の生産性＝チームx会社の文化＝コミュニケーション＋コラボレーションと言い換える事が出来ます。 その組織のコミュニケーションとコラボレーションを下支えし促進するツールがGoogle Workspaceとなります。 Google Workspace には費用の異なる複数のエディションが存在します。詳しくはこちらの記事を参照ください。 blog.g-gen.co.jp Frontlineエディションについて Frontlineエディションとは Google Workspace の Frontline エディションとは、 第一線で活躍する現場スタッフ向け のエディションです。 統制が取れた上でと表現したのは、現場スタッフは業務を遂行する上で知りたい情報を得るのに自分たちの個人デバイスやアプリを使うほかない状況が推測されるからです。 そういった状況はシャドーITとも繋がり企業にとっては望ましくない状況でしょう、きちんと管理下に置いた上で適切な情報を素早く得られる状態が望ましいはずです。 現場スタッフの定義 Google Workspace Frontlineを利用可能な現場スタッフの定義は以下になります。 不特定多数の人に直接対応して、サービスやサポート、商品販売を行う 製品やサービスの製造、配送に直接携わる 戦力の大部分を構成し、業務遂行にはスピードと共同作業が重要である 該当する具体的な現場スタッフの例: 製造業の組み立て作業員 レストラン、接客業、小売業のスタッフ 農業、漁業、林業の従事者 建設作業員 主に屋外で作業するスタッフ コールセンターや交通機関のオペレーター 利用可能なサービス 価格や利用人数の制限などは下記のようになっています。 Frontline Business Starter Business Standard Business Plus 基本情報 月額料金（1ユーザーあたり※税別） 520円 680円 1,360円 2,040円 利用可能人数 無制限 1〜300名 1〜300名 1〜300名 ストレージ容量 2G 30GB 2TB 5TB 24時間365日の電話サポート ✔ ✔ ✔ ✔ 利用可能なコアサービスは下記の通りです。 Frontline Business Starter Business Standard Business Plus コアサービス Gmailとカレンダー ✔ ✔ ✔ ✔ ビジネス向け Google グループ ✔ ✔ ✔ ✔ ChatとChatスペース ✔ ✔ ✔ ✔ ドライブ ストレージとドキュメント エディタ ✔ ✔ ✔ ✔ Meet によるビデオ会議 ✔ ✔ ✔ ✔ ディレクトリ管理 ✔ ✔ ✔ ✔ Cloud Searchによるドメイン内検索 ✔ ✔ Google Vault ✔* ✔ 基本的な機能はほぼ利用出来ると言って良いでしょう、また上記に加えてFrontlineではデバイス管理において「基本のエンドポイント管理」「高度なエンドポイント管理」が利用可能となっており、現場スタッフが利用するにあたって企業のガバナンスを効かせる事が可能です。 ※ Vault は Frontline では有料アドオンとしてご利用いただけます。 仕様についての注意点 「共有ドライブ」の作成機能は無いが、すでに作成されている共有ドライブに参加する事は可能 Frontline ユーザーは「共有ドライブ」のフォルダは 「閲覧」 しかできない ただしファイル単位で権限を付与すれば編集可能（フォルダ単位・ドライブ単位では編集権限を付与できない。 参考 ） 1ユーザーあたりのメール、ドキュメント、写真の保存容量を含めて2GBとなっている Cloud Searchを使った横断的な検索ができない と言った事が上げられます。特に「共有ドライブ」のドライブのルートやフォルダには 閲覧権限 しか与えられない事に注意してください (ファイル単位で編集権限を付与することはできます) 。この事からも現場スタッフに特化したプランと言えます。 契約に際しての注意点 ユースケース審査 その特性上、Frontlineを契約する場合には Google 社の要件に沿っているか？ が Google によって審査されます。 Google Cloud 社と直接契約の場合には Google Cloud 社が直接審査を実施します。 パートナー経由で利用している場合にはパートナーが Google Cloud 社と協議いたします。 Frontline のユースケースに合致していると判断された場合のみ、契約が可能となります。 エディション混在のみで利用可能 Frontline エディション 単体での契約は不可 であり Frontline + 別エディション のように混在した形でのみ契約が可能です。 例えば Business Standard + Frontline などです。 ただし Frontline 以外のプランに関しては、例えば Business StandardとBusiness Starter 等のように複数のエディションやプランを混在させて契約する事は 出来ません のでご注意ください。 契約期間と支払い Frontline を契約するにあたって、契約期間と支払いは以下の通りです。 混在して契約する Frontline 以外のエディションもあわせて以下になりますのでご注意ください。 ライセンス数を定めた年間契約 (12ヶ月間) 契約締結翌月の月初に請求書発行・翌月末に 12 ヶ月分をまとめて支払 年途中でユーザーを追加する場合は、残月分を前払い 現在の契約次第では手続きに 2〜3 週間かかる場合がある 申込み方法 上記の注意点を見ても分かります通り、現在の環境や契約形態によって検討する部分が多い為、弊社株式会社G-genにお気軽にご相談ください。 docs.google.com 最後に Frontlineを上手く組み合わせる事で全社一丸となった働き方変革、コミュニケーション、コラボレーションの促進にお役立ち出来る事かと思います。 弊社株式会社G-genではGoogle Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 また Google Workspace / Google Cloud (GCP) を5%割引でご提供しております。 既に Google Cloud をご利用中の方も、新規にご利用開始を検討されている方も、お気軽にご連絡ください。 g-gen.co.jp 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

G-genの渡邉@norryです。当記事では、現場スタッフにリーズナブルな価格で Google Workspace ライセンスを割り当てるための Google Workspace Frontline エディションを紹介します。 概要 Frontline エディションとは 現場スタッフの定義と審査 仕様 利用可能な機能 機能の制限 人数や容量の上限 Starter、Standard、Plus の比較 注意点 主な機能制限 エディション混在のみで利用可能 契約期間と支払い 購入にあたり 概要 Frontline エディションとは Google Workspace の Frontline エディション とは、第一線で活躍する 現場スタッフ向けのエディション です。なお Frontline（フロントライン）とは、「前線」を意味する英単語です。 Frontline エディションは、他のエディションと比較して機能制限はあるものの、比較的安価にライセンスを購入することができます。 Frontline エディションには Frontline Starter 、 Frontline Standard 、 Frontline Plus の3種類が存在します。上位エディションになるほど、セキュリティ管理機能が強化されます。 参考 : Frontline エディション 現場スタッフの定義と審査 Frontline エディションを利用可能な「現場スタッフ」の定義は、以下のとおりです。 不特定多数の人に直接対応して、サービスやサポート、商品販売を行う 製品やサービスの製造、配送に直接携わる 戦力の大部分を構成し、業務遂行にはスピードと共同作業が重要である 具体的には、以下のような従業員が該当します。 製造業の組み立て作業員 レストラン、接客業、小売業のスタッフ 農業、漁業、林業の従事者 建設作業員 主に屋外で作業するスタッフ コールセンターや交通機関のオペレーター Frontline エディションのライセンスを購入するには、利用する従業員が上記の要件に沿っているか、 Google によって審査 が行われます。 Google Cloud と直接契約をする場合には、Google Cloud 社が直接、審査を実施します。G-gen のような販売パートナー経由で契約する場合、パートナーが Google Cloud 社と協議することが可能です。 Frontline のユースケースに合致していると判断され、審査をクリアした場合のみ、購入が可能となります。 仕様 利用可能な機能 Frontline エディションでは、以下のような機能が利用可能です。Business エディション以上で使える Google Workspace のほとんどの機能が、Frontline エディションでも利用できることがわかります。 Gmail とカレンダー ビジネス向け Google グループ Chat とチャットルーム ドライブ ストレージとドキュメント エディタ（Google ドキュメント、スプレッドシート、スライド、フォーム、サイトを含む） Meet によるビデオ会議 ディレクトリ管理 サイト その他の Google サービス Colab: データ サイエンスと機械学習モデルを共同で開発できます（その他の Google サービスとして、ユーザー ライセンスは不要）。 Colab Pro と Colab Pro+（アドオン） エンタープライズ級のデータ保護を備えた Gemini アプリ AppSheet Core NotebookLM Cloud Search（Frontline Plus のみ） AppSheet Core 上記は、一部抜粋です。利用可能な機能の一覧や詳細は、以下の公式ドキュメントを参照してください。 参考 : Frontline エディションの比較 機能の制限 Frontline エディションでは、Business 以上のエディションと比較して、以下のような機能制限があります。 Google ドライブの共有ドライブには、 閲覧者権限 しか付与できない（ファイルに直接権限を付与する場合は、編集も可能） Google Vids は視聴のみ（編集ができない） Gemini ウェブアプリは利用可能だが、Gemini Advanced ではない（高度な機能が利用できない） 人数や容量の上限 Google Workspace の各エディションには、ライセンス数の上限や、ストレージ容量に上限が設けられています。以下の表では、3種類の Frontline エディションと、比較のために Business Starter および Plus エディションの上限を記載しています。 エディション ユーザー数 ストレージ容量 Frontline Starter 無制限 5 GB/ユーザー Frontline Standard 無制限 5 GB/ユーザー Frontline Plus 無制限 5 GB/ユーザー Business Starter 300 30 GB/ユーザー Business Standard 300 2 TB/ユーザー Business Plus 300 5 TB/ユーザー Starter、Standard、Plus の比較 Frontline Starter では、デバイス管理において「基本のエンドポイント管理」「高度なエンドポイント管理」が利用できます。一方、Frontline Standard や Plus では、「 エンタープライズエンドポイント管理 」が利用可能となっており、現場スタッフが利用するにあたって、より高度な統制とセキュリティを発揮する事が可能です。 最上位の Plus エディションでは、高度なデータエクスポートや、クライアントサイト暗号化、データリージョンの指定、監査情報の BigQuery へのエクスポート、ログイベントの Google SecOps へのエクスポートなど、より高度なセキュリティ機能が利用できます。 詳細な一覧は、以下のドキュメントを参照してください。 参考 : Frontline エディションの比較 注意点 主な機能制限 Frontline エディションでは、以下の制限に特に注意が必要です。 「共有ドライブ」の作成機能は無いが、すでに作成されている共有ドライブに参加する事は可能 Frontline ユーザーは組織内の共有ドライブに、 閲覧者 権限のみを付与可能 フォルダ単位・ドライブ単位では編集者権限を付与できない ただしファイル単位では、編集者権限を付与できる 参考 : 共有ドライブを作成する 組織外の共有ドライブのメンバーとして追加される場合は、 管理者 などの任意のアクセスレベルを付与できる 参考 : 組織の共有ドライブを設定する 1ユーザーあたりのメール、ドキュメント、写真の保存容量は 5 GB 特に、組織内の共有ドライブには閲覧権限しか付与できない点には注意が必要です。Frontline エディションは、あくまで現場スタッフに特化したライセンスのため、ドライブ上のファイルの主要な管理者としては想定されていないと考えられます。 エディション混在のみで利用可能 Frontline エディションは、単体での契約は不可であり、 Business 以上の別のエディションとの組み合わせる 形でのみ、購入が可能です。例えば、 Business Standard + Frontline Starter のように、エディションを混在させる場合で購入ができます。 ただし、Frontline 以外のプランに関しては、例えば Business Standard + Business Starter のように、複数のエディションやプランを混在させて契約する事はできない点に注意してください。 契約期間と支払い Frontline を契約するにあたって、契約期間と支払いは以下のとおりです。混在して契約する Frontline 以外のエディションも、あわせて以下が適用されますのでご注意ください。 ライセンス数を定めた年間契約（12ヶ月間） 契約締結翌月の月初に請求書発行・翌月末に 12 ヶ月分をまとめて支払 年途中でユーザーを追加する場合は、残月分を前払い 現在の契約次第では手続きに 2〜3 週間かかる場合がある なお、この情報は G-gen 社の過去実績に基づいています。最新情報は、Google Cloud 社や販売パートナーにご確認ください。 購入にあたり 上記の注意点を見てもわかるとおり、現在の環境や契約形態によって考慮すべき要素が多いため、Frontline エディションの購入は、経験ある販売パートナーに相談することが推奨されます。 当記事を執筆した株式会社 G-gen のお問い合わせフォームより、お気軽にご相談ください。 参考 : ご相談・お問い合わせフォーム - 株式会社G-gen G-gen では Google Workspace や Google Cloud（旧称 GCP）を割引価格で提供しています。既に Google Cloud や Google Workspace をご利用中の方も、新規に利用開始を検討している方も、お気軽にご連絡ください。 参考 : Google Cloud 請求代行 - 株式会社G-gen 渡邉 宣之 (記事一覧) クラウドソリューション部 AI/ML、アプリケーションモダナイゼーション、データ分析基盤の構築、クラウド管理運用やネットワークなどインフラ系は何でも、Google Workspace 活用も推進中 週末フォトグラファーで、観葉植物や塊根植物にハマっていて種から育ててます。

Google が提供するゼロトラスト・ソリューションである Chrome Enterprise Premium （旧称 BeyondCorp Enterprise）を紹介します。 Chrome Enterprise Premium の概要 Chrome Enterprise Premium とは 実現できること ゼロトラストセキュリティとは 構成要素 運用 ID（ユーザーアカウント） 外部 ID 連携 監査ログ 料金 Chrome Enterprise Premium の料金 その他の課金 無料範囲 技術的な詳細 01. Identity-Aware Proxy（IAP） Identity-Aware Proxy（IAP） とは 他のプラットフォームへの中継 02. Identity and Access Management（IAM） 03. Access Context Manager Access Context Manager とは [A] IP アドレスレンジ [B] 地域 [C] プリンシパル（主体） [D] デバイスポリシー 04. Endpoint Verification その他の機能 Threat and Data Protection Cloud Console / Google Cloud API へのアクセス制御 Chrome Enterprise Premium の概要 Chrome Enterprise Premium とは Chrome Enterprise Premium （旧称 BeyondCorp Enterprise）は、エージェントレス・VPN レスで社内 IT サービスへのアクセスを実現する、 Google のゼロトラスト・セキュリティサービスです。Chrome ブラウザの利用を前提としており、特に Google Workspace や Chromebook を社内 IT の中心に置いている組織にとって、有効なセキュリティソリューションといえます。 Chrome Enterprise Premium を用いると、インターネット VPN を使うことなく、インターネット経由で安全に社内システムや SaaS などへアクセスすることができます。また、データ損失防止（DLP）機能やフィッシング対策など、多くのセキュリティ機能を具備しています。 重要なキーワードとして、 コンテキストアウェア アクセス があります。例として「会社承認のデバイスであること」「会社の Google アカウントでログインしていること」という条件を満たしていれば社内の顧客情報システムへのアクセスを許可する、といった設定が可能です。なおかつ、 IT 管理者は VPN ルーターやゲートウェイ（プロキシ）の管理をする必要がありません。 なお旧称である BeyondCorp Enterprise の BeyondCorp は、後述のゼロトラストセキュリティを実現するために Google が開発した実装モデルを指しています。BeyondCorp を一般の組織向けに販売するプロダクトが Chrome Enterprise Premium です。 参考 : Chrome Enterprise Premium 参考 : Chrome Enterprise Premium overview 実現できること Chrome Enterprise Premium では、以下のようなことが実現できます。 VPN なしで Google Cloud 他のプラットフォーム上の Web アプリケーションにアクセスできるようにする 社内システムにアクセスできる端末を、社用端末だけに制限する モバイル デバイスから社内データにアクセスできるようにする 従業員が機密データをコピーして持ち出せないようにする Chrome Enterprise Premium を利用すると、以下のような情報をもとにしたアクセス制御が可能になります。 接続元 IP アドレス デバイス情報 Google アカウントや Google グループ サポートされているサードパーティ製品（CrowdStrike 等）からの情報 ゼロトラストセキュリティとは 前述のようにユーザーのリクエストのコンテキスト（デバイス状態、アクセス状況等、 ID とパスワードだけに頼らない各種背景情報）を判断に使ってアクセス制御を行う方式は ゼロトラストセキュリティ と呼ばれます。Google 社では実際に、BeyondCorp の仕組みを社内で利用し、 VPN レスなゼロトラストセキュリティを実現しているといわれています。 ゼロトラストセキュリティは、従来型の「社内と社外を境界線のファイアウォールや UTM で区切る」「社内ネットワークからのアクセスであれば安全とみなして、全て許可する」という 境界型ネットワーク とは、考え方が異なります。 境界型セキュリティ vs ゼロトラスト 2010 年代以降に一般的になった標的型攻撃等により、社内ネットワークにマルウェアが入り込んだり、あるいは侵入者にひとたび社内ネットワークに入り込まれると、境界型セキュリティは意味をなしません。これが、近年ゼロトラスト・セキュリティが注目されている理由です。 Chrome Enterprise Premium は Google が自社で実現したゼロトラストをサービス化したものであり、多数の実績のあるソリューションだといえます。 構成要素 Chrome Enterprise Premium は次の 4 つのコンポーネントで構成されます。 No 名称 概要 説明 01 Identity-Aware Proxy（IAP） マネージドのリバースプロキシ 社内サーバなどへの接続を中継してくれる Google Cloud 上の仕組み 02 Identity and Access Management（IAM） Google Cloud の権限管理機構 Google アカウントと権限を紐づける仕組み 03 Access Context Manager ルールエンジン デバイス情報、アカウント情報、接続状況など各種背景情報からアクセス可否を判断する仕組み 04 Endpoint Verification エンドポイント エージェント ユーザーのデバイス情報を収集する Google Chrome 拡張機能 各コンポーネントの機能を図で表すと、以下のようになります。 各コンポーネントの機能 この図では IAP が単一障害点（SPOF）に見えてしまうかもしれませんが、IAP は Google の高度にスケーラブルなインフラで稼働しているため、物理的には単一障害点にはならず、高い可用性を持っています。IAP の物理的な構成要素の一つである Cloud Load Balancing は月単位で 99.99% の SLA が定義されています。 参考 : Compute Engine Service Level Agreement (SLA) また、その他の機能として Threat and Data Protection があります。Threat and Data Protection は、Chrome ブラウザの追加機能として提供され、マルウェアやソーシャルエンジニアリングなどのウェブ上の脅威に対する保護や、Data Loss Prevention（DLP）ルール、セキュリティアラート、レポートツールを提供します。 運用 ID（ユーザーアカウント） 認証に用いられる ID（ユーザーアカウント）は、原則 Google アカウントです。 Google アカウントは Google Workspace または Cloud Identity で管理されます。1人の個人に対して、1つの Google アカウントが発行されます。詳細は、以下の記事も参照してください。 blog.g-gen.co.jp 外部 ID 連携 外部 ID 連携 を用いることで、以下のような外部 ID を Google アカウントと連携して認証することもできます。 メールアドレスとパスワード OAuth（Facebook、X、GitHub、Microsoft など） SAML OIDC 電話番号 カスタム 匿名 参考 : External identities 監査ログ デフォルトでは、アクセスポリシー違反をしたログは、全て Cloud Audit Logs により記録されます。 追加の手順を実行することで、違反ログだけでなく、すべてのリクエストを詳細にログに出力することも可能です。 参考 : Identity-Aware Proxy audit logging ログは、Cloud Logging の Log Explorer を使うことなどによって閲覧できます。ログを Cloud Logging から BigQuery へエクスポートすることで、より深い分析も可能です。Cloud Audit Logs や Cloud Logging の詳細については、以下の記事をご確認ください。 blog.g-gen.co.jp blog.g-gen.co.jp 料金 Chrome Enterprise Premium の料金 Chrome Enterprise Premium の料金は、1ユーザーあたり月額 $6 です。 Chrome Enterprise Premium の購入は、Web コンソール等からは行うことはできません。Google もしくは販売パートナーの担当営業へお問い合わせください。その際に利用人数を申請しますが、その申請アカウント数ベースで課金が行われます。 参考 : Chrome Enterprise Premium その他の課金 利用人数ベースの課金のほか、Chrome Enterprise Premium の使用に伴いデプロイされた Cloud Load Balancing などに料金が発生します。 また ID 管理のための Google Workspace や Cloud Identity（Premium の場合）のアカウント料金も、別途発生することに注意が必要です。 無料範囲 Google Cloud では Cloud IAP が無料で利用できます。 Chrome Enterprise Premium を購入しなくとも、Cloud IAP を活用することで、Google Cloud 上で稼働する Web アプリケーションへのアクセス制御や、踏み台サーバ無しでの VM へのログインなどが実現できます。以下の記事も参照してください。 blog.g-gen.co.jp 技術的な詳細 ここまでは、Chrome Enterprise Premium の基本的な概念を解説しました。ここからは技術的な観点で、 Chrome Enterprise Premium の構成要素を解説します。 01. Identity-Aware Proxy（IAP） Identity-Aware Proxy（IAP） とは Identity-Aware Proxy（IAP） は、 フルマネージドのリバースプロキシ です。簡単に言うと、社内システムへの接続を中継してくれる、 Google Cloud 上の仕組みです。 「フルマネージド」というのは、 この仕組みが Google の管理するインフラの上で動いているため、 インフラ管理・運用をする必要がない ということを意味しています。 IAP が中継するのは基本的には HTTP（S）トラフィックですので、 Web アプリケーションが利用対象となります。IAP が中継を許可するかどうかは、後述の IAM や Access Context Manager で定義したルールに基づいて判断されます。つまりインターネットから社内システムへアクセスする際、ユーザー情報やデバイス情報に基づいてアクセス可否が判断されるため、社内システムを安全に利用することができます。 この仕組みにより、インターネット VPN に頼らない、セキュアなアクセスを構築できます。 参考 : Securing resources with IAP 他のプラットフォームへの中継 Cloud IAP は、Google Cloud 上に Google Compute Engine（GCE）や Google Kubernetes Engine（GKE）で構築された Web アプリケーションに加え、Amazon Web Services（AWS）や Microsoft Azure、オンプレミスなど、他のプラットフォーム上で稼働する Web アプリケーションにも対応しています。 参考: Securing resources with IAP 参考: オンプレミス アプリの IAP の概要 他のプラットフォーム上の Web アプリを中継する場合、 コネクタ をデプロイする必要があります。コネクタの実体は、Cloud Load Balancing の外部アプリケーションロードバランサーと、Google Kubernetes Engine（GKE）でホストされたアプリケーションです。 IAP経由でオンプレミスアプリへアクセスする コネクタから Web アプリケーションへの通信は、HTTPS などの暗号化プロトコルであればインターネット経由でもリスクは低いといえます。 HTTP などの非暗号化プロトコルの場合は、Google Cloud の VPC とオンプレミス環境が Cloud Interconnect（専用線）やインターネット VPN で接続されているべきです。 02. Identity and Access Management（IAM） Identity and Access Management は略称を IAM といい、Google Cloud の認証・認可の管理機構です。特にクラウドサービスでは一般的な用語です。 参考: Applying IAM conditions IAM は「 誰 （プリンシパル、主体）が、どういった 条件 （コンディション）のもとで、 何に対して （対象リソース）、 何をできる （ロール、権限）か」というルールセットを管理します。 Google Cloud の IAM の特徴として「誰（プリンシパル、主体）が」「どういう条件（コンディション）のもとで」「何をできる（ロール、権限）」という情報を、 操作対象のリソースに設定する 形になっている点が挙げられます。この紐付けを バインディング（binding） と呼びます。バインディングは IAM policy と呼ばれる、各リソースの属性として保持されます。 Chrome Enterprise Premium では、アクセス制御対象の Web アプリケーションに対して Cloud IAP 上で IAM policy を設定し、「誰（プリンシパル、主体）が」「どういう条件（コンディション）のもとで」「何をできる（ロール、権限）= どのサービスに対して接続できる」という細かいアクセス制御が実現可能です。 Google Cloud の IAM の仕組みについては、以下の記事で詳細に紹介しています。さらに深堀りして理解したい方はご参照ください。 blog.g-gen.co.jp 03. Access Context Manager Access Context Manager とは Access Context Manager は、デバイス情報、アカウント情報、接続状況など、リクエストの背景情報からアクセス可否を判断する仕組みです。 参考 : Limiting access Access Context Manager は IAM とセットで使われます。 IAM の「条件（コンディション）」として Access Context Manager が使われるイメージです。 個々の条件設定オブジェクトを アクセスレベル と呼びます。アクセスレベルでは、以下の要素を条件として利用できます。 [A] IP アドレスレンジ [B] 地域 [C] プリンシパル (主体) [D] デバイスポリシー 参考 : Access level attributes [A] IP アドレスレンジ 許可する接続元 IP アドレスを、CIDR 形式（ x.x.x.x/x ）で指定できます。 IPv4 と IPv6 の両方に対応しており、パブリック IP のみを指定できます。 [B] 地域 アクセス元 IP アドレスから地理情報が判断され、指定した地域からのアクセスのみが許可されます。 条件に複数地域を指定すると、OR で判定されます。 なおパブリック IP アドレスから判定されるため、地域を条件に指定すると、Private Google Access（限定公開の Google アクセス）等を使ったプライベート IP アドレスからのアクセスは拒否されます。 [C] プリンシパル（主体） アクセスに使われるプリンシパル（Google アカウントやサービスアカウント）です。 そもそも IAM policy は Google アカウントや Google グループ、サービスアカウントと紐付けられて作成されるので、条件の中でプリンシパルを指定することは限定的かもしれません。同じグループに紐付いている IAM policy で、プリンシパルによって条件を少し変えたい、というときに利用します。 [例] Google グループ ops-grp@example.com に対して、システム A への IAP アクセスを許可する IAM policy がある その IAM policy の条件として以下を設定 tom@example.com は 9:00-18:00 の時間帯でアクセスを許可 mary@example.com は 18:00-09:00 の時間帯でアクセスを許可 [D] デバイスポリシー 後述の Endpoint Verification で取得されたデバイスポリシーと合致しているかどうかを条件として設定できます。これにより、会社指定の端末以外がサービスに接続することを防いだり、セキュアでない設定の端末が、Web サービスに接続することを防ぐ事ができます。 以下の要素を条件としてチェックできます。 スクリーンロックの強制 ストレージ暗号化 デバイスが管理者に承認されていること 会社指定のデバイスであること 会社指定の OS であること 04. Endpoint Verification Endpoint Verification （エンドポイント・ベリフィケーション）は Chrome ブラウザの拡張機能（Chrome Extention）を使い、ユーザー情報や端末の情報を収集します。 つまり各 PC の Chrome ブラウザに拡張機能をインストールする必要があります。Google Workspace を利用している場合は Endpoint Verification Chrome extension を管理コンソールから一斉配布・自動展開が可能です。 参考 : Endpoint Verification overview 参考 : Gathering device information その他の機能 Threat and Data Protection 前述の主要な4つの構成要素に加えて、 Threat and Data Protection 機能を利用できます。 これは Chrome ブラウザの追加機能として提供され、マルウェアやソーシャルエンジニアリングなどのウェブ上の脅威に対する保護や、 Data Loss Prevention（DLP、データ損失防止）ルール 、 セキュリティアラート 、 レポートツール を利用できるようになります。 DLP 機能 では、 Chrome 上で機密データの共有に関して警告を出したりブロックしたりします。 ファイルのアップロード・ダウンロードや、コピー&ペーストの中に、クレジットカード番号や大量のメールアドレスが含まれている場合などに当機能が働き、ブロックやアラート発報などを行うことができます。ただしこの機能は Windows、Mac、Linux、Chrome OS の Chrome ブラウザでのみ機能する ことに注意が必要です。 また、 監査ログ 、 セキュリティ ダッシュボード 、 レポーティング 機能も充実しています。 「Chrome の脅威対策に関する概要」「Chrome のデータ保護に関する概要」「リスクの高い Chrome ユーザー」「リスクの高い Chrome ドメイン」などのレポートを表示することができ、マルウェアの転送、危険なサイトへのアクセス、パスワードの再利用、機微なデータの転送などのアクティビティを可視化できます。 従業員の活動を Chrome ブラウザに集約・制限したうえで Threat and Data Protection をうまく活用することで、情報漏洩のリスクを下げる事が可能です。 参考 : Chrome Enterprise Premium で Chrome ユーザーを保護する Cloud Console / Google Cloud API へのアクセス制御 Google Cloud の Web コンソールや、gcloud コマンドライン、SDK を使った Google Cloud API へのアクセス制御を行うことができます。 この機能を使って、Google Cloud 環境の運用者や開発者に対し、接続元 IP アドレスやデバイスポリシーに基づいたアクセス制御をかけることができます。 アクセスレベルの定義に違反する運用者は、コンソール画面にアクセスできないほか、CLI や SDK を使った環境操作もできなくなります。 blog.g-gen.co.jp 参考 : Secure the Google Cloud console and the Google Cloud APIs 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。 Google は The Google Cloud Adoption Framework というフレームワーク (考え方や施策の枠組み) を公表しています。 このフレームワークでは、組織がクラウドを導入するときにどのように考え、施策に取り組むべきかについての指針を示しています。 技術的な視点にとどまらず、 組織づくりや経営層の関わり方も含めた、包括的なフレームワーク となっています。 以下のページから無料でホワイトペーパーを閲覧することができます。 cloud.google.com ただし、ドキュメントは残念ながら英語でしか公開されていません。 当記事では The Google Cloud Adoption Framework を抄訳 (逐語訳ではなく要約しつつ翻訳) し、紹介したいと思います。 当記事の内容は、図を含め、前述の The Google Cloud Adoption Framework ホワイトペーパーから抜粋・翻訳したものとなりますが、一部に翻訳者 (杉村) の解釈や解説を含むことをご了承ください。 また (※) で挿入された注釈は翻訳者によるものです。 第一部: エグゼクティブ・サマリー 1-1. 四つのテーマ、三つのフェイズ 1-2. クラウド成熟度 1-3. エピック 1-4. The Google Cloud Adoption Framework とは 1-5. はじめかた 1-5-1. クラウド成熟度の測定 1-5-2. ゴールを決める 1-5-3. クラウド導入プログラムを計画する 1-5-4. ちょうどよいワークロードを見つける 第二部: テクニカル・ディープダイブ 2-1. クラウド成熟度の各段階について 2-1-1. Tactical (戦術) 段階 2-1-2. Strategic (戦略) 段階 2-1-3. Transformational (柔軟) 段階 2-2. 各テーマごとのクラウド成熟度 2-2-1. Learn (学習) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-2-2. Lead (リード) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-2-3. Scale (スケール) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-2-4. Secure (セキュア) Tactical (戦術段階) Strategic (戦略段階) Transformational (柔軟段階) 2-3. エピック 2-3-1. アクセス管理 2-3-2. アーキテクチャ 2-3-3. 振る舞い 2-3-4. CI/CD (Continuous integration and delivery) 2-3-5. コストコントロール 2-3-6. コミュニケーション 2-3-7. データマネジメント 2-3-8. 外部の知見 2-3-9. ID (アイデンティティ) 管理 2-3-10. インシデント管理 2-3-11. Infrastructure as Code (IaC, インフラのコード化) 2-3-12. 計測 2-3-13. ネットワーキング 2-3-14. 人的オペレーション 2-3-15. リソース管理 2-3-16. スポンサーシップ 2-3-17. チームワーク 2-3-18. スキル向上 付録: クラウド成熟度アセスメント 第一部: エグゼクティブ・サマリー 1-1. 四つのテーマ、三つのフェイズ The Google Cloud Adoption Framework には4つのテーマと、3つのフェイズがあります。 4つのテーマは以下です。 The Google Cloud Adoption Framework より引用した図を翻訳したもの Learn (学習) Lead (リード) Scale (スケール) Secure (セキュア) Learn (学習) は、技術部門のメンバーをスキルアップさせたり、あるいは技術のあるパートナー企業との連携を行うことを扱うテーマです。 Lead (リード) は、クラウド移行にあたり経営層やリーダー層の支援を得られているか、それにより部署間連携が取れているか、モチベーションは十分か、どのようなチーム編成となっているか、といった内容を扱うテーマです。 Scale (スケール ※) は、適切なクラウドサービスの利用や自動化を駆使することで、インフラに関わる運用負荷を減らしたり、アプリケーションのアップデートの負荷を減らしたりするためのテーマです。 ※スケール = コンピューティングリソースやストレージを、使用状況に応じて拡張したり縮小したりすることをスケーリングと言い、動詞的に「スケールする」のように用いる Secure (セキュア) は、セキュリティに関するテーマです。多層セキュリティ、IDベースのセキュリティを基本とします。 これら4つのテーマごとに、それぞれ3つのフェイズ (進捗度) があります。 The Google Cloud Adoption Framework より引用した図を翻訳したもの Tactical (「戦術」段階) Strategic (「戦略」段階) Transformational (「柔軟」段階) Tactical (「戦術」段階) は、個別の取り組みが存在しているものの、組織として一貫した状態にはない、という状態です。この状態での関心は、個々のシステムのコスト削減や、波風の少ない移行などに留まっており、将来の拡張などにはまだ関心がありません。ここが短期的なゴールになります。 Strategic (「戦略」段階) は、将来に渡る観点が存在し、個々の取り組みが管理されている状態です。また必要な関係者の巻き込みはできており IT チームは成果を出し始めています。ここが中期的なゴールとして捉えられます。 Transformational (「柔軟」段階) は、クラウド運用がスムーズに実現しており、関心はクラウド上にあるデータやそこから得られる洞察にある、という状態です。 IT 部門、もしくは相当するチームがイノベーションのエンジンになっており、これが長期的なゴールといえます。 1-2. クラウド成熟度 前述の4テーマ、3フェイズのうち、組織が現段階でどこにいるかを確かめる際は、 クラウド成熟度 をチェックします。 以下の図のように、組織は各テーマごとに、上から下へ成熟していきます。 The Cloud Maturity Scale - The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-3. エピック クラウド成熟度スケールを使って自組織の現在地が分かったら、次は前へ進むための方法を考えます。 クラウド導入のためのそれぞれの取組みのことを、ここでは エピック (※叙事詩のこと) と呼びます。 各エピックはお互いに重複しないよう定義されています。また、各個人のストーリーにブレイクダウンできます。 下の図は、エピックを People (人) 、 Technology (技術) 、 Process (プロセス) に分類したものです。 色がついた部分は、各テーマに対応しています。Learn (学習) = 緑、 Lead (リード) = 黄、 Scale (スケール) = 青、 Secure (セキュア) = 赤です。 全てのエピックを実施できない場合は 色付きの部分にまず取り組む ことが、成功への近道です。 Fine-tuning your direction with epics - The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-4. The Google Cloud Adoption Framework とは 先に紹介した「クラウド成熟度測定」で自組織の現在位置を確認したあと、エピックを使ってゴールへの施策を決めます。 なお The Google Cloud Adoption Framework は Google Cloud (旧称 GCP) だけでなく どのクラウドに対しても適用できる 方法論です。 Google Cloud の Technical Account Manager (TAM) の支援を仰ぐことで、超上流のアセスメントを行うことができます。 これによりクラウド成熟度を測定したり、それに伴うトレーニングの優先度決定や、チェンジ・マネジメント (※) の仕組みの策定、パートナーとの関わり方、クラウド運用体制、アカウント管理手法などを検討できます。 ※ チェンジ・マネジメント = 経営学用語。経営戦略や組織の変革がスムーズに行われるようにマネジメントすること、またその手法 TAM は、クラウド化の最初のプロジェクトから、その組織がクラウドファーストな組織になるまで、伴走することができます。 The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-5. はじめかた 1-5-1. クラウド成熟度の測定 ステイクホルダー (関係者) に4つのテーマ、すなわち Learn (学習) 、 Lead (リード) 、 Scale (スケール) 、 Secure (セキュア) を説明し、アセスしてもらいます。 後述のテクニカル・ディープダイブで、各テーマごとのサマリー表が示されるので、それを元に議論を勧めます。 1-5-2. ゴールを決める クラウド成熟度のうち、どの段階をゴールとするかを決めます。 この段階で、 IT 組織の中でも意見が合わないことが多いでしょう。 その人が組織の中のどの階層にいるかによって、クラウド化によって得られる利益 vs リスクに対する考え方が異なるからです。 まずは足がかりとして、短期戦術的な目標にフォーカスして議論することも検討しましょう。 1-5-3. クラウド導入プログラムを計画する ゴールとのギャップがあるエピックについて、施策を実施します。 いずれの施策も、最終的に以下の4つのいずれかに行き着くようにしてください。 トレーニングプログラムの策定 チェンジ・マネジメントプログラムの策定 クラウド運用モデルの設計 クラウドアカウントのセットアップ Getting Started - The Google Cloud Adoption Framework より引用した図を翻訳したもの 1-5-4. ちょうどよいワークロードを見つける ※ワークロード = 元は仕事量、処理量という意味。ここではシステムが処理する業務やその性質、あるいはシステム自体を指す 初めにクラウド化するのは「 シンプルでビジネスクリティカルではないシステム 」が最適です。 こういったシステムを最初にクラウド化することで、組織のクラウド能力を鍛え、自信をつけることに繋がります。 能力が高まってくれば、将来はより複雑でクリティカルなシステムのクラウド化にも対応できます。 最初のプロジェクトはワークロード主体で考えるべきか、あるいは運用方法主体で考えるべきか、悩むこともあるでしょう。 スタートアップ企業では、迅速に商用環境へデプロイすることを優先し、運用負荷は甘んじて受けることもあるでしょう。 トップダウンでクラウド導入を進める大企業であれば、クラウドを本番導入する前にまずは運用体制をしっかり確立することもあると思われます。 これらの検討に正解は無く、組織ごとに異なるものです。 第二部: テクニカル・ディープダイブ ※ディープダイブ = 技術要素などに対して、深堀りして紹介したり考察すること。 IT 界隈でしばしば使われる言葉 2-1. クラウド成熟度の各段階について 2-1-1. Tactical (戦術) 段階 Tactical (戦術) 段階は、既存 IT の コスト最適化 という短期的な目標ともいえます。 クラウド化によってあまり使われていないコンピュートリソース (※主に CPU ) やストレージを最適化したり、運用負荷を下げたり、調達やセットアップの工数を下げたりすることが該当します。 この段階では、 IT チーム (人的) 、アプリケーションやツール (技術的) 、運用体制 (プロセス的) に大きな変更は起こさないことが多いでしょう。 とはいえ、これもクラウド導入において重要なフェイズです。 Tactical (戦術) 段階では、期待する成果は TCO (※) 分析への影響度合いで判断します。 分析の結果として得られる利益が少ない場合、すぐに Strategic (戦略) 段階へ行きたいと考えるかも知れませんが、商用環境でクラウドを使った経験がない場合は十分に気をつけてください。この段階で得られる経験がチームに成功体験として残れば、その経験自体がのちのフェイズのための重要な基礎となるでしょう。 ※ TCO = Total Cost of Ownership, 総所有コスト。資産を調達してから廃棄するまでに発生する、金銭的・人的等のコストの総額 2-1-2. Strategic (戦略) 段階 Strategic (戦略) 段階は IT組織がもたらす価値の増大 という中期的な目標です。 この段階を達成するには、 IT チームの開発・運用に関する効果や効率が飛躍的に向上しなければなりません。 それには、アーキテクチャのモダナイゼーション (近代化) によりクラウドネイティブ (※) なサービスを活用することも含まれます。 ※クラウドネイティブ = 「クラウドありき」だったり、クラウドのメリットを存分に活用している状態を指す。サービスやシステムに対して使うこともあれば、組織や個人に対して使う言葉でもある この段階では、 IT チーム (人的) 、アプリケーションやツール (技術的) 、運用体制 (プロセス的) な変化が、一定の範囲で必要です。 変化は IT 組織の一部に留まるかもしれませんが、組織の将来像 (青写真) を示したり、成功体験として残るという意味で、最終段階である Transformational (柔軟) 段階への布石として重要です。 2-1-3. Transformational (柔軟) 段階 Transformational (柔軟) 段階は、 ITがイノベーションのエンジンである状態 を目指すという長期的な目標に当たります。 この段階では IT がビジネス変革を推し進める原動力となっており、もはやコストセンターではなくビジネスに不可欠な存在です。 以下のような要素がキーとなります。 既存データから洞察を得ること 新しいデータを収集・分析すること (感情、画像、音声など) 機械学習で Predictive Analytics (予測的分析 ※) や Prescriptive Analytics (処方的分析 ※) を行うこと ※ Predictive Analytics = 予測的分析。機械学習により、将来起こり得る事象や数値を予測すること ※ Prescriptive Analytics = 処方的分析。機械学習により、意思決定の自動化、もしくはサポートを行うこと また IT 組織自体もスピード感を持ってイノベーションを提供できるよう、上記のようなデータドリブンな (データ起因の) アプローチを取る必要があります。 組織として、 SLO の合意・計測を適切に行い、知見の横展開や、個人やチームが主体的に意思決定できることを促進するようにします。 またクラウドサービスやクラウド流のベストプラクティスが、組織の新しい常識になる必要があります。 組織は、失敗や障害を含めて実験的な取り組みを正しく評価し、成果とコストを適切に算定することで、この新しい常識を下支えできるでしょう。 2-2. 各テーマごとのクラウド成熟度 関連エピック: スキル向上 、 外部の知見 2-2-1. Learn (学習) Tactical (戦術段階) 自己動機づけに頼った、個人単位でのスキル向上 オンラインドキュメントや YouTube パートナーが全体的な知見をカバー パートナーがクラウド環境への admin 権限を持つ スキル向上は個人のベストエフォートに任されており、オンラインドキュメントや YouTube といった無料の教材を使っています。 この段階ではサードパーティのパートナーが完全に頼られており、クラウド資産への特権アクセスが可能です。 技術的な質問や、有事の際のエスカレーションもパートナーが一手に引き受けている状態です。 この段階に至るために、クラウド要員を雇う必要はなく、既存のメンバーで到達できるでしょう。 Strategic (戦略段階) トレーニング開催あり 資格試験への支援あり クラウド関連業務での人材募集あり パートナーが緊急時のみ発動するクラウド環境への admin 権限を持つ (Break-glass admin access ※) ※ Break-glass 〜 = 緊急時に稼働するものを意味する。火災報知器のアラームを鳴らすためにガラスを割ることから 定期的なスキル向上プログラムが IT 要員に対して提供されている状態です。 資格試験取得が推奨され、予算も確保されています。 サードパーティのパートナーは、社内の IT 要員がまだ持っていないスキルや、内製で到達するには狭く深すぎる領域の知見をカバーします。 技術的な質問や有事の際のエスカレーションについては、一次受けは内部の IT メンバーが受けます。 そこで解決できない場合の第2層として、サードパーティのパートナーがエスカレーションを受けます。 そのため、パートナーは普段は制限付きのアクセス権限しか持っておらず、有事の際に必要な権限へ昇格する仕組みとなります。 この段階ではクラウド用の新しいポジションが用意され、採用施策が始まっています。 また各 IT メンバーにはテスト用のクラウド環境 (サンドボックス) が用意され、検証作業や新しいアイデアのテストを行うことができます。 Transformational (柔軟段階) 個人同士が相互に学びあう文化あり wiki, テックトーク(※), ハッカソン IT 要員の役割や責任範囲が刷新されている パートナーは補強的な役割のみであり、特権を持たない ※テックトーク = 技術に関する意見交換会、知見共有会など この段階では、スキル向上は継続的で、相互的に行われます。 定期的なトレーニングに加えて、 IT チームや個々の従業員は、定期的にハッカソンやテックトークを開き、知見を共有します。 IT メンバーはブログ記事や講演を通じて、業界をリードする立ち振舞いをすることが推奨されます。 これは IT メンバーの成長の意味もありますが、新たな採用に繋がるという点で一石二鳥です。 クラウドファーストな IT 組織として、 IT 部門の役割と職責は、必要な再定義が完了している状態です。 サードパーティのパートナーは、補助的な役割のみを担います。 特権管理権限は持ちません。ほとんどのエスカレーションは内部で解決し、全てのインシデント対応手順が内部で完結します。 2-2-2. Lead (リード) 関連エピック: スポンサーシップ 、 チームワーク Tactical (戦術段階) ある特定プロジェクトの特定個人によりクラウド導入が行われる IT 部門内の別部署との連携は難しい 上長からの承認はあるものの、予算は限られている この段階では、スポンサーシップ (上長・幹部からの支援) は単一部門の上級管理職からのものに限られている状態です。 といっても、この上長はクラウド導入を承認し、進捗が芳しくないときのエスカレーション先であるに過ぎません。 クラウド導入は個人的なクラウドへの興味を持っている一部のメンバーによってのみ、行われます。 他の IT メンバーとの連携は、既存組織の構造次第で制限されてしまいます。なぜなら、 IT 部門員の職責の範囲は、割り当てられたプロジェクトやビジネス部門の管轄内・予算内に限られてしまっているからです。 また彼らの成果は末端で利用される IT だけに現れており、組織の中央の IT に還元されることはありません。 結果として「かろうじて生存しているクラウド」や「クラウド・シャドーIT (※)」のようになってしまいます。 ※シャドー IT : 中央の IT 部門によって承認されていない IT ツール等を事業部門やメンバーが勝手に使っていることを指す。一般的にセキュリティリスクである Strategic (戦略段階) プロジェクト横断で集まった少数のクラウド推進派グループによりクラウド導入が進む このグループ外との連携は難しい CxO レベルの幹部からの承認があり、予算もついている この段階では C レベルの幹部 (※) からのスポンサーシップを受けられるようになっています。 レポートライン上の各マネージャは、クラウド導入にあたり目標や KPI を明確に定められています。 上長からの支援により、他の IT 部門やビジネス部門との水平連携が可能になっています。 ※ Cレベル = CIO, CTO など C から始まる幹部職 いまだ従来型の SLO (Service Level Objectives, サービスレベル目標) が、検証のスピードやイノベーション、障害からの回復よりも優先されています。 この段階では、クラウド導入は少数精鋭の機能横断・プロジェクト横断のチーム (Center of Excellence, CoE) により進められています。 この CoE チームにはアプリケーションアーキテクト、ソフトウェアエンジニア、データエンジニア、ネットワークエンジニア、 ID / ディレクトリ管理者、運用担当者、セキュリティ担当者、財務担当者など、コアとなる役職が揃っている状態です。 チームのメンバーは、専務の場合も兼務の場合もありますが、役職名や評価軸は新しい役割に応じて刷新されています。 IT 組織などの関係者と技術業界知識に明るい、専任の技術マネージャーがいることが望ましいでしょう。 Transformational (柔軟段階) 自主的なプロダクト開発チームが複数ある エラーバジェット (※) と "批判なし" のポストモーテム (※) が CxO レベル幹部に認識されている 組織全体で定期的に進捗が更新される ※エラーバジェット = 事前に定める障害に対する予算であり SLO に基づき算出される。これが残っているうちは新しいリリースが可能、などのように使われる ※ポストモーテム = 語源は「検死」。インシデントとその対応が完了した後に、事象・対応・原因・根本対策などをまとめる再発防止目的のドキュメント。障害報告書と似ているが報告ではなく改善が目的である点でニュアンスが異なる ※いずれの用語もオライリー社による出版の『SRE サイトリライアビリティエンジニアリング』に詳しい。同書は Google のメンバーにより執筆され SRE という用語を広く普及させた スポンサーシップは、マーケティング、財務、オペレーション、人事などをも含む CxO レベル幹部全体から受けられるようになっており、その下位のマネージャ陣にも行き渡っている状態です。 そのおかげで、実験とイノベーションが大事であるという文化が全体に行き渡っています。 エラーバジェットの概念が CEO まで理解されており、批判を伴わないポストモーテムの文化が IT 組織に浸透しています。 チームは、透明性がありオープンな情報共有が可能な環境で働くことができており、各種決定権限を持っています。 アドホックな検証を行うために、承認を得たりリソースの準備を待つ必要はありません。 データガバナンスやコストコントロールは自動化されています。 障害すら、後進のための貴重な教訓として歓迎されます。個人による失敗は個人に帰すことはせず、組織としての欠陥と解釈され、叱責はありません。 2-2-3. Scale (スケール) 関連エピック: アーキテクチャ 、 CI/CD (※) 、 IaC (※) ※ CI/CD = Continuous Integration / Continuous Delivery 。継続的インテグレーション・継続的デリバリーと訳される。前者は自動化によりソフトウェアのビルド・テストのスピード・効率を向上させる手法。後者は自動化を駆使してサービスのリリースのスピード・効率を向上させる手法 ※ IaC = Infrastructure as Code 。IT インフラをコードないし定義ファイルで定義して再現性確保・自動化・バージョン管理を可能にする手法 Tactical (戦術段階) クラウドリソースは手動で展開される アプリは長期運用の VM に展開。 OS の保守が必要 環境変更のレビューは手作業 環境変更のリスクは高く、頻度は低く、手作業 この段階では、マネージドサービス (※) やサーバレス (※) の利用は限定的です。 自ら運用する必要がある 仮想マシン (VM ※) に頼っています。 しかしこれは、管理対象が増えるに連れ、対象ごとに意図しない設定のズレが起きるなどの原因となり、管理運用の工数が増え続けます。 サーバの数が増えれば増えるほど、管理・運用の対象は増え、監視対象も増え、パフォーマンス情報の収集対象も増えていきます。 ※マネージドサービス = クラウドサービス側でインフラが管理されるサービス。物理層や OS 層を意識せずソフトウェアレベルで利用することができる。例として Google Cloud (GCP) の Cloud SQL や Amazon Web Services (AWS) の Amazon RDS はリレーショナルデータベースのマネージドサービスである ※サーバレス = マネージドサービスのうち、サーバの概念がない (ユーザから見て隠蔽されている) サービスのこと。利用前にインスタンスの展開等が必要なく、即座に利用できる。 Google Cloud (GCP) の BigQuery や Amazon Web Services (AWS) の AWS Lambda などが該当 ※仮想マシン (VM) = Google Cloud (GCP) であれば Google Compute Engine (GCE) であり、 Amazon Web Services (AWS) でいえば Amazon EC2 である アプリケーションのコードやインフラ設定の変更は人の目によりレビューされ、手動で実施されます。 環境に対する変更は高リスクとみなされ、数週間に一度、もしくは数ヶ月に一度の頻度です。 この段階では、クラウドリソースの展開は手動で行われます。 Google Cloud (GCP) の Deployment Manager や Hashicorp 社の Terraform といったインフラ自動化ツールは用いられません (※) 。 ※ Amazon Web Services (AWS) の場合は Terraform や AWS CloudFormation が該当する Strategic (戦略段階) クラウドリソースはテンプレートから展開する アプリはイミュータブル (※) な VM やコンテナに展開。 OS への接続は不可 (不要) 環境変更のテストは自動 環境変更のリスクは中程度 環境変更は手動 ※イミュータブル = 「不変の」を意味する英単語。コード定義の仮想サーバまたはコンテナの利用により、インフラ (サーバ) が不変である代わりにいつでも捨てられることを意味している。従来はサーバを構築すると、内部に配置された設定ファイルにより設定が管理され、アプリケーションのデータを内部に持つため、サーバの中身は「可変」であった。それゆえ、サーバのバックアップを取り、障害の際は中身の復旧が必要となる。対してイミュータブルなインフラでは、サーバの中身は変わらない。データは外部のデータストアに永続化され、設定値はコードでバージョン管理されるからである。障害の際は、障害が起きたサーバ/コンテナは廃棄し、新しいサーバ/コンテナをイメージから復旧する。このイミュータブルなインフラにより管理工数は大幅に減り、水平スケールが容易になる この段階では VM はイミュータブルな設計になっています。そのためシステム変更におけるスコープを小さくすることに成功しています。 環境設定はファイルではなく、 VM イメージとして保持され (イメージを "焼いておく" と表現することもあります) バージョン管理されています。 ステートフル (※) なワークロードとスケートレス (※) なワークロードは区別されており、そのため柔軟な水平スケール (※) ができるようになっています。 ※ ステートフル = アプリケーションやサーバが状態を保持することが前提のアーキテクチャ。「データ腹に持つ」ものが該当。例えばあるアプリケーションサーバがローカルディスクにセッションファイルを保存する仕組みの場合、そのアーキテクチャはステートフルである ※ ステートレス = アプリケーションやサーバが状態を保持 "しない" ことが前提のアーキテクチャ。「データを腹に持たない」ものが該当。保存するべきデータは全てサーバ/コンテナ外部のデータベース等のストレージに保存する ※ 水平スケール = スケールアウトとスケールイン。1つのサーバのスペックを上げたり下げたりするスケールアップやスケールダウンとは対象的に、サーバやコンテナの数を増やしたり減らしたりしてパフォーマンスを調整する方法。アプリケーションがステートレスであれば、データを複製したり整合性を取る必要がないため、水平スケールが容易である 環境変更のリスクは中程度であると認識されている状態です。 本番環境へのデプロイはプログラムにより行われますが、その処理は人手によって起動されます。 必要な場合、すぐにロールバックして元の状態に戻すことができます。 アプリケーションチームは基礎的なモニタリングから卒業し、 Application Performance Monitoring (APM) を実現しています。 24 時間・ 365 日 でアプリケーションのパフォーマンスに関する洞察を、ニアリアルタイムで得ることができています。 Google Cloud (GCP) プロジェクト (あるいは AWS でいう "AWS アカウント" 等) や VPC ・ ID など関連リソースの展開は Deployment Manager (Google Cloud), Terraform (Hashicorp) などを用いてプログラムで行われます。 コスト明細タグやデータ機密レベル、保有チームなどインプットすべき変数を入力すれば、自動的に展開できるようになっている状態です。 Transformational (柔軟段階) 全クラウドリソースはボタン一つで、数分内に再構築可能 アプリはサーバレスなクラウドサービスに展開 環境変更は定常的で低リスク 環境変更はプログラマブルに行われる 本番環境 VM には緊急時のデバッグ目的以外ではアクセスできないようになります。 セルフマネージドなサービス (IaaS) は全て、マネージドサービス、サーバレス、 SaaS などに置き換わっており、運用負荷は最小化されています。 環境変更のリスクは小さいとみなされ、本番環境へのデプロイはプログラムにより自動的に行われます。 カナリアリリース (※) やブルーグリーンデプロイ (※) などのフェイズ別デプロイ戦略が実施されています。 ※カナリアリリース, ブルーグリーンデプロイ = いずれもアプリケーションのデプロイ戦略の名称で、新バージョンへの切り替えと問題があった際の旧バージョンへの切り戻しを効果的に行うための戦略。 Amazon Web Services Japan 公開の AWS Black Belt Online Seminar AWS CodeDeploy の資料に詳しい ロギングとモニタリングは包括的であり各 SLO のもとになる全ての SLI をカバーしています。 全てのクラウドリソースは Deployment Manager (Google Cloud), Terraform (Hashicorp) などを用いてプログラムで行われます。 本番環境全体が、数分以内で別ゾーンや別リージョンに再構築できるようになっています。 2-2-4. Secure (セキュア) 関連エピック: アクセス管理 , データマネジメント , ID (アイデンティティ) 管理 Tactical (戦術段階) ID は Google によってのみ発行 Owner, Editor, Viewer といった基本ロールのみ利用 (Google Cloud の場合) 境界型セキュリティに依存し、プライベートネットワーク内を暗黙的に信用してる この段階では、利用者の ID は Cloud Identity (※) によって管理されており、それが Google Analytics や Adwords, YouTube などの他の Google サービスのアカウントにもなります。 アカウントが企業によって管理されている状態です。 しかしながら、まだ Microsoft Active Directory などの企業の中央ディレクトリとは同期されていません。 ※ Cloud Identity = Google Cloud (GCP) の ID を管理するための仕組み。 Amazon Web Services (AWS) の場合は、これを IAM User と読み替えて差し支えない。 Cloud IAM では Owner, Editor, Viewer (※) といった、非常に強い権限を持った基本ロールの利用がほとんどです。 これは、最小権限の原則を守っていない状態といえます。 権限設定がデフォルトのままなので、 Google Cloud (GCP) ユーザーは好きにプロジェクトや請求先アカウントを作成できてしまう状態です。 IAM 権限は Forseti Security のようなツールを使ってモニタリングされていません。 Cloud Audit Logs (※) の管理アクティビティ監査ログやデータアクセス監査ログはシステマティックにチェックされていません。 サービスアカウント (※) の作成も制限なしで自由に作成でき、秘密鍵も自動ローテーションされません。 ※ Owner, Editor, Viewer = 管理者用、編集者用、閲覧者用の強い権限を持つロールで、プロジェクト内の全てのリソースに対して強い操作権限を持つ。 AWS であれば Administrator や ReadOnlyAccess といった AWS 定義の IAM ポリシーが該当 ※ Cloud Audit Logs = 監査ログを保存する仕組み。 当社ブログ に詳しい。 AWS であれば AWS CloudTrail が該当 ※ サービスアカウント = アプリケーションなど人間以外が Google Cloud API 等をコールするときに用いるアカウント。当文の記述は AWS であれば Amazon EC2 用の IAM Role であったりプログラム用の IAM User から発行される Credentials を自由に発行できる状態を意味している ネットワークセキュリティ (境界型セキュリティ) が過信されており、ファイアウォールが重要なセキュリティコンポーネントです。 IP アドレスやポート番号といった情報に基づいてアクセスが制限されます。 クラウドとオンプレミス間の通信は VPN トンネルなどによる暗号化はなされているものの TLS によるエンドツーエンドの暗号化にはあまり関心が払われていません。 VPC Service Controls (※) は Cloud Storage や BigQuery といったフルマネージドサービスに対して適用されていますが、データの機密性に応じてルールが設計されている状態には達していません。 ※ VPC Service Controls = Google Cloud (GCP) の API をコンテキスト情報に応じて保護するための仕組み。 当社ブログ に詳しい。 Strategic (戦略段階) ID は企業のディレクトリから同期される 最小権限の原則に基づいて定義済み IAM Role が利用される (Google Cloud の場合) ネットワークレイヤとアプリケーションレイヤのハイブリッドセキュリティモデル クラウドユーザーの ID は Active Directory や OpenLDAP といった企業のディレクトリサービスから Google Cloud Identity に同期されているため、整合性があり、運用もシンプルです。 ユーザーは同期されたパスワードで認証するか、あるいはサードパーティの SSO (Single-Sign On) サービスで認証されます。 100% のユーザーは SMS (ショートメッセージ) やワンタイムコード生成アプリを使った二段階認証を使っており、フィッシング攻撃などの対策となっています。 Cloud IAM ポリシーにおいては、おおざっぱな基本ロールの利用はやめて、より細かく権限定義されている事前定義ロール (※) を利用しています。 Google Cloud (GCP) でデフォルトで付与されている プロジェクト作成者 ( Project Creator ) ロールと 請求先アカウント作成者 ( Billing Account Creator ) ロールは Google Cloud 組織レベルからは削除されており基本的なクラウドリソースのガバナンスが確保されています。 ※事前定義ロール = 基本ロール以外のプリセットの IAM ロール。例として「 BigQuery 管理者」のように用途別に権限が予め定義されているので利用者は細かく権限を設定する必要がない。 AWS では AWS IAM の「AWS 管理ポリシー」が該当 VPC の境界セキュリティはファイアウォールだけでなく Cloud Load Balancing (TLS 有効化) や Cloud Identity-Aware Proxy (IAP) 、 Cloud Armor などで強化されています。 これらはパブリックなインターネットにサービスを晒すことにおけるリスクを低減化するものです。 Transformational (柔軟段階) 全てのアプリ間アクセスに対して認証・認可が行われる IAM ポリシーが継続的にモニタリングされ修正される インターネットから VPC に至るまでの多層ネットワークセキュリティ 全てのサービス間通信は認証・認可されます。同一 VPC や同じプライベートネットワークにいるノード同士でも、信頼はしません。 VPC のファイアウォールルールも、 IP アドレスレンジによってではなく、サービスアカウントによって許可されます (※) 。 ※サービスアカウントによるファイアウォールルール = Google Cloud (GCP) のファイアウォールルールでは、 IP アドレスやポート番号による許可 / ブロックという一般的なルールを使うことができるが、 VM に付与したネットワークタグによるルールや、 VM に付与するサービスアカウントによるルールを利用することもできる どのデータストアにどのようなデータが入っているか、ということが全体的に理解されており、それゆえに認証をすり抜けたアクセスや不適切なアクセスに対応するセキュリティモデル・データガバナンスモデルを適切に設計することができます。 100% のクラウド利用者がハードウェアセキュリティキーを二段階認証に使っているため、フィッシング攻撃への対策は十分です。 SMS (ショートメッセージ) やワンタイムコード生成アプリが十分に安全ではないと認識されています。 Cloud Audit Logs の管理アクティビティ監査ログやデータアクセス監査ログは定期的に監査され、事前に定義した脅威パターンに一致した場合はアラートが自動発報されるように設定されています。 Cloud IAM の権限やファイアウォールのルールは継続的にモニターされ、 Forseti Security のようなツールで修正されます。 2-3. エピック クラウド成熟度が測定できたら、次は具体的なアクションです。ここでエピックを使います。 エピックは「人 (People) 」「プロセス (Process) 」「技術 (Technology) 」に分類されています。 Fine-tuning your direction with epics - The Google Cloud Adoption Framework より引用した図を翻訳したもの ※原文では以降、各エピックはアルファベット順で記載されている。当記事では日本語に翻訳しているが、そのままの順番で記載する。 2-3-1. アクセス管理 目的: 適切な人/サービスだけが認証・認可され適切なリソースに対する適切な操作を行えるようにすること 適切なアクセス管理ができていれば、不便さを感じさせることなく、最小権限の原則で、人/サービスが業務に必要なリソースへアクセスできます。 Google Cloud (GCP) では Cloud Identity と Resource Manager の組み合わせでこれを実現できます。 2-3-2. アーキテクチャ 目的: ベストプラクティスを適切に推奨したり、将来を視野に入れたクラウドコンピューティングやストレージの選択に役立つ視野を提供すること アプリケーションがクラウドプラットフォームをフル活用できるためにはコンピュートやストレージの適切な選択が必要であり、これに寄与するのがクラウドアーキテクチャです。 例として「柔軟なスケーラビリティを得るためには、アプリケーションはステートレスなマイクロサービス構成とし、永続ストレージとは分離する」「再現性とセキュリティを確保するために、手作業でのパッチ当てやメンテナンスを排除する。そのためインフラはコード定義とし、イミュータブルなものにする」といったものです。 アプリケーションやデータウェアハウス、パイプラインなどのスケーラビリティ・可用性・費用負担を段階的に変えていくこと、また開発スピードを向上させていくことは、どのようなビジネスでも必須だと考えられます。 2-3-3. 振る舞い 目的: よりチームとして働きやすくしたり、受け手の気持ちを考えるコミュニケーションを取れるようにしたり、スキル向上プログラムからより多くを得たりするための「振る舞い」を助長する、システマティックな方法を開発すること 人の振る舞いの 90% 以上は無意識のモチベーション、価値観、信念、習慣から起こるのだといいます。 成功するクラウド導入には、意識的な行動だけでなく、マインドセットや価値観にも着目する必要があります。 Learn (学習) や Lead (リード) がうまくいくかどうかは、人々が次のような新しい振る舞いを受け入れられるかどうかにかかっています。 例: コラボレーション、批判しない文化、心理的安全性、プロトタイピング、データドリブンな意思決定 組織の「現在の振る舞い」と「目指すべき振る舞い」の両方を理解して、「目指すべき振る舞い」に行き着くための行程を設計することが最終ゴールです。 2-3-4. CI/CD (Continuous integration and delivery) 目的: CI/CD パイプラインによりシステムへの変更を自動化し、最小の中断時間で全ての変更がテストされ、監査され、デプロイされるようにすること 巨大な分散システムでは不明点や依存関係、部分によって責任部署が違うなど、コードへの変更が意図通りに動かない可能性に繋がる不確定要素が多くなりがちです。 ビジネスにとって、不確定要素はリスクやソフトウェアデリバリーの遅延に繋がります。 CI/CD (Continuous integration and delivery) によって継続的にリリースプロセスを検証することで、どんなコード変更でも意図通りに動くという自信に繋がります。 2-3-5. コストコントロール 目的: コストをニアリアルタイムで可視化することで、開発者やアーキテクトにコスト意識を持たせること クラウドでは前払いが必要な調達がなく、資産化による減価償却に基づく複数年のキャパシティ計画もありません。そのため、コストコントロールは一人のソフトウェアエンジニアから始まることもあります。 オンプレでは物理的な制約がありましたが、クラウドでは代わりにリソースクォータ (ソフトウェア的な上限) やオートスケーリングの設定があるのみです。 適切なダッシュボード・アラート設定・プロセスの確立がなければ、複数プロジェクト・複数チーム・複数事業部門によるクラウド支出を管理することは、難易度が高く時間もかかるものとなってしまいます。 物理的制約がないため、アプリケーションの所有部門は、次の3つの戦略のうちどれかを選び、実行する必要があります。 無制限のスケーリング (例: E コマースサイト) 徐々に削減する (例: 社内のデータ分析) 上限を設ける (例: 開発用サンドボックス) 2-3-6. コミュニケーション 目的: 「失敗をオープンに共有することを推奨」「ミスは改善の機会として歓迎される」といった風潮の土台となるように、批判をしない文化やオープンコミュニケーションの文化を理解して、醸成すること こんにちではソフトウェアのデリバリーは速度も速く、複雑です。そのような中で組織は、失敗や障害は不可避であり、ミスは改善の良い機会である、ということを理解する必要があります。 心理的安全性を作り出し、批判のない職場を醸成し、リスク取ることが奨励され、ミスの責任は個人ではなく仕組みやプロセスにあるとする文化であることは、もはや必須です。 またポストモーテム (前述) は、批判しない文化・学び続ける文化・仕組みの改善の文化を醸成する大事なツールとなります。 2-3-7. データマネジメント 目的: どんなデータが保管されており、出自はどこで、どれくらい機密性があり、誰がアクセス可能なのか、といったことを理解して管理することで、データの安全を守り、検索可能で、利用可能にすること データマネジメントが弱いと、データ漏洩やそれによる信頼失墜、規制当局による制裁などの結果に繋がります。 暗号化、分類、漏洩対策、コンプライアンス規格の順守などはもちろんのこと、データマネジメントでは他にも多くの事項を検討する必要があります。 2-3-8. 外部の知見 目的: エキスパートの支援により、ベストプラクティスを適用し、他組織のクラウド導入期の教訓を学ぶことで、クラウド導入を加速すること 知識はトレーニングなどから得ることができます。しかし経験はそうもいきません。 そういった経験があれば、問題を早急に解決したり、予測不可能なリスクに対処したり、特定のビジネスニーズにフィットするソリューションを効率的に開発することができます。 クラウド導入の初期段階では、組織の外部に支援を求めることが有効な策となり得ます。 Google のパートナー、プロフェッショナルサービス (※) 、 Office of the CTO (※) 、ソリューションアーキテクト (※) などが支援可能です。 ※プロフェッショナルサービス、 Office of the CTO = いずれも Google Cloud のコンサルタントサービス ※ソリューションアーキテクト = クラウドでのアーキテクチャ設計に精通したエンジニア 2-3-9. ID (アイデンティティ) 管理 目的: 人もしくはサービスへの信頼ある認証を提供すること、および認証情報の漏洩やなりすましに対策すること 人やデバイスのアイデンティティ管理に信頼がおけることは、現代的なセキュリティモデルでは必須です。 現代的なセキュリティモデルにおいては、単一要素だけを信頼することはありません。 パスワード、証明書、 IP アドレスといった要素は単一では信頼の対象にはなり得ません。 代わりに複数要素を組み合わせることで、どんなネットワークからのアクセスも可能にします。 2-3-10. インシデント管理 目的: 内製および Google のサポートのもとで、予定外のサービス低下を、秩序正しく迅速に、アラート発報・トリアージ・整理すること システム運用では効率的で効果的なサポート提供や、迅速なサービス復旧が求められます。 クラウド導入においては、スキルのギャップや運用プロセスのギャップが発生し得ます。 ソリューションの最適化や稼働率向上、ビジネス価値を確保するためには、これらのギャップは正す必要があります。 適切なサポート体制を構築することで、サービス中断のリスクを下げたり、中断が起こったときでも影響範囲を最小化したりすることができます。 ツールやサービス構築に使っているプラットフォームを最大限利用することが重要です。 2-3-11. Infrastructure as Code (IaC, インフラのコード化) 目的: 設定値や構築をコード化することで自動化し、人的ミスを撲滅し、時間を節約し、全ステップをドキュメント化すること インフラをプログラム化することにより設定値とリソースの展開を自動化すれば、水平スケール・自動スケールが可能になります。 またサーバへの admin/root 権限アクセスを禁止したり、開発環境を数分で展開したり、本番環境すら安定バージョンと新バージョンの間をダウンタイムなしで切り替えることも可能になります。 2-3-12. 計測 目的: リソースの稼働状況やログイベントを計測し、アプリケーションをトレース・プロファイリング・デバッグすることで、様々な状況下でのシステムの挙動を監視し、 SLO を定量化すること 包括的な計測を行うことは、クラウドでは一層重要になります。 計測されたメトリクス (指標) によって、クラウドリソースをいつ、どのようにスケールするかが決まりますし、障害時やパフォーマンス低下時には、原因がクラウドサービス側なのかアプリケーション側なのかを判断する重要な要素になります。 また、クラウドにおける全ての操作は API コールなので、誰が、どのリソースに対して、どのような操作を行ったかという監査ログを包括的かつ変更不可能な形で残すことで、クラウド運用を本質的にセキュアにすることができます。 2-3-13. ネットワーキング 目的: 認証・認可の有無とは別軸で、サービスやデータの流れを論理的境界により接続・保護すること ネットワークはどのようなビジネスにとっても重要なインフラです。ネットワークは顧客とサービスを繋ぎ、エンドユーザーとビジネスを繋ぎ、従業員の仕事を可能にします。 こんにちのビジネスは、接続性なしには成り立ちません。そして接続性は、組織 (会社) の境界内だけにとどまらず、顧客、パートナー企業、インターネットにも広げる必要があります。 これはどのような規模・形式のビジネスでも同様であり、オンプレミス・クラウド・ハイブリッドの別を問いません。 2-3-14. 人的オペレーション 目的: 必要な組織構成を定義し、クラウド導入担当者たちを適切な役職・スキル・勤務評定手法に当てはめ、クラウド導入の円滑を図ること 組織構成・人員配置・勤務評定手法を調整することで、チームが変更を受け入れて新しい役割をこなすことを促進できます。 逆に、 IT 部門や運用部門、関連ビジネス部門がどのように動くべきかを理解せず、期待されていることが分からない状態だと混乱が発生し、せっかくのクラウド移行のための投資への悪影響となってしまいます。 また、クラウド導入担当者たちが新しい役割や新しい振る舞い (コラボレーション、透明性、失敗の許容、信頼) を受け入れることへの動機付けも重要です。 そのための勤務評定手法やインセンティブ構成が必要となってきます。 最後に、測定可能でありかつクラウド導入行程と連携した「組織としてのゴール」を定義することが非常に重要です。 ゴールや方向付けがブレると、クラウド導入の成功は遠のきます。 2-3-15. リソース管理 目的: クラウド環境の整頓・一貫性確保・制御のため、クラウドリソースのクォータ (割当て上限) を整理・明示・設定すること クラウドでは誰でも仮想的にリソースを生成することができますが、代わりに見通しが悪くなったり、勝手な行動をされるおそれも出てきます。 有用で分かりやすいルールを作り、組織の階層構造と合わせてフォルダー・プロジェクトの階層構造 (※) を構築すれば、ガバナンスを維持し、無秩序状態を回避することができます。 ※フォルダー・プロジェクトの階層構造 = Google Cloud (GCP) ではクラウド環境の1テナントを "プロジェクト" と呼び、複数プロジェクトをグルーピングして整理する単位を "フォルダー" と呼ぶ。フォルダーやプロジェクトは階層構造にして管理ポリシーや IAM 権限を適用できる 2-3-16. スポンサーシップ 目的: 幹部層からの熱心かつ継続的な支援により、クラウド導入担当者が変革を委任されていることを広く認識させること スポンサーシップとは、幹部やリーダーがクラウド導入チームやプロジェクトに対して、能動的で目に見える形の支援を行うことをいいます。 組織でのクラウド導入は複雑です。ビジネス価値の増大やコラボレーション推進、速度向上のために、組織規模でクラウド利用を決断するにあたって、 強力なスポンサーシップは必要不可欠です。 幹部層は組織で最も影響力がある立ち位置だけに、クラウド導入戦略に対して熱心かつ継続的な支援を行うことで、クラウド導入担当者たちが変革を委任されているのだということを広く認識させる必要があります。 2-3-17. チームワーク 目的: クラウド技術が最高効率で活用されるよう、コラボレーションと信頼に基づく振る舞い・文化を体現するチームを構築すること チームワークは、個々人の担当者によるボトムアップの理念リーダーシップ (Thought leadership) から始まります。 理念リーダーシップは Center of Excellence (CoE ※) や専任エバンジェリスト、非公式のクラウド派など様々な形を取り、また多くの知見共有の取り組みとなっている場合があります。 ※ Center of Excellence (CoE) = 組織の中で特定技術や分野において、研究・開発・導入などのリーダーシップを取るチームのこと。特にクラウドにおいては Cloud Center of Excellence (CCoE) と呼ばれ近年話題になっている こういった主導者たちが、セキュリティやアーキテクチャ、ネットワーク、運用、データベース管理などの規律を形作っていきます。 彼らに共通しているのは、前向きであることと、クラウド導入のベストプラクティスに自発的に関心を持っていることです。 こういった主導者がいない場合、クラウド導入は幹部層のスポンサーシップに依存してしまいます (スポンサーシップの項を参照)。しかしこのような一方的かつトップダウンの方策はスケールが遅く、またクラウドの利点である IT リソースの本質的な民主化という利点を活用できない結果にお話ある可能性があります。 2-3-18. スキル向上 目的: 現職メンバーが持つ業務知識や既存 IT 資産に関する知見と、新規に学んだベストプラクティスを融合するため、学習に対して投資をすること クラウドコンピューティングは、仮想化の出現以来、類を見ないパラダイムシフトとなっています。 これらの新しい考え方やベストプラクティスは、チームの個々人のスタイルにあうように、様々な方法で学習することができます。先生が教えるタイプの研修や、 coursera.com や qwiklabs.com のようにインタラクティブな自己学習タイプのものでもよいでしょう。 スキル向上とは、技術的な理論を学ぶことだけを指すのではありません。学んだことを業務に活かしたり、自分で問題解決ができるようにしたり、 Google サポートを利用したり、同僚と教訓を共有したりすることで、継続的に学ぶ文化を醸成し、それにより組織全体の知見を育てることこそが重要です。 付録: クラウド成熟度アセスメント ホワイトペーパーの抄訳は、以上で終了です。 ここからは Google により無償公開されている、クラウド成熟度アセスメントツールをご紹介します。 以下のサイトで公開されている Web ツールを用いると、ホワイトペーパー内でも紹介されていたクラウド成熟度を測定することができます。 digitalmaturitybenchmark.withgoogle.com 画面に表示される質問に順に答えていくと、組織の現在のクラウド成熟度を4つのテーマに沿って測定することができます。 質問の内用を吟味すると、今の組織に足りないものが何か、見えてくるはずです。 質問は英語ですので、苦手な方は Chrome ブラウザの翻訳機能などを駆使してご活用ください。 杉村 勇馬 (記事一覧) 執行役員 CTO / クラウドソリューション部 部長 元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。Twitter では Google Cloud や AWS のアップデート情報をつぶやいています。 Follow @y_sugi_it

G-gen の杉村です。Google Cloud 認定資格の1つである Professional Data Engineer 認定資格は、Google Cloud でのデータエンジニアリングやデータ分析に関する難関資格です。当記事では、試験の学習に役立つ情報を記載します。 はじめに 当記事の内容 想定読者 試験の難易度 推奨の勉強法 出題傾向 セキュリティとガバナンス 組織、IAM 個人情報の扱い VPC Service Controls BigQuery 基本的な知識 関連記事 外部テーブルと BigLake テーブル データの共有 Cloud Storage 基本的な知識 複数リージョンとターボレプリケーション Bigtable 基本的な知識 テーブル設計 運用 適切なデータベースの選択 Dataplex Dataplex による権限管理 Dataplex Universal Catalog Dataflow 概要 ウインドウ exactly-once 融合（fusion） ネットワークとファイアウォール データパイプライン Dataform Pub/Sub Cloud Composer Dataproc Dataprep、Cloud Data Fusion データ移行 オンプレミスからのデータ移行 データベース間のデータ移行 機械学習（AI/ML） オペレーションスイート 基本 注目すべきメトリクス その他 受験環境 はじめに 当記事の内容 当記事では、Google Cloud（旧称 GCP）認定資格の1つである Professional Data Engineer 認定資格の学習に役立つ情報を紹介します。Professional Data Engineer 認定資格は、Google Cloud でのデータエンジニアリングやデータ分析に関する難関資格です。 参考 : Professional Data Engineer 認定資格 試験の利用規約において、試験の内容を公開することは禁じられています。そのため当記事では試験問題そのものを書くこと等はせず、主にサービスカットで、 合格するためには何を知っているべきか という観点で情報をご提供します。 なお、当記事で試験範囲を全てカバーできているわけではありません。公式の試験ガイドや模擬試験なども駆使して、学習を進めてください。 想定読者 当記事は以下のような方向けです。 Professional Data Engineer 試験の出題傾向を知りたい Google Cloud サービスやデータエンジニアリングの基本的な知識は把握済みである 近日中に試験を受けようと思っているので、知識の確認をしたい また前提知識として Google Cloud の基礎知識が必要です。 Associate Cloud Engineer 試験 相当の知見は持っておくことが推奨されます。以下の記事も参考にしてください。 blog.g-gen.co.jp 試験の難易度 Professional Data Engineer 試験の難易度は、 比較的高い と言えます。 IPA の「応用情報技術者試験」程度の基本的な IT の知識があり、かつ Google Cloud をある程度業務で使用した経験があることが望ましいです。これに加えて、データモデリングや ETL / ELT 、分散アーキテクチャのデータ処理基盤や RDBMS、NoSQL データベースなどのデータ関連技術要素に関する基礎知識が必要です。 これらの情報技術に関する基礎知識のうえに、Google Cloud のデータベースやデータ処理に関するサービスや、サービスの組み合わせなどについて、書籍や公式ドキュメントで理解しておくこと必要があります。 また、普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、Google の考える「クラウドらしいクラウドの使い方」という一種の哲学を、頭にインプットしておくことが重要です。 これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。 推奨の勉強法 Associate Cloud Engineer を先に取得する 書籍や各社のブログ等で Google Cloud のデータ関係サービスの概要を理解する。特に以下のサービスに着目する BigQuery、Dataplex、Dataplex Universal Catalog、Cloud Storage、Dataflow、Pub/Sub、Cloud Composer、Bigtable、Dataproc、BigQuery ML 試験ガイドを読み、出題範囲を理解する 当記事を読み、出題傾向を理解する 把握した試験範囲・出題傾向をもとに勉強する 模擬試験を受け、足りない知識を認識して、ギャップを埋める勉強をする 試験ガイドや模擬試験へのリンクは、以下の公式ページから確認できます。 参考 : Professional Data Engineer 認定資格 出題傾向 当記事ではこれ以降、出題傾向や必要な知識を解説します。分からない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。 そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。 セキュリティとガバナンス 組織、IAM Identity and Access Management （IAM）の 継承 の概念や、リソースとの紐づけ、またリソース階層（組織、フォルダ、プロジェクト、各リソース...）の概念については確実に理解してください。以下の記事を参照してください。 blog.g-gen.co.jp また IAM と BigQuery の組み合わせの応用として、 承認されたビュー の使用方法も問われます。この機能については、以下の記事を参照してください。 blog.g-gen.co.jp 個人情報の扱い 個人識別情報 （PII）の扱いについては、頻出です。 PII を保存して必要なときには参照できるようにしておきたいが、適切な権限を持っている人以外は閲覧できないようにしたい、という場合、 Sensitive Data Protection （旧称 Cloud Data Loss Prevention、 Cloud DLP ）が活躍します。 元データに対して「削除」や「マスキング」を行って上書きすると当然、元のデータが失われてしまいます。一方で 暗号ベースのトークン化変換 という手法のうち フォーマット保持暗号化 や 確定的暗号化 を使うと、暗号鍵への権限さえあれば再度、元の値を復元できます。反対に 暗号ハッシュ化 をしてしまうと元の値に戻せない（不可逆）である点に注意してください。 参考 : 暗号ベースのトークン化変換 VPC Service Controls VPC Service Controls は、Google Cloud の API とデータを保護するための仕組みです。以下の記事を読んで、概要を把握してください。 blog.g-gen.co.jp VPC Service Controls の境界（perimeter）には、プロジェクトまたは VPC ネットワークを追加することができます。VPC ネットワークだけを追加しても、プロジェクトの API は保護されない点に注意してください。 BigQuery 基本的な知識 Google Cloud の誇るフルマネージドなデータウェアハウスである BigQuery は、当試験で最も出題されるプロダクトです。まずは以下の記事で、BigQuery の機能や用語を一通り理解してください。 blog.g-gen.co.jp blog.g-gen.co.jp BigQuery 以下のような概念を理解していれば、多くの問題に答えることができます。用語やドキュメントの暗記ではなく、概念として腹落ちするまで理解するようにしてください。 BigQuery の特質 列志向ストレージ 分散アーキテクチャ スロットと予約（Reservation） パーティショニングとクラスタリング 権限管理 IAM 承認済みビュー、承認済みデータセット BigQuery Sharing（旧称 Analytics Hub） 列レベルのアクセス制御、行レベルのセキュリティ バックアップとタイムトラベル ロケーション選択にてマルチリージョンを選択する意味 ストリーミングインサート（メリットとデメリット） 関連記事 上記の学習にあたっては、以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp blog.g-gen.co.jp 外部テーブルと BigLake テーブル BigQuery では、 外部テーブル を定義することで、Cloud Storage 上の CSV や Parquet といった形式のファイルに対して、リアルタイムにクエリを実行することができます。また、外部テーブルの発展版である BigLake テーブル への理解も必要です。 参考 : BigQueryを徹底解説！(応用編) - BigLake BigLake テーブルには メタデータキャッシュ 機能があり、パフォーマンス向上につながります。 参考 : 外部テーブルのメタデータのキャッシュ保存 データの共有 BigQuery Sharing（旧称 Analytics Hub）を使うと、少ない労力で他の組織に BigQuery データセットを安全に共有できます。アクセス制御を適切に行なったうえで共有でき、データのコピーは必要ありません。 参考 : BigQuery Sharing の概要 BigQuery Sharing（Analytics Hub）は、 限定公開リスティング を使うことで同じ組織内での共有に利用することもできます。 Cloud Storage 基本的な知識 Cloud Storage に関する問題も頻出です。以下の記事で、一通りの機能を把握してください。 blog.g-gen.co.jp 複数リージョンとターボレプリケーション Cloud Storage バケットの作成時に、バケットを配置するリージョンを単一リージョン、デュアルリージョン、マルチリージョンの3種類の中から選択可能です。これにより、データの可用性や堅牢性が向上します。ただし、リージョン間のデータレプリケーションは非同期で行われ、60分以上の遅延が発生する場合もあります。 データの RTO を短縮するには、 ターボレプリケーション の有効化が効果的です。有効化すると、追加料金と引き換えに15分以内でデータの複製が完了します。 参考 : データの可用性と耐久性 - ターボ レプリケーション Bigtable 基本的な知識 Bigtable は、Google Cloud のフルマネージドの NoSQL データベースです。どのようなアクセスユースケースで Bigtable を利用するのが望ましいのか、ユースケースを押さえておいてください。 以下の記事も参考にして下さい。 blog.g-gen.co.jp テーブル設計 スキーマ設計についてはドキュメントをよく読み込んでおき、特に大事な行キーの設計はよく理解しておきます。テーブル、列ファミリー、列、行、セル、行キーといった概念を理解してください。 基本的に、行キーにタイムスタンプを使うのはバッドプラクティスです。タイムスタンプは連続した値になってしまうので、データ格納先のストレージ位置が集中してしまい、 ホットスポット の原因となります。 machine_4223421#1425330757685 のように先頭にカーディナリティの高い ID などと組み合わせてキーとする手法が使われます。 参考 : スキーマ設計のベスト プラクティス 参考 : 時系列データ用のスキーマ設計 運用 モニタリング、本番用ワークロードと分析用ワークロードの分離（ アプリプロファイル ）、クラスタ拡張、 Key Visualizer など、管理運用面も把握しておきましょう。 参考 : アプリ プロファイルの概要 適切なデータベースの選択 Cloud SQL、Firestore（旧 Datastore）、Spanner、Bigtable、BigQuery など、Google Cloud には多用なデータベースサービスが存在しています。それぞれのユースケースや、できること、できないことを把握しておきましょう。どういったユースケースでどのデータベースを選ぶのかを回答できるようにする必要があります。 以下の表を参考にしてください。 名称 Cloud SQL Firestore Spanner Bigtable BigQuery 概要 マネージドRDB。MySQL / PostgreSQL / SQL Server が利用可能 NoSQL データベース。モバイルアプリからもよく利用される 無制限のスケーリング、グローバル利用が可能なリレーショナルデータベース NoSQL データベース。高スループット、高スケーラビリティ データウェアハウス。分析目的の列指向 DB ユースケース 一般的なアプリ。RDB Web、モバイル、ゲーム等で KVS がマッチする場合 金融、ヘルスケア、ゲーム等でグローバルなトランザクション 時系列データ、購入履歴、IoT 等。高スループット、高スケーラビリティが求められる SQL での分析や ELT 種類 RDB NoSQL（ドキュメント DB） RDB かつ分散アーキ NoSQL（ワイドカラム） データウェアハウス（表形式・列指向） クエリ方法 SQL API もしくは SQL ライク言語 SQL API SQL トランザクション ○ △ (※) ○ ✕ (1行のみ可) ✕ (※) Firestore と Datastore で仕様が違う Dataplex Dataplex による権限管理 Dataplex は、分散されたデータの統合・管理を自動化するためのサービスです。データの権限管理を簡素化し、 データメッシュ の構築を後押しします。プロダクトの詳細は、以下の記事で把握してください。 blog.g-gen.co.jp Dataplex では、BigQuery や Cloud Storage のデータへのアクセス権限の管理を行うことができます。具体的なアーキテクチャ等については、以下の記事も参考にしてください。 blog.g-gen.co.jp Dataplex Universal Catalog Dataplex Universal Catalog は、メタデータ管理のためのフルマネージドサービスです。BigQuery や Cloud Storage のデータのためのメタデータを管理し、データカタログを構築できます。かつて存在していた Data Catalog というプロダクトの後継プロダクトです。 以下の記事を参考にして、概要を把握してください。 blog.g-gen.co.jp Dataflow 概要 Dataflow は Apache Beam のマネージドサービスです。リアルタイム処理とバッチ処理の 両方を 扱うことができる点が特徴です。Dataflow はマネージドサービスであるため、自動的なスケールイン・スケールアウトなどにより、小さい運用負荷でデータ変換処理を実現できます。当試験においては、Dataflow は BigQuery に次いで最も出題数が多いプロダクトといえます。 以下の記事を読んで、Dataflow の概要を理解してください。 blog.g-gen.co.jp また以下のドキュメントを確認し、Apache Beam のプログラミングモデルについて概要を把握してください。 参考 : Programming model for Apache Beam ウインドウ Dataflow がストリーミングデータを扱う際に、データを分割してグルーピングする粒度として、 ウインドウ という設定を使用できます。 タンブリングウインドウ 、 ホッピングウインドウ （= スライディングウインドウ）、 セッションウインドウ の用語は押さえておきましょう。 参考 : Streaming pipelines - Windows and windowing functions exactly-once 例えば Pub/Sub から BigQuery へのデータ連携などでは、少なくとも1回（ at-least-once ）が原則である Pub/Sub からデータを受け取って、1回限り（ exactly-once ）の処理を実現できることも特徴です。 参考 : Exactly-once in Dataflow 融合（fusion） Dataflow は複数のワーカーを使って並列処理を行いますが、オペレーションの内容によっては自動的にジョブが最適化されて 融合 （fusion）が発生し、ジョブが少ないノードで実行されることがあります。場合によってはこれが非効率であり、実行時間が延びてしまうことがあります。 reshuffle を使うことで、融合を回避するようなテクニックもあります。 参考 : Dataflow pipeline best practices - Identify performance issues caused by fused steps ネットワークとファイアウォール Dataflow の VM ノード同士が通信するには、VPC ファイアウォールルールでノード同士の通信を許可する必要があります。 許可するポートはストリーミングジョブの場合は 12345/tcp 、バッチジョブの場合は 12346/tcp Dataflow VM ノード に付与されたネットワークタグでファイアウォールルールを作成する ネットワークタグはデフォルトで dataflow が付与される。カスタムネットワークタグの付与も可能 Dataflow の学習においては、上記のような、ネットワークとファイアウォールに関する知識も把握しておいてください。詳細は以下のドキュメントに記載されています。 参考 : Configure internet access and firewall rules データパイプライン Dataform Dataform は、BigQuery 用のフルマネージドのデータパイプラインサービスです。BigQuery に実行する SQL をワークフロー管理でき、スケジュール実行や、Git リポジトリとの連携も可能です。ワークフローは SQLX と呼ばれる SQL ベースの言語で記述するため、SQL の知識があれば学習コストが小さく済みます。 以下の記事も参考にして下さい。 blog.g-gen.co.jp なお Dataform では アサーション と呼ばれるテストコードを記述することで、データ品質を検証できます。アサーションでは、null 値のチェック、一意制約のチェックなどが可能です。 参考 : データ品質のテスト Pub/Sub 多くの問題文、または選択肢において、Dataflow とセットで Pub/Sub が扱われます。Apache Kafka を Pub/Sub で置き換えるという定番パターンも出題されます。 Pub/Sub の基本概念（トピックとサブスクリプション）、 デッドレタートピック 、Push サブスクリプションの 再試行ポリシー などについて理解を深めてください。 参考 : Pub/Sub サービスの概要 参考 : デッドレター トピック 参考 : サブスクリプション プロパティ - 再試行ポリシー Cloud Composer Google Cloud のサービスを活用してジョブオーケストレーションを行うには Cloud Composer が有用な選択肢です。 ジョブ実行ツールとしては他に、 Cloud Scheduler とサーバーレスサービスを組み合わせる方法などがありますが、Cloud Composer は DAG （有向非巡回グラフ）によるジョブの前後関係の管理や、モニタリング等の面で強みがあります。以下の記事も参照してください。 blog.g-gen.co.jp blog.g-gen.co.jp Dataproc Hadoop/Spark のマネージドサービスである Dataproc も頻出です。公式ドキュメントを確認し、クラスタ構成や管理運用方法について把握しておきましょう。 参考 : Dataproc の概要 Dataproc では基盤として Compute Engine VM が使われます。そのためパフォーマンス向上やコスト削減にあたっては、Compute Engine と同じ知識が使えます。例えば「ローカル SSD は永続ディスク（=ネットワークストレージ）よりもレイテンシが低い」であったり、「コスト効率を良くするために、セカンダリワーカーとして Spot VM（プリエンプティブル VM）が使用できる」などです。 また、オンプレミスの Spark / Hive 環境をクラウドに移行する際の移行先として、Dataproc が第1選択肢になります。 参考 : Apache Spark ジョブの Dataproc への移行 参考 : Dataproc での Apache Hive の使用 Dataprep、Cloud Data Fusion Dataprep と Cloud Data Fusion は、いずれもデータ抽出・変換パイプラインをノーコードで実装できるマネージドサービスです。GUI 上でワークフローを構築し、スケジュール実行できます。BigQuery などへのデータ挿入や、データ変換が可能です。ソースコードを書かずにデータパイプラインを実装したい場合のユースケースに適しています。 参考 : Google Cloud Dataprep by Trifacta クイック リファレンス 参考 : Cloud Data Fusion の概要 データ移行 オンプレミスからのデータ移行 データ移行というテーマも扱われます。オンプレミスから Google Cloud への大規模なデータ移行には、 Transfer Appliance という選択肢があります。Transfer Appliance は物理的なストレージデバイスです。Transfer Appliance にデータを転送して、Google に返送すれば、Google Cloud の Cloud Storage に速やかにデータを移行することができます。どのようなシチュエーションやどのくらいの規模のデータにこのサービスが適しているのかは頭の片隅に入れておきます。 参考 : Transfer Appliance また gcloud storage rsync （ gsutil rsync ）コマンドを使って手作業で Cloud Storage にデータ移行を行うこともありますし、Storage Transfer Service を使えば Cloud Storage へのデータ移行をジョブ化・自動化できます。 参考 : Cloud Storage とビッグデータの使用 参考 : Storage Transfer Service とは BigQuery Data Transfer Service と Storage Transfer Service の違いには注意してください。前者は外部から BigQuery へ データを転送する仕組みであり、後者は Cloud Storage へ データを転送する仕組みです。 データベース間のデータ移行 Datastream は、フルマネージドのデータ転送サービスです。データソースとして MySQL、PostgreSQL、Oracle などの RDBMS に対応しており、宛先としては BigQuery、Cloud Storage に対応しています。CDC（Change data capture）により、データの更新をリアルタイムにキャッチしてデータ転送を行うことができます。 参考 : Datastream の概要 Datastream を使い、オンプレミスのデータベースから専用線経由で BigQuery にデータを転送することもできます。データソースは Compute Engine VM でもよく、例えば VM にインストールされている Oracle Database から CDC でリアルタイムに BigQuery にデータを転送することが可能です。 機械学習（AI/ML） 当試験では、機械学習系の出題もあります。また Google Cloud 特有の知識というよりも、機械学習の一般的な用語や基礎知識について、ある程度の理解が必要です。 ラベリング、トレーニング、モデル、推論、回帰、分類（Classification）、クラスタリング、リコメンデーション、教師あり学習、教師なし学習、混同行列、過学習とのその対策、など基礎的な用語を押さえます。これらの用語の意味がわからない場合は、Web 検索や Gemini を活用して、浅くでもいいので理解しておきましょう。 また BigQuery ML も出題範囲です。使い方やある程度の仕組みは理解している必要があります。 参考 : BigQuery の AI と ML の概要 オペレーションスイート 基本 Cloud Monitoring の基本機能をしっかり理解しておきましょう。 blog.g-gen.co.jp 「Google の指標」のリファレンスページで、Compute Engine や Pub/Sub、Cloud Storage など、データエンジニアリングにおいて重要なサービス群のメトリクスは、簡単でいいので眺めておくことが望ましいです。 参考 : Google Cloud metrics overview 注目すべきメトリクス 「Pub/Sub からデータを読み取って、Cloud Storage にデータを書き込むデータパイプライン」があるとして、これを Cloud Monitoring で監視するときにどうするか、などのシチュエーションを想像してください。 Pub/Sub のメトリクスのうち subscription/num_undelivered_messages が上昇していると「処理の遅延等が起きている」とみなせるはずです。 また BigQuery には slots/allocated_for_project といったメトリクスがあります。プロジェクトごとに割り当てられたスロット数が確認できるため、複数の部署で BigQuery を使っているときにどの部署がスロットを多く消費しているのか、などが確認できます。 その他 受験環境 当社メンバーの受験環境に関する実体験が以下の記事で紹介されています。ぜひご参照ください。 blog.g-gen.co.jp blog.g-gen.co.jp 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

みなさんこんにちは。G-genの鈴木ことすずたつです。 私はG-genに9月にJoinして、日々優秀な技術者とともに学ばせていただいて、11月2日にProfessional Cloud Architectの試験に合格させていただきました。 ※Associate Cloud Engineerに関しては10月の頭に合格させていただいたので、その話はまた別の機会にでもブログ書いてみたいと思います。 今回は、受験記ではなくいまこのコロナの時期だからこそ有効活用したい遠隔試験に関して少し話してみようと思います。 Google Cloudの遠隔試験とは？ 遠隔試験の要件と実際の環境 最初に受験しようとしていた環境 実際の受験環境 事前の予約 当日の流れ その他 眼鏡 外付けのWebカメラ 後日、Professional Collaboration Engineerを受験しました。 Google Cloudの遠隔試験とは？ Google Cloudでは以下にありますように、様々な試験を提供しています。 Google Cloud 認定資格 そして、その試験がなんと 家から受験できてしまう のです！ 現時点(2021年11月4日時点)では、日本語対応している以下のすべての試験が 遠隔での受験が可能 です。 Google Cloud Certified - Cloud Digital Leader (Japanese) Google Cloud Certified - Associate Cloud Engineer (Japanese) Google Cloud Certified - Professional Cloud Architect (Japanese) Google Cloud Certified - Professional Cloud Developer (Japanese) Google Cloud Certified - Professional Collaboration Engineer (Japanese) Google Cloud Certified - Professional Data Engineer (Japanese) コロナが落ち着いてきたとはいえ、リモートで受験できるのはとても便利ですので、ぜひ活用しましょう。 遠隔試験の要件と実際の環境 実際に公式にアナウンスされている要件は以下の通りになります。 Exam Procedures 私の場合は、あまり家も大きくないので、、、どこで受験しようかと、実は試験開始30分前まで悩み、最後の最後で変更しました(汗) 最初に受験しようとしていた環境 最初は、机の上に何も無ければよいだろう！と考え、リビングのテーブルで受けようと考えておりました。 ※簡単な環境は以下の絵を参考にしてください。 家の間取りと受験しようとしていた場所 ただ、キッチンにはものがあったり、近くにテレビがあったりと、これはつっこまれるか？？と思い、試験30分前に子供部屋を利用することを決意。(実はこの時夜の23時30分) 実際の受験環境 結果として以下の環境で受験を決意！ 最終的に受験した場所 結果からいうとこの場所で子供のおもちゃたちに見守られながら受験して事なきを得ました。それでは次より、事前準備(予約)や当日の流れを説明してゆきます。 ちなみにPCは普通のWindowsのプライベート端末に外付けカメラをセットしたものになります。 事前の予約 基本的に、予約は通常の方法と何ら代わりありません。以下のKryterionのサイトから通常通り申込みしましょう。 準備ができたら ただ、注意なのが日時と時間です。Professional Cloud Architectは人気の試験なのか、結構受けたい日の枠が空いておらず、悩みに悩んだ末に 11月2日00:00AM での受験を決意。 みなさま、00:00AMって、真っ昼間なのか、夜中なのかすぐにわかりますか？ 鈴木は実は昨年、子供の運動会が終わったあとの、お昼にマクドナルドが来るように予約してたら、夜中に来てしまった。という体験があるため一瞬で判別可能でした。(どこでどういう経験が活きるかわかりませんね)。 そう。11月2日00:00AMというのは11月1日のお仕事が終わって、夕飯食べおわって、お風呂に入ったあとの夜中です！お間違えないよう！ 他にも、海外から監視だからなのか3:00AMとか、日本だと普通は 寝ている時間でも受験が可能 なので、予約時間は間違わないように注意しましょう。 予約が完了しましたら、以下の画面の右側にSentinelのインストール、というボタンと、生体認証用の顔写真登録。というボタンがでますので、2つとも試験前までに済ませておきましょう。 Kryterionの画面 当日の流れ 当日は10分前になった時点で、予約画面の？の印が”受験する”というボタンに変わります。ボタンをクリックするとSentinelが自動的に立ち上がります。 ただこの時、どうやらチェックする側の方が混雑してたっぽく、数分間待つことに。 画面は「この画面を切らないでくださいね。混雑してるので最大15分待ってもらうかもしれません。」のようなメッセージが画面に表示されていました。 やっとのことで接続されると。はじめは簡単な説明があった上で、パスポート等をカメラに近づけてよく見えるように映してください。という指示があり、OKだとチャットボックスが立ち上がります。 どきどきしながら英語のゴリゴリの外人の方がへろー！とか言ってくるのかと思ったら、画面左にチャット、右側にカメラ。というウィンドウが立ち上がり、チャットボックスに「ではチェックを開始します。まずは壁四面、天井、床をカメラで映してください。各部分5秒程度静止してください」のような メッセージが日本語で表示 され、それに従って映すような形になります。 ただ、ここで注意なのが、 リアルタイムですぐになにかリアクションしてくれるわけではなく 、全部確認してOKだったら次の指示。のような形なので、何もリアクションが無いままで「右の壁5秒、左の壁5秒、前、後ろ、天井、足元、、、最後に自分。。。これであってるのかな？」という状況で、数秒たつと。「では次に、机の上を映してください」、「次は携帯のカメラ、もしくは手鏡をつかって、PCのディスプレイを映してください。」、「ありがとうございます！パスポート、携帯をどこかにおいてください！」と来て、(どこにおけば・・・)、と思いつつも部屋の隅っこのおもちゃたちの中へぽいっ。と。 こういった一連の流れが終わると「これでOKです！それでは試験を開始します！この時間は試験時間に含まれませんのでご安心ください！」というメッセージが表示され、試験が開始されます。 ただ、数十秒(体感的には1分くらい？)のあいだ試験開始ボタンが表示されなかったため、「え？？どうやって試験開始するの？？？」と思ってしまいましたが、無事にボタンが出現し試験開始となりました。 あとはいつもの試験と同じで、合意の画面があって、試験があり、アンケートあり、結果。という流れで進みます。 (試験終了した時点で夜中の1時30分すぎでした・・・) 合格もそうですが、実は始めての遠隔体験だったため、30分前に場所を変えたり、バタバタしたりでなんだか日程さえ合えば行った方が良かったんじゃないかとも少し思ってしまいましたが、、、 今後のためにもいい経験ができました。 その他 眼鏡 生体認証(自分の顔写真を撮って送付)のときも、実際のときも自分の顔を送付。というのはあることはわかってたのですが、このときのインストラクションで メガネも外してください という説明があり、メガネを外すと0.01レベルの鈴木は 撮影ボタンが見えない！ という状況だったので、眼鏡くらいは許してほしいな。。。と思いました。 外付けのWebカメラ 私は幸いにもUSBの外付けのWebカメラを持っていたため、そちらを当日は利用しました。チェックリスト的には内蔵のカメラでもOKなのですが、机の下を映したり、あちこち映したりするので、内蔵だと正直厳しいのではないか。。。と思っております。 後日、Professional Collaboration Engineerを受験しました。 後日談ですが、Professional Collaboration Engineerを受験しました。(結果は別のブログで・・・) 2度目のリモート受験なので、落ち着いて、ある意味チャレンジを。と思い、以下のような環境で受験しました。 結論からいうと問題なく、試験監にいくつか指摘されましたが、 手の届くところにものがない というのが条件のようです。手の届くところにいろいろあるじゃないか！というツッコミはご容赦ください。 ※試験に必要なパスポートを「そこに置いてある赤いノートを片付けなさい！と突っ込まれたときは・・・と思いましたが。。。」 デスクまわりの写真 これから寒い時期にもなりますし、遠隔受験をうまく活用して、いいGoogle Cloudライフを送りましょう！ Professional Cloud Architect 鈴木 達文 (記事一覧) 執行役員 COO ビジネス推進部 部長 基本、なんでも屋。主にビジネスの立ち上げや仕組みづくりが好き 日々、努力。日々、楽しむことを大事に 　 Professional Cloud Architect / Professional Workspace Administratorのみ保持していますがそろそろ失効してしまいそうな予感。

G-gen の杉村です。 Professional Cloud Architect 試験 は、 Associate Cloud Engineer 試験の上位に位置する Google Cloud (旧称 GCP) の難関認定資格です。本投稿では試験の合格に役立つ、勉強方法や出題傾向などについて解説します。 はじめに Professional Cloud Architect 試験 とは 難易度 推奨の勉強法 ケーススタディ 出題傾向 更新試験 組織と IAM 組織のポリシー IAM の基本概念 オペレーションスイート Cloud Monitoring Cloud Logging セキュリティ・統制 Network Intelligence Center Sensitive Data Protection Google Kubernetes Engine（GKE） 基本概念 モニタリング 安全なデプロイ GKE からの Google API への認証 データベース・分析 データ分析プラットフォームの選択 Cloud SQL Cloud Storage コンピュートサービス 概要 App Engine CI/CD 概要 コンテナセキュリティ VPC / ネットワーク VPC の基本 ネットワークセキュリティ 接続性 概要 VPC 間の推移的通信 ハイブリッドネットワーク 可用性 SLA Compute Engine Compute Engine の基本 マネージドインスタンスグループ リージョン永続ディスクを利用した可用性向上 ライセンスの持ち込み その他 その他のプロダクト はじめに Professional Cloud Architect 試験 とは Professional Cloud Architect は、Associate Cloud Engineer 試験の上位に位置する Google Cloud の認定資格です。 IT インフラやアプリケーション開発に関係する Google Cloud サービスの知識のみならず、データ分析、セキュリティ、モニタリングなど幅広い知識が求められます。この試験に合格していることは、Google Cloud を幅広く理解しており、一人前の Google Cloud 技術者である証左だといっても過言ではないでしょう。 試験時間は 120 分、試験問題数は 50〜60 問です。試験は日本語と英語で提供されています。 参考 : Professional Cloud Architect ‐ Google Cloud 可能であれば、当試験より先に Associate Cloud Engineer 試験に合格しておくことが望ましいですが、受験にあたり必須要件ではありません。Associate Cloud Engineer 試験については以下の記事もご参照ください。 blog.g-gen.co.jp 難易度 当試験の難易度としては 中程度 だと言えます。 IPA の「応用情報技術者試験」程度の基本的な IT 知識があり、かつ Google Cloud をある程度業務で使用した経験があるというのが前提知識として理想的です。試験ガイドでは「3年以上の業界での経験と、1年以上の Google Cloud における経験」が推奨だと記載されていますが、必ずしもこれを満たしていなくても十分合格が狙える資格です。 むしろ普段から Google Cloud の公式ブログやドキュメントのベストプラクティスに目を通し、Google の考えるクラウドらしいクラウドの使い方が何か、という一種の クラウドの哲学 を頭にインプットしておくことが重要です。選択肢に迷った時に、 最もクラウドらしい選択肢はどれか という思考が助けになります。 これらに加えて、当記事で追加の学習をすれば、合格は難しくないと言えます。 特に Amazon Web Services（AWS）の試験を受けたことがある人であれば気が付きますが、問題文の長さや複雑さは AWS Certified Solutions Architect - Professional 認定のそれと比較すると、短くてシンプルであると感じられます。体感的案難易度は AWS の Professional 試験より低いかもしれません。 推奨の勉強法 Associate Cloud Engineer を先に取得する 試験ガイド を読んで出題範囲を理解する 当記事を読み、出題傾向を理解する 把握した試験範囲・出題傾向をもとに勉強する 模擬試験 を受け、足りない知識を認識して、ギャップを埋める勉強をする ケーススタディ を直前に確認する ドキュメントを読むだけでは理解が進まないサービスも出てきます。こういったときは「書籍を読む」「ブログ記事を検索して読む」「コンソール画面や gcloud で実際に触ってみる」の3つを織り交ぜて学習を進めるのがおすすめです。 特に3つめの「 実際に触れる 」は重要です。コンソールやコマンドラインを触ると、Google Cloud プロダクトの リソース構成 が手にとるように分かり、理解が進みます。リソース構成を把握してからドキュメントに戻ると、理解度が全く違うことがあります。 ケーススタディ Professional 試験では ケーススタディ と呼ばれる、架空の会社をテーマにしたクラウド導入事例が引用されます。 参考 : Professional Cloud Architect Exam Guide | Japanese 試験中は画面の右半分にケーススタディの内容が表示されるため、内容を覚えておく必要はありませんが、事前に目を通しておきましょう。どんな本番環境でも要求されるような基本的な要件も多く書かれていますが、そのケースで大事にしている（優先すべき）要件に注意しましょう。例えば「コスト vs 全世界からのレイテンシ」というトレードオフからどちらかを選択しなくてはいけない場合、ケーススタディに書かれているビジネス要件や技術要件がヒントになります。 出題傾向 出題範囲のサービスは、Associate Cloud Engineer 試験対策記事に記載されているものと、大半が重複していますので、そちらの記事をご参照ください。 参考 : Associate Cloud Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog 出題範囲は幅広く、多様なサービスを広く理解している必要があります。 当記事ではこれ以降、どのような試験問題が出るか、出題傾向とその内容を解説していきます。公式ドキュメントへのリンク等もできるだけ付記していますので、知らない用語や理解の浅い概念があれば、ドキュメントを読んだり、実際にサービスに触れる等の対策を行ってください。 更新試験 Professional Cloud Architect 試験には、一度合格して更新時期を迎えた人向けの 更新試験 も用意されています。 更新試験は英語と日本語で提供されており、問題数は通常試験の約半分の25問、試験時間は半分の1時間です。また受験費用は、通常料金の半額の $100 です。 更新試験は通常試験とは出題範囲が異なっており、ケーススタディの内容も、生成 AI ソリューションをテーマとしたものになっています。ケーススタディに関する問題が全体の90%〜100%を占めているとされており、ほとんどが生成 AI 関連の問題と考えられます。最新情報は、公式の更新認定試験ガイドを参照してください。 参考 : Professional Cloud Architect 更新認定試験ガイド 組織と IAM 組織のポリシー 組織のポリシーでは、さまざまな制約を組織全体に課すことができます。 ここでの設定は IAM での許可よりも優先されます。組織のポリシーでどんなことができるのか、もちろんすべて覚える必要はありませんが、組織に統制を効かせる際にどのようなポリシーが使われるだろうかと想像しながら以下のドキュメントを確認するとよいでしょう。 参考 : 組織のポリシーの制約 例えば以下のようなポリシーに注目して、意義や使い方（パラメータに何を設定するか）を事前に理解しておいてください。 特定リージョンしか使えないようにする ( constraints/gcp.resourceLocations ) 外部 IP アドレスを持つことができる Compute Engine VM をホワイトリスト式で制限する ( constraints/compute.vmExternalIpAccess ) 外部組織の Google アカウントが IAM 権限を持てないようにする ( constraints/iam.allowedPolicyMemberDomains ) 以下の記事も参照してください。 blog.g-gen.co.jp IAM の基本概念 Google Cloud の Identity and Access Management （IAM）は、 リソースが持つポリシーが中心 の概念であること、また 継承 が起きるということを正しく理解してください。IAM の概念については、以下の記事も参考にしてください。 blog.g-gen.co.jp Associate 試験と同様に基本的な概念をしっかり理解しておけば解ける問題ばかりです。 また試験問題で「こういうシチュエーションを改善するにはどうするか」と問われるとき、 最小権限の原則 を意識して改善策を考えてください。オーナーなどの強いロールは極力使わない方向にするべきですし、使う場合は組織全体に対して付与するのではなく、フォルダなどを使って適用範囲を制限します。 また、 サービスアカウント の使い方は理解しておいてください。サービスアカウントは、人間ではなく プログラムや Google Cloud サービスが使うアカウント です。サービスアカウントに権限を与える際は、人のアカウントと同様に、最小権限の原則に従うべきです。 選択肢に安易に「組織の管理者を付与する」「オーナー権限を付与する」などがあれば、誤った選択肢である可能性が高いと言えます。 また個人のアカウントに個別に IAM 権限を付与することなく、グループに対して付与することで、運用工数を削減することができます。 参考 : IAM を安全に使用する オペレーションスイート Cloud Monitoring Cloud Monitoring の基本機能（Google Cloud の指標、 Ops エージェントの指標、カスタム指標、ダッシュボード等）を理解してください。 blog.g-gen.co.jp Cloud Monitoring にはリソースのモニタリングやアラートの発報などの機能のほか、簡易的なインシデント管理の機能もあります。ドキュメント中心で構わないので、理解をしておく必要があります。 また Google Kubernetes Engine（GKE）でも Cloud Monitoring を使ったモニタリングが活躍します。こちらも確認しておくとよいでしょう。 Cloud Logging Cloud Logging の シンク （ログルーター）の仕様や用途をしっかり押さえておきましょう。シンクからどのサービスにログをエクスポートできるのか、どんなアクションに繋げられるのか、という点が重要です。また 集約シンク を使うことで、組織配下の全プロジェクトや、特定フォルダ配下の複数のプロジェクトのログを容易に集約し、監査用プロジェクトに保存することもできます。 参考 : ログエントリを転送する Compute Engine VM に Ops Agent をインストールすれば、VM 上のアプリケーションログを簡単に Cloud Logging に送信し、ログシンクを使って BigQuery や Cloud Storage へログを転送、保存することができます。 参考 : Ops エージェントの概要 また Cloud Logging からログをフィルタしたうえで Pub/Sub へ送信すれば、特定のログ発生をトリガにしてイベントドリブンで Cloud Run functions を起動することもできます。こういった文面を読んだ時に、構成図が思い浮かぶくらいに理解しておきましょう。 Cloud Logging 全体の概要については以下の記事をご参照ください。 blog.g-gen.co.jp セキュリティ・統制 Network Intelligence Center Network Intelligence Center は Google Cloud のネットワーク関連の可視性を提供したり、モニタリングやトラブルシューティングに役立つサービスです。以下の記事を読んで、どのような機能があるのかを確認しておきましょう。 blog.g-gen.co.jp ファイアウォールインサイト機能に注目です。これは、自動的に VPC のファイアウォールログをチェックしてルールの棚卸し等に役立つ機能です。 なお VPC のファイアウォールログは、 ファイアウォールルールごとに明示的に有効化 する必要がある点に注意しましょう。ファイアウォールのログを有効化しないと、ファイアウォールインサイト機能も動作せず、いつまで待っても検知事項がゼロのままです。 Sensitive Data Protection Sensitive Data Protection （旧称 Cloud Data Loss Prevention、Cloud DLP）で何ができるかを確認しておきましょう。また、スキャン結果はどこにどのように配置したり応用したりできるかが重要になってきます。 参考 : Sensitive Data Protection overview データ処理パイプライン中で Sensitive Data Protection を使って PII（個人識別情報）を検知することで、PII を削除してからデータを保存するユースケースなどが挙げられます。 また、Sensitive Data Protection の検査結果はデータに対するメタデータとして、Dataplex Universal Data Catalog に保存できます。 Google Kubernetes Engine（GKE） 基本概念 Professional Cloud Architect 試験では Google Kubernetes Engine（GKE）だけでなく Kubernetes の全般知識が求められる問題もあります。 Pod、Deployment、Service、Ingress、Namespace、Cluster、Istio、サーキットブレイク、マイクロサービスなどの単語や概念の理解を進めましょう。 GKE や Kubernetes については以下の記事も参考にしてください。 blog.g-gen.co.jp blog.g-gen.co.jp モニタリング GKE はネイティブに Cloud Monitoring や Cloud Logging と統合されています。この統合機能は Cloud Operations for GKE と呼ばれています。 参考 : GKE のオブザーバビリティ GKE クラスタで Managed Service for Prometheus を有効化することもできます。新規クラスタのみならず、既存クラスタでも有効化が可能です。 参考 : Google Cloud Managed Service for Prometheus 安全なデプロイ readiness probe と liveness probe を設定しておくと、Pod が更新された際などに、正常でない Pod にトラフィックがルーティングされてしまい、サービスに影響が出ることを防ぐことができます。 参考 : コストが最適化された Kubernetes アプリケーションを GKE で実行するためのベスト プラクティス - アプリケーションに有用な readiness probe と liveness probe を設定する GKE からの Google API への認証 GKE で実行されているアプリケーションから Google Cloud サービスへアクセスする際の推奨事項を確認しておきましょう。 GKE から Google Cloud API への認証方法の最初の選択肢は Workload Identity 機能です。これは Kubernetes のサービスアカウントと Google Cloud のサービスアカウントを紐づける機能です。GKE コンテナからすると Kubernetes サービスアカウントのみを意識すれば良いため Kubernetes リソースと Google Cloud リソースが疎結合になり、保守性が向上します。 参考 : GKE ワークロードから Google Cloud API に対する認証を行う データベース・分析 データ分析プラットフォームの選択 Google Cloud のデータ分析系サービスは多数ありますが、それぞれをどんなユースケースのときに選択するのか、押さえておきましょう。Cloud SQL、Datastore（Firestore）、Bigtable、Spanner、BigQuery の特性を、それぞれ自分の言葉で説明できるでしょうか？ 運用管理の知識を問われたときの備えて、それぞれのデータベースのバックアップ方法なども抑えておきましょう。 以下の記事の「その他のデータベース・移行」の項にて、データベースごとのユースケースを書いていますのでご参照ください。 参考 : Professional Data Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog - データベースの選択 例えば Bigtable は高スループットが出るデータベースです。IoT やアプリケーションのトラッキングのような秒間数万の書き込みリクエストがあるような場合に適しています。一方で標準的な SQL には対応していないため、 SQL での操作が必要な場合や、トランザクション処理が必要な場合には Cloud SQL や Spanner を検討することになります。 Firebase はサーバーレスでリクエスト数に応じた従量課金であるため、あまりワークロードが多くないシステムにおいてコストを重視する場合などに選択できます。 各種データベースサービスについて、以下の記事も参考にしてください。 参考 : Cloud SQLを徹底解説！ - G-gen Tech Blog 参考 : Cloud Spanner を徹底解説！ - G-gen Tech Blog 参考 : BigQueryを徹底解説！(基本編) - G-gen Tech Blog 参考 : Bigtableを徹底解説！ - G-gen Tech Blog 参考 : Firebaseを徹底解説！ - G-gen Tech Blog 参考 : AlloyDB for PostgreSQLを徹底解説！ - G-gen Tech Blog Cloud SQL オンプレミスからのデータベース（RDB）の移行先としては Cloud SQL が選択されることが多いはずです。どのような手法で移行ができるかを理解しておきましょう。 また、バックアップとリストアの方法や冗長化の方法など、可用性に関する内容は自信をもって設計・実装できるくらいに把握しておきます。 自動バックアップ機能に加え、トランザクションログの保存日数指定などが行える点を押さえておきます。また「ポイントインタイムリカバリ（PITR）機能」を用いるには、自動バックアップとポイントインタイムリカバリを 両方有効にする 必要があります。 PITR により、データベースを特定時刻の状態で復旧することができます。ただし、元のインスタンスとは別インスタンスとして構築されることになります。 以下の記事を参考にして、Cloud SQL の仕様を一通り理解しましょう。 blog.g-gen.co.jp Cloud Storage Cloud Storageの基本的な仕様や概念は Associate 試験で押さえているはずです。さらに以下のようなポイントを押さえて、応用的な使い方を理解しましょう。 IAM によるアクセス制御 オブジェクトのバージョニング 保持ポリシーと保持ポリシーのロック ストレージクラス（Standard、Nearline、Coldline、Archive） 以下の記事で Cloud Storage の一通りの仕様を解説していますので、ご参照ください。 blog.g-gen.co.jp コンピュートサービス 概要 Google Cloud のコンピュートサービスである Compute Engine、Cloud Run、Cloud Run functions、App Engine について、各プロダクトのアーキテクチャ、用法、運用管理、デプロイ、スケーリングなどの特徴を理解する必要があります。 どのようなときにどのプロダクトを選択するのか？それぞれのプロダクトの強みは何か？ や可用性を高める方法は？ コストを最適化するには？ 安全にアプリケーションの新バージョンをデプロイして移行する方法は？ 例えば Cloud Run では、 新旧バージョン間でトラフィックを徐々に移行 することができます。割合を指定することで、「新バージョンに10%、旧バージョンに90%のトラフィックをルーティング」「問題ないことがわかったら、徐々に%を変えていく」といった運用が可能です。 参考 : ロールバック、段階的なロールアウト、トラフィックの移行 また「静的ファイルは Cloud Storage に配置。軽量なバックエンド API は Cloud Run functions で実装。フロントには Cloud Load Balancing を置く」といった クラウドネイティブなアーキテクチャ は可用性・コスト効率が高いことも理解しましょう。 このように、プロダクトの特性を活かしたアーキテクチャやデプロイ方法などが問われます。 以下の記事も参考にしてください。 blog.g-gen.co.jp App Engine App Engine では、運用工数が低い スタンダード 環境と、より詳細なカスタマイズができる フレキシブル 環境が選択できます。 デプロイの容易さや運用性を優先する場合で、開発言語が Java、Node.js、Go など、スタンダード環境に対応しているプログラミング言語である場合は、スタンダードが選択肢になります。 参考 : App Engine 環境を選択する また、App Engine には新バージョンをデプロイする際、まずは別の URL へ新バージョンをデプロイして、テスト完了後に任意のタイミングで本番昇格する機能もあります。 参考 : アプリケーションをテストしてデプロイする - トラフィック移行前の App Engine でのテスト また、App Engine のフレキシブル環境は VPC ネットワーク上の Compute Engine VM で実行される一方、スタンダード環境は VPC 外 で実行されている点に注意が必要です。スタンダード環境の App Engine アプリケーションから VPC リソースや、VPC ネットワークと VPN や専用線で接続されているオンプレミス環境のリソースにアクセスするには、 サーバーレス VPC アクセス を設定する必要があります。 参考 : App Engine 環境を選択する 参考 : VPC ネットワークへの接続 CI/CD 概要 Google Cloud サービスを使って CI/CD パイプラインを構築するにはどのサービスを使うか、理解しておきます。また、各コンピューティングサービスへのアプリケーションデプロイの方法を押さえます。Google Cloud プロダクトで実装する CI/CD では、 Cloud Build が重要です。 Cloud Build はそのサービス名称からするとビルド専用のサービスにも思えますが、実際には GKE、Cloud Run、App Engine、Cloud Run functions などへのデプロイ自動化にも使われます。 Git などのソースコードレポジトリの特定のブランチに、ソースコードがコミットされたことを検知して Cloud Build が動き出し、アプリケーションやコンテナのビルドやテストが実行され、その後 GKE などにデプロイする、という一連の流れが基本です。 参考 : Google Cloud 上での DevOps と CI / CD について コンテナセキュリティ Binary Authorization というサービスでは、Google Kubernetes Engine（GKE）や Cloud Run で「署名済みのコンテナイメージ」以外はデプロイできないようにする機能があります。これにより、検査されたセキュアなイメージ以外のデプロイを防ぐことができます。 参考 : Binary Authorization の概要 VPC / ネットワーク VPC の基本 以下の2記事を参考に、 Virtual Private Cloud （VPC）の基本は改めておさらいしておきましょう。 Google Cloud(旧GCP)のVPC基本機能を学ぶ！VPC・サブネット・NAT・ピアリング・AWSとの違い - G-gen Tech Blog Google CloudのVPCを徹底解説！(基本編) - G-gen Tech Blog VPC に対して、Associate Cloud Engineer 試験と同等以上のレベルの理解は必要です。Associate Cloud Engineer 試験対策記事の VPC に関する記述も、改めて参考にしてください。 参考 : Associate Cloud Engineer試験対策マニュアル。出題傾向・勉強方法 - G-gen Tech Blog ‐ VPC ネットワークセキュリティ VPC ファイアウォールの基本的な仕様は、Associate 試験と同様に必須です。 また Cloud Armor の基本概念や、実装方法（Google Cloud コンソールおよび gcloud コマンドライン）も押さえておきましょう。 参考 : Cloud Armor セキュリティ ポリシーを構成する Cloud Armor はフルマネージドの WAF サービスです。L7 レベルの攻撃を防ぐ機能に加え、接続元 IP アドレスを制限することもできます。Fastly などの CDN からのトラフィックは許可できるよう、名前付き IP アドレスリストも用意されています。Fastly で言えば sourceiplist-fastly というようなリスト名です。 Cloud Armor の基本は以下の記事で把握することができます。 blog.g-gen.co.jp 接続性 概要 異なる VPC ネットワークに存在する VM 同士で通信するにはどうすればいいか、といった応用的な方法を理解しておきます。以下のそれぞれの特徴を理解してください。 VPC 間で VPC ネットワークピアリングを接続する VPC 間で Cloud VPN を使って接続する 複数の VPC の NIC を VM に追加する VPC ネットワークピアリング を使うと、異なる VPC ネットワーク間を接続できます。利用料金がかからず、最もコスト効率の良い方法です。VPC ネットワーク同士が異なるプロジェクトや 異なる組織 に所属していても、VPC ネットワークピアリングを使うことができます。 参考 : VPC ネットワーク ピアリング VPC 間の推移的通信 VPC ネットワークピアリングで2つの VPC ネットワークを接続すると、自動的にルートが交換され、相互に通信できるようになります。ただし以下のような場合、 VPC A と VPC C 同士は通信できません。 VPC A ===(Peering)=== VPC B ===(Peering)=== VPC C VPC A と C は直接繋がっていないので、お互いに通信できません。この特性を「VPC ネットワークピアリングでは、推移的な接続はできない」と表現します。俗にこれを「2ホップ制限」と呼ぶこともあります。 ただし、この構成を VPC ネットワークピアリングではなく Cloud VPN で構成すれば、適切なルート交換を設定する前提で、推移的な通信が可能です。 ハイブリッドネットワーク オンプレミスネットワークと VPC ネットワークを接続するための様々な方法を理解しておきましょう。 Google Cloud には、 Dedicated Interconnect 、 Partner Interconnect 、 ダイレクトピアリング 、 キャリアピアリング と呼ばれる4つのライベート接続方法があり、それぞれユースケースが異なります。 細かい設定までは理解する必要はありませんが、 どのようなときにどれを選ぶか を理解しておきましょう。 オンプレミスから Google Cloud の VPC ネットワークへプライベート接続を確立するためには、Dedicated Interconnect（専有型専用線）または Partner Interconnect（共有型専用線）を選択します。これらの専用線サービスを使うことで、Cloud VPN に比べて、安定した帯域とレイテンシを確保できます。 一方で、Google Workspace 等の Google サービスに接続したいときに ダイレクト ピアリング（専有型専用線）やキャリアピアリング（共有型専用線）を選択します。 専有型か共有型かという観点では、自社・データセンター等から Google の PoP（Point of Presence）に直接接続できる場合であり、かつ安定的で広い帯域が求められる場合に、専有型である Dedicated Interconnect / ダイレクトピアリングを選択します。一方でコストが重視される場合は、共有型である Partner Interconnect / キャリアピアリングを選択します。 参考 : Network Connectivity プロダクトの選択 可用性 SLA Cloud VPN や Cloud Interconnect の可用性についても理解しておきます。 Cloud VPN で言えば、99.99% の可用性 SLA が適用されるには、以下の構成である必要があります。 1台の HA VPN ゲートウェイを、2台のピアデバイスに接続（トンネル数は2） 1台の HA VPN ゲートウェイを、外部 IP アドレスを2つ持つ1台のピアデバイスに接続（トンネル数は2） 1台の HA VPN ゲートウェイを、1つの外部 IP アドレスを持つ1台のピアデバイスに接続（トンネル数は2） つまり、トンネルが2つ確立されていれば、オンプレ側のルータが1台でも、99.99%の 可用性 SLA の対象になります 。ただし HA VPN ゲートウェイ側は、2つのインターフェイスを使用する必要があります。 以下のドキュメントを参照し、構成を理解しておいてください。 参考 : HA VPN トポロジ - 99.99% の可用性 SLA 用に構成する 参考 : Dedicated Interconnect で 99.99% の可用性を実現する Compute Engine Compute Engine の基本 Compute Engine の基本的な仕様は、Associate 試験と同様です。さらに、運用にあたり重要となる応用的な概念を加えて理解しておきましょう。 blog.g-gen.co.jp マネージドインスタンスグループ マネージドインスタンスグループ（MIG）におけるインスタンスのアップデートの仕様が問われることがあります。 MIG でインスタンスを更新するとき、方法が「自動更新（Automatic または proactive）」「選択（selective または opportunistic）」の二種類があります。前者はインスタンスの更新が自動的にされます。後者は手動で命令したときや新インスタンスが作成されたときにのみ更新されます。日中の稼働が激しいシステムなどでは、自動更新（proactive 更新）はリスクが大きいため、避けることを検討します。 参考 : MIG で VM 構成の更新を自動的に適用する ‐ タイプの更新 リージョン永続ディスクを利用した可用性向上 リージョン永続ディスク は、Compute Engine VM にアタッチ可能な永続ディスクです。通常の永続ディスクがゾーンリソースなのに対して、リージョン永続ディスクはリージョンリソースです。ある片方のゾーンで障害が発生しても、データは別のゾーンに複製されます。 Compute Engine VM を複数のゾーンにデプロイし、現用系と待機系のアクティブ/スタンバイ構成を取っている場合、現用系のゾーンが停止しても、リージョン永続ディスクであれば待機系の VM に 強制アタッチ できます。これにより、可用性の高い構成を実現できます。 参考 : ディスクの同期レプリケーションについて 参考 : 同期的に複製されたディスクを使用して HA サービスを構築する ライセンスの持ち込み Windows Server のライセンスは、一定条件下で Google Cloud に持ち込む（BYOL）ことができます。以下のドキュメントを参考に、一連の流れを把握してください。 参考 : お客様所有ライセンスの使 ライセンスの持ち込みには、オンプレミスの仮想マシンの、仮想ディスクファイルを Compute Engine にインポートし、イメージを作成します。また、デプロイ先の Compute Engine は、物理的に専有された 単一テナントノード である必要があります。 その他 以下のような細かい仕様を押さえておいてください。 Cloud IAP Linux VM での起動スクリプトの使用 オーバープロビジョニング（CPU やメモリが過剰にアサインされている VM）に対して推奨事項を表示する方法 Spot VM その他のプロダクト 以下のようなサービスも出題範囲となっています。細かい使い方まで分かれば理想的ですが、業務で使ったことがなければ、最低でも「どのようなサービスか」「どのようなときに、どのように利用されるのか」などを押さえておきましょう。 Migrate for Compute Engine ランブック という言葉を把握しておく Cloud Memorystore Cloud Filestore Fire store ではなく File store 選択可能な Service Tier を把握し、ユースケースやスループット上の限界値を確認しておく Cloud Scheduler Anthos Service Mesh / Anthos Config Management Dataproc 杉村 勇馬 (記事一覧) 執行役員 CTO 元警察官という経歴を持つ IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 認定資格および Google Cloud 認定資格はすべて取得。X（旧 Twitter）では Google Cloud や Google Workspace のアップデート情報をつぶやいています。 Follow @y_sugi_it

こんにちは株式会社G-genの渡邉@norryです。 前回はBusinessエディションでの端末管理をお話しました、今回はそのEnterpriseエディション編になります。 blog.g-gen.co.jp 今回は主に利用人数300名以上のEnterpriseエディションで端末管理を利用したい場合に、Google Workspace Business Plusと何が違うのかを知りたい方のご参考になればと思います。 補足になりますがEnterpriseエディションは300名以下の組織でも利用可能となっていますので、ご利用されたい機能がある場合には選択肢としてご覧ください。 BusinessエディションとEnterpriseエディションの全体比較記事はこちらになります。 blog.g-gen.co.jp 端末管理を考えた時にどのGoogle Workspace Enterpriseプランを選ぶべきか Enterprise Standard及びPlusを選択した方が良いケース 端末管理においてのBusiness Premiumとの違い Business Premiumも一定の管理機能は備わっている Google Workspaceを導入するなら株式会社G-genにご相談ください。 端末管理 を考えた時にどのGoogle Workspace Enterpriseプランを選ぶべきか Google Workspace Enterpriseエディションには「Enterprise Essentials」「Enterprise Standard」「Enterprise Plus」の3つのプランがあります そしてこのプランのうち端末管理を考慮した場合にプランの選択肢としては下記の２つになります。Enterprise Essentialsは端末管理のエンタープライズ エンドポイント管理機能を備えていませんので省略しています。 Enterprise Standard Enterprise Plus ただしEnterprise Essentialsも基本のエンドポイント管理と高度なエンドポイント管理の機能は備えていますので、300名以上で Gmail以外 の機能を利用し端末管理は別のサードパーティー製品でカバーするケースには良いかと思います。 Enterprise Standard及びPlusを選択した方が良いケース Google Workspaceを300名以上での利用と様々なOS（Chrome OS、Android 、iOS、Windows）を統合的に管理したい場合にEnterprise Standard及びEnterprise Plusをおすすめします。 このプランではMDM (Mobile Device Management)の領域をカバーしています。サードパーティーのMDMを利用せずにGoogle Workspaceのみで管理する場合にはこちらを選択ください。 ただし、Enterprise Standard及びPlusのプランにおいて 端末管理 で使える機能について差異はありません。 以下がGoogle Workspace Enterpriseの各プランの端末管理における機能比較表になります。 Enterprise Essentials Enterprise Standard Enterprise Plus 基本のエンドポイント管理（多数の機能） ✔ ✔ ✔ 高度なエンドポイント管理（多数の機能） ✔ ✔ ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ ✔ デバイス監査ログ ✔ ✔ 使われていない会社所有デバイスに関するレポート ✔ ✔ 会社所有の Android デバイス ✔ ✔ 会社所有の iOS デバイス ✔ ✔ Windows デバイス管理 ✔ ✔ iOS データの保護 ✔ ✔ デバイスのリモートワイプ（Windows） ✔ ✔ モバイル デバイスの証明書 ✔ ✔ 管理ルール ✔ ✔ 端末管理においてのBusiness Premiumとの違い Google Workspace Business Premiumにも端末管理の機能は備わっていました、ではBusiness PremiumとEnterprise Standard及びPlusでの機能面での違いは何でしょうか Business Premiumも一定の管理機能は備わっている 下記が比較表になります。Business Premiumの場合Chrome OSやAndroid OSのみ対象とするとライセンスの範囲内で管理が可能です。Enterprise Standard及びPlusでは、iOSデバイスの管理やWindowsデバイスのリモートワイプ（消去）、モバイルデバイスの証明書など、エンタープライズな環境で複数のOSを管理する場合に必須な機能が備わっている事が分かります。 Business Plus Enterprise Standard Enterprise Plus 基本のエンドポイント管理（多数の機能） ✔ ✔ ✔ 高度なエンドポイント管理（多数の機能） ✔ ✔ ✔ エンタープライズ エンドポイント管理 モバイルアプリを個別に配布する ✔ ✔ ✔ デバイス監査ログ ✔ ✔ ✔ 使われていない会社所有デバイスに関するレポート ✔ ✔ ✔ 会社所有の Android デバイス ✔ ✔ ✔ 会社所有の iOS デバイス ✔ ✔ Windows デバイス管理 ✔ ✔ iOS データの保護 ✔ ✔ デバイスのリモートワイプ（Windows） ✔ ✔ モバイル デバイスの証明書 ✔ ✔ 管理ルール ✔ ✔ 以上から、どの種類（OS）の端末をどの程度管理したい（ログインさせない、ブロックする、紛失時のワイプなど）かによってプランをご検討ください。 Google Workspaceを導入するなら株式会社G-genにご相談ください。 Google Workspaceを使った働き方に変えると本当に組織のコミュニケーションとコラボレーションのあり方が変わってびっくりすると思います。 この感動をより多くの人に体感してもらいたいですね。 株式会社G-genではGoogle Workspace / Google Cloud（GCP）を5%割引でご提供しております。 g-gen.co.jp また、Google Workspace / Google Cloud（GCP）/ Chrome book の導入から運用までのご支援を行っていますのでご検討の際にはぜひお声がけください。 お問い合わせはこちらから docs.google.com 渡邉 宣之 (記事一覧) クラウドソリューション部 データ分析基盤の構築、クラウド管理運用やネットワークが守備範囲、Google Workspace 活用推進中、Google Cloud 認定資格は4資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

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 のログ出力は必須と言っていいでしょう。 これにはロードバランサー側のログを有効化する必要がある、ということを覚えておきましょう。 参考 : リクエスト ロギングの使用 杉村 勇馬 (記事一覧) 執行役員 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資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。