RAG LLM Application 보안 - 데이터 보호

데이터 보호는 저장 중이거나 전송 중인 데이터의 기밀성, 무결성, 가용성을 보장하고, 민감 정보의 유출을 방지하는 것을 의미합니다. RAG LLM 시스템에서는 프롬프트/응답 내용, 벡터 DB의 지식베이스, 대화 기록, 사용자 개인정보 등이 모두 보호 대상입니다. 제로 트러스트 환경에서는 내부 네트워크도 불신해야 하므로, 데이터는 항상 암호화하고 접근을 엄격히 통제해야 합니다 . 또한 AI 서비스 특성상 훈련 데이터 및 모델 자산 보호도 중요한 부분입니다 (모델 유출 방지 등).

 

위협 (STRIDE)

• 스푸핑: (데이터 측면에서는 주로 무결성 관련 이슈) 공격자가 데이터 접근 권한을 위조하여 무단으로 데이터에 접근하거나 변조할 수 있습니다. 예를 들어 API 요청에 위조된 자격증명을 포함해 저장된 벡터 임베딩에 접근한다면 허가 없는 데이터 열람이 가능합니다.
• 변조(Tampering): 전송 중 데이터나 저장된 데이터가 무단 변경될 수 있습니다. 암호화되지 않은 채널로 LLM 프롬프트 컨텍스트를 전송하면 MITM 공격으로 내용이 조작될 수 있습니다. 저장 데이터의 무결성 검증이 없다면 공격자가 지식베이스 문서를 조작(데이터 포이즈닝)하여 잘못된 답변을 유도할 수도 있습니다  .
• 부인: 적절한 로그나 무결성 검증이 없다면, 데이터 조작 또는 삭제에 대한 사후 부인을 막기 어렵습니다. 예를 들어 어느 사용자가 의도적으로 지식베이스 일부를 삭제했는데 로그가 없다면 이를 부인할 수 있습니다.
• 정보 노출(Information Disclosure): 암호화 미비 또는 잘못된 접근통제로 인해 민감 정보가 유출될 수 있습니다. 예를 들어 데이터베이스 암호화를 사용하지 않아 내부자나 침입자가 평문으로 데이터를 가져갈 수 있고, S3 버킷 설정 잘못으로 전체 공개되어 대화 로그가 인터넷에 유출되는 사고가 있을 수 있습니다. 또한 LLM 응답을 통해서도 민감정보가 노출될 수 있는데, 모델이 보유한 고객정보를 잘못 응답하는 경우가 이에 해당합니다  .
• 서비스 거부(Denial of Service): 데이터 보안과 직접 연관되진 않지만, 랜섬웨어나 대용량 입력으로 데이터 저장소를 인질로 삼거나 과부하를 줄 수 있습니다. 예컨대 벡터DB에 과도한 임베딩을 저장해 질의를 느리게 만들거나, KMS 한도를 초과해 암호화 연산 실패로 서비스 이용이 지연될 수 있습니다.
• 권한 상승(Elevation of Privilege): 낮은 권한의 사용자가 암호화 키나 백업 데이터에 접근하면, 더 높은 수준의 데이터에 접근하는 효과를 얻습니다. 키 관리 실수로 전체 데이터를 복호화할 수 있는 키에 접근하게 되는 경우가 대표적입니다.

 

보안 요구사항 및 대응

