← 전체 글 공격 경로

AWS에서의 공격 경로 분석과 공격 경로 검증

Pathbreak 팀 작성 · · 8분 읽기

핵심 요약

  • 공격 경로 분석은 개별 발견 항목을 공격자가 진입점에서 목표까지 밟을 수 있는 단계의 순서로 연결합니다. 무엇을 체인으로 엮을 수 있는지에 답합니다.
  • 공격 경로 검증은 각 후보 체인을 AWS가 평가할 권한 부여, 즉 자격 증명 정책, 리소스 정책, 신뢰 정책, 서비스 제어 정책, 권한 경계, 조건 키에 비추어 확인합니다. 그 체인 가운데 어느 것이 실제로 성립하는지에 답합니다.
  • AWS에서는 두 답이 크게 다릅니다. 그래프에서 완성된 것처럼 보이는 체인도 SCP, 경계, 조건 키에 의해 여전히 차단될 수 있으며, 이 모두를 함께 해석해야만 어떤 체인이 살아남는지 알 수 있습니다.
  • 컨트롤 플레인에서의 검증에는 익스플로잇 실행이 필요하지 않습니다. 실제 권한 부여를 읽기 전용으로 해석하면 위험 없이 같은 답을 얻습니다.
  • 우선순위는 검증에 달려 있습니다. Pathbreak 랩 계정에서 4,942개의 후보 경로가 순위 목록으로 줄었고, 두 가지 변경으로 위험의 80퍼센트가 제거되었습니다.

공격 경로 분석은 공격자가 AWS에서 진입점부터 목표까지 이동하는 데 쓸 수 있는 권한, 신뢰 관계, 노출의 체인을 찾아냅니다. 공격 경로 검증은 그 체인 하나하나를 AWS가 호출마다 평가하는 권한 부여와 대조해 확인하고, 성립하는 체인만 남깁니다.

서로 동떨어진 3,000개의 문제 목록 대신 분석은 체인을 만들어 냅니다. 이 퍼블릭 인스턴스가 이 역할을 가지고 있고, 이 역할은 저 역할을 Lambda에 전달할 수 있으며, 저 역할은 관리자라는 식입니다. 대부분의 클라우드 보안 플랫폼이 이제 어떤 형태로든 이를 제공하며, 심각도순으로 정렬한 목록에 비하면 큰 발전입니다.

검증은 분석 다음 단계입니다. AWS에서는 모든 결정에 여러 종류의 정책이 관여하기 때문에 이것은 보기보다 어려운 질문이며, 두 답은 대부분의 팀이 예상하는 것보다 더 크게 갈립니다.

공격 경로 분석이 하는 일

CreateFunction iam:PassRole runs as role 01 Attacker principal 02 New Lambda 03 Passed role 04 Administrator
이 글에서 다루는 체인. iam:PassRole과 lambda:CreateFunction을 함께 가진 주체는 함수를 만들고, 그 함수에 권한 있는 역할을 넘기며, 함수는 그 역할로 실행됩니다. 이 글은 이 체인을 그래프상의 후보에서 증명된 경로까지 따라갑니다.

분석은 인벤토리에서 시작합니다. 주체, 역할, 정책, 신뢰 관계, 컴퓨팅, 스토리지, 그리고 이들 사이의 네트워크 연결입니다. 이를 바탕으로 그래프를 만들고, 관리자 역할, 프로덕션 데이터베이스, 고객 데이터가 담긴 버킷처럼 민감한 대상에서 끝나는 경로를 그래프에서 찾습니다. 각 홉은 알려진 기법입니다. iam:PassRole과 lambda:CreateFunction의 조합은 하나의 홉입니다. 신뢰하는 계정으로의 sts:AssumeRole도 하나의 홉입니다. 퍼블릭 함수 URL은 진입점입니다.

결과물은 후보 경로의 집합입니다. 이들이 후보인 이유는 그래프가 작성된 그대로의 정책 문서로 만들어졌기 때문이며, 자격 증명 정책 하나만으로는 호출이 이루어질 때 AWS가 어떤 결정을 내릴지 알 수 없습니다.

분석이 멈추는 지점

