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 の 限定グッズ が手に入る ルール・受験方法 言語・試験時間・料金 ※ 受験料の記載は税別です 資格名 試験時間 受験料 言語 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資格保持 週末フォトグラファーで、観葉植物や塊根植物にハマってます。

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

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

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

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

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

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