CSP 보안에서의 Blast Radius

클라우드 환경에서의 Blast Radius는 특정 시스템에 장애나 침해가 발생했을 때 그 영향이 어디까지 확산될 수 있는지를 나타내는 개념으로 사용한다.

보안의 관점에서 좀더 구체적으로 표현하면 다음과 같다.

하나의 계정, 시스템 또는 보안영역이 침해되었을 때 공격자가 추가로 영향을 미칠 수 있는 최대 범위

클라우드를 사용하는 고객 입장에서도 중요한 개념이지만, 여러 고객에게 클라우드 서비스를 제공하는 Cloud Service Provider(이하 CSP) 입장에서는 더욱 중요하다.

고객사의 관리자 계정 하나가 침해되면 일반적으로 해당 고객이 사용하는 클라우드 자원이 영향 범위가 된다.

하지만 CSP의 Control Plane(이하 CP)이나 내부 관리 시스템이 침해되는 경우에는 여러 고객, 여러 서비스, 경우에 따라서는 여러 Region까지 하나의 침해사고에 영향을 받을 수 있기 때문이다.

침해 만큼 중요한 침해 이후의 범위

보안 시스템을 아무리 잘 구축하더라도 침해 가능성을 완전히 제거하는 것은 현실적으로 어렵다.

관리자 계정이 탈취될 수도 있고, 소프트웨어에 취약점이 발생할 수도 있으며, 잘못된 설정이나 배포로 예상하지 못한 문제가 발생할 수도 있다.

그래서 현대적인 보안 아키텍처에서는 단순히 “어떻게 침해를 막을 것인가?” 뿐만 아니라 “하나가 침해되었을 때 어디까지 영향을 받을 것인가?“를 함께 고민한다.

Zero Trust의 Assume Breach 원칙도 같은 방향이다. Microsoft의 보안 가이드에서도 Assume Breach의 구현 요소로 Blast Radius 최소화와 접근 영역의 분리를 명시하고 있으며, NIST의 Zero Trust Architecture 역시 네트워크 위치에 기반한 암묵적인 신뢰를 제거하고 사용자뿐 아니라 서비스 Identity를 기반으로 세분화된 인증과 권한통제를 적용하는 것을 강조한다.

즉 좋은 보안 아키텍처는 침해가 전혀 발생하지 않는 아키텍처라기보다, “침해가 발생하더라도 피해가 일정한 경계를 넘어가지 않는 아키텍처“라고 볼 수 있다.

CP와 Blast Radius

CP는 클라우드 자원을 생성하고 삭제하며, 설정하고 권한을 관리하는 영역이다.

예를 들어 VM 생성 요청은 API와 Scheduler, Host Controller를 거쳐 처리될 수 있다.

고객의 VM에서 취약점이 발생하는 것과 Scheduler나 Host Controller가 침해되는 것은 의미가 크게 다르다.

고객 VM이 침해되면 기본적인 영향 범위는 해당 VM 또는 해당 Tenant다.

반면 CSP의 Scheduler나 Host Controller가 다수의 물리 Host와 고객 자원을 관리하고 있다면 영향 범위가 훨씬 넓어질 수 있다.

따라서 CSP CP를 설계할 때 중요한 것은 단순한 서비스 가용성 만이 아니다.

각 CP Component가 어느 범위의 자원을 제어할 수 있는지 자체가 보안 아키텍처의 중요한 요소가 된다.

Tenant Isolation

Public Cloud의 가장 기본적인 보안 경계 중 하나는 Tenant다.

Tenant A의 사용자는 Tenant B의 자원에 접근할 수 없어야 한다.

예를 들어 다음과 같은 API 요청이 있다고 해보자.

GET /instance/1234

이 때 단순히 사용자가 VM을 조회할 권한이 있는지만 검사하면 안된다.

사용자 인증 → Tenant 확인 → 사용자 권한 확인 → Resource의 Tenant 확인 → Action 허용 여부 확인

처럼 요청 주체와 대상 자원의 Tenant 관계까지 검증해야 한다.

잘못된 Authorization 구현으로 Tenant A가 Tenant B의 Resource ID를 지정해 조회하거나 변경할 수 있다면 단순한 API 취약점이 아니라 CSP 전체의 Multi-Tenant Isolation 문제로 확대된다.

따라서 CSP에서는 Tenant Boundary 자체가 가장 중요한 Blast Radius Boundary 중 하나다.

하지만 Tenant만 분리한다고 끝나는 것은 아니다.

여기에서 한 단계 더 생각해야 되는데, 고객끼리는 잘 분리되어 있다고 하더라도 모든 Tenant를 관리하는 내부 CP Service가 하나라면 해당 서비스가 새로운 Single Blast Radius가 될 수 있다.