AWS는 모든 API 호출을 여러 문서에 동시에 비추어 평가하며, 그중 어느 하나라도 허용을 거부로 바꿀 수 있습니다. 그래프에 존재하는 경로도 다음 중 어느 것에 의해서든 차단될 수 있습니다.

  • 서비스 제어 정책. 조직 단위에 적용된 SCP는 OU 전체에서 lambda:CreateFunction을 거부할 수 있으며, 그 안의 어떤 자격 증명 정책도 이를 무효화할 수 없습니다.
  • 권한 경계. 출발 주체에 걸린 경계는 자격 증명 정책이 부여할 수 있는 범위의 상한을 정합니다. 경계에 iam:PassRole이 빠져 있으면, 자격 증명 정책이 허용하더라도 전달은 실패합니다.
  • 신뢰 정책. 대상 역할은 해당 홉이 의존하는 서비스나 주체를 신뢰해야 합니다. lambda.amazonaws.com을 신뢰하지 않는 역할은 호출자가 무엇을 가졌든 Lambda에 전달할 수 없습니다.
  • 리소스 정책. 경로 끝에 있는 버킷, 키, 큐, 함수에는 각자의 정책이 있으며, 체인이 도착한 주체를 거부할 수 있습니다.
  • 조건 키. iam:PassedToService, aws:SourceAccount, aws:PrincipalOrgID, 그리고 sts:ExternalId 검사는 모두 작업 목록에서는 넓어 보이는 권한 부여를 좁힙니다.
  • 명시적 거부. 평가 과정 어디에든 있는 거부 문은 모든 허용보다 우선하며, 그래프가 읽은 정책과는 다른 정책에 들어 있는 경우가 많습니다.

이 문서 중 하나를 읽는 것은 쉽습니다. 어려운 일은 모든 체인의 모든 단계에 대해 이 문서들을 AWS와 같은 순서로 한꺼번에 해석하는 것이며, 바로 이 단계가 후보 경로와 증명된 경로를 가릅니다. 이 단계를 건너뛰면 목록은 길어지고, 그중 상당 부분은 첫 호출에서 실패할 것입니다.

AWS에서 클라우드 공격 경로를 검증하는 방법

흔한 체인을 하나 살펴봅시다. ci-deploy라는 CI 역할이 data-pipeline이라는 역할에 대한 iam:PassRole과 함께 lambda:CreateFunction, lambda:InvokeFunction을 가지고 있습니다. data-pipeline 역할에는 AdministratorAccess가 있습니다. 그래프에서 이것은 CI 역할에서 관리자까지 가는 두 홉짜리 경로입니다. data-pipeline을 연결한 함수를 만들고 호출하면, 함수 코드가 관리자로 실행됩니다.

분석은 이 경로를 도달 가능으로 표시합니다. 그러면 검증이 한 번에 하나씩 확인해 나갑니다.

  1. ci-deploy의 자격 증명 정책이 data-pipeline의 ARN, 또는 이를 포함하는 와일드카드에 대해 iam:PassRole을 허용하는가? 예, arn:aws:iam::*:role/data-*에 대해 허용합니다.
  2. 전달이 iam:PassedToService로 좁혀져 있는가? 조건이 없으므로 어떤 서비스든 받아들여집니다.
  3. data-pipeline의 신뢰 정책이 lambda.amazonaws.com을 신뢰하는가? 예, Lambda 기반 파이프라인용으로 만들어졌습니다.
  4. 계정이 속한 OU의 SCP가 lambda:CreateFunction이나 iam:PassRole을 거부하는가? OU에 SCP가 있지만 둘 다 거부하지 않습니다.
  5. ci-deploy의 권한 경계가 두 작업 중 하나를 제외하는가? 이 역할에는 경계가 없습니다.
  6. 함수 실행이 중요한 무언가에 도달하는가? data-pipeline은 관리자이므로 답은 계정 안의 모든 것이며, 두 개의 교차 계정 신뢰를 통해 다른 두 계정까지 포함됩니다.

모든 확인을 통과했으므로 경로는 증명되었습니다. 함수는 하나도 만들어지지 않았고 아무것도 호출되지 않았습니다. 각 단계는 AWS가 해석할 것과 같은 문서를 같은 순서로 해석했고, 같은 결정을 돌려주었습니다. 컨트롤 플레인에서 검증이 뜻하는 바가 바로 이것입니다. 익스플로잇이 권한이므로, 증명은 권한 부여 결과입니다.

