デフォルトでは、App Engine アプリケーションは、暗号化されていない接続やセキュリティ保護されていない接続を受け入れます。このような接続では、データが不正アクセス、盗難、改ざんの危険にさらされます。

デフォルトでは、HTTP のトリガーにより、Cloud Function は HTTPS リクエストへの応答に対して実行することのみが可能になります。安全でない HTTP リクエストを許可すると、データが不正アクセス、盗難、改ざんの危険にさらされます。

例 1: 次の例は、https_trigger_security_level を SECURE_OPTIONAL に設定することで、HTTPS エンドポイントの強制に失敗する HTTP トリガーを定義する Terraform 構成を示しています。

resource "google_cloudfunctions_function" "demo_function" {
...
  trigger_http = true
  https_trigger_security_level = "SECURE_OPTIONAL"
...
}

デフォルトでは、Cloud SQL インスタンスは、暗号化されていない接続やセキュリティ保護されていない接続を受け入れます。このような接続では、データが不正アクセス、盗難、改ざんの危険にさらされます。

例 1: 次の例は、require_ssl を false に設定することで、すべての接続への SSL の強制をデータベース インスタンスに要求しない Terraform 構成を示しています。

resource "google_sql_database_instance" "database_instance_demo" {
  ...
  settings {
    ip_configuration {
      require_ssl = false
      ...
    }
    ...
  }
}

デフォルトでは、Edge Cache サービスは、暗号化されていない接続やセキュリティ保護されていない接続を受け入れます。このような接続では、データが不正アクセス、盗難、改ざんの危険にさらされます。

例 1: 次の例は、require_tls を false に設定することで、通信での TLS の使用をクライアントに要求しない Edge Cache サービスを定義する Terraform 構成を示しています。

resource "google_network_services_edge_cache_service" "srv_demo" {
...
  require_tls = false
...
}

Transport Layer Security (TLS) プロトコルおよび Secure Sockets Layer (SSL) プロトコルは、クライアントと Web サーバーの間で転送されるデータの真正性、機密性および完全性を保証するための保護メカニズムを提供します。TLS と SSL の両方とも複数回の改訂を経て定期的にバージョンが更新されています。新しい改訂では毎回、前のバージョンで見つかったセキュリティの脆弱性に対応しています。安全ではない TLS/SSL のバージョンを使用すると、データ保護が脆弱化し、攻撃者が機密情報を侵害したり、盗んだり、改変したりする可能性が生じます。

安全でないバージョンの TLS/SSL には、次のような性質のいくつかが含まれる場合があります。

- 中間者 (man-in-the-middle) 攻撃に対する保護が行われない
- 認証と暗号化に同じ鍵が使用される
- メッセージ認証制御が脆弱である
- TCP 接続の切断に対して保護が行われない

このような性質があると、攻撃者による機密データの傍受、改変、改竄が可能になることがあります。

例 1: 次の Terraform 構成の例では、profile を COMPATIBLE に設定することで、プロキシ ロード バランサーによる弱い SSL 暗号スイートの使用を許可する SSL ポリシーを定義しています。

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "COMPATIBLE"
...
}

例 2: 次の Terraform 構成の例では、プロキシ ロード バランサーによる TLS_RSA_WITH_AES_128_CBC_SHA という名前の弱い SSL 暗号スイートの使用を具体的に許可するカスタム SSL ポリシーを定義しています。

resource "google_compute_ssl_policy" "policy-demo" {
...
  profile = "CUSTOM"
  min_tls_version = "TLS_1_2"
  custom_features = ["TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256", "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256", "TLS_RSA_WITH_AES_128_CBC_SHA"]
...
}

監査記録がないと、セキュリティ関連のインシデントを検出して対応する機能が制限され、フォレンジック調査が妨げられます。

ログ機能を損なう構成設定には次のものが含まれますが、これらに限定されません。
- 監査ログを意図的に無効にする
- 特定のユーザー、グループ、またはプロセスのアクションをログから除外する
- ログの整合性を不適切に保護する
- オプションの監査ログを有効にしない
- ログのサンプリング レートを下げる

監査記録がないと、セキュリティ関連のインシデントを検出して対応する機能が制限され、フォレンジック調査が妨げられます。

ログ機能を損なう構成設定には次のものが含まれますが、これらに限定されません。
- 監査ログを意図的に無効にする
- 特定のユーザー、グループ、またはプロセスのアクションをログから除外する
- ログの整合性を不適切に保護する
- オプションの監査ログを有効にしない
- ログのサンプリング レートを下げる

Terraform 構成は、使用状況ログとストレージ ログを有効にしないで Cloud Storage Bucket を作成します。これらのログには、ネットワーク監視、フォレンジック、リアルタイムのセキュリティ分析、およびコスト最適化に役立つ貴重なデータが含まれています。

例 1: 次の例は、log_bucket 引数がないため、使用状況ログとストレージ ログを有効にしないで Cloud Storage Bucket を作成する Terraform 構成を示しています。

resource "google_storage_bucket" "bucket-demo" {
    name     = "name-demo"
    location = "US"
}

デフォルトでは、Google Kubernetes Engine (GKE) クラスターは Stackdriver Kubernetes Engine Logging Service にログを書き込みます。Terraform 構成は、GKE クラスターをセットアップし、ログ サービスを明示的に無効にします。ログには、セキュリティ インシデントの特定、ポリシー違反の監視、および否認防止の制御を支援するために使用される、貴重なデータが含まれています。

