✓ 인간이 작성한 분석; AI는 서식 지정 및 교정용으로 사용됨.

에이전트 기반 보안 플랫폼(Agentic security platforms)이 등장하고 있습니다. Bedrock 모델을 호출하고, S3에 케이스 아티팩트(case artifacts)를 기록하며, EFS를 통해 공유 세션 상태를 마운트하고, ALB를 통해 대화형 셸(interactive shells)을 노출하는 ECS 호스팅 조사 에이전트들입니다. 아키텍처는 견고합니다. 하지만 보안 설정 표면(security configuration surface)은 매우 방대합니다. 기존의 벤치마크들은 에이전트가 존재하기 전에 작성되었기 때문에, 대부분의 영역이 기존 벤치마크로 커버되지 않습니다.

저는 ECS 호스팅 에이전트 기반 SOC 플랫폼으로 공개된 배포 아키텍처를 감사(audit)했습니다. 자율 에이전트가 경고를 분류(triage)하고, 사고를 조사하며, 케이스 보고서를 생성하는 AI 사고 대응(incident response) 시스템입니다. 보안을 위해 24개의 구성 속성(configuration properties)이 중요합니다. 저는 각 속성을 통제 카탈로그(control catalog)와 대조하여 확인했습니다.

19개는 이미 커버되어 있었습니다. 5개는 그렇지 않았습니다. 이 5개의 격차(gaps)는 설령 당신이 이 특정 아키텍처를 배포하지 않더라도 이해할 가치가 있는 패턴을 보여줍니다.

아키텍처 (The Architecture)

아키텍처는 네 가지 계층으로 구성되며, 각 계층은 고유한 보안 표면을 가집니다:

아티팩트 저장소(S3)는 조사 결과, 포렌식 아티팩트(forensic artifacts), 증거 파일과 같은 케이스 데이터를 보유합니다. 퍼블릭 액세스 차단(Public access blocks), 액세스 포인트 정책(access point policies), 암호화(encryption), 전송 보안(transport security), 수명 주기 규칙(lifecycle rules), 그리고 버전 관리(versioning)가 모두 적용됩니다. 표준적인 S3 경화(hardening) 작업이지만, 데이터가 조사 증거라는 점은 일반적인 애플리케이션 데이터에는 존재하지 않는 변조 위험(tampering risk)이 있음을 의미합니다.

세션 상태(EFS)는 에이전트 태스크(agent tasks) 간의 공유 파일 시스템 스토리지를 제공합니다. 암호화, IAM 인증(익명 마운트 불가), TLS 강제 적용, 액세스 포인트에서의 POSIX ID, 그리고 마운트 대상(mount targets)에 대한 보안 그룹(security group) 제한이 적용됩니다. EFS 보안은 S3보다 덜 잘 알려져 있습니다. 대부분의 팀은 자신의 마운트 대상이 인터넷으로부터의 NFS 트래픽을 허용하는지 여부에 대해 생각해 본 적이 없습니다.

복합적인 위험(Compound risks)은 작업 ID(Task identity, ECS)에 존재합니다. 각 에이전트는 IAM 역할(Role)을 가진 ECS 태스크(Task)로 실행됩니다. 해당 역할에는 Bedrock 모델 호출, S3 아티팩트 쓰기, 그리고 EFS 마운트 권한이 필요합니다. 문제는 권한이 올바르게 범위가 지정(Scoped)되었는지, 역할이 여러 서비스 간에 공유되는지, 그리고 읽기 전용 소비자(Consumer)가 실수로 쓰기 자격 증명(Write credentials)을 가지고 있는지 여부입니다.

노출 제어(Exposure controls)는 네트워크 표면(Network surface)을 다룹니다: ECS 태스크에 공인 IP(Public IP) 미할당, 대화형 셸(Interactive shell) 엔드포인트에 대한 ALB 인증 강제, 리스너 포트(Listener ports)에 대한 보안 그룹(Security group) 제한, 그리고 exec 세션에 대한 감사 로깅(Audit logging) 등이 포함됩니다.

24개 중 19개는 이미 다뤄짐

기존 클라우드 보안 벤치마크(Cloud security benchmarks)가 다루는 구성 속성들은 충분히 커버되어 있습니다:

S3 퍼블릭 액세스 차단(Public access blocks), 액세스 포인트 정책(Access point policies), 고객 관리 키(Customer-managed keys)를 사용한 암호화, 전송 암호화(Transport encryption), 수명 주기 규칙(Lifecycle rules), 그리고 버전 관리(Versioning) — 이 모든 것들은 전용 제어 항목을 가지고 있습니다. EFS 암호화, IAM 인증, TLS 강제, 그리고 액세스 포인트에서의 POSIX ID(Identity)도 다뤄집니다. ECS 비밀 관리(Secrets management), 공인 IP 할당, 로그 구성, 그리고 exec 감사 로깅(Audit logging) 또한 다뤄집니다. ALB 인증 작업(Authentication actions)과 보안 그룹 제한도 포함됩니다.

