엔터프라이즈 AI는 제로 트러스트 (Zero Trust)가 네트워크 경계에서 멈춘다면 결코 진정으로 안전해질 수 없습니다.

이는 데이터 수집 (Data ingestion)부터 검색 (Retrieval), 생성 (Generation), 그리고 출력 (Output)에 이르기까지 전체 AI 파이프라인 전반에 걸쳐 확장되어야 합니다.

최근 결성된 Open Secure AI Alliance는 많은 조직이 이미 직면하고 있는 문제, 즉 대규모 언어 모델 (LLM)을 엔터프라이즈 환경에 통합할 때 발생하는 파편화된 보안 가이드라인, 독점적 도구, 그리고 일관되지 않은 제어 (Controls) 문제를 강조합니다.

공유 프레임워크와 개방형 표준이 이러한 격차를 메우기 시작했습니다. 하지만 실제 작업은 여전히 실제 데이터 흐름을 설계하는 아키텍트와 엔지니어들의 몫입니다.

AI에 대해 기존 제로 트러스트가 부족한 이유

전통적인 인프라에서는 경계를 보호하고 애플리케이션 계층에서 신원 (Identity)을 강제하는 것만으로도 충분한 경우가 많았습니다. 일단 트래픽이 네트워크 내부로 들어오고 인증을 거치면, 대체로 신뢰할 수 있는 것으로 간주되었습니다.

생성형 AI (Generative AI)는 이 모델을 깨뜨립니다.

LLM은 본질적으로 사용자 권한을 이해하지 못합니다. 만약 대규모 기업 지식 베이스를 LLM에 입력하면, LLM은 요청한 사용자가 해당 데이터를 볼 권한이 있는지 여부가 아니라 의미론적 유사성 (Semantic similarity)을 기반으로 정보를 노출할 것입니다.

이는 근본적인 변화를 야기합니다. 권한 부여 (Authorization)는 더 이상 애플리케이션이나 네트워크 계층에서만 이루어질 수 없습니다. 반드시 AI 파이프라인 내부에서 강제되어야 합니다.

핵심 공격 표면: AI 데이터 파이프라인

대부분의 엔터프라이즈 AI 시스템은 유사한 흐름을 따릅니다:

1. 데이터 수집 (Data ingestion) 및 청킹 (Chunking)
2. 임베딩 (Embedding) 생성
3. 벡터 데이터베이스 (Vector database)에 저장
4. 검색 (Retrieval, 의미론적 검색)
5. 컨텍스트 조립 (Context assembly)
6. LLM에 의한 생성 (Generation)
7. 사용자로의 출력 (Output)

모든 단계에서 잠재적인 보안 리스크가 발생합니다:

• 분류 (Classification) 없이 임베딩 공간 (Embedding space)으로 유입되는 민감한 데이터
• 사용자가 접근해서는 안 되는 문서에 대한 제한 없는 검색
• 검색된 컨텍스트를 통해 유입되는 프롬프트 인젝션 (Prompt injection, RAG poisoning)
• 민감한 정보나 승인되지 않은 권장 사항을 포함하는 모델 출력

전통적인 방화벽과 네트워크 세분화 (Network segmentation)는 의미론적 의도 (Semantic intent)를 검사할 수 없습니다. 따라서 보안 제어는 파이프라인 자체 내부로 이동해야 합니다.

제로 트러스트 (Zero Trust) 제어의 실무적 구현

1. ID 인식 검색 (벡터 레이어에서의 RBAC)

프롬프트가 언어 모델 (Language model)에 도달하기 전에, 검색 (Retrieval) 단계가 반드시 제한되어야 합니다.

벡터 데이터베이스 (Vector database)에 저장된 모든 문서 청크 (Document chunk)는 해당 정보에 접근할 수 있는 권한이 있는 사람(역할, 부서, 보안 등급 등)을 설명하는 메타데이터 (Metadata)를 포함해야 합니다. 사용자가 쿼리 (Query)를 실행하면, 검색 시스템은 컨텍스트 윈도우 (Context window)를 구성하기 전에 인증된 ID를 기반으로 결과를 필터링해야 합니다.

이는 가장 중요한 제어 항목 중 하나입니다. 이것이 없다면, 모델은 사용자가 결코 봐서는 안 될 정보를 노출할 수 있습니다.

2. 임베딩 (Embedding) 전 데이터 정화 및 분류

민감한 데이터는 검증되지 않은 상태로 임베딩 공간 (Embedding space)에 진입해서는 안 됩니다.

다음 사항을 포함하는 다단계 인제스션 (Ingestion) 파이프라인을 구현하십시오:

