KIMKYUTAE.COM · ©
CSP 보안에서의 Blast Radius #2
( 이전글 : CSP 보안에서의 Blast Radius #1 )
Network Segmentation와 Blast Radius
Blast Radius를 줄인다고 하면 가장 먼저 떠올리는 것이 Network Segmentation이다.
물론 Network Isolation은 중요하다.
- Control Network
- Management Network
- Storage Network
- Customer Network
등을 목적에 따라 분리하면 침해 확산을 제한하는 데 도움이 되지만, 현대적인 클라우드 환경에서는 네트워크만 분리해서는 충분하지 않다.
Control Plane(이하 CP)은 수많은 API와 Microservice로 구성되어 있기 때문이다.
이 구조에서 모든 내부 서비스가 “내부 관리망에서 들어온 요청이니까 신뢰한다.” 라고 동작한다면 Scheduler가 침해된 순간 다른 CP Component까지 접근할 수 있다.
따라서 내부 서비스에도 별도의 Identity가 필요하고
등을 적용해 “어디에서 접속했는가가 아니라 누가 어떤 권한으로 요청했는가”를 확인해야 한다.
NIST SP 800-207A 역시 Cloud-native 환경의 Zero Trust에서 IP나 Subnet 같은 네트워크 위치에 따른 신뢰보다 Application과 Service Identity를 기반으로 한 세분화된 인증·인가를 강조한다. (NIST Cybersecurity Resources)
CI/CD와 Blast Radius
CI/CD는 CSP에서 놓치기 쉬운 영역 중 하나다.
CP를 아무리 강하게 보호하더라도 해당 CP의 Software를 배포하는 CI/CD가 침해될 경우, 공격자는 정상적인 배포 과정을 이용할 수 있다.
만약 하나의 CI/CD Pipeline으로 모든 Region에 동시에 배포한다면 해당 Pipeline 자체가 Global Blast Radius를 가진다.
이 때문에 Production 배포도 한 번에 모든 환경으로 진행하기보다 제한된 영역부터 순차적으로 확대하는 Progressive Deployment 방식이 중요하다.
예를 들어,
와 같은 구조다.
AWS의 Cell Architecture 가이드 역시 Cell 단위 또는 여러 Cell의 Wave 단위로 배포한 뒤 이상이 확인되면 Rollback하여 문제가 노출되는 고객 범위를 줄이는 방식을 설명한다. (AWS 문서)
Microsoft도 Safe Deployment Practice에서 Progressive Exposure를 이용해 잘못된 배포의 Blast Radius를 최소화하는 것을 주요 원칙으로 제시하고 있다. (Microsoft Learn)
보안 취약점만이 Blast Radius의 원인이 아니다. 잘못된 코드와 잘못된 배포 역시 CSP 전체에 보안 영향을 발생시킬 수 있다.
관리자와 Blast Radius
CSP 내부 운영자에게도 같은 원칙이 적용되는데, 다음과 같은 계정은 매우 위험하다.
CSP Administrator
- Region : All
- Service : All
- Tenant : All
- Permission : Admin
사실상 하나의 Identity가 CSP 전체의 Blast Radius를 가지기 때문이다.
필요한 경우가 있을 수 있지만 상시 권한으로 제공할 필요는 없고, 일반적인 운영자는 담당 범위에 따라
정도로 권한을 제한하고 더 높은 권한은 장애나 긴급 상황에서만 일정 시간 동안 부여하는 것이 안전하다. 즉 최소권한은 단순히 사용하지 않는 API를 몇 개 제거하는 문제가 아니다.
CSP 입장에서는 다음 Scope를 모두 고려해야 한다.
- Service
- Region
- Cell
- Tenant
- Resource
- Action
- Time
가능한 범위에서 이 Scope를 작게 만들수록 관리자 Credential이 침해되었을 때의 Blast Radius도 작아진다.
Shared Service와 Blast Radius
CSP에는 여러 서비스가 공동으로 사용하는 시스템이 많다.
예를 들어,
- IAM
- PKI
- DNS
- KMS
- Logging
- Monitoring
- Artifact Repository
- Container Registry
- CI/CD
등이다.
이런 서비스는 중앙 집중화할수록 관리 효율은 좋아지지만 그만큼 Blast Radius가 커질 가능성이 있다. 특히 Identity Provider나 PKI처럼 다른 시스템의 신뢰를 만들어내는 서비스는 일반적인 CP보다 더 높은 수준의 보호가 필요하다.
예를 들어 개별 Service Credential 하나를 탈취하면 해당 Service의 권한을 얻게 되지만, Service Certificate를 발급하는 Root 또는 Intermediate CA가 침해되면 공격자가 새로운 Service Identity 자체를 만들어낼 가능성이 생긴다.
따라서 CSP에서 Blast Radius를 평가할 때는 단순히 시스템의 중요도뿐 아니라 “이 시스템이 다른 시스템에 어떤 신뢰를 제공하고 있는가?” 도 반드시 확인해야 한다.
Blast Radius의 크기
CSP 보안에서는 Blast Radius를 하나의 숫자가 아닌 여러 방향으로 생각할 수 있다.
Tenant Blast Radius
하나의 침해가 몇 개의 고객에게 영향을 줄 수 있는가.
- 1 Tenant
- 10 Tenants
- 1,000 Tenants
- All Tenants
Service Blast Radius
하나의 침해가 몇 종류의 Cloud Service에 영향을 줄 수 있는가.
- Compute Only
- Compute + Network + Storage + IAM
Regional Blast Radius
- 1 Host
- 1 Cell
- 1 AZ
- 1 Region
- Multi Region
- Global
Privilege Blast Radius
공격자가 확보할 수 있는 최대 권한이다.
- Read
- Write
- Delete
- IAM / Policy 변경
- Credential 생성
Data Blast Radius
접근 가능한 고객 데이터의 범위다.
- Single Resource
- Tenant
- Cell
- Region
- Global
따라서 하나의 시스템을 평가하면서 단순히 “Blast Radius가 크다.” 라고 표현하는 것보다 “어느 방향으로 얼마나 큰지” 를 구체적으로 보는 것이 좋겠다.
Blast Radius 줄이기
Blast Radius를 줄이는 방법은 결국 경계를 잘게 나누는 것이다.
- Global → Region
- Region → AZ / Cell
- Service → Component
- Human Identity → Role
- Machine Identity → Workload
- Network → Segment
- Credential → Scope
그리고 각 경계를 넘을 때마다 다시 인증과 권한을 확인한다.
Microsoft의 Segmentation 가이드에서도 Segmentation을 침해된 영역에서 공격자의 확산을 제한하여 Blast Radius를 통제하는 방법으로 설명하며, 이를 네트워크뿐 아니라 Resource Management와 Access Control에도 적용할 수 있다고 설명한다.
중요한 것은 단순히 시스템을 많이 나누는 것이 아니다.
침해가 발생했을 때 그 경계가 실제 보안 경계로 작동하는가가 중요하다.
Network만 다르고 같은 관리자 계정과 같은 Credential을 사용한다면 실제 Blast Radius는 나뉘지 않은 것과 크게 다르지 않을 수 있다.
보안 담당자가 확인해야 할 것
아래 질문을 통해 시스템의 실제 Blast Radius를 어느 정도 확인할 수 있다.
- 이 시스템이 침해되면 최대 몇 개의 Tenant가 영향을 받는가?
- 다른 Region이나 Cell까지 접근할 수 있는가?
- 해당 Service Credential로 다른 CP Service를 호출할 수 있는가?
- 고객 Resource를 조회하는 것뿐 아니라 변경하거나 삭제할 수 있는가?
- 새로운 Credential이나 권한을 생성할 수 있는가?
- IAM, PKI, KMS 등 더 높은 신뢰영역으로 이동할 수 있는가?
- Production 전체에 한 번에 Software를 배포할 수 있는가?
- 하나의 Credential을 여러 Region이나 Service가 공유하고 있지는 않은가?
- 침해가 발생했을 때 해당 영역만 격리하거나 Credential을 폐기할 수 있는가?
결론
CSP는 수많은 서버와 네트워크 장비, CP Service, 운영자와 개발자가 함께 동작하는 거대한 분산 시스템이다. 이 정도 규모의 환경에서 모든 장애와 보안사고를 완전히 예방한다는 것은 현실적인 목표가 아니다.
그래서 CSP 보안에서는 침해 예방과 함께 침해의 확산을 제한하는 구조가 중요하다.
따라서,
- 하나의 Host가 침해되더라도 Cell을 넘어가지 않고,
- 하나의 Cell이 침해되더라도 Region을 넘어가지 않고,
- 하나의 Region이 침해되더라도 다른 Region으로 확산되지 않도록
설계한다.
그리고 하나의 관리자나 Service Credential이 침해되더라도 CSP 전체를 제어할 수 없도록 권한과 신뢰영역을 나눈다.
결국 Blast Radius를 줄인다는 것은 “무엇이든 침해될 수 있다는 것을 전제로, 하나의 실패가 전체의 실패가 되지 않도록 만드는 것”이라고 생각할 수 있다.
CSP 보안에서 중요한 것은 강력한 하나의 성벽을 만드는 것만이 아니다.
그 성벽이 뚫렸을 때도 다음 경계가 남아 있도록 만드는 것이 더 중요하다.