이것들은 기본 중의 기본(Table-stakes) 체크 항목들입니다. 시장의 모든 스캐너(Scanner)가 이를 찾아냅니다. 흥미로운 발견은 다뤄지지 않은 나머지 5개 항목에 있습니다.

5가지 격차(Gaps) — 모두 복합적임

격차 1: 작업 역할(Task role)과 실행 역할(Execution role)이 동일한 IAM 역할임. ECS 태스크 정의(Task definitions)에는 두 가지 역할 필드가 있습니다: 작업 역할(Task role, 애플리케이션 코드가 사용하는 것)과 실행 역할(Execution role, ECS가 컨테이너 이미지를 가져오고 로그를 전송하는 데 사용하는 것)입니다. 이들이 동일한 역할일 경우, 애플리케이션 코드는 필요하지 않은 ECR 풀(Pull) 및 CloudWatch 푸시(Push) 권한을 상속받게 됩니다. 두 개의 신뢰 경계(Trust boundaries)가 하나로 붕괴되는 것입니다. 해결책은 단일 속성 비교입니다: taskRoleArn이 executionRoleArn과 동일한가? 간단한 체크이지만, 작업 역할과 실행 역할의 구분은 에이전트 기반 아키텍처(Agentic architectures) 이전부터 존재했던 ECS 특유의 개념이기 때문에 어떤 벤치마크에도 포함되어 있지 않습니다.

Gap 2: 읽기 전용 소비자(Read-only consumer)가 쓰기 자격 증명(Write credentials)을 보유함. SOC 플랫폼에는 아티팩트 저장소(Artifact store)로부터 읽기만 수행해야 하는 서비스들이 있습니다. 예를 들어 리포팅 서비스(Reporting service), 대시보드(Dashboard), 증거 뷰어(Evidence viewer)가 이에 해당합니다. 만약 이들의 작업 역할(Task role)에 s3:PutObject 권한이 있다면, 침해된 읽기 전용 서비스가 조사 아티팩트(Investigation artifacts)를 조작할 수 있습니다. 이 점검을 위해서는 ECS 작업 정의(Task definition, 어떤 역할인가?)와 IAM 정책 분석(해당 역할이 무엇을 할 수 있는가?)을 상관 분석(Correlating)해야 합니다. 이는 단일 리소스 스캐너(Single-resource scanner)가 표현할 수 없는 리소스 간 속성(Cross-resource property)입니다. 수집기(Collector)는 해당 역할의 IAM 정책을 분석하여 ECS 관찰(Observation) 데이터에 has_s3_write: true/false라는 불리언(Boolean) 값을 기록합니다. 평가기(Evaluator)는 이 불리언 값을 확인합니다. 리소스 간의 복잡성은 점검(Check) 단계가 아닌 수집기(Collector) 단계에서 해결됩니다.

Gap 3: Resource: *에 대한 Bedrock 모델 호출(Model invocation). 모든 리소스에 대해 bedrock:InvokeModel 권한을 가진 에이전트 역할(Agent role)은 계정 내의 어떤 모델이든 호출할 수 있습니다. 여기에는 다른 프로젝트의 학습 데이터가 포함되어 있을 수 있는 커스텀 미세 조정(Fine-tuned) 모델도 포함됩니다. 해결책은 리소스를 특정 모델 ARN으로 제한(Scoping)하는 것입니다. 기존의 와일드카드 탐지 제어(Wildcard detection control)가 이를 다루고 있지만, 해당 액션(Action)이 민감한 액션 레지스트리(Sensitive-action registry)에 등록되어 있는 경우에만 작동합니다. 레지스트리에 bedrock:InvokeModel(및 스트리밍 및 대화 변형 액션들)을 추가하는 것이 해결책입니다.

Gap 4: 인터넷 노출과 모델 호출을 연결하는 복합 체인(Compound chain)의 부재. 원자적 제어(Atomic controls)는 정상 작동합니다. "ECS 서비스가 퍼블릭 IP를 보유함"이 탐지되고, "역할이 광범위한 Bedrock 호출 권한을 보유함"이 탐지되며, "역할이 광범위한 S3 쓰기 권한을 보유함"이 탐지됩니다. 각각은 독립적으로 탐지됩니다. 하지만 이들을 "인터넷 접속이 가능한 서비스가 모든 모델을 호출할 수 있고 동시에 모든 버킷에 쓸 수 있음"이라는 하나의 복합 체인으로 연결해주는 장치는 없습니다. 이 복합적인 경로(Compound path)가 바로 폭발 반경(Blast radius)입니다. 개별 탐지 결과(Findings)들은 그 구성 요소일 뿐입니다.

