전체 IPv4에 SSH를 허용하는 GCP 방화벽

SSH 관리 접근은 승인된 출발지와 대상 VM으로 제한하고 강한 인증을 함께 적용하세요.

설명

TCP 22를 0.0.0.0/0에 허용하면 네트워크 경로가 있는 모든 IPv4 출발지에서 SSH 연결을 시도할 수 있습니다. 외부 IP나 다른 연결 경로가 실제 도달 가능성을 결정하며, SSH 인증은 여전히 필요합니다. source_ranges와 source_tags를 함께 지정하면 둘 중 하나에 해당하는 트래픽이 허용되므로 태그가 전체 IPv4 범위를 좁혀 주지는 않습니다.

잠재적 영향

  • 접근 가능한 SSH 서비스가 자동화된 로그인 시도와 알려진 취약점 공격을 받을 수 있습니다.
  • 유출된 키나 취약한 인증이 악용되면 VM과 연결된 데이터·서비스가 침해될 수 있습니다.

해결 방법

  1. 전체 IPv4 허용을 제거하고 승인된 관리 출발지 또는 IAP·VPN 경로와 필요한 대상 VM으로 제한하세요.
  2. 다른 방화벽 규칙과 우선순위가 SSH를 넓게 허용하지 않는지 확인하세요. OS Login 같은 인증 통제는 네트워크 범위 제한을 대신하지 않습니다.
  3. 키와 IAM 권한을 최소화하고, 변경 후 허용된 관리 접속과 차단할 접속을 각각 시험하세요.

예시

실제 프로젝트와 인증 정보를 제공하고 적용할 VPC를 확인하세요. 네트워크를 생략하면 기본 네트워크가 사용됩니다.

google.cloud 1.14.0 모듈은 source_tags와 target_tags의 동시 입력을 거부합니다. 아래 태그 조합은 Compute Engine API의 허용 범위를 설명하며, 해당 모듈 버전에서 실행하려면 지원되는 출발지·대상 조합으로 조정해야 합니다.

변경 전

yaml
- name: ssh_unrestricted
  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
    source_ranges:
      - "0.0.0.0/0"

출발지 태그가 있어도 0.0.0.0/0에 해당하는 연결이 허용됩니다. 대상 태그는 이 규칙을 적용할 VM을 제한합니다.

변경 후

yaml
- name: ssh_restricted
  google.cloud.gcp_compute_firewall:
    name: test-object
    allowed:
      - ip_protocol: tcp
        ports:
          - "22"
    target_tags:
      - test-ssh-server
      - staging-ssh-server
    project: "{{ project_id }}"
    auth_kind: serviceaccount
    service_account_file: /tmp/auth.pem
    state: present
    source_ranges:
      - "203.0.113.10/32"

출발지를 하나의 IPv4 주소로 제한합니다. 203.0.113.10/32는 문서용 주소이므로 실제 관리 경로에서 사용되는 출발지 주소로 바꾸세요.

참조