00 — Docs & Demo
프로젝트 자료 & 데모 영상
핵심 기능이 실제로 동작하는 모습을 편집한 1분 30초 영상입니다. 구조와 구현 근거, 구현 화면, 트러블슈팅 등은 아래 섹션에 있습니다.
프로젝트 시연: 데모 영상
PDF를 불러올 수 없습니다. 아래 버튼으로 다운로드해서 확인해 주세요.
⬇ PDF 다운로드'CNAPP 보안 플랫폼' 프로젝트에서 Bedrock은 두 가지 일을 합니다.
- 위험 판정 Read-only API를 직접 호출해 확인한 뒤 판정합니다.
- 설명 지식베이스에서 찾은 근거로만 답합니다.
스캐너가 찾은 finding(보안 위험)은 정규화와 상관분석, AI 조사를 거쳐 관제 콘솔까지 도달하며, 전 구간이 실제 환경에서 동작합니다.
상세는 04 구현 검증 결과, 화면은 06 구현 화면에 있습니다.
Multi-Cloud
AWS는 워크로드를, Azure는 신원을 맡고 두 클라우드의 보안 상태를 한 화면에서 확인합니다
CNAPP 6 Pillars
CSPM, CIEM, 취약점, KSPM, 데이터 보안 다섯 축을 점검하고, 그 결과를 attack-path로 엮습니다
Agentic AI
Bedrock 멀티에이전트가 Read-only API를 스스로 호출해 가설을 세우고 증거를 모아 판정합니다. 실제 Bedrock 호출로 검증했습니다
Cross-Cloud Path
AWS 워크로드 침해가 Azure 신원 장악으로 번지는 경로를 추적하고 시각화합니다
01 — Overview
프로젝트 개요
개별 도구가 놓치는 공격 경로를 OCSF 정규화와 상관분석으로 찾고, AI 에이전트가 증거를 직접 조사합니다.
AWS 설정과 Azure 신원, 이미지 CVE를 각각 다른 도구가 점검합니다.
문제는 이것들이 이어질 때입니다. 연결되면 신원 탈취 경로가 되지만, 단일 도구는 그 연결을 잡아내지 못합니다.
수백 개 finding 중 무엇이 급한지는 결국 사람이 판단해야 합니다.
여섯 영역의 신호를 OCSF 형식으로 통일해 모으고, 상관 규칙이 중간 위험들을 하나의 공격 경로로 엮습니다.
그 경로 위에서 AI가 Read-only API 9종을 스스로 골라 호출하고, 실제 응답만으로 판정합니다.
조사는 AI가 하고, 실제 변경은 사람이 승인합니다.
2인 협업: 9개 영역 역할 분담 펼쳐 보기
각 영역을 반씩 나누되 서로의 영역까지 이해하며 진행했습니다. 애플리케이션 2종과 CI/CD, 인프라, 조치, 하드닝은 직접 전담했습니다. 그 외 파이프라인은 양쪽이 핵심을 함께 구현했습니다.
02 — Architecture
아키텍처
AWS는 워크로드를, Azure는 신원을 맡고, 두 클라우드에서 모은 finding(보안위험)이 정규화와 상관분석을 거쳐 AI 추론까지 흐릅니다. 타깃 앱과 관제 앱은 서로 직접 통신하지 않고, 모든 데이터는 저장소를 통해서만 오갑니다.
AWS 서비스 아이콘 기준으로 스캐너부터 AI 조사, 크로스클라우드 공격 경로까지 한 장에 담은 전체 구성도입니다. 클릭하면 확대됩니다.
타깃 앱
위험의 원천
EKS에 배포된 의도적 취약 앱
스캐너
발견
계정을 조회 전용으로 스캔 → finding
정규화
통일
OCSF로 표준화 · 중복 병합
attack-path
엮기
상관 규칙으로 공격 경로 생성
엔진 · RAG
조사 · 설명
AI가 증거 수집 · 판정 · 규정 근거 설명
관제 콘솔
표시
posture · findings · 조치 승인
finding 하나가 어디서 만들어져 어디까지 가는지입니다. 두 앱이 서로를 직접 부르지 않아(agentless), 데이터는 저장소(pgvector)를 통해서만 오갑니다.
03 — Core Features
핵심 기능
여섯 영역을 스캐너 7종으로 한 번에 점검하고 그 결과를 에이전틱 AI가 조사하는데, 차별점은 클라우드 경계를 넘는 공격 경로입니다.
CSPM 설정
공개 S3나 열린 SG 같은 설정 미스컨피그
탐지 Prowler, Security Hub, AWS Config(Security Hub 경유)
병합 여러 도구가 잡은 같은 위험은 1건으로 병합합니다(공개 S3 1건 = 4소스)
CIEM 권한
과도한 IRSA나 위험한 앱 권한 같은 권한 과다
탐지 IAM Access Analyzer · Prowler (Entra ID)
Vuln 취약점
이미지와 코드의 CVE. 실제 악용 중인 KEV가 최우선
탐지 Trivy, ECR 스캔, Inspector(Security Hub 경유)
KSPM 쿠버네티스
CIS 벤치마크 기준 특권 파드와 cluster-admin 남용
탐지 kube-bench (CIS) · Trivy (k8s)
DSPM 데이터
공개 버킷에 노출된 회원 정보 같은 민감 데이터
탐지 Macie (S3 PII 분류)
attack-path 경로
위 5개를 엮은 공격 경로
상관 커스텀 상관 엔진이 중간 위험을 하나의 경로로 엮습니다
대표 공격 경로: 크로스클라우드 attack-path
진입
취약 워크로드 침투
KEV CVE 이미지 (EKS)
확장
과도 권한 측면 이동
과도한 IRSA 역할
획득
평문 시크릿 발견
Azure 자격증명 노출
탈취
공개 S3의 PII 유출
회원 민감정보
장악
Entra ID 신원 장악
탈취 자격증명으로 Azure 진입
MEDIUM ×5 = CRITICAL 개별로는 전부 중간 위험입니다. 연결되는 순간 신원 탈취 경로가 됩니다. 경계를 넘는 것은 앱이 아니라 탈취된 자격증명입니다.
에이전틱 엔진: 4단계 능동 조사 루프
챗봇은 답을 만들고, 이 엔진은 근거를 만듭니다. 스캔 결과만 요약하면 그 사이 상태가 바뀌었는지 알 수 없습니다. 그래서 Read-only API를 스스로 호출해 지금 상태를 확인한 뒤 판정하게 했습니다. 가르는 기준은 정해 준 API를 쓰느냐가 아니라, 도구를 스스로 고르느냐입니다.
학습 지식만 쓰는 AI라면
"이 버킷은 공개 설정일 수 있습니다."
학습 지식 기반 추측. 실제로 확인하지 않음
이 엔진은
GetBucketPolicy 호출 → Principal:"*" 확인 → "공개 맞음"
실제 API 응답 = 증거 기반 판정 (CONFIRMED)
00 · 루프 지휘
Orchestrator
4개 에이전트 순차 호출 · 케이스 조립 → RDS 저장 · 단계별 토큰 추적
01 · 비용 게이트
Triage
Bedrock 호출 전 규칙으로 선별: High 이상이거나 공격 경로에 포함된 항목만 통과
02 · 가설 생성
Hypothesis
"이게 진짜면 이런 위험". 검증 가능한 공격 가설을 구조화 출력으로 강제
03 · 능동 조사
Evidence
LLM이 (API, 대상)을 스스로 선택 → 실행 → 응답을 최대 6회까지 되먹이고 근거가 충분하면 스스로 종료합니다
04 · 판정 · 서사
Reasoning
수집 증거로 3값 판정 + confidence → 한국어 서사 · 권고 생성
허용 목록은 스키마 enum으로 한 번, 실행 직전에 다시 한 번 검사해 두 겹으로 강제합니다. 변경 · 쓰기 API는 0종이라 어느 경로로도 호출되지 않습니다. 모델은 Bedrock Claude Haiku(서울 global inference profile)이고, 1회 조사에 약 100원이 듭니다(토큰 사용량 측정).
RAG: 지어내지 않는 설명
finding이 왜 위험한지, 어떻게 고치는지를 LLM이 지어내지 않고 지식 코퍼스에서 벡터 검색으로 찾아낸 근거로만 답하게 했습니다.
입력
finding · 질문
자동 조사 대상 finding 또는 AI 챗 질문
벡터화
Titan Embed v2
텍스트를 1024차원 벡터로 변환
유사도 검색
RDS pgvector
HNSW 인덱스 · 코사인 유사도
근거 선별
Top-k 청크
유사도 상위 청크만 선별
답변 생성
Bedrock Haiku
선별된 근거만 참고해 답변 · 근거 목록을 함께 반환
코퍼스는 보안 통제 15종을 한국어로 설명한 26청크입니다(통제 ID 태깅). 답변 문장은 AI가 쓰지만 근거는 검색이 실제로 찾은 문서입니다. Finding 상세의 '설명' 탭과 AI 챗, 엔진 판정 근거(rag_refs)가 모두 같은 방식으로 동작합니다.
📐 RAG 파이프라인 구성도 펼쳐 보기
- 에이전틱 AI 분석의 조사 권한은 AWS 9종과 Azure MS Graph read scope 3종으로 한정했습니다. 단계마다 다른 모델을 붙일 수 있게 해뒀고, 현재는 전 단계를 Claude Haiku로 돌립니다. Triage 게이트를 통과한 finding만 조사에 넣어 비용을 통제합니다
- 위 대표 공격 경로는 두 클라우드의 finding에 걸쳐 발화하는 크로스클라우드 상관 규칙 R1~R5가 만들어 낸 결과입니다. 체인 길이가 3 이상이면 자동으로 Critical로 자동 상향됩니다
- 변경은 사람이 승인해야 실행됩니다(HITL). 에이전트는 조회만 하고, 실제 변경은 Step Functions 승인 경로를 지납니다. 모든 판정과 조치는 불변 감사로그(S3 Object Lock)에 남습니다
04 — Implementation
구현 검증 결과
각 축을 목업으로 먼저 완성한 뒤 실제 클라우드로 옮겨 검증했습니다. 각 영역 담당은 위 역할 분담 표를 따릅니다.
Bedrock이 실제 AWS 응답만으로 판정에 도달합니다. 조사 전 과정을 실제 호출로 검증했습니다.
- 실제 Bedrock이
s3:GetBucketPolicy를 스스로 골라 호출해 CONFIRMED 판정까지 도달 - 실물이 없는 finding에는 refuted를 내립니다. 시키는 대로 confirmed를 찍지 않는다는 증거입니다
- 판정 근거에도 RAG를 배선해 통제 문서를 인용합니다
안전장치 상세 더 보기
- 허용 목록에 쓰기 API가 0종인 것을 스키마와 실행 시점 두 곳에서 확인했습니다
- 검증용 S3는 공개 상태로 잠깐 세웠다가 판정 직후 destroy했습니다
- 판정은 confirmed, inconclusive, refuted 세 값입니다. 증거 확인 비율을 confidence로 함께 냅니다
- 검색이 조용히 실패하는 것을 막기 위해 엔진과 챗의 임베딩 모델이 어긋나면 CI가 차단합니다
- 조회 전용 조사와 변경 실행을 IAM 수준에서 서로 다른 역할로 분리했습니다
$ engine investigate --finding public-s3
→ tool: s3:GetBucketPolicy · s3:GetPublicAccessBlock (LLM이 스스로 선택, 호출)
→ evidence: S3 응답. PublicAccessBlock 미설정 · 정책상 공개 읽기 허용
verdict: CONFIRMED · 확증률 100% (도구 4회 호출 중 4회 확증)
스캐너 실행부터 조치까지, 전 구간을 실제 AWS와 Azure 계정에서 확인했습니다.
📐 수집 · 정규화 파이프라인 구성도 펼쳐 보기
- 스캐너 7종의 finding이 콘솔까지 도달합니다
- Security Hub와 Inspector, Macie 같은 관리형 서비스도 실제 계정에 연동했습니다
- 승인 기반 조치를 실행해 finding이 remediated로 바뀌고 posture 점수가 올라갔습니다
- GuardDuty는 테스트 도메인 DNS 질의를 4분 만에 C&C High로 탐지하는 것을 확인한 뒤 일부러 분리했습니다. "고치면 사라지는" 설정 finding과 "불변 사건"인 런타임 위협은 데이터 모델이 달라 별도 SOC 모듈로 뺐고, 이 분리 원칙은 테스트로 강제합니다
파이프라인 · 콘솔 상세 더 보기
- 한국 주민등록번호는 관리형 식별자에 없어서 커스텀 정규식으로 직접 정의해 탐지했습니다
- 콘솔에서 승인하면 Step Functions가 S3 암호화 같은 조치를 수행하고, 드리프트는 0이었습니다
- 공개 S3 하나에 네 소스가 붙는 것처럼, 여러 스캐너가 잡은 같은 위험은 dedup 키로 묶어 1건으로 병합합니다. 심각도는 더 심각한 쪽을 남기고 원본 소스는 전부 보존합니다
- 미매핑 체크는 FAIL일 때만 finding으로 만들어 노이즈 1,329행을 억제했습니다. kube-bench 1,023행과 Prowler 306행이 걸러져 콘솔에는 신호만 남습니다
- Inspector relay 크래시를 봉합했습니다. ASFF의 명시적 null 값이 정규화 전체를 죽이던 결함을 직접 재현해 규명하고 고쳤습니다
- 관제 콘솔 9화면이 운영 데이터로 돕니다. 컴플라이언스와 posture가 운영 DB 산출이라 조치하면 통제가 pass로 뒤집힙니다
- AI 챗이 RAG 근거를 인용해 답합니다. 타깃 3서비스는 ArgoCD로 Synced 상태를 유지합니다
여섯 레이어가 전부 Terraform 코드라 destroy 후 다시 apply해도 같은 환경이 나옵니다.
📐 요청 경로 · SSO 인증 경로 구성도 펼쳐 보기
📐 보안 하드닝 3계층 구성도 펼쳐 보기
- 여섯 레이어 374개 리소스를 apply부터 destroy까지 실제로 돌렸고 잔존 리소스는 0입니다
- Entra ID에서 Cognito로 넘어오는 SSO 로그인이 실제로 됩니다. 커스텀 도메인과 ACM 인증서를 붙였습니다
- CloudFront WAF가 XSS 페이로드를 실제로 차단했습니다
- 장기 자격증명은 0입니다. 인증과 CI, 파드 모두 키리스(OIDC, IRSA)로 구성했습니다
복원력 · 하드닝 상세 더 보기
- CI는 OIDC를, 파드는 IRSA를 씁니다. 로그인은 페더레이션입니다
- 오토스케일은 두 층으로, 노드층은 Karpenter가 파드층은 HPA가 맡습니다. PodDisruptionBudget과 topologySpread를 3서비스에 적용해 스팟이 회수돼도 동시에 내려가지 않게 했습니다
- 우리 콘솔에도 같은 하드닝으로 TLS와 JWT 서명 검증, 보안 헤더를 걸었습니다. JWT 검증에서는 위조 토큰으로 권한이 올라가는 취약점을 찾아 수정했습니다
무증상 장애와 비용 폭증. 실제 사고 두 건을 대시보드 계측이 먼저 잡았습니다.
📐 관측 · 알림 구성도 펼쳐 보기
- 무증상 장애를 X-Ray가 먼저 발견했습니다. 5-Lambda 분산 추적에서 2-pass 트리거가 조용히 실패하던 것을
batch_id상관으로 잡아 고쳤습니다. 계측을 붙인 뒤에야 드러난 장애입니다 - 엔진 기동 빈도를 통제하는 장치를 넣었습니다. 원인과 조치는 05 트러블슈팅에 있습니다
- NAT Gateway 대신 NAT Instance를 써서 NAT 비용을 약 90% 줄였습니다
대시보드 · 알림 상세 더 보기
- 종량제 서비스는 검증 세션에만 켰다 끄고, Triage 게이트로 토큰을 소수 케이스에만 씁니다
- Grafana 대시보드 6종을 GitOps 사이드카로 자동 로드해 스팟 수명주기부터 AI 토큰 비용까지 추적합니다. CloudWatch 24위젯은 별도입니다
- Teams 알림을 보안과 비용, 로그인 3채널로 분리했습니다. 로그인 감사와 헬스 카나리, Bedrock 비용 가드레일도 함께 돕니다
- PR 단계에서 Trivy와 Checkov가 Shift-Left 게이트로 위험한 변경을 배포 전에 막습니다
2인 병렬 개발의 정합성을 계약 문서(SSOT)와 CI 머지 게이트로 강제했습니다.
📐 CI/CD 파이프라인 구성도 펼쳐 보기
- JSON Schema 7종과 컨트롤 카탈로그 15종, 목업 시나리오를 먼저 동결한 뒤 구현을 시작했습니다. mock으로 끝까지 만들고 운영 데이터로 교체했습니다. 이때 mock에는 없던 컬럼 누락이 드러나 두 곳을 고쳤습니다
- 정합성은 CI 머지 게이트가 강제하고,
validate.py가 네 가지를 의미 수준에서 검증합니다. 계약을 깨는 변경은 병합 자체가 막힙니다 - 회귀 게이트는 컴포넌트 9종
run_demo와run_e2e(전 구간 연결)가 전부 통과해야 머지를 허용합니다. 상대 영역을 깨지 않기 위한 안전장치입니다
인프라 6층: 레이어별 AWS 서비스 구성 펼쳐 보기
| 그룹 | AWS 서비스 | 용도 |
|---|---|---|
| ① infra/shared: 기반 (제일 먼저, 나머지가 다 참조) | ||
| 🌐 네트워크 | VPC + 서브넷 · 라우팅 · IGW | 전체 사설망 |
| NAT Instance (EC2 t4g.nano) | private → 인터넷 아웃바운드 (저비용 NAT) | |
| VPC Endpoint ×2 (S3, DynamoDB) | NAT 우회 게이트웨이 | |
| Security Group ×2 | NAT SG · RDS SG(VPC 내부 5432만) | |
| ☸️ 컴퓨트 | EKS 클러스터 + 노드그룹 | 쿠버네티스 (앱이 살 곳) |
| 📦 레지스트리 | ECR 리포 ×4 | 컨테이너 이미지 저장소 |
| 🗄️ 데이터 | RDS PostgreSQL (pgvector) | findings · attack-path · RAG 저장 |
| 🔑 IAM · 시크릿 | OIDC Provider(GitHub) · IAM Role/Policy · Secrets Manager | 키리스 CI · Evidence 조회 전용 + Bedrock invoke · RDS 비밀번호 |
| ② infra/karpenter: 노드 오토스케일 | ||
| ☸️ 오토스케일 | Karpenter 컨트롤러 (Helm) + IRSA | 노드 프로비저닝 두뇌 |
| NodePool · EC2NodeClass | spot 우선 + on-demand 폴백 · 유휴 30초 회수(consolidation) | |
| SQS (스팟 중단 큐) | 회수 경고 수신 → drain · 재배치 | |
| ③ infra/target: 취약 워크로드 (의도적 결함) | ||
| 🗄️ 데이터 | S3 버킷 (member-pii) | 회원 PII 저장: 공개 버킷 결함 |
| 🔑 IAM | IAM Role ×2 (IRSA) | member=최소권한 / order=과도권한 결함 |
| 🌐 네트워크 | Security Group ×1 | 0.0.0.0/0 열린 SG 결함 |
| ④ infra/console: 관제 앱 (얼굴) | ||
| 📄 프론트 | S3 + CloudFront + OAC | React 정적 파일 호스팅 |
| 🔐 인증 | Cognito User Pool · Domain · SAML IdP | Entra ID SSO 로그인 |
| 🔀 로드밸런서 | ALB + 리스너 ×2 + Target Group | authenticate-cognito → Lambda |
| ⚡ 백엔드 | Lambda (console-backend) | findings 읽기 API + AI 챗 |
| ⑤ infra/backend: 데이터 · 추론 평면 (파이프라인 몸통) | ||
| ⚡ 컴퓨트 | Lambda ×5 | 수집, 정규화, 상관, 오케스트레이터, 조치 |
| 📬 큐 · 이벤트 | SQS ×2(+DLQ) · EventBridge rule ×3 | finding 큐(실패 격리) · 2-pass 이벤트 체인 |
| 🔄 워크플로우 | Step Functions (remediation) | 사람 승인 기반 조치(HITL) |
| 🗄️ 감사 | S3 버킷 (Object Lock) | 불변 감사 로그 |
| ⑥ infra/monitoring: 운영 관측 (맨 마지막) | ||
| 📊 대시보드 · 알람 | CloudWatch Dashboard + Metric Alarm ×7 | Lambda, SQS, RDS, Bedrock 토큰/비용, 비용 가드레일 |
| 📢 알림 | SNS + Lambda ×3 + Secrets Manager ×3 | Teams 알람 · 일일 비용 · 로그인 알림 (웹훅, 채널 분리) |
| 🌐 관측 노출 | ACM 인증서 + Route 53 검증 레코드 · ExternalDNS · ALB Controller | Grafana를 grafana.cnapp-agentic.cloud로 HTTPS 공개 (DNS 레코드는 ExternalDNS가 자동 생성) |
| 📜 감사배관 · IAM | CloudWatch Logs ×4(CloudTrail 연동, Subscription Filter) · IAM Role ×7 | 감사 로그 배관 · Grafana IRSA(CloudWatch, X-Ray 읽기) 등 관측 최소권한 |
Bedrock은 서버리스라 Terraform 리소스가 없고, bedrock:InvokeModel IAM 권한만 코드로 관리합니다. 콘솔 정적 파일은 Terraform이 S3에 올리고, 타깃 앱 이미지는 CI가 빌드해 ECR로 push합니다. apply 순서는 deploy.ps1이 강제하고 destroy는 그 역순입니다. 엔진 tool-use 검증에 쓴 공개 S3는 6층과 무관한 독립 스택(infra/slice)으로 따로 세웠다가 검증 직후 destroy했습니다.
05 — Troubleshooting
트러블슈팅
갈래가 다른 네 건을 직접 규명하고 해결한 뒤, 각 사례를 증상부터 핵심까지 순서대로 정리했습니다.
batch_size=10인데 배칭 window가 0초 → 1건마다 기동 · suppressed 배치도 발행 · 재유입 미차단(멱등성 부재)xmax=0으로 신규 open만 기동 → 5분당 60회 → 1회severity_id는 EXCLUDED로 덮어써, "나중에 처리된 스캐너"가 등급을 결정LEAST(findings.severity_id, EXCLUDED.severity_id)로 항상 더 심각한 쪽 유지 → 처리 순서 무관 최고 심각도 보장terraform destroy가 노드 SG DependencyViolation으로 반복 실패aws-K8S-*)가 GC되지 못해 노드 SG를 붙잡음deploy.ps1 훅에 "karpenter.sh/nodepool 태그 인스턴스 종료 + available pod ENI 삭제(in-use 제외)" 자동 스윕을 걸어 수동 복구 2회를 자동화로 전환했습니다undefined.join() (mock=전 필드 vs real=선택 컬럼)06 — Live Screens
구현 화면
cnapp-agentic.cloud에서 실제 운영된 화면입니다. 클릭하면 확대되고, ←/→ 키나 스와이프로 넘겨볼 수 있습니다.
관제 콘솔: 운영 화면
운영 · 배포 · CI: SSO / GitOps / 회귀 게이트
관측: 분산 추적 · AI 텔레메트리
07 — Tech Stack
기술 스택
영역별로 사용한 기술이며, 운영 환경에서 쓰는 구성을 최소 비용으로 증명하는 것이 설계 기준이었습니다.
AWS 보안
CloudTrail, Security Hub, Prowler, IAM Access Analyzer, Macie(S3 전용), Config(Security Hub 경유), Inspector(Security Hub 경유), GuardDuty(런타임, 분리 모듈)
Azure 보안
Microsoft Entra ID(신원, CIEM) · MS Graph API(read scope)
에이전틱 AI
Amazon Bedrock(멀티에이전트) · 수동 RAG · pgvector(RDS PostgreSQL)
워크로드 / 배포
EKS, ECR, ArgoCD(GitOps), Karpenter, IRSA
Shift-Left
GitHub Actions(OIDC) · Checkov / OPA · Trivy · kube-bench
수집 / 오케스트레이션
EventBridge, SQS, Lambda, Step Functions, OCSF 정규화
인증
Entra ID(IdP) → Cognito → ALB(authenticate-cognito)
프론트 / IaC
React + TypeScript · S3 + CloudFront · Terraform(6레이어)
관측 / 알림
CloudWatch Dashboard · Grafana(IRSA) · CloudTrail · SNS → Teams