클라우드 보안 세미나에서 본 다섯 가지 사례: NACL, Bedrock 가드레일, IAM, 와일드카드, PassRole

클라우드 보안 세미나에서 들은 발표를 주제별로 정리했습니다. 발표자분들의 내용을 제가 이해한 대로 적은 노트입니다.

1. Transit Gateway를 붙였더니 NACL이 무력화된 이유

Transit Gateway(TGW) 는 여러 VPC를 한곳에서 연결해 주는 리전 단위 가상 라우터입니다. VPC끼리 일일이 피어링하던 복잡한 구조를 단순하게 만들어 줍니다.

구성 요소	하는 일
attachment	VPC, VPN 같은 네트워크를 TGW에 연결
association	각 attachment를 특정 라우팅 테이블에 매핑
propagation	라우팅 정보를 라우팅 테이블에 전달

NACL은 서브넷 단위의 접근 통제로, 인바운드·아웃바운드 규칙을 따로 정해야 합니다.

문제는 TGW가 VPC 서브넷 안에 네트워크 인터페이스를 배포할 때, 트래픽이 그 가용 영역의 모든 서브넷에 닿을 수 있다는 점이었습니다. 특정 서브넷에만 연결된다고 생각하고 NACL을 걸었다면, 의도와 다르게 통제가 빠지게 됩니다.

대응 방법으로 소개된 것은 이렇습니다.

TGW attachment마다 전용 서브넷을 쓴다
TGW 서브넷의 NACL은 모두 허용으로 두고, 실제 통제는 워크로드 서브넷에 건다
TGW와 연결된 서브넷에는 하나의 공통 NACL을 적용한다

2. Bedrock 가드레일 우회: 프롬프트 포맷팅

Bedrock은 AWS의 생성형 AI 관리형 서비스이고, Knowledge Base는 외부 문서를 검색해 답변에 쓰는 완전 관리형 RAG입니다. 가드레일은 민감 정보(PII) 필터, 맥락 근거 검사 같은 출력 필터입니다.

발표의 핵심은 프롬프트 포맷팅이었습니다. 보안 필터가 인식하도록 설계되지 않은 비표준 형식으로 출력하게 지시해 필터를 피하는 난독화 기법입니다.

	프롬프트 인젝션	프롬프트 포맷팅
공격 대상	LLM 모델 자체	보안 가드레일
방식	시스템 지시와 사용자 입력을 혼동시킴	출력 형식을 바꿔 필터 패턴을 피함

가드레일이 없으면 RAG 환경의 LLM은 문서를 "그대로 요약해 주는 비서"로 동작해서, 문서에 있는 민감 정보도 평문으로 내보냅니다.
PII 필터는 정해진 패턴을 보고 막기 때문에, 글자 사이에 구분자를 넣는 식의 형식 변화로 피할 수 있었습니다.
맥락 필터까지 켜면 막히지만, 그럴듯한 이유(가짜 맥락)를 함께 주면 다시 통과하는 경우가 있었습니다.

대응 방안은 세 가지로 정리됐습니다.

원천 데이터 관리: 가드레일은 언제든 우회될 수 있으니, 애초에 지식 베이스에 민감 정보를 넣지 않는다
보안 프롬프팅: 답변 생성 프롬프트와 검색 쿼리를 만드는 오케스트레이션 프롬프트에 보안 지시를 넣는다
모니터링: CloudWatch로 모델·가드레일 호출을 지켜본다

3. IAM 정책 자동 분석 도구의 한계

발표에서는 클라우드 사고의 대부분이 침투보다 피싱, 권한 오용, 설정 오류 같은 사람의 실수에서 시작된다고 했습니다. IAM 정책의 네 요소(principal, action, resource, condition) 사이의 논리 오류가 취약점이 됩니다.

Sonrai Security의 Cloud Privilege Inspector로 CloudGoat 시나리오(Lambda 권한 상승, IAM 권한 상승)를 풀어 보며 도구의 역할과 사람의 역할을 나눴습니다.

도구가 할 일	사람이 할 일
대규모 정책의 1차 검토	도구에 대한 정확한 이해
와일드카드(`*`)와 위험 패턴 식별	도구가 "안전"하다고 본 권한의 우회 가능성 검토
단순 실수 전수 조사	신중한 IAM 설계

결론은 최소 권한, 수명 주기 관리, 격리였습니다.

4. API Gateway와 Lambda의 와일드카드 함정

서버리스는 서버를 클라우드 사업자가 대신 관리하고, 개발자는 핵심 로직만 작성하는 방식입니다. 대신 준비 시간, 세부 설정 제약, 실행 시간·메모리 제한, 대규모 상시 서비스에서의 비용 역전 같은 단점이 있습니다.

Lambda: 이벤트가 올 때만 코드 단위로 실행되는 FaaS. 요청마다 독립 실행되어 격리와 확장에 유리
API Gateway: API를 만들고 관리하는 서버리스 리버스 프록시. Lambda authorizer로 커스텀 인증 로직을 붙일 수 있음

문제는 권한을 줄 때 쓰는 와일드카드였습니다. IAM 정책은 정규 표현식을 지원하지 않아서, *로 범위를 넓게 잡으면 의도하지 않은 리소스까지 허용될 수 있습니다.

5. Managed Airflow(MWAA)의 권한 상승

MWAA: 대규모 데이터 처리를 조율하는 Apache Airflow의 AWS 관리형 버전. 처리 단위(DAG)의 task가 다른 AWS 서비스를 직접 호출합니다.
AWS Glue: 데이터 추출·변환·적재(ETL)를 하는 관리형 서비스
PassRole: IAM 역할을 다른 서비스에 넘겨주는 권한. 받을 수 있는 대상은 역할의 신뢰 정책이 정합니다.
횡적 이동(Lateral movement): 처음 침투한 공격자가 내부의 다른 자산으로 옮겨 가는 것

발표의 전제는 "Airflow 일반 사용자 권한(일부 DAG 실행·조회)을 가진 내부 침투자"였습니다. DAG 로그에 노출된 자격 증명과, MWAA가 가진 PassRole을 통해 Glue 작업에 더 높은 권한의 역할을 붙이는 흐름으로 권한이 커지는 시나리오였습니다. 관리형 서비스는 구조상 높은 권한을 가질 수밖에 없어서 생기는 딜레마라는 점이 핵심이었습니다.

예방법은 이렇게 정리됐습니다.

위임되는 IAM 역할에 최소 권한 적용
위임 권한(PassRole)을 가진 객체에 대한 감사 강화
관리형 서비스는 다른 것보다 더 구체적이고 정교하게 권한을 설계

정리

다섯 사례 모두 기술 자체의 결함이 아니라 "이 설정이면 이 범위까지만 영향이 간다"는 가정이 틀린 지점에서 문제가 생겼습니다. NACL이 걸릴 거라는 가정, 필터가 막아 줄 거라는 가정, *가 생각한 범위만 잡을 거라는 가정, 관리형 서비스의 권한이 거기서 멈출 거라는 가정이었습니다.