RAG LLM Application 보안 - 애플리케이션 보안

애플리케이션 보안은 LLM 애플리케이션 자체의 코드 및 운영 상 취약점을 식별하고 제거하는 영역입니다. RAG LLM 앱은 일반 웹/모바일 애플리케이션의 취약점에 더해 프롬프트 기반의 새로운 공격 벡터를 갖습니다. 예를 들어 프롬프트 인젝션을 통해 LLM의 의도치 않은 동작을 유발하거나, LLM이 생성한 출력을 악용하는 다운스트림 공격이 존재합니다. 따라서 전통적인 OWASP Top 10 웹 취약점 (XSS, SQL Injection 등)과 OWASP LLM Top 10에 나온 취약점 모두에 대비한 설계가 필요합니다.

 

위협 (STRIDE)

• 스푸핑: 공격자가 애플리케이션의 합법적 부분(예: 다른 사용자나 서비스)인 것처럼 위장하여 악성 입력을 주입하거나 응답을 가로챌 수 있습니다. (예: 프롬프트에 시스템 메시지를 가장한 텍스트를 삽입해 LLM이 잘못 인식하도록 하는 공격)
• 변조(Tampering): 애플리케이션 입력 또는 상태를 조작하여 권한 밖 행동을 유발합니다. 프론트엔드에서 기본 프롬프트 템플릿을 변조하거나, 요청 JSON에 추가 필드를 삽입해 일반 사용자가 관리자 기능을 호출하도록 시도하는 경우 등이 해당됩니다. 내부적으로는 Injection 취약점이 변조를 일으키는 대표적 수단입니다  .
• 부인: 애플리케이션이 발생시키는 보안 이벤트(예: 거부 리스트 차단 등)에 대한 로깅이 없으면 사후에 공격자가 “의도치 않은 기능”이라고 주장할 수 있습니다. 또한 LLM 응답의 부정확성으로 인한 문제 발생 시 책임 논의가 복잡해질 수 있으므로, 애플리케이션 레벨에서 추론 과정을 일정 부분 기록하고 있어야 합니다.
• 정보 노출: 에러 메시지나 디버그 출력에 시스템 정보가 노출되거나, LLM 응답에 내부 경로, API 키 등이 포함되는 경우입니다. 특히 Insecure Output Handling 이슈로, LLM이 생성한 출력이 곧바로 브라우저로 전달될 때 XSS 취약점이 될 수 있습니다 . 또 프롬프트 내 포함된 기밀이 응답으로 드러나거나, 로그에 민감정보가 찍히는 것도 해당됩니다.
• 서비스 거부: LLM 특유의 자원 소모형 요청으로 인한 모델 서비스의 과부하가 발생할 수 있습니다. 예를 들어, 한 사용자가 비정상적으로 긴 프롬프트나 반복 API 호출로 모델 인퍼런스를 지연시키면, 다른 사용자도 응답 지연이나 실패를 겪게 됩니다 (LLM04: 모델 DoS 공격). 또한 정교하지 못한 입력 처리로 재귀 호출이나 대량 데이터 로딩이 일어나 애플리케이션이 뻗을 수 있습니다.
• 권한 상승: 애플리케이션 보안 결함으로 공격자가 시스템 명령 실행 등 애플리케이션 이상의 권한을 획득할 수 있습니다. 예를 들어, LLM에 플러그인으로 연계된 기능에서 명령 인젝션이 발생하면 호스트 OS 명령을 실행해 서버 권한을 탈취할 수 있습니다. (LLM07 플러그인 설계 미비 시나리오에 포함 )

 

보안 요구사항 및 대응

