CSP 보안에서의 Blast Radius #1

클라우드 환경에서의 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 서비스를 단순화하면 다음과 같은 구조가 될 수 있다.

고객의 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가 될 수 있다.

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

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

Cell-based Architecture

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

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

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

Cell 1에 문제가 발생하면

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

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

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

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

Cell 별로