コンプライアンス

GKE 対策の拡張: Policy Controller 違反が Security Command Center で確認可能に

Tue, 03 Oct 2023 01:20:00 +0000

※この投稿は米国時間 2023 年 9 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes を大規模に利用しているお客様は、セキュリティ、リソース管理、柔軟性を向上させるために、環境全体のリソース使用状況について一貫したガードレールを必要とされています。お客様から、こういったポリシーガードレールを簡単に適用、表示できる方法が必要であるとの声が寄せられていることから、Google Cloud は Policy Controller ダッシュボードをリリースし、すべての GKE 環境に対するサポートを追加いたしました。

それに対するセキュリティ管理者の皆様からのフィードバックとして、Google Cloud 資産全体のセキュリティ分析情報とともに、GKE のポリシーとコンプライアンスの違反に関するレポートを利用可能にする必要があるとのご意見をいただきました。これに対応するために Google Cloud は、Policy Controller（CIS Kubernetes Benchmark v1.5.1 および PCI-DSS v3.2.1）の違反を Security Command Center（SCC）で確認できるようにするフルマネージドのインテグレーションを導入いたします。

SCC は、Google Cloud に組み込みのセキュリティ管理とリスク管理のためのソリューションです。SCC を使用することで、クラウドアセットを攻撃にさらすおそれのある構成ミス、脆弱性、コンプライアンスエラーの検出が容易になります。

Policy Controller を使用すると、GKE クラスタリソースの「ガードレール」として機能する完全にプログラム可能なポリシーを監査、適用して、セキュリティ、運用、コンプライアンスの管理に違反する変更を防止できるようになります。Policy Controller は、デベロッパーが迅速かつ安全にコードをリリースできるようにすることで、アプリケーションのモダナイゼーションへの取り組みを加速させます。Policy Controller で監査、適用できるポリシーの例をいくつか以下にご紹介します。

すべてのコンテナイメージは承認されたリポジトリから取得する必要がある
すべての Pod にはリソース制限が必要である
クラスタのフリートで実行されているリソースは CIS Kubernetes Benchmark に準拠している必要がある
クラスタのフリートで実行されているリソースは NIST-800 フレームワークに準拠している必要がある
クラスタのフリートで実行されているリソースは PCI DSS ベンチマークに準拠している必要がある

Policy Controller と SCC のインテグレーション

すべての Policy Controller ユーザーが Policy Controller 違反を SCC で表示できます。このインテグレーションには、以下のようなメリットがあります。

可視性と透明性の向上: SCC とのインテグレーションでは、組織全体におけるプラットフォームやワークロードの違反を一つのダッシュボードで可視化できます。これは、セキュリティとコンプライアンスの体制の強化と組織に対するリスクの軽減につながります。
使いやすさ: フルマネージドのインテグレーションとは、追加のビルドや運用オーバーヘッドが不要ということです。また、このインテグレーションはすぐに利用可能です。
デフォルトで有効: このインテグレーションは、Policy Controller と Security Command Center のすべてのユーザーに対してデフォルトで有効になります。
効率性と意思決定の向上: 組み込みのレポートで確認できる違反とコンプライアンスに関するデータを活用して情報に基づく意思決定を行い、目標とするセキュリティ、ガバナンス、コンプライアンスの標準を満たす正しい方向に歩みを進めることができます。

Policy Controller と SCC のインテグレーションを使ってみる

Policy Controller と Security Command Center の既存のユーザーは何もする必要がありません。Policy Controller 違反は SCC の [検出結果] タブに自動的に表示されます。

SCC の [検出結果] タブから Policy Controller 違反を確認

Policy Controller 違反の検出結果の詳細を確認

SCC の [脆弱性] ページに、各 Policy Controller 評価が、SCC から提供される他の評価とともに表示され、関連するコンプライアンス管理にマッピングされます。

SCC の [脆弱性] タブから Policy Controller の検出結果を確認

Google は使いやすさ、すぐに使えるコンテンツ、Google Cloud 機能のさらなるインテグレーションに重点を置いて、GKE と GKE Enterprise のフルマネージドポリシー機能の構築に投資を続けています。Policy Controller の使用を開始するには、Policy Controller をインストールし、CIS Kubernetes Benchmark などの基準に照らしてクラスタのフリートを監査するためにポリシーバンドルを適用してみてください。SCC の利用を今すぐ開始するには、Google Cloud コンソールと Google Cloud のクイックスタートガイドをご確認ください。

ー Google Cloud、プロダクト マネージャー Poonam Lamba

ープロダクト マネージャー Tim Wingerter

Policy Controller ダッシュボード: Anthos と GKE のすべての環境で利用可能に

Wed, 24 May 2023 09:40:00 +0000

※この投稿は米国時間 2023 年 5 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

Kubernetes を大規模に利用しているお客様は、セキュリティ、リソース管理、柔軟性を向上させ、製品化までの時間の短縮と運用効率の向上を達成するために、環境全体のリソース使用状況について一貫したガードレールを必要とされています。

また、クラスタのフリートに対する適用ステータス、違反、修正の推奨事項など、ポリシーガードレールを簡単に適用、表示できる方法も求められています。そこで Google は 2023 年 1 月、すぐに使えるポリシーバンドルが付属した Policy Controller ダッシュボードをリリースしました。そしてこのたび、Policy Controller ダッシュボードをすべての Google Kubernetes Engine（GKE）と Anthos 環境（オンプレミス、マルチクラウド、接続クラスタ）でご利用いただけるようになりました。このダッシュボードでは、違反の修正に役立つ優れたフローが利用できます。

Policy Controller を使用すると、ガードレールとして機能する完全にプログラム可能なポリシーをクラスタリソースに適用し、セキュリティ、運用、またはコンプライアンスの管理に違反する変更を防止できます。Policy Controller は、デベロッパーが迅速かつ安全にコードをリリースできるようにすることで、アプリケーションのモダナイゼーションへの取り組みを加速させます。Policy Controller で監査、適用できるポリシーの例をいくつか以下にご紹介します。

すべてのコンテナイメージは承認されたリポジトリから取得する必要がある
すべての Ingress ホスト名はグローバルに一意である必要がある
すべての Pod にはリソース制限が必要である
すべての名前空間には、連絡先を一覧表示したラベルが必要である
クラスタのフリートで実行されているリソースは CIS Kubernetes Benchmark に準拠している必要がある
クラスタのフリートで実行されているリソースは PCI DSS ベンチマークに準拠している必要がある

Policy Controller ダッシュボード

一方、プラットフォームとセキュリティ管理者は Policy Controller ダッシュボードを使用して、次のことができます。

適用ステータス（dryrun、warn、enforced）など、クラスタのフリートに適用されたすべてのポリシーの状態を一目で確認
各違反に対する独自の推奨事項を参照することで、ポリシー違反を容易にトラブルシューティングして解決
クラスタリソースのコンプライアンスステータスを可視化

Policy Controller ダッシュボードは、ユーザーフレンドリーで直感的に操作できるよう設計されているため、あらゆるスキルレベルのユーザーがクラスタのフリートに対する違反を簡単に管理、モニタリングできます。これにより、ポリシー違反の状況を一元的に把握し、必要に応じて対処することが可能になります。

上のダッシュボードの円形グラフには、Policy Controller のインストール全般のステータス、違反しているクラスタ、クラスタのフリート全体に適用されているポリシーの合計など、すべての環境にわたるポリシーの状態が表示されます。違反措置は、ポリシーに照らしてリソースを監査しているだけなのか、クラスタの承認時にポリシーを適用しているのかを示します。

Policy Controller ダッシュボードページの下部には、フリートのポリシーバンドルごとのカバレッジが示され、該当バンドルに準拠しているリソースや違反しているリソースの割合が分けて表示されます。

棒グラフが完全にグレー表示されている場合、このクラスタのフリートにバンドルは適用されていません。棒グラフの一部がグレー表示されている場合、フリート内の 1 つ以上のクラスタにバンドルが適用されていません。
バンドルが 1 つ以上適用されている場合、リソースの全体的なコンプライアンスはバンドルに対して計算されます。棒グラフの青色の部分はポリシーに準拠しているリソースを示し、オレンジ色の部分は違反を表します。

各バンドルの違反リンクをクリックすると、下の画像に示されている詳細な [違反] タブが表示されます。

新しい [違反] タブを使うと、ご利用の環境でポリシー違反を簡単に表示して把握できます。

[違反] タブでは、クラスタ、バンドル、リソースの種類などに基づいて違反をフィルタできます。さらに、制約と名前空間ごとに違反をグループ化して、さまざまなユーザーペルソナがジョブの実行を効率化できるようになりました。いずれかのグループの制約リンクをユーザーがクリックすると、以下のように [制約] ビューが表示されます。

[制約の詳細] タブには、修正の対応案と制約 YAML が表示されます。

[制約の詳細] タブには制約の説明が表示されます。また、推奨される対応も示されるため、制約および影響を受けるリソースに対する違反を修正できます。クラスタ上に存在する制約の YAML を表示することもできます。[影響を受けるリソース] タブには、制約に違反しているすべてのリソースと詳細なエラーメッセージが下の図のように一覧表示されます。

[影響を受けるリソース] タブに、違反しているリソースが表示されています。

今すぐ使用を開始する

Google は使いやすさ、すぐに使えるコンテンツ、Google Cloud 機能のさらなる統合に重点を置いて、GKE と Anthos のフルマネージドポリシー機能の構築に投資を続けています。Policy Controller の使用を開始するには、Policy Controller をインストールし、CIS Kubernetes Benchmark などの基準に照らしてクラスタのフリートを監査するためにポリシーバンドルを適用してみてください。また、Policy Essentials バンドルに照らしてクラスタを監査するために、Policy Controller をご試用いただけます。Policy Controller の最新機能については、次回のブログ投稿で詳しくご紹介します。ぜひ Next ’23 に参加して詳細をご確認ください。

- Google Cloud、プロダクトマネージャー Poonam Lamba

新しい PCI DSS ポリシーバンドルで Kubernetes クラスタを強化し、ワークロードのコンプライアンスを大規模にモニタリングする

Thu, 16 Feb 2023 03:15:00 +0000

※この投稿は米国時間 2023 年 2 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

PCI DSS は、PCI Security Standards Council で採択された一連のネットワークセキュリティおよびビジネス上のベストプラクティスガイドラインによって構成され、お客様の支払いカード情報を保護するための「最小限のセキュリティ基準」が設定されています。Google Cloud は少なくとも年に 1 回、第三者監査を実施し、PCI DSS に照らして個々のプロダクトの認証を受けています。お客様はこうした証明書に基づいて、アプリケーションのコンプライアンスを測定できます。このブログ投稿では、新しいアプリケーションと既存のアプリケーションを評価して PCI DSS のコンプライアンス状況を確認できるようにします。

Policy Controller を使用すると、クラスタに対して完全にプログラム可能なポリシーを適用できます。ポリシーバンドルは、すぐに使える一連の制約で、Google Cloud によって作成、管理されます。ポリシーバンドルにより、Kubernetes 基準、業界基準、Google Cloud 推奨のベストプラクティスに照らしてクラスタリソースを監査できます。多くのポリシーバンドルはすぐに利用可能であり、新規ユーザーでも既存ユーザーでもそのまま、つまり 1 行もコードを記述することなく簡単に使用できます。Policy Controller ダッシュボードを使用して、クラスタのフリートに対するポリシーバンドルのカバレッジとコンプライアンスの状況を確認することもできます。

PCI DSS v3.2.1 ポリシーバンドル

組織のセキュリティ管理者は、PCI DSS ポリシーバンドルの違反を確認することで、PCI DSS の要件に対するアプリケーションの対応状況を確認できます。PCI DSS バンドルの各制約には PCI DSS コントロール番号も設定されており、この番号を PCI の要件にマッピングできます。このマッピングはコンプライアンス報告時に必要に応じて使用できます。違反リストを表示する方法については、この投稿の次のセクションで説明します。

PCI DSS v3.2.1 ポリシーバンドルのポリシーは、次の分野に焦点を当てています。

安全なネットワークとシステム

すべてのアプリに特定の監査ラベルを含めることを必須にすることで、ファイアウォールの要件を保証します。
すべてのアプリに特定のアノテーションを含めることを必須にすることで、ネットワーク制御の要件を保証します。
クラスタで定義されているすべての名前空間に NetworkPolicy が必要です。
RoleBinding リソースに有効な app.kubernetes.io/managed-by= ラベルが必要です。
デフォルトのサービスアカウントを使用したリソースの作成を制限します。
Pod がデフォルトの名前空間を使用できないようにします。

安全なシステムとアプリケーション

すべての PeerAuthentication が厳格な mTLS を上書きできないようにします。
アンチウイルス DaemonSet が必要です。
Anthos Config Management のプレゼンスと有効化を適用します。
BackendConfig リソースに Cloud Armor の構成を適用します。

高度なアクセス制御とモニタリング

basic-auth タイプのシークレットの使用を制限します。
Container-Optimized OS を OS イメージとして確実に使用することで、ノード上での一貫性のある正確な時間を確保します。

PCI DSS v3.2.1 ポリシーバンドルを使用する

PCI DSS v.3.2.1 ポリシーバンドルは、Policy Controller v1.14.0 以降がインストールされている Anthos クラスタにインストールできます。含まれているポリシーは、デフォルトでは「監査」モードで構成されているので、既存または新しいワークロードに影響しません。ポリシーバンドルを適用するには、kubectl（以下で手順を説明します）、kpt、または Config Sync を使用できます。

1. Google Cloud CLI をインストールして初期化します。これにより、この手順で使用する gcloud コマンドと kubectl コマンドが提供されます。Cloud Shell を使用する場合、Google Cloud CLI がプリインストールされています。

2. 参照制約と Policy Controller 制約テンプレートライブラリを有効にして、Anthos クラスタに Policy Controller をインストールします。

3. 次の YAML マニフェストを policycontroller-config.yaml という名前のファイルに保存します。このマニフェストでは、特定の種類のオブジェクトを監視するように Policy Controller を構成します。

注: gatekeeper-system 名前空間にすでに既存の構成がある場合は、変更を維持するため、以前にカスタマイズした設定をすべて含める必要があります。

code_block: <ListValue: [StructValue([('code', 'apiVersion: config.gatekeeper.sh/v1alpha1\r\nkind: Config\r\nmetadata:\r\n name: config\r\n namespace: "gatekeeper-system"\r\nspec:\r\n sync:\r\n syncOnly:\r\n - group: "apps"\r\n version: "v1"\r\n kind: "DaemonSet"\r\n - group: "networking.k8s.io"\r\n version: "v1"\r\n kind: "NetworkPolicy"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a202a50>)])]>

4. policycontroller-config.yaml マニフェストを適用します。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -f policycontroller-config.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2037d0>)])]>

4. kubectl でポリシーの制約をプレビューします。