• 입력 밸리데이션 및 인코딩: 신뢰할 수 없는 모든 입력은 검증 또는 인코딩 후 사용해야 합니다. 여기에는 최종 사용자 입력뿐 아니라, 외부 데이터소스(OpenSearch 결과 등)나 LLM의 출력조차 포함됩니다.
• 사용자 프롬프트에 대해 허용 문자셋, 최대 길이 등을 제한하고 특수 명령어나 코드 조각은 제거/이스케이프합니다. 예를 들어 프롬프트에 <script> 태그 등이 들어와도 그대로 LLM 응답에 반영되지 않도록 필터링합니다.
• OpenSearch나 DB에서 가져온 컨텍스트 데이터에도 예상치 못한 내용(예: system:으로 시작하는 프롬프트 등)이 있을 수 있으므로 클린징을 거칩니다. 이는 간접 프롬프트 인젝션(indirect prompt injection) 대응으로, 지식베이스에 삽입된 악성 콘텐츠가 LLM에 주입되지 않게 하는 절차입니다.
• LLM이 생성한 응답을 최종 사용자가 볼 때 출력 인코딩/필터링을 합니다. 만약 LLM 응답에 <script>alert('xss')</script> 같은 문자열이 포함됐어도 이를 무해화(escape)하여 XSS가 실행되지 않도록 합니다 .
• 일반적인 웹 입력에 대한 검사(숫자형 필드에 숫자만, 문자열 예상 길이 등)도 수행하고, 서버단에서 재검증하여 신뢰도를 높입니다. 이러한 다중 계층 검증으로 Injection 공격 면을 줄입니다.
• 보안 라이브러리 활용: 암호화, 인코딩, 인증 등 보안 기능을 직접 구현하기보다 검증된 프레임워크를 사용합니다. 예를 들어 SQL 쿼리에는 ORM이나 Prepared Statement를 사용하여 SQL Injection을 예방하고, HTML 생성에는 템플릿 엔진의 이스케이프 기능을 활용합니다. LLM 프롬프트에 특수 제어 시퀀스가 필요하면 Bedrock 등의 Guardrails 기능을 사용해 안전하게 처리합니다 .
• 아웃풋 검증 및 신뢰경계 분리: LLM의 응답은 신뢰할 수 없는 출력으로 간주하고 후속 로직에 바로 사용하지 않습니다. 예를 들어 LLM 응답을 가지고 DB에 질의를 하거나 코드를 실행하는 기능이 있다면, 반드시 중간에 승인 절차나 화이트리스트 검증을 거칩니다. 
• 취약점 진단 자동화: 정기적으로 애플리케이션에 대한 정적/동적 분석 도구를 활용해 OWASP Top 10 취약점을 스캔합니다. SAST/DAST 도구로 SQL Injection, XSS, 인증결함 등을 사전에 찾아내고, 종속 라이브러리의 알려진 취약점(CVE)을 관리합니다. 또한 프롬프트 관련 보안테스트(예: 공개된 프롬프트 인젝션 시나리오 테스트)를 수행하여 LLM 레이어 특화 취약점도 점검합니다.
• 안티-자동화 및 리소스 제어: 애플리케이션 레벨에서 Rate Limiting을 적용하고, 사용자별 동시 요청 수나 일정 기간당 요청 횟수를 제한합니다 . AWS API Gateway나 ALB에서 IP별 제한을 걸거나, CloudFront(WAF)에서 봇 차단을 설정할 수 있습니다. 또한 각 요청에 할당되는 리소스(예: 최대 토큰 수, 컨텍스트 문서 개수)를 제한하여 자원 고갈형 공격을 예방합니다 . LLM 요청에 대하여 응답 시간이나 사용 메모리를 모니터링하고 임계치 이상은 강제 중단하는 메커니즘도 필요합니다.
• 디버그 및 에러 관리: 애플리케이션의 에러 메시지는 과도한 정보를 노출하지 않도록 처리합니다. 예를 들어, 프롬프트 처리 중 NullPointerException 발생 시 스택트레이스를 사용자에게 노출하지 말고, 내부 로그로만 남기고 사용자에겐 일반 오류메시지만 보여줍니다. DEBUG 모드 설정이 실서비스에 남아있지 않은지, 불필요한 엔드포인트 (예: /actuator 등 관리용 인터페이스)가 외부 노출되지 않았는지도 확인해야 합니다.

 

OWASP LLM Top 10 대응

LLM01: Prompt Injection 

• 프롬프트 인젝션 공격으로, 공격자가 악의적 입력을 통해 LLM의 지시를 가로채거나 임의 동작을 유발할 수 있습니다 . 
• 대응: 사용자 입력 프롬프트에 대한 엄격한 검증/필터링이 1차 대응입니다. 시스템 프롬프트를 쉽게 덮어쓰지 못하도록 LLM API의 지시 기능(e.g. Bedrock에서 user/input 필드와 system 필드 구분 등)을 활용하고, 답변에 부적절한 내용이 나오지 않도록 콘텐츠 필터를 병행합니다 . 또한 중요한 결정은 LLM 혼자 내리지 않도록 하고, LLM 응답에 따라 행동하는 에이전트에는 human confirmation 절차를 넣습니다. 예를 들어 “사용자 계정 삭제해”라는 응답을 LLM이 생성하더라도 실제 수행 전에 관리자 승인을 요구하는 것입니다.

LLM02: Insecure Output Handling 

• 출력 처리 취약으로, 검증되지 않은 LLM 출력을 사용해 XSS, RCE 등이 발생하는 경우입니다 . 
• 대응: LLM 출력은 항상 검증 또는 이스케이프 처리 후 사용합니다. 웹 페이지에 출력한다면 HTML 이스케이프를 적용하고, 다른 시스템 명령으로 사용할 경우 안전한 파싱을 거칩니다.

LLM04: Model Denial of Service 

• 모델 서비스 거부로, 과도한 요청으로 LLM API를 느려지게 하거나 비용을 폭증시키는 공격입니다 . 
• 대응: 앞서 언급한 Rate Limit, WAF 등을 통해 1차 제어하고, 모니터링을 통해 자원 사용 스파이크를 조기 인지합니다 . 또한 요청별 복잡도를 제한하는 규칙(토큰 길이 제한 등)을 두고, 필요 시 큐잉을 통해 순차 처리하여 대량 동시 호출을 완화합니다.

LLM05: Supply Chain Vulnerabilities 