• 전송 중 암호화: 모든 서비스 간 통신과 클라이언트-서버 간 트래픽은 TLS 1.2 이상으로 암호화해야 합니다. 예를 들어, 프런트엔드와 API 게이트웨이 간 HTTPS는 물론이고, 내부적으로 Bedrock 호출, OpenSearch 쿼리 등도 PrivateLink 등의 VPC 엔드포인트를 사용하여 사설 경로 + TLS로 전달합니다. NIST 800-207의 권고대로 “모든 트래픽을 가장 안전한 방식으로 통신”해야 하며, 내부망이라도 평문 전달을 지양합니다.
• 저장 시 암호화: 데이터베이스, 파일 스토리지, 로그 등 정적 데이터는 모두 암호화합니다. AWS에서는 AWS KMS 관리 키(CMK)를 사용하여 DynamoDB, Amazon S3, OpenSearch, RDS 등의 암호화를 설정할 수 있습니다. 예를 들어 DynamoDB의 챗봇 대화 기록 테이블을 KMS CMK로 투명암호화하고, S3에 저장된 프롬프트/응답 로그도 버킷 암호화를 켭니다. 키 관리도 중요하여, 누가 어떤 키에 접근권한이 있는지 주기적으로 검토하고 키 로테이션을 정기화합니다 .
• 암호 키 관리: KMS CMK를 사용하면 키에 대한 접근 정책을 별도로 관리할 수 있고, 키 사용 로그를 감사할 수 있습니다  . 키 관리자와 사용자 역할을 분리하고, 하나의 계정이 모든 키를 관리하지 않도록 직무 분리를 적용합니다. 또한 키를 정기적으로 로테이션하여 오래된 키로 인한 위험을 줄입니다.
• 민감정보 식별 및 마스킹: 프롬프트나 응답에 포함될 수 있는 개인식별정보(PII)나 기밀 데이터에 대한 데이터 분류 정책을 수립합니다. 예컨대, 사용자의 질문에 고객 개인정보가 포함되었는지 DLP 검사를 수행하고, 모델 응답에 주민번호번호 등이 있으면 마스킹하거나 차단합니다. LLM 응답 내 민감정보 필터링은 OWASP Top 10의 Sensitive Information Disclosure 대응의 일환이며, 민감 데이터 자체가 아예 모델 학습이나 벡터DB에 저장되지 않도록 입력 단계에서 스크러빙 처리합니다 .
• 백업 및 삭제 보호: 데이터 백업본도 암호화하여 저장하고 접근 통제를 적용합니다. 주기적으로 백업을 취하되, 랜섬웨어 대비 오프라인 사본 또는 WORM(Write Once Read Many) 스토리지 적용을 고려합니다. 또한 사용자 요청시 데이터 삭제(예: 개인정보 삭제 요청)가 정확히 이행되도록 프로세스를 갖추고, 삭제 이벤트를 로깅하여 추적 가능하게 합니다.
• 데이터 무결성 검증: LLM의 지식 소스로 사용되는 데이터(예: 사내 문서, 위키 등)가 변조되지 않도록 무결성 해시나 서명 검증을 고려합니다. 중요한 데이터셋에는 파일 해시를 저장하고 정기적으로 대조하거나, Git과 같은 형상관리로 변경 시 추적하도록 합니다. 또한 전송 중 데이터에 대한 무결성 보호를 위해 메시지 해시/HMAC 등을 활용하거나 TLS 외에 응용계층에서 추가 검증을 시행합니다  .

 

OWASP LLM Top 10 대응

LLM06: Sensitive Information Disclosure

• 민감 정보 노출 위험으로, LLM 응답이나 취약한 저장소를 통해 개인정보나 기밀정보가 새어나갈 수 있습니다 . 
• 대응: 애플리케이션 설계단에서 민감정보가 LLM에 학습/입력되지 않도록 차단하고 , 모델 출력에는 비식별화 혹은 필터링을 적용합니다. 또한 국제적으로 LLM 구축 시 데이터 주권 문제가 있으므로 **데이터 지역성(data localization)**을 지키도록 지역별 격리도 고려해야 합니다 . 예를 들어 유럽 사용자 데이터는 EU 지역 서버에서 벡터DB를 운영하고, 해당 데이터는 EU내에서만 모델에 제공되도록 합니다.

LLM05: Supply Chain Vulnerabilities 

• 공급망 취약점은 LLM 서비스 구성요소(모델, 라이브러리, 데이터셋, 플러그인 등) 자체에 대한 신뢰성 문제입니다 . 데이터 측면에서는 외부에서 얻은 프리트레인 모델이나 학습데이터셋이 악성일 수 있는 위험을 뜻합니다. 
• 대응: 공급망 위험을 줄이기 위해 모델과 데이터의 출처를 검증하고 , 서드파티 데이터 세트는 샘플 검증 및 스캔을 실시합니다. 예를 들어 벡터DB에 삽입되는 문서는 안티바이러스/악성코드 스캔, 금칙어 필터링 등을 통과한 것만 반영합니다. 또한 오픈소스 라이브러리의 취약점(CVE)을 지속 모니터링하고 주기적으로 업데이트하여, 의존성 하위에 백도어가 숨어있지 않도록 관리합니다.

LLM10: Model Theft 

• 모델 탈취 역시 데이터 유출의 일종입니다. 공격자가 모델 파일에 무단 접근하면 훈련데이터에 내재된 정보까지 추출할 수 있습니다. 
• 대응: 모델 파일(파인튜닝한 모델 가중치 등)이 저장된 스토리지를 암호화하고 접근을 엄격히 제한합니다. 또한 LLM API를 호출할 때 유출 위험을 줄이도록 요청/응답에 포함된 내부 정보 최소화, API 남용 방지(rate limiting) 등을 적용합니다. 예를 들어 모델 자체를 추출하려는 대량 쿼리를 감지하여 차단하고 CloudTrail로 감사합니다.

