설명
기본 방화벽 규칙에 의존하면 환경에 필요하지 않은 접근을 허용할 수 있습니다. 명확한 이름과 목적을 가진 방화벽 규칙을 직접 정의하면 어떤 통신을 왜 허용하는지 검토하기 쉽습니다. 다만 이름에 default가 있다는 사실만으로 위험한 규칙은 아니며, 이름을 바꾸어도 권한은 줄어들지 않습니다.
잠재적 영향
- 불필요한 소스나 서비스까지 접근이 허용될 수 있습니다.
- 방화벽 정책 의도가 불명확하면 검토와 감사가 어려워질 수 있습니다.
해결 방법
- 실제 규칙의 소스, 대상, 프로토콜과 포트를 업무 목적에 맞게 최소화하세요.
- 기존 규칙의 우선순위와 종속성을 확인하고 승인된 연결을 시험한 뒤 불필요한 규칙을 정리하세요.
예시
변경 전은 허용·거부 동작을 생략한 이름과 연결의 발췌입니다. 변경 후의 192.0.2.0/24는 문서용 주소이므로 승인된 실제 클라이언트 대역으로 바꾸고, 대상 VM에 web-server 태그를 설정하세요.
변경 전
hcl
resource "google_compute_firewall" "example" {
name = "default"
network = google_compute_network.example.name
}
resource "google_compute_network" "example" {
name = "test-network"
}
변경 후
hcl
resource "google_compute_firewall" "example" {
name = "web-ingress-firewall"
network = google_compute_network.example.name
source_ranges = ["192.0.2.0/24"]
target_tags = ["web-server"]
allow {
protocol = "tcp"
ports = ["80", "8080"]
}
}
resource "google_compute_network" "example" {
name = "test-network"
}
설명:
- 변경 전: 이름이 default일 뿐 실제 접근 범위는 이 발췌만으로 정해지지 않습니다.
- 변경 후: 이름뿐 아니라 소스와 대상, TCP 포트를 명시합니다. 실제 서비스에 80과 8080이 필요한지도 확인하세요.