• 앞서 데이터 보호에서도 다룬 공급망 이슈가 애플리케이션 구성요소에도 해당됩니다. 프레임워크나 오픈소스 라이브러리의 취약점, 모델 제공자의 API 신뢰성 등이 포함됩니다 . 
• 대응: 코드 의존성에 대한 보안 업데이트를 정기 적용하고, 서드파티 SDK(예: LLM API SDK)가 최신 버전인지 확인합니다. 또한 프롬프트 템플릿 등 공유된 레시피를 사용할 경우, 출처를 검증하고 임의 코드 실행 기능이 포함되지 않았는지 확인합니다.

LLM03: Training Data Poisoning 

• 이는 모델 측면의 공급망 문제이지만, RAG의 컨텍스트 데이터 오염으로 확장될 수 있습니다 . 
• 대응: 애플리케이션에 유입되는 데이터에 검증 체계를 마련합니다. 예컨대, 외부 웹 크롤링 데이터를 바로 벡터DB에 넣지 말고, 신뢰할 도메인만 허용하거나 스코어 기반 필터링을 합니다. 또한 사용자 생성 콘텐츠(예: 질문 자체에 악성 내용 포함)를 맹신하지 않고, LLM에 넣기 전 텍스트 클래시파이어나 정규식으로 위험패턴을 제거합니다.

 

NIST SP 800-207 지침

제로 트러스트의 적용은 애플리케이션 레벨에서도 마찬가지입니다. LLM 같은 애플리케이션 구성요소도 불완전하고 잠재적으로 위험한 것으로 간주하여, 그것이 생산하는 데이터나 요청을 검증하는 구조가 필요합니다. 또한 ZT 원칙 “모든 요청을 지속적으로 모니터링하고 위협을 평가” 하는 부분은 애플리케이션에서도 이상 트래픽 탐지 및 대응으로 나타납니다. 즉, 비정상적인 프롬프트 시퀀스나 출력 패턴(예: 반복적으로 금지된 답변 시도 등)을 감지해 차단하는 논리가 있어야 합니다. Zero Trust는 공격 전제를 두고 방어하기 때문에, 애플리케이션 방어도 다계층(Defense-in-Depth)으로 겹겹이 구성해야 합니다.

 

NIST AI RMF 지침

AI RMF에서는 레질리언스(Resilience) 측면에서 “예기치 않은 환경 변화나 오용에 견딜 수 있고, 안전하게 열화되어야 한다”고 언급합니다. 이는 LLM 애플리케이션이 적대적 입력(프롬프트 인젝션 등)에도 완전히 무너지지 않고 안전하게 대응해야 함을 의미합니다. 또한 투명성 및 책임성(Accountability) 특성상 LLM의 의사결정에 인간이 개입할 수 있는 구조, 예를 들어 “결정에 최종적으로 인간 검토” 같은 메커니즘을 마련하라고 권고합니다. 애플리케이션에서 과도한 자동화를 지양하고 휴먼 가드레일을 두는 것이 이에 부합합니다. 마지막으로 AI RMF는 시스템 테스트 및 밸리데이션을 강조하기 때문에, LLM 통합 애플리케이션에 대해서도 정기적인 보안테스트와 시뮬레이션(예: 레드팀 공격 시나리오 수행)이 필요합니다.

 

체크 항목	보안 요구사항 및 베스트 프랙티스
입력 데이터 검증	사용자 입력 및 외부 데이터에 대해 화이트리스트 기반 검증을 적용하고 있는가? (특수문자 이스케이프, 최대길이 제한 등)
출력 처리	LLM 응답 등 동적으로 생성된 콘텐츠를 표시하거나 사용할 때 안전하게 인코딩/필터링하는가 ? (HTML 화면 출력 시 XSS 방지 등)
Injection 대비	SQL/명령/코드 삽입에 대비하여 ORM, 파라미터 바인딩, 샌드박스 등 대책이 적용되어 있는가? (시큐어 코딩 표준 준수 여부 등)
에러/디버그 노출	스택 추적이나 시스템 내부 정보가 사용자에게 노출되지 않는가? 에러 메시지는 최소한의 정보만 포함하는가?
업데이트/패치 관리	종속 라이브러리 및 컨테이너 이미지에 최신 보안 패치가 적용되었는가? (예: log4j 같은 known 취약점 라이브러리 존재 여부)
자동화 악용 방지	봇 트래픽이나 과도한 요청을 식별/차단하기 위한 WAF 규칙, Rate Limit이 설정되어 있는가 ?
콘텐츠 필터 및 Guardrails	AI 응답의 유해 콘텐츠 출력 방지 대책이 있는가? (ex. Bedrock Guardrails 또는 자체 필터링 로직 적용 여부)
테스트 커버리지	보안 테스트(동적 분석, 침투 테스트 등)가 정기적으로 수행되고 결과가 반영되는가? (프롬프트 취약성 전용 시나리오 테스트 포함 여부 등)
권한 분리 (클라이언트/서버)	프론트엔드에서 중요한 결정을 내리지 않고, 반드시 서버에서 권한 체크 등 수행하는가?