LLM03: Training Data Poisoning 

• 훈련 데이터 중독은 악의적인 데이터 삽입으로 모델의 출력에 편향이나 오동작을 유발하는 공격입니다 . 이는 RAG 맥락에서는 지식베이스에 잘못된 정보를 심는 것과 유사합니다. 
• 대응: 데이터 투입 시 검증 파이프라인을 구축하여 이상값 탐지, 출처 신뢰성 평가를 수행합니다. 또한 훈련 파이프라인에 대한 접근 통제를 강화하고, 모델 업데이트 시 변화 감지를 통해 성능 저하나 이상 징후를 발견하면 롤백합니다.

 

NIST SP 800-207 지침

제로 트러스트 아키텍처는 내부망도 안전하지 않다고 가정하므로, 평문 데이터 전송이나 약한 보안을 허용하지 않습니다. 문서에서는 “자산은 항상 공격자가 있는 것으로 간주하고 가능한 가장 안전한 방식으로 통신해야 한다”고 명시하며, 이를 위한 예로 모든 연결 인증 및 모든 트래픽 암호화를 들고 있습니다. 또한 “모든 자원 요청은 인증·인가되어야 하고, 모든 통신은 기밀성과 무결성을 보장해야 한다”고 강조합니다. 이는 데이터 보호에 있어 엔드투엔드 암호화와 무결성 검증이 필수임을 의미합니다. 더불어, 제로 트러스트는 데이터 자체를 보호하는 것(암호화, DLP 등)을 중시하므로, 설령 공격자가 네트워크에 침투하더라도 데이터 평문을 얻기 어렵게 만들어야 합니다.

 

NIST AI RMF 지침

AI RMF의 Secure and Resilient 항목은 “대규모 언어 모델 시스템의 보안 우려로 적대적 예시, 데이터 중독, 모델/데이터 유출이 있다”고 지적합니다 . 따라서 AI 체계에서는 훈련데이터와 모델 자산이 유출되지 않도록 보호하고, 데이터 무결성을 해치는 시도를 막는 것이 중요합니다. AI RMF는 AI 시스템이 CIA(trustworthiness)를 유지하며 허가되지 않은 접근을 방지해야 한다고 명시하여, 데이터 보호와 접근통제가 AI 위험 완화의 기본임을 보여줍니다. 또한 프라이버시 강화도 언급되므로, 개인정보처리 측면에서 암호화, 가명처리 등 프라이버시 보호기술을 도입하는 것이 권장됩니다. LLM의 경우 입력 데이터와 응답에 개인정보가 섞일 가능성이 높으므로, 프라이버시 리스크 평가와 보호 대책이 데이터 보호 도메인의 핵심 과제로 포함됩니다.

 

체크 항목	보안 요구사항 및 베스트 프랙티스
전송 암호화(TLS)	내부서비스 간 호출, 외부 API 호출 등 모든 트래픽에 TLS/HTTPS가 적용되었는가? (인증서 관리 상태와 유효성 점검 등)
저장 암호화	데이터베이스, 파일시스템, S3 등의 암호화 at rest가 활성화되었는가? (KMS CMK 등 키 관리 사용 여부 등)
키 관리 및 접근	암호키(KMS CMK 등)에 대한 접근권한이 최소화/분리되어 있는가? (키 로테이션 주기 및 관리 절차 존재 여부 등)
민감 데이터 식별	시스템이 처리하는 민감정보(PII 등)를 파악하고 있는가? 해당 데이터에 마스킹, 토큰화 등의 조치가 적용되는가?
백업 및 복구	중요한 데이터에 대해 정기 백업과 오프사이트 보관이 이루어지는가? 백업 데이터 역시 암호화되고 접근통제되는가?
데이터 수명주기 관리	불필요한 데이터는 파기하고 있는가? 사용자 요청시 데이터 삭제/정정이 적시에 수행되고 로그로 증빙되는가?
지식베이스 무결성	RAG용 지식 문서 저장소(OpenSearch 등)에 무결성 검증 또는 승인 프로세스가 있는가? 임의 문서 추가로 인한 데이터 중독 방지 대책이 있는가?
공급망 보안	외부에서 도입한 모델/데이터/라이브러리에 대한 신뢰 검증을 했는가? (서드파티 구성요소의 보안 업데이트 정책 등)
로그 민감정보 보호	로그에 민감정보 또는 암호화되지 않은 데이터가 기록되지 않는가? (예: 비밀번호 평문 노출, 신용카드 번호 등) 필요시 마스킹 처리하는가?