Ch3. 보안 아키텍처

AI 시스템은 "모델 호출"보다 "도구 호출"에서 사고가 커집니다. 따라서 아키텍처는 모델 정확도보다 권한 경계와 실행 격리를 우선해야 합니다.

게이트웨이, 정책 엔진, 오케스트레이터, LLM 런타임, RAG, 도구 샌드박스가 신뢰경계로 분리된 아키텍처 지도

핵심 운영 흐름

이 장의 목적은 설계도를 그리는 것이 아니라, AI 시스템의 실행 경계를 배포 전에 고정하는 것입니다.

신뢰경계와 데이터 이동 경로를 식별합니다.

모델·RAG·도구 실행기를 서로 다른 신뢰 단위로 분리합니다.

고위험 도구와 내부 시스템 호출은 Policy Engine을 거치게 합니다.

배포 게이트에서 정책 테스트, PII 스캔, 감사 로그 연결을 검증합니다.

참조 아키텍처

Attack Surface Score

AI 시스템의 공격 표면은 노출 엔드포인트, 도구 수, 권한 수준에 비례해 넓어집니다. 아래 계산기로 현재 아키텍처의 공격 표면 점수를 추정하세요.

\text{Attack Surface Score} = E \times 2 + T \times 3 + P \times 5 + (1 - I) \times 10

$E$ : 외부 노출 엔드포인트 수
$T$ : 연결된 도구(Tool) 수
$P$ : 고위험 권한(쓰기/삭제/결제) 수
$I$ : 격리 수준 (0.0~1.0, 완전 격리 시 1.0)

점수 구간	분류	조치
0~50	Low	분기 1회 점검
51~100	Medium	월 1회 점검 + 도구 허용목록 검토
101~150	High	격리 수준 강화 + 릴리스 게이트 필수
151+	Critical	아키텍처 재설계 + 임원 승인 전 배포 금지

계층별 통제

계층	핵심 리스크	기본 통제
Gateway	인증 우회, 과다 호출	OAuth/OIDC, Rate Limit, WAF
Policy Engine	정책 미적용	정책 버전관리, 차단 우선(Default Deny)
Orchestrator	잘못된 도구 선택	Allowlist, Tool Risk Tag
Tool Executor	권한 남용	네트워크 분리, 명령 샌드박스
Logging	민감정보 유출	필드 단위 마스킹, 접근 제어

계층별 위협 모델

각 계층에서 발생 가능한 위협과 그에 대한 완화 전략을 정리합니다.

계층	위협	공격 벡터	영향도	완화 전략
Gateway	Credential Stuffing	탈취된 자격증명 대량 시도	High	Rate Limit + MFA 강제 + IP 평판 필터링
Gateway	DDoS / Resource Exhaustion	대량 요청으로 모델 비용 폭증	Critical	요청 크기 제한 + 토큰 예산(Token Budget)
Policy Engine	Policy Bypass	정책 로직 취약점 악용	Critical	정책 단위 테스트 + Deny-by-Default
Policy Engine	Stale Policy	오래된 정책 버전 적용	Medium	Git 기반 버전관리 + 자동 배포
Orchestrator	Tool Confusion	프롬프트로 의도하지 않은 도구 호출 유도	High	Tool Allowlist + 호출 전 확인(Human-in-the-Loop)
Orchestrator	Chain Injection	중간 응답 조작으로 다음 단계 오염	High	단계별 출력 검증 + 체인 길이 제한
LLM Runtime	Prompt Injection	시스템 프롬프트 탈취/우회	High	입력 필터링 + 출력 검증 이중 방어
LLM Runtime	Model Exfiltration	모델 가중치/프롬프트 추출 시도	Medium	API-only 접근 + 응답 길이 제한
RAG Service	Data Poisoning	악성 문서 삽입으로 RAG 결과 오염	High	문서 출처 검증 + 임베딩 이상치 탐지
RAG Service	Context Overflow	과도한 검색 결과로 컨텍스트 오염	Medium	Top-K 제한 + Relevance Score 임계값
Tool Executor	Privilege Escalation	도구 권한을 이용한 시스템 침투	Critical	최소 권한 + 네트워크 격리 + 실행 시간 제한
Tool Executor	Command Injection	도구 인자에 악성 명령 삽입	Critical	입력 파라미터화 + 샌드박스 실행
Audit Log	Log Tampering	로그 삭제/변조로 사건 은폐	High	Append-only 저장소 + 무결성 해시
Audit Log	PII Leakage	로그에 민감정보 기록	High	필드 단위 마스킹 + DLP 스캔