• 콘텐츠 분류 (예: 개인정보(PII), 기밀, 공개)
• 적절한 경우 고위험 데이터의 정화 (Sanitization)
• 추후 접근 제어를 위한 메타데이터 태깅 (Metadata tagging)
• 매우 민감한 콘텐츠에 대한 휴먼 인 더 루프 (Human-in-the-loop) 검토

도구와 접근 방식은 단순한 정규 표현식 (Regex) 및 개체명 인식 (Named Entity Recognition) 모델부터 더 발전된 분류 파이프라인까지 다양할 수 있습니다.

3. 컨텍스트 윈도우 권한 부여 (Context Window Authorization)

권한 부여는 생성 (Generation) 이전에 이루어져야 합니다.

시스템이 관련 청크를 검색할 때, 현재 사용자가 접근할 수 있도록 허용된 청크만을 반환해야 합니다. 언어 모델은 특정 ID에 대해 처리하도록 허용되지 않은 컨텍스트를 절대로 받아서는 안 됩니다.

이는 전통적인 애플리케이션과의 결정적인 차이점입니다. 모델 자체가 권한 부여 경계 (Authorization boundary)의 일부가 됩니다.

4. 출력 가드레일 (Output Guardrails) 및 실행 제어

강력한 입력 및 검색 제어가 있더라도, 모델의 출력은 여전히 문제가 될 수 있습니다.

사용자에게 반환되기 전에 생성된 응답을 검사하는 런타임 가드레일 (Runtime Guardrails)을 배포하십시오. 여기에는 다음 사항이 포함될 수 있습니다:

• 민감한 데이터 유출 탐지
• 정책 기반 필터링 (Policy-based filtering)
• 승인되지 않은 작업 차단 (특히 에이전트 시스템 (Agentic systems)에서)

Amazon Bedrock Guardrails 또는 커스텀 중간 서비스 (Custom intermediary services)가 여기서 실용적인 옵션입니다.

5. 파이프라인 구성 요소의 격리 (Isolation of Pipeline Components)

가능한 경우, 파이프라인의 서로 다른 단계들을 격리하십시오:

• 임베딩 모델 (Embedding models)을 생성 모델 (Generation models)로부터 분리
• 검색 (Retrieval)과 생성 (Generation)을 서로 다른 보안 컨텍스트 (Security contexts)에서 실행
• 모든 에이전트 또는 도구 호출 (Tool-calling) 구성 요소의 권한 제한

오픈 표준 (Open Standards)이 중요한 이유

현재 AI 보안의 지형은 여전히 파편화되어 있습니다. 서로 다른 벤더들이 서로 다른 도구, 서로 다른 가이드라인, 그리고 서로 다른 수준의 투명성을 제공합니다.

Open Secure AI Alliance와 같은 오픈 이니셔티브는 NIST AI 위험 관리 프레임워크 (NIST AI Risk Management Framework) 및 LLM 애플리케이션을 위한 OWASP Top 10과 같은 프레임워크와 결합되어, 더욱 일관된 구현을 위한 토대를 제공합니다.

표준화가 신중한 아키텍처 설계의 필요성을 없애주는 것은 아닙니다. 다만, 사후에 보안을 적용하는 것이 아니라 기본적으로 안전한 (Secure by default) 시스템을 설계하기 더 쉽게 만들어 줄 뿐입니다.

결론

AI가 비즈니스 핵심 워크플로우의 일부가 됨에 따라, 보안은 더 이상 네트워크 경계에서 멈출 수 없습니다.

제로 트러스트 (Zero Trust)는 데이터 수집 (Data ingestion)부터 검색 및 생성에 이르기까지 전체 파이프라인에 걸쳐 적용되어야 합니다. ID 인식 검색 (Identity-aware retrieval), 강력한 데이터 분류 (Data classification), 컨텍스트 권한 부여 (Context authorization), 그리고 출력 가드레일 (Output guardrails)은 더 이상 선택 사항이 아닙니다.

목표는 취약점을 지속적으로 패치하는 것에서 시작부터 안전한 데이터 흐름을 설계하는 것으로 이동하고 있습니다.

오픈 표준과 공유 프레임워크는 이를 대규모로 실용화하는 데 중요한 역할을 할 것입니다. TLS가 웹 트래픽에 있어 타협할 수 없는 요소가 된 것처럼, AI 파이프라인을 위한 오픈 보안 표준은 엔터프라이즈 배포를 위한 기본 요구 사항이 될 가능성이 높습니다.

AI 보안을 도구(tooling)의 문제라기보다 아키텍처(architectural)의 문제로 취급하는 조직들이 이러한 시스템을 확신을 가지고 배포할 수 있는 조직이 될 것입니다.

출처:

NVIDIA Blog: Open Secure AI Alliance: https://blogs.nvidia.com/blog/open-secure-ai-alliance/

NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework

OWASP Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/