Gap 5: 공유 스토리지(Shared storage)를 통한 아티팩트 변조(Artifact tampering). 한 서비스가 S3에 기록합니다. 다른 서비스는 S3에서 읽습니다. 만약 기록하는 서비스가 침해(Compromised)된다면, 읽는 서비스가 신뢰하는 아티팩트(Artifacts)를 오염(Poison)시킬 수 있습니다. 기존의 어떤 체인 모델도 이 "쓰기(Write) → 공유 저장소(Shared store) → 읽기 전용 소비자(Read-only consumer) 오염" 패턴을 모델링하지 못합니다. 이는 데이터 접근 공격(Data access attack)이 아니라 데이터 무결성 공격(Data integrity attack)입니다. 이 체인은 다음과 같이 연결됩니다: 인터넷에서 접근 가능한 서비스가 쓰기 권한을 가지고, 저장소에는 버전 관리(Versioning)가 없으며(변조된 객체가 조용히 덮어쓰기됨), 하위 소비자(Downstream consumers)는 저장소의 콘텐츠를 신뢰합니다.

5가지 갭(Gap) 전체에 걸친 패턴

모든 갭은 리소스 간의 복합적인 구성(Cross-resource composition)입니다. '작업 역할(Task role)이 실행 역할(Execution role)과 동일함'은 하나의 리소스에 있는 두 필드를 비교하는 것입니다. '쓰기 자격 증명(Write credentials)을 가진 읽기 전용 소비자'는 작업 정의(Task definition)와 IAM 정책(IAM policy)을 상관관계로 연결합니다. 복합 체인(Compound chains)은 3~4개의 리소스를 공격 경로(Attack paths)로 연결합니다.

단일 리소스 스캐너(Single-resource scanners)는 각 리소스를 독립적으로 검사합니다. 각 리소스는 통과합니다. 하지만 복합 경로(Compound path)는 안전하지 않습니다. 스캐너는 '정상(Green)'이라고 보고합니다.

이는 Hugging Face 사고에서 드러난 것과 동일한 구조적 갭입니다. 샌드박스(Sandbox)는 모든 개별 검사를 통과했습니다. 탈출 경로(Escape path)는 각각은 개별적으로 수용 가능한 세 가지 설정의 복합체였습니다. 에이전트 기반 SOC 플랫폼도 동일한 형태를 가집니다. 각 서비스는 올바르게 구성되어 있습니다. 위험은 서비스 간의 상호작용(Interactions) 속에 존재합니다.

이것이 에이전트 기반 아키텍처(Agentic architectures)에 의미하는 바

만약 ECS(또는 Lambda, EKS, 또는 기타 컨테이너 오케스트레이터)에 AI 에이전트를 배포하고 있다면, 구성 표면(Configuration surface)은 개별 리소스가 아닙니다. 그것은 에이전트의 컴퓨팅(Compute), 신원(Identity), 데이터 저장소(Data stores), 그리고 노출 지점(Exposure points)을 연결하는 권한 및 네트워크 경로의 그래프(Graph)입니다.

배포 시 확인해야 할 다섯 가지 질문:

작업 역할(Task role)이 실행 역할(Execution role)과 구별됩니까? 만약 에이전트의 애플리케이션 코드가 필요하지 않은 ECR 및 CloudWatch 권한을 상속받는다면, 침해 시의 폭발 반경(Blast radius)은 의도보다 더 넓어집니다.

모든 서비스가 각자의 역할(Role)을 가지고 있습니까? 역할을 공유한다는 것은 침해된 분류(Triage) 에이전트가 조사(Investigation) 에이전트와 동일한 권한을 가진다는 것을 의미합니다. 서비스별 역할(Per-service roles)은 폭발 반경(Blast radius)을 하나의 기능으로 제한합니다.

모델 호출(Model invocation)이 특정 모델로 범위가 제한되어 있습니까? 어떤 모델이든 호출할 수 있는 에이전트는 모든 미세 조정(Fine-tuned)된 모델의 학습 데이터에 접근할 수 있습니다. 에이전트가 사용하는 모델로 범위를 제한하십시오.

읽기 전용 소비자(Read-only consumer)가 아티팩트 저장소(Artifact store)에 쓸 수 있습니까? 만약 보고(Reporting) 서비스가 조사 증거를 수정할 수 있다면, 모든 사례 보고서의 무결성(Integrity)은 의심스러워집니다. 이 점검은 단순히 작업 정의(Task definition)를 확인하는 것이 아니라, 작업 역할(Task role)과 IAM 정책(IAM policy)을 상관 분석(Correlating)해야 합니다.

에이전트가 인터넷에서 도달 가능하다면, 무엇에 도달할 수 있습니까? 인터넷 노출부터 에이전트의 역할(Role)을 거쳐 Bedrock, S3, EFS에 이르는 복합적인 경로는 폭발 반경(Blast radius)이 됩니다. 각 리소스를 독립적으로 점검하는 것은 이 경로를 놓치게 됩니다.

24개 항목의 체크리스트와 5가지 격차 해소(Gap closures) 방안은 오픈 소스 클라우드 구성 검증 도구인 Stave에 구현되어 있습니다. 리소스 간 에이전트 위험을 탐지하는 복합 체인(Compound chains)은 ECS, IAM, S3, EFS 및 ELB에 걸친 탐지 결과들을 조합해야 하며, 이는 단일 리소스 스캐너가 구조적으로 수행할 수 없는 작업입니다. Apache 2.0.