설계 원칙

Default Deny: 명시적으로 허용한 액션만 실행
Policy as Code: 정책을 코드 리뷰/배포 파이프라인에 포함
Blast Radius 최소화: 단일 에이전트 실패가 전체 시스템으로 확산되지 않게 분리

Zero Trust for AI Workloads

전통적인 네트워크 경계 보안은 AI 시스템에 부적합합니다. 모델, 도구, RAG 서비스가 각각 독립된 신뢰 단위로 동작하므로 모든 계층에서 신원을 검증해야 합니다.

핵심 원칙

Zero Trust 3원칙 (AI 확장)

Never Trust, Always Verify — 모든 요청은 내부/외부 무관하게 인증·인가를 거칩니다. 2. Least Privilege per Invocation — 에이전트의 도구 호출마다 최소 권한을 동적으로 부여합니다. 3. Assume Breach — 모델 출력도 잠재적 공격 벡터로 간주하고 검증합니다.

계층별 ID 검증 매트릭스

계층	주체	인증 방식	인가 방식	갱신 주기
Gateway → Policy Engine	API Client	mTLS + JWT	Scope 기반	요청마다
Policy Engine → Orchestrator	Service Account	SPIFFE/SPIRE ID	Policy-as-Code 평가	요청마다
Orchestrator → LLM Runtime	Agent Session	세션 토큰 + Context Hash	모델별 허용 목록	세션마다
Orchestrator → Tool Executor	Agent + Tool Pair	서명된 호출 토큰	Tool Risk Tag + ABAC	호출마다
Tool Executor → Internal Systems	Tool Identity	Short-lived Token	최소 권한 Scope	호출마다
RAG Service → Vector DB	Service Account	API Key (Vault 주입)	Read-only Scope	1시간

구현 단계

Workload Identity 도입

모든 서비스와 에이전트에 SPIFFE ID를 부여합니다.
하드코딩된 API Key를 제거하고 Vault 또는 Secret Manager로 전환합니다.

mTLS 전면 적용

서비스 간 통신에 mTLS를 적용하여 평문 통신을 차단합니다.
인증서 자동 갱신(auto-rotation)을 설정합니다.

호출별 인가(Per-Invocation Authorization)

에이전트의 매 도구 호출 시 Policy Engine이 실시간으로 허용 여부를 판단합니다.
캐시를 사용하되, 고위험 도구는 캐시 없이 매번 판단합니다.

Continuous Verification

세션 중에도 주기적으로 컨텍스트(IP, 행동 패턴)를 재검증합니다.
이상 행동 탐지 시 세션을 즉시 종료하고 감사 로그를 생성합니다.

신뢰경계(Trust Boundary) 다이어그램

아래 다이어그램은 AI 시스템의 주요 신뢰경계를 시각화합니다. 경계를 넘는 모든 통신에는 인증·인가·암호화가 필수입니다.

경계 간 통신 원칙

신뢰경계를 넘는 모든 데이터는 암호화(mTLS) + 인증(토큰 검증) + 인가(정책 평가) 3중 검증을 거쳐야 합니다. 경계 내부라도 민감 데이터는 전송 시 암호화합니다.

네트워크 분리 패턴

AI 시스템의 네트워크 분리는 전통적인 서버 격리와 다릅니다. 모델 런타임, 도구 실행기, 데이터 저장소 각각에 맞는 격리 전략이 필요합니다.

목표: LLM 런타임이 침해되어도 내부 시스템에 직접 접근할 수 없게 합니다.

통제 항목	구현 방식
네트워크 정책	Orchestrator → LLM만 허용, LLM → 외부 차단
GPU 격리	MIG(Multi-Instance GPU) 또는 전용 노드 할당
파일시스템	Read-only root + tmpfs (모델 가중치만 마운트)
Egress 제어	모든 아웃바운드 트래픽 차단 (모델은 응답만 반환)
리소스 제한	CPU/메모리/GPU 메모리 Quota 설정

# Kubernetes NetworkPolicy 예시
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: llm-runtime-isolation
spec:
  podSelector:
    matchLabels:
      app: llm-runtime
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orchestrator
  egress: []  # 모든 아웃바운드 차단

목표: 도구가 의도하지 않은 명령을 실행하거나 네트워크를 통해 데이터를 유출하지 못하게 합니다.

