KIMKYUTAE.COM · ©
CSP 보안에서의 Cloud Firewall과 Security Group
클라우드 네트워크를 구성하다 보면 한 가지 의문이 생긴다. Security Group이 있는데 왜 별도의 Cloud Firewall이 필요할까?
둘 다 IP와 Port를 기준으로 트래픽을 허용하거나 차단할 수 있다. 그래서 기능 목록만 보면 비슷해 보인다.
하지만 CSP(Cloud Service Provider)의 입장에서 보면 두 기능은 같은 일을 중복해서 하는 것이 아니다. 정책이 적용되는 위치, 트래픽을 처리하는 방법, 검사 깊이, 장애 영향 범위, 그리고 Control Plane이 침해되었을 때의 Blast Radius가 다르다.
Security Group은 워크로드 가까이에서 통신 범위를 줄이고, Cloud Firewall은 주요 Traffic Path에서 더 깊은 보안 검사를 수행한다.
1. 가장 큰 차이: Workload를 지키는가, Traffic Path를 지키는가
Security Group은 일반적으로 VM, NIC, ENI처럼 실제 워크로드와 가까운 위치에서 통신을 제어한다.
반면 Cloud Firewall은 Internet ↔ VPC/VNet, VPC 간 통신, On-Premise ↔ Cloud 같은 주요 네트워크 경로에 트래픽을 통과시키고 검사하는 형태로 사용한다.
쉽게 생각하면 Security Group은 Workload-oriented Security Control이고, Cloud Firewall은 Traffic-path-oriented Security Control이다.
중요한 것은 제품 이름이 아니라 실제 Enforcement Point가 어디에 있고 어떤 트래픽이 반드시 그 지점을 통과하는가다. 중앙형처럼 보이는 서비스도 내부 Data Plane은 분산될 수 있고, 반대로 분산형 정책도 하나의 Control Plane에 강하게 의존할 수 있다.
2. Security Group: 정책은 중앙에서 만들지만 Enforcement는 분산된다
Security Group을 단순한 ACL 목록으로만 보면 CSP 내부 구조에서 중요한 부분을 놓치기 쉽다.
고객은 API나 Console에서 하나의 정책을 생성하지만, 실제 정책은 CSP의 SDN Data Plane을 통해 해당 워크로드와 가까운 Enforcement Point에 배포된다. 구현 위치는 CSP에 따라 Virtual Switch, Host Networking Stack, Hypervisor, SmartNIC/DPU 등으로 달라질 수 있다.
이 구조의 장점은 확장성이다. VM이 수십만 대로 늘어나더라도 모든 패킷을 하나의 중앙 장비로 보내지 않고, 필요한 정책을 여러 Enforcement Point에 분산해서 적용할 수 있다.
그렇다고 Blast Radius까지 자동으로 작아지는 것은 아니다. 수많은 워크로드가 하나의 Security Group이나 공통 정책 템플릿을 공유하고 있다면 정책 변경 한 번이 넓은 범위로 전파될 수 있다.
즉 Data Plane이 분산되어 있다는 사실과 Control Plane의 영향 범위가 작다는 것은 서로 다른 이야기다.
3. Cloud Firewall: 트래픽 자체를 검사 경로로 보낸다
Cloud Firewall은 정책만 워크로드로 보내는 방식과 다르다. 검사하려는 트래픽이 실제 Firewall Data Plane을 통과하도록 Routing을 구성하는 경우가 많다.
AWS Network Firewall을 예로 들면 Availability Zone별 Firewall Endpoint를 만들고 Route Table을 이용해 검사 대상 트래픽을 Endpoint로 전달한다. AWS 공식 문서 역시 Network Firewall이 Stateful/Stateless Rule Engine을 제공하며, Stateful Engine에서 Suricata 호환 규칙과 Deep Packet Inspection을 사용할 수 있다고 설명한다.
여기서 중요한 것은 방화벽이 존재한다는 것보다 트래픽이 실제로 방화벽을 경유하는가다.
Internet 경로는 검사하지만 VPC Peering, VPN, 전용회선, 내부 서비스 경로가 우회한다면 그 구간은 Cloud Firewall의 보호 범위 밖에 있을 수 있다. 그래서 CSP 보안점검에서는 정책 파일만 보는 것만큼 Routing과 Traffic Path를 확인하는 것이 중요하다.
4. 같은 Stateful이라도 패킷을 보는 깊이는 다르다
Security Group과 Cloud Firewall은 모두 Stateful 방식으로 동작할 수 있다. 하지만 Stateful이라는 공통점만으로 같은 수준의 보안 기능이라고 볼 수는 없다.
| 항목 | Security Group | Cloud Firewall |
|---|---|---|
| 주요 목적 | 워크로드 접근제어 | 네트워크 경로 보안검사 |
| 일반적인 검사 기준 | IP, Port, Protocol 등 L3/L4 | L3/L4 + 서비스에 따라 L7 검사 |
| Stateful | 지원 | 지원 |
| Payload/DPI | 일반적으로 하지 않음 | 서비스에 따라 지원 |
| IDS/IPS | 일반적으로 없음 | 서비스에 따라 지원 |
| Domain/FQDN 제어 | 제한적 | 서비스에 따라 지원 |
Security Group은 매우 많은 워크로드에 빠르게 적용할 수 있어야 한다. 반면 Cloud Firewall은 더 많은 연산 비용을 쓰더라도 탐지와 검사를 강화하는 쪽에 가깝다.
결국 두 서비스는 “누가 더 강력한가?”의 문제가 아니다. 어디에서 어느 정도 깊이까지 검사할 것인가라는 설계 선택에 가깝다.
5. CSP 보안에서는 Rule보다 Control Plane을 먼저 봐야 한다
고객 입장에서는 Firewall Rule 하나가 가장 중요해 보인다. 하지만 그 Rule이 Data Plane까지 전달되는 과정을 함께 봐야 한다.
예를 들어 정책 변경 요청은 다음과 같은 과정을 거칠 수 있다.
- 사용자와 Service Identity 인증
- Tenant와 Resource Ownership 확인
- 해당 Action에 대한 권한 확인
- 정책 Validation과 Compilation
- Controller를 통한 정책 배포
- 올바른 Enforcement Point 적용 여부 확인
이 과정 중 하나라도 잘못되면 “방화벽 규칙 오류”보다 훨씬 큰 문제가 될 수 있다.
예를 들어 다른 Tenant의 Resource ID를 지정해 정책을 변경할 수 있다면 이는 단순한 API 취약점이 아니라 Multi-Tenant Isolation Failure다.
6. Tenant가 분리되어 있어도 Controller가 하나라면?
Public Cloud에서 가장 기본적인 보안 경계 중 하나는 Tenant다. Tenant A의 정책이 Tenant B의 워크로드에 적용되어서는 안 된다.
하지만 Tenant끼리 잘 분리되어 있다고 끝나는 것은 아니다.
모든 Tenant의 Security Group 정책을 하나의 Controller가 배포하고 있다면 그 Controller가 새로운 Single Blast Radius가 될 수 있다. 고객별 정책은 분리되어 있어도 그보다 위쪽의 Control Plane 권한이 너무 넓으면 하나의 침해가 여러 Tenant로 확산될 가능성이 생긴다.
그래서 CSP 내부에서는 Tenant Boundary뿐 아니라 Controller, Service Identity, Credential, Database, CI/CD 같은 논리적인 Dependency의 Scope도 함께 확인해야 한다.
7. Blast Radius는 장비 위치가 아니라 권한과 공유 범위로 본다
Security Group은 분산형이니까 Blast Radius가 작고, Cloud Firewall은 중앙형이니까 무조건 크다고 단정하면 안 된다.
개별 Security Group Rule 오설정은 해당 SG가 연결된 Resource 범위에 영향을 줄 수 있다. 하지만 공통 SG나 배포 템플릿을 수천 개 Resource가 공유한다면 영향 범위는 훨씬 커진다.
반대로 Cloud Firewall 정책을 Cell이나 Tenant 단위로 잘게 분리하면 하나의 정책 오류가 전체 CSP로 확산되는 것을 줄일 수 있다.
따라서 Blast Radius는 다음을 함께 봐야 한다.
- 정책을 몇 개의 Tenant가 공유하는가?
- 하나의 Controller가 몇 개 Region과 Cell을 제어하는가?
- 관리자나 Service Credential의 Scope는 어디까지인가?
- 정책을 변경하면 몇 개의 Resource에 동시에 배포되는가?
- 다른 보안 계층을 함께 비활성화할 수 있는 권한이 있는가?
즉 “장비가 어디에 있는가?”보다 하나가 침해되거나 잘못 변경되었을 때 어디까지 영향을 줄 수 있는가?가 더 중요하다.
8. 장애 관점에서도 두 서비스는 다르다
Security Group Control Plane에 문제가 발생했다고 해서 이미 Data Plane에 배포된 정책까지 함께 사라지면 안 된다. 기존 정책은 계속 Enforcement되고 신규 생성이나 변경만 제한되는 구조가 더 안전하다.
Cloud Firewall은 실제 Traffic Path에 들어가므로 Data Plane 장애가 네트워크 장애로 직접 연결될 수 있다. 따라서 HA, Health Check, Traffic Rerouting, Session State, Scale-out 같은 요소가 중요하다.
여기서 Fail Open과 Fail Close 문제도 생긴다. Fail Open은 서비스는 살릴 수 있지만 보안 통제가 사라질 수 있고, Fail Close는 보안 경계는 유지하지만 서비스 자체가 중단될 수 있다.
CSP에서는 보안 기능의 정상 동작뿐 아니라 장애가 발생했을 때 어떤 상태로 실패하는가도 보안 설계의 일부다.
9. 운영 주체도 다르게 나누는 편이 좋다
Security Group은 Application Team이 자신의 서비스 통신 요구사항을 가장 잘 알고 있기 때문에 워크로드 단위 Least Privilege를 구현하기 좋다.
반면 Malware/C2 차단, 공통 IDS/IPS Rule, 조직 차원의 Domain 정책처럼 여러 서비스에 공통으로 적용해야 하는 통제는 중앙 보안조직이 Cloud Firewall에서 관리하는 편이 자연스럽다.
다만 관리 권한을 나눴다고 안심할 수는 없다.
하나의 상위 관리자 계정이 Security Group, Cloud Firewall, Routing, Logging을 모두 바꿀 수 있다면 공격자가 그 계정을 탈취했을 때 여러 방어 계층을 동시에 무너뜨릴 수 있다. Defense in Depth가 실제로 동작하려면 정책뿐 아니라 관리 권한과 Credential도 어느 정도 독립적이어야 한다.
10. 결국 둘 중 하나를 고르는 문제가 아니다
Cloud Firewall과 Security Group은 서로 대체하는 관계라기보다 서로 다른 실패를 막는 보안 계층에 가깝다.
Cloud Firewall에서는 Network Boundary Protection, 공통 보안 정책, IDS/IPS, Threat Inspection 같은 역할을 맡고, Security Group에서는 Workload Protection, Micro-Segmentation, Least Privilege, East-West Access Control을 수행할 수 있다.
| 항목 | Security Group | Cloud Firewall |
|---|---|---|
| 보호 중심 | Workload | Traffic Path / Network Boundary |
| Enforcement 특성 | 분산형에 적합 | 검사 경로 기반 |
| 주요 보안 역할 | Micro-Segmentation, Least Privilege | Central Policy, Threat Inspection |
| Routing 의존성 | 일반적으로 낮음 | 검사 경로 설계가 중요 |
| CSP 보안 핵심 | Policy Distribution, Tenant Isolation | Routing, HA, Inspection, Policy Control |
| Blast Radius 관점 | 공유 SG·템플릿·Controller 범위 | 공유 정책·경로·Controller 범위 |
보안 담당자가 확인해야 할 것
실제 환경을 점검한다면 다음과 같은 질문을 해볼 수 있다.
- Security Group 정책은 실제 어떤 Enforcement Point에서 적용되는가?
- Cloud Firewall을 우회하는 Traffic Path가 존재하는가?
- 정책 변경 요청에서 Tenant와 Resource Ownership을 다시 검증하는가?
- 하나의 Controller가 몇 개 Tenant, Cell, Region을 제어하는가?
- 공통 Credential이나 Service Identity가 여러 영역에 공유되고 있지는 않은가?
- 정책 배포 실패 시 이전 정책은 계속 유지되는가?
- Firewall Data Plane 장애 시 Traffic은 Fail Open인가, Fail Close인가?
- 하나의 관리자 계정이 SG, Firewall, Routing, Logging을 동시에 변경할 수 있는가?
- 정책 오류나 Controller 침해가 발생했을 때 영향 범위를 특정 Cell이나 Region에 제한할 수 있는가?
마치며
사용자 입장에서 Security Group과 Cloud Firewall은 모두 트래픽을 허용하거나 차단하는 기능처럼 보인다.
하지만 CSP 내부에서는 서로 다른 위치에서 서로 다른 실패를 막는다. Security Group은 수많은 Workload 가까이에서 통신 범위를 줄이고, Cloud Firewall은 주요 Traffic Path에서 더 깊은 보안 검사를 수행한다.
그리고 CSP 보안담당자라면 여기에서 한 단계 더 들어가야 한다.
정책 자체뿐 아니라 누가 정책을 변경하는지, 어느 Tenant에 속하는지, 어떤 Controller를 거쳐 배포되는지, 어떤 Credential을 공유하는지, 하나의 Control Plane이 침해되면 어디까지 영향을 미칠 수 있는지를 함께 봐야 한다.
좋은 클라우드 네트워크 보안은 강력한 하나의 방화벽을 만드는 것이 아니라, 하나의 보안 계층이 실패해도 다음 경계가 남아 있도록 만드는 것이다.
참고: 서비스별 세부 기능과 내부 구현은 CSP와 서비스 SKU에 따라 다를 수 있다. 본문의 구조도는 보안 역할과 아키텍처를 설명하기 위한 개념도다.
(작성: 챗지피티, 제미나이)