해결책은 두 번째 단계에서 나옵니다. 가장 좁은 변경은 전달 권한에 iam:PassedToService를 추가해 의도한 서비스만 역할을 받을 수 있게 하거나, 와일드카드 ARN을 CI에 필요한 단일 역할로 바꾸는 것입니다. 변경 후 같은 여섯 가지 확인을 다시 실행하면 두 번째 단계가 실패합니다. 경로는 사라지고, 그 확인 결과가 발견 항목 옆에 기록됩니다. 이 체인에 대한 맵 항목에 CloudTrail 이벤트와 전체 설명이 있습니다.

공격 경로 검증을 프로덕션에서 실행해도 안전한가

읽기 전용 검증이라면 안전합니다. Pathbreak는 고객이 직접 만들고 언제든 취소할 수 있는 최소 권한의 읽기 전용 IAM 역할로 연결합니다. Pathbreak가 하는 모든 호출은 읽기(Get, List, Describe)이며, 각 단계의 권한 부여는 그 호출이 반환하는 정책 문서로 해석합니다. 함수를 만들지 않고, 경로상의 역할을 맡지 않으며, 리소스를 변경하지 않으므로 프로덕션 워크로드는 그대로 계속 실행됩니다.

역할 세션과 읽기 호출은 CloudTrail에 Pathbreak 역할의 관리 이벤트로 기록되므로 활동을 쉽게 감사할 수 있습니다. Pathbreak는 구성을 읽으며, 여기에는 인스턴스 사용자 데이터, 함수 환경 변수, 스택 출력처럼 자격 증명이 흔히 노출되는 위치도 포함됩니다. 객체 스토리지나 데이터베이스의 내용은 읽지 않습니다.

읽기 전용 검증은 각 단계마다 하나의 질문에 답합니다. AWS가 이 주체의 이 호출을 승인할 것인가 하는 질문입니다. 애플리케이션 코드, 실행 중인 호스트에 대한 익스플로잇, 탐지와 대응이 공격자를 잡아낼 수 있는지는 테스트하지 않습니다. 이런 부분은 수동 AWS 보안 평가가 다루며, Pathbreak는 그와 함께 사용할 수 있습니다. 환경에서 공격 단계를 실행해 검증하는 도구도 있으며, 이 비교 글에서 각 접근 방식이 맞는 경우를 설명합니다.

이 차이가 무엇을 먼저 고칠지 결정하는 이유

영향도로 경로의 순위를 매기는 것은 경로가 실제일 때만 의미가 있습니다. 증명된 체인과 이미 SCP가 차단한 체인이 섞인 목록은 팀을 아무것도 바꾸지 못하는 작업으로 이끕니다. Pathbreak 랩 계정에서 분석은 4,942개의 후보 경로를 만들었습니다. 검증과 영향 범위 기준 순위 매기기를 거친 뒤, 하나의 역할에 대한 단 하나의 Deny가 남은 4,087개 경로 중 3,893개를 제거했고, 두 가지 변경으로 계정 위험의 80퍼센트가 제거되었습니다. 이런 순서는 각 경로를 실제 권한 부여에 비추어 해석한 뒤에야 보입니다.

Pathbreak의 방식

Pathbreak는 그래프를 만들고, 이를 추론해 후보 체인을 만든 다음, AWS가 평가할 권한 부여, 즉 자격 증명 및 리소스 정책, 신뢰 정책, SCP, 경계, 조건을 해석해 각 체인을 처음부터 끝까지 검증합니다. 접근은 읽기 전용이며 아무것도 실행되지 않습니다. 검증된 각 경로는 도달하는 대상에 따라 순위가 매겨지고, 그 경로를 차단하는 구체적인 변경이 함께 제공됩니다. 변경이 배포되면 경로를 다시 평가해 결과를 기록하므로, 해결은 증거로 확인됩니다.

Pathbreak 공격 경로 화면: 스테이징 역할이 CloudFormation 스택을 읽고, 그 템플릿에는 관리자 사용자의 자격 증명이 노출되어 있으며, 선택한 엣지의 위험 등급과 증거가 함께 표시됨
Pathbreak에서 검증된 경로. PathbreakLabStaging 역할은 관리자 사용자의 장기 키가 템플릿에 포함된 CloudFormation 스택을 읽을 수 있습니다. 선택한 엣지에는 기법, 증거(관찰된 자격 증명), 그리고 경로가 그렇게 평가된 이유가 표시됩니다.

