多くの組織では、さまざまなビジネス目的でデータを分析できるように、機密情報を保存するデータ ウェアハウスをデプロイしています。このドキュメントは、BigQuery を使用してデータ ウェアハウスのデプロイと保護を行うデータ エンジニアとセキュリティ管理者を対象としています。これは、以下で構成されるセキュリティ ブループリントの一部です。
一連の Terraform の構成とスクリプトを含む GitHub リポジトリ。機密データを格納するデータ ウェアハウスをサポートする、Google Cloud の環境を設定する Terraform 構成。
このブループリントを使用して実装するアーキテクチャ、設計、セキュリティ管理のガイド(このドキュメント)。
サンプル環境をデプロイするチュートリアル。
このドキュメントでは、次のトピックについて説明します。
本番環境でデータ ウェアハウスを保護するために使用できるアーキテクチャと Google Cloud サービス。
データの匿名化、機密データの差分処理、列レベルのアクセス制御を含む、Google Cloud でデータ ウェアハウスを作成、デプロイ、運用する際のデータ ガバナンスのベスト プラクティス。
このドキュメントは、Google Cloud エンタープライズ基盤ブループリントに説明されているように、基本的なセキュリティ管理の構成が完了していることを前提としています。既存のセキュリティ管理にセキュリティ管理機能を追加して、データ ウェアハウス内の機密データを保護できます。
データ ウェアハウスのユースケース
このブループリントは、次のユースケースをサポートしています。
Google Cloud から安全な BigQuery データ ウェアハウスにデータをインポートする(このドキュメント)
概要
BigQuery などのデータ ウェアハウスでは、ビジネスデータを分析すると分析情報が得られます。アナリストは、データ ウェアハウスに保存されているビジネスデータにアクセスして分析情報を作成します。データ ウェアハウスに機密データが含まれている場合は、ビジネスデータの保存中、転送中、分析中のセキュリティ、機密性、整合性、可用性を維持するための措置を取る必要があります。このブループリントでは、以下のことを行います。
- 機密データへの安全なアクセスに役立つ管理を構成します。
- データ パイプラインの保護に役立つ管理を構成します。
- ペルソナごとに職掌分散を適切に構成します。
- 機密データを検出して匿名化するためのテンプレートを設定します。
- 適切なセキュリティ管理とロギングを設定して、機密データを保護します。
- データ分類タグとポリシータグを使用して、データ ウェアハウス内の特定の列へのアクセスを制限します。
アーキテクチャ
機密データ ウェアハウスを作成するには、データが機密か機密でないかを分類し、そのデータを別々の境界に保存する必要があります。次の図は、取り込まれたデータの分類、匿名化、保存の仕組みを示しています。また、分析のためにオンデマンドで機密データを再識別する方法も表しています。
このアーキテクチャでは、次の Google Cloud のサービスと機能を組み合わせて使用します。
Identity and Access Management(IAM)と Resource Manager で、アクセスとセグメント リソースを制限します。アクセス制御とリソース階層は、最小権限の原則に従います。
VPC Service Controls で、承認、アクセス制御、および安全なデータ交換を設定することで、サービスとリソースを分離するセキュリティ境界を作成します。境界は次のとおりです。
受信データ(バッチまたはストリーム)を受け入れて匿名化するデータ取り込み境界。ランディング ゾーンを分離すると、残りのワークロードを受信データから保護できます。
機密データを再識別して制限された場所に保存できる機密データ境界。
暗号鍵を保管し、機密データとみなされるものを定義するガバナンス境界。
これらの境界は、追加のアクセス制御とモニタリングを設定して機密データを分離し、ウェアハウス内の実際のデータとガバナンスを分離するように設計されています。ガバナンスには、鍵管理、Data Catalog 管理、ロギングが含まれます。
Cloud Storage と Pub/Sub は、次のようにデータを受け取ります。
Cloud Storage: 匿名化の前にバッチデータを受信して保存します。Cloud Storage は TLS を使用して転送中のデータを暗号化し、デフォルトでストレージ内のデータを暗号化します。暗号鍵は顧客管理の暗号鍵(CMEK)です。Identity and Access Management、アクセス制御リスト(ACL)、ポリシー ドキュメントなどのセキュリティ管理を使用して、Cloud Storage バケットへのアクセスを保護できます。サポートされているアクセス制御の詳細については、アクセス制御の概要をご覧ください。
Pub/Sub: 匿名化する前にストリーミング データを受信して保存します。Pub/Sub では、CMEK で認証、アクセス制御、メッセージ レベルの暗号化を使用し、データを保護します。
次の 2 つの Dataflow パイプラインは、機密データの匿名化と再識別を行います。
- 最初のパイプラインでは、仮名化を使用して機密データを匿名化します。
- 2 番目のパイプラインでは、承認されたユーザーがアクセス権を必要とするときに、機密データを再識別します。
Dataflow では、データを保護するため、パイプラインごとに一意のサービス アカウントと暗号鍵、アクセス制御を使用します。バックエンド サービスに移動してパイプラインの実行を保護するため、Dataflow は Streaming Engine を使用します。詳細については、Dataflow のセキュリティと権限をご覧ください。
センシティブ データの保護により、取り込み中に機密データが匿名化されます。
Sensitive Data Protection では、検出された infoType またはレコードに基づいて、構造化データと非構造化データが匿名化されます。
Cloud HSM が鍵暗号鍵(KEK)をホストします。Cloud HSM は、クラウドベースのハードウェア セキュリティ モジュール(HSM)サービスです。
Data Catalog では、取り込み時メタデータ(ポリシータグとも呼ばれます)を使用して機密データを自動的に分類します。Data Catalog は、メタデータを使用して機密データへのアクセスも管理します。詳細については、Data Catalog の概要をご覧ください。データ ウェアハウス内のデータへのアクセスを制御するには、機密データを含む列にポリシータグを適用します。
BigQuery では、機密データは機密データ境界に保存されます。
BigQuery では、コンテンツを保護するため、アクセス制御、機密データの列レベルのセキュリティ、データ暗号化を含む、さまざまなセキュリティ コントロールを使用します。
Security Command Center は、Google Cloud 環境全体でのセキュリティ検出結果を 1 か所でモニタリングして確認します。
組織構造
組織のリソースをグループ化して管理できるようにし、テスト環境を本番環境から分離します。Resource Manager を使用すると、プロジェクト、フォルダ、組織ごとに論理的にリソースをグループ化できます。
次の図に、ブートストラップ、共通、本番、非本番(ステージング)、開発などのさまざまな環境を表すフォルダを持つリソース階層を示します。ブループリント内のほとんどのプロジェクトを本番環境フォルダにデプロイし、データ ガバナンス プロジェクトをガバナンスに使用する共通フォルダにデプロイします。
フォルダ
フォルダを使用して、本番環境とガバナンス サービスを非本番環境やテスト環境から分離します。次の表に、このブループリントで使用されるエンタープライズ基盤ブループリントのフォルダを示します。
フォルダ | 説明 |
---|---|
本番 | テスト済みですぐに使用できるクラウド リソースがあるプロジェクトが含まれます。 |
一般 | ガバナンス プロジェクトなど、組織の一元化されたサービスが含まれます。 |
これらのフォルダの名前は、組織のフォルダ構造に合わせて変更できますが、同様の構造を維持することをおすすめします。詳しくは、Google Cloud エンタープライズ基盤ブループリントをご覧ください。
プロジェクト
プロジェクトを使用して環境の一部を分離します。次の表に、組織内で必要なプロジェクトを示します。Terraform コードの実行時にこれらのプロジェクトを作成します。これらのプロジェクトの名前は変更できますが、同様のプロジェクト構造を維持することをおすすめします。
プロジェクト | 説明 |
---|---|
データの取り込み | データを受信して機密データを匿名化するために必要なサービスが含まれています。 |
ガバナンス | 鍵管理、ロギング、データカタログ化の機能を提供するサービスが含まれます。 |
機密ではないデータ | 匿名化されたデータを保存するために必要なサービスが含まれます。 |
機密データ | 機密データの保存と再識別に必要なサービスが含まれています。 |
これらのプロジェクトに加えて、環境には Dataflow Flex テンプレート ジョブをホストするプロジェクトも必要です。Flex テンプレート ジョブは、ストリーミング データ パイプラインに必要です。
ロールとグループをプロジェクトにマッピング
組織内のさまざまなユーザー グループに、機密データ ウェアハウスを構成するプロジェクトへのアクセス権を付与する必要があります。以降のセクションでは、作成するプロジェクトのユーザー グループとロールの割り当てに関するブループリントの推奨事項について説明します。組織の既存の構造に合わせてグループをカスタマイズできますが、同様の職掌分散とロール割り当てを維持することをおすすめします。
データ アナリスト グループ
データ アナリストは、ウェアハウス内のデータを分析します。次の表に示すように、このグループにはさまざまなプロジェクトのロールが必要です。
プロジェクトのマッピング | ロール |
---|---|
データの取り込み |
機密データへのアクセスを必要とするデータ アナリストの追加ロール: |
機密データ |
|
機密ではないデータ |
|
データ エンジニア グループ
データ エンジニアは、データ パイプラインとデータ ウェアハウスを設定して維持します。次の表に示すように、このグループにはさまざまなプロジェクトのロールが必要です。
プロジェクトのマッピング | ロール |
---|---|
データの取り込み | |
機密データ |
|
機密ではないデータ |
|
ネットワーク管理者グループ
ネットワーク管理者はネットワークを構成します。通常は、ネットワーキング チームのメンバーです。
ネットワーク管理者には、組織レベルで次のロールが必要です。
roles/logging.viewer
セキュリティ管理者グループ
セキュリティ管理者は、アクセス、鍵、ファイアウォール ルール、VPC Service Controls、Security Command Center などのセキュリティ制御を管理します。
セキュリティ管理者には、組織レベルで次のロールが必要です。
セキュリティ アナリスト グループ
セキュリティ アナリストは、セキュリティ インシデントと Sensitive Data Protection の検出結果をモニタリングし、対処します。
セキュリティ アナリストには、組織レベルで次のロールが必要です。
roles/cloudkms.viewer
roles/logging.viewer
roles/securitycenter.findingsEditor
次のいずれかの Security Command Center のロール:
roles/securitycenter.findingsBulkMuteEditor
roles/securitycenter.findingsMuteSetter
roles/securitycenter.findingsStateSetter
必要なセキュリティ管理について
このセクションでは、データ ウェアハウスの保護に使用する Google Cloud 内のセキュリティ管理について説明します。考慮すべき主なセキュリティ原則は次のとおりです。
最小権限の原則を採用してアクセスを保護する。
セグメンテーションの設計とポリシーでネットワーク接続を保護する。
各サービスの構成を保護する。
リスクレベルに基づいてデータを分類、保護する
データ ウェアハウスをホストする環境のセキュリティ要件を把握する。
検出、調査、レスポンスに十分なモニタリングとロギングを構成する。
データの取り込みに関するセキュリティ管理
データ ウェアハウスを作成するには、別の Google Cloud ソース(データレイクなど)からデータを転送する必要があります。次のいずれかのオプションを使用して、データを BigQuery のデータ ウェアハウスに転送できます。
Cloud Storage を使用するバッチジョブ。
Pub/Sub を使用するストリーミング ジョブ。取り込み中にデータを保護するために、ファイアウォール ルール、アクセス ポリシー、暗号化を使用できます。
ネットワークとファイアウォールのルール
Virtual Private Cloud(VPC)ファイアウォール ルールによって、境界へのデータフローが制御されます。restricted.googleapis.com
の特別なドメイン名からの特定の TCP ポート 443 接続を除き、すべての下り(外向き)を拒否するファイアウォール ルールを作成します。restricted.googleapis.com
ドメインには次のようなメリットがあります。
- ワークロードが Google API およびサービスと通信する際に限定公開の Google アクセスを使用することで、ネットワーク攻撃の可能性を低減できます。
- VPC Service Controls をサポートするサービスのみを使用するようになります。
詳細については、限定公開の Google アクセスの構成をご覧ください。
Dataflow ジョブごとに個別のサブネットを構成する必要があります。個別のサブネットにすると、匿名化されたデータが、再識別されるデータと適切に分離されます。
dwh-networking
モジュール リポジトリの dataflow_firewall.tf
ファイルに示すように、データ パイプラインでは、ファイアウォール内の TCP ポートを開く必要があります。詳細については、インターネット アクセスとファイアウォール ルールの構成をご覧ください。
リソースの外部 IP アドレスを使用する機能を拒否するには、compute.vmExternalIpAccess
組織ポリシーですべてを拒否する設定にします。
境界制御
アーキテクチャ図に示すように、機密データ ウェアハウスのリソースを個別の境界に配置します。異なる境界のサービス間でデータを共有できるようにするには、境界ブリッジを作成します。境界ブリッジを使用すると、保護されたサービスが境界外のリソースをリクエストできます。これらのブリッジで行える接続は次のとおりです。
データ取り込みプロジェクトをガバナンス プロジェクトに接続して、取り込み中に非匿名化できるようにします。
機密ではないデータ プロジェクトと機密データ プロジェクトを接続し、データ アナリストからの要請に応じて機密データを再識別できるようにします。
機密プロジェクトをデータ ガバナンス プロジェクトに接続して、データ アナリストからの要請に応じて再識別できるようにします。
境界ブリッジに加えて、下り(外向き)ルールを使用して、サービス境界で保護されているリソースが境界外のリソースにアクセスできるようにします。このソリューションでは、下り(外向き)ルールを構成して、外部プロジェクトの Cloud Storage にある外部 Dataflow Flex テンプレート ジョブを取得します。詳細については、境界外の Google Cloud リソースにアクセスするをご覧ください。
アクセス ポリシー
特定の ID(ユーザーまたはサービス)のみがリソースとデータにアクセスできるようにするには、IAM のグループとロールを有効にします。
特定のソースのみがプロジェクトにアクセスできるように、Google 組織でアクセス ポリシーを有効にします。リクエストに対して許可される IP アドレス範囲を指定し、特定のユーザーまたはサービス アカウントからのリクエストのみを許可するアクセス ポリシーを作成することをおすすめします。詳しくは、アクセスレベル属性をご覧ください。
取り込みの際の鍵管理と暗号化
どちらの取り込みオプションでも、CMEK の管理には Cloud HSM が使用されます。CMEK 鍵を使用して、取り込み中にデータを保護します。Sensitive Data Protection はさらに、構成した検出機能を使用して機密データを暗号化することで、データを保護します。
データを取り込むには、次の暗号鍵を使用します。
Dataflow パイプラインと Pub/Sub サービスでも使用される取り込みプロセスの CMEK 鍵。取り込みプロセスは、抽出、変換、読み込み(ETL)プロセスとも呼ばれます。
Sensitive Data Protection を使用したデータ匿名化プロセスのために Cloud HSM によってラップされた暗号鍵。
2 つの CMEK 鍵。1 つは機密ではないデータ プロジェクトの BigQuery ウェアハウス用、もう 1 つは機密データ プロジェクトのウェアハウス用です。詳細については、鍵管理をご覧ください。
CMEK のロケーションを指定します。これにより、鍵が保存され、アクセスできるようになる地理的な場所が決まります。CMEK がリソースと同じ場所に存在するようにする必要があります。デフォルトでは、CMEK は 30 日ごとにローテーションされます。
組織のコンプライアンス義務により、独自の鍵を Google Cloud から外部で管理する必要がある場合は、Cloud External Key Manager を有効にできます。外部鍵を使用する場合、鍵のローテーションを含む鍵管理アクティビティは、ユーザーの責任で行う必要があります。
サービス アカウントとアクセス制御
サービス アカウントは、Google Cloud がユーザーに代わって API リクエストを実行するために使用できる ID です。サービス アカウントにより、ユーザー ID がサービスに直接アクセスできなくなります。職掌分散を許可するには、特定の目的のための異なるロールを持つサービス アカウントを作成します。これらのサービス アカウントは、data-ingestion
モジュールと confidential-data
モジュールで定義されています。サービス アカウントは次のとおりです。
機密データを匿名化する Dataflow パイプラインの Dataflow コントローラ サービス アカウント。
機密データを再識別する Dataflow パイプラインの Dataflow コントローラ サービス アカウント。
バッチファイルからデータを取り込むための Cloud Storage サービス アカウント。
ストリーミング サービスからデータを取り込むための Pub/Sub サービス アカウント。
Dataflow パイプラインを作成する Dataflow バッチジョブを実行するための Cloud Scheduler サービス アカウント。
次の表に、各サービス アカウントに割り当てられているロールを示します。
サービス アカウント | 名前 | プロジェクト | ロール |
---|---|---|---|
Dataflow コントローラ このアカウントは匿名化に使用されます。 |
sa-dataflow-controller |
データの取り込み | |
Dataflow コントローラ このアカウントは再識別に使用されます。 |
sa-dataflow-controller-reid |
機密データ | |
Cloud Storage | sa-storage-writer |
データの取り込み |
|
Pub/Sub | sa-pubsub-writer |
データの取り込み |
|
Cloud Scheduler | sa-scheduler-controller |
データの取り込み |
|
データの匿名化
Sensitive Data Protection を使用して、取り込みフェーズで構造化データと非構造化データを匿名化します。構造化データの場合は、フィールドに基づくレコード変換を使用してデータを匿名化します。このアプローチの例については、/examples/de_identification_template/
フォルダをご覧ください。この例では、構造化データにクレジット カード番号とカード PIN があるかどうかチェックします。非構造化データの場合は、情報タイプを使用してデータを匿名化します。
機密としてタグ付けされたデータを匿名化するには、Sensitive Data Protection と Dataflow パイプラインを使用してデータをトークン化します。このパイプラインは、Cloud Storage からデータを取得して処理し、BigQuery データ ウェアハウスに送信します。
データの匿名化プロセスの詳細については、データ ガバナンスをご覧ください。
データ ストレージのセキュリティ管理
BigQuery ウェアハウスでデータを保護するため、次のセキュリティ管理を構成します。
列レベルのアクセス制御
ロールが制限されたサービス アカウント
組織のポリシー
適切な境界ブリッジを使用して、機密プロジェクトと機密でないプロジェクトの間で VPC Service Controls 境界を設定します。
暗号化と鍵管理
列レベルのアクセス制御
機密データを保護するために、BigQuery ウェアハウスでは特定の列のアクセス制御を使用します。これらの列のデータにアクセスするには、データ アナリストにきめ細かい読み取りのロールが必要で。
BigQuery で列のアクセス権を定義するには、ポリシータグを作成します。たとえば、bigquery-confidential-data
の例のモジュールの taxonomy.tf
ファイルでは、次のタグが作成されます。
クレジット カード番号などの機密性の高い情報を含む列用の
3_Confidential
ポリシータグ。このタグにアクセスできるユーザーは、2_Private
または1_Sensitive
ポリシータグがタグ付けされた列にもアクセスできます。個人の名前など、個人を特定できる機密情報(PII)を含む列用の
2_Private
ポリシータグ。このタグにアクセスできるユーザーは、1_Sensitive
ポリシータグでタグ付けされた列にもアクセスできます。ユーザーは、3_Confidential
ポリシータグでタグ付けされた列にはアクセスできません。利用限度額など、公開できないデータを含む列用の
1_Sensitive
ポリシータグ。このタグにアクセスできるユーザーは、2_Private
または3_Confidential
ポリシータグがタグ付けされた列にはアクセスできません。
タグのないものはすべて、データ ウェアハウスにアクセスできるすべてのユーザーが利用できます。
このアクセス制御により、データが再識別された後も、ユーザーにアクセス権が明示的に付与されるまでデータを読み取ることはできません。
ロールが制限されたサービス アカウント
承認されたユーザーのみが機密データを表示できるように、機密データ プロジェクトへのアクセスを制限する必要があります。そのためには、承認されたユーザーが成り代わる必要がある roles/iam.serviceAccountUser
ロールを持つサービス アカウントを作成します。サービス アカウントの権限借用は、ユーザーがサービス アカウント キーをダウンロードせずにサービス アカウントを使用するため、プロジェクトの全体的なセキュリティが向上します。権限借用は、roles/iam.serviceAccountTokenCreator
ロールを持つ承認されたユーザーがダウンロードできる短期間のトークンを作成します。
組織のポリシー
このブループリントには、エンタープライズ基盤ブループリントで使用されている組織のポリシーの制約と、追加の制約が含まれています。エンタープライズ基盤ブループリントで使用されている制約の詳細については、組織のポリシーの制約をご覧ください。
次の表に、org_policies
モジュールで定義された追加の組織ポリシー制約を示します。
ポリシー | 制約名 | 推奨値 |
---|---|---|
特定の物理的な場所にリソースのデプロイを制限します。その他の値については、値グループをご覧ください。 |
gcp.resourceLocations
|
次のいずれかです:in:us-locations in:eu-locations in:asia-locations
|
サービス アカウント作成を無効にする |
iam.disableServiceAccountCreation
|
true
|
プロジェクトで作成した VM に対して OS Login を有効にします。詳細については、組織での OS Login の管理と OS Login をご覧ください。 |
compute.requireOsLogin
|
true
|
IP アドレスに基づいて、新しい転送ルールを内部専用に制限します。 | compute.restrictProtocolForwardingCreationForTypes
|
INTERNAL
|
Compute Engine リソースで使用できる一連の共有 VPC サブネットワークを定義します。 |
compute.restrictSharedVpcSubnetworks
|
projects/PROJECT_ID/regions/REGION/s
ubnetworks/SUBNETWORK-NAME 。SUBNETWORK-NAME をブループリントで使用するプライベート サブネットのリソース ID に置き換えます。 |
Cloud Logging へのシリアルポート出力ロギングを無効にする | compute.disableSerialPortLogging |
true |
鍵管理と暗号化によるストレージと再識別
機密データに対して個別の CMEK 鍵を管理するため、データを再識別できます。Cloud HSM を使用して鍵を保護します。データを再識別するには、次のキーを使用します。
Dataflow パイプラインが再識別プロセスに使用する CMEK 鍵。
データを匿名化するために Sensitive Data Protection によって使用される元の暗号鍵。
機密データ プロジェクト内の BigQuery ウェアハウスの CMEK 鍵。
前述の取り込みの際の鍵管理と暗号化で説明したように、CMEK の場所とローテーション期間を指定できます。組織で必要な場合は Cloud EKM を使用できます。
運用管理機能
ロギングと、Security Command Center のプレミアム ティアの機能(Security Health Analytics、脅威の検出など)を有効にできます。こうした制御により、次のことを実現できます。
データにアクセスするユーザーをモニタリングする。
適切な監査を確実に実施する。
発生する可能性のある問題への、インシデント管理チームと運用チームの対応能力をサポートする。
アクセスの透明性
アクセスの透明性により、Google サポート担当者がデータにアクセスする必要がある場合、リアルタイム通知を提供いたします。アクセスの透明性ログは、人間がコンテンツにアクセスするたびに生成され、ビジネス上の正当な理由(サポートケースなど)がある Google の担当者のみがアクセス権を取得できます。アクセスの透明性を有効にすることをおすすめします。
ロギング
監査要件を満たしてプロジェクトの分析情報を得るには、追跡するサービスのデータログを使用して、Google Cloud Observability を構成します。centralized-logging
モジュールでは、次のベスト プラクティスが構成されます。
すべてのプロジェクトにまたがる集約ログシンクの作成を行う。
適切なリージョンにログを保存する。
CMEK 鍵をログシンクに追加する。
プロジェクト内のすべてのサービスに対して、データの読み取りと書き込みに関する情報と、管理者が何を読み取ったかに関する情報がログに含まれている必要があります。その他のロギングのベスト プラクティスについては、検出制御をご覧ください。
アラートとモニタリング
ブループリントをデプロイした後、セキュリティ インシデントが発生している可能性があることをセキュリティ オペレーション センター(SOC)に通知するアラートを設定できます。たとえば、アラートを使用して、IAM 権限が変更されたことをセキュリティ アナリストに知らせることができます。Security Command Center のアラートの構成の詳細については、検出通知の設定をご覧ください。Security Command Center で公開されないその他のアラートについては、Cloud Monitoring でアラートを設定できます。
その他のセキュリティ上の考慮事項
このブループリントのセキュリティ管理は、Google サイバーセキュリティ対応チームとサードパーティのセキュリティ チームの両方によってレビューされています。NDA に基づいて STRIDE 脅威モデルとサマリー評価レポートの両方へのアクセス権をリクエストするには、secured-dw-blueprint-support@google.com にメールを送信してください。
このソリューションで説明したセキュリティ管理に加えて、このソリューションの使用と重複し相互に影響し合う主要領域でもセキュリティとリスクを確認して管理する必要があります。次に例を示します。
Dataflow ジョブの構成、デプロイ、実行に使用するコード。
このソリューションで使用するデータ分類タクソノミー。
データ ウェアハウスに保存して分析するデータセットのコンテンツ、品質、セキュリティ。
ソリューションをデプロイする全体的な環境で、以下が含まれます。
- このソリューションに接続するネットワークの設計、セグメンテーション、セキュリティ。
- 組織の IAM コントロールのセキュリティとガバナンス。
- このソリューションの一部であるインフラストラクチャへのアクセス権を持ち、そのインフラストラクチャで保存と管理がされているデータにアクセスできるアクターに対する認証と認可の設定。
まとめ
このドキュメントで説明されたアーキテクチャを実装する方法は次のとおりです。
ブループリントを単独でデプロイするか、エンタープライズ基盤ブループリントとともにデプロイするかを決定します。エンタープライズ基盤ブループリントをデプロイしない場合は、同様のセキュリティ ベースラインを環境に設定するようにしてください。
ブループリントの README を確認し、すべての前提条件を満たしていることを確認します。
テスト環境でチュートリアルをデプロイして、ソリューションの動作を確認します。テストプロセスの一環として、次のことを検討します。
Security Command Center を使用して、コンプライアンス要件を基に新しく作成したプロジェクトをスキャンします。
独自のサンプルデータを BigQuery ウェアハウスに追加します。
企業内のデータ アナリストと連携して、機密データへのアクセスと、BigQuery のデータを想定どおりに操作できるかどうかをテストします。
ブループリントを本番環境にデプロイします。
次のステップ
ベースラインの安全な環境について、Google Cloud エンタープライズ基盤ブループリントで確認する。
ブループリントの詳細について、Terraform 構成の Readme を読む。
その他のベスト プラクティスとブループリントについては、セキュリティ ベスト プラクティス センターをご確認ください。