例 1: 次の例は、logging_service を none に設定して GKE クラスターのログ サービスを無効にする Terraform 構成を示しています。

resource "google_container_cluster" "cluster-demo" {
    name            = "name-demo"
    location        = "us-central1-a"
    logging_service = "none"
    ...
}

デフォルトでは、Google Kubernetes Engine (GKE) クラスターが、ポッドから Stackdriver Kubernetes Engine Monitoring Service にメトリックを送信します。Terraform スクリプトは、GKE クラスターをセットアップし、監視サービスを明示的に無効にします。メトリックがないため、セキュリティ イベントを適切に検出し、これに迅速に応答することができなくなります。

例 1: 次の例は、monitoring_service を none に設定して GKE クラスターの監視サービスを無効にする Terraform 構成を示しています。

resource "google_container_cluster" "cluster-demo" {
    name               = "name-demo"
    location           = "us-central1-a"
    monitoring_service = "none"
    ...
}

監査記録がないと、セキュリティ関連のインシデントを検出して対応する機能が制限され、フォレンジック調査が妨げられます。

ログ機能を損なう構成設定には次のものが含まれますが、これらに限定されません。
- 監査ログを意図的に無効にする
- 特定のユーザー、グループ、またはプロセスのアクションをログから除外する
- ログの整合性を不適切に保護する
- オプションの監査ログを有効にしない
- ログのサンプリング レートを下げる

監査記録がないと、セキュリティ関連のインシデントを検出して対応する機能が制限され、フォレンジック調査が妨げられます。

ログ機能を損なう構成設定には次のものが含まれますが、これらに限定されません。
- 監査ログを意図的に無効にする
- 特定のユーザー、グループ、またはプロセスのアクションをログから除外する
- ログの整合性を不適切に保護する
- オプションの監査ログを有効にしない
- ログのサンプリング レートを下げる

Terraform 構成は、ログ オプションを指定せずに仮想マシン サブネットをセットアップします。これらのログには、ネットワーク監視、フォレンジック、リアルタイムのセキュリティ分析、およびコスト最適化に役立つ貴重なデータが含まれています。

権限の管理を誤ると、制限されたデータへの不正アクセスや改変のリスクが高まり、サービスの可用性が損なわれます。

サービス アカウントは、個人ではなくアプリケーションまたは VM によって使用される特別な Google アカウントで、エンド ユーザーに代わって自動化されたプロセスを実行したり API リクエストを行うために、機密性の高いアクセス許可を使用します。信頼性を確保するために、慎重に管理、制御、および監査する必要があります。サービス アカウント ロールを IAM ユーザー (通常は人を表す) に割り当てると、セキュリティ制御が弱まります。

不要なネットワーク トラフィックのブロックに失敗すると、クラウド サービスの攻撃対象領域が拡大します。一般に公開されているサービスは、悪意のあるエンティティによるほぼ継続的なスキャンとプロービングの対象になります。

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール

カスタマーマネージド暗号鍵 (CMEK) は、保存データに対して有効になっていません。

デフォルトでは、Google Cloud はランダムに生成されたデータ暗号鍵 (DEK) を使用して保存データを暗号化します。CMEK 機能を使用すると、組織は、選択した暗号化キーを使用して DEK を暗号化できます。これにより、組織は暗号化プロセスをより適切に制御し、ログに記録できます。

そのため、CMEK は通常、次のような要件 (これに限らない) に対処するソリューションの一部です。
- 機密データへのアクセスの監査ログ
- データ所在地
- キーの交換、無効化、または破棄
- 改ざん防止ハードウェア セキュリティ モジュール

URL マップは、受信 HTTP(S) リクエストを特定のバックエンド サービスにルーティングするための一連のルールです。デフォルトでは、URL マップは、暗号化されていない接続やセキュリティ保護されていない接続を受け入れます。このような接続では、データが不正アクセス、盗難、改ざんの危険にさらされます。

例 1: 次の例は、https_redirect を false に設定することで、クライアントが通信で HTTP を使用することを許可する URL マップを定義する Terraform 構成を示しています。

resource "google_compute_url_map" "urlmap" {
...
  default_url_redirect {
...
    https_redirect = false
...
  }
...
}

DNSSEC は、DNS 応答の検証にデジタル署名を使用する機能を提供することにより、DNS 偽装を防止します。ただし、SHA-1 を使用する DNSSEC 署名アルゴリズムは、増え続ける攻撃のリスクには脆弱です。SHA-1 は、デジタル署名で使用される場合、安全なハッシュ アルゴリズムとは見なされなくなりました。

例 1: 次の例は、安全ではない署名アルゴリズム rsasha1 を使用して DNSSEC を有効にする Terraform 構成を示しています。

resource "google_dns_managed_zone" "zone-demo" {
...
  dnssec_config {
    default_key_specs {
      algorithm = "rsasha1"
      ...
    }
  }
...
}

GKE は、2 つのクラスター ネットワーク モード (ルートベースと VPC ネイティブ) をサポートします。VPC ネイティブのクラスターは、エイリアス IP アドレスの範囲を使用して、ノード内のあるポッドから別のポッドにトラフィックをルーティングします。これにより、ポッドに対する正確な IP ベースのポリシーとファイアウォール ルールが可能になります。一方、ノード全体で詳細なレベルの制御を実現するのがルートベースのクラスターです。

例 1: 次の Terraform 構成の例では、networking_mode を ROUTES に設定しているため、VPC ネイティブのクラスターが有効になっていません。

resource "google_container_cluster" "cluster_demo" {
...
  networking_mode = "ROUTES"
..
}