하나의 CSP Shared Control Plane이 Tenant A·B·C의 자원 관리에 연결되어 Controller 권한 침해 시 여러 테넌트로 영향이 확산될 수 있는 구조도

공유 Controller의 권한이 여러 테넌트에 미치는 범위.

Compute Controller 하나가 모든 고객의 Compute Resource를 관리한다면 Controller 침해 시 Tenant Isolation보다 위쪽의 권한으로 접근할 가능성이 생긴다.

따라서 CSP 내부에서도 CP를 다시 잘게 나누어야 한다.

Cell-based Architecture

Blast Radius를 줄이기 위한 대표적인 방법 중 하나가 Cell-based Architecture다.

예를 들어 전체 Compute 서비스를 하나의 거대한 CP로 운영하는 대신 여러 개의 독립적인 Cell로 나눈다.

CSP의 Cell 1·2·3이 각각 별도 Controller와 Credential을 가지고, Cell 1에 사고가 발생해도 다른 Cell은 독립적으로 유지되도록 설계한 격리 구조도

제어기와 인증정보를 Cell별로 분리해 영향 범위를 줄인다.

각 Cell은 가능한 독립적인 CP와 자원을 가진다.

Cell 1에 문제가 발생하면

Cell 1 → 영향
Cell 2 → 정상
Cell 3 → 정상

이 되도록 설계하는 것이다.

AWS도 Cell-based Architecture를 Fault Isolation을 위한 구조로 설명하고 있으며, 독립적인 Cell로 분할함으로써 소프트웨어 버그, 잘못된 배포 또는 과부하가 발생하였을 때 영향을 받는 고객을 제한하는 방식을 제시하고 있다. (AWS 문서)

이 개념은 장애 뿐 아니라 보안에서도 동일하게 적용할 수 있다.

Cell 별로

Control Plane
Credential
Database
Service Identity
Network

를 적절히 분할한다면 Cell 하나가 침해되도 다른 Cell로의 확산을 어렵게 할 수 있다.

Region과 Blast Radius

Region을 나눴다고 반드시 Blast Radius가 줄어드는 것은 아니다.

흔히 Region을 분리하면 모든 것이 독립적이라고 생각하기 쉽다. 하지만 그렇지 않을 수 있다.

예를 들어 각 Region의 Data Plane(이하 DP)은 분리되어 있을 수 있지만 이를 관리하는 Global CP가 존재할 수 있다.

Region A·B·C의 Data Plane은 각각 분리되어 있지만 Global Control Plane이 세 리전을 관리하므로 상위 관리영역 침해 시 리전 경계를 넘어 영향이 확대될 수 있는 구조도

공유 관리영역은 리전 경계를 넘어 영향을 줄 수 있다.

이 경우 Region 하나의 문제에는 강할 수 있지만 Global CP가 침해될 경우 세 Region 모두 영향을 받을 수 있다.

따라서 Region의 Blast Radius를 평가할 때 물리적인 범위만 보아서는 안된다.

Credential, IAM, PKI, CI/CD, Control Database 같은 논리적인 Dependency까지 확인해야 한다.

예를 들어 Region별 Compute Controller를 분리했지만 모든 Controller가 하나의 Global Service Account를 사용한다면 Credential 관점의 Blast Radius는 여전히 Global이다.

왼쪽은 하나의 Global Credential이 Region A·B·C에 접근하는 구조이며 오른쪽은 리전별 Key A·B·C가 각각 하나의 리전에만 권한을 갖는 구조를 비교한 도식

리전 분리와 Credential 권한 분리는 별개의 통제다.

보다 안전한 구조는 가능한 범위에서 Region별 Credential의 Scope를 분리하는 것이다.

Credential 하나가 침해되더라도 다른 Region을 제어할 수 없도록 만드는 것이다.

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가 필요하다.

mTLS와 인가 정책 등을 적용해 “어디에서 접속했는가가 아니라 누가 어떤 권한으로 요청했는가”를 확인해야 한다.

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 방식이 중요하다.

예를 들어,

CSP의 변경 사항을 하나의 Canary Cell에 먼저 배포해 검증한 뒤 Selected Cells와 나머지 Cell로 순차 확대하며 단계마다 확인 또는 롤백하는 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를 가지기 때문이다.

필요한 경우가 있을 수 있지만 상시 권한으로 제공할 필요는 없다. 일반적인 운영자는 담당 서비스·리전·Cell·테넌트·자원의 범위에 맞춰 권한을 부여한다.

더 높은 권한은 장애나 긴급 상황에서만 일정 시간 동안 부여하는 것이 안전하다. 즉 최소권한은 단순히 사용하지 않는 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 보안에서 중요한 것은 강력한 하나의 성벽을 만드는 것만이 아니다.
그 성벽이 뚫렸을 때도 다음 경계가 남아 있도록 만드는 것이 더 중요하다.