통제 항목	구현 방식
런타임 격리	gVisor 또는 Firecracker MicroVM
시간 제한	도구별 Timeout (기본 30초, 최대 300초)
Egress Allowlist	도구별 허용 도메인만 통과 (DNS 기반 필터링)
파일시스템	임시 디렉토리만 쓰기 가능, 실행 후 삭제
Syscall 필터링	Seccomp 프로파일로 허용 시스템콜 제한
리소스 제한	메모리 512MB, CPU 0.5 코어 기본값

# Tool Executor 샌드박스 설정 예시
sandbox:
  runtime: gvisor
  timeout: 30s
  resources:
    memory: 512Mi
    cpu: 500m
  filesystem:
    readOnly: true
    tmpDir: /tmp  # 유일한 쓰기 가능 경로
  network:
    egress_allowlist:
      - "api.internal.company.com"
      - "vault.internal.company.com"
  seccomp:
    profile: runtime/default

목표: RAG 서비스가 Vector DB에만 Read-only 접근하고, 다른 시스템과 직접 통신하지 못하게 합니다.

통제 항목	구현 방식
DB 접근	Read-only 계정, 쿼리 파라미터화
네트워크	Orchestrator → RAG → Vector DB 단방향만 허용
임베딩 검증	문서 삽입 시 출처 메타데이터 필수, 이상치 탐지
결과 필터링	PII 필드 자동 제거 후 반환
인덱스 관리	프로덕션 인덱스는 CI/CD 파이프라인에서만 갱신

# RAG 서비스 네트워크 정책
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: rag-service-isolation
spec:
  podSelector:
    matchLabels:
      app: rag-service
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orchestrator
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: vector-db
      ports:
        - port: 6333  # Qdrant 기본 포트

Policy as Code 구현

정책을 문서가 아닌 코드로 관리하면 리뷰·테스트·배포를 자동화할 수 있습니다.

정책 엔진 선택

엔진	언어	장점	적합 시나리오
OPA (Rego)	Rego	범용, 생태계 풍부	Kubernetes, API Gateway 통합
Cedar	Cedar	타입 안전, 빠른 평가	AWS 환경, 세밀한 ABAC
Casbin	다중 언어	경량, 모델 유연	단일 앱 내 권한 관리

정책 코드 예시 (OPA/Rego)

# policy/ai/tool_execution.rego
package ai.tool_execution

default allow := false

# 고위험 도구는 승인 필수
allow if {
    input.tool.risk_level != "critical"
    input.agent.role in allowed_roles[input.tool.name]
}

# 승인된 고위험 도구
allow if {
    input.tool.risk_level == "critical"
    input.approval.status == "approved"
    input.approval.expires_at > time.now_ns()
}

# 도구별 허용 역할 매핑
allowed_roles := {
    "search_documents": ["analyst", "agent", "admin"],
    "send_email": ["agent", "admin"],
    "process_payment": ["admin"],
    "delete_record": ["admin"],
}

정책 파이프라인

정책 작성 및 코드 리뷰

정책 파일을 Git 저장소에서 관리합니다.
변경 시 보안팀 리뷰를 필수로 둡니다.

자동화 테스트

정책별 단위 테스트를 작성합니다 (허용/차단 시나리오).
CI에서 opa test 또는 동등한 명령으로 검증합니다.

# CI 파이프라인 예시
policy_test:
  script:
    - opa test ./policy/ -v
    - opa check ./policy/ --strict
  rules:
    - changes:
        - "policy/**"

스테이징 배포 및 Shadow Mode

프로덕션 적용 전 Shadow Mode로 배포합니다.
실제 트래픽에 대해 정책을 평가하되, 차단하지 않고 로그만 기록합니다.
예상치 못한 차단이 없는지 확인한 후 Enforce Mode로 전환합니다.

프로덕션 Enforce + 모니터링

정책 평가 결과(허용/차단/오류)를 대시보드에서 실시간 모니터링합니다.
차단율이 임계값을 초과하면 알림을 발생시킵니다.

정책 거버넌스 규칙

정책 변경 통제

정책 변경은 반드시 PR을 통해 진행하며, 보안팀 1인 이상 승인이 필요합니다.
긴급 변경(Hotfix)도 사후 24시간 이내에 PR과 리뷰를 완료합니다.
정책 롤백 절차를 사전에 준비하고 테스트합니다.

배포 게이트 예시

security_gates:
  - name: policy-test
    rule: 'critical policy tests == 100% pass'
  - name: tool-permission-diff
    rule: 'new high-risk tool requires approval'
  - name: pii-leak-scan
    rule: 'no P0 field in logs'