code_block: <ListValue: [StructValue([('code', 'kubectl kustomize https://github.com/GoogleCloudPlatform/acm-policy-controller-library.git/anthos-bundles/pci-dss-v3.2.1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a203490>)])]>

5. kubectl でポリシーの制約を適用します。

code_block: <ListValue: [StructValue([('code', 'kubectl apply -k https://github.com/GoogleCloudPlatform/acm-policy-controller-library.git/anthos-bundles/pci-dss-v3.2.1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a202d50>)])]>

出力は次のようになります。

code_block: <ListValue: [StructValue([('code', 'asmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls created\r\nk8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount created\r\nk8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth created\r\nk8senforcecloudarmorbackendconfig.constraints.gatekeeper.sh/pci-dss-v3.2.1-enforce-cloudarmor-backendconfig created\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a201090>)])]>

6. ポリシーの制約がインストールされていることを確認し、クラスタ全体で違反の存在を確認します。

code_block: <ListValue: [StructValue([('code', 'kubectl get constraint -l policycontroller.gke.io/bundleName=pci-dss-v3.2.1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a202cd0>)])]>

出力は次のようになります。

code_block: <ListValue: [StructValue([('code', 'NAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS\r\nasmpeerauthnstrictmtls.constraints.gatekeeper.sh/pci-dss-v3.2.1-asm-peer-authn-strict-mtls dryrun 0\r\nNAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS\r\nk8sblockcreationwithdefaultserviceaccount.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-creation-with-default-serviceaccount dryrun 0\r\nNAME ENFORCEMENT-ACTION TOTAL-VIOLATIONS\r\nk8sblockobjectsoftype.constraints.gatekeeper.sh/pci-dss-v3.2.1-block-secrets-of-type-basic-auth dryrun 0\r\n…'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a203710>)])]>

違反を修正するためには、リソースの yaml を更新することをおすすめします。ガイドラインをご覧ください。違反には、その違反の修正手順も含まれています。修正手順は CLI と Policy Controller ダッシュボードの両方から確認できます。

Policy ダッシュボードで PCI DSS ポリシーバンドルの違反を確認する

クラスタでの違反は、Policy Controller ダッシュボードを使用して UI からも確認できます。

クラスタで PCI DSS ポリシーバンドル違反をモニタリングする

PCI DSS ポリシーバンドルは、デフォルトで適用アクションが dryrun に設定されています。この構成では、リソースをブロックまたは中止することなく Policy Controller で違反が表示されます。これにより、クラスタの監査、ワークロードオーナーとの違反の共有、重要なセキュリティ問題を共同で修正することが可能になります。

すべてのポリシー違反は自動的に Cloud Logging に記録され、ログエクスプローラで以下のフィルタを適用して見つけることができます。

code_block: <ListValue: [StructValue([('code', 'resource.type="k8s_container"\r\nresource.labels.namespace_name="gatekeeper-system"\r\nresource.labels.pod_name:"gatekeeper-audit-"\r\njsonPayload.process: "audit"\r\njsonPayload.event_type: "violation_audited"\r\njsonPayload.constraint_name:*\r\njsonPayload.constraint_namespace:*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2004d0>)])]>

また、ポリシー違反が発生するたびに通知を受け取るようにするため、Cloud Monitoring を使用してログベースのアラートを設定することもできます。

Policy Controller には、制約の数、制約テンプレート、検出された監査違反などをはじめとする、ポリシーの使用に関連する指標が含まれています（公開された指標のリストを参照）。インストール時にこれらの指標を Cloud Monitoring と Prometheus にエクスポートできます（ブログ投稿、ドキュメント）。また、指標に基づいてアラートを設定することもできます。

まとめ

Policy Controller により、Google によって作成、管理されるポリシーバンドルとカスタムポリシーの両方をクラスタに適用できます。これにより、Kubernetes API に対する変更がセキュリティ、運用、コンプライアンスの管理に違反することを防止しますまた、Kubernetes クラスタへのデプロイ前にコンプライアンスを確認するために構成を分析するときに、必要に応じて Policy Controller を使用できます。

使ってみる

Anthos Policy Controller の使用を開始する際は、Policy Controller をインストールし、Google によって作成、管理されている他のポリシーバンドルを試してみることが最も簡単です。

- Google Cloud、プロダクトマネージャー Poonam Lamba
- Google Cloud、テクニカルソリューションコンサルタント Andrew Peabody

Kubernetes クラスタにポリシーバンドルを適用してポリシー準拠の状況を大規模にモニタリング

Mon, 30 Jan 2023 02:30:00 +0000

※この投稿は米国時間 2023 年 1 月 24 日に、Google Cloud blog に投稿されたものの抄訳です。

ハイブリッドクラウドやマルチクラウド戦略を採用する企業ユーザーが増加する現在、ワークロードは環境全体に分散されるようになり、一元化されたセキュリティとガバナンスの重要性が高まっています。Anthos は、最新のアプリケーションをあらゆる場所で一貫して大規模に実行するための、Google のクラウド中心（Cloud-Centric）のコンテナプラットフォームです。Anthos Config Management（ACM）は、Kubernetes クラスタのポリシーとセキュリティを自動化するサービスで、Config Sync、Config Controller、Policy Controller により構成されています。Config Sync は、クラスタの状態を 1 つ以上の Git リポジトリと調整します。Config Controller は、管理者が Google Cloud Platform（GCP）リソースを宣言型で管理できるようにするホスト型サービスです。このブログ記事では、Policy Controller コンポーネントに追加された機能拡張について取り上げます。

ACM の主要コンポーネントである Policy Controller を使用すると、クラスタに対して完全にプログラム可能なポリシーを適用できます。こうしたポリシーは「ガードレール」として機能し、セキュリティ、運用、またはコンプライアンスの管理に違反する変更を防止します。Policy Controller は、デベロッパーが迅速かつ安全にコードをリリースできるようにすることで、アプリケーションのモダナイゼーションへの取り組みを加速させます。

このたび、クラスタのフリートに適用されるポリシーガードレールを簡単に管理、モニタリングできるパワフルなツールとして、新しい組み込みの Policy Controller ダッシュボードをリリースいたしました。

プラットフォームとセキュリティ管理者は Policy Controller ダッシュボードを使用して、次のことを実現できます。

適用ステータス（dryrun または enforced）など、クラスタのフリートに適用されたすべてのポリシーの状態を一目で確認
各違反に対する独自の推奨事項を参照することで、ポリシー違反を容易にトラブルシューティングして解決
クラスタリソースのコンプライアンスステータスを可視化

Anthos の Policy Controller ダッシュボード

このダッシュボードでは、特定のポリシーの影響を受けるリソースを表示して、問題の解決方法について独自の提案を行うこともできます。

脆弱性の影響を受けるリソースを特定

ポリシーバンドルの概要

ポリシーバンドルは、すぐに使える一連の制約で、Google によって作成、管理されます。このバンドルにより、Kubernetes 基準、業界基準、または Google 推奨のベストプラクティスに照らしてクラスタリソースを監査することができます。

ポリシーバンドルはすぐに利用可能で、新規ユーザーでも既存ユーザーでもそのまま、つまり 1 行もコードを記述することなく簡単に使用できます。ユーザーは、Policy Controller ダッシュボードから、フリートに対するポリシーバンドルのカバレッジの状況を確認できます。たとえば、フリート内に 4 つのクラスタがあり、この 4 つのクラスタすべてに PCI DSS 3.2.1 バンドルを適用した場合、ダッシュボードにはフリートのカバレッジが 100% であることが表示されます。また、カバレッジに加え、ダッシュボードにはクラスタのフリート全体に対する、各バンドルの包括的なコンプライアンスステータスも表示されます。

Anthos では、現在以下のポリシーバンドルを利用できます。

PCI DSS 3.2.1: PCI-DSS 3.2.1 業界基準に照らしてクラスタリソースの監査を行う
CIS Kubernetes Benchmark 1.5.1: CIS Kubernetes Benchmark（Kubernetes を構成し、堅牢なセキュリティ体制をサポートするための一連の推奨事項）に照らしてクラスタリソースの監査を行う
PSS Baseline: PSS - Baseline に照らしてクラスタリソースの監査を行う
PSS Restricted: PSS - Restricted に照らしてクラスタリソースの監査を行う
PSP: Pod のセキュリティポリシーに照らしてクラスタリソースの監査を行う
Policy Essentials: コンテナ化されたワークロード向けに、Google 推奨のベストプラクティスに照らしてクラスタリソースの監査を行う
Anthos Service Mesh セキュリティ : 推奨される Anthos Service Mesh のベストプラクティスに対してクラスタの監査を行う

使ってみる

Anthos Policy Controller の使用を開始する際は、Policy Controller をインストールし、CIS ベンチマークなどの基準に照らしてクラスタのフリートを監査するためにポリシーバンドルを適用してみることが最も簡単です。

また、Policy Essentials バンドルに照らしてクラスタを監査するために、Policy Controller を試すこともできます。

- Google Cloud、プロダクトマネージャー Poonam Lamba

CISO サバイバルガイド: 変革を成功に導くための重要な質問

Wed, 18 Jan 2023 02:00:00 +0000

※この投稿は米国時間 2023 年 1 月 10 日に、Google Cloud blog に投稿されたものの抄訳です。

デジタルトランスフォーメーションに取り組む組織のセキュリティリーダーは、変革戦略の実施方法に関する難しい質問と複雑な答えに備える必要があります。

前回の CISO サバイバルガイドに関するブログでは、金融サービス組織がより安全にクラウドに移行する方法について説明しました。組織、オペレーション、テクノロジー（OOT）アプローチの利点のほか、継続的デリバリーや必要な文化的変革などの新しいプロセスの採用など、高度に規制された金融サービス業界が直面しているデジタルトランスフォーメーションの課題について整理し、考える方法を検討しました。

運命を共有するための Google Cloud の取り組みの一環として、この記事では、組織の変革を良い成果に導く会話集を作成するうえで役立つ、適切な質問の方法に関するヒントをご紹介します。多くの場合、正しい答えは 1 つとは限りませんが、思慮深く整然としたアプローチによって的を絞った質問をし、返ってきた答えを偏見のない心で受け止めることで、求める成果を達成できます。本記事の質問は、組織のセキュリティ変革をどこから開始し、どこで終えるべきかを明らかにできるように考案されています。以下の質問をすることで、CISO とビジネスリーダーは、建設的で的を絞った対話を展開できます。これにより、セキュリティ管理の実装と、経営陣や取締役会が設定したリスク許容度の微調整との間で、適切なバランスを判断できます。

会話の導入時に問うべき質問:

組織の文化を定義するものは何ですか？
文化をセキュリティ目標に組み込むための最適な方法は何ですか？

CISO がビジネスリーダーに対して問うべき質問:

変革を成功させるにはどうすればよいですか？
変革の主な目標は何ですか？
（最も）価値のあるデータは何ですか？
廃棄、再分類、移行できるデータはどれですか？
被っても機能を維持できる損失はどのようなものですか？
組織が受け入れ可能な現実のリスクは何ですか？

ビジネスリーダーが CISO とセキュリティチームに対して問うべき質問:

貴重なデータを保護するためのベストプラクティスは何ですか？
そうした管理体制を導入すると、ビジネスにどのような影響がありますか？
対処する必要がある主な脅威は何ですか？

CISO とビジネスリーダーが問うべき質問:

重要度が下がったで脅威は何ですか？
ファイアウォールやウイルス対策ソフトウェアなど、より費用対効果の高い制御機能を実現するうえで、どの部分に費用をかけることができますか？
アプリケーションをリファクタリングすることで得られるメリットは何ですか？
私たちは本当に変革（リフト＆シフト）を実現しているでしょうか？
ビジネスの目標を達成するために、ID とアクセスの管理をどのように実施する必要があるでしょうか？
最初のワークロードでエンタープライズレベルのパフォーマンスを確保するために、必要な中核的な制御機能は何ですか？

CISO とリスクチームが問うべき質問:

セキュリティ機能を合理化するために、既存のコード本体の再構築をどのように使用できるでしょうか？
リスクを許容範囲内に抑えるには、どのようにセキュリティ体制をモニタリングすべきでしょうか？

ビジネスチームと技術チームが問うべき質問:

私たちのバックアップ計画はどのようなものですか？
その計画が失敗した場合はどうしますか？

実践的なアドバイスと運用変革の現実

組織によっては 10 年以上にわたってクラウドに取り組み、すでに多くの運用手順に対応し、その過程で痛ましい教訓を得ていることもあります。長期間にわたり安全にクラウドを運用している組織には、文化、運用の専門知識、技術に対するアプローチを理解することで得られるものが多くあることを Google は認識しています。

しかし一方で、準備がおおよそ整ってから初めてクラウド環境での運用方法を考え始める組織がまだ多くあります。そのような場合は、遅すぎる可能性があります。クラウド環境をどのように運用するか運用開始前に詳細が定まっていなければ、誰がその保守において責任を持つべきかもわかりません。

変革の開始にあたって把握すべき重要なステークホルダーや、特定のシステムのエンジニアリングと保守を担当する人物は誰でしょうか。ステークホルダーには、変革の運用に沿ったグループや、運用に合わせたクラウドの制御設計に重点を置いているグループなど、いくつかのグループが存在する可能性があります。

設計段階にオペレーターが関与していない場合、実用的な価値がほとんどない巧妙なセキュリティ管理ができあがることになります。なぜなら、日常の保守担当者は、こうした管理体制を効果的に運用するための専門知識を持たず、そのためのトレーニングも受けていない可能性が高いためです。

多くの組織がクラウド運用に関する適切なスキルを持つ人材の採用、維持に苦労しているという事実から、この事態は複雑なものになっています。既存の従業員をトレーニングして新しいクラウドスキルを習得させ、他の担当職務から離れる時間を与えることで、熟練した多様なクラウドセキュリティチームを構築できると Google は考えています。

セキュリティリーダーや熟練したスタッフの離職率が高い組織は、一貫性を高めるために社内文化のかじ取りをする必要があります。もちろん、信頼できるパートナーを活用して社内の知識を補完することもできますが、それは将来の運用費用の面で割高な戦略です。

Google は最近、2～3 年ごとに熟練したスタッフとリーダーが交代するセキュリティ組織に出会いました。この交代の速さは、セキュリティ目標の頻繁なリセットにつながります。このチームは、最良のセキュリティアプローチを常に見直し続けているにもかかわらず有意義な進歩を遂げていないため、それが「グラウンドホッグデー」のようだと冗談を言っています。これは模倣すべきモデルではありません。

多くのセキュリティ管理が失敗するのは、その不適切な設計のためではなく、それを使用する人々、すなわちセキュリティチームが不適切にトレーニングされ、モチベーションも不十分であるためです。これは、離職率が高く、組織上の不整合が他にも見られるチームに特に当てはまります。攻撃を 100% ブロックするセキュリティ管理は正しく設計されているかもしれませんが、それを効率的に運用できなければ、時間の経過とともに管理体制の有効性は無に帰します。さらに思わしくないことに、管理体制が機能していると誤って思い込むことで、ある種の負債を抱えることになります。

次回のブログ記事では、組織のデジタルトランスフォーメーションを通じてセキュリティチームを導くうえで役立つと思われるいくつかの実証済みのアプローチをご紹介します。

現時点で公開されている情報については、以下をご覧ください。

- Google Cloud、セキュリティソリューション戦略 Anton Chuvakin
- Google Cloud、CISO オフィス David Stone

CISO サバイバルガイド: 金融サービス組織がより安全にクラウドに移行するには

Mon, 21 Nov 2022 05:00:00 +0000

※この投稿は米国時間 2022 年 11 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

新学期の始まりに子どもと大人が期待や不安を抱くのと同様に、金融サービス組織にとっても、クラウドへの移行の開始は簡単ではないかもしれません。

最高情報セキュリティ責任者（CISO）は、組織のデジタルトランスフォーメーションのクラウドセキュリティ対策を主導する必要があります。この複雑なタスクにはさまざまな疑問が付きまといますが、Google サイバーセキュリティ対応チームのメンバーがその答えを提供します。どの組織にも通用する、画一的なクラウドセキュリティアプローチは存在しません。Google は、デジタルトランスフォーメーションという魅力的な新世界への移行と、サイバーセキュリティ専任の堅固なチーム作りという点で、金融サービス組織の支援したいと考えています。

Google はこれまで、トランスフォーメーションの過程にある多くの金融サービス組織を支援してきました。組織の目標は、サイバーセキュリティ目標の達成方法を革新することから、移行後の立ち上げに必要なセキュリティコントロールを最小限に抑えることまで多岐にわたります。また、運用面と技術面のニーズ、資金源、リスク許容度も組織ごとに異なり、そのすべてがセキュリティ戦略を根本的に変える可能性があります。

Google は、クラウド CISO オフィスから実際的な知識と経験を提供し、組織がクラウドへの移行を大胆かつより安全に行えるよう支援しています。これは、運命共有モデルを施策として、セキュリティ面でのお客様の成果を最大限に高めることに対する Google の取り組みの一部でもあります。私たちは、組織の安全を確保することが、より安全な世界の構築につながると強く信じています。

移行を開始する前に解消しておくべき多くの懸案事項

クラウドへの移行を間近に控えた組織からよく寄せられる質問は、次のとおりです。

今回が初めての移行ですが、まず何を気にかける必要がありますか？
技術的・サイバーセキュリティ的負債をクラウドに移さないようにするにはどうすればよいですか？
注意する必要のある主な脅威として、どのようなものがありますか？
どのようなデータをオンプレミスで引き続き管理しなければなりませんか？
重点課題に適切に対処するには、チームをどのように編成すればよいですか？

これらの質問の内容からわかるとおり、テクノロジー部門とセキュリティ部門のリーダーは、クラウドへの移行をビジネス変革の機会として利用しようとしています。それは素晴らしい考えです。ただし、技術的負債やサイバーセキュリティの負債は、「意図せず生み出されたものだからクラウドに移行すればチャラになる」わけではありません。これらの負債をなくすには、堅固な基盤を確立し、クラウドの利点を活用してリスクを軽減するという協調的な取り組みが必要です。

これらの懸念事項とそれに対処するための戦略は、組織とその運営、テクノロジー、人員、そして CISO のリーダーシップに基づいて分類できます。

組織におけるクラウド思考の推進

昨今のセキュリティチームは、NIST サイバーセキュリティフレームワークなどのセキュリティコンプライアンスモデルに基づいて編成されています。この方法は、セキュリティコントロールや一般的なセキュリティ対策について議論するための土台を提供しますが、最適な効果をもたらすセキュリティチームを編成するための最良の方法であるとは限りません。

また、こうしたフレームワークのほとんどは、規制の厳しい業界でクラウドが広く採用される前に開発されたものです。今では、特殊なケースや業種に対応する、専門分野に特化した知識とツールが求められるようになっています。

クラウドの普及に伴い、フレームワークを進化させて新しい脅威に適応するとともに、迅速なビジネスの変更とアジャイルな IT によって新しい運用環境に順応する必要があります。基本的に、デジタルトランスフォーメーションでは、組織のチェンジマネジメント能力が問われます。デジタルトランスフォーメーションの前準備として重要な要素は、組織の人員をオンプレミス思考から脱却させて、新しい考え方を採用するように導くことです。

クラウドセキュリティに向けた CISO のメンタルモデル刷新の必要性で指摘したとおり、デジタルトランスフォーメーションの過程および完了後のセキュリティでは、ネットワークとエンドポイントのセキュリティ、検出と対応、データセキュリティ、Identity and Access Management（IAM）がクラウドでどのように機能するかに着目し、それらの機能の違いを利用して、復元性に優れたセキュリティ体制を整える必要があります。

適切な質問がセキュリティの変革を促進

戦略的および戦術的な決定を下す際に重要となるのは、セキュリティコントロールを実装する理由を自問することです。

デジタルトランスフォーメーションは、チームについて再検討する絶好の機会をもたらします（クラウドトランスフォーメーションでは文化が最重要であるため）。これにより、ファイアウォール、ウイルス対策ソフトウェア、アプリケーション、データ保護、全体的なセキュリティおよびリスク体制、バックアッププランについて、組織が推進している戦略に沿った変革への道が開かれます。技術面のコントロールを最初に変更しても、成功につながることはほとんどありません。

セキュリティ目標の最も効果的な達成方法を決定するには、明確なビジョンを抱き、目標を設定する必要があります。ほとんどの場合、これは、CISO とそのチームがコンフォートゾーンを抜け出して、テクノロジー部門、ビジネス部門、その他のパートナーと協力し、成功を収める必要があることを意味します。組織がオンプレミスでのこれまでのやり方に固執すると、クラウドトランスフォーメーションは非効率的になりやすく、ビジネス部門がアジリティとセキュリティを手に入れることはできなくなります。

MIT と連邦準備制度理事会が 9 月に主催した会議、金融サービス業界におけるサイバーリスクの測定では、聴講者の一人が「ファイル整合性監視プログラムがインストールされているかどうかをサイバー保険会社が尋ねるのはなぜか？」という重要な疑問をパネルに投げかけました。

サイバー保険会社によるこのような質問は、デジタルトランスフォーメーションプロセスに合わせて進化させる必要があるマインドセットを示しています。私たちは、手法やアーキテクチャについて再考する新たな機会を積極的に受け入れるべきです。ファイルの整合性だけを確保しても、組織の全体的なリスクの軽減にはほとんど効果がありません。サイバー保険会社が目的に応じてすべき質問は、「トランザクションフローにおいて重要な決済データが変更されるのをどのように防いでいますか？」や「本番環境で実行されているソフトウェアが承認され、変更されないことをどのように保証していますか？」などです。

ファイルの整合性を監視すれば、両方の質問に答えられるようになりますが、サイバー保険会社の質問票に記載されている質問に答えても、価値はほとんどありません。これらは〇×形式のチェックリストにすぎず、セキュリティ上のメリットはほぼ皆無です。クラウドは、標準的なコントロールに関する再考、そしてセキュリティ面とビジネス面におけるより優れた成果という 2 つの要素に、等しく機会を提供します。

クラウドでのセキュリティの実装を開始するにあたっては、組織にとって理想的なセキュリティ体制とはどうあるべきかを念頭に置き、どのように目標を設定して達成できるかについて関係者（ビジネスリーダーや IT リーダーを含む）と認識を一致させることが重要です。最初のステップは、組織がどれだけの圧力に耐えられるかを知る貴重な機会となります。1 回で成功する CISO はごく一握りですのでご安心ください。状況に柔軟に適応し、変更をいとわず、組織内の衝突を最小限に抑えるよう努めるべきです。

この議論の続きは、運用変革を開始する際の実際問題に焦点を当てた次回のブログで取り上げます。

詳細については、CISO のフラストレーション、成功、教訓に関するポッドキャストと、クラウドセキュリティの変革に関するガイダンスレポートをご覧ください。その他のホワイトペーパーやガイダンスについては、Google サイバーセキュリティ対応チームのサイトをご確認ください。

- Google Cloud、CISO オフィスディレクター David Stone
- Google Cloud、セキュリティソリューション戦略 Anton Chuvakin

Spanner でデータを保護する新しい方法として Cloud Spanner にきめ細かなアクセス制御を導入

Tue, 27 Sep 2022 09:10:00 +0000

※この投稿は米国時間 2022 年 9 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

無制限のスケーリング、強整合性、最大 99.999% の可用性を備えた Google Cloud のフルマネージドリレーショナルデータベースとして、Cloud Spanner は金融サービス、ゲーム、小売、ヘルスケアなどの業界におけるあらゆる規模のアプリケーションを強化します。本日、Spanner 向けのきめ細かなアクセス制御のプレビューを発表します。この機能により、Spanner のデータへのアクセスをテーブルと列のレベルで承認することが可能になります。また、きめ細かなアクセス制御により、Spanner でトランザクションデータを保護し、データへのアクセスを許可する際に適切な制御を行うことが、これまで以上に容易になります。

この投稿では、Spanner の現在のアクセス制御モデルできめ細かいアクセス制御のユースケースを検討します。また、Spanner アプリケーションで、この新しい機能を使用する方法についても見ていきます。

Spanner のアクセス制御モデルの現在

Spanner では、Identity and Access Management（IAM）によるアクセス制御を利用できます。IAM によって、Google Cloud のすべてのサービスにシンプルで一貫性のあるアクセス制御インターフェースが提供されています。組み込みの監査証跡やコンテキストアウェアアクセスなどの機能により、Spanner のユーザーに対してインスタンスおよびデータベースレベルの権限を簡単に付与できます。

IAM のモデルは、次の 3 つの主要な要素で構成されています。

ロール。ロールは権限の集合です。Spanner ではこれらの権限により、Spanner のプロジェクト、インスタンス、またはデータベースに対して特定のアクションを実行できます。たとえば、spanner.instances.create は新しいインスタンスを作成し、spanner.databases.select ではデータベースに対して SQL の select ステートメントを実行できます。Spanner には利便性を目的に、spanner.databases.read と spanner.databases.write の権限を持つ roles/spanner.databaseUser などの事前定義ロールが用意されていますが、独自のカスタムロールを定義することもできます。
IAM プリンシパル。プリンシパルは、リソースへのアクセスが許可されている Google アカウント（エンドユーザー向け）、サービスアカウント（アプリケーションまたはコンピューティングワークロード向け）、Google グループ、Google Workspace アカウントです。各プリンシパルには、一意の識別子（通常はメールアドレス）があります。
ポリシー。許可ポリシーは、1 つ以上のプリンシパルを個々のロールにバインドするロールバインディングの集合です。たとえば、roles/spanner.databaseReader を IAM プリンシパル user@abc.xyz にバインドできます。

より強固なアクセス制御の必要性

データベースレベルよりも詳細なレベルでロールを定義する必要があるユースケースが数多くあります。その一部を見てみましょう。

台帳アプリケーション

台帳は、在庫管理、暗号通貨、銀行のアプリケーションに有用で、在庫レベルを調べ、既存の残高に貸方や借方などの更新を適用できます。台帳アプリケーションでは、残高の確認、在庫の追加、在庫の削除ができますが、先週に戻って、在庫レベルを 500 ウィジェットに調整することはできません。これは、SELECT権限（残高の確認）と INSERT 権限（在庫の追加または削除）はあるものの、UPDATE 権限や DELETE 権限はないことを意味します。

アナリティクスユーザー

アナリティクスユーザーは Spanner データベースのいくつかのテーブルへの SELECT アクセスを必要とすることがよくあります。しかし、データベースのすべてのテーブルへのアクセス権を持つ必要はありません。また、データベース内のものに対して、INSERT、UPDATE または DELETE のアクセス権を持つ必要もありません。これは、データベース内のすべてのテーブルではなく、一部のテーブルに対して SELECT 権限を持つことに相当します。

サービスアカウント

サービスアカウントは特別なタイプの Google アカウントで、Google Cloud のデータにアクセスして認証を受ける必要がある人間以外のユーザーを表します。Spanner のそれぞれのサービスアカウントは、データベース内の特定のテーブルに対して独自の権限を持つ必要があると考えられます。たとえば、ライドシェアリングのアプリケーションで、運転手と乗客のサービスアカウントがある場合を考えてみましょう。運転手のサービスアカウントには、乗客のプロファイルテーブルの特定の列（ユーザーのファーストネーム、プロフィール写真など）の SELECT 権限が必要で、乗客のメールアドレスやその他の個人情報の更新は許可されるべきではありません。

Spanner におけるきめ細かなアクセス制御の基本

他のリレーショナルデータベースにおけるロールベースのアクセス制御に慣れている方は、Spanner におけるきめ細かいアクセス制御の重要なコンセプトをよくご存じのはずです。Spanner におけるきめ細かなアクセス制御のモデルを確認してみましょう。

データベース権限。Spanner は SELECT、INSERT、UPDATE、DELETE の 4 種類の権限をサポートするようになりました。SELECT、INSERT、UPDATE、DELETE 権限をテーブルに、SELECT、INSERT、および UPDATE 権限をテーブルまたは列に適用できます。
データベースロール。データベースのロールは、特権の集合です。たとえば、inventory_admin というロールが付与されている場合、SELECT 権限と INSERT 権限を Inventory_Transactions テーブルに対して適用し、SELECT 権限、INSERT 権限、UPDATE 権限、DELETE 権限をプロダクトの表に対して適用できます。

Spanner では ID とアクセスの管理に IAM が使用されているため、条件付きロールバインディングを管理することによって、適切な IAM プリンシパルにデータベースロールを割り当てる必要があります。

例を見てみましょう。IAM プリンシパル user@abc.xyz が Inventory_Transactions と Products の 2 つのテーブルにきめ細かくアクセスできるように設定するとします。そのために、inventory_admin というデータベースロールを作成し、このロールを user@abc.xyz に付与します。

ステップ 1: IAM プリンシパルを Cloud Spanner のきめ細かいアクセス制御ユーザーとして設定する

今日まで、IAM プリンシパルにデータベースレベルのアクセスを付与したい場合、roles/spanner.databaseUser ロール、またはそのロールにバンドルされている特権のいずれかを付与する必要がありました。きめ細かいアクセス制御では、代わりに IAM プリンシパルに Cloud Spanner のきめ細かいアクセス制御ユーザーロール（roles/spanner.fineGrainedAccessUser）を付与できるようになりました。

Cloud Spanner のきめ細かいアクセス制御ユーザーは、データベースへの API 呼び出しを許可しますが、public ロールに付与された以外のデータアクセス権限は付与されません。デフォルトでは、public ロールは何の権限も持っておらず、このロールはデータベースへの API 呼び出しを行うためのアクセス権のみを付与しています。データにアクセスするには、きめ細かいアクセス制御ユーザーが希望するデータベースロールを指定する必要があります。

ステップ 2: データベースのロールを作成する

ロールを作成するには、標準 SQL の CREATE ROLE コマンドを実行します。

CREATE ROLE inventory_admin;

新しく作成されたデータベースロールは、projects/<project_name>/instances/<instance_name>/databases/<database_name>/databaseRoles/inventory_admin というリソース URI で IAM ポリシーから参照可能です。後ほど、特定の IAM プリンシパルの権限をデータベースロールとして付与する IAM ポリシーの構成方法を紹介します。

ステップ 3: データベースロールに権限を割り当てる

次に、このロールに適切な権限を割り当てます。

code_block: <ListValue: [StructValue([('code', 'GRANT SELECT, INSERT\r\nON TABLE Inventory_Transactions\r\nTO ROLE inventory_admin;\r\n\r\nGRANT SELECT, INSERT, UPDATE, DELETE\r\nON TABLE Products\r\nTO ROLE inventory_admin;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a544150>)])]>

これらのステートメントは個別に実行することもできますが、Cloud Spanner DDL ステートメントを 1 つのバッチで発行することをおすすめします。

ステップ 4: IAM プリンシパルにロールを割り当てる

最後に user@abc.xyz がデータベースロール inventory_admin として機能するように、Cloud Spanner データベースロールのユーザーをデータベースロールを条件として user@abc.xyz に付与します。これを行うには、データベースの IAM 情報パネルを開き、IAM 条件エディタを使用して次の条件を追加します。

resource.type == “spanner.googleapis.com/DatabaseRole” &&
resource.name.endsWith(“/inventory_admin”)
また、このデータベースロールのアクセスをさらに制限するために、時間帯、曜日、有効期限でアクセスをスケジュールするなどの条件を追加することが可能。

きめ細かなアクセス制御への移行

きめ細かいアクセス制御に移行する際は、roles/spanner.databaseUser と roles/spanner.fineGrainedAccessUser の両方を IAM プリンシパルに割り当てることをおすすめします。IAM プリンシパルをきめ細かい権限に切り替える準備ができたら、IAM プリンシパルから databaseUser ロールを削除するだけです。

エンドユーザーとしてロールを利用する

エンドユーザーが Spanner にログインすると、付与されたロールを使って、Google Cloud コンソールや gcloud コマンドからデータベースにアクセスできます。また、Go、Java、Node.js、Python のクライアントライブラリがサポートされているほか、近日中にこのサポートの対象が増える予定です。

詳細

きめ細かなアクセス制御により、ユーザーやロール、所属する組織に応じて、Spanner データベースへのアクセス権を設定できます。現在のプレビュー版では、きめ細かいアクセス制御を追加料金なしで Spanner のすべてのお客様にご利用いただけます。

Spanner の使用を始めるには、インスタンスを作成するか、Spanner Qwiklab で試してみるか、無料のトライアルインスタンスを作成する
Spanner できめ細かいアクセス制御を始めるには、About fine-grained access control（きめ細かいアクセス制御について）を確認するか、Google Cloud コンソールの Write DDL statements から直接アクセスする
Spanner を始めるには、インスタンスを作成するか、無料で試用するか、Spanner の Qwiklabs を受講する

- Spanner プロダクトマネージャー Mark Donsky

DLP を使用した BigQuery の自動データリスク管理

Tue, 28 Jun 2022 09:00:00 +0000

※この投稿は米国時間 2022 年 4 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

センシティブデータの保護および意図しないデータ漏洩の防止は、企業にとって非常に重要です。しかし、多くの組織にはセンシティブデータが社内のどこにあるのかを常に把握するためのツールがありません。特に問題なのは、意外な場所にセンシティブデータが生じる場合です。たとえば、顧客がカスタマーサポートとのチャットにうっかりセンシティブデータを送信したり、組織が非構造化された分析ワークロードを管理したりする際に、サービスが生成するログにセンシティブデータが含まれる場合です。BigQuery 向け自動データ損失防止（DLP）機能が役立つのはこうした場面です。

データの検出や分類はオンデマンドで手作業によって行われることが多く、多くの組織では思うほど頻繁に実施できていません。大量のデータが常時生成される環境においては、検出や分類の機能を既存のデータ分析ツールに組み込むのが、効率的で現代的な方法です。自動化すれば、リスクを発見するための重要な対策が常に実行されていることになります。これは、Google Cloud の「見えないセキュリティ」戦略の一例です。自動 DLP は、組織全体のデータを継続的にスキャンするフルマネージドサービスです。これにより組織は、どんなデータがあるかを全般的に認識するとともに、センシティブデータが具体的にどこに保存され、処理されているかを把握できます。この認識は、データの保護と統制の重要な第一歩であり、セキュリティ、プライバシー、コンプライアンス対策を支える重要な管理手段として機能します。

昨年 10 月、Google は BigQuery 向け自動 DLP を発表しました。発表以来、導入企業は数ペタバイトの規模で BigQuery の構造化データと非構造化データのスキャンと処理を行うことで、どこにセンシティブデータがあるかを特定し、データリスクを可視化しています。この自動 DLP の一般提供を開始することは、Google にとって非常にうれしいことです。リリースの一環として、さらにデータの理解を容易にし、より多くの Cloud ワークフローで情報を活用するための新しい機能もいくつか追加しました。たとえば次のような機能です。

作成済みのデータポータルダッシュボード。ビジネスニーズに応じてカスタマイズできる高度なサマリー、レポート、調査ツールを備えています。

わかりやすいダッシュボードで BQ のデータの概要を把握

データのプロファイリングや再プロファイリングの頻度や条件を調整できるきめ細かい制御機能。データの特定のサブセットを他より高い頻度または低い頻度でスキャンしたり、プロファイリングから除外したりすることも可能です。

データをスキャンする頻度の細かい設定

各テーブルの DLP プロファイラ情報とリスクスコアを Google のセキュリティ分析プラットフォームである Chronicle に自動同期する機能。Google は自社セキュリティポートフォリオの相乗効果の向上に努めており、今回のインテグレーションでは、アナリストが Chronicle を使用してインシデントに巻き込まれている可能性のある BQ データに高い価値があるかどうかを即座に把握できるようにしました。これは、脅威の検出、優先順位付け、セキュリティ調査の強化に大きく役立つ可能性があります。たとえば Chronicle が複数の攻撃を検出した場合、そのうち 1 つが機密性の高いデータを対象としていることがわかれば、最も緊急な脅威を優先して調査し、最初に対処できます。

Chronicle との緊密でネイティブなインテグレーションが検出と対応をスピードアップ

データ分類でデータリスクを抑制

一般に特に注意が必要なセンシティブデータには、クレジットカード、医療情報、社会保障番号、政府発行の ID、住所、フルネーム、アカウント認証情報などがあります。自動 DLP は、機械学習を利用するほか、150 以上の定義済み検出項目によってセンシティブデータを調査、分類、統制し、適切な保護対策を支援します。

センシティブデータを明確に把握できさえすれば、問題に対処したり、データリスクを全体的に減らしたりする方法は数多くあります。たとえば、IAM を使用してデータセットやテーブルへのアクセスを制限する、BigQuery ポリシータグを使用して詳細なアクセスポリシーを列レベルで設定するといった方法があります。Google の Cloud DLP プラットフォームには、詳細かつ徹底的なデータ検査をオンデマンドで実行する、またはデータの難読化、マスク、トークン化によって全体的なデータリスクを軽減するためのツール群も揃っています。分析や機械学習にデータを使用する際はこの機能が特に重要です。なぜなら、ユーザーのプライバシーやプライバシー規制へのコンプライアンスを確保するため、センシティブデータを適切に取り扱う必要があるためです。

ご利用方法

自動 DLP は、組織全体、選択した組織フォルダ、各プロジェクトに対して有効化できます。これらの新機能の詳細を確認する、または早速利用を開始する場合は、Cloud Console の [Cloud DLP] ページを開いてドキュメントをご覧ください。

- Google Cloud プロダクトマネージャー Scott Ellis

Google Cloud での品質管理システムのモニタリング

Wed, 01 Jun 2022 03:10:00 +0000

※この投稿は米国時間 2022 年 5 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

グローバル企業にソフトウェアとサービスを提供する Google Cloud は、プロダクトの品質とセキュリティがお客様からの信頼を維持するうえで重要であることを理解しています。Google Cloud は、お客様による品質管理の目標達成をサポートするプロダクトとサービスを提供し、その結果お客様の組織が規制の要件と顧客の要求を満たせるよう支援することに尽力しています。この取り組みの中心にあるのは Google Cloud の強固な品質管理システム（QMS）です。これはプロダクトおよびサービスのライフサイクルのすべての段階において高水準の品質を実現することを目的とするプロセスベースのアプローチであり、ISO 9001:2015 認証を活用します。

Google が最近発表した品質管理システムに関するホワイトペーパーでは、Google が採用している品質管理の原則とプラクティスを紹介しています。これらに従うことにより、プロダクトとサービスの品質を継続的にモニタリング、管理、改善する、明確かつ一貫したプロセスを確立できます。ISO 9001 と同様、Google Cloud の QMS は 7 つの品質管理の原則を基礎としています。これらの原則は次の通りです。

お客様重視: お客様から寄せられたフィードバックによると、お客様はセキュリティ、スピード、信頼性、効率を重視しています。Google は、効果的なソフトウェア開発プロセスとお客様とのコミュニケーションのための明確なプラクティスに従うことによってこれを実現できると考えています。そのため、QMS の主要な要素として、システム開発のライフサイクル（SDLC）と Cloud Platform のサポート（CPS）に重点を置いています。
リーダーシップ: Google の品質管理プログラムの基盤となるのは、セキュリティエンジニアリング担当バイスプレジデントによって管理される品質ポリシーです。このポリシーが目的とするのは、Google Cloud プロダクトおよび関連するソフトウェア開発プロセスの品質の管理と維持、製品品質の問題から生じるリスクの抑制、継続的な改善の促進、そしてお客様、法律、規制に関連する要件の遵守です。
人々の積極的関与: Google は、効果的で効率的な QMS には、お客様や従業員など、多様な視点や異なる背景を持つ人々が関与することが大切であると考えています。また、適切な評価、権限委譲、学習機会などを通じて、これらの人を個人として尊重し、サポートすることも重要だと考えています。Google は、人々の要望を理解したりフィードバックを集めたりすることによって、QMS の取り組みの最初の段階から人々と関わっています。
プロセスアプローチ: Google Cloud の QMS では、プロセスの計画に PDCA（Plan-Do-Check-Act）アプローチを活用しています。Google は、品質管理の目標を達成するために、次の 4 つの主要なプロセスグループを定義しました。リーダーシップと計画のプロセス、ソフトウェアの設計と開発のための運用プロセス、評価およびモニタリングプロセス、改善プロセスです。これらのプロセスのインプット、アクティビティ、コントロール、アウトプット、インターフェースを管理することにより、システム有効性を確立し、維持できます。
改善: 品質管理に対するプロアクティブなアプローチは、品質の改善とビジネスチャンスの拡大に役立つため、組織全体でオペレーションが最適化され、パフォーマンスが向上します。
客観的事実に基づく意思決定: QMS をビジネス戦略に適合させるために、Google では内部および外部の情報源からの適切な情報を照合して分析し、現状に対する潜在的な影響と次の戦略を判断します。
関係性管理: Google は、サービス提供の背後で行われるデータ処理を自分たちで実施しています。とはいえ、カスタマーサポートやテクニカルサポートに関連するサービスの提供をサードパーティに依頼することもあります。そのような場合は、ベンダーオンボーディングプロセス（Google に対するベンダーの要求の検討も含む）を実施することにより、合理的なサプライチェーンの統合を実現します。

競争と変化が激しく、規制が厳しくなる一方の今日の状況において、品質は経営陣にとっての重要課題です。こうした状況において Google は、プロダクトとサービスの品質を最高水準に保つことにより、お客様が品質によってビジネスを変革し、品質面で一歩先を行くことを可能にしています。Google Cloud の品質管理についての詳細は、ホワイトペーパーをご覧ください。

- Google Cloud エンタープライズトラスト責任者 Rani Urbas

Google Cloud CLI の Terraform 用ポリシーガードレールプレビュー版に関するお知らせ

Mon, 30 May 2022 01:20:00 +0000

※この投稿は米国時間 2022 年 5 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

Terraform は人気の高いオープンソースの Infrastructure as Code（IaC）ツールで、今や世界中のあらゆる規模の組織で使用されています。デベロッパーとしてローカルで使用する場合でも、複雑な CI / CD パイプラインを運営するプラットフォーム管理者として使用する場合でも、Terraform なら Google Cloud 上にインフラストラクチャを簡単にデプロイできます。

このたび、クライアント側のツールである gcloud beta terraform vet についてお知らせできることをうれしく思います。このツールは追加料金なしで利用でき、インフラストラクチャのデプロイや既存のインフラストラクチャパイプラインに対するポリシー検証を可能にします。今回のリリースにより、Terraform の google および google-beta プロバイダの任意のリソースに対するポリシーを記述できるようになります。すでに GitHub で Terraform Validator を使用している場合は、移行手順に沿って、この新機能をお試しください。

課題

Terraform を使用したインフラストラクチャの自動化は、アプリケーションを提供するために組み合わせて使用するインフラストラクチャやサービスのデプロイを自動化することで、アジリティを向上させるとともに、エラーを減少させます。

企業は、継続的デリバリーを実装することで、より迅速にアプリケーションを開発し、変更に素早く対応することができます。インフラストラクチャに対する変更はありふれたもので、多くの場合、頻繁に起こります。特に、複数のビジネスユニットにまたがり、自動化された方法でリクエストを迅速かつ効率的に処理するインフラストラクチャについては、その変更のすべてを監視することが困難になる場合があります。組織で Terraform をスケールするにつれて、構成ミスやヒューマンエラーが生じるリスクが高まります。人の手で構成の変更を記述すると、インフラストラクチャの脆弱性修正に要する時間が延び、組織がコンプライアンス上または予算上のリスクにさらされかねません。組織が大規模に、安全に、費用対効果の高い方法で迅速に行動するには、ポリシーガードレールが必要です。そしてガードレールを設けるのが開発プロセスの早い段階であればあるほど、将来の監査における問題を回避することができます。

ソリューション

gcloud beta terraform vet は、Terraform の構成にガードレールとガバナンスを提供し、組織のポリシー違反となる Google Cloud リソースの構成ミスを減らすことができます。

gcloud beta terraform vet を使用すると、以下のようなメリットがあります。

アプリケーション開発のあらゆる段階で組織のポリシーを適用する
ポリシー検証を自動化し、手動によるエラーを排除する
デプロイ前のチェックによるフェイルファストを実践する

新機能

CAI ベースの制約を作成できることに加え、Terraform の google および google-beta プロバイダの任意のリソースに対するポリシーを記述できるようになりました。この機能は、Terraform Validator の既存のユーザーから GitHub で受け取ったフィードバックをもとに追加されました。この機能を利用するには、今すぐ gcloud beta terraform vet に移行してください。

ポリシー検証の主なユースケース

プラットフォームチームは、インフラストラクチャ CI / CD パイプライン（計画段階と適用段階の間）にガードレールを簡単に追加して、クラウドにデプロイする前にインフラストラクチャに対するすべてのリクエストを検証することができます。これにより、デプロイ前のチェック中に、エンドユーザーに違反したポリシーを知らせるエラーメッセージが送信されるようになり、プラットフォームチームが関与する場面が削減されます。

アプリケーションチームと開発者は、組織の中央ポリシーライブラリに対して Terraform の構成を検証し、開発プロセスの早い段階で構成ミスを特定できます。CI / CD パイプラインに送信する前に、Terraform の構成が組織のポリシーを遵守していることを簡単に確認できるため、時間と労力を節約できます。

セキュリティチームは、組織全体のすべてのチームがポリシー違反を特定・防止するために使用する一元化されたポリシーライブラリを作成できます。個々のポリシーについては、組織の構造に応じて、セキュリティチームまたは他の信頼できるチームが、会社のニーズまたはコンプライアンス要件に応じて必要なものを追加することが可能です。

使ってみる

ポリシーガードレールの利用を開始する方法については、クイックスタートに詳細な手順が記載されています。ここではプロセスの概要を簡単に見ていきます。

1. まず、ポリシーライブラリのクローンを作成します。ポリシーライブラリには、スタート用のサンプル制約テンプレートとバンドルが含まれています。これらの制約テンプレートは、制約が使用するロジックを指定するものです。

2. 制約を policies/constraints フォルダに追加します。これは適用するポリシーを表すものです。たとえば、IAM ドメイン制限の制約により、IAM ポリシーメンバーが「gserviceaccount.com」ドメイン所属のものに限られるようになります。他のサンプルについては、サンプル制約をご覧ください。

code_block: <ListValue: [StructValue([('code', 'apiVersion: constraints.gatekeeper.sh/v1alpha1\r\nkind: GCPIAMAllowedPolicyMemberDomainsConstraintV2\r\nmetadata:\r\n name: service_accounts_only\r\n annotations:\r\n description: Checks that members that have been granted IAM roles belong to allowlisted\r\n domains.\r\nspec:\r\n severity: high\r\n match:\r\n target: # {"$ref":"#/definitions/io.k8s.cli.setters.target"}\r\n - "organizations/**"\r\n parameters:\r\n domains:\r\n - gserviceaccount.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a95e690>)])]>

3. Terraform plan を生成し、JSON フォーマットに変換します

code_block: <ListValue: [StructValue([('code', '$ terraform show -json ./test.tfplan > ./tfplan.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2d1cd0>)])]>

4. terraform-tools という名前の gcloud コンポーネントをインストールします

code_block: <ListValue: [StructValue([('code', '$ gcloud components update\r\n$ gcloud components install terraform-tools'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2d3550>)])]>

5. gcloud beta terraform vet を実行します

code_block: <ListValue: [StructValue([('code', '$ gcloud beta terraform vet tfplan.json --policy-library=.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2d31d0>)])]>

6. 最後に、結果を表示します。ポリシーチェックに違反した場合は、次の出力が表示されます。

合格:

code_block: <ListValue: [StructValue([('code', '[]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2d0990>)])]>

失敗: 合格時よりも出力が長くなります。以下は抜粋です。

code_block: <ListValue: [StructValue([('code', '[\r\n{\r\n "constraint": \r\n… \r\n\r\n"message": "IAM policy for //cloudresourcemanager.googleapis.com/projects/PROJECT_ID contains member from unexpected domain: user:user@example.com",\r\n…\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a2d2790>)])]>

フィードバック

この機能の活用法や、Google で実施できる改善のアイデアについて、ご意見をお待ちしています。

- Terraform プロダクトマネージャー Arslan Saeed
- ソフトウェアエンジニア / TL Stephen Lewis

テクノロジーによってどのように効率的で透明性の高い安全な金融市場の基盤が築かれているのか

Mon, 04 Apr 2022 02:20:00 +0000

※この投稿は米国時間 2022 年 3 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

金融市場は新しいテクノロジーを先駆けて採用した市場の一つであり、これはまた、電子商取引をいち早く取り入れたデリバティブ市場にも当てはまります。今後、業界関係者のコミュニケーション、分析、取引の方法が新たな機能によって大きく変わっていくと見込まれています。

FIA Boca 2022 にて、Google Cloud の Phil Moyer と元 SEC コミッショナーの Troy Paredes 氏にインタビューし、今後の市場やポリシー、スピード感と透明性の向上に向けてすでにその貢献が認められつつある新しいテクノロジーについてお話を伺いました。また、市場の長期的なビジョンを実現するために、クラウドによってどのように復元性、パフォーマンス、セキュリティの向上を促進できるかについても論じられました。以下はその要約です。

クラウドテクノロジーの現状

テクノロジーの採用という点においては、市場および市場参加者によるクラウドテクノロジーと、さらには機械学習（ML）の導入がますます拡大しています。クラウドテクノロジーにより、大規模なデータセットや ML のテストがより簡単かつ迅速に、そしてはるかに安全になります。

Google のスポンサー提供のもと Coalition Greenwich が行った最近の調査（2021 年 9 月）によると、取引システム、取引所、データプロバイダの 93% 以上がなんらかの形でクラウド上でのサービスを提供していることがわかりました。同調査では、バイサイドかセルサイドかを問わず金融業界の約 72% が、パブリッククラウドデータをベースとする市場データを今後 1 年以内に利用する意向を持っていることが明らかになっています。

データドリブンな意思決定とリスク管理は、これまでも、そしてこれからも、金融市場にとって不可欠なものです。時の経過とともに、技術革新によってデータからより深く詳細な分析情報を得られるようになり、その結果、より優れた意思決定とリスク管理を行えるようになりました。このようにデータを高度に活用する取り組みは現在の主流となっており、今後さらに洗練されていくことでしょう。

複数のフェーズで考えるテクノロジーの軌跡

取引所のクラウド化には、「Crawl-Walk-Run（ハイハイ - 歩く - 走る）」と呼ばれる方式を取り入れて、簡単なことから着手し、徐々に範囲を拡大していきます。短期的にはまず簡単に達成できる目標が選定され、中長期的にはより大きな抜本的変革に取り掛かります。なかには、この 3 つのステージは進むペースが異なることを承知したうえで、それらを同時に開始する組織もあります。

「Crawl」のフェーズでは、組織はまずデータをクラウドに移行し、ある程度の分析を試みるなどして、基盤を構築します。これは、透明性を高め、リスク管理の機会を具体化する最も重要なフェーズの一つです。

人、プロセス、テクノロジーの組み合わせにそれまで依存していたインフラストラクチャは、クラウドに移行すると、アプリケーションを実行するコードに置き換えられます。初期に行われるこのフェーズは、組織がクラウドベースかつアジャイル優先の運用モデルに移行するための鍵となります。これにより、よりミッション重視の作業に注力できるよう、スタッフやリソースを IT 管理から解放することもでき、その後の新製品をより簡単かつシームレスにリリースできるようになります。

クラウドの運用モデルを確立することで、コンプライアンスの自動化が進み、レイテンシの影響を受けやすいアプリケーションの運用が容易になります。また、次世代の取引所、市場参加者、規制当局が将来の課題に備えてしっかりと対応できるようになり、「Walk」と「Run」のフェーズを簡素化できます。

「Walk」のフェーズでは、多くのイノベーションが行われます。ここで取引所は大きな進歩を遂げています。決済、清算、リスク管理、担保管理、コンプライアンスの改善や、新製品のリリースに、「Crawl」フェーズでの基本的なデータに基づく意思決定と、クラウドのイノベーションが活用されています。

そして最後に「Run」フェーズです。この段階で、企業はレイテンシの影響を受けやすい市場をクラウドに移行し始めます。市場では、これまでの市場アクセスに対する障害を解決するため、透明性や分析とともに、低レイテンシと高パフォーマンスがますます求められるようになるためです。

規制当局と市場参加者双方にとっての機会

規制当局は、特に法令遵守の観点から、大きな技術的変化が行われた際には必ずその影響を調査します。

技術的な変化により、規制当局と市場参加者の双方がより多くの機会を得られるようになってきています。また、このような変化によって整合性や透明性が向上し、市場の保護の強化につながる場合もあります。

時間の経過とともに、規制制度（規則、規制、法令、解釈、ガイダンス）も新しいテクノロジーに適応し、市場に利益をもたらすとともに、規制の目標を推進することになるのです。

その一例として、クラウドでは、コンプライアンスをトランザクションに組み込めるようにすることで、コンプライアンス要件に対応する能力を高めています。さらに、規制業界にはリアルタイムでの規制報告というビジョンがあり、ここ数年ペースを上げている市場の技術的進展も後押しとなり、さまざまな規制当局がより高度な分析を使用するようになっています。この傾向は今後も続き、より効果的かつ効率的に規制目標を達成し、市場全体についての期待を監視、実現していくための規制当局の推進力となるでしょう。

金融市場における機械学習の役割

Google Cloud の AI および業種別ソリューション担当責任者である Andrew Moore は、ML が今後 10 年で、「意味を与える」、「コンシェルジュサービスを提供する」、「保護管理者的な役割を果たす」という 3 つの重要な仕事を行うようになるだろうと述べています。投資家の意思決定に不可欠な情報を抽出することは極めて重要です。かつてないほど多くのデータを使用することで、ML はその処理能力を高めると同時に、クラウド上でのアクセス性も向上させ、法令遵守をより適切にサポートできるようになります。

ML は、市場の機能として導入されるようになると、取引、マネーロンダリング防止、さまざまなリスク管理の分野で力を発揮すると予想されます。意思決定、監視、保護の面で投資家と規制当局の双方の利益をサポートするものになるでしょう。

人をプロセスから排除するわけではありません。人の持つ専門知識はこれからも重要な目標の達成に欠かせません。市場、アセット、ガードレールのデジタル化と ML を組み合わせることで、そうした知識をさまざまな仕方で発揮できるようになるのです。

将来に向けた市場基盤の構築

運用上の復元力、セキュリティ、プライバシーに関する目標が、市場参加者と規制当局の双方にとって、市場の基盤を構築するうえで鍵となる点は今後も変わりません。そのため、テクノロジーの導入には具体的で目に見えるメリットがあるとはいえ、その潜在的なリスクや懸念事項を精査することが重要です。

テクノロジープロバイダにとっての優先事項は、転送データの暗号化や保存データの暗号化を含むゼロトラストセキュリティ環境を構築して、そのインフラストラクチャ上で実行されるすべての取引に信頼を付加しつつ、同時に市場の運用上の復元力を保証することです。マルチクラウドのアーキテクチャとアプローチも、運用の復元性を高めるソリューションに組み込むことを検討できます。

いつの時代も、流動性はアクセス、透明性、安全性の向上の結果でした。テクノロジープロバイダは、将来の市場に対する責任を引き受けるだけでなく、その運命共同体ともなり、金融業界の効率、スピード、透明性、セキュリティを改善するため、日々奮闘しています。

Google のアプローチの詳細については、最新のホワイトペーパー「Building the financial markets foundation for the future」をご覧ください。

- Google Cloud シニアカウンセル Behnaz Kibria

米国と EU 間でのデータ移転の新たな枠組みに関する発表を踏まえた EU 域内のビジネスに対する Google Cloud の取り組みの最新情報

Fri, 01 Apr 2022 01:00:00 +0000

※この投稿は米国時間 2022 年 3 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。

先週、欧州委員会と米国政府は、米国と EU 間のデータ移転に関する新たな枠組みについて合意しました。今朝ほど Google は、EU のデータに対するプライバシー保護を強化し、高信頼性の大西洋横断データフローを促進する米国政府の取り組みを歓迎することを表明しました。Google Cloud のお客様には、この新たな枠組みが施行されしだい、枠組みに基づいた保護を利用していただけるように計画しています。

昨年 Google は、欧州の最高裁判所が EU-US Privacy Shield（EU-US プライバシーシールド）フレームワークを無効であるとし、EU 標準契約条項（SCC）を支持したことに伴い、欧州データ保護会議（EDPB）が補助的な施策に関する勧告を発表したことを受け、EU 域内のビジネスに対する取り組みを再確認しました。

これ以降、Google は業界をリードする技術的な管理手段、契約責任、リスク評価のためのリソースを提供することで、お客様が厳格なデータ保護要件を満たせるようにサポートを続けています。また、大西洋横断データフローの法的な確実性をより高めるための支援も引き続き行っていきます。

今日は、この取り組みに関してお客様に最新情報を提供していきます。

お客様がコントロールするクラウド

Google Cloud1 は、これからも技術的な管理とセキュリティ管理の先進的なプロバイダであり続け、お客様のデータ保護要件や、高まるデータ主権への期待を満たすためのサポートを提供します。

Google は、顧客管理の暗号化および増え続ける主要プロダクトやローカルパートナーとの連携のためのデータローカリゼーションの提供などによって、欧州の規約に沿ったクラウドの構築に取り組んでいます。そして、欧州のビジネスや組織に新たな成長と変革の波を届けながら、最高水準の主権も提供しています。

Google Cloud Platform

Google は最近、EU 向けの Assured Workloads の一般提供について発表しました。このプロダクトでは、以下によって Google Cloud Platform（GCP）のお客様がデータを保護する際のサポートを行っていきます。

任意の EU 内の Google Cloud のリージョン内にデータを保存
データへのアクセスとカスタマーサポートを EU 域内ユーザーに制限
顧客が管理する暗号鍵など、データアクセスの暗号化による制御をデプロイ

Cloud External Key Manager（EKM）は、Google のインフラストラクチャの外部にデプロイされたサードパーティの鍵管理システムで保存、管理されている暗号鍵を使用して、お客様によるさまざまなサービスのデータの暗号化を実現します。Google Cloud は、クラウドに存在するデータの暗号鍵をプロバイダのインフラストラクチャの外にお客様が保存および管理でき、行政機関によるアクセスリクエストを含む特定の事由に基づく復号に対してお客様によるコントロールが行える、唯一のクラウドプロバイダであり続けています。

Key Access Justifications は、外部でホストされている鍵を使用してデータを復号するたびに Justification を提示することで、GCP をご利用のお客様によるデータのコントロールを大いに進歩させています。署名付きアクセス承認（SAA）は、さらなる保証による強化が行われており、管理者による顧客データや構成へのアクセスに対しては、顧客からの明示的な同意を必須条件としています。

Google Cloud の Confidential Computing ポートフォリオは、特に機密性が高いデータを使用中であってもお客様が暗号化できる画期的なテクノロジーです。ユビキタスなデータ暗号化は、保存データ、使用中のデータ、転送中のデータを暗号保護することで、データ保護をさらに拡充します。GCP の外部にある顧客データを Cloud EKM を使って暗号化する際に使用された鍵は、機密環境内で運用しているアプリケーションによって安全に共有されます。

Google Workspace

Google Workspace（Workspace for Education を含む）のお客様は、対象となるデータを欧州に保存することを選択できます。さらに、クライアントサイド暗号化では、お客様が暗号鍵と、鍵にアクセスするために選んだ ID サービスを直接コントロールできる方法を提供しています。クライアントサイド暗号化を使うと、Google はお客様のデータを解読できなくなりますが、ユーザーは Google ネイティブのウェブベースのコラボレーション、モバイルデバイス上のコンテンツへのアクセス、暗号化されたファイルの外部との共有を引き続き利用できます。クライアントサイド暗号化は、現在のところ Google ドライブ、ドキュメント、スプレッドシート、スライドで公開ベータ版として使用できます。今後、Gmail、カレンダー、Meet にも拡大される予定です。加えて、お客様は特定の Google Workspace サービスで、同様の暗号化機能を提供するサードパーティのソリューションを選ぶことでもメリットが得られます。

国際的なデータ移転の法的根拠

Google は、GCP および Google Workspace と Cloud Identity のデータ処理規約を更新し、2021 年 6 月 4 日に欧州委員会によって承認された新しい EU の標準契約条項（SCC）、および別途、英国の SCC のさまざまなモジュールを盛り込みました。

Google Cloud は、米国と EU 間のデータ移転に関する新たな枠組みを導入し、転送ソリューションとしてクラウドのお客様に提供する予定です。詳しくは、データ処理規約をご覧ください。

支援および追加の役立つリソース

Google は業界の仲間たちと一緒に、Trusted Cloud Principles（信頼できるクラウド原則）を採用することで、Google Cloud のお客様の権利を守る取り組みを実践しています。Google は、行政機関によるデータアクセスに対する経済開発協力機構の取り組みや、監視法改革の手段としての CLOUD 法の合意交渉（米国と EU 間を含む）を継続してサポートしていきます。

Google では、Google Cloud による国際的なデータ移転のための安全保護対策に関するホワイトペーパーなどを、参考資料としてクラウドプライバシーリソースセンターに継続して公開していきます。

欧州にユーザーを擁する数百万もの組織が、Google のクラウドサービスを使用して日々のビジネス活動を行っています。Google は、多様なコンプライアンスツールのセットを維持していくことで、こうした組織が規制要件を満たせるよう支援を継続してまいります。

^{1. Google Cloud: Google Workspace（Google Workspace for Education を含む）と Google Cloud Platform（GCP）}

- Google Cloud プライバシー部門ディレクター兼グローバル責任者 Marc Crandall
- Google Cloud プライバシー規制戦略とコンプライアンス担当責任者 Nathaly Rey

Google Cloud の Professional Service Organization と連携して政府機関のコンプライアンスを加速

Tue, 29 Mar 2022 02:30:00 +0000

※この投稿は米国時間 2022 年 3 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

パブリッククラウドコンピューティングへの企業の IT 支出が、2025 年までに従来型の IT 支出を超える見込みであることをご存じでしょうか。アプリケーションソフトウェア、インフラストラクチャソフトウェア、ビジネスプロセスサービス、システムインフラストラクチャに対する IT 支出の 51％がパブリッククラウドに移行すると予測されています（2022 年は 41％）1。企業のクラウドへの移行が急速に進む中、政府機関はセキュリティとコンプライアンスの導入を優先的に急ぐ必要があります。

2021 年 5 月に米国政府が発令した大統領令では、米国の政府機関に、クラウド導入を加速させ、セキュリティのベストプラクティスを取り入れ、ゼロトラストアーキテクチャの導入計画を策定し、導入の枠組みを FedRAMP に合わせることを求めています。政府が安全なクラウドの導入に重点を置くことは、サイバーセキュリティ優先への大々的な方針転換を意味します。Google Cloud の公共部門向け Professional Services Organization（PSO）は、専門的なコンサルティングを通じて、お客様がクラウドにおけるセキュリティとコンプライアンスの要件を満たせるよう支援する取り組みを行っています。

Authority to Operate（ATO）を加速

FedRAMP（Federal Risk and Authorization Management Program: 米国連邦政府によるリスクおよび認証管理プログラム）は、2011 年に確立された政府規模のプログラムで、連邦政府全体で安全なクラウドサービスの導入を推進しています。FedRAMP は、クラウドテクノロジーと連邦政府機関のセキュリティ評価とリスク評価に対する、標準化されたアプローチを提供しています。米国の政府機関は、連邦政府のクラウドコンピューティング戦略「クラウドファースト」の一環として、FedRAMP 認定のクラウドサービスを利用、導入するよう求めています。

Google Cloud は FedRAMP 認定のクラウドサービスプラットフォームと、FedRAMP 承認の豊富なプロダクトやサービス（92 のサービス、さらに増加中）を提供していますが、それでもお客様は使用するプロダクトやサービスにおいて Agency ATO を達成する任務を負っています。そのような状況の中で、Google Cloud ではお客様のこの任務を支援するために数多くのリソースを提供しています。Google Cloud の FedRAMP パッケージにアクセスするには、FedRAMP Package Access Request Form にご記入のうえ、info@fedramp.gov に送信してください。また、管理策実装の文書化の出発点として、Google の NIST 800-53 ATO Accelerator をご利用いただけます。最終的に、Google Cloud の公共部門向け PSO は、以下の戦略的コンサルティングエンゲージメントを提供し、お客様が Agency ATO プロセスを円滑化できるよう支援します。

Cloud Discover: FedRAMP は 6 週間のインタラクティブワークショップで、Google Cloud の ATO プロセスに取り組み始めたばかりのお客様が対象です。お客様は、FedRAMP の基礎、Google のセキュリティ体制とコンプライアンス体制、Google Cloud で ATO にアプローチする方法について学びます。PSO は、綿密なインタビューと設計セッションを通じて、お客様が実行可能な ATO 計画を策定し、FedRAMP の準備状況を評価して、概念的な ATO 境界を構築できるよう支援します。このエンゲージメントにより、お客様は Google Cloud の FedRAMP ATO について明確に理解し、これに向けてのロードマップを確立できます。
FedRAMP Security Review は、FedRAMP の運用準備においてお客様を支援する 10〜12 週間のエンゲージメントです。PSO のコンサルタントは、FedRAMP アーキテクチャを細かく検証し、NIST 800-53 セキュリティ管理策実装と、Google Cloud の安全なアーキテクチャのベストプラクティスとの潜在的なギャップを特定します。セキュリティレビューの結果は、構成ガイダンスと推奨事項を添えてお客様と共有されます。このエンゲージメントにより、お客様は FedRAMP ATO に必要な第三者機関や独立機関によるセキュリティ評価に向けて準備を整えることができます。
Cloud Deploy: FedRAMP は数か月のエンゲージメントで、お客様が FedRAMP の Low、Moderate、High レベルでの Google Cloud の Agency ATO に備え、FedRAMP システムセキュリティプラン（SSP）と、対応する NIST 800-53 セキュリティ管理策の内容を文書化できるよう設計されています。PSO は、お客様と協力して、FedRAMP システムアーキテクチャ、セキュリティ管理策実装、データフロー、システムコンポーネントの証拠を反映した、詳細な技術インフラストラクチャ設計ドキュメントとセキュリティ管理策のマトリックスを作成します。また、PSO が第三者評価組織（3PAO）や独立評価機関（IA）と提携し、FedRAMP セキュリティ評価に対するお客様の取り組みをサポートすることも可能です。このエンゲージメントにより、お客様のシステムオーナーは Agency ATO の評価やパッケージ提出の準備ができます。

ゼロトラスト戦略の開発

公共部門向け PSO は、FedRAMP に関する支援に加え、Google Cloud の最高情報セキュリティ責任者（CISO）チームと連携して、ゼロトラストのアーキテクチャと戦略の開発も支援しています。

Zero Trust Foundations は、Google Cloud の CISO チームと PSO チームが共同で提供する 7 週間のエンゲージメントです。CISO と PSO は、ゼロトラストの基礎、Google の BeyondCorp を通じたゼロトラストへの道のり、多層防御のベストプラクティスについてお客様に情報を提供します。CISO チームは、お客様とともに組織のゼロトラスト評価（ZTA）を進め、現在のセキュリティ体制と成熟度を理解します。その後、ZTA から得た分析情報をもとに、お客様と協力して、ゼロトラストの導入において最初の移行に適したワークロードを特定します。CISO による ZTA に続き、PSO が詳細なゼロトラストワークショップ（ZTW）を実施し、お客様の主要な関係者と協力して、特定された最初の移行対象ワークロードに対して NIST 800-207 に沿ったクラウドに依存しないゼロトラストアーキテクチャを策定します。ゼロトラストアーキテクチャは、2022 年 1 月に発表された米国行政管理予算局（OMB）の連邦政府ゼロトラスト移行戦略で指摘された重点分野に基づく、包括的なゼロトラスト戦略の成果物の一部となります。

PSO と連携して安全なクラウド導入を拡大

公共部門向け PSO は、実績ある手法を用いて、Google の技術的専門知識、クラウド戦略、実装ガイダンス、トレーニング、支援を提供し、お客様を成功へと導きます。企業の IT、運用、組織のモデルが進化し続ける中、Google の目標は、政府機関がクラウドでのセキュリティとコンプライアンス実現への道のりを加速できるよう支援することです。連邦政府との取り組みについて詳しくは、cloud.google.com/solutions/federal-government をご覧ください。

^{1 Gartner の見解: 2025 年までには主要な市場セグメントで企業の IT 支出の半分以上がクラウドに移行する}

- Google Cloud プロフェッショナルサービス公共部門担当戦略的クラウドアドバイザー Adrienne Wilkins

第三者のリスク管理プロバイダを活用して Google Cloud のベンダーデューデリジェンスを促進

Thu, 24 Mar 2022 01:10:00 +0000

※この投稿は米国時間 2022 年 3 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

お客様に革新的なソリューションやエクスペリエンスを提供するためにクラウドサービスの導入を加速させている企業では、リスクチームやコンプライアンスチームがデューデリジェンスプログラムを整備することで、ビジネスクリティカルなワークロードのアウトソーシングに付随するリスクをより深く理解し管理しようとしています。こうした取り組みの核にあるのは、複雑な世界規模での規制の要件、枠組み、ガイドラインに沿ったコンプライアンスを維持しながら、内部ポリシーやベストプラクティスに従って機密データやアプリケーションを保護することです。クラウドの監査可能性、管理のモニタリング、継続的なクラウドのリスク評価は、中核となるビジネスプロセスやアプリを支えるクラウドサービスに対する、信頼の構築と規制機関からの信頼の獲得のためには必要不可欠です。その結果、組織は関連するクラウドポリシー、プロセス、技術実装の包括的な評価の実施に、ますますリソースを割くようになっています。また、そうしたリソースに関して、組織での費用を最適化しながら、プロバイダのリスク評価をさらに広く深く実施していくための方法が常に求められています。

Google Cloud は業界最高水準の信頼できるクラウドになるために取り組んでおり、Google サイバーセキュリティ対応チームではお客様と緊密に連携し、お客様のデューデリジェンス、リスク管理、規制遵守のニーズに対応できるようにサポートしています。Google がお客様によるクラウド評価のスケーリングと促進を支える方法の一つに、第三者リスク管理（TPRM）プロバイダとの協働があります。こうした組織は独立したデューデリジェンスサービスやプラットフォームを提供しており、データを収集および提供することでベンダーによるリスク管理の自動化をサポートしています。Google はこうした TPRM 評価者が、Google のインフラストラクチャやオペレーションに内在する管理の評価を実施できるようにします。TPRM プロバイダは、モニタリングや評価に基づいて独自かつ偏りのない監査レポートを作成し、場合によってはそれをお客様に直接共有します。

Google Cloud のお客様にとっての TPRM ソリューションのメリットには、以下のようなものがあります。

包括的かつ定期的な評価: TPRM プロバイダは、Google Cloud のプラットフォームおよびサービスに対して、定期的で、複数階層かつ多次元な評価を決まったスケジュールで実施します。こうした評価の中で、TPRM プロバイダは、NIST SP 800-53、NIST CSF、ISO 27001、PCI-DSS、HIPAA、CMMC、SOC2、CSA STAR などの業界の基準や規制に沿った数百ものセキュリティ、プライバシー、ビジネスの継続性、業務の復元力の管理を検査します。こういった徹底した評価によってもたらされる情報は、クラウド内のデータおよびアプリケーションの管理に関連する複雑な規制遵守の要件を満たすための取り組みの基盤となる、Google Cloud のお客様ご自身の評価プロセスに役立ちます。
監査リソースの効率的な利用: TPRM プロバイダは、Google Cloud とお客様の間のリスク評価のやり取りを円滑に進め、レポートをお客様のコンプライアンスの状況に応じてカスタマイズします。これにより、ベンダーのリスク評価プロセスを合理化し、お客様と Google の両方に求められる通常の労力を低減します。こうした TPRM 評価の対象範囲の広さと大規模なフィールドワークによって、Google Cloud のお客様はベンダーのデューデリジェンスと全体的なリスク管理プロセスを高速化することが可能です。
独立したクラウド監査の専門知識へのアクセス: TPRM のソリューションでは、Google Cloud とは完全に独立した監査評価とレポートをお客様に提供します。加えて、お客様はクラウド管理、リスク体制、監査の慣習について、パブリッククラウドプロバイダの監査の経験が豊富な第三者と話し合う機会が持てます。

多くの Google Cloud のお客様は、Google が構築してきた TPRM との関係性をすでに活用しています。現在、Google は CyberGRX、TruSight、KY3P といった業界をリードする TPRM プロバイダと連携し、世界規模でお客様に高品質なリスク評価をお届けしています。Google は、お客様がリスク管理要件や規制遵守要件を満たすためのサポートとして、これからも効果的で効率的なソリューションを探し続けることを約束します。Google Cloud の信頼とコンプライアンスについて詳しくは、コンプライアンスリソースセンターをご覧ください。

- Google Cloud エンタープライズトラスト責任者 Rani Urbass

Google Cloud、EU 向け Assured Workloads で欧州のデータ主権機能を強化

コンプライアンスエンジニアリング - GCP における継続的コンプライアンスに関するケーススタディ

Fri, 07 Jan 2022 02:00:00 +0000

※この投稿は米国時間 2021 年 12 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

前回の記事では、本番環境への導入プロセスを一変させ、Google Cloud のワークロードに対応させるためのツールや手法を紹介しました。この記事では、GCP に用意されている技術的な統制手段の例と、お客様の組織が GCP におけるセキュリティ態勢とコンプライアンス態勢を維持するのにこれらの統制手段がどのように役立つかを説明します。

オンプレミスインフラストラクチャと比較して、GCP は高度に統合された環境であり、多種多様な統制が実施されていることを証明するための機能があらかじめ用意されています。以下の基本要素を使用することで、統制が実施されていることを効果的に証明できます。

インベントリ管理 - 多くの場合、オンプレミスワークロードには、企業の IT 環境にどのようなインフラストラクチャコンポーネントが実際にデプロイされているかを把握するための検出ツールが実装されています。GCP では、明示的に宣言されていないコンポーネントが環境内に存在することはあり得ません。このリアルタイムで正確に管理されるインベントリが、以下のケーススタディにおいて継続的コンプライアンスを実現するための基礎となります。
Infrastructure as Code - GCP におけるすべてのデプロイメントと構成は、（Terraform のように）機械で読み取り可能な指示として実装され、上位環境へと順次ステージングされる CI / CD パイプラインに組み込まれている必要があります。インフラストラクチャのリソースをプログラムで定義することで、デプロイが行われる前にセキュリティ態勢（誤って構成された Google Cloud Storage バケットが公共インターネットに公開されてしまわないか、など）を効率的に確認できます。
Compliance as Code - ポリシーの実装についても同じことが言えます。ワークロードの全期間を通じて証拠収集とコンプライアンス確認を自動化するには、プログラムによる定義である「Compliance as Code」を使用する必要があります。Google Cloud のリスク・コンプライアンス管理のコード化ソリューションは、ベストプラクティスに基づくこのようなプロセスの実装を支援します。

それでは、クラウドセキュリティアライアンスの Cloud Controls Matrix（CSA CCM）からいくつかの統制手段を取り上げ、GCP がどのように統制を支援するのかを見ていきましょう。

ケーススタディ - 鍵のライフサイクル管理イベントを記録する

鍵のライフサイクル管理の記録に関する CSA CCM の具体的な統制手段を見てみましょう。

LOG-11 - トランザクションの記録とモニタリングまたは活動の記録 - 暗号鍵の使用に関する監査と報告を行えるよう、鍵のライフサイクル管理イベントを記録、モニタリングします。

Cloud Key Management Service（KMS）と Cloud Audit Logs を併用することで、鍵の作成や破棄など、Key オブジェクトに対するお客様の活動が記録されます。お客様は、ログの保持期間のほか、アクセス許可を定義できます。ログメッセージは以下のようになります。

code_block: <ListValue: [StructValue([('code', 'gcloud logging read "logName : projects/my-project/logs/cloudaudit.googleapis.com" --project=my-project\r\n\r\n[...]\r\n permission: cloudkms.cryptoKeys.create\r\n resource: projects/my-project/locations/us-central1/keyRings/sample-keyring\r\n resourceAttributes:\r\n name: projects/my-project/locations/us-central1/keyRings/sample-keyring/cryptoKeys/key-us\r\n service: google.cloud.kms\r\n type: google.cloud.kms.CryptoKey\r\n methodName: CreateCryptoKey\r\n[...]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a3c8c50>)])]>

図 1 - 鍵作成のロギング

これらの活動を積極的にモニタリングするには、オペレーションスイートで protoPayload.methodName="CreateCryptoKey" について、ログベースのカウンタ指標を作成する必要があります。このログベースの指標を使用すると、イベントごとにアラームを作成したり、特定のしきい値に達したときに通知をトリガーしたりできます。Cloud Monitoring は、インシデント通知のほか、検査用のグラフを表示します。

ケーススタディ - 変更前の状態の復元

従来の IT 環境では、多くの場合、本番環境への展開は、厳格なチェンジマネジメントプロセスによって守られた環境で段階的に行われ、変更承認委員会の審査を受けます。クラウド環境でも、同様の確認を行う必要がありますが、エンドツーエンドではるかに迅速に確認できます。前述のとおり、本番環境では、人の介入を制限する必要があります。すべてのアプリケーションとインフラストラクチャのデプロイは、Infrastructure as Code パターンに従い、自動化技術を活用する必要があります。繰り返し可能な自動化パターンにより、運用が簡素化され、大規模なコンプライアンス検証を行えます。CSA CCM 統制セットのうち、以下の例を見てみよう。

CCC-09 変更管理および構成管理 - 変更前の状態の復元 - エラーやセキュリティ上の懸念が生じた場合に、変更前の既知の良好な状態にロールバックするプロセスを定義し、実装します。

インフラ構成の状態を Terraform で記述することで、各変更を簡単に展開およびロールバックでき、抜けが生じたり、不可逆的な変更が行われたりすることはありません。統制責任者としては、変更が自動化されており、既知の作業状態に完全に戻すことができるという安心感を持てます。

ベストプラクティスとして、Infrastructure as Code パターンをアプリケーションプロジェクトのソースコードと一緒にバージョン管理システムに格納し、CI / CD パイプラインを活用して、環境を介してステージングすることをおすすめします。

ケーススタディ - ログの完全性を守る

Cloud Audit Logs やアクセスの透明性などの GCP の広範なロギング機能は、環境内で発生した活動を記録します。特に、規制対象の業界では、これらのログは、不変性と完全性を確保しながら長期間保管する必要があります。この要件は、以下の CSA CCM に反映されています。

IAM-12 Identity & Access Management - ログの完全性を守る - ロギングインフラストラクチャが特権的アクセスロールなどの書き込みアクセス権を持つすべてのユーザーに対して読み取り専用となること、ならびに書き込みアクセス権を無効化する機能が、義務の分離を保証する手順およびブレークグラス手順を介して制御されることを保証するためのプロセス、手順、技術的対策を定義、実装、評価します。

GCP のログシンクを利用して、ログエントリを Google Cloud Storage など、サポートされているさまざまな宛先にエクスポートできます。ログエントリは、JSON ファイルとして GCS バケットに保存されます。GCS バケットは、バケット内のオブジェクトをどのくらいの期間保持すべきかを規定するデータ保持ポリシーをサポートしています。「バケットロック」機能により、構成を永久的かつ不可逆的なものにするデータ保持ポリシーを該当の GCS バケットで設定できます。

バケットをロックし、ファイルを 2 日間保存する Terraform の例:

code_block: <ListValue: [StructValue([('code', 'resource "google_storage_bucket" "my-log-bucket" {\r\n name = "my-log-bucket-8225"\r\n location = "EU"\r\n force_destroy = false\r\n retention_policy {\r\n retention_period = 172800\r\n is_locked = true\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a3c9b90>)])]>

図 2 - バケットロックの仕組み

バケットロックは不可逆的な活動です。上記の例で説明したとおり、該当の GCS バケット内に保存されたファイルは、特権的アクセス権を持つロールを含めて、定義された期間保持されます。

code_block: <ListValue: [StructValue([('code', "$ gsutil retention get gs://my-log-bucket-8225\r\n Retention Policy (LOCKED):\r\n Duration: 2 Day(s)\r\n Effective Time: Tue, 30 Nov 2021 13:17:14 GMT\r\n$ gsutil retention set 1d gs://my-log-bucket-8225\r\nSetting Retention Policy on gs://my-log-bucket-8225/...\r\nAccessDeniedException: 403 Cannot reduce retention duration of a locked Retention Policy for bucket 'my-log-bucket-8225'.\r\ngsutil rm gs://my-log-bucket-8225/README.txt\r\nRemoving gs://my-log-bucket-8225/README.txt...\r\nAccessDeniedException: 403 Object 'my-log-bucket-8225/README.txt' is subject to bucket's retention policy and cannot be deleted, overwritten or archived until 2021-12-02T05:24:02.18624-08:00"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f064a3c85d0>)])]>

図 3 - バケットロックの効果

FSI における変革

ドイツ銀行では、自動化が変革を加速させる重要な原動力となっています。

最後の数個の統制機能が「クラウド対応」に変換され、一部のアプリケーションが統制機能を通過するようになったことで、統制の自動化が現在、私たちの取り組みの中心となっています。Google Cloud に組み込まれた統制フレームワークの真の力を徐々に学び、活用し、これに対する確信を深めながら、統制責任者と緊密に協力して、Google Cloud のネイティブ機能を活用しています。自動化に成功したことで、オンプレミス環境の価値も高まりました。そのため、統制を自動化するためのハイブリッドモデルは、私たちにとって今後数か月における次の課題となります。 ドイツ銀行バイスプレジデント、運用準備プロダクトオーナー Great Binder 氏

GCP の統合環境は、セキュリティ態勢とコンプライアンス態勢を確立し維持する際に統制責任者にかかる負担を大幅に軽減する基本機能（リアルタイムインベントリなど）を備えています。このケーススタディは、GCP のお客様が、リアルタイムの証明書と（構成に誤りがある場合に発生し得る事態などについての）通知を含む、継続的なコンプライアンスに移行する方法の例を示しています。統制責任者が GCP の機能に慣れれば慣れるほど、統制の自動化に信頼が持てるようになります。

今回紹介した統制の自動化の例を基に、次のステップとして、GKE Policy Controller 内のポリシーに統制機能を組み込み、GKE Config Connector で Cloud Operations Suite や Security Command Center にシームレスにログインすることが考えられます。このトピックの詳細については、最近リリースしたソリューション「コンプライアンスのモダナイズ: リスクとコンプライアンスの管理のコード化」の一部でご確認いただけます。

- テクニカルアカウントマネージャー Florian Graf

- テクニカルアカウントマネージャー Jo Hellwig

ソフトウェア定義コミュニティクラウド - 「行政機関向けクラウド」への新しいアプローチ

ドイツのデジタルトランスフォーメーションを加速する共同イノベーション

Tue, 07 Dec 2021 07:00:00 +0000

※この投稿は米国時間 2021 年 11 月 30 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud では、ヨーロッパの企業や組織に成長の新たな波を起こすべく取り組んでいます。ドイツはインターネットが最も発展している最大規模のグローバル市場の一つで、現在はクラウドサービスによるデジタルトランスフォーメーションを推し進めています。このたび Google は、この変革をさらに推し進めるべく、2030 年までにドイツのクラウドインフラストラクチャとグリーンエネルギーに約 10 億ユーロの投資を行う計画を発表しました。

機能性やイノベーションにネガティブな影響を与えることなく、セキュリティ、プライバシー、デジタル主権の要件を満たすクラウドソリューションがドイツとヨーロッパ全域の組織から求められています。こうした要件を満たすのを支援するべく、9 月に「Cloud. On Europe’s Terms」を立ち上げました。また、このイニシアティブの一環として、ドイツの民間および公共部門の組織向けにソブリンクラウドサービスを構築することを目的とした、T-Systems との長期にわたる戦略的パートナーシップを結びました。

今回の投資とパートナーシップに関連して、ここからはドイツにおける持続可能なデジタルトランスフォーメーションを支援する計画の今後の予定について紹介していきます。T-Systems とのパートナーシップのもと、ドイツ国内でクラウドを利用しているお客様のイノベーションの推進と競争力強化を支援する新たなソブリンクラウドソリューションとデジタルトランスフォーメーションソリューションの開発を目的とした、野心的な共同イノベーションプログラムに乗り出していきます。

ミュンヘン – 世界中のユーザーとお客様にデジタルイノベーションを届けるための本拠地

今回の計画はミュンヘンを中心に進めていくことになります。Google と Google Cloud は長年にわたってミュンヘンでビジネスを展開してきました。2006 年に開設された Google ミュンヘンオフィスはその後、ヨーロッパにおける Google の主なエンジニアリング拠点へと変貌していきました。ドイツ最大の Google オフィスがあるミュンヘンのアルヌルフパークには 1,500 人以上の Google 社員が在籍しています。数十億人にのぼる Google ユーザーが利用する堅牢なプライバシーソリューションとセキュリティソリューションを開発するグローバル Google セーフティエンジニアリングセンター（GSEC）もここにあります。クラウドに関する共同イノベーションの取り組みを進める場所として、セキュリティとプライバシーに関する専門知識を持つ人材が豊富なミュンヘンを選択したのは自然な流れでした。

バイエルン州とその州都は、デジタル化の次の 10 年をリードする場所として、世界的に見ても非常に魅力的な土地です。定評のある業界のリーダーや新たな業界のリーダー、活気あるテクノロジーセクター、学術機関と研究機関から成る充実したエコシステムがここにはあります。

開発が進められている Arnulfpost 地区の Westhof 側にある Google オフィス内に開設される、ヨーロッパで最初の Google Cloud 共同イノベーションセンターにとってこの環境はうってつけです。共同イノベーションセンターは今後数か月以内に開設され、バイエルン州の州都でデジタルイノベーションの拠点として機能することになります。

バイエルンの大臣主席である Markus Söder 博士は次のように述べています。「ドイツとアメリカの企業が手を結びました。未来はデジタル化にかかっています。Google Cloud と T-Systems はクラウドコンピューティングのためのグローバルパートナーシップをバイエルンで立ち上げます。一方、ミュンヘンは世界の IT をリードする都市として発展を続けていきます。ハイテク分野においては、バイエルンが合計 35 億ユーロの投資をもとにテクノロジー、デジタル化、スーパーテックを推進していきます。13,000 にのぼる大学でのポジションを創出する予定です。教授も 1,000 人募集し、そのうち 100 人が AI の専門家です。」

Google Cloud の CEO である Thomas Kurian（画面右下）、T-Systems の CEO である Adel Al-Saleh 氏と CTO の Maximilian Ahrens 博士（画面左下）、Google Cloud のエンジニアリング担当バイスプレジデントである Wieland Holfelder 博士（画面右上）と会話する、バイエルンの大臣主席である Markus Söder 氏、およびバイエルン州デジタル担当大臣の Judith Gerlach 氏。写真のクレジット: © Bavarian State Chancellery

主権の基盤構築に向けた共同イノベーション

長年にわたりミュンヘンでイノベーションの先頭に立ってきた T-Systems とともに、新たな共同イノベーションセンターで次のような取り組みを進めていきます。

サステナビリティと変革の目標達成に役立つ新たなソリューションの開発に向けて協力することで、共通のお客様のニーズに対処
ドイツ国内で活躍する、優秀なクラウドエンジニアリング人材を惹きつけ、育成する機会を創出
ドイツにおける競争力とデジタルトランスフォーメーションの取り組み全体を強化する、新たなソブリンソリューションに向けた大規模な基盤を構築

共同イノベーションセンターでは、クラウドを利用しているお客様とパートナーがエコシステム全体でデジタルトランスフォーメーションを加速させるのに必要な専門知識を身に付けられるプログラムも提供する予定です。

T-Systems の最高技術責任者である Maximilian Ahrens 博士は次のように述べています。「Google Cloud とのパートナーシップの柱である共同イノベーションがミュンヘンで実現することを大変うれしく思います。T-Systems では信頼が、Google Cloud ではイノベーションが最大の強みとなっています。こうした強みを活かした共同イノベーションによって、両社のドイツのお客様が抱える最も重要な主権のニーズに応えられるのは私たち以外にはありません。」

この取り組みの一環として、T-Systems と Google Cloud は高度な資格が求められるソフトウェアエンジニアリングのポジションをミュンヘンで複数創出していきます。

今後の展望

共同イノベーションセンターの正式な開設は 2022 年中頃を予定しています。Google Cloud で長年にわたってエンジニアリング担当バイスプレジデントを務め、Google ミュンヘンオフィスを統括してきた Wieland Holfelder 博士が、次世代のソブリンクラウドソリューションに向けた取り組みを率いていくことになります。

さまざまな課題やチャンスが存在するなか、関係を構築して障壁を減らし、手を取り合って優れたテクノロジーを創出および開発し、ドイツとヨーロッパにとどまらず、世界中に届けることに意義があると Google では考えています。持続可能なデジタルトランスフォーメーションにとって Google Cloud が最適な場所となるよう、Google では日々取り組んでいます。新たな共同イノベーションセンターでお客様、そしてパートナーの皆様とお会いできることを楽しみにしております。

-Google Cloud EMEA（欧州、中東、アフリカ）北部地域担当バイスプレジデント Daniel Holz

- Google Cloud エンジニアリング担当バイスプレジデント Wieland Holfelder

空軍研究所が Google Workspace でコラボレーション、セキュリティ、生産性を促進

Tue, 16 Nov 2021 04:00:00 +0000

※この投稿は米国時間 2021 年 11 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

空軍研究所（AFRL）は、アメリカ合衆国空軍とアメリカ合衆国宇宙軍の 2 つの軍をサポートするグローバルな研究組織です。望遠鏡で宇宙をより遠くまで見ることを可能にするレーザーガイド補償光学から、量子計算と人工知能のイノベーションを生み出した基礎科学まで、AFRL は急速に発見の規模を拡大し、軍事に最先端の技術を提供しています。

国防に不可欠なものとして、AFRL は世界をリードする科学者、中小企業、巨大産業、他の政府機関と協力して、イノベーションを推進するコミュニティを構築しています。また、その業務の機密性を考えると、AFRL には、リモートでの働き手とでも、ハイレベルなセキュリティを維持する必要があります。AFRL はこのような課題に取り組むために、AFRL で働く全科学者とエンジニアのセグメントを対象に Google Workspace を導入しています。

コラボレーションとイノベーションのための一元的で安全なプラットフォーム

最先端技術の開発の先駆者として、AFRL には柔軟性が必要ですが、新しい研究者を迅速にオンボーディングするアジリティを維持しながら、厳しいセキュリティの基準を満たすことも必要です。

AFRL チームは、Google スマートキャンバスなどの Google Workspace ソリューションを使用することで、メールでの度重なるやり取りや数時間にわたるデータのファイル交換のような労苦を解消して、研究の共有、コラボレーション、協議を同時に行えるようになります。複数の AFRL 研究チームが、ビデオ会議サービスである Google Meet でバーチャル会議を主催し、いつでもどこでもアイデアを交換しています。最近発表した、Workspace クライアントサイド暗号化は、Google のゼロトラストセキュリティ手法と融合されています。この機能により、セキュリティ対策をエンドユーザーに見えないようにしながら、さらなる安全保護対策が AFRL に提供されます。最終的には、アメリカ国防情報システム局（DISA）によって定義された基準を満たしながら、AFRL の科学者間でのコラボレーションとイノベーションを加速することが目標です。

「COVID-19（新型コロナウイルス感染症）により、研究室での業務をが大幅に制限されました」と、Joshua Kennedy 博士（AFRL の Materials and Manufacturing Directorate を務める物理学研究員）は述べています。「Google Workspace がなければ業務が中断する可能性もありましたが、無事回避できました。実際、空軍省が将来もつべき能力にとって重要な 2D ナノマテリアルについての新たな知見が、Workspace を使用して見つかりました。他の方法では不可能だったでしょう。」

Google Workspace を使用した結果、業務に対して目に見える確かな効果があったと報告した AFRL の研究者は Kennedy 博士のみにとどまりません。たとえば、Google Workspace の予備導入に関係した数百人の研究者を対象とした最近の調査では、平均で週 3 時間の時間が節減されたことが明らかになりました。高度なトレーニングを受け、それぞれが博士号を持つ AFRL の研究者にとっては、任務に専念する時間が増えたと言えます。

グローバルな任務のための安全なコラボレーション

AFRL で働くスタッフは全世界に広がっています。これによって組織のイノベーションは促進される一方、最大の課題の発生源ともなります。高度な研究を行う組織のために、イノベーション力を妨げることなく、協調性、安全性、適応性の揃った環境をどう作ればよいでしょうか。

2021 年度の初頭、空軍研究所の司令官である Heather Pringle 少将は AFRL に、デジタルトランスフォーメーションの継続的な取り組みを優先するよう指示し、AFRL デジタルトランスフォーメーションチーム設立の憲章を公表しました。チームの憲章では、「先進的な手段、デジタル処理、デジタルツール、IT インフラストラクチャを使用した、データと情報のシームレスな統合をフル活用する」柔軟で相乗的な取り組みである「One AFRL」のビジョンが概説されています。

「私たちのモットーは、『コラボレーションしてイノベーションを起こす』ことです」と、Pringle 少将は述べています。「私たちは、当研究所のエキスパート達が密接につながることを望んでいます。そして、データが第 3 言語となるデジタルワークフォースとして、技能を真に高めたいと考えています。デジタルエンジニアリングを科学技術についての取り組みすべてに取り入れ、データに基づく人的資本戦略を立てています。Google Workspace で既存の機能を補完する試みを開始し、外部のパートナーとコラボレーションして最良なチームを構築する能力において改革をもたらしました。」

Google Cloud がアメリカ合衆国空軍と協力して極めて困難な課題を解決した方法や Google Cloud が空軍のパイロットを育成する訓練の変革にいかに役立っているかについての詳細をご覧ください。

- Google Cloud グローバル公共部門担当バイスプレジデント Mike Daniels

クラウドプロジェクトの迅速かつ適切な立ち上げを支援する Google の新しい RAD Lab ソリューション

Tue, 16 Nov 2021 02:00:00 +0000

※この投稿は米国時間 2021 年 11 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

公共部門では、新しいテクノロジーの開発には、予算、調達、将来のソフトウェアやハードウェアのリソースの予測など、慎重な計画が必要です。しかし、どんなに先見の明があったとしても、クラウド環境での作業経験がないと、移行を管理するのは難しいものです。お客様のニーズに応えるために、チームでどのようなツールが必要になるのかを 1 年前に知ることはできません。クラウドシステムの専門家でない場合はどうすればいいのでしょうか？

アカデミックな研究所では、科学者がプロジェクトの柔軟性とコラボレーションの機会を増やすために、研究モジュールをクラウドで立ち上げることがよく求められます。しかし、必要なクラウドスキルがないと、多くのプロジェクトを着実に開始させることができません。

イノベーションのための安全なサンドボックスである RAD Lab のご紹介

そこで本日は、テクノロジーチームや研究チームが研究開発から本番環境までを迅速に進めるための、Google Cloud ベースのサンドボックス環境である RAD Lab をご紹介します。RAD Lab は、クラウドネイティブな研究、開発、プロトタイピングのためのソリューションで、既存のインフラストラクチャにリスクを与えることなく実験を行うことで、クラウド環境の立ち上げを加速させるよう設計されています。また、公共機関や学術機関の特定のテクノロジーやスケーラビリティの要件を満たすように設計されており、予測可能なサブスクリプションモデルにより予算や調達を簡素化します。

RAD Lab を利用することで、政府機関、研究所、大学の IT 部門は、経験のあるなしに関係なく、あらゆるユーザー向けに迅速にクラウド環境を構築できます。最新のパワフルなテクノロジーを利用するために、シンプルさや使いやすさを犠牲にする必要はもうありません。簡素化されたプロセスとわかりやすいツールにより、RAD Lab ユーザーはわずか数時間で簡単にプロジェクトを立ち上げることができます。また、Google Cloud では、将来的に役立つ可能性のあるテクノロジーソリューションについて従業員を教育するためのワークショップをオプションで提供しています。

RAD Lab は、分析のためのデータを収集するためのフレキシブル環境を提供し、コスト超過のリスクなしに、チームが自由に自分のペースで実験や革新を行うことを可能にします。主な内容は以下のとおりです。

クラウド上で動作するオープンソースの環境で、ハードウェアへの投資やベンダーロックインなしに、迅速なデプロイが可能。
FedRAMP、HIPAA、GDPR セキュリティポリシーなどの規制要件を遵守した Google Cloud ツール上に構築。
すべてのプロジェクトで共通の IT ガバナンス、ロギング、およびアクセス制御。
BigQuery、Vertex AI などの分析ツールや、あらかじめ用意されたノートブックのテンプレートとのインテグレーション。
クラウドベースの環境のトレーニング、テスト、構築を促進するドキュメントやコード例を含むベストプラクティスの運用ガイダンス。
Google Cloud のスペシャリストが行う、任意のユーザー向けのオンボーディングワークショップ。

RAD Lab はお客様とパートナーのためにクラウド開発を加速

米国特許商標庁（USPTO）は、「アメリカのイノベーション機関」として、人工知能／機械学習、データサイエンス、エンタープライズアーキテクチャなどの新たな社内研究開発を可能にするために RAD Lab を活用しています。RAD Lab のサンドボックス環境を活用して、アイデアを吟味し、スケーリング可能なプロトタイプを開発しています。

CIO の Jamie Holcombe 氏は次のように述べています。「USPTO では、アメリカの発明家や起業家に対し、彼らが自宅のガレージで仕事をしていても、シリコンバレーのスタートアップ企業で仕事をしていても、多国籍企業や研究開発機関で仕事をしていても、サービスを提供できる特権を持っています。クラウドコンピューティングは、このミッションを遂行するために機関のテクノロジーをモダナイズし、変革するための活動の一環です。RAD Lab では、技術専門家から経済学者、ビジネス専門家までのスタッフが、主要機関のニーズを満たす新しいクラウドソリューションを構築、テスト、検証できます。」

また、RAD Lab は、Google Cloud パートナーが、イテレーション、実験、プロトタイピングのために設計されたクラウドベースの環境を顧客に提供する際に、ツールをより簡単かつ迅速に導入するための基盤を提供します。Onix のヘルスサイエンスおよびライフサイエンス部門のクラウドスペシャリストである Jim Coyne 氏は次のように述べています。「当社のお客様は、さまざまなソリューションやアプリケーションを試し、何が最適かを見極めるために、柔軟でスケーラブルなサンドボックス環境を求めています。RAD Lab は、お客様と協力して、Google Cloud を使ってまったく新しい方法でイノベーションを起こすための柔軟性を提供してくれます。」

また、SpringML の CTO である Girish Reddy 氏は次のように述べています。「RAD Lab を利用して、Google Cloud のツールをアクセス性の高いオープンソースの環境でお客様に提供できることを嬉しく思います。お客様が AI/ML ソリューションを導入する際に、自社のデータの力を示すことができる貴重なツールです。」

今すぐ試験運用を開始し、短期間で成果を得る

RAD Lab の迅速なデプロイにより、お客様のチームは、数週間、数か月ではなく、数時間でクラウドのデプロイを開始し、プロトタイピングを行うことができます。公共部門やその他の規制された業界では、RAD Lab の展開に含めるべき最適なクラウド機能を決定し、お客様のチームが必要なときに必要なテクノロジーにアクセスできるよう Google がサポートします。Google Cloud チームに RAD Lab のプロジェクトについてお問い合わせください。また、一部の国では無料の研究クレジットを今すぐ申請できます。

- Google Cloud グローバル公共部門戦略ビジネスエグゼクティブ、Alexander Titus 博士

コンプライアンス

GKE 対策の拡張: Policy Controller 違反が Security Command Center で確認可能に

Policy Controller と SCC のインテグレーション

Policy Controller と SCC のインテグレーションを使ってみる

Policy Controller ダッシュボード: Anthos と GKE のすべての環境で利用可能に

Policy Controller ダッシュボード

今すぐ使用を開始する

新しい PCI DSS ポリシー バンドルで Kubernetes クラスタを強化し、ワークロードのコンプライアンスを大規模にモニタリングする

PCI DSS v3.2.1 ポリシー バンドル

PCI DSS v3.2.1 ポリシー バンドルを使用する

Policy ダッシュボードで PCI DSS ポリシー バンドルの違反を確認する

クラスタで PCI DSS ポリシー バンドル違反をモニタリングする

まとめ

使ってみる

Kubernetes クラスタにポリシー バンドルを適用してポリシー準拠の状況を大規模にモニタリング

ポリシー バンドルの概要

使ってみる

CISO サバイバル ガイド: 変革を成功に導くための重要な質問

会話の導入時に問うべき質問:

CISO がビジネス リーダーに対して問うべき質問:

ビジネス リーダーが CISO とセキュリティ チームに対して問うべき質問:

CISO とビジネス リーダーが問うべき質問:

CISO とリスクチームが問うべき質問:

ビジネスチームと技術チームが問うべき質問:

実践的なアドバイスと運用変革の現実

CISO サバイバル ガイド: 金融サービス組織がより安全にクラウドに移行するには

CISO サバイバル ガイド: 金融サービス組織がより安全にクラウドに移行するには

移行を開始する前に解消しておくべき多くの懸案事項

組織におけるクラウド思考の推進

適切な質問がセキュリティの変革を促進

クラウド セキュリティに向けた CISO のメンタルモデル刷新の必要性

Spanner でデータを保護する新しい方法として Cloud Spanner にきめ細かなアクセス制御を導入

Cloud Spanner の誤解を打ち破る

DLP を使用した BigQuery の自動データリスク管理

データ分類でデータリスクを抑制

ご利用方法

Cloud Data Loss Prevention の自動化

Google Cloud での品質管理システムのモニタリング

大規模なハードウェアのオフロードを実現する PSP の暗号化がオープンソースで登場

Google Cloud CLI の Terraform 用ポリシー ガードレール プレビュー版に関するお知らせ

課題

ソリューション

新機能

ポリシー検証の主なユースケース

使ってみる

フィードバック

Cloud Build で Terraform デプロイのスケーリングとコンプライアンスを実現

テクノロジーによってどのように効率的で透明性の高い安全な金融市場の基盤が築かれているのか

クラウド テクノロジーの現状

複数のフェーズで考えるテクノロジーの軌跡

規制当局と市場参加者双方にとっての機会

金融市場における機械学習の役割

将来に向けた市場基盤の構築

米国と EU 間でのデータ移転の新たな枠組みに関する発表を踏まえた EU 域内のビジネスに対する Google Cloud の取り組みの最新情報

お客様がコントロールするクラウド

Google Cloud Platform

Google Workspace

国際的なデータ移転の法的根拠

支援および追加の役立つリソース

Google Cloud の Professional Service Organization と連携して政府機関のコンプライアンスを加速

Authority to Operate（ATO）を加速

ゼロトラスト戦略の開発

PSO と連携して安全なクラウド導入を拡大

第三者のリスク管理プロバイダを活用して Google Cloud のベンダー デュー デリジェンスを促進

Google Cloud、EU 向け Assured Workloads で欧州のデータ主権機能を強化

コンプライアンス エンジニアリング - GCP における継続的コンプライアンスに関するケーススタディ

ケーススタディ - 鍵のライフサイクル管理イベントを記録する

ケーススタディ - 変更前の状態の復元

ケーススタディ - ログの完全性を守る

FSI における変革

コンプライアンスのモダナイズ: リスクとコンプライアンスの管理のコード化

ソフトウェア定義コミュニティ クラウド - 「行政機関向けクラウド」への新しいアプローチ

ドイツのデジタル トランスフォーメーションを加速する共同イノベーション

ミュンヘン – 世界中のユーザーとお客様にデジタル イノベーションを届けるための本拠地

主権の基盤構築に向けた共同イノベーション

今後の展望

EU のお客様向けの新しいデータ主権管理

空軍研究所が Google Workspace でコラボレーション、セキュリティ、生産性を促進

コラボレーションとイノベーションのための一元的で安全なプラットフォーム

グローバルな任務のための安全なコラボレーション

新しい PCI DSS ポリシーバンドルで Kubernetes クラスタを強化し、ワークロードのコンプライアンスを大規模にモニタリングする

PCI DSS v3.2.1 ポリシーバンドル

PCI DSS v3.2.1 ポリシーバンドルを使用する

Policy ダッシュボードで PCI DSS ポリシーバンドルの違反を確認する

クラスタで PCI DSS ポリシーバンドル違反をモニタリングする

Kubernetes クラスタにポリシーバンドルを適用してポリシー準拠の状況を大規模にモニタリング

ポリシーバンドルの概要

CISO サバイバルガイド: 変革を成功に導くための重要な質問

CISO がビジネスリーダーに対して問うべき質問:

ビジネスリーダーが CISO とセキュリティチームに対して問うべき質問:

CISO とビジネスリーダーが問うべき質問:

CISO サバイバルガイド: 金融サービス組織がより安全にクラウドに移行するには

CISO サバイバルガイド: 金融サービス組織がより安全にクラウドに移行するには

クラウドセキュリティに向けた CISO のメンタルモデル刷新の必要性

Google Cloud CLI の Terraform 用ポリシーガードレールプレビュー版に関するお知らせ

クラウドテクノロジーの現状

第三者のリスク管理プロバイダを活用して Google Cloud のベンダーデューデリジェンスを促進

コンプライアンスエンジニアリング - GCP における継続的コンプライアンスに関するケーススタディ

ソフトウェア定義コミュニティクラウド - 「行政機関向けクラウド」への新しいアプローチ

ドイツのデジタルトランスフォーメーションを加速する共同イノベーション

ミュンヘン – 世界中のユーザーとお客様にデジタルイノベーションを届けるための本拠地

クラウドプロジェクトの迅速かつ適切な立ち上げを支援する Google の新しい RAD Lab ソリューション