このセクションでは、ブループリントのデプロイに使用できるプロセス、その命名規則、ブループリントの推奨事項に代わる方法について説明します。
タスクのまとめ
このブループリントのベスト プラクティスと推奨事項に沿って独自のエンタープライズ基盤をデプロイするには、このセクションにまとめられた大まかなタスクを実施してください。デプロイするには、前提条件のセットアップ手順、GitHub の terraform-example-foundation による自動デプロイ、最初の基盤デプロイの完了後に手動で構成する必要がある追加の手順を組み合わせる必要があります。
プロセス | ステップ |
---|---|
基盤パイプライン リソースをデプロイする前の前提条件 |
基盤パイプラインをデプロイする前に、以下の手順を完了します。
既存のオンプレミス環境に接続するには、以下の準備を行います。
|
GitHub から terraform-example-foundation をデプロイする手順 |
各ステージの README に沿って、GitHub から terraform-example-foundation をデプロイします。
|
IaC のデプロイ後の追加手順 |
Terraform コードをデプロイしたら、次の操作を完了します。
|
機密性の高いワークロードを扱うお客様向けのその他の管理機能
Google Cloud には、セキュリティとコンプライアンスの要件に向けた便利な追加の管理機能が用意されています。ただし、一部の管理機能には追加の費用や運用上のトレードオフが伴うため、すべてのお客様にとって必ずしも適切であるとは限りません。このような管理機能には、特定の要件に合わせてカスタマイズされた入力情報も必要です。この操作は、すべてのお客様向けのデフォルト値を使用してブループリントで完全に自動化することはできません。
このセクションでは、基盤に一元的に適用できるセキュリティ管理について説明します。このセクションは、特定のワークロードに適用できるすべてのセキュリティ管理を網羅するものではありません。Google のセキュリティ プロダクトとソリューションの詳細については、Google Cloud セキュリティ ベスト プラクティス センターをご覧ください。
コンプライアンス要件、リスク許容度、データの機密性に基づいて、次の各管理機能が基盤に適しているかどうかを評価します。
管理機能 | 説明 |
---|---|
VPC Service Controls では、信頼できる境界の外部にある Google マネージド サービスへのアクセスを禁止して、信頼できない場所からのデータへのアクセスをブロックし、データ漏洩のリスクを軽減するセキュリティ ポリシーを定義できます。ただし、計画的なアクセス パターンを許可する例外を定義するまで、VPC Service Controls により既存のサービスが中断される可能性があります。 情報漏洩のリスクを軽減する価値が、VPC Service Controls の導入に伴う複雑さと運用オーバーヘッドの増加に見合うかどうかを評価します。ブループリントは、VPC Service Controls を構成する制限付きネットワークとオプションの変数を作成しますが、境界を設計して有効にする追加の手順を踏むまで、境界は有効になりません。 |
|
規制要件によっては、クラウド リソースを承認された地理的位置にのみデプロイする必要があります。この組織のポリシーの制約により、定義したロケーションのリストにのみリソースをデプロイできるようになります。 |
|
Assured Workloads は、特定の規制制度への対応に役立つ追加のコンプライアンス管理を提供します。ブループリントのデプロイ パイプラインには、これを有効にするオプションの変数が用意されています。 |
|
特定のセンシティブ データまたはリソースへのすべてのアクセスをログに記録することが要件となる場合があります。 データアクセス ログを必要とするセンシティブ データをワークロードが処理する場所を評価し、センシティブ データを扱うサービスや環境ごとにログを有効にします。 |
|
Access Approval により、Cloud カスタマーケアやエンジニアリングがお客様のデータにアクセスする必要がある場合は常に、お客様の明示的な承認が必要になります。 Access Approval のリクエストを確認するために必要な運用プロセスを評価して、サポート インシデントの解決で遅延が発生しないようにします。 |
|
Key Access Justifications を使用すると、自動化されたオペレーションまたはカスタマーケアによるお客様のコンテンツへのアクセスなどの目的で、Google がお客様の暗号鍵にアクセスできるかどうかをプログラムで制御できます。 Key Access Justifications に関連する費用と運用オーバーヘッドのほか、その Cloud External Key Manager(Cloud EKM)との依存関係を評価します。 |
|
Cloud Shell はオンライン開発環境です。お客様環境の外部にある Google が管理するサーバーでホストされているため、お客様独自のデベロッパー ワークステーションに実装された管理機能の対象にはなりません。 デベロッパーがクラウド リソースへのアクセスに使用できるワークステーションを厳密に制御する場合は、Cloud Shell を無効にします。お客様独自の環境で構成可能なワークステーションのオプションとして Cloud Workstations を評価することもできます。 |
|
Google Cloud では、グループ メンバー、信頼できる IP アドレス範囲、デバイスの確認などのアクセスレベルの属性に基づいて、Google Cloud コンソールへのアクセスを制限できます。一部の属性では、BeyondCorp Enterprise への追加サブスクリプションが必要です。 大規模なゼロトラスト デプロイの一環として、コンソールなどのウェブベースのアプリケーションへのユーザー アクセスに関して信頼できるアクセス パターンを評価します。 |
命名規則
Google Cloud リソースには、標準化された命名規則を使用することをおすすめします。次の表は、ブループリントのリソース名に推奨される規則を示しています。
リソース | 命名規則 |
---|---|
フォルダ |
例: |
プロジェクト ID |
例: |
VPC ネットワーク |
例: |
サブネット |
例: |
ファイアウォール ポリシー |
例:
|
Cloud Router |
例: |
Cloud Interconnect 接続 |
例: |
Cloud Interconnect VLAN アタッチメント |
例: |
グループ |
ここで、 例: |
カスタムロール |
ここで、 例: |
サービス アカウント |
各要素の意味は次のとおりです。
例: |
Storage バケット |
各要素の意味は次のとおりです。
例: |
デフォルトの推奨事項に代わる方法
ブループリントで推奨されているベスト プラクティスは、すべてのお客様に当てはまるとは限りません。推奨事項は、特定の要件に合わせてカスタマイズできます。次の表は、既存の技術スタックと業務の進め方に応じて必要となる可能性のある一般的なバリエーションの一部を示しています。
決定分野 | 代替策 |
---|---|
組織: このブループリントでは、すべてのリソースのルートノードとして単一の組織を使用します。 |
Google Cloud ランディング ゾーンのリソース階層を決定するでは、次のような複数の組織を選択するシナリオが紹介されています。
|
フォルダ構造: このブループリントはシンプルなフォルダ構造を持ち、ワークロードは最上位のレイヤで |
Google Cloud ランディング ゾーンのリソース階層を決定するでは、リソースの管理方法とポリシーの継承方法に基づいてフォルダを構造化する次のような別の方法が紹介されています。
|
組織のポリシー: このブループリントでは、すべての組織のポリシーの制約が組織ノードで適用されます。 |
セキュリティ ポリシーや業務の進め方は、ビジネスの部門ごとに異なる場合もあります。そのようなシナリオでは、組織のポリシーの制約をリソース階層の下位ノードで適用します。組織のポリシーの制約の一覧で、要件を満たす制約をご確認ください。 |
デプロイ パイプライン ツール: このブループリントは、Cloud Build を使用して自動化パイプラインを実行します。 |
デプロイ パイプラインには、Terraform Enterprise、GitLab Runners、GitHub Actions、Jenkins などの他のプロダクトを使用する場合もあります。ブループリントには、各プロダクトの代替案が含まれています。 |
デプロイ用のコード リポジトリ: このブループリントは、限定公開のマネージド Git リポジトリとして Cloud Source Repositories を使用します。 |
コード リポジトリの管理には、GitLab、GitHub、Bitbucket など、任意のバージョン管理システムを使用することもできます。 オンプレミス環境でホストされている限定公開リポジトリを使用する場合は、リポジトリから Google Cloud 環境へのプライベート ネットワーク パスを構成します。 |
ID プロバイダ: このブループリントは、オンプレミスの Active Directory を前提として、Google Cloud Directory Sync を使用して ID を Cloud Identity と連携させます。 |
すでに Google Workspace を使用している場合は、Google Workspace で管理されている Google ID を使用することもできます。 既存の ID プロバイダがない場合は、Cloud Identity でユーザー ID を直接作成して管理できます。 Okta、Ping、Azure Entra ID などの既存の ID プロバイダがある場合は、既存の ID プロバイダでユーザー アカウントを管理して Cloud Identity と同期できます。 データ主権またはコンプライアンスの要件により Cloud Identity を使用できない場合や、Google 広告または Google マーケティング プラットフォームなどの他の Google サービスで管理対象の Google ユーザー ID が必要ない場合は、Workforce Identity 連携の方が適している可能性があります。このシナリオでは、サポート対象のサービスの制限事項にご注意ください。 |
複数のリージョン: このブループリントは、リージョン リソースを 2 つの異なる Google Cloud リージョンにデプロイし、高可用性と障害復旧の要件を考慮したワークロード設計を可能にします。 |
エンドユーザーが複数の地域に分散している場合は、レイテンシの影響を受けにくいエンドユーザーに近いリソースを作成するために、Google Cloud リージョンを追加で構成することもできます。 データ主権の制約がある場合、または単一のリージョンで可用性のニーズを満たすことができる場合は、1 つの Google Cloud リージョンのみを構成することもできます。 |
IP アドレスの割り振り: このブループリントは、一連の IP アドレス範囲を提供します。 |
既存のハイブリッド環境で使用できる IP アドレスに基づいて、使用する特定の IP アドレス範囲の変更が必要になる場合があります。IP アドレス範囲を変更する場合は、必要となる範囲の数とサイズのガイダンスとしてブループリントを使用し、Google Cloud の有効な IP アドレス範囲をご確認ください。 |
ハイブリッド ネットワーキング: このブループリントは、帯域幅と可用性を最大化するために、複数の物理サイトと Google Cloud リージョンの間で Dedicated Interconnect を使用します。 |
費用、帯域幅、信頼性の要件によっては、Partner Interconnect または Cloud VPN を構成することもできます。 Dedicated Interconnect の完了前にプライベート接続でリソースのデプロイを開始する必要がある場合は、Cloud VPN から始めて、後から Dedicated Interconnect を使用するように変更することもできます。 既存のオンプレミス環境がない場合は、ハイブリッド ネットワーキングがまったく必要ない可能性もあります。 |
VPC Service Controls の境界: このブループリントでは、制限付き VPC ネットワークに関連付けられたすべてのサービス プロジェクトを含む単一の境界が推奨されています。ベース VPC ネットワークに関連付けられたプロジェクトは、境界内には含まれません。 |
ユースケースによっては、組織に複数の境界を必要とする場合や、VPC Service Controls をまったく使用しない場合もあります。 詳細については、Google API を使用してデータの引き出しを抑制する方法を決定するをご覧ください。 |
Secret Manager: このブループリントは、組織全体のシークレット用の |
組織全体で機密性の高いシークレットの管理と監査を担当する単一のチームがある場合は、シークレットへのアクセスの管理に単一のプロジェクトのみを使用することをおすすめします。 各ワークロード チームが独自のシークレットを管理できるようにする場合は、一元化されたプロジェクトを使用してシークレットへのアクセスを管理するのではなく、各チームがワークロード プロジェクトで独自の Secret Manager インスタンスを使用できるようにすることもできます。 |
Cloud KMS: このブループリントは、組織全体の鍵用の |
組織全体で暗号鍵の管理と監査を担当する単一のチームがある場合は、鍵へのアクセスの管理に単一のプロジェクトのみを使用することをおすすめします。一元化されたアプローチは、PCI 鍵管理者などのコンプライアンス要件を満たすのに役立ちます。 ワークロード チームが独自の鍵を管理できるようにする場合は、一元化されたプロジェクトを使用して鍵へのアクセスを管理するのではなく、各チームがワークロード プロジェクトで独自の Cloud KMS インスタンスを使用できるようにすることもできます。 |
集約されたログシンク: このブループリントは、組織ノードに一連のログシンクを構成して、中央のセキュリティ チームが組織全体の監査ログを確認できるようにします。 |
ビジネスの部門ごとに監査を担当する複数のチームがあり、各チームがそれぞれの業務で別々のログを必要とすることもあります。このような場合は、適切なフォルダとプロジェクトで複数の集約されたシンクを設計し、各チームが必要なログのみを受け取るようにフィルタを作成するか、共通のログバケットに対してきめ細かくアクセス制御できるログビューを設計します。 |
モニタリング スコープ対象プロジェクト: このブループリントは、環境ごとに単一のモニタリング スコープ対象プロジェクトを構成します。 |
各チームが管理するきめ細かいスコープ対象プロジェクトを構成し、それぞれのチームが管理するアプリケーションを含む一連のプロジェクトにスコープを設定することもできます。 |
インフラストラクチャ パイプラインの粒度: このブループリントは、各ビジネス ユニットが個別のインフラストラクチャ パイプラインを持ち、ワークロード プロジェクトを管理するモデルを使用します。 |
すべてのプロジェクトとインフラストラクチャのデプロイを担当する中央チームがある場合は、中央チームが管理する単一のインフラストラクチャ パイプラインを選択することもできます。この中央チームは、ワークロード チームからの pull リクエストを受け入れて、プロジェクトを作成する前に確認して承認することができます。また、チケット制システムに応じて、チーム自体が pull リクエストを作成することもできます。 個々のワークロード チームが独自のパイプラインをカスタマイズできる場合で、パイプラインに対する詳細な権限が付与されたサービス アカウントを設計する場合は、より粒度の細かいパイプラインを選択することもできます。 |
SIEM エクスポート: ブループリントは、すべてのセキュリティ検出結果を Security Command Center で管理します。 |
セキュリティ検出結果は、Security Command Center から Chronicle や既存の SIEM などのツールにエクスポートすることもできますが、チームがコンソールを使用してセキュリティ検出結果を表示および管理することもできます。また、スコープと責任が異なる固有のフィルタをチームごとに使用して、複数のエクスポートを構成することもできます。 |
オンプレミスからの Google Cloud サービスの DNS ルックアップ: このブループリントは、共有 VPC ごとに一意の Private Service Connect エンドポイントを構成します。これにより、複数の VPC Service Controls の境界を使用した設計が可能になります。 |
複数の VPC Service Controls の境界を必要としない場合は、オンプレミス環境から Private Service Connect エンドポイントに対して、この粒度でルーティングを行う必要がない場合もあります。 環境ごとにオンプレミス ホストを Private Service Connect エンドポイントにマッピングする代わりに、適切な API バンドルを含む単一の Private Service Connect エンドポイントを使用するか、 |
次のステップ
- GitHub の Terraform のサンプル基盤を使用してブループリントを実装する。
- Google Cloud アーキテクチャ フレームワークで、設計原則のベスト プラクティスについて詳しく学ぶ。
ブループリントのライブラリを確認して、次のような一般的なエンタープライズ ワークロードの設計と構築を迅速に進める。
基盤環境の上にデプロイする関連ソリューションを確認する。
デモンストレーション環境へのアクセスについては、security-foundations-blueprint-support@google.com までお問い合わせください。