배포 보안 체크리스트

배포 전 아래 항목을 모두 확인합니다. 하나라도 미충족 시 배포를 중단합니다.

인증·인가

모든 서비스 간 통신에 mTLS가 적용되어 있는가
하드코딩된 API Key/Secret이 코드에 없는가
에이전트 ID가 SPIFFE 등 표준 Workload Identity를 사용하는가
고위험 도구 호출 시 실시간 인가 검증이 동작하는가

네트워크 격리

LLM Runtime의 Egress가 완전 차단되어 있는가
Tool Executor가 샌드박스(gVisor/Firecracker) 안에서 실행되는가
Tool별 Egress Allowlist가 최소한으로 설정되어 있는가
RAG Service → Vector DB 연결이 Read-only인가

정책

정책 코드의 단위 테스트가 100% 통과했는가
Shadow Mode에서 예상치 못한 차단이 없었는가
Default Deny가 모든 정책의 기본값인가
정책 버전이 배포 artifact와 함께 태깅되어 있는가

데이터 보호

로그에 PII/민감정보가 마스킹되어 있는가
감사 로그가 Append-only 저장소에 기록되는가
모델 프롬프트에 민감 데이터가 포함되지 않는가
RAG 인덱스의 문서 출처가 모두 검증되었는가

운영 준비

Fallback 응답이 설정되어 있는가 (모델 장애 시)
토큰 예산(Token Budget)이 설정되어 있는가
알림 임계값(차단율, 오류율, 지연시간)이 설정되어 있는가
롤백 절차가 문서화되고 테스트되었는가

AI 공급망 보안

AI 시스템의 공급망은 전통적 소프트웨어보다 공격 표면이 넓습니다. 모델 가중치, 파인튜닝 데이터, 서드파티 플러그인 등 새로운 공급망 요소가 추가되기 때문입니다.

공급망 위협 맵

공급망 보안 통제 매트릭스

위협	공격 벡터	탐지 방법	필수 통제
파인튜닝 데이터 오염	악성 데이터 삽입으로 모델 백도어 생성	데이터 이상치 탐지, 출력 품질 모니터링	데이터 출처 검증, 무결성 해시, 접근 로그
모델 가중치 변조	배포 파이프라인에서 가중치 파일 교체	해시 검증, 서명 확인	모델 서명(cosign 등), CI/CD 무결성 체인
사전학습 모델 백도어	공개 모델에 숨겨진 트리거 기반 백도어	트리거 패턴 스캔, 행동 테스트	모델 출처 검증, 샌드박스 평가 후 채택
서드파티 도구 악용	악성 MCP 서버, 변조된 플러그인	도구 행동 모니터링, 권한 감사	도구 허용목록, 서명 검증, 샌드박스 실행
의존성 공격	ML 라이브러리의 악성 패키지(typosquatting 등)	의존성 스캔(SCA), lockfile 검증	의존성 고정, 보안 스캔 CI 통합

모델 무결성 검증 파이프라인

모델 서명

모델 학습 완료 시 가중치 파일에 디지털 서명을 적용합니다.
cosign, Sigstore 등 표준 도구를 활용합니다.
서명 키는 HSM 또는 Cloud KMS에서 관리합니다.

배포 전 검증

CI/CD 파이프라인에서 모델 서명과 해시를 자동 검증합니다.
검증 실패 시 배포를 즉시 차단합니다.
검증 결과를 감사 로그에 기록합니다.

런타임 무결성 확인

서빙 시작 시 로드된 모델의 해시를 레지스트리와 대조합니다.
주기적(매 6시간)으로 런타임 모델의 무결성을 재검증합니다.
불일치 탐지 시 자동 알림 + 서빙 중단 트리거.

공급망 공격은 탐지가 어렵습니다

파인튜닝 데이터 오염이나 모델 백도어는 일반적인 테스트로 발견하기 매우 어렵습니다. **"내가 사용하는 모델과 데이터의 출처를 모두 신뢰할 수 있는가?"**를 주기적으로 점검하고, 모델 레지스트리에 출처·버전·해시를 필수로 기록하세요.

아키텍처 리뷰 질문

