クラスターの中央管理エンティティである Kubernetes API サーバーは、HTTP 基本認証を受け入れてユーザーを認証します。HTTP 基本認証は非推奨であり、ブルートフォース攻撃の影響を受けやすく、誤って設定された環境では攻撃者にユーザー資格情報を漏らす可能性があります。

例 1: 次の例は、master_auth ブロックの username と password を空でない値に設定することにより、GKE クラスターで HTTP 基本認証を有効にする Terraform 構成を示しています。

resource "google_container_cluster" "container_cluster_demo" {
...
  master_auth {
    username = "foo"
    password = "bar"
  }
...
}

デフォルトでは、属性ベースのアクセス制御 (ABAC) は、GKE バージョン 1.8 以降を実行する新しいクラスターでは無効になっています。ABAC は、ロールベースのアクセス制御 (RBAC) またはアイデンティティ/アクセス管理 (IAM) で提供される機能のほか、特定のユーザーまたはグループにリソースへのアクセスを静的に許可できます。これにより、承認管理が複雑になり、アクセス制御の集中管理がしにくくなります。

例 1: 次の例は、enable_legacy_abac を true に設定して GKE クラスターの ABAC 承認を有効にする Terraform 構成を示しています。

resource "google_container_cluster" "container_cluster_demo" {
...
  enable_legacy_abac = true
...
}

各クラウド サービス セキュリティ機能は、既知の脅威を防止または軽減するように設計されています。意図的にまたは誤って無効にされた場合、保護は提供されません。

デフォルトでは、GKE ノードが一定期間にわたって異常なステータスを繰り返し報告すると、GKE はそのノードの修復プロセスを開始します。ノードの自動修復を無効にすると、ミッション クリティカルなワークロードが実行される可能性のある異常なノードが適切なタイミングで自動交換されません。

例 1: 次の Terraform 構成では、management ブロックの auto_repair を false に設定して、ノード プールのノード自動修復を無効にします。

resource "google_container_node_pool" "node-pool-demo" {
...
  management {
    auto_repair = false
    ...
  }
...
}

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

プライベート GKE ノードには外部 IP アドレスがありません。これらのノードで実行されるポッドは、クラスターの境界を超えて通信できません。パブリック エンドポイントを無効にすると、GKE クラスターの管理が内部のプライベート IP アドレスに制限されて、GKE クラスターが保護されます。プライベート エンドポイントとプライベート ノードを強制しないと、クラスターがパブリックに公開されます。

例 1: 次の Terraform 構成では、enable_private_nodes および enable_private_endpoint が false に設定されているため、任意の IP アドレスがクラスター ノードとコントロール プレーンにアクセスできます。

resource "google_container_cluster" "cluster-demo" {
...
  private_cluster_config {
    enable_private_endpoint = false
    enable_private_nodes = false
  }
...
}

デフォルトでは、GKE ノードは Container-Optimized OS (COS) を使用して実行されます。COS は、Google Compute Engine インスタンスで GKE ノードを実行するように最適化されたオペレーティング システム イメージです。デフォルトをオプトアウトすると、セキュリティと効率が向上するというメリットがなくなります。

例 1: 次の Terraform 構成の例では、node_config ブロックで image_type が COS 以外のイメージに設定されているため、COS を実行しない GKE ノードのプールをセットアップしています。

resource "google_container_node_pool" "node_pool_demo" {
  ...
  node_config {
    image_type = "UBUNTU"
    ...
  }
  ...
}

デフォルトでは、GKE は Kubernetes ノードを安定した新しいバージョンに自動的にアップグレードします。既知のソフトウェアの脆弱性にタイムリーにパッチを適用する自動アップグレードは無効になっています。

例 1: 次の Terraform 構成の例では、management ブロックの auto_upgrade を false に設定することで、Kubernetes ノードの自動アップグレードを無効にしています。

resource "google_container_node_pool" "node_pool_demo" {
...
  management {
    auto_upgrade = false
    ...
  }
...
}

新しい Google Cloud プロジェクトは、デフォルトで、プロジェクト全体のネットワークを開始します。デフォルト ネットワークには、同一プロジェクト内の Compute Engine インスタンス間で行われる制限なしの通信を許可し、セキュリティが重要な全インスタンスのポートを公開するファイアウォール ルールが事前に設定されます。影響を受けるポートには、TCP 22 (SSH) と TCP 3389 (RDP) が含まれます。十分に保護されていないインスタンスは、不正アクセスに対して脆弱になります。

例 1: 次の Terraform 構成の例では、auto_create_network を true に設定することで、プロジェクト全体のネットワークの自動生成を有効にしています。

resource "google_project" "project-demo" {
...
  auto_create_network = true
...
}

Terraform 構成は、サービス アカウントのアクセス スコープを cloud-platform に設定します。これにより、ほとんどの Google Cloud API へのアクセスが許可されます。その結果、侵害された Compute Engine インスタンスがアクセスできる攻撃対象領域が大幅に拡大し、最小特権の原則に違反することになります。

例 1: 次の例は、サービス アカウントのアクセス スコープ (scopes) を cloud-platform に設定する Terraform 構成を示しています。

resource "google_compute_instance" "compute-instance-demo" {
    name         = "name-demo"
    machine_type = "e2-micro"
    ...
    service_account {
        email  = "foobar.service.account@example.com"
        scopes = ["cloud-platform"]
    }
}

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

例 1: 次の例は、example.com という名前のドメインについて、ssl_settings ブロックを含まない Terraform 構成を示しています。その結果、App Engine アプリケーションのカスタム ドメインは HTTPS をサポートしていません。

resource "google_app_engine_domain_mapping" "domain_mapping" {
  domain_name = "example.com"
}

デフォルトでは、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"
    ...
}

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

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