GCP の既定のファイアウォールルールによるアクセス範囲の確認

説明

デフォルトネットワークのファイアウォールルールは初期接続を容易にしますが、サービスに必要な範囲を超える場合があります。例えば、既定の SSH・RDP ルールは IPv4 全体を送信元として許可します。ルール名だけで権限は決まらないため、実際の送信元、対象、プロトコル、ポート、優先度を確認してください。

想定される影響

• 広い受信許可と外部からの接続経路があると、管理サービスに不要な接続が試みられる可能性があります。
• 内部 VM 間の過剰な許可も、侵害された VM から他のサービスへのアクセスを容易にします。

対処方法

1. 各許可ルールが必要か確認し、管理元、対象 VM、ポートを最小限にしてください。名前の変更だけではアクセス範囲は狭まりません。
2. 内部 VM 間の通信には適切な送信元・対象タグやサービスアカウントを使用し、それらを変更できる権限も制限してください。
3. 既存の広い許可ルールを削除または修正し、適用されるファイアウォールポリシーと実際の接続を確認してください。名前やネットワークが異なるルールを追加しても、以前のルールは削除されません。

例

実際のネットワーク、プロジェクト、認証情報が必要な抜粋です。

google.cloud 1.14.0 モジュールは source_tags と target_tags の同時指定を拒否します。以下のタグの組み合わせは Compute Engine API の許可範囲を示すもので、そのモジュール版で実行するには対応する送信元・対象の組み合わせに調整してください。

変更前

- name: create a firewall2
  google.cloud.gcp_compute_firewall:
    name: default
    allowed:
      - ip_protocol: tcp
        ports:
          - "22"
    state: present
    network: "{{ my_network2 }}"

この受信ルールは送信元と対象を制限していません。送信元の既定値は 0.0.0.0/0 で、指定したネットワークの VM に TCP 22 を許可します。実際の外部接続には、到達可能なネットワーク経路も必要です。

変更後

- name: create a firewall
  google.cloud.gcp_compute_firewall:
    name: test-object
    allowed:
      - ip_protocol: tcp
        ports:
          - "22"
    target_tags:
      - test-ssh-server
      - staging-ssh-server
    source_tags:
      - test-ssh-clients
    project: "{{ project_id }}"
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present
    network: "{{ my_network }}"

同じ VPC 内で、指定した送信元タグと対象タグを持つ VM 間の SSH を許可します。二つの例はルール名とネットワークの入力が異なるため、既存ルールの置き換えは別途行ってください。

参考資料

• CWE-1188
• Ansible のファイアウォール設定
• VPC ファイアウォールと既定のルール
• Compute Engine Firewall API