신규 도구 추가 시 자동으로 위험등급이 부여되는가
모델 실패 시 안전한 기본 응답으로 폴백되는가
정책 변경이 코드와 함께 버전 관리되는가
감사 로그가 사건 재구성 수준으로 충분한가
신뢰경계를 넘는 모든 통신이 mTLS로 암호화되는가
Tool Executor의 샌드박스 탈출 시나리오가 위협 모델에 포함되어 있는가
정책 Shadow Mode 운영 기간이 충분했는가
Attack Surface Score가 허용 범위 내인가
모델 가중치의 무결성 검증(서명/해시)이 배포 파이프라인에 통합되어 있는가
서드파티 도구·플러그인의 출처 검증과 권한 감사가 수행되고 있는가

완료 산출물

Ch3 완료 기준

이 장을 적용한 뒤에는 신뢰경계 다이어그램, Attack Surface Score, 계층별 위협 모델, Policy as Code 저장소, 배포 보안 체크리스트, 공급망 무결성 검증 절차가 남아 있어야 합니다.

핵심 운영 흐름

이 장의 목적은 설계도를 그리는 것이 아니라, AI 시스템의 실행 경계를 배포 전에 고정하는 것입니다.

신뢰경계와 데이터 이동 경로를 식별합니다.

모델·RAG·도구 실행기를 서로 다른 신뢰 단위로 분리합니다.

고위험 도구와 내부 시스템 호출은 Policy Engine을 거치게 합니다.

배포 게이트에서 정책 테스트, PII 스캔, 감사 로그 연결을 검증합니다.

참조 아키텍처

Attack Surface Score

AI 시스템의 공격 표면은 노출 엔드포인트, 도구 수, 권한 수준에 비례해 넓어집니다. 아래 계산기로 현재 아키텍처의 공격 표면 점수를 추정하세요.

\text{Attack Surface Score} = E \times 2 + T \times 3 + P \times 5 + (1 - I) \times 10

$E$ : 외부 노출 엔드포인트 수
$T$ : 연결된 도구(Tool) 수
$P$ : 고위험 권한(쓰기/삭제/결제) 수
$I$ : 격리 수준 (0.0~1.0, 완전 격리 시 1.0)

점수 구간	분류	조치
0~50	Low	분기 1회 점검
51~100	Medium	월 1회 점검 + 도구 허용목록 검토
101~150	High	격리 수준 강화 + 릴리스 게이트 필수
151+	Critical	아키텍처 재설계 + 임원 승인 전 배포 금지

계층별 통제

계층	핵심 리스크	기본 통제
Gateway	인증 우회, 과다 호출	OAuth/OIDC, Rate Limit, WAF
Policy Engine	정책 미적용	정책 버전관리, 차단 우선(Default Deny)
Orchestrator	잘못된 도구 선택	Allowlist, Tool Risk Tag
Tool Executor	권한 남용	네트워크 분리, 명령 샌드박스
Logging	민감정보 유출	필드 단위 마스킹, 접근 제어

계층별 위협 모델

각 계층에서 발생 가능한 위협과 그에 대한 완화 전략을 정리합니다.

계층	위협	공격 벡터	영향도	완화 전략
Gateway	Credential Stuffing	탈취된 자격증명 대량 시도	High	Rate Limit + MFA 강제 + IP 평판 필터링
Gateway	DDoS / Resource Exhaustion	대량 요청으로 모델 비용 폭증	Critical	요청 크기 제한 + 토큰 예산(Token Budget)
Policy Engine	Policy Bypass	정책 로직 취약점 악용	Critical	정책 단위 테스트 + Deny-by-Default
Policy Engine	Stale Policy	오래된 정책 버전 적용	Medium	Git 기반 버전관리 + 자동 배포
Orchestrator	Tool Confusion	프롬프트로 의도하지 않은 도구 호출 유도	High	Tool Allowlist + 호출 전 확인(Human-in-the-Loop)
Orchestrator	Chain Injection	중간 응답 조작으로 다음 단계 오염	High	단계별 출력 검증 + 체인 길이 제한
LLM Runtime	Prompt Injection	시스템 프롬프트 탈취/우회	High	입력 필터링 + 출력 검증 이중 방어
LLM Runtime	Model Exfiltration	모델 가중치/프롬프트 추출 시도	Medium	API-only 접근 + 응답 길이 제한
RAG Service	Data Poisoning	악성 문서 삽입으로 RAG 결과 오염	High	문서 출처 검증 + 임베딩 이상치 탐지
RAG Service	Context Overflow	과도한 검색 결과로 컨텍스트 오염	Medium	Top-K 제한 + Relevance Score 임계값
Tool Executor	Privilege Escalation	도구 권한을 이용한 시스템 침투	Critical	최소 권한 + 네트워크 격리 + 실행 시간 제한
Tool Executor	Command Injection	도구 인자에 악성 명령 삽입	Critical	입력 파라미터화 + 샌드박스 실행
Audit Log	Log Tampering	로그 삭제/변조로 사건 은폐	High	Append-only 저장소 + 무결성 해시
Audit Log	PII Leakage	로그에 민감정보 기록	High	필드 단위 마스킹 + DLP 스캔

