개별 검사는 전부 통과인데 대시보드가 초록인 공격 경로, Stave가 잡아내요

개별 검사는 전부 통과인데 대시보드가 초록인 공격 경로, Stave가 잡아내요

AI 뉴스 썸네일

AWS 보안 검사를 리소스 단위로 돌리는 도구는 많지만, 각 리소스가 모두 통과해도 리소스 사이를 가로지르는 공격 경로는 그대로 남아요. 오픈소스 도구 Stave는 AWS 설정을 통째로 로컬 스냅샷으로 떠서, 권한과 연결 관계까지 포함한 복합 위험을 검증해요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
도구	AWS 설정 스냅샷을 오프라인에서 검증하는 오픈소스 Stave	개별 검사엔 잡히지 않는 복합 공격 경로를 찾아요
방식	읽기 전용 권한으로 한 번 수집, 이후엔 자격 증명 없이 분석	같은 입력에서 같은 결과가 나오는 재현 가능한 검증이에요
AI	Bedrock·SageMaker 권한 경로 검사와 OWASP NHI Top 10 매핑	AI 에이전트가 만드는 새로운 권한 경로를 점검할 수 있어요

1. 문제는 리소스가 아니라 리소스 사이의 경로예요

Stave가 노리는 문제를 개발자 문서의 대표 사례로 설명해요. Bedrock 에이전트가 폭넓은 Lambda 호출 권한을 갖고, 가드레일이 없고, 그 Lambda 도구가 민감 정보 태그가 붙은 S3 버킷까지 접근하는 구성을 생각해 볼 수 있어요. 1

이 구성에서 컴포넌트 단위 검사는 전부 통과해요. 암호화는 켜져 있고, VPC 설정도 맞고, 모델 허용 목록도 지켜졌고, 버킷의 공개 접근도 차단돼 있어요. 대시보드는 초록이에요. 그런데 이 설정들이 모이면 "에이전트 → Lambda → 민감 S3 데이터, 감사 기록 없음"이라는 하나의 공격 시나리오가 완성돼요. 1

S3의 암호화와 공개 접근 차단이 정상이어도, Bedrock 에이전트에서 Lambda를 거쳐 민감한 S3 데이터로 이어지는 경로에 제약이나 감사 기록이 빠져 있을 수 있다는 지적도 같은 맥락이에요. 2

여기에 대상이 사라졌는데 남아 있는 참조도 별도 검사 대상이에요. 삭제된 역할을 가리키는 IAM 설정, 사라진 Lambda를 호출하는 에이전트, 없어진 S3 버킷을 가리키는 CNAME처럼, 침해 사고 재구성이나 버킷 이름 탈취 점검에서 실제로 걸리는 패턴이에요. 2

2. 스냅샷을 분석하는 이유

Stave는 AWS에 직접 접속해 검사하지 않아요. obs.v0.1 형식으로 저장한 로컬 JSON 스냅샷을 분석해요. 수집할 때 읽기 전용 AWS 권한이 필요하지만, 이후 분석은 자격 증명 없이 오프라인에서 반복할 수 있어요. 2

기본 수집 스크립트는 AWS CLI와 jq로 Get, List, Describe 같은 읽기 호출만 써요. Steampipe나 다른 도구로 만든 데이터도 정해진 형식에 맞춰 쓸 수 있어요. 1

이 구조가 주는 이점은 세 가지예요.

728x90

• 보안 데이터가 로컬에 머물러요. 평가 과정에서 AWS API를 호출하지 않아요. 1
• 한 대의 머신에서 수집하고 다른 머신에서 평가할 수 있고, 시점별 스냅샷을 비교할 수도 있어요. 1
• 지켜야 할 보안 조건을 규칙으로 정의하고 스냅샷이 이를 만족하는지 검사하기 때문에, 같은 입력에서 같은 결과가 재현돼요. 2

스캐너가 알려진 나쁜 패턴을 찾는 도구라면, Stave는 스스로를 검증자(verifier)라고 소개해요. 결과가 휴리스틱이 아니라 규칙 만족 여부로 나오는 점이 차이예요. 1

3. 설치부터 평가까지

Go 기반 프로젝트라 설치는 한 줄이에요.

``` go install github.com/sufield/stave/cmd/stave@latest ```

평가 흐름은 세 단계로 정리돼요. 1

1. `bash scripts/aws-snapshot.sh ./my-snapshot` — 읽기 전용 AWS CLI 호출로 원본 JSON을 모으고 obs.v0.1 관측값으로 변환해요.
2. `stave apply --observations ./my-snapshot/observations/` — 스냅샷을 규칙 카탈로그에 대입해 평가해요.
3. 결과를 읽고 심각도 기준으로 걸러진 항목을 확인해요.

AWS 계정 없이 실행할 수 있는 데모(`bash examples/demo-ai-security/run.sh`)도 제공돼요. 계정이 없어도 도구의 검사 방식을 먼저 확인할 수 있어요. 2

기본 검사 규칙은 S3, IAM, VPC, EC2, RDS, Lambda, EKS, CloudTrail에 더해 Bedrock과 SageMaker까지 포함해요. 조직에 필요한 규칙과 평가 템플릿을 직접 추가하거나 수정할 수도 있어요. 2

4. 평가 템플릿과 AI 권한 경로

Stave는 규칙을 하나씩 조립하는 대신, 용도별 묶음 템플릿을 제공해요. 1

• 심각한 문제 우선 점검(기본값)
• 전체 감사
• 인수 실사
• 침해 사고 재구성
• S3 버킷 이름 탈취 위험 점검 2

AI 관련 검사는 OWASP의 비인간 정체성(NHI) Top 10에 매핑돼 있어요. AI 에이전트에 부여한 권한이 만드는 경로를 기존 보안 체크리스트 언어로 풀어볼 수 있다는 점이 특징이에요. 1

실무에서 쓸 때 볼 점

도구 문서도 한계를 명확히 적어요. 기존 보안 스캐너를 대체하는 도구가 아니라 보완하는 도구이고, 검사 범위는 수집한 설정과 지원하는 규칙에 한정돼요. 2

실무에 넣기 전에 확인할 항목을 정리하면 아래와 같아요.

• 수집 시점: 스냅샷 방식이라 검사 결과는 수집한 시점의 설정 기준이에요. 수집 주기를 정해두는 게 좋아요.
• 규칙 커버리지: `stave transform --coverage`로 지원 범위를 먼저 확인해요. 사용 중인 서비스가 빠져 있으면 직접 규칙을 추가해야 해요.
• 기존 도구와 병행: CloudTrail 감사 시점과 스냅샷 수집 시점을 맞추면 침해 재구성 템플릿을 쓸 때 도움이 돼요.

왜 중요한가요

AI 에이전트가 인프라 안에서 권한을 갖고 움직이는 일이 많아지면서, 보안 허점도 리소스 하나의 잘못된 설정이 아니라 여러 설정의 조합으로 생겨요. 각 리소스 검사가 모두 초록인데 접근 경로는 뚫려 있는 상황은 기존 CSPM 도구로 잡기 어려웠어요. Stave는 이 조합을 하나의 이야기로 재구성해 주는 오픈소스 대안을 보여줘요. 1

참고 자료

1. Stave - AWS 설정 사이에 숨어 있는 공격 경로를 찾는 보안 검증 도구 — GeekNews
2. sufield/stave: Open-source cloud configuration verifier — GitHub