자주 묻는 질문

공격 경로 분석이란 무엇인가요?

공격 경로 분석은 개별 보안 발견 항목을 공격자가 진입점에서 목표까지 밟을 수 있는 단계의 순서로 연결하는 것으로, 보통 자격 증명, 권한, 리소스의 그래프를 만들고 민감한 자산으로 가는 경로를 그래프에서 찾는 방식으로 이루어집니다. Pathbreak는 AWS에 대해 이 그래프를 만든 뒤, 찾아낸 각 경로를 검증합니다.

공격 경로 검증이란 무엇인가요?

공격 경로 검증은 각 후보 경로를 클라우드 공급자가 모든 단계에서 평가할 권한 부여에 비추어 확인합니다. AWS에서는 자격 증명 정책, 리소스 정책, 신뢰 정책, 서비스 제어 정책, 권한 경계, 조건 키를 함께 해석하고 경로가 성립하는지 확인하는 것을 뜻합니다. Pathbreak는 이런 방식으로 AWS 공격 경로를 읽기 전용으로 검증하고, 모든 단계의 결과를 기록합니다.

검증하려면 AWS 계정에서 익스플로잇을 실행해야 하나요?

아니요. AWS 컨트롤 플레인에서 공격자의 이동은 API 호출이며, 각 호출은 정책 문서에 의해 허용되거나 거부됩니다. 이 문서들을 읽기 전용으로 해석하면 AWS와 같은 결정을 얻으므로, 아무것도 만들거나 호출하거나 변경하지 않고 경로를 증명할 수 있습니다. 이것이 Pathbreak가 AWS에서 공격 경로를 검증하는 방식입니다.

CSPM으로 공격 경로 검증을 할 수 있나요?

CSPM과 CNAPP 도구는 구성 그래프 위에서 공격 경로 분석을 제공합니다. 여기서 말하는 검증은 각 단계마다 AWS 권한 부여의 모든 계층을 평가하고 이후 해결을 확인하는 것을 뜻합니다. Pathbreak는 이를 수행하며, CSPM과 함께 실행하거나 독립형 스캐너를 대체할 수 있습니다.

AWS에서 클라우드 공격 경로는 어떻게 검증하나요?

주체, 역할, 신뢰 관계, 리소스로 그래프를 만들고 그 그래프에서 후보 체인을 생성합니다. 체인의 각 단계마다 자격 증명 기반 정책, 리소스 기반 정책, 신뢰 정책, 서비스 제어 정책, 권한 경계, 조건 키를 AWS가 평가하는 순서대로 함께 해석하고, 모든 단계가 허용되는 체인만 남깁니다. 수정 사항을 적용한 뒤에는 같은 검사를 다시 실행해 경로가 사라졌는지 확인합니다. Pathbreak는 AWS에서 이 단계들을 자동화합니다.

Pathbreak가 공격 경로를 검증할 때 CloudTrail에는 무엇이 기록되나요?

고객이 만든 읽기 전용 IAM 역할로 각 세션을 시작하는 sts:AssumeRole 호출과 그 뒤의 읽기 호출입니다. Pathbreak의 Get, List, Describe 호출은 해당 역할의 관리 이벤트로 CloudTrail에 기록됩니다. 경로상에서 만들거나 호출하거나 변경하는 것이 없으므로 검증 과정에서 쓰기 이벤트는 남지 않습니다.

읽기 전용 공격 경로 검증이 다루지 않는 것은 무엇인가요?

읽기 전용 검증은 AWS가 경로의 각 단계를 승인할지에 답합니다. 애플리케이션 코드, 실행 중인 호스트에 대한 익스플로잇, 탐지와 대응이 공격자를 잡아낼 수 있는지는 테스트하지 않습니다. 이런 부분은 수동 AWS 보안 평가가 다루며, Pathbreak는 그와 함께 사용할 수 있습니다.

관련 글

여러분의 AWS 계정에서 어떤 공격 경로가 증명되었는지, 그리고 각 경로를 차단하는 변경을 확인하세요.

데모 신청 데모 보기