Q> RAG(Retrieval Augmented Generation, 검색 증강 생성) 시스템 구축시 위험요소와 고려해야 하는 보안
RAG 개요
* RAG는 GenAI(LLM)을 구축할때, PEFT와 함께 필수 요소로 사용되고 있다.
* RAG는 표준 LLM 시스템의 한계를 극복하기 위해 개발된 기술로써, 사용자의 질문에 대한 답변을 제공할 때, 문서들을 검색하여 LLM이 그 문서를 기반으로 정확한 답변을 생성하도록 돕는 기능을 제공한다.
* ChatGPT의 사용자라면 자료검색을 요청할때 화면에서 모레시계가 나타나면서 웹 검색하는 순간을 봤을 것이다. 이 기능을 제공하는 것이 RAG이다.
* 또한, 예를 들어서 계열사들의 상품정보에 해당하는 문서들을 수집하여 사용자에게 적합한 상품정보를 즉각적으로 제공하는 등의 기능을 제공한다.
* 특히, 특정 도메인이나 최신 정보에 대한 답변을 정확히 할 수 있도록 도와줌으로써 GenAI(LLM) Application에서 중요한 역할을 담당한다.
RAG 구축의 잇점
* RAG의 아키텍처와 workflow를 이해한다면 RAG를 이용하여 GENSI(LLM)서비스 제공시 민감한 데이터를 안전하게 저장할 수 있는 잇점이 있다는 것을 알수 있을 것이다. 이 부분이 보안통제를 적용하여 컴플라이언스에 대응할 수 있는 중요한 포인트가 된다.
* OpenAI와 같은 AI서비스는 다양한 RAG agent들을 구성하고 있으며 이 업계들은 GenAI(LLM)서비스에서 RAG의 중요성을 인정하고 있다.
* RAG는 LLM의 매개변수에 있는 것 보다 월씬 더 많은 외부의 Knowlege Source들을 활용하여 서비스 함으로써 응답서비스의 품질을 높일 수 있게 되었다.
* RAG를 활용함으로써 사실적이고 최신의 정확한 정보를 제공함으로써 Hallucination을 감소시킬수 있다는 연구결과가 있다.
* 외부의 다양한 지식소스를 이용함으로써 새로운 정보를 손쉽게 통합하여 서비스할 수 있는 강점을 가지게 된다.
* 대상이나 목적에 맞게 다양한 RAG Agent를 활용함으로써 대규모 지식을 효울적으로 쉽게 확장할 수 있는 장점을 갖게 된다.
* LLM을 변경하지 않고도 검색과 같은 구성요소를 통해 GenaI서비스의 품질을 지속적으로 개선할 수 있게 된다.
RAG 아키텍처와 구성요소
* RAG 시스템은 쿼리에 대한 상황별 응답을 제공하기 위해 함께 작동하는 기존의 전통적 GenAI과 Search기능을 결합하기 위해 다양한 기술 요소들이 구성되며, RAG아키텍처의 이해를 돕기 위한 몇 가지 그림들을 보면 아래와 같다.
* 목적에 따라 여러 가지 종류의 아키텍처 설명이 있지만 일반적 RAG 아키텍처는 3-티어(Knowlege Source/Vector Database, Retriever, Generator)로 구성된다.
Knowlege Source/Vector Database(Documents/Databases, Indexing, Embedding Generation, Vector Database) ↔ Retriever(Fectch Relevant Contect) ↔ Generator(GEN, LLM, GPT, Claud)
* RAG 아키텍처 상의 workflow를 살펴보면, 1) Knowlege Source가 인덱싱되고 벡터임베딩이 생성된 다음 데이터베이스에 저장된다. 2) 쿼리의 경우 검색기는 의미검색 및 ANN을 사용하여 데이터베이스에서 가장 관련성이 높은 콘텍스트를 찾아낸다. 3) 이 컨텍스트는 사용자의 응답을 생성하는 LLM으로 이용한다.
* Tier-1: Knowlege Source/Vector Database
- Knowlege Source: RAG시스템의 필수 요소로써, 포괄적인 지식 기반을 집합적으로 형성하는 텍스트 문서, 데이터베이스 및 지식 그래프로 구성된다.
- Indexing/Embedding Generation: Knowlege Source의 정보를 손쉽게 검색할 수 있도록 정보를 분류하고 색인을 생성하는 등의 작업이 이뤄지는 컴포넌트이다.
- Vector Database: 생성된 임베딩은 벡터 데이터에 최적화된 Vector Database에 저장됨으로써 유사성을 기반으로 효율적인 검색을 가능하도록 해준다.
* Tier-2: Retriever
- Retriever는 의미론적 검색과 ANN(Approximous Nearest Neighbors)을 사용하여 주어진 쿼리 또는 프롬프트에 대해 벡터 데이터베이스에서 상황에 맞는 관련 데이터를 가져오는 역할을 하며 키워드 이상의 정보를 검색하기 위해 쿼리의 의미를 이해하는 기능을 수행한다.
- Retriever는 RAG시스템 전체 성능을 좌지우지할 수 있는 중요한 역할을 하기 때문에 Multi-query Retriever, Parent-Document Retriever, Self-query Retriever, Time-weighted Retriever등 다양한 기법들이 사용되고 있다.
* Tier-3: Generator
- Generator는 GPT, LLam, Claud와 같은 LLM 모델로써, 오픈소스들로 구성된다. 검색기에서 컨텍스트를 가져와 일관되고 관련성 높은 응답을 생성 및 선별하여 사용자 또는 시스템에게 제공하는 역할을 한다. 대부분 LLM에서 제공하는 API를 통해 접근하게 된다.
RAG는 GenAI(LLM)의 중요한 보안통제의 포인트
* GenAI(LLM) Application의 외부 지식정보를 검색하여 사용자 요청에 응답하는 GenAI(LLM)의 필수적 구성요소로써 자리매김하고 있는 RAG는 위의 아키텍처 구성으로볼때 정보보안과 개인(신용)정보보호를 통제할 수 있는 매우 중요한 통제 포인트로 이용할 수 있다.
* RAG의 정보보안 적용을 통해, 외부 데이터에 대한 데이터 익명화, 벡터데이터베이스에 대한 접근제어 및 암호화, 쿼리에 대한 유효성 검사, 생성된 콘텐츠의 유효성 검사, 출력정보에 대한 접근제어 등을 적용하여 정보보안 및 개인(신용)정보보호 목적을 달성할수 있다.
* GenAI(LLM)보안의 글로벌 표준인 OWASP Top10 for LLM Application에서 언급하고 있는 LLM 01. Prompt Injection, LLM 02. Insecure Output Handling, LLM 03. Training Data Poisoning, LLM 06. Sensitive Information Disclosure 등 거의 모든 취약점 유형이 RAG 시스템 아키텍처와 연관이 있다.
Tier-1: Knowlege Source/Vector Database 위험요소와 보안 요구사항
발생 가능한 위험
- 지식 소스를 저장하는 Vector Database가 변조되거나 손상될 경우, RAG시스템이 부정확한 데이터를 사용하게 되거나 악의적인 검색과 같은 공격으로 이어질수 있다.
- Vector Database에 대한 적절한 접근통제 보안조치가 없으면 악의적인 행위자가 데이터베이스에 액세스하여 데이터의 무결성과 개인 정보 보호를 손상시킬 수 있다.
- 저장된 방대한 양의 지식에는 민감하거나 독점적인 정보가 포함될 수 있으므로 데이터 보호에 대한 조치가 이뤄지지 않을 경우 데이터 침해의 위험성이 존재할수 있다.
- RAG시스템은 Vector Database에 의존하기 때문에 공격자가 의도적으로 Vector Database의 가용성을 저해하는 공격을 할 경우 RAG시스템 전체에 문제를 발생시키게 된다.
보안 요구사항
- Vector Database에 대한 접근제어: 강력한 사용자 인증 및 권한 부여 메커니즘을 구현함으로써 승인된 사용자(직원)만 데이터베이스에 접근할 수 있도록 하고, 접근이 허용된 사용자 그룹 내에서도 역할에 따라 접근 수준을 상세하게 관리할 수 있도록 구별한다.
- 데이터 암호화: 저장되어 있는 데이터와 전송 중인 데이터 모두를 암호화를 적용함으로써 무단 접근이 발생하더라도 데이터를 이해할 수 없는 상태로 유지함으로써 데이터 보호를 달성할 수 있다.
- 모니터링 및 경고: 데이터베이스에서 이뤄지는 모든 작업을 지속적으로 모니터링하면 비정상적인 패턴을 감지할 수 있다. 또한, 실시간 경고를 통해 관리자에게 잠재적인 보안 위반을 알릴 수 있게 된다.
- 백업 및 복구: 정기적인 백업을 통해 데이터가 손상되거나 손실된 경우 지식 소스를 복원할 수 있게 하고 백업 자체를 안전하게 보호하고 정기적으로 무결성을 테스트하는 것이 중요하다.
- 쿼리속도 제한: 리소스 고갈과 잠재적인 서비스 중단을 방지하려면 데이터베이스 쿼리에 속도 제한을 구현하는 것이 좋다. 이를 통해 특정 유형의 서비스 거부 공격을 완화할 수도 있다.
- 데이터 검증 및 삭제: 데이터가 데이터베이스에 수집되기 전에 잠재적인 Injection공격이나 악성데이터가 포함되는 것을 방지하기 위해 데이터를 검증하고 삭제하는 것이 필요하다.
- 정기적인 보안진단: 정기적인 보안 취약점 진단을 통해 취약점을 식별하고 최신 보안 모범 사례를 따르고 있는지 확인함으로써 데이터 보안을 유지할 수 있다.
- 네트워크 보안: 벡터 데이터베이스가 작동하는 네트워크의 안전성 확보를 위해 방화벽, 침입탐지시스템 등을 구축하고 보호된 네트워크 영역에서 데이터베이스를 분리할 필요가 있다.
- 패치관리: 벡터 데이터베이스 제공업체의 최신 패치를 정기적으로 모니터링하여 업데이트 함으로써 알려진 취약점으로부터 벡터데이터베이스를 보호한다.
Tier-2: Retriever 위험요소와 보안 요구사항
발생 가능한 위험
- Prompt Injection 위험: Retriever의 기본적 보안 중 하나는 쿼리 또는 프롬프트 유효성 검사이다. 벡터 데이터베이스에 대한 신속한 주입과 관련된 위험을 완화하는 데 특히 중요하다.
- 기존 데이터베이스를 대상으로 하는 기존 SQL 또는 Command Injection공격과 달리 벡터 데이터베이스의 프롬프트 주입에는 검색쿼리를 조작하여 무단정보 또는 민감한 정보를 검색하는 작업이 포함될수 있다. 각 프롬프트나 쿼리를 처리하기 전에 엄격하게 검증함으로써 시스템은 합법적인 요청만 벡터 데이터베이스에 이루어지도록 보장하여 악의적인 행위자가 검색 프로세스를 악용하는 것을 방지할수 있다.
- 벡터 데이터베이스의 무단 데이터 액세스: 앞에서 이미 설명을 했으나, Retriever Tier에서 벡터 데이터베이스에 대한 무단접근은 RAG시스템 전체에 위험을 초래할 수 있다.
- 벡터 데이터베이스의 유사성 검색 기능과 관련된 위험: 유사성 쿼리를 통한 데이터 유출, 검색 결과 조작, 정찰 및 패턴 분석, 자원 고갈의 위험성이 존재할 수 있다.
보안 요구사항
- 쿼리 유효성 검사 메커니즘 구현: 각 사용자 쿼리를 처리하기 전에 면밀히 조사하는 것으로써 쿼리 유효성 검사의 주요 목적은 시스템 취약점을 악용할 수 있는 잠재적으로 유해하거나 악의적인 쿼리를 필터링하고 조직의 내부 데이터 누출 방지 정책을 위반하는 잠재적인 데이터 누출을 감지하는 것이다.
- 벡터 데이터베이스에 대한 접근제어: 벡터 데이터베이스의 접근제어는 단순한 사용자 인증을 포함하여 누가 어떤 종류의 정보를 검색할 수 있는지 지정하는 포괄적인 권한관리까지 접근제어의 상세화 및 차별화 해야 한다. 사용자의 허가수준이 다르거나 시스템이 다양한 민감도의 데이터를 처리하는 환경에서 필수적이다.
- 정보의 무결성 유지: 벡터 데이터베이스에서 가져온 정보가 검색 중에 변조되지 않도록 보장하는 것이다. 데이터 전송 중에 암호화를 적용함으로써 안전성을 유지할 수 있다.
- 정기적인 감사 및 모니터링: 검색 프로세스에 대한 정기적인 감사 및 모니터링을 통해 처리된 모든 쿼리를 추적하고, 잠재적인 보안 위협을 나타낼 수 있는 패턴을 분석하고, 무단 액세스 시도가 있는지 시스템을 모니터링하는 것이다. 이러한 사전 모니터링은 잠재적인 위협이 시스템 취약성을 악용하기 전에 신속하게 식별하고 완화하는 데 도움이 된다.
Tier-3: Generator 위험요소와 보안 요구사항
발생 가능한 위험
- 오류정보 및 부정확한 콘텐츠: LLM은 실제로 부정확하거나 오해의 소지가 있는 응답을 생성할 수 있다. 이러한 잘못된 응답결과가 잘못되거나 부정확한 의사결정에 사용되거나 더 많은 사용자들에게 정보를 전파하게 되는 위험으로 확산될수 있다.
- 편견 및 공격적인 콘텐츠: 편향된 훈련 데이터 또는 쿼리 자체의 특성으로 인해 LLM이 편견 또는 공격적인 콘텐츠를 생성할 위험이 내재되어 있다. 이는 특히 콘텐츠가 차별적이거나 콘텐츠 표준을 위반하는 경우 명예 훼손 및 법적 책임으로 이어질 수도 있다.
- 데이터 개인정보보호 위반: LLM은 민감한 정보를 포함하거나 추론하는 응답을 실수로 생성하여 데이터 개인정보보호 위반으로 이어질 수 있다. 특히 모델이 민감한 훈련데이터에 노출된 경우 더욱 그럴수 있다.
- 출력 조작: 공격자가 LLM에 악영향을 주어 조작된 쿼리를 통해 또는 모델의 약점을 악용하여 특정 응답을 생성하는 외부 조작의 위험이 있을 수 있다.
- 자동화 및 반복 작업 취약성: LLM이 AutoGPT, BabyAGI 또는 OpenAI Assistant API와 같은 Agentic 도구 사용과 같은 자동화된 작업에 사용되는 경우 반복적이거나 예측 가능한 응답이 악의적으로 사용될 수 있는 악용에 취약할 수 있다.
보안 요구사항
- 생성된 콘텐츠의 유효성 검사: 오해의 소지가 있거나 공격적이거나 부적절한 콘텐츠를 식별하고 필터링하기 위해 LLM이 생성한 응답을 면밀히 조사하는 것이다. 특히 정보가 널리 전파되거나 중요한 의사 결정에 사용되는 경우에는 생성된 콘텐츠에 대한 유효성 감사는 필수적인 보호장치이다.
- 생성된 콘텐츠의 무결성 검사: LLM의 응답이 제공된 컨텍스트와 일치하는지 확인하여 모델이 관련이 없거나 민감한 주제로 전환되는 것을 방지해야 한다. 이 것은 응답의 관련성과 적절성을 유지하는 데 특히 중요하다.
- 훈련 데이터 보호: 비즈니스 요구사항으로 인해 RAG 시스템에 Fine-tuning이 관련된 경우 LLM에 사용되는 훈련데이터에 특별한 주의가 기울여한다. 훈련 데이터가 완전히 익명화되도록 보장함으로써 모델이 실수로 민감한 정보를 포함하거나 추론하는 응답을 생성할 위험을 줄일수 있고 개인정보 침해를 방지하기 위한 사전조치가 된다.
- LLM에 입력된 쿼리와 입력을 모니터링: 조작된 쿼리를 통하거나 모델 약점을 악용하여 출력을 조작하려는 시도를 탐지하는 것으로써, 입력 및 프롬프트에 민감한 데이터가 포함되어 있지 않은지 확인하기 위해 데이터 손실을 방지하는 메커니즘을 적용하는 것이다.
- 미세 조정 중 편향 완화: 미세 조정을 위한 다양하고 대표적인 데이터 세트를 보장하면 편향을 상당히 줄일 수 있습니다. 단어 임베딩 편향성 제거와 같은 기술은 모델의 중립성을 더욱 구체화할 수 있습니다.
- Fine-tuning 중 인간 참여형 평가: Fine-tuning 단계에서 인간 평가자는 모델이 윤리적 및 품질 벤치마크와 일치하는지 확인하기 위해 귀중한 통찰력과 미묘한 판단을 제공하는 것을 고려할 수 있다.
- 콘텐츠 조정: 출력 생성 중에 허용 목록 및 차단 목록을 구현하면 미리 정의된 기준에 따라 콘텐츠를 정렬할 수 있는 강력한 메커니즘을 구현하는 것을 고려할 수 있다.
- Fine-tuning 중 데이터 개인정보보호: 모델을 Fine-tuning하는 동안 개인정보보호 및 데이터 익명화와 같은 모범사례를 통합하는 것을 고려할 수 있다.
- 포괄적인 모델 평가: Fine-tuning이 완료되면 모델은 성능, 안전 및 품질 표준에 대한 철저한 평가를 거치도록 조직적 역할(R&R)과 정책 같은 관리체계 수립을 고려할 수 있다.
- 안전한 API 앤드포인트: 항상 API 엔드포인트에 HTTPS를 활용하여 암호화된 데이터 전송을 보장하고 도청 공격으로부터 보호한다.
- API 속도 제한: DDoS 공격을 방어하고 중단 없는 서비스 가용성을 보장하기 위해 속도 제한을 설정하는 것을 고려한다.
- 인증 및 권한 부여: OAuth 2.0, JWT 등과 같은 강력한 인증 메커니즘을 채택하고 세분화된 권한통제와 결합하여 사용자 또는 시스템이 허용된 리소스에만 액세스하도록 보장해야 한다.
- API 입력 및 출력 검증: OWASP Top 10에서 두드러진 우려 사항인 Injection 공격으로부터 보호하려면 모든 API 입력을 엄격하게 검증하고 삭제하는 것은 기본적 보안요구사항이다. 특히 LLM 모델에 대한 입력이 자연어 입력이므로 입력검증에 어려움이 존재하지만 지속적인 공격기법에 대한 모니터링과 방어가 필요하다.
- 안전한 오류 처리: 각종 오류 메시지는 공격자에게 공격을 지속할수 있는 힌트를 주는 것과 같다. 민감한 정보를 공개하지 않도록 설계하여 정보 유출 위험을 줄여야 한다.
- 정기적인 업데이트와 패치: API 제공업체의 제공하는 최신 패치를 정기적으로 확인고 적용함으로써 알려진 보안취약점으로부터 보호해야 한다.
- API 로깅 및 모니터링: API 액세스에 대한 자세한 로그를 유지하고 의심스러운 활동에 대한 경고와 함께 실시간 모니터링을 설정한다.
- API 종속성 검토: SBOM과 오픈소스에 대한 취약점 점검은 필수요소다. 특히, ML-SBOM은 일반적인 SW SBOM과는 생성주기가 다르기 때문에, 다양한 ML을 사용하는 API에 사용된 모든 타사 라이브러리 또는 종속성에 알려진 취약점이 없는지 정기적으로 확인해야 한다.
당사의 GenAI(LLM) Red Team 서비스 요약
당사가 제공하는 GenAI(LLM) Red Team 서비스 내용을 요약하면 아래와 같다.
* GenAI(LLM) Red Team이란?
- LLM 및 RAG 등 GenAI(LLM)서비스의 보안과 관련된 취약점을 찾아내고 테스트하는 팀을 의미한다. LLM Red Team은 사이버보안에서 모의공격을 수행하여 LLM Service의 취약점을 식별하고 개선방안을 제안하는 업무를 수행한다.
* GenAI(LLM) Red Team Activity
- RAG, LLM Application 모의해킹 진단 (LLM특화 Pentest, 취약점 식별, 보안강화방안 제시)
- ML-SBOM(AI-SBOM) 생성 및 취약점 스캔(필요시)
- LLM Goverance 및 관리체계(정책, 지침) 수립(필요시)
* GenAI(LLM) Red Team 서비스 기대효과
- 글로벌 보안평가 항목을 기반으로 기업이나 기관에서 개발(또는 운영)중인 LLM Servcie의 보안 취약성을 점검하여 보안성 및 개인(신용)정보보호를 강화
* 기법 및 Tool
- LLM 취약점 스캐너 (자사 자동화 도구)
- ML(AI)-SBOM Generator (자사 자동화 도구)
- LLM 정책지침 및 거버넌스 수립 컨설팅
- 컨설턴트의 경험과 노하우 기반의 수작업 진단
* 수행 결과물
- LLM 모의해킹 진단 결과서
- ML(AI)-SBOM 및 취약점 결과서
- LLM 거버넌스 수립 결과서(필요시)
- LLM Application 취약점 진단 결과 보고서(필요시)
