AI 보안과 거버넌스
대상: 클라우드·보안 엔지니어
AI 보안과 거버넌스
보안 위협 지형 · AWS 보안 아키텍처 · Guardrails · 에이전트 보안 · 거버넌스
모델이 아니라 시스템을 지킨다
클라우드·보안 엔지니어를 위한 AI 보안 아키텍처 설계
보안 위협 지형
통제 재설계 4축 · LLM01→ASI01 증폭 · OWASP 브리지
보안 위협 지형
OWASP 위협 카탈로그를 AWS 통제 설계로 번역 — 4축 재설계와 LLM01 → ASI01 증폭 경로
위협 카탈로그에서 통제 설계로
무엇이 위험한지는 OWASP LLM·Agentic 두 모듈이 답했습니다 — 이 모듈은 그 위협들을 AWS에서 어떻게 막을지 설계합니다.
- 통제 재설계 4축 — 위협 전환이 요구하는 방어 재배치
- LLM01 → ASI01 — 인젝션이 행동 피해로 증폭되는 경로
- 이후 파트 — 인프라(P2) · Guardrails 조합(P3) · 행동 통제(P4) · 거버넌스(P5)
이 파트는 두 OWASP 카탈로그의 요약이자 다리입니다 — 위협 상세는 해당 모듈에, 여기서는 통제 설계에 집중합니다.
보안 통제 재설계 4축
OWASP가 보여준 위협 전환을 통제 설계 관점으로 번역
위협 분류는 OWASP LLM·Agentic 모듈에서 다뤘습니다 — 이 4축이 이후 파트(인프라·Guardrails·행동 통제·거버넌스)의 설계 기준이 됩니다.
LLM01 → ASI01 — 위협의 증폭
같은 주입 공격이 에이전트에서 행동 피해로 증폭되는 경로
LLM01 Prompt Injection
- 공격 대상 — 모델의 출력
- 피해 — 잘못된 텍스트·정보 유출
- 1차 방어 — Guardrails 입력 검사 (PART 3)
ASI01 Agent Goal Hijack
- 공격 대상 — 에이전트의 목표
- 피해 — 도구 실행·시스템 변경으로 확대
- 1차 방어 — Cedar 도구 통제 + HITL (PART 4)
같은 인젝션도 에이전트에서는 행동으로 증폭됩니다 — Direct/Indirect 시나리오 상세는 OWASP LLM 모듈에서 다루고, 여기서는 방어 지점을 설계합니다.
AWS 보안 아키텍처
IAM 최소 권한 · VPC · 암호화 · 조건 키
AWS 보안 아키텍처
IAM 최소 권한 + VPC 격리 + KMS 암호화 — 3중 인프라 보호
3중 인프라 보호
IAM이 권한을, VPC가 네트워크를, KMS가 데이터를 지킵니다 — 에이전트가 실행되기 전에 먼저 갖추는 기반 방어선입니다.
- IAM 정책 4요소 — Who · What · Where · When
- VPC 격리 — Private Subnet + VPC Endpoint
- 암호화 — 전송 중 TLS · 저장 시 KMS CMK
출발점은 최소 권한입니다 — 에이전트별 전용 IAM Role 분리로 권한 경계를 먼저 긋습니다.
IAM 정책 4요소
모든 에이전트 IAM 정책은 4가지를 명확히 정의
Who (누가)
어떤 역할/서비스가 호출하는가. 에이전트별 전용 IAM Role 분리로 구분
What (무엇을)
어떤 Action을 허용하는가. bedrock:InvokeModel만 허용, CreateAgent는 금지
Where (어디서)
어떤 리소스에 대해. ARN으로 특정 모델/에이전트만 지정
When (언제)
어떤 조건에서. IP 범위, 시간대, MFA 여부, 태그 매칭
bedrock:InvokeModel만 허용하고 CreateAgent는 금지하듯 — 네 요소를 전부 명시할수록 권한 경계가 좁아집니다.
VPC 격리와 암호화
에이전트 네트워크 통제 + 데이터 보호
VPC 격리
- 고객 VPC 안에서만 에이전트 실행
- Private Subnet + NAT Gateway
- VPC Endpoint로 AWS 서비스 접근
- Security Group으로 포트 제한
암호화
- 전송 중: TLS 암호화 (AWS 네트워크 내)
- 저장 시: KMS CMK (고객 관리 키)
- 에이전트 세션 데이터 암호화
- CloudTrail 로그 암호화
고객 VPC 안에서만 실행하고, 세션 데이터와 CloudTrail 로그까지 KMS CMK로 암호화합니다 — 네트워크와 데이터를 함께 보호합니다.
Bedrock Guardrails 적용
조합 전략 · Automated Reasoning · 비용
Bedrock Guardrails 적용
워크로드별 필터 조합으로 최적 방어 수준 설계
워크로드가 방어 수준을 결정
Content Filters · PII · Grounding · Automated Reasoning을 워크로드에 맞게 배합합니다 — 필터를 전부 켜는 것이 목표가 아닙니다.
- 조합 전략 — 워크로드별 필터 배합
- Automated Reasoning — 정책 위반을 수학적으로 증명
- InvokeGuardrailChecks — 리소스 생성 없이 임의 지점에 적용
금융 컴플라이언스는 4종 전부, 코드 생성은 Content Filters LOW만 — 방어 수준은 워크로드가 결정합니다.
Guardrails 조합 전략
고객 챗봇 · 사내 헬프데스크 · 금융 컴플라이언스 · 코드 생성 — 워크로드 4종의 필터 배합표
| 워크로드 | Content Filters | PII | Grounding | Automated Reasoning |
|---|---|---|---|---|
| 고객 챗봇 | ✓ HIGH | ✓ MASK | ✓ | — |
| 사내 헬프데스크 | ✓ MEDIUM | ✓ BLOCK | — | — |
| 금융 컴플라이언스 | ✓ HIGH | ✓ BLOCK | ✓ | ✓ |
| 코드 생성 | ✓ LOW | — | — | — |
같은 PII 필터도 고객 챗봇은 MASK, 사내 헬프데스크는 BLOCK — 워크로드에 따라 동작 모드까지 달라집니다.
Automated Reasoning — 조합 판단 기준
명문화된 규칙 · 큰 오답 비용 · 논리 위반 탐지 — 수학적 정책 증명이 필요한 신호
켜야 할 신호
- 규칙이 명문화된 도메인 — 여신 한도·수수료 정책
- 오답 비용이 큰 컴플라이언스 워크로드
- Grounding만으로 못 잡는 논리 위반 탐지 필요
조합 시 고려
- 자연어 정책을 논리식으로 변환해 검증
- 모호한 정책은 Policy Refinement로 반복 개선
- Content Filters·PII와 독립 — 필요한 워크로드에만 추가
동작 원리와 검증 파이프라인 상세는 Bedrock Guardrails 모듈에서 다룹니다 — 이 모듈에서는 조합 기준만 잡습니다.
에이전트 보안
Cedar 정책 · Identity · HITL 승인 게이트
에이전트 보안
Cedar 정책 + Identity 인증 + HITL 승인의 3중 행동 통제
에이전트 행동 통제 3종
Cedar가 도구 접근을, Identity가 자격 증명을, HITL이 위험 동작을 통제합니다 — 인프라 보호 위에 얹는 애플리케이션 수준 방어입니다.
- Cedar 정책 — permit/forbid로 도구 접근 제어
- Identity — Inbound(IAM/JWT) · Outbound(OAuth/API Key)
- HITL 승인 게이트 — 위험 동작은 승인되어야만 실행
IAM이 AWS 리소스를 지키는 인프라 수준이라면, Cedar는 도구 이름 자체가 action이 되는 애플리케이션 수준입니다.
Cedar 정책으로 도구 접근 제어
Strands Cedar(strands-agents[cedar])가 permit/forbid 정책으로 도구 접근을 통제
Cedar 정책 예시
- permit — 허용할 도구를 명시적으로 선언 (search_wiki)
- forbid — 차단할 도구를 명시적으로 선언 (delete_data)
- forbid가 permit보다 항상 우선 적용
- 어느 정책에도 매칭되지 않으면 기본 거부 (default deny)
IAM vs Cedar 차이
- IAM = AWS 리소스 접근 제어 (인프라 수준)
- Cedar = 에이전트 도구 접근 제어 (애플리케이션 수준)
- Cedar의 action = 도구 이름 자체 (Action::"search_wiki")
- principal은 principal_resolver로 해석 (기본 User::"anonymous")
- 역할 제어: context.session.role + when 조건 조합
AgentCore Policy는 같은 Cedar 언어를 쓰지만 별도 스키마(AgentCore::Action::"{Target}___{tool}")를 사용합니다 — Policy 모듈에서 다룹니다.
Cedar 정책 문법 — permit · forbid · default deny
허용과 차단을 선언하는 실제 정책 파일 — 원칙과 코드의 줄별 대응
// ① permit — 허용할 도구를 명시적으로 선언
permit(
principal,
action == Action::"search_wiki",
resource
);
// ② forbid — 차단 선언, permit보다 항상 우선
forbid(
principal,
action == Action::"delete_data",
resource
);- permit — 허용 도구를 명시 선언, action은 도구 이름 자체 (Action::"search_wiki")
- forbid — 차단 선언, permit과 충돌하면 forbid가 항상 우선
- 어느 정책에도 매칭되지 않으면 기본 거부 (default deny)
HITL 승인 게이트
위험 동작 전 사람 승인을 강제하는 패턴 — 거부뿐 아니라 타임아웃도 차단(deny by default)
approvals — 관리자 승인 콘솔
"target": "prod-db.users", "rows": 1204,
"reason": "GDPR 삭제 요청 #4521"}
✓ 승인 후 실행
✕ 거부
-
1
에이전트 판단
"데이터 삭제가 필요합니다" → 위험 동작 감지.
-
2
승인 요청
사용자/관리자에게 승인 요청 전송.
-
3
대기
승인 응답 대기 (Timeout 설정).
-
4
실행/차단
승인 → 실행, 거부/타임아웃 → 차단.
거버넌스 체계
AI 편향 · CloudTrail 감사 · 성숙도 기반 자율 확대
거버넌스 체계
편향 탐지 + 감사 로깅 + 점진적 자율 확대의 3축 거버넌스
3축 거버넌스
편향을 탐지하고, 모든 동작을 기록하고, 신뢰가 쌓인 만큼 자율을 넓힙니다 — 기술 통제를 조직 운영으로 완성합니다.
- AI 편향 — 학습 데이터 · 프롬프트 · 선택 편향
- CloudTrail + CloudWatch — 100% 로깅과 사후 추적
- 점진적 자율 확대 — L1 완전감독 → L2 선택감독 → L3 자율운영
"처음엔 모두 승인, 신뢰 확보 후 점진 자율화" — 이 파트를 관통하는 운영 원칙입니다.
AI 편향 유형과 대응
학습 데이터 · 프롬프트 · 선택 — 편향이 스며드는 세 경로
학습 데이터 편향
학습 데이터의 편향이 모델에 반영. 특정 그룹에 불공정한 결과
프롬프트 편향
시스템 프롬프트의 무의식적 편향. "남성 엔지니어에게 추천"
선택 편향
평가 데이터셋이 특정 집단에 치우침. 모니터링으로 탐지
편향은 학습 데이터만의 문제가 아닙니다 — 시스템 프롬프트와 평가 데이터셋에서도 스며들기에 모니터링과 다양성 검증으로 탐지합니다.
감사 체계 위의 점진적 자율 확대
CloudTrail 100% 로깅이 감사 기반을 만들고, 그 위에서 신뢰가 쌓이는 만큼 자율을 넓히는 L1→L3 프레임
-
1
L1 완전 감독
모든 에이전트 동작에 HITL 승인. CloudTrail 100% 로깅
-
2
L2 선택적 감독
위험 동작만 승인. 일상 동작은 자동. 이상 탐지 알람
-
3
L3 자율 운영
대부분 자동. 사후 감사 기반. 서킷 브레이커로 안전장치
"처음엔 모두 승인 → 신뢰 확보 후 점진 자율화"가 원칙입니다 — L1→L3는 이 원칙을 운영 단계로 나눈 프레임입니다.
AI 보안 운영 원칙
최소 권한으로 시작 · 모든 계층에서 검증 · 신뢰만큼 자율 확대 — IAM·Guardrails·Policy·모니터링의 심층 방어
최소 권한으로 시작해, 모든 계층에서 검증하고, 신뢰만큼 자율을 넓힌다
IAM + Guardrails + Policy + 모니터링 — 단일 방어선 대신 심층 방어
IAM + Guardrails + Policy + 모니터링 = 4중 방어