설계 원칙

Default Deny: 명시적으로 허용한 액션만 실행
Policy as Code: 정책을 코드 리뷰/배포 파이프라인에 포함
Blast Radius 최소화: 단일 에이전트 실패가 전체 시스템으로 확산되지 않게 분리

Zero Trust for AI Workloads

핵심 원칙

Zero Trust 3원칙 (AI 확장)

Never Trust, Always Verify — 모든 요청은 내부/외부 무관하게 인증·인가를 거칩니다. 2. Least Privilege per Invocation — 에이전트의 도구 호출마다 최소 권한을 동적으로 부여합니다. 3. Assume Breach — 모델 출력도 잠재적 공격 벡터로 간주하고 검증합니다.

계층별 ID 검증 매트릭스

계층	주체	인증 방식	인가 방식	갱신 주기
Gateway → Policy Engine	API Client	mTLS + JWT	Scope 기반	요청마다
Policy Engine → Orchestrator	Service Account	SPIFFE/SPIRE ID	Policy-as-Code 평가	요청마다
Orchestrator → LLM Runtime	Agent Session	세션 토큰 + Context Hash	모델별 허용 목록	세션마다
Orchestrator → Tool Executor	Agent + Tool Pair	서명된 호출 토큰	Tool Risk Tag + ABAC	호출마다
Tool Executor → Internal Systems	Tool Identity	Short-lived Token	최소 권한 Scope	호출마다
RAG Service → Vector DB	Service Account	API Key (Vault 주입)	Read-only Scope	1시간

구현 단계

Workload Identity 도입

모든 서비스와 에이전트에 SPIFFE ID를 부여합니다.
하드코딩된 API Key를 제거하고 Vault 또는 Secret Manager로 전환합니다.

mTLS 전면 적용

서비스 간 통신에 mTLS를 적용하여 평문 통신을 차단합니다.
인증서 자동 갱신(auto-rotation)을 설정합니다.

호출별 인가(Per-Invocation Authorization)

에이전트의 매 도구 호출 시 Policy Engine이 실시간으로 허용 여부를 판단합니다.
캐시를 사용하되, 고위험 도구는 캐시 없이 매번 판단합니다.

Continuous Verification

세션 중에도 주기적으로 컨텍스트(IP, 행동 패턴)를 재검증합니다.
이상 행동 탐지 시 세션을 즉시 종료하고 감사 로그를 생성합니다.

신뢰경계(Trust Boundary) 다이어그램

아래 다이어그램은 AI 시스템의 주요 신뢰경계를 시각화합니다. 경계를 넘는 모든 통신에는 인증·인가·암호화가 필수입니다.

경계 간 통신 원칙

네트워크 분리 패턴

AI 시스템의 네트워크 분리는 전통적인 서버 격리와 다릅니다. 모델 런타임, 도구 실행기, 데이터 저장소 각각에 맞는 격리 전략이 필요합니다.

목표: LLM 런타임이 침해되어도 내부 시스템에 직접 접근할 수 없게 합니다.

통제 항목	구현 방식
네트워크 정책	Orchestrator → LLM만 허용, LLM → 외부 차단
GPU 격리	MIG(Multi-Instance GPU) 또는 전용 노드 할당
파일시스템	Read-only root + tmpfs (모델 가중치만 마운트)
Egress 제어	모든 아웃바운드 트래픽 차단 (모델은 응답만 반환)
리소스 제한	CPU/메모리/GPU 메모리 Quota 설정

# Kubernetes NetworkPolicy 예시
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: llm-runtime-isolation
spec:
  podSelector:
    matchLabels:
      app: llm-runtime
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orchestrator
  egress: []  # 모든 아웃바운드 차단

목표: 도구가 의도하지 않은 명령을 실행하거나 네트워크를 통해 데이터를 유출하지 못하게 합니다.

