tl;dr
- Assured Workloads は、デジタル主権に対応するための Google Cloud のソリューションです
- Assured Workloads の日本リージョン向けコンプライアンス プログラムが 2023 年 10 月末に一般提供されました
- 本記事は Assured Workloads って何？Google Cloud 上でデジタル主権を確保するためにはどうするの？と思われた、主にエンジニア様に送る記事となっています
はじめに
この記事は Google Cloud Japan Advent Calendar 2023 (入門編) の 23 日目の記事です。
皆様こんにちは。Google Cloud の中谷です。Google Cloud でパートナーエンジニアというロールをやっていまして、Google Cloud のパートナー様に対して技術支援をさせて頂いております。
本記事は、Google Cloud の Assured Workloads という機能に焦点を充てて、その機能概要や具体的な設定方法等をまとめていきたいと思います。
デジタル主権 (Digital Sovereignty) と Assured Workloads
Assured Workloads アイコン
Google Cloud の Assured Workloads は、お客様のデジタル主権 (Digital Sovereignty) を確保する為のソリューションです。業界や組織で異なる定義はありますが、一般的なデジタル主権とは、お客様のデジタルアセットをお客様主体でコントロール出来る能力のことを言います。Google Cloud の様なパブリッククラウドはサービスプロバイダーによって運用されているので、お客様がパブリッククラウド上で非常に機密性の高いワークロードを動かしたいですとか、高いセキュリティ管理を必要とするシステムを作りたいとなった際には、サービスプロバイダーがお客様のデータにアクセスすることを防いだり、お客様が必要と考える特定のサービスプロバイダーの行動に対してのみアクセスを承認する仕組みが重要になります。
そしてデジタル主権を確保する為の要件として、Google Cloud としては、更に細かい 3 つの要件を定めています。
- データ主権: 自らのデータのアクセスや暗号化についてのコントロールを有する
- 運用主権: サービスプロバイダー側の運用に関する透明性やコントロールを有する
- ソフトウェア主権: サービスプロバイダーのソフトウェアに対する依存無しにワークロードを稼働できる
Google Cloud におけるデジタル主権の為の 3 つの柱
上記 3 つの要件に際して、Google Cloud は Cloud EKM (External Key Manager) を利用してクラウドの外部で暗号鍵を保管 / 管理してお客様のデータ主権を確保したり、Access Transparency や Access Approval で、サービスプロバイダー側の運用に関する透明性やコントロールを有して運用主権を確保したりと、それぞれ個別の Google Cloud プロダクトを組み合わせることで、お客様がデジタル主権を保ちながら Google Cloud を安全に利用できるようにご支援しています。
ただ、この 3 つの柱に沿っていくつものプロダクトの設定を細かく設定していくのは、それなりの労力が必要です。話のトピックがなんだか壮大な話に聞こえてしまうので、まず何からしたらよいのかわからない。。というケースもあるでしょう。そこで登場するのが、Assured Workloads です。Assured Workloads によって、Google Cloud のお客様はデジタル主権に必要なコントロールを効率的に設定、維持、管理をすることが出来るようになります。
Google Cloud におけるデジタル主権の為の 3 つの柱に関して、より詳細な説明は以下のリンクを御覧ください。
上記のリンクの中では、Digital Sovereignty Explorer というツールも紹介しています。ヨーロッパにおけるデジタル主権のニーズに重点を置いていますが、Google Cloud が提供しているこのユニークなツールは、ウェブ上での対話形式でお客様ごとのデジタル主権に対して、必要なアクションをガイドしてくれます(インターフェースは英語のみ)。
Assured Workloads 機能概要
ここからは、Assured Workloads の機能を具体的に説明していきたいと思います。
まず、Assured Workloads には、コンプライアンス プログラムというキーワードがあります。国ごと、業界ごと、様々なコンプライアンスの定義があり、要求事項も様々です。例えば米国には、ITAR(国際武器取引規則)というコンプライアンスが存在しており、米国人以外の人が ITAR 技術データとみなされる情報を物理的または論理的に閲覧できないようにするための規則があります。Assured Workloads のコンプライアンス プログラムは、このような各国規制を予め定義しており、Assured Workloads の設定ウィザードの中で適用するコンプライアンス プログラムを選択することで、規制に対する具体的な設定のベースラインを Google Cloud 環境に効率的に適用することが出来ます。
このようなメリットがある一方で、留意点として、選択したコンプライアンス プログラムによって、利用可能な Google Cloud サービス、およびそれらのサービスが提供されているリージョンなどの制限が適用されます。その為、Assured Workloads は、Google Cloud のユースケースが積極的に何らかのコンプライアンスの対象となる場合にのみ使用を検討するのがよいでしょう。 コンプライアンス プログラムの詳細と、サポート対象のサービスは以下のページを御覧ください。
より具体的な話に入ります。本記事でご紹介したいのは、Assured Workloads における日本リージョン向けのコンプライアンス プログラムについてです。2023 年 10 月に一般提供が開始されたこのプログラムは、何かしらの国内の規制要件に対してアラインするものではありませんが、お客様の Google Cloud 環境に本コンプライアンス プログラムを適用することにより、前述のデジタル主権を確保する為の 3 つの柱に対して、
- データ主権: すべてのサポート対象サービスに対する Access Transparency を強制
- データ主権: 対象リージョンに保存されたすべての顧客データに対する CMEK ベースの暗号化制御のフレームワークを提供
- 運用主権: 選択した対象リージョンにのみデータが保管されるよう、Organization Policy に変更を加える
上記のような制御を効率的に設定することが出来ます。次の章からは、実際の設定の操作画面も添えて、Assured Workloads の詳細を紹介していきます。なお、Google Cloud 公式ブログにおける日本リージョン向けのコンプライアンスの発表および機能の詳細は、以下のページを御覧ください。
Assured Workloads を使ってみる
まず、Assured Workloads の日本リージョン向けのコンプライアンス プログラムを適用する前に、事前準備が必要になります。実際の Google Cloud コンソールから、Assured Workloads が求める事前準備を確認しましょう。なお、Assured Workloads は Google Cloud の Resource Manager における組織レイヤーで有効化するものなので、そもそも組織を作っていないという方は組織を作ってから Assured Workloads を有効化させましょう。また当然、その組織レイヤーに対しての特定の IAM 役割も必要になります。Assured Workloads 管理者(roles/assuredworkloads.admin)のロールです。こちらの役割を有した Google アカウントで、以下のページを参照に以後の作業を進めます。
組織がある環境で組織レイヤーから Assured Workloads の画面に行くと、以下の画面が現れます。
組織レイヤーから Assured Workloads の画面に行きます
ここの画面では、アクセスの透明性(Access Transparency) を有効化するように求めています。Assured Workloads の有効化において、Access Transparency の有効化が前提になるので、その作業をやっておきます。このスクリーンショットではもう適用が済んでいますが、まだの方は以下の手順を参考に有効化しましょう。
Access Transparency を有効化したら、改めて Assured Workloads の先程の画面で、下段にある「次へ」を押します。すると、以下の画面が現れます。
有効化したいコンプライアンス プログラムを選択します
ここで前章で述べたコンプライアンス プログラムを選択する画面になります。今回は日本リージョン向けのコンプライアンス プログラムを適用させるので、上の画面通り選択して、また「次へ」を押します。
ワークロードのロケーションを限定します
リージョンを選択する画面に遷移します。日本リージョン向けのコンプライアンス プログラムでは、東京リージョン(asia-northeast1) もしくは大阪リージョン(asia-northeast2) のどちらかが選択出来ます。今回は、asia-northeast1 を選択して、「次へ」を選択します。
フォルダの場所とフォルダの名前を構成する
フォルダを構成する画面に遷移しました。どうやらこの設定ウィザードの中で新しいフォルダを作るようです。フォルダを作成する Resource Manager の上位レイヤーと、新規に作成するフォルダ名を指定して、「次へ」を選択します。
キーリングとプロジェクト名、さらには請求先アカウントを選択します
キーリングとキーリングを保管するプロジェクト名、プロジェクトID、更にはそのプロジェクトが紐づく請求先アカウントを指定します。フォルダを作るだけでなく、さらにそのフォルダの中にキーリングを持つプロジェクトも作成してくれそうです。それぞれ任意の値を入れ、請求先アカウントを指定して、「次へ」を押します。
確認画面
今までの設定の確認画面です。入力内容が正しいことをチェックして、「作成」ボタンを押します。
日本リージョン向けのコンプライアンスを持ったアイテムが作成されたようです
無事に初期設定作業が完了したようです。ウィザードで指定したフォルダ名のアイテムが追加されていることが確認できました。今までの設定から推測できるように、Assured Workloads のウィザードを進めてこの画面迄行くと、
- Assured Workloads で統制を利かせる為のフォルダ(Assured Workloads フォルダ)が出来る
- Assured Workloads で CMEK ベースの暗号化制御を行う為のフレームワーク一式(プロジェクトとキーリング)
が出来ます。絵にするとこんな感じです。
Assured Workloads のウィザードが構成する初期構築範囲
実際に Resource Manager の画面を見てみると、以下の様に、ウィザードで指定したフォルダとプロジェクトが作成されていることが確認できます。
Recource Manager の画面
つまり、一定のガバナンスが効いたガードレール環境がこの Assured Workloads フォルダであり、その配下でお客様のワークロードを実際に作成していくことにより、ガバナンスが効いた環境下でワークロードの構築が出来ることになります。
次章からは、上記手順によって作成された Assured Workloads フォルダ配下を眺めて、通常のフォルダと何が変わっているのかを確認していきたいと思います。
Assured Workloads 環境を眺めてみる
Assured Workloads フォルダを眺めてみましょう。Google Cloud コンソールから該当のフォルダを選択すると、以下の注意が表示されるようになります。
Assured Workloads フォルダ配下のリソースでは、今後このようなアラートが表示されるようになります
Assured Workloads を使って構築した環境には、このようなアラートが Google Cloud コンソールに表示されるようになり、本当に操作してもよいかを都度確認してくれるようになりました。他にも以下の項目の設定が書き換わっています。詳しく説明していきます。
Assured Workloads 環境の Organization Policy
Assured Workloads フォルダは、いくつかの Organization Policy がデフォルトで変更されています。
日本向けのコンプライアンス プログラムにおける執筆時点の Organization Policy が変更されるポイントは以下の通りです。
| 番号 | 組織ポリシー名 | 組織ポリシーID | 変更内容 |
|---|---|---|---|
| 1 | Resource Location Restriction | constraints/gcp.resourceLocations |
Assured Workload 初期ウィザードで設定したリージョンのみが設定される |
| 2 | Restrict Resource Service Usage | constraints/gcp.restrictServiceUsage |
利用可能なプロダクトの API が設定・制限される |
| 3 | Restrict TLS Versions | constraints/gcp.restrictTLSVersion |
Google API endpoints に対する TLS バージョンが指定され、TLS_VERSION_1, TLS_VERSION_1_1 を拒否するようになる |
先の章に述べたように、リージョンと利用可能な Google Cloud サービスの Organization Policy が書き換わります。通常ですとこれらの項目を手作業でやっていく必要があるところを Assured Workloads のウィザードだけで一括設定してくれるのはありがたいポイントですね。
Assured Workloads 環境のログバケットのリージョン変更
また、Assured Workloads フォルダ、およびその配下のプロジェクトが持つ _Default と _Requred のログバケットのリージョンが、今後新規作成されるフォルダ、プロジェクトも含めて、ウィザードで指定したリージョンに変更されます。これは、Assured Workloads フォルダに、デフォルトのストレージロケーションの変更が裏側で書き換わる為です。デフォルトのログバケットのロケーション変更についての詳細は以下のページを御覧ください。
Google Cloud が必須で取得する監査ログが入る _Required バケットのリージョンを効率的に設定できるのは非常にメリットありますね。
Assured Workloads フォルダのログバケットの画面。リージョンが通常の global ではないことが確認できます
Assured Workloads 環境の CMEK プロジェクトとキーリングの作成
Assured Workloads の設定ウィザードでも既に出てきましたが、Assured Workloads フォルダ配下に、CMEK プロジェクトとキーリングが準備されています。
CMEK プロジェクトとキーリング
ここまで出来ているので、後はキーリング内に実際の暗号化 / 復号化に使うキーを準備し、更に CMEK 関連の強制項目、例えば Organization Policy の constraints/gcp.restrictCmekCryptoKeyProjects (CMEK 用の KMS CryptoKey を提供できるプロジェクトを制限する) や、constraints/gcp.restrictNonCmekServices (CMEK を使用せずにリソースを作成できるサービスを制限する)と行った項目を追加設定することで、より統制の効いた環境を作り込むことが出来ます。以下のページを参照に、Cloud Logging 用に CMEK を構成するのもよいでしょう。
Assured Workloads 環境のモニタリング
今までは Assured Workloads 環境で適用される構成について説明しましたが、Assured Workloads を設定することで、追加のモニタリング機能が Assured Workloads フォルダ配下に提供されるようになります。具体的には、事前定義された追加のモニタリング項目にそって、その設定項目が書き換えられた際に通知を出すことが出来ます。Assured Workloads のモニタリング機能の概要およびモニタリング対象の監視項目については、以下を御覧下さい。
実際に監視項目の一つを書き換えてみて、その挙動を確認してみたいと思います。Assured Workloads フォルダの組織ポリシー、Restrict Resource Service Usage に追加の設定を加えてみます。すると、Assured Workloads のモニタリングの表示に 1 件、未解決のアイテムが追加されていることが確認できます。
違反のアイテムが追加されていることが確認できます
このアイテムの違反 ID というところをクリックすると、違反の内容と対処方法についてのガイドが記載されています。ガイドに沿って違反内容を修正することで、この違反 IDは解決済みのステータスに変わります。もし仮にこの違反がお客様の中で承認された上での計画された変更だった場合は、違反の例外というオペレーションを実行することが出来ます。この処理を施すことで、許容された違反 IDとして例外フラグを立てる事ができます。違反自体を修正すれば、それは解決済みのステータスに変更されます。注意点として、一度例外として処理されたアイテムは、その例外処理時に補足として記載した理由を変更したりすることができなくなります。理由は監査ログに記録されますので、例外を実施する場合は慎重に行って下さい。
違反の詳細から例外処理を追加することができます
またもし、違反が起きたフォルダにおいてエッセンシャル コンタクトに連絡先を入れていた場合は、以下のようなメール通知を受け取る事ができます。
エッセンシャル コンタクトに連絡先を定義していると、違反が発生した際に上記のようなメールを即時受け取ることが出来ます
Assured Workloads の料金
最後に補足として、Assured Workloads の料金についても紹介しておきたいと思います。日本リージョン向けのコンプライアンス プログラムは、有償のプレミアムティアというティアに分類されており、Assured Workloads フォルダ内のすべての費用に対して 20% の追加料金がかかります。Assured Workloads の料金の詳細および計算サンプルは以下のページを御覧ください。
終わりに
本記事では、Assured Workloads の概要と、実際の設定画面や追加のモニタリングについて説明させて頂きました。いかがでしたでしょうか？
Assured Workloads については、先日行われた Google Cloud Next Tokyo '23 の基調講演でも、日本リージョン向けのコンプライアンスが大きく発表されていました。別途、ブレイクアウトセッションでも Google Cloud データセンター & デジタル主権ソリューション事業開発部 部長 堀地さんがより詳細を説明されていましたので、こちらを見ていただくのもおすすめです。
今後、クラウドの発展とともに重要なキーワードとなってくるであろうデジタル主権と Google Cloud の Assured Workloads。是非皆様も本プロダクトの発展を楽しみにしてて下さい。
Discussion