Virtual Private Cloud(VPC) 방화벽 규칙이 특정 프로젝트 및 네트워크에 적용됩니다. 조직의 여러 VPC 네트워크에 방화벽 규칙을 적용하려면 방화벽 정책을 참조하세요. 이 페이지의 나머지 부분에서는 VPC 방화벽 규칙만 다룹니다.
VPC 방화벽 규칙을 사용하면 VPC 네트워크의 가상 머신(VM) 인스턴스에 대한 연결을 허용하거나 거부할 수 있습니다. 사용 설정한 VPC 방화벽 규칙은 인스턴스의 구성 및 운영 체제와 상관없이 인스턴스를 보호할 수 있도록 항상 실행됩니다. 아직 시작하지 않은 인스턴스도 마찬가지입니다.
모든 VPC 네트워크는 분산형 방화벽으로 작동합니다. 방화벽 규칙은 네트워크 수준에서 정의되지만 연결은 인스턴스별로 허용되거나 거부됩니다. VPC 방화벽 규칙은 인스턴스와 다른 네트워크 사이뿐만 아니라 동일한 네트워크 내의 개별 인스턴스 간에 존재하는 것으로 생각할 수 있습니다.
방화벽에 대한 자세한 내용은 방화벽(컴퓨팅)을 참조하세요.
방화벽 규칙 권장사항
방화벽 규칙을 설계하고 평가할 때 다음 권장사항을 고려하세요.
- 최소 권한 원칙을 구현합니다. 기본적으로 모든 트래픽을 차단하고 필요한 특정 트래픽만 허용합니다. 여기에는 필요한 프로토콜 및 포트로만 규칙을 제한하는 것이 포함됩니다.
- 계층식 방화벽 정책 규칙을 사용하여 허용되어서는 안 되는 트래픽을 조직 또는 폴더 수준에서 차단합니다.
- '허용' 규칙의 경우 VM의 서비스 계정을 지정하여 특정 VM으로 제한합니다.
- IP 주소를 기반으로 규칙을 만들어야 하는 경우 규칙 수를 최소화합니다. 16개의 개별 규칙을 추적하는 것보다 16개의 VM 범위로 들어오는 트래픽을 허용하는 규칙 한 개를 추적하는 것이 더 쉽습니다.
- 방화벽 규칙 로깅을 사용하고 방화벽 통계를 사용하여 방화벽 규칙이 의도한 방식으로 사용되고 있는지 확인합니다. 방화벽 규칙 로깅은 비용이 발생할 수 있으므로 선택적으로 사용하는 것이 좋습니다.
Google Cloud의 방화벽 규칙
VPC 방화벽 규칙을 만들 때 VPC 네트워크와 규칙의 역할을 정의하는 구성요소 집합을 지정합니다. 구성요소를 사용하면 트래픽의 프로토콜, 포트, 소스, 목적지를 기준으로 특정 트래픽 유형을 대상으로 지정할 수 있습니다. 자세한 내용은 방화벽 규칙 구성요소를 참조하세요.
Google Cloud Console, Google Cloud CLI, REST API를 사용하여 VPC 방화벽 규칙을 만들거나 수정합니다. 방화벽 규칙을 만들거나 수정할 때 규칙의 대상 매개변수를 사용하여 적용할 인스턴스를 지정할 수 있습니다. 방화벽 규칙 예시는 기타 구성 예시를 참조하세요.
작성하는 방화벽 규칙 외에도 Google Cloud에는 수신(인그레스) 또는 송신(이그레스) 연결에 영향을 줄 수 있는 다른 규칙이 있습니다.
Google Cloud는 특정 트래픽을 차단하거나 제한합니다. 자세한 내용은 차단 및 제한된 트래픽을 참조하세요.
Google Cloud는 VM 인스턴스와
169.254.169.254
에 있는 대응하는 메타데이터 서버 간 통신을 항상 허용합니다. 자세한 내용은 항상 허용되는 트래픽을 참조하세요.모든 네트워크에는 나가는 연결을 허용하고 들어오는 연결을 차단하는 두 가지 묵시적인 방화벽 규칙이 있습니다. 생성한 방화벽 규칙은 이러한 묵시적 규칙에 우선합니다.
기본 네트워크에는 방화벽 규칙이 미리 입력되며, 이러한 규칙은 삭제하거나 수정할 수 있습니다.
사양
VPC 방화벽 규칙의 특징은 다음과 같습니다.
각 방화벽 규칙은 수신(인그레스)이나 송신(이그레스) 연결 중 하나에 적용됩니다. 두 연결 모두에 함께 적용되지는 않습니다. 자세한 내용은 연결 방향을 참조하세요.
방화벽 규칙은 IPv4 연결을 지원합니다. IPv6 연결은 IPv6이 사용 설정된 VPC 네트워크에서도 지원됩니다. 주소로 인그레스 또는 이그레스 규칙의 소스 또는 대상을 지정할 때 IPv4 또는 IPv6 주소 또는 블록을 CIDR 표기법으로 지정할 수 있습니다.
각 방화벽 규칙은 IPv4 또는 IPv6 범위 중 하나를 포함할 수 있지만 둘 다 포함할 수는 없습니다.
각 방화벽 규칙의 작업은
allow
또는deny
입니다. 규칙은 시행되는 중에만 연결에 적용됩니다. 예를 들어 문제 해결을 위해 규칙을 사용 중지할 수 있습니다.방화벽 규칙을 만들 때는 VPC 네트워크를 선택해야 합니다. 규칙을 인스턴스 수준에서 시행한다면, 규칙의 구성은 VPC 네트워크와 연결됩니다. 따라서 VPC 네트워크 피어링 또는 Cloud VPN 터널를 통해 연결된 네트워크 등 VPC 네트워크 간에는 방화벽 규칙을 공유할 수 없습니다.
VPC 방화벽 규칙은 스테이트풀(Stateful)입니다.
- 어떤 방향으로든 방화벽을 통해 연결이 허용되는 경우 이 연결과 일치하는 반환 트래픽도 허용됩니다. 연결된 응답 트래픽을 거부하도록 방화벽 규칙을 구성할 수는 없습니다.
- 반환 트래픽은 수락된 요청 트래픽의 5튜플(소스 IP, 대상 IP, 소스 포트, 대상 포트, 프로토콜)과 일치해야 하지만 소스 및 대상 주소와 포트가 반대로 되어 있어야 합니다.
- Google Cloud는 연결 추적 테이블을 사용하여 수신 패킷을 해당 아웃바운드 패킷과 연결합니다. IPv4 연결은 TCP, UDP, SCTP, ICMP 프로토콜을 지원합니다. IPv6 연결은 TCP, UDP, SCTP, ICMPv6 프로토콜을 지원합니다.
- Google Cloud는 프로토콜이 연결을 지원하는지 여부에 관계없이 연결 추적을 구현합니다. 소스와 대상 간(인그레스 규칙의 경우) 또는 대상과 목적지 간(이그레스 규칙의 경우)의 연결이 허용되는 경우 모든 응답 트래픽은 방화벽의 연결 추적 상태가 활성 상태인 동안 허용됩니다. 10분마다 하나 이상의 패킷이 전송되는 경우 방화벽 규칙의 추적은 활성 상태로 간주됩니다.
- 조각화된 연결이 방화벽을 통해 허용될 때 Google Cloud는 연결 추적을 사용해서 반환 트래픽의 첫 번째 조각만 허용합니다. 후속 반환 조각을 허용하려면 방화벽 규칙을 추가해야 합니다.
- 허용되는 TCP/UDP 연결에 대한 응답으로 생성된 'ICMP TYPE 3, DESTINATION UNREACHABLE'과 같은 ICMP 응답 트래픽은 방화벽을 통해 허용됩니다. 이 동작은 RFC 792과 일치합니다.
VPC 방화벽 규칙은 조각화된 TCP 패킷을 재구성하지 않습니다. 따라서 TCP 프로토콜에 적용할 수 있는 방화벽 규칙은 첫 번째 조각에만 적용할 수 있습니다(TCP 헤더가 포함되어 있기 때문에). TCP 프로토콜에 적용할 수 있는 방화벽 규칙은 후속 TCP 조각에는 적용되지 않습니다.
방화벽 규칙 테이블에서 추적된 최대 연결 수는 인스턴스의 머신 유형에서 지원하는 스테이트풀(Stateful) 연결 수에 따라 다릅니다. 추적된 최대 연결 수를 초과하면 새 연결이 추적될 수 있도록 유휴 간격이 가장 긴 연결에 대해 추적이 중지됩니다.
인스턴스 머신 유형 최대 스테이트풀(Stateful) 연결 수 공유 코어 머신 유형 130,000 1~8개의 vCPU가 있는 인스턴스 vCPU당 130,000개의 연결 9개 이상의 vCPU가 있는 인스턴스 총 1,040,000(130,000 × 8)개의 연결
묵시적인 규칙
모든 VPC 네트워크에는 두 가지 묵시적인 IPv4 방화벽 규칙이 있습니다. IPv6가 VPC 네트워크에서 사용 설정된 경우 네트워크에는 2개의 묵시적 IPv6 방화벽 규칙도 있습니다. 이러한 규칙은 Google Cloud 콘솔에 표시되지 않습니다.
네트워크가 생성되는 방법 및 자동 모드 또는 커스텀 모드 VPC 네트워크인지 여부와 관계없이 모든 VPC 네트워크에는 묵시적인 IPv4 방화벽 규칙이 있습니다. 기본 네트워크에는 동일한 묵시적 규칙이 적용됩니다.
묵시적 IPv4 이그레스 허용 규칙 작업이
allow
, 목적지가0.0.0.0/0
, 우선순위가 가장 낮은(65535
) 이그레스 규칙을 사용하면 모든 인스턴스가 Google Cloud에서 차단하는 트래픽을 제외한 모든 목적지에 트래픽을 전송할 수 있습니다. 우선순위가 더 높은 방화벽 규칙은 아웃바운드 액세스를 제한할 수 있습니다. 아웃바운드 트래픽을 거부하는 다른 방화벽 규칙이 없고 인스턴스에 외부 IP 주소가 있거나 Cloud NAT 인스턴스를 사용하는 경우 인터넷 액세스가 허용됩니다. 자세한 내용은 인터넷 액세스 요구 사항을 참조하세요.라우팅 요구사항에 대한 자세한 내용은 인터넷 액세스 요구사항을 참조하세요.
묵시적 IPv4 인그레스 거부 규칙 작업이
deny
, 소스가0.0.0.0/0
, 우선순위가 가장 낮은(65535
) 인그레스 규칙은 모든 인스턴스로 수신되는 연결을 차단하여 보호합니다. 우선순위가 더 높은 규칙은 수신 액세스를 허용할 수도 있습니다. 기본 네트워크에는 이 규칙을 재정의하는 추가 규칙이 포함되어 있어 특정 유형의 수신 연결을 허용합니다.
IPv6가 사용 설정된 경우 VPC 네트워크에는 다음과 같은 두 가지 묵시적 규칙도 있습니다.
묵시적 IPv6 이그레스 허용 규칙 작업이
allow
, 목적지가::/0
, 우선순위가 가장 낮은(65535
) 이그레스 규칙을 사용하면 모든 인스턴스가 Google Cloud에서 차단하는 트래픽을 제외한 모든 목적지에 트래픽을 전송할 수 있습니다. 우선순위가 더 높은 방화벽 규칙은 아웃바운드 액세스를 제한할 수 있습니다. 라우팅 요구사항에 대한 자세한 내용은 인터넷 액세스 요구사항을 참조하세요.묵시적 IPv6 인그레스 거부 규칙 작업이
deny
, 소스가::/0
, 우선순위가 가장 낮은(65535
) 인그레스 규칙은 모든 인스턴스로 수신되는 연결을 차단하여 보호합니다. 우선순위가 더 높은 규칙은 수신 액세스를 허용할 수도 있습니다.
묵시적 규칙은 삭제할 수 없지만 우선순위는 가장 낮습니다. 규칙의 우선순위가 더 높으면 규칙을 재정의하는 규칙을 만들 수 있습니다(우선순위 번호가 65535
미만). deny
규칙은 우선순위가 동일한 allow
규칙에 우선하기 때문에 우선순위가 65535
인 인그레스 allow
규칙은 절대로 적용되지 않습니다.
기본 네트워크에 미리 입력된 규칙
기본 네트워크에는 인스턴스로 들어오는 연결을 허용하는 방화벽 규칙이 미리 입력됩니다. 이러한 규칙은 필요에 따라 삭제하거나 수정할 수 있습니다.
규칙 이름 | 방향 | 우선순위 | 소스 범위 | 작업 | 프로토콜 및 포트 | 설명 |
---|---|---|---|---|---|---|
default-allow-internal
|
ingress
|
65534
|
10.128.0.0/9
|
allow
|
tcp:0-65535
|
동일한 VPC 네트워크 내의 다른 인스턴스에서 VM 인스턴스로 들어오는 연결을 허용합니다. |
default-allow-ssh
|
ingress
|
65534
|
0.0.0.0/0
|
allow
|
tcp:22
|
ssh , scp , sftp 등의 도구를 사용하여 인스턴스에 연결할 수 있습니다.
|
default-allow-rdp
|
ingress
|
65534
|
0.0.0.0/0
|
allow
|
tcp:3389
|
Microsoft 원격 데스크톱 프로토콜을 사용하여 인스턴스에 연결할 수 있습니다. |
default-allow-icmp
|
ingress
|
65534
|
0.0.0.0/0
|
allow
|
icmp
|
ping 등의 도구를 사용할 수 있습니다.
|
기본 네트워크 외의 네트워크에도 유사한 방화벽 규칙을 만들 수 있습니다. 자세한 내용은 일반적인 사용 사례의 방화벽 규칙 구성을 참조하세요.
차단된 트래픽 및 제한된 트래픽
Google Cloud는 VPC 방화벽 규칙과 계층식 방화벽 정책과 별도로 다음 표에 설명된 특정 트래픽을 차단하거나 제한합니다.
트래픽 유형 | 세부정보 |
---|---|
패킷 속도 및 대역폭
적용 대상:
|
Google Cloud는 각 네트워크 인터페이스(NIC) 또는 IP 주소에 대해 VM 인스턴스당 대역폭을 고려합니다. VM의 머신 유형은 가능한 최대 이그레스 속도를 정의하지만 이 가능한 최대 이그레스 속도는 특정 상황에서만 달성할 수 있습니다. 자세한 내용은 Compute Engine 문서의 네트워크 대역폭을 참조하세요. |
DHCP 오퍼 및 확인
적용 대상:
|
Google Cloud는 메타데이터 서버에서 수신되는 DHCP 패킷을 제외한 모든 소스에서 수신되는 DHCP 오퍼 및 확인을 차단합니다. |
Google Cloud 외부 IP 주소에서 지원하는 프로토콜
적용 대상:
|
외부 IPv4 및 IPv6 주소는 TCP, UDP, ICMP, IPIP, AH, ESP, SCTP, GRE 패킷만 허용합니다. 외부 IP 주소를 사용하는 리소스에는 추가 프로토콜 제한이 적용됩니다.
|
SMTP(포트 25) 트래픽
적용 대상:
|
기본적으로 Google Cloud는 외부 IP 주소(다른 Google Cloud 리소스의 외부 IP 주소 포함)의 TCP 대상 포트 25로 전송된 이그레스 패킷을 차단합니다. 하지만 일부 Google Cloud 고객이 소유한 프로젝트에서는 이 트래픽이 차단되지 않습니다. Google Cloud 콘솔에서 VPC 네트워크 페이지와 방화벽 정책 페이지 모두의 SMTP 포트 25가 프로젝트에 허용되었는지 여부를 나타내는 메세지가 표시됩니다. 이 블록은 VPC 네트워크 또는 온프레미스 네트워크에서 비공개로 사용되는 공개 IP 주소를 포함하여 내부 IP 주소의 TCP 대상 포트 25로 전송된 이그레스 패킷에는 적용되지 않습니다. 프로젝트에서 포트 25에 외부 SMTP 이그레스가 허용되고 이 유형의 트래픽을 보내려면 다음 추가 조건을 충족해야 합니다.
이그레스 거부 VPC 방화벽 규칙 또는 계층식 방화벽 정책을 만들면 외부 SMTP 이그레스를 방지할 수 있습니다. |
항상 허용된 트래픽
VM 인스턴스의 경우 VPC 방화벽 규칙과 계층식 방화벽 정책은 다음에 적용되지 않습니다.
- Google Cloud 메타데이터 서버와 주고받는 패킷
패킷이 VM 자체에서 유지되는 인스턴스의 자체 네트워크 인터페이스(NIC) 중 하나에 할당된 IP 주소로 전송된 패킷: 인스턴스의 NIC에 할당되는 IP 주소는 다음과 같습니다.
- NIC의 기본 내부 IPv4 주소
- NIC의 별칭 IP 범위에 속한 모든 내부 IPv4 주소
- 서브넷에 IPv6를 구성한 경우 NIC에 할당된 모든 IPv6 주소
- 인스턴스가 부하 분산기의 백엔드이거나 프로토콜 전달의 대상 인스턴스인 경우 부하 분산 및 프로토콜 전달을 위해 전달 규칙과 연결된 내부 또는 외부 IPv4 주소
- 루프백 주소
- 인스턴스 자체 내에서 실행하는 네트워킹 오버레이 소프트웨어의 일부로 구성된 주소
Google Cloud 메타데이터 서버
Google Cloud에서는 로컬 메타데이터 서버를 169.254.169.254
에 있는 각 인스턴스와 함께 실행합니다. 이 서버는 인스턴스 작동에 필수적이며, 따라서 어떤 방화벽 규칙을 구성하더라도 인스턴스는 이 서버에 액세스할 수 있습니다. 메타데이터 서버는 다음과 같은 기본 서비스를 인스턴스에 제공합니다.
- DHCP
- VPC 네트워크의 DNS 이름 확인 순서에 따른 DNS 확인
- 인스턴스 메타데이터
- 네트워크 시간 프로토콜(NTP)
제품 상호작용
다음 섹션에서는 방화벽 규칙과 계층식 방화벽 정책이 다른 Google Cloud 제품과 상호작용하는 방법을 설명합니다.
방화벽 규칙 및 패스스루 부하 분산기
VPC 방화벽 규칙 및 계층식 방화벽 정책은 패스스루 부하 분산기의 백엔드에 액세스하도록 허용되는 전달 규칙의 지원되는 프로토콜 및 포트를 제어합니다. 자세한 내용은 다음을 참고하세요.
방화벽 규칙 및 프록시 부하 분산기
외부 애플리케이션 부하 분산기, 내부 애플리케이션 부하 분산기, 내부 프록시 네트워크 부하 분산기, 외부 프록시 네트워크 부하 분산기의 경우 VPC 방화벽 규칙과 계층식 방화벽 정책은 프록시 부하 분산기의 전달 규칙 IP 주소로 허용되는 프로토콜과 포트를 제어하지 않습니다. 프록시 부하 분산기에서 허용하는 프로토콜과 포트는 전달 규칙만으로 결정됩니다.
VPC 방화벽 규칙과 계층식 방화벽 정책은 이러한 프록시 부하 분산기가 백엔드와 통신하는 방법을 제어합니다. 자세한 내용은 다음을 참고하세요.
- 외부 애플리케이션 부하 분산기 문서의 방화벽 규칙
- 내부 애플리케이션 부하 분산기 문서의 방화벽 규칙
- 내부 프록시 네트워크 부하 분산기 문서의 방화벽 규칙
- 외부 프록시 네트워크 부하 분산기 문서의 방화벽 규칙
방화벽 규칙 및 Cloud VPN
방화벽 규칙 및 계층식 방화벽 정책은 Cloud VPN 게이트웨이에서 허용하는 프로토콜과 포트를 제어하지 않습니다.
Cloud VPN 게이트웨이는 Cloud VPN 사양에 설명된 프로토콜과 포트의 패킷만 허용합니다.
방화벽 규칙 및 GKE
Google Kubernetes Engine은 클러스터 또는 클러스터에 리소스(서비스 및 수신 포함)를 만들 때 방화벽 규칙을 자동으로 만들고 관리합니다. 자세한 내용은 Google Kubernetes Engine 문서의 자동으로 생성된 방화벽 규칙을 참조하세요.
방화벽 규칙 구성요소
각 방화벽 규칙은 다음 구성 요소로 구성됩니다.
대상의 관점에서의 방향. 방향은 인그레스 또는 이그레스일 수 있습니다.
숫자 우선순위: 규칙 적용 여부를 결정합니다. 다른 구성요소가 트래픽과 일치하는 가장 높은 우선순위(가장 낮은 우선순위 번호) 규칙만 적용됩니다. 우선순위가 낮은 충돌 규칙은 무시됩니다.
일치 시 작업(
allow
또는deny
): 규칙이 연결을 허용할지 차단할지 결정합니다.방화벽 규칙 적용 상태: 방화벽 규칙을 삭제하지 않고도 사용 설정하거나 사용 중지할 수 있습니다.
대상: 규칙이 적용되는 인스턴스(GKE 클러스터 및 App Engine 가변형 환경 인스턴스 포함)를 정의합니다.
패킷 특성에 대한 소스 또는 대상 필터
프로토콜(예: TCP, UDP, ICMP) 및 대상 포트
Cloud Logging에 규칙과 일치하는 연결을 로깅하는 부울 로그 옵션
구성요소 요약
인그레스(인바운드) 규칙 | ||||||
---|---|---|---|---|---|---|
우선순위 | 작업 | 적용 | 타겟 매개변수 | 소스 및 대상 필터 | 프로토콜 및 포트 | |
0 부터 65535 까지의 정수이며 기본값은 1000 입니다. |
allow 또는 deny |
enabled (기본값) 또는 disabled |
패킷을 수신하는 인스턴스를 지정합니다. | 프로토콜 또는 프로토콜과 대상 포트를 지정합니다. 설정하지 않으면 규칙이 모든 프로토콜과 대상 포트에 적용됩니다. 자세한 내용은 프로토콜 및 포트를 참조하세요. |
||
이그레스(아웃바운드) 규칙 | ||||||
우선순위 | 작업 | 적용 | 타겟 매개변수 | 소스 및 대상 필터 | 프로토콜 및 포트 | |
0 부터 65535 까지의 정수이며 기본값은 1000 입니다. |
allow 또는 deny |
enabled (기본값) 또는 disabled |
패킷을 전송하는 인스턴스를 지정합니다. | 프로토콜 또는 프로토콜과 대상 포트를 지정합니다. 설정하지 않으면 규칙이 모든 프로토콜과 대상 포트에 적용됩니다. 자세한 내용은 프로토콜 및 포트를 참조하세요. |
트래픽 방향
인그레스 또는 이그레스 트래픽에 적용되는 방화벽 규칙을 만들 수 있습니다. 단일 규칙은 인그레스 및 이그레스 트래픽 모두에 적용할 수 없습니다. 하지만 여러 규칙을 만들어 방화벽을 통해 허용하거나 거부하는 인그레스 및 이그레스 트래픽을 정의할 수 있습니다.
인그레스(인바운드)는 대상의 네트워크 인터페이스로 들어오는 패킷을 설명합니다.
이그레스(아웃바운드)는 대상의 네트워크 인터페이스에서 나가는 패킷을 설명합니다.
방향을 지정하지 않으면 Google Cloud가 인그레스를 사용합니다.
우선순위
방화벽 규칙 우선 순위는 0
에서 65535
사이의 정수입니다. 낮은 정수는 높은 우선 순위를 나타냅니다. 규칙을 만들 때 우선 순위를 지정하지 않으면 우선 순위가 1000
으로 지정됩니다.
방화벽 규칙의 상대적 우선순위는 다른 규칙에 대해 평가할 때 적용 가능한지 여부를 결정합니다. 평가 논리는 다음과 같습니다.
지정된 유형의 트래픽 대상에 적용할 수 있는 최우선 순위 규칙이 우선시됩니다. 대상 특이성은 중요하지 않습니다. 예를 들어 모든 대상을 위한 특정 대상 포트 및 프로토콜에 대해 우선순위가 높은 인그레스 규칙은 특정 대상을 위한 동일한 대상 포트 및 프로토콜에 대해 우선순위가 낮은 비슷하게 정의된 규칙을 재정의합니다.
프로토콜 및 대상 포트 정의가 보다 일반적인 경우에도 주어진 프로토콜 및 대상 포트 정의에 적용할 수 있는 최상위 우선순위 규칙이 우선시됩니다. 예를 들어 지정된 대상을 대상으로 하는 모든 프로토콜 및 대상 포트에 대한 트래픽을 허용하는 우선순위가 높은 인그레스 규칙은 동일한 대상의 TCP 22 포트를 거부하는 우선순위가 낮은 인그레스 규칙을 재정의합니다.
두 규칙의 우선순위가 동일한 경우에만
deny
작업이 있는 규칙이allow
작업이 있는 규칙을 재정의합니다. 상대적 우선순위를 사용하면deny
규칙을 재정의하는allow
규칙과allow
규칙을 재정의하는deny
규칙을 작성할 수 있습니다.동일한 우선순위와 작업을 갖고 있는 규칙은 동일한 결과를 도출합니다. 하지만 평가 과정에서 사용하는 규칙은 확정적이지 않습니다. 일반적으로 방화벽 규칙 로깅을 사용 설정할 때를 제외하면 어떤 규칙을 사용하는가는 중요하지 않습니다. 평가 중인 방화벽 규칙이 일관되고 명확한 순서로 로그에 표시되도록 하려면 고유한 우선순위를 할당하세요.
두 가지 방화벽 규칙이 있는 다음 예시를 고려합니다.
소스
0.0.0.0/0
(모든 IPv4 주소)의 인그레스 규칙은deny
작업이 있고 우선순위가1000
인 모든 대상, 모든 프로토콜, 모든 대상 포트에 적용할 수 있습니다.소스
0.0.0.0/0
(모든 IPv4 주소)의 인그레스 규칙은webserver
네트워크 태그가 있는 특정 대상에 적용할 수 있습니다(TCP 80 트래픽의 경우allow
작업으로).
두 번째 규칙의 우선순위는 포트 80의 TCP 트래픽이 webserver
대상에 허용되는지 여부를 결정합니다.
두 번째 규칙의 우선순위가
1000
보다 큰 숫자로 설정되면 우선순위가 낮아지므로, 모든 트래픽을 거부하는 첫 번째 규칙이 적용됩니다.두 번째 규칙의 우선순위가
1000
으로 설정되면 두 규칙의 우선순위가 동일하므로 모든 트래픽을 거부하는 첫 번째 규칙이 적용됩니다.두 번째 규칙의 우선순위가
1000
보다 작은 숫자로 설정되면 우선순위가 높아지므로 TCP 80에서webserver
대상에 대한 트래픽을 허용합니다. 다른 규칙이 없으면 첫 번째 규칙은webserver
대상에 대한 다른 유형의 트래픽을 거부하며,webserver
네트워크 태그가 없는 인스턴스에 대해 TCP 80을 포함한 모든 트래픽을 거부합니다.
앞의 예시는 우선순위를 사용하여 선택적인 allow
규칙과 전체적인 deny
규칙을 만들어 최소 권한의 보안 권장사항을 구현하는 방법을 보여줍니다.
일치 시 작업
방화벽 규칙의 작업 구성요소는 규칙의 다른 구성요소에 따라 트래픽의 허용 또는 차단 여부를 결정합니다.
allow
작업은 지정된 다른 구성요소와 일치하는 연결을 허용합니다.deny
작업은 지정된 다른 구성요소와 일치하는 연결을 차단합니다.
적용
상태를 enabled
또는 disabled
로 설정하여 방화벽 규칙 적용 여부를 선택할 수 있습니다. 규칙을 생성하거나 규칙을 업데이트할 때 적용 상태를 설정합니다.
새 방화벽 규칙을 만들 때 적용 상태를 설정하지 않으면 방화벽 규칙이 자동으로 enabled
로 설정됩니다.
사용 사례
사용 중지 및 사용 설정은 문제 해결 및 유지보수를 수행하는 데 유용합니다. 다음과 같은 경우 방화벽 규칙의 적용 변경을 고려하세요.
문제 해결: 방화벽 규칙 로깅과 함께 방화벽 규칙을 일시적으로 중지하면 규칙이 트래픽을 차단하거나 허용하는지 확인할 수 있습니다. 여러 방화벽 규칙이 동일한 트래픽에 적용되는 경우에 유용합니다. 규칙을 중지했다가 사용 설정하면 규칙의 다른 구성요소가 손실되지 않기 때문에 규칙을 삭제하고 다시 만드는 것보다 유용합니다.
유지보수: 방화벽 규칙을 사용 중지하면 주기적 유지보수가 간소화될 수 있습니다. 예를 들어 SSH를 사용하여 유지보수를 수행해야 하는 시점에만 SSH 액세스를 허용하는 인그레스 방화벽 규칙을 사용 설정할 수 있습니다. 유지보수를 수행하지 않을 때는 규칙을 사용 중지할 수 있습니다.
기존 트래픽에 미치는 영향
방화벽 규칙의 적용 상태를 변경하거나 enforced
상태의 새 규칙을 만들면 해당 변경사항이 새 연결에만 적용됩니다.
기존 연결은 이러한 변경사항의 영향을 받지 않습니다.
프로토콜 및 포트
프로토콜을 지정하거나 프로토콜 및 대상 포트를 함께 지정하여 방화벽 규칙의 범위를 좁힐 수 있습니다. 프로토콜만 지정할 수도 있고 프로토콜과 대상 포트의 조합을 지정할 수도 있습니다. 프로토콜과 포트를 모두 생략하면 방화벽 규칙이 전체 프로토콜과 대상 포트의 모든 트래픽에 적용됩니다. 소스 포트를 기반으로 하는 규칙은 지원되지 않습니다.
모든 프로토콜이 포트를 지원하지는 않습니다. 예를 들어 TCP와 UDP용 포트는 있지만 ICMP용은 없습니다. ICMP에 다양한 ICMP 유형이 있지만 이러한 유형은 포트가 아니며, 방화벽 규칙에 지정될 수 없습니다.
방화벽 규칙에서 다음 프로토콜 이름을 사용할 수 있습니다. tcp
, udp
, icmp
(IPv4 ICMP용), esp
, ah
, sctp
, ipip
다른 모든 프로토콜의 경우 IANA 프로토콜 번호를 사용해야 합니다.
많은 프로토콜이 IPv4와 IPv6 모두에서 동일한 이름과 번호를 사용하지만 ICMP와 같은 일부 프로토콜은 사용하지 않습니다.
IPv6 홉별 프로토콜은 방화벽 규칙에서 지원되지 않습니다.
다음은 Google Cloud 방화벽 규칙에서 사용할 수 있는 프로토콜 및 대상 포트 사양 조합을 요약한 표입니다.
사양 | 예 | 설명 |
---|---|---|
프로토콜 및 포트 없음 | — | 프로토콜을 지정하지 않으면 방화벽 규칙은 모든 프로토콜과 관련 대상 포트에 적용됩니다. |
프로토콜 | tcp |
포트 정보 없이 프로토콜만 지정하면 방화벽 규칙은 해당 프로토콜과 프로토콜 관련 포트 전체에 적용됩니다. |
프로토콜 및 단일 포트 | tcp:80 |
프로토콜과 단일 대상 포트를 지정하면 방화벽 규칙은 프로토콜의 해당 대상 포트에만 적용됩니다. |
프로토콜 및 포트 범위 | tcp:20-22 |
프로토콜과 포트 범위를 지정하면 방화벽 규칙은 프로토콜의 해당 대상 포트 범위에만 적용됩니다. |
조합 | icmp,tcp:80 tcp:443 udp:67-69 |
방화벽 규칙이 적용되는 프로토콜 및 대상 포트의 다양한 조합을 지정할 수 있습니다. 자세한 내용은 방화벽 규칙 만들기를 참조하세요. |
타겟, 소스, 대상
타겟은 방화벽 규칙이 적용되는 인스턴스의 네트워크 인터페이스를 식별합니다.
인그레스 및 이그레스 방화벽 규칙 모두에 대해 패킷 소스 또는 대상에 적용되는 소스 및 대상 매개변수를 모두 지정할 수 있습니다. 방화벽 규칙의 방향에 따라 소스 및 목적지 매개변수에 사용할 수 있는 값이 결정됩니다.
타겟 매개변수
타겟 매개변수는 GKE 노드 및 App Engine 가변형 환경 인스턴스를 포함하여 Compute Engine 인스턴스의 네트워크 인터페이스를 식별합니다.
인그레스 또는 이그레스 규칙 모두에 대해 다음 타겟을 정의할 수 있습니다. 대상, 소스, 대상 매개변수는 소스, 대상, 타겟의 설명대로 함께 작동합니다.
기본 타겟 - VPC 네트워크의 모든 인스턴스 대상 사양을 생략하면 방화벽 규칙이 VPC 네트워크의 모든 인스턴스에 적용됩니다.
대상 네트워크 태그별 인스턴스. 인스턴스에 방화벽 규칙의 대상 네트워크 태그 중 최소 하나 이상과 일치하는 네트워크 태그가 있는 경우 방화벽 규칙은 방화벽 규칙 VPC 네트워크에 네트워크 인터페이스가 있는 인스턴스에만 적용됩니다. 방화벽 규칙별로 지정할 수 있는 최대 대상 네트워크 태그 수는 방화벽 규칙별 한도를 참조하세요.
대상 서비스 계정별 인스턴스: 인스턴스에서 방화벽 규칙 대상 서비스 계정 중 최소 하나 이상과 일치하는 서비스 계정을 사용하는 경우 방화벽 규칙은 방화벽 규칙 VPC 네트워크에 네트워크 인터페이스가 있는 인스턴스에만 적용됩니다. 방화벽 규칙별로 지정할 수 있는 최대 대상 서비스 계정 수는 방화벽 규칙별 한도를 참조하세요.
대상 네트워크 태그와 대상 서비스 계정의 이점과 제한사항은 서비스 계정 및 네트워크 태그별 필터링을 참조하세요.
인그레스 규칙의 타겟 및 IP 주소
대상 VM의 네트워크 인터페이스로 라우팅된 패킷은 다음 조건을 기준으로 처리됩니다.
인그레스 방화벽 규칙에 대상 IP 주소 범위가 포함되는 경우 패킷의 대상이 명시적으로 정의된 대상 IP 주소 범위 중 하나에 속해야 합니다.
인그레스 방화벽 규칙에 대상 IP 주소 범위가 포함되지 않는 경우, 패킷의 대상이 다음 IP 주소 중 하나와 일치해야 합니다.
인스턴스의 NIC에 할당된 기본 내부 IPv4 주소
인스턴스의 NIC에 구성된 모든 별칭 IP 범위
인스턴스의 NIC와 연결된 외부 IPv4 주소
서브넷에 IPv6를 구성한 경우 NIC에 할당된 모든 IPv6 주소
인스턴스가 내부 패스 스루 네트워크 부하 분산기 또는 외부 패스 스루 네트워크 부하 분산기의 백엔드인 패스 스루 부하 분산에 사용되는 전달 규칙과 연결된 내부 또는 외부 IP 주소
인스턴스가 대상 인스턴스에서 참조되는 경우 프로토콜 전달에 사용되는 전달 규칙과 연결된 내부 또는 외부 IP 주소
인스턴스를 다음 홉 VM(
next-hop-instance
또는next-hop-address
)으로 사용하는 커스텀 정적 경로의 대상 범위에 속한 IP 주소VM이 내부 패스 스루 네트워크 부하 분산기의 백엔드인 경우 이 부하 분산기(
next-hop-ilb
) 다음 홉을 사용하는 커스텀 정적 경로의 대상 범위에 속한 IP 주소
이그레스 규칙의 타겟 및 IP 주소
대상의 네트워크 인터페이스에서 내보낸 패킷의 처리는 대상 VM의 IP 전달 구성에 따라 달라집니다. IP 전달은 기본적으로 사용 중지되어 있습니다.
대상 VM이 IP 전달을 사용 중지하면 VM은 다음 소스를 사용하여 패킷을 내보낼 수 있습니다.
인스턴스 NIC의 기본 내부 IPv4 주소
인스턴스 NIC의 모든 구성된 별칭 IP 범위
서브넷에 IPv6를 구성한 경우 NIC에 할당된 모든 IPv6 주소
인스턴스가 내부 패스 스루 네트워크 부하 분산기, 외부 패스 스루 네트워크 부하 분산기의 백엔드이거나 대상 인스턴스에서 참조되는 경우 패스 스루 부하 분산 또는 프로토콜 전달을 위해 전달 규칙과 연결된 내부 또는 외부 IP 주소
이그레스 방화벽 규칙에 소스 IP 주소 범위가 포함되는 경우 대상 VM은 여전히 이전에 언급된 소스 IP 주소로 제한되지만 소스 매개변수를 사용하여 해당 세트를 세분화할 수 있습니다. IP 전달을 사용 설정하지 않고 소스 매개변수를 사용하면 가능한 패킷 소스 주소 집합이 확장되지 않습니다.
이그레스 방화벽 규칙에 소스 IP 주소 범위가 포함되지 않으면 이전에 언급된 모든 소스 IP 주소가 허용됩니다.
대상 VM에 IP 전달이 사용 설정된 경우 VM이 임의의 소스 주소로 패킷을 내보낼 수 있습니다. 소스 매개변수를 사용하면 허용되는 패킷 소스 집합을 보다 정확하게 정의할 수 있습니다.
소스 매개변수
소스 매개변수 값은 방화벽 규칙의 방향에 따라 달라집니다.
인그레스 규칙의 소스
인그레스 방화벽 규칙에 다음 소스를 사용할 수 있습니다.
기본 소스 범위: 인그레스 규칙에서 소스 사양을 생략하면 Google Cloud가 기본 소스 IPv4 주소 범위
0.0.0.0/0
(모든 IPv4 주소)을 사용합니다. 기본값에는 IPv6 소스가 포함되지 않습니다.소스 IPv4 범위: CIDR 형식의 IPv4 주소 목록입니다.
소스 IPv6 범위: CIDR 형식의 IPv6 주소 목록입니다.
소스 네트워크 태그: 방화벽 규칙과 동일한 VPC 네트워크에서 VM 인스턴스의 네트워크 인터페이스를 식별하는 하나 이상의 네트워크 태그입니다. 방화벽 규칙별 최대 소스 네트워크 태그 수는 방화벽 규칙별 한도를 참조하세요. 이 암시적 소스 사양을 사용할 때 패킷 소스 주소를 일치시키는 방법에 대한 자세한 내용은 소스 네트워크 태그와 소스 서비스 계정이 패킷 소스를 암시하는 방법을 참조하세요.
소스 서비스 계정: 방화벽 규칙과 동일한 VPC 네트워크에서 VM 인스턴스의 네트워크 인터페이스를 식별하는 하나 이상의 서비스 계정입니다. 방화벽 규칙별 최대 소스 서비스 계정 수는 방화벽 규칙별 한도를 참조하세요. 이 암시적 소스 사양을 사용할 때 패킷 소스 주소를 일치시키는 방법에 대한 자세한 내용은 소스 네트워크 태그와 소스 서비스 계정이 패킷 소스를 암시하는 방법을 참조하세요.
유효한 소스 조합: 다음 모든 조합에서 유효한 소스 세트는 명시적으로 지정된 IPv4 또는 IPv6 주소와 소스 네트워크 태그나 소스 서비스 계정에서 암시하는 IP 주소 범위의 통합입니다.
- 소스 IPv4 범위 및 소스 네트워크 태그의 조합
- 소스 IPv6 범위와 소스 네트워크 태그의 조합
- 소스 IPv4 범위와 소스 서비스 계정의 조합
- 소스 IPv6 범위와 소스 서비스 계정의 조합
소스 네트워크 태그와 소스 서비스 계정이 패킷 소스를 암시하는 방법
인그레스 방화벽 규칙에서 소스 네트워크 태그를 사용하는 경우에는 다음 기준을 충족하는 네트워크 인터페이스에서 패킷을 배출해야 합니다.
- 네트워크 인터페이스는 방화벽 규칙이 정의된 VPC 네트워크에 있어야 합니다.
- 네트워크 인터페이스는 방화벽 규칙의 소스 네트워크 태그 중 최소 하나 이상과 일치하는 네트워크 태그가 있는 VM과 연결되어야 합니다.
인그레스 방화벽 규칙에 소스 서비스 계정이 사용될 경우 다음 기준을 충족하는 네트워크 인터페이스에서 패킷을 배출해야 합니다.
- 네트워크 인터페이스는 방화벽 규칙이 정의된 VPC 네트워크에 있어야 합니다.
- 네트워크 인터페이스는 방화벽 규칙의 소스 서비스 계정 중 하나와 일치하는 서비스 계정이 있는 VM과 연결되어야 합니다.
네트워크 인터페이스를 지정하는 것 외에도, 인그레스 방화벽 규칙에 소스 네트워크 태그 또는 소스 서비스 계정이 사용될 경우 VM의 네트워크 인터페이스에서 배출된 패킷은 다음과 같은 유효한 소스 IP 주소 중 하나를 사용해야 합니다.
- 해당 네트워크 인터페이스의 기본 내부 IPv4 주소
- 해당 네트워크 인터페이스에 할당된 모든 IPv6 주소
인그레스 방화벽 규칙에도 목적지 IP 주소 범위가 포함된 경우 네트워크 태그에 바인딩된 네트워크 인터페이스는 목적지 IP 범위와 동일한 IP 버전으로 확인됩니다.
소스 네트워크 태그 또는 소스 서비스 계정을 사용할 때 다른 패킷 소스 IP 주소는 암시되지 않습니다. 예를 들어 네트워크 인터페이스와 연관된 별칭 IP 범위 및 외부 IPv4 주소가 제외됩니다. 소스에 별칭 IP 주소 범위 또는 외부 IPv4 주소가 포함된 인그레스 방화벽 규칙을 만들어야 하는 경우에는 소스 IPv4 범위를 사용합니다.
이그레스 규칙의 소스
이그레스 방화벽 규칙에 다음 소스를 사용할 수 있습니다.
기본값 — 대상에 의해 암시됨: 이그레스 규칙에서 소스 매개변수를 생략하면 패킷 소스가 이그레스 규칙의 대상 및 IP 주소에 설명된 대로 암시적으로 정의됩니다
소스 IPv4 범위: CIDR 형식의 IPv4 주소 목록입니다.
소스 IPv6 범위: CIDR 형식의 IPv6 주소 목록입니다.
다음 안내에 따라 이그레스 규칙의 소스 IP 주소 범위를 추가합니다.
VM 인터페이스에 내부 및 외부 IPv4 주소가 모두 할당되어 있으면 규칙 평가 중에 내부 IPv4 주소만 사용됩니다.
이그레스 규칙에서 소스 및 대상 매개변수를 모두 지정할 경우 두 매개변수에 동일한 IP 버전을 사용합니다. IPv4 주소 범위 또는 IPv6 주소 범위 중 하나를 사용할 수 있고 둘 다 사용할 수는 없습니다. 자세한 내용은 이그레스 규칙의 대상을 참조하세요.
대상 매개변수
대상은 인그레스 및 이그레스 규칙 모두에서 지원되는 IP 주소 범위를 사용하여 지정할 수 있습니다. 기본 대상 동작은 규칙의 방향에 따라 달라집니다.
인그레스 규칙의 대상
인그레스 방화벽 규칙에 다음 대상을 사용할 수 있습니다.
기본값 - 대상에 암시됨. 인그레스 규칙에서 대상 매개변수를 생략하면 패킷 대상은 인그레스 규칙의 대상 및 IP 주소에 설명된 대로 암시적으로 정의됩니다.
대상 IPv4 범위: CIDR 형식의 IPv4 주소 목록입니다.
대상 IPv6 범위: CIDR 형식의 IPv6 주소 목록입니다.
다음 안내에 따라 인그레스 규칙의 대상 IP 주소 범위를 추가합니다.
VM 인터페이스에 내부 및 외부 IPv4 주소가 모두 할당되어 있으면 규칙 평가 중에 내부 IPv4 주소만 사용됩니다.
인그레스 규칙에서 소스 및 대상 매개변수를 모두 지정하는 경우 소스 매개변수가 대상 IP 주소 범위와 동일한 IP 버전으로 확인됩니다. 인그레스 규칙의 소스를 정의하는 방법은 인그레스 규칙의 소스를 참조하세요.
이그레스 규칙의 대상
이그레스 방화벽 규칙에 다음 대상을 사용할 수 있습니다.
기본 대상 범위. 이그레스 규칙에서 대상 사양을 생략하면 Google Cloud가 기본 대상 IPv4 주소 범위
0.0.0.0/0
(모든 IPv4 주소)을 사용합니다. 기본값에는 IPv6 대상이 포함되지 않습니다.대상 IPv4 범위: CIDR 형식의 IPv4 주소 목록입니다.
대상 IPv6 범위: CIDR 형식의 IPv6 주소 목록입니다.
서비스 계정별 소스 및 대상 필터링
서비스 계정을 사용하여 실제로 더욱 구체적인 방화벽 규칙을 만들 수 있습니다.
인그레스 및 이그레스 규칙 모두에 대해 서비스 계정을 사용하여 대상을 지정할 수 있습니다.
인그레스 규칙의 경우 수신 패킷에 대한 소스를 VM이 특정 서비스 계정을 사용하는 네트워크 내 VM의 기본 내부 IP 주소로 지정할 수 있습니다.
서비스 계정에 의존하는 방화벽 규칙을 만들기 전에 서비스 계정을 방화벽 규칙과 동일한 프로젝트에 만들어야 합니다. 시스템이 다른 프로젝트의 서비스 계정을 사용하는 규칙을 만드는 것을 막지는 못하지만, 방화벽 규칙의 프로젝트에 서비스 계정이 없으면 규칙이 시행되지 않습니다.
서비스 계정을 사용하여 인스턴스를 식별하는 방화벽 규칙은 서비스 계정으로 생성되어 연결된 새 인스턴스에 적용되며, 서비스 계정을 변경했다면 기존 인스턴스에도 적용됩니다. 인스턴스와 관련된 서비스 계정을 변경하려면 인스턴스를 중지했다가 다시 시작해야 합니다. 서비스 계정을 개별 인스턴스 및 관리형 인스턴스 그룹에서 사용하는 인스턴스 템플릿과 연결할 수 있습니다.
서비스 계정별 필터링 및 네트워크 태그별 필터링
이 섹션에서는 대상 또는 소스(인그레스 규칙의 경우)를 정의하는 데 서비스 계정이나 네트워크 태그를 사용해야 하는지 여부를 결정할 때 고려해야 할 주요 사항을 강조 표시합니다.
VM에 적용되는 방화벽 규칙을 엄격하게 제어해야 하는 경우 대상 네트워크 태그 및 소스 네트워크 태그 대신 대상 서비스 계정 및 소스 서비스 계정을 사용합니다.
네트워크 태그는 임의의 속성입니다. 인스턴스를 수정할 수 있는 권한이 있는 모든 Identity and Access Management(IAM) 주 구성원이 하나 이상의 네트워크 태그를 인스턴스에 연결할 수 있습니다. 프로젝트에 대한 Compute Engine 인스턴스 관리자 역할이 있는 IAM 주 구성원에게 이 권한이 있습니다. 인스턴스를 편집할 수 있는 IAM 주 구성원은 해당 네트워크 태그를 변경할 수 있으며, 이로 인해 해당 인스턴스에 해당하는 방화벽 규칙 세트가 변경될 수 있습니다.
서비스 계정은 인스턴스와 관련된 ID를 나타냅니다. 하나의 서비스 계정만 인스턴스와 연결할 수 있습니다. 다른 IAM 주 구성원에 대한 서비스 계정 사용자 역할의 권한을 제어하여 서비스 계정에 대한 액세스를 제어할 수 있습니다. IAM 주 구성원이 서비스 계정을 사용하여 인스턴스를 시작하려면 최소 해당 서비스 계정을 사용할 수 있는 서비스 계정 사용자 역할과 인스턴스를 만들 수 있는 적합한 권한이 있어야 합니다(예: 프로젝트에 대한 Compute Engine 인스턴스 관리자 역할 보유).
어떠한 방화벽 규칙에서도 서비스 계정과 네트워크 태그를 조합하여 사용할 수 없습니다.
어떠한 방화벽 규칙에서도(인그레스 또는 이그레스) 대상 서비스 계정과 대상 네트워크 태그를 함께 사용할 수 없습니다.
다음은 대상 네트워크 태그 또는 대상 서비스 계정별로 대상을 지정하는 경우 인그레스 방화벽 규칙에 대해 잘못된 소스입니다.
대상 잘못된 소스 대상 네트워크 태그 소스 서비스 계정
소스 IP 범위와 소스 서비스 계정의 조합대상 서비스 계정 소스 네트워크 태그
소스 IP 범위와 소스 네트워크 태그의 조합
서비스 계정 및 네트워크 태그에 대한 운영 고려사항은 다음과 같습니다.
인스턴스의 서비스 계정을 변경하려면 인스턴스를 중지했다가 다시 시작해야 합니다. 인스턴스 실행 중 네트워크 태그를 추가하거나 삭제할 수 있습니다.
방화벽 규칙에 지정할 수 있는 대상 서비스 계정, 소스 서비스 계정, 대상 네트워크 태그, 소스 네트워크 태그에는 상한이 존재합니다. 자세한 내용은 방화벽 규칙별 한도를 참조하세요.
네트워크 태그로 인스턴스를 식별한다면 방화벽 규칙이 인스턴스의 기본 내부 IP 주소에 적용됩니다.
서비스 계정 방화벽 규칙은 GKE pod가 아닌 GKE 노드에 적용됩니다.
역할 및 권한
다음 표에서는 VPC 방화벽 규칙을 사용하는 데 필요한 Identity and Access Management(IAM) 권한을 설명합니다.
작업 | 필요한 권한 | 샘플 역할 |
---|---|---|
방화벽 규칙 만들기 |
compute.firewalls.create
|
Compute 보안 관리자 ( roles/compute.securityAdmin )
|
방화벽 규칙 삭제 |
compute.firewalls.delete
|
Compute 보안 관리자 ( roles/compute.securityAdmin )
|
방화벽 규칙 변경 |
compute.firewalls.update
|
Compute 보안 관리자 ( roles/compute.securityAdmin )
|
방화벽 규칙 세부정보 보기 |
compute.firewalls.get
|
Compute 네트워크 뷰어 ( roles/compute.networkViewer ) |
방화벽 규칙 목록 보기 |
compute.firewalls.list
|
Compute 네트워크 뷰어 ( roles/compute.networkViewer ) |
사용 사례
다음 사용 사례에서는 방화벽 규칙의 작동 방식을 보여줍니다. 이 예시에서는 모든 방화벽 규칙이 사용 설정되어 있습니다.
인그레스 사례
인그레스 방화벽 규칙은 소스에서 VPC 네트워크의 대상 인스턴스로 들어가는 연결을 제어합니다. 인그레스 규칙의 소스는 다음 중 하나로 정의할 수 있습니다.
- IPv4 또는 IPv6 주소 범위로 기본값은 모든 IPv4 주소(
0.0.0.0/0
)입니다. - 네트워크 태그별로 식별된 VPC 네트워크의 다른 인스턴스
- 서비스 계정별로 식별된 VPC 네트워크의 다른 인스턴스
- IPv4 또는 IPv6 주소 범위 및 네트워크 태그별로 식별된 VPC 네트워크의 다른 인스턴스
- IPv4 또는 IPv6 주소 범위 및 서비스 계정별로 식별된 VPC 네트워크의 다른 인스턴스
기본 소스는 모든 IPv4 주소(0.0.0.0/0
)입니다. 인터넷의 다른 소스를 포함하여 VPC 네트워크 외부 소스의 수신 연결을 제어하려면 CIDR 형식의 IP 주소 범위를 사용합니다.
allow
작업이 있는 인그레스 규칙은 규칙의 다른 구성요소를 기반으로 수신 트래픽을 허용합니다. 규칙의 소스와 대상을 지정하는 것 외에도 특정 프로토콜과 대상 포트에 적용되도록 규칙을 제한할 수 있습니다. 마찬가지로 deny
작업이 있는 인그레스 규칙을 사용하여 방화벽 규칙 구성요소를 기반으로 수신되는 트래픽을 차단하여 인스턴스를 보호할 수 있습니다.
인그레스 예시
그림 1은 방화벽 규칙으로 인그레스 연결을 제어할 수 있는 인그레스 연결의 몇 가지 예시를 보여줍니다. 예시에서는 규칙 할당에서 대상 매개변수를 사용하여 특정 인스턴스에 규칙을 적용합니다.
우선순위가
1000
인 인그레스 규칙은 VM 1에 적용할 수 있습니다. 이 규칙은 모든 IPv4 소스(0.0.0.0/0
)에서 들어오는 TCP 트래픽을 허용합니다. 다른 인스턴스에 적용되는 이그레스 규칙에 따라 VPC 네트워크의 다른 인스턴스로부터의 TCP 트래픽이 허용됩니다. VM 4에는 이러한 통신을 차단하는 이그레스 규칙이 없으므로 VM 4는 TCP를 통해 VM 1과 통신할 수 있습니다(묵시적 이그레스 허용 규칙만 적용). VM 1에는 외부 IP가 있으므로 이 규칙은 인터넷의 외부 호스트에서 들어오거나 외부 IP 주소를 통해 VM 2에서 들어오는 TCP 트래픽을 허용합니다.VM 2에는 지정된 인그레스 방화벽 규칙이 없으므로 묵시적 인그레스 거부 규칙은 들어오는 모든 트래픽을 차단합니다. 다른 인스턴스의 이그레스 규칙과 관계없이 네트워크의 다른 인스턴스로부터의 연결은 차단됩니다. VM 2에는 외부 IP가 있기 때문에 인터넷의 외부 호스트에서 외부 IP로 이어지는 경로가 있지만, 이 묵시적 거부 인그레스 규칙은 외부 수신 트래픽도 차단합니다.
우선순위가
1000
인 인그레스 규칙은 VM 3에 적용할 수 있습니다. 이 규칙은 VM 4.와 같은 네트워크 태그client
가 있는 네트워크의 인스턴스에서 TCP 트래픽을 허용합니다. VM 4에는 이러한 통신을 차단하는 이그레스 규칙이 없으므로 VM 4에서 VM 3으로의 TCP 트래픽이 허용됩니다(묵시적 이그레스 허용 규칙만 적용). VM 3에는 외부 IP가 없기 때문에 인터넷의 외부 호스트에서 외부 IP로 이어지는 경로가 없습니다.
이그레스 사례
이그레스 방화벽 규칙은 VPC 네트워크의 대상 인스턴스에서 나가는 연결을 제어합니다. allow
작업이 있는 이그레스 규칙은 규칙의 다른 구성요소를 기반으로 인스턴스에서 트래픽을 허용합니다. 예를 들어 지정한 프로토콜 및 대상 포트에서 특정 목적지(예: IPv4 주소 범위)로 가는 아웃바운드 트래픽을 허용할 수 있습니다. 이와 마찬가지로 deny
작업이 있는 이그레스 규칙은 규칙의 다른 구성요소에 따라 트래픽을 차단합니다.
모든 이그레스 규칙에는 목적지가 필요합니다. 기본 대상은 모든 IPv4 주소(0.0.0.0/0
)이지만 CIDR 형식의 IPv4 또는 IPv6 주소 범위를 사용하여 보다 구체적인 대상을 만들 수 있습니다. IP 주소 범위를 지정할 때 인터넷의 대상을 포함하여 네트워크의 인스턴스와 네트워크 외부의 대상에 대한 트래픽을 제어할 수 있습니다.
이그레스 예시
그림 2는 방화벽 규칙으로 이그레스 연결을 제어할 수 있는 이그레스 연결의 몇 가지 예시를 보여줍니다. 예시에서는 규칙 할당에서 대상 매개변수를 사용하여 특정 인스턴스에 규칙을 적용합니다.
VM 1에는 지정된 이그레스 방화벽 규칙이 없으므로 묵시적 이그레스 허용 규칙을 사용하면 모든 목적지로 트래픽을 보낼 수 있습니다. VPC 네트워크의 다른 인스턴스에 대한 연결은 해당 인스턴스에 적용 가능한 인그레스 규칙에 따라 허용됩니다. VM 4는 임의의 IP 주소 범위에서 들어오는 트래픽을 허용하는 인그레스 규칙을 가지고 있으므로 VM 1은 VM 4로 트래픽을 보낼 수 있습니다. VM 1에는 외부 IP 주소가 있으므로 인터넷의 외부 호스트로 트래픽을 보낼 수 있습니다. 방화벽 규칙이 스테이트풀(Stateful) 방식이므로 VM 1에서 보낸 트래픽에 대한 수신 응답이 허용됩니다.
우선순위가
1000
인 이그레스 규칙은 VM 2에 적용할 수 있습니다. 이 규칙은 모든 IPv4 대상(0.0.0.0/0
)으로 나가는 모든 트래픽을 거부합니다. VPC 네트워크의 다른 인스턴스로 나가는 트래픽은 다른 인스턴스에 적용되는 인그레스 규칙과 관계없이 차단됩니다. VM 2에 외부 IP가 있더라도 이 방화벽 규칙은 인터넷의 외부 호스트로 나가는 트래픽을 차단합니다.우선순위가
1000
인 이그레스 규칙은 VM 3에 적용할 수 있습니다. 이 규칙은192.168.1.0/24
IP 범위의 모든 목적지로 나가는 TCP 트래픽을 차단합니다. VM 4의 인그레스 규칙이 들어오는 모든 트래픽을 허용하더라도 VM 3은 TCP 트래픽을 VM 4로 보낼 수 없습니다. 그러나 이그레스 규칙이 TCP 프로토콜에만 적용되기 때문에 VM 3은 VM 4로 UDP 트래픽을 보낼 수 있습니다.또한 VM 3은
192.168.1.0/24
IP 범위를 벗어나는 VPC 네트워크의 다른 인스턴스로 트래픽을 전송할 수 있습니다. 단, 다른 인스턴스에 이러한 트래픽을 허용하는 인그레스 규칙이 있어야 합니다. 외부 IP 주소가 없으므로 VPC 네트워크 외부로 트래픽을 전송할 경로가 없습니다.
다음 단계
- 방화벽 규칙을 만들고 사용하려면 VPC 방화벽 규칙 사용을 참조하세요.
직접 사용해 보기
Google Cloud를 처음 사용하는 경우 계정을 만들어 실제 시나리오에서 Cloud NGFW의 성능을 평가할 수 있습니다. 신규 고객에게는 워크로드를 실행, 테스트, 배포하는 데 사용할 수 있는 $300의 무료 크레딧이 제공됩니다.
Cloud NGFW 무료로 사용해 보기