통제 항목	구현 방식
런타임 격리	gVisor 또는 Firecracker MicroVM
시간 제한	도구별 Timeout (기본 30초, 최대 300초)
Egress Allowlist	도구별 허용 도메인만 통과 (DNS 기반 필터링)
파일시스템	임시 디렉토리만 쓰기 가능, 실행 후 삭제
Syscall 필터링	Seccomp 프로파일로 허용 시스템콜 제한
리소스 제한	메모리 512MB, CPU 0.5 코어 기본값

# Tool Executor 샌드박스 설정 예시
sandbox:
  runtime: gvisor
  timeout: 30s
  resources:
    memory: 512Mi
    cpu: 500m
  filesystem:
    readOnly: true
    tmpDir: /tmp  # 유일한 쓰기 가능 경로
  network:
    egress_allowlist:
      - "api.internal.company.com"
      - "vault.internal.company.com"
  seccomp:
    profile: runtime/default

목표: RAG 서비스가 Vector DB에만 Read-only 접근하고, 다른 시스템과 직접 통신하지 못하게 합니다.

통제 항목	구현 방식
DB 접근	Read-only 계정, 쿼리 파라미터화
네트워크	Orchestrator → RAG → Vector DB 단방향만 허용
임베딩 검증	문서 삽입 시 출처 메타데이터 필수, 이상치 탐지
결과 필터링	PII 필드 자동 제거 후 반환
인덱스 관리	프로덕션 인덱스는 CI/CD 파이프라인에서만 갱신

# RAG 서비스 네트워크 정책
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: rag-service-isolation
spec:
  podSelector:
    matchLabels:
      app: rag-service
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: orchestrator
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: vector-db
      ports:
        - port: 6333  # Qdrant 기본 포트

Policy as Code 구현

정책을 문서가 아닌 코드로 관리하면 리뷰·테스트·배포를 자동화할 수 있습니다.

정책 엔진 선택

엔진	언어	장점	적합 시나리오
OPA (Rego)	Rego	범용, 생태계 풍부	Kubernetes, API Gateway 통합
Cedar	Cedar	타입 안전, 빠른 평가	AWS 환경, 세밀한 ABAC
Casbin	다중 언어	경량, 모델 유연	단일 앱 내 권한 관리

정책 코드 예시 (OPA/Rego)

# policy/ai/tool_execution.rego
package ai.tool_execution

default allow := false

# 고위험 도구는 승인 필수
allow if {
    input.tool.risk_level != "critical"
    input.agent.role in allowed_roles[input.tool.name]
}

# 승인된 고위험 도구
allow if {
    input.tool.risk_level == "critical"
    input.approval.status == "approved"
    input.approval.expires_at > time.now_ns()
}

# 도구별 허용 역할 매핑
allowed_roles := {
    "search_documents": ["analyst", "agent", "admin"],
    "send_email": ["agent", "admin"],
    "process_payment": ["admin"],
    "delete_record": ["admin"],
}

정책 파이프라인

정책 작성 및 코드 리뷰

정책 파일을 Git 저장소에서 관리합니다.
변경 시 보안팀 리뷰를 필수로 둡니다.

자동화 테스트

정책별 단위 테스트를 작성합니다 (허용/차단 시나리오).
CI에서 opa test 또는 동등한 명령으로 검증합니다.

# CI 파이프라인 예시
policy_test:
  script:
    - opa test ./policy/ -v
    - opa check ./policy/ --strict
  rules:
    - changes:
        - "policy/**"

스테이징 배포 및 Shadow Mode

프로덕션 적용 전 Shadow Mode로 배포합니다.
실제 트래픽에 대해 정책을 평가하되, 차단하지 않고 로그만 기록합니다.
예상치 못한 차단이 없는지 확인한 후 Enforce Mode로 전환합니다.

프로덕션 Enforce + 모니터링

정책 평가 결과(허용/차단/오류)를 대시보드에서 실시간 모니터링합니다.
차단율이 임계값을 초과하면 알림을 발생시킵니다.

정책 거버넌스 규칙

정책 변경 통제

정책 변경은 반드시 PR을 통해 진행하며, 보안팀 1인 이상 승인이 필요합니다.
긴급 변경(Hotfix)도 사후 24시간 이내에 PR과 리뷰를 완료합니다.
정책 롤백 절차를 사전에 준비하고 테스트합니다.

배포 게이트 예시

security_gates:
  - name: policy-test
    rule: 'critical policy tests == 100% pass'
  - name: tool-permission-diff
    rule: 'new high-risk tool requires approval'
  - name: pii-leak-scan
    rule: 'no P0 field in logs'

배포 보안 체크리스트

배포 전 아래 항목을 모두 확인합니다. 하나라도 미충족 시 배포를 중단합니다.

인증·인가

모든 서비스 간 통신에 mTLS가 적용되어 있는가
하드코딩된 API Key/Secret이 코드에 없는가
에이전트 ID가 SPIFFE 등 표준 Workload Identity를 사용하는가
고위험 도구 호출 시 실시간 인가 검증이 동작하는가

네트워크 격리

LLM Runtime의 Egress가 완전 차단되어 있는가
Tool Executor가 샌드박스(gVisor/Firecracker) 안에서 실행되는가
Tool별 Egress Allowlist가 최소한으로 설정되어 있는가
RAG Service → Vector DB 연결이 Read-only인가

정책

정책 코드의 단위 테스트가 100% 통과했는가
Shadow Mode에서 예상치 못한 차단이 없었는가
Default Deny가 모든 정책의 기본값인가
정책 버전이 배포 artifact와 함께 태깅되어 있는가

데이터 보호

로그에 PII/민감정보가 마스킹되어 있는가
감사 로그가 Append-only 저장소에 기록되는가
모델 프롬프트에 민감 데이터가 포함되지 않는가
RAG 인덱스의 문서 출처가 모두 검증되었는가

운영 준비

Fallback 응답이 설정되어 있는가 (모델 장애 시)
토큰 예산(Token Budget)이 설정되어 있는가
알림 임계값(차단율, 오류율, 지연시간)이 설정되어 있는가
롤백 절차가 문서화되고 테스트되었는가

위협	공격 벡터	탐지 방법	필수 통제
파인튜닝 데이터 오염	악성 데이터 삽입으로 모델 백도어 생성	데이터 이상치 탐지, 출력 품질 모니터링	데이터 출처 검증, 무결성 해시, 접근 로그
모델 가중치 변조	배포 파이프라인에서 가중치 파일 교체	해시 검증, 서명 확인	모델 서명(cosign 등), CI/CD 무결성 체인
사전학습 모델 백도어	공개 모델에 숨겨진 트리거 기반 백도어	트리거 패턴 스캔, 행동 테스트	모델 출처 검증, 샌드박스 평가 후 채택
서드파티 도구 악용	악성 MCP 서버, 변조된 플러그인	도구 행동 모니터링, 권한 감사	도구 허용목록, 서명 검증, 샌드박스 실행
의존성 공격	ML 라이브러리의 악성 패키지(typosquatting 등)	의존성 스캔(SCA), lockfile 검증	의존성 고정, 보안 스캔 CI 통합

모델 무결성 검증 파이프라인

모델 서명

모델 학습 완료 시 가중치 파일에 디지털 서명을 적용합니다.
cosign, Sigstore 등 표준 도구를 활용합니다.
서명 키는 HSM 또는 Cloud KMS에서 관리합니다.

배포 전 검증

CI/CD 파이프라인에서 모델 서명과 해시를 자동 검증합니다.
검증 실패 시 배포를 즉시 차단합니다.
검증 결과를 감사 로그에 기록합니다.

런타임 무결성 확인

서빙 시작 시 로드된 모델의 해시를 레지스트리와 대조합니다.
주기적(매 6시간)으로 런타임 모델의 무결성을 재검증합니다.
불일치 탐지 시 자동 알림 + 서빙 중단 트리거.

공급망 공격은 탐지가 어렵습니다

아키텍처 리뷰 질문

신규 도구 추가 시 자동으로 위험등급이 부여되는가
모델 실패 시 안전한 기본 응답으로 폴백되는가
정책 변경이 코드와 함께 버전 관리되는가
감사 로그가 사건 재구성 수준으로 충분한가
신뢰경계를 넘는 모든 통신이 mTLS로 암호화되는가
Tool Executor의 샌드박스 탈출 시나리오가 위협 모델에 포함되어 있는가
정책 Shadow Mode 운영 기간이 충분했는가
Attack Surface Score가 허용 범위 내인가
모델 가중치의 무결성 검증(서명/해시)이 배포 파이프라인에 통합되어 있는가
서드파티 도구·플러그인의 출처 검증과 권한 감사가 수행되고 있는가

완료 산출물

Ch3 완료 기준

Ch3. 보안 아키텍처

Ch4. 프롬프트 인젝션 방어

Ch5. 접근제어·비밀관리

목차

Ch3. 보안 아키텍처

Ch4. 프롬프트 인젝션 방어

Ch5. 접근제어·비밀관리

목차