Become a Good Analyst

RAG LLM Application 보안 - 로깅 및 모니터링

SalaYH — Sun, 1 Jun 2025 18:01:28 +0900

로깅과 모니터링은 시스템 활동을 기록하고 이상 징후를 실시간으로 감시하는 영역입니다. 제로 트러스트 환경에서는 지속적인 모니터링을 통해 정책을 개선하고 위협에 대응하는 것이 필수이며, LLM 애플리케이션에서도 사용자 활동, 모델 사용 내역, 보안 이벤트를 모두 기록하여 추적 가능하고 분석 가능해야 합니다. 또한 실시간 모니터링으로 침해 시도를 빨리 탐지하고 차단하는 체계를 갖춰야 합니다.

위협 (STRIDE):

스푸핑: 적절한 모니터링이 없으면, 공격자가 시스템 내에서 악의적 활동을 해도 정상 사용자로 위장하여 지나칠 수 있습니다. 예를 들어 공격자가 탈취한 계정으로 행동해도 모니터링이 그 사용자의 일반 패턴과 비교해 이상함을 탐지 못하면 알아채지 못합니다.
변조: 공격자가 로그를 임의로 조작하거나 삭제하여 자신의 흔적을 지울 수 있습니다. 로그 무결성 보호가 없다면 침입 후 로그 지우기를 통해 증거를 없애고 나갈 수 있습니다.
부인: 부인방지(Non-repudiation) 측면에서 로그는 핵심 증거입니다. 로그가 없다면 사용자는 악의적 행위를 하지 않았다고 주장할 수 있고, 이를 반박할 방법이 없습니다 . 특히 RAG LLM의 응답 오류로 인한 문제 발생 시에도, 로그를 통해 당시 프롬프트와 응답을 확인할 수 없다면 책임 소재 규명이 어렵습니다.
정보 노출: 로그 자체에 민감정보가 남아있으면, 로그 유출이 곧 데이터 유출로 이어집니다. 예를 들어 로그에 사용자 질문이나 답변 전문이 저장되는데, 그 안에 개인정보가 포함되어 있었다면 로그 관리 소홀 시 문제가 됩니다.
서비스 거부: 모니터링 경고를 무시하거나, 로그 용량 관리 실패로 디스크가 가득 차면 서비스 장애로 이어질 수 있습니다. 공격자가 의도적으로 엄청난 양의 이벤트를 발생시켜 로그를 가득 채우는 로그 폭주 공격도 고려해야 합니다.
권한 상승: 모니터링 취약 시 장기간에 걸친 은밀한 권한 상승 시도를 놓칠 수 있습니다. 예컨대 한 계정이 점진적으로 더 많은 데이터에 접근하는 것을 모니터링하면 권한 오남용을 캐치할 수 있는데, 이런 관측이 없으면 내부자 권한남용이나 APT 공격을 늦게 발견합니다.

보안 요구사항 및 대응:

중앙집중 로깅: 분산된 마이크로서비스 환경에서는 모든 로그를 중앙에 수집하여 분석해야 합니다. AWS 환경에서는 CloudWatch Logs나 Amazon OpenSearch Service로 로그를 모으고, 필요 시 Security Lake를 활용해 각종 로그를 통합 저장합니다 . 수집 대상 로그에는 인증/인가 이벤트, 사용자 행위 로그(질문 내용 등), 시스템 이벤트(에러, 예외), 보안 장비(WAF, GuardDuty 등) 경보가 모두 포함됩니다.
세분된 모니터링 메트릭: 단순 로그뿐 아니라 시스템 메트릭도 모니터링해야 합니다. 예를 들어 모델 호출 횟수, 응답 지연, 토큰 사용량, 프롬프트 내 금지어 검출 건수 등 LLM 애플리케이션 특화 지표를 정의합니다. AWS CloudWatch를 이용해 Bedrock InvokeModel 횟수, 지연시간, 에러율 등을 추적하고, DynamoDB의 RCUs 소비량이나 OpenSearch 쿼리 응답시간도 모니터링합니다 . 또한 사용자별 요청 빈도, IP별 요청 분포 등의 커스텀 메트릭도 설정해 둡니다.
경보 및 대응: 중요한 이벤트에 대해서는 알람을 설정하여 실시간 대응이 가능해야 합니다. 예를 들어 WAF에서 여러 차단 발생 시 알람, GuardDuty에서 이상행위 탐지 시 알람, 모델 응답 지연 급증 시 알람 등을 구성합니다 . AWS SNS나 이메일, PagerDuty 등을 연계하여 운영팀이 즉시 인지하고 대응하도록 합니다. 경보 발생 시 표준대응절차(Playbook)를 마련해 두어, 예를 들어 “API 키 누출 의심 로그 발생 -> 즉시 해당 키 폐기 및 사용자 통보”와 같은 플랜을 실행합니다.
로그 무결성 및 접근 통제: 로그는 사후 증거로 사용되므로 변조나 삭제로부터 보호되어야 합니다. AWS CloudTrail의 경우 S3에 저장하고 객체 잠금(WORM) 설정이나 CloudTrail 로그 무결성 검사 기능을 이용할 수 있습니다. 또한 운영자 중 극소수만 로그 접근권한을 가지며, 로그 접근도 감사하도록 설정합니다.
SIEM 및 분석: 수많은 로그를 상호 연관짓고 이상패턴을 찾기 위해 SIEM을 활용합니다 . 예를 들어 AWS Security Hub나 ELK 스택을 사용해 다양한 소스의 로그를 통합 분석하고, 머신러닝 기반 이상탐지도 도입할 수 있습니다. LLM 애플리케이션 특이사항으로, 프롬프트/응답 내용 분석을 통한 정책 위반 탐지(예: 민감정보가 응답된 로그를 찾아내기) 등을 자동화하는 것도 고려합니다.
지속적 개선: 모니터링 지표와 알람 임계치는 정적인 것이 아니므로, 정기 리뷰를 통해 튜닝합니다 . 새로운 공격 벡터 등장 시 로그 항목을 추가하거나, 오탐 많은 경보는 조정합니다. 또한 로그 분석을 통해 얻은 인사이트를 보안 정책에 반영합니다 (예: 자주 차단되는 프롬프트 패턴을 시스템 프롬프트에 추가 반영 등).

\OWASP LLM Top 10 대응

LLM04: Model DoS

모델 서비스 거부 공격의 징후를 모니터링으로 감지해야 합니다. LLM API 호출수나 리소스 사용량에 급증이 있으면 경보를 통해 대응함으로써, 공격이 장기화되지 않도록 합니다 . 예를 들어 CloudWatch로 모델 호출 TPS를 추적해 평소 대비 2배 이상 치솟으면 알람을 발생시켜 조사합니다.

LLM09: Overreliance

과도한 신뢰 항목은 보안 취약점이라기보다 조직 문화 위험이지만, 모니터링으로 LLM 출력의 신뢰도를 관리할 수 있습니다. 예를 들어 LLM이 근거를 제시하지 않은 답변(할루시네이션)을 자주 내놓는다면, 이를 탐지해 품질 경고를 내보내고, 일정 횟수 이상 발생 시 해당 기능을 일시 중단하여 검토하게 하는 등의 운영상 조치를 취할 수 있습니다. 결국 모니터링은 LLM 시스템의 성능 및 안전성 지표 (정확도 저하, 오답률 상승 등)도 포함하여, 운영 리스크를 제어하는 데 활용됩니다.

LLM01/02 등 일반 취약점:

프롬프트 인젝션이나 출력 취약 문제도 로그를 통해 식별될 수 있습니다. 예를 들어 시스템 프롬프트 변경 시도를 로그에 남겨두면 추후 분석에 도움이 되고, XSS 의심 문자열이 응답에 섞여있다면 이를 로그 스캐닝으로 찾아낼 수 있습니다. OWASP LLM Top 10 각각의 발생 여부를 지속적으로 로깅/모니터링하는 것은 보안 체크리스트로 활용 가능하며 , AWS에서 제공하는 Security Hub 규칙이나 Config 규칙을 통해 알려진 모범사례 미준수 사항을 지속 점검할 수도 있습니다 .

NIST SP 800-207 지침:

제로 트러스트 7대 원칙 중 마지막은 “기업은 자산 상태, 네트워크 트래픽 및 액세스 요청에 대한 가능한 많은 정보를 수집하고 이를 보안태세 개선에 활용해야 한다”입니다 . 이는 로깅/모니터링의 중요성을 명시한 것으로, 끊임없는 데이터 수집과 분석을 통해 정책을 업데이트하고 위험에 대응하라는 의미입니다. 따라서 조직은 LLM 애플리케이션 운영 시에도 최대한의 로그와 텔레메트리를 수집하고, 이를 토대로 정책 튜닝과 이상 징후 대응을 해야 합니다. Zero Trust에서는 신뢰를 실시간 평가하므로, 모니터링 시스템이 곧 보안 정책 엔진과 연계되어 자동 차단 등의 액션까지도 이어질 수 있습니다. (예: 이상 행동 탐지 시 해당 세션의 접근 즉시 차단 등)

NIST AI RMF 지침:

AI RMF에서는 모니터링과 데이터피드백을 통한 위험관리도 강조합니다. AI 시스템을 실시간 모니터링하여 “예상치 못한 동작이나 편향이 나타나면 개입 또는 수정한다”는 지침이 있으며 , 특히 인간의 개입 옵션 (kill switch)을 준비해두는 것을 권고합니다. LLM 애플리케이션의 경우 모니터링을 통해 만약 모델이 지속적으로 유해 출력이나 이상응답을 낼 경우, 긴급하게 모델 호출을 중지하거나 이전 안전한 버전으로 롤백하는 등의 운영상 조치를 취할 수 있어야 합니다. 이는 AI 시스템의 회복탄력성(resilience)을 높이는 방법으로, 모니터링 체계 없이는 불가능합니다. 또한 AI RMF는 투명성을 위해 로그 등이 활용될 수 있다고 언급하므로, 향후 규제나 감사에 대비해서도 운영 로그를 잘 비치하는 것이 중요합니다.

체크 항목	보안 요구사항 및 베스트 프랙티스
로그 범위	어떤 이벤트들이 로깅되고 있는가? 인증, 인가, 오류, 모델 질의 등 중요한 이벤트 누락 없이 수집되는지 .
로그 무결성	로그 저장소(S3 등)에 무결성 보호조치가 있는가? 관리자가 로그 임의 조작이 불가능하도록 설정(버전관리 또는 WORM 적용) 여부.
접근 제어	로그 및 모니터링 대시보드에 대한 접근권한이 최소한으로 제한되어 있는가? (보안팀/운영팀 등으로 한정)
실시간 경보	주요 보안 이벤트에 대해 CloudWatch 경보, GuardDuty, Security Hub 등 알림이 설정되어 대응 프로세스가 있는가 ?
지표 및 대시보드	성능 및 보안 지표(모델 지연시간, 에러율, 차단 건수 등)를 모니터링하는 대시보드를 구축했는가? 이를 주기적으로 검토하는지.
로그 보존 및 삭제	로그의 보관 기간은 정책에 따르는가? (예: 1년 등) 너무 오래 보존하여 개인정보 문제가 생기거나, 반대로 너무 짧아 포렌식 불가하지 않도록.
통합 로그 분석	여러 소스의 로그를 통합 분석(SIEM)하고 있는가 ? 이상 징후에 대한 상관관계 규칙(예: 동일 IP서 다수 계정 실패 로그인) 등을 설정했는지.
테스트 및 개선	로그/모니터링 체계가 제대로 작동하는지 정기 테스트하는가? (예: 침투테스트 시나리오에 경보 발생 확인 등) 모니터링 항목을 지속 보강하는지.

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

SalaYH — Sun, 1 Jun 2025 18:00:26 +0900

애플리케이션 보안은 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 또는 자체 필터링 로직 적용 여부)
테스트 커버리지	보안 테스트(동적 분석, 침투 테스트 등)가 정기적으로 수행되고 결과가 반영되는가? (프롬프트 취약성 전용 시나리오 테스트 포함 여부 등)
권한 분리 (클라이언트/서버)	프론트엔드에서 중요한 결정을 내리지 않고, 반드시 서버에서 권한 체크 등 수행하는가?

RAG LLM Application 보안 - 데이터 보호

SalaYH — Sun, 1 Jun 2025 17:59:33 +0900

데이터 보호는 저장 중이거나 전송 중인 데이터의 기밀성, 무결성, 가용성을 보장하고, 민감 정보의 유출을 방지하는 것을 의미합니다. 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 등)에 무결성 검증 또는 승인 프로세스가 있는가? 임의 문서 추가로 인한 데이터 중독 방지 대책이 있는가?
공급망 보안	외부에서 도입한 모델/데이터/라이브러리에 대한 신뢰 검증을 했는가? (서드파티 구성요소의 보안 업데이트 정책 등)
로그 민감정보 보호	로그에 민감정보 또는 암호화되지 않은 데이터가 기록되지 않는가? (예: 비밀번호 평문 노출, 신용카드 번호 등) 필요시 마스킹 처리하는가?

RAG LLM Application 보안 - 인가

SalaYH — Sun, 1 Jun 2025 17:58:42 +0900

인가는 인증된 주체에 부여된 권한을 검증하여, 적절한 권한으로만 자원에 접근하도록 통제하는 것입니다. RAG LLM 서비스에서는 사용자별로 볼 수 있는 데이터 제한, 기능별 관리자/일반 사용자 권한 차등, 마이크로서비스 간 권한 위임 등이 중요합니다. 제로 트러스트 맥락에서 모든 요청에 최소 권한 원칙을 적용하고, 접근 시마다 정책에 따라 권한을 재평가해야 합니다 .

위협 (STRIDE)

스푸핑/권한 도용: 인증을 통과한 사용자가 다른 사용자인 척하면서 그들의 데이터나 기능에 접근할 수 있습니다. 예를 들어 URL이나 ID를 바꿔치기(IDOR 취약점)하여 남의 대화 히스토리나 프롬프트 결과를 열람하는 행위가 가능합니다.
변조: 클라이언트 측에서 권한 정보(예: JWT의 role 클레임 등)를 조작하여 더 높은 권한을 가장할 수 있습니다. 서버에서 해당 토큰의 무결성을 검증하지 않으면 공격자가 권한을 위조할 수 있습니다.
부인: 권한 있는 사용자가 한 민감행위(예: 데이터 삭제 등)를 나중에 부인할 수 있습니다. 인가 결정 및 사용자의 행위에 대한 로그가 없다면 감사가 어려워집니다.
정보 노출: 인가 결함으로 인해 비인가된 사용자가 민감 데이터를 읽어갈 수 있습니다. 예를 들어 잘못된 S3 버킷 정책이나 퍼블릭한 OpenSearch 인덱스로 인해 내부 지식베이스 정보가 외부에 공개될 수 있습니다.
서비스 거부: 권한 체크 결여로 인해 특정 사용자 API가 제한 없이 남용되면 리소스 고갈로 이어질 수 있습니다. (예: 일반 사용자가 어드민 API를 호출해 대량 작업을 수행하여 시스템을 느려지게 만드는 경우)
권한 상승(Elevation of Privilege): 가장 큰 위험으로, 원래 권한이 없는 기능을 얻게 되는 시나리오입니다. 인가 정책의 부재나 오구현으로 일반 사용자가 관리자 기능(API 호출, 설정 변경 등)을 실행할 수 있다면 시스템 장악으로 이어질 수 있습니다.

보안 요구사항 및 대응

정책 기반 접근제어: 모든 서비스 요청에 대해 중앙 정책 엔진(PDP)이 역할 기반 접근제어(RBAC) 또는 속성 기반 접근제어(ABAC)를 적용해 허용/거부를 결정해야 합니다. AWS 환경에서는 IAM 정책 및 리소스 기반 정책을 활용하여 세분화된 권한 정책을 설정합니다. 예를 들어 DynamoDB 테이블이나 S3 버킷에 대해 리소스 ARN 단위로 읽기/쓰기를 구분한 정책을 적용하고, 마이크로서비스별 IAM Role을 분리합니다.
최소 권한 원칙(Least Privilege): 사용자나 애플리케이션 컴포넌트가 필요 이상으로 권한을 갖지 않도록 합니다. 기본값으로 모든 접근 거부(Deny all) 후 필요한 경우에만 허용을 부여하는 방식으로 설정합니다. 예를 들어 챗봇 프런트엔드 Lambda 함수에는 딱 필요한 DynamoDB 읽기 권한만 주고, 쓰기나 삭제 권한은 제외하는 식입니다. 네트워크 측면에서도 마찬가지로 각 서비스 간 통신을 보안 그룹, NACLS, VPC 세그멘테이션으로 제한하여 불필요한 경로를 차단합니다 .
계층형 권한모델: 관리자, 일반 사용자, 읽기전용 사용자 등 역할의 등급을 두고 각 등급에 따른 자원 접근을 구분합니다. 특히 관리자 기능(예: 지식베이스 업로드, 시스템 설정 변경 등)은 절대 일반 사용자 토큰으로 호출되지 않도록 API Gateway 단계에서부터 역할 검증을 수행합니다.
맥락 기반 인가: Zero Trust에서는 맥락(Context) 정보(사용자 단말 상태, 위치, 액세스 시간 등)에 따라 동적으로 인가 결정을 내릴 것을 권장합니다. 예를 들어 허가된 사용자라도 비정상적인 접근(새 디바이스, 해외 IP, 업무시간 외 대량 요청 등)이 감지되면 추가 인증 또는 접근 차단을 할 수 있어야 합니다.
마이크로서비스 호출 권한: RAG 아키텍처 내에서 각 구성요소(예: 벡터DB, LLM API, UI 백엔드)는 고유 IAM 역할 또는 API 키로 통신하며, 서로 호출 시 상호 TLS 인증이나 IAM 권한으로 검증해야 합니다. 예를 들어 OpenSearch를 호출하는 Lambda에는 해당 도메인에 대한 일체의 권한이 없으면 요청 자체가 실패하게 구성합니다. 이를 통해 한 컴포넌트가 침해되더라도 횡적 움직임을 최소화합니다.
권한 검증 실패 처리: 인가 실패 시 민감 정보를 에러메시지로 출력하지 않고 일반화된 에러(HTTP 403 Forbidden 등)로 응답해야 합니다. 또한 권한 에러 발생 자체를 모니터링하여 혹시 권한 탈취 시도가 있는지 경보로 연계합니다.

OWASP LLM Top 10 대응

LLM07: Insecure Plugin Design

앞서 인증 도메인에서도 다룬 플러그인 보안 이슈입니다. 플러그인의 접근 제어 미비는 곧 인가 결함으로 이어집니다.
대응: 플러그인별 인증 외에도 권한 제한 토큰을 사용하여 플러그인이 수행할 수 있는 액션을 제어합니다. 예를 들어 플러그인이 DB에 질의할 때 특정 쿼리만 허용되도록 쿼리 파서나 프록시를 둘 수 있습니다. 또한 플러그인의 입력에 대해 유해한 명령이 전달되지 않도록 샌드박싱과 검증을 수행합니다 .

LLM08: Excessive Agency

과도한 에이전시란 LLM 에이전트에게 너무 광범위한 자율적 행동 권한을 부여한 상황을 말합니다 . 예를 들어 LLM이 시스템 파일을 삭제하는 등의 액션까지 자동 수행하게 두면, 프롬프트 조작이나 오류로도 큰 피해가 발생할 수 있습니다 .
대응: LLM 애플리케이션이 자동으로 실행하는 기능을 최소화하고, 위험도가 높은 행위(파일 조작, 시스템 명령 실행 등)는 사람의 추가 승인을 받도록 합니다 . 또한 플러그인이나 도구(tool)에 부여하는 권한을 필요한 범위로 제한하고, OS 레벨에서 AppArmor/SElinux 같은 것으로 프로세스 권한을 격리합니다. 즉, LLM이 영향 미칠 수 있는 범위를 통제하여 권한 남용을 구조적으로 막습니다.

NIST SP 800-207 지침

제로 트러스트 원칙에서 인가는 인증과 불가분의 관계로, 모든 리소스 요청마다 정책에 따른 동적 인가가 이루어져야 합니다 . 특히 NIST 800-207은 리소스별로 세분화된 접근통제와 “정책 결정 지점(PDP)”의 중앙 관리를 강조합니다. 각 접근 요청은 사용자 신원뿐 아니라 장치 상태, 위치, 시간 등의 신뢰 기준을 종합 평가하여 정책에 부합할 때만 허용됩니다. 또한 마이크로세그멘테이션(microsegmentation)을 통해 네트워크상의 리소스를 세분 격리하여, 인가된 경로 외에는 다른 서비스에 접근하지 못하도록 권한 범위를 좁힐 것을 권고합니다. 이러한 맥락에서 최소 권한과 지속적 검증이 인가 단계의 핵심 지침입니다.

※ PDP : 들어오는 접근요청에 대해 중앙화 된 정책을 펴가하여 승인 여부를 결정

NIST AI RMF 지침

AI RMF에서도 AI 시스템의 무단 사용 방지를 핵심 안전 요구로 기술하고 있습니다 . 이는 관리자 승인 없이 AI 모델을 임의로 활용하거나 내부 데이터에 접근하지 못하게 통제해야 함을 뜻합니다. 또한 AI 시스템이 의도되지 않은 기능을 수행하지 않도록, 설계 단계에서 오남용 시나리오를 식별하고 대비책을 마련하도록 권고합니다. 예를 들어 RAG 시스템에서 일반 사용자는 사내 기밀 문서를 조회하는 기능이 없어야 하고, 모델이 그러한 지시를 받더라도 거부하도록 하는 설계(시스템 프롬프트 수준에서 정책 적용 등)도 AI 거버넌스 차원에서 필요합니다. NIST AI RMF의 대응(Function: MAP) 단계에서는 이러한 오용 가능 시나리오에 대한 맵핑과 제어를 요구하므로, 결국 강력한 인가 정책 수립이 AI 위험 관리의 시작임을 시사합니다.

체크 항목	보안 요구사항 및 베스트 프랙티스
권한 정책 정의	모든 API 및 기능에 대해 누구에게 어떤 권한이 부여되는지 명확한 정책이 정의되어 있는가? (예: RBAC 매트릭스)
최소 권한 구성	IAM 정책, 보안 그룹 등이 기본 Deny 후 필요 권한만 Allow로 설정되었는가? Wildcard (*)나 Allow all 권한 남용 여부 확인.
관리자 기능 제한	관리자용 API/페이지에 비인가 사용자가 접근 가능하지 않은가? 숨겨진 엔드포인트나 UI를 통한 권한 우회 시도 방지 여부.
수평권한 검증	사용자가 자신의 리소스만 접근하는지 확인하는 검증(예: URL에 사용자 ID 전달시 서버측에서 본인 것만 조회하는지)이 구현되어 있는가?
토큰/세션 인가 정보	JWT 등 토큰에 담긴 권한정보를 신뢰할 수 있는 방식으로 서명 검증하고 있는가? 토큰의 scope/role이 서버에서 재검증되는가?
권한 변경 절차	사용자 권한 상승/하향 변경 시 로그를 남기고 즉시 적용되는가? 권한 철회 시 활성 세션에 대한 처리하는가?
자원 소유권 검증	RAG 지식베이스 등에서 사용자별 데이터 분리가 되어 있는가? 예: 벡터DB의 네임스페이스 등으로 테넌트 격리가 이루어지는가?
취약한 엔드포인트 점검	인가 누락 우려가 있는 엔드포인트에 대해 보안테스트(스캐닝, 페네트레이션)를 수행했는가? (특히 새로 추가된 API의 권한 설정 확인)
권한 오류 로깅	권한 실패 이벤트(403 발생 등)를 로깅/모니터링하여 권한 우회 시도 탐지에 활용하고 있는가?

RAG LLM Application 보안 - 인증

SalaYH — Sun, 1 Jun 2025 17:56:09 +0900

인증은 사용자나 서비스의 신원을 확인하는 과정입니다. RAG 기반 LLM 애플리케이션에서는 최종 사용자, 내부 마이크로서비스, 외부 API 호출 등 다양한 주체에 대한 강력한 인증이 필수입니다. 제로 트러스트 원칙에 따라 모든 주체를 사전에 신뢰하지 않고, 모든 접근 요청마다 엄격한 신원 확인이 이루어져야 합니다 .

위협 (STRIDE)

스푸핑(Spoofing): 공격자가 합법적 사용자나 서비스를 가장하여 LLM 애플리케이션에 접근할 수 있습니다. 예를 들어, 피싱이나 크리덴셜 탈취를 통해 토큰이나 세션을 가로챔으로써 공격자가 사용자로 위장할 수 있습니다.
변조(Tampering): 인증 토큰이나 세션 ID가 탈취·위조되어 무단으로 사용될 수 있습니다. 전송 중 토큰이 노출되거나 위변조되면 인증 체계를 우회당할 위험이 있습니다.
부인(Repudiation): 인증 로그가 부실하면 사용자는 자신의 행동을 부인할 수 있습니다. 누가 언제 인증했는지 기록되지 않으면 사후 추적과 책임소재 규명이 어려워집니다.
정보 노출(Information Disclosure): 인증 과정에서 암호나 키와 같은 민감정보가 평문으로 저장 또는 전송되면 공격자에게 노출될 수 있습니다. 예를 들어 소스 코드나 설정에 하드코딩된 비밀번호, AWS 키 등이 유출 위험입니다 .
서비스 거부(Denial of Service): 인증 엔드포인트에 대한 무차별 대입 공격이나 과도한 인증 시도로 서비스가 붕괴되거나 계정이 잠길 수 있습니다.
권한 상승(Elevation of Privilege): 취약한 인증을 통해 낮은 권한의 사용자가 관리자 계정으로 가장하거나, 다중 요소 인증을 우회하여 상위 권한을 획득할 수 있습니다.

보안 요구사항 및 대응

강력한 신원 확인: 모든 사용자와 서비스는 신뢰할 수 있는 IdP(Idenity Provider)를 통해 인증되어야 합니다. OAuth 2.0/OpenID Connect와 같은 표준 프로토콜을 활용하고, SSO를 위해 AWS IAM Identity Center(이전 AWS SSO) 등의 서비스와 연동하여 중앙집중식 인증을 구현합니다. 임시 세션 토큰 등을 사용하여 장기 자격증명 노출을 최소화합니다.
다중 요소 인증(MFA): 중요 리소스에 대한 접근은 MFA를 필수로 적용합니다. NIST SP 800-207에서도 엔터프라이즈 자원 접근 시 MFA 사용을 권고하고 있으며, AWS IAM 사용자나 역할에도 MFA를 적용하여 크리덴셜 탈취 위험을 낮춰야 합니다 .
자격증명 관리: 하드코딩된 비밀번호나 액세스 키를 코드나 설정 파일에 두지 않습니다. 대신 AWS Secrets Manager, Parameter Store 등의 안전한 저장소를 사용하고, 애플리케이션은 실행 시 필요에 따라 불러쓰도록 합니다. AWS 리소스 간 통신에는 IAM 역할 연동을 활용하여, 애플리케이션 코드에 비밀키를 가지고 있지 않게 설계합니다.
짧은 세션 수명 및 회수: 발급되는 액세스 토큰/쿠키의 수명은 최소화하고, 재사용 공격을 방지하기 위해 한 세션에 한해 사용하거나 주기적으로 재인증합니다. Zero Trust 원칙상 인증과 인가를 동적으로 지속 검증해야 하며, 필요시 재인증을 트리거하는 정책을 운영합니다. 또한 사용자 로그아웃이나 비정상 활동 탐지 시 토큰을 즉시 무효화하고 회수합니다.
안전한 전송: 인증 자격 증명은 항상 암호화된 채널(예: HTTPS/TLS)로 주고받아야 합니다. 모든 연결을 인증하고 모든 트래픽을 암호화하는 것은 제로 트러스트의 기본 전제이며, 토큰 탈취를 막기 위해 전송 중 기밀성이 유지되어야 합니다 .
계정 잠금 및 Throttling: 무차별 크리덴셜 시도가 탐지되면 계정 잠금이나 지연 응답 등으로 대응해 서비스 거부 공격을 완화합니다. AWS WAF의 레이트 리미팅 또는 API Gateway 사용 시 IP/사용자별 Rate Limit을 설정하여 과도한 인증 시도를 차단하고 , 의심스러운 활동은 추가 검증(MFA 재확인 등)을 요구합니다.

OWASP LLM Top 10 대응

LLM07 (취약한 플러그인 설계)

LLM 애플리케이션에 연동되는 MCP, 플러그인, 또는 서드파티 모듈이 적절한 인증을 거치지 않고 과도한 권한으로 동작하면, 공격자가 플러그인을 악용해 원격 코드 실행(RCE) 등의 공격을 실시할 수 있습니다 .
대응: 플러그인 또는 API 통합 지점마다 인증 토큰 검증과 최소 권한(least privilege) 원칙을 적용합니다 . 예를 들어 플러그인별로 별도 인증 키를 두고, 해당 플러그인이 접근 가능한 리소스 범위를 IAM 정책 등으로 제한합니다.

LLM10 (모델 탈취)

인증이 미흡하면 공격자가 LLM 모델이나 프롬프트 입력 인터페이스에 무단 접근하여, 사유 모델이나 데이터 자산을 탈취할 위험이 있습니다 .
대응: 모델 엔드포인트나 프롬프트 입력 API는 사전에 인증된 주체만 호출할 수 있도록 보호해야 합니다. 예를 들어 내부적으로 Amazon Bedrock 등의 모델 API를 호출할 때도 VPC 엔드포인트와 IAM 권한으로 제한하고, 결과적으로 인가된 요청만 모델을 사용할 수 있도록 구성합니다. NIST AI RMF에서도 무단 접근과 사용을 방지하여 AI 시스템의 기밀성과 무결성을 유지할 것을 강조하고 있습니다 .

NIST SP 800-207 지침

제로 트러스트 아키텍처에 따르면 “모든 리소스에 대한 인증과 인가는 액세스 전에 동적으로 엄격히 적용되어야 한다”고 명시합니다. 이를 위해 조직은 ICAM(Identity, Credential and Access Management) 체계를 갖추고 MFA 도입을 권장하며, 사용자와 기기의 신원을 계속 평가하여 세션 중에도 필요시 재인증을 수행합니다 . 또한 주기적 위협 모니터링과 정책에 따른 접근 제어로 세션 중에도 끊임없이 신뢰를 재평가할 것을 요구합니다. 이처럼 인증 단계부터 암묵적 신뢰를 두지 않고 항상 검증하는 것이 제로 트러스트의 핵심입니다.

NIST AI RMF 지침

NIST의 AI 위험관리 프레임워크에서도 안전하고 신뢰성 있는 AI 구현을 위해 접근 통제와 보안을 강조합니다. 특히 “AI 시스템의 기밀성, 무결성, 가용성을 유지하며 무단 접근과 사용을 방지”해야 안전한 AI라고 정의하고 있으며 , 인증 체계 약화를 노린 사회공학 공격이나 크리덴셜 탈취 시나리오에 대비한 통제가 필요함을 시사합니다. 이는 LLM 애플리케이션에서도 기본 인증이 뚫릴 경우 모델 악용이나 데이터 유출로 이어질 수 있으므로, AI RMF의 Secure and Resilient 특성 관점에서 강력한 인증은 필수 요소입니다

체크 항목	보안 요구사항 및 모범 사례
인증 방식	표준 프로토콜(OAuth 2.0/OIDC) 및 신뢰할 수 있는 IdP를 사용하고 있는가? 자체 구현보다는 검증된 프레임워크 사용 여부 확인.
자격증명 저장 및 관리	비밀번호, 액세스 키 등이 소스코드나 설정에 하드코딩되어 있지 않은가? Secrets Manager 등 안전한 저장소 활용 여부.
다중 요소 인증(MFA)	관리자나 고권한 사용자 계정, 민감 자원 접근에 MFA가 적용되어 있는가 ? MFA 백업코드/장치에 대한 관리도 검토.
세션 관리	토큰의 수명(Time-to-Live)이 최소화되어 있는가? 로그아웃/세션만료 처리와 재인증 정책이 존재하는가?
전송 구간 보호	로그인 폼, 토큰 교환 등 모든 인증 트래픽이 TLS 등으로 암호화되고 있는가 ? HSTS 등 적용 여부.
인증 시도 제한	무작위 대입 공격 대비 계정 잠금 또는 Rate Limiting이 구현되어 있는가 ? 비정상 다수 로그인 시도에 대한 경보 처리 여부.
로그인 감사 로그	모든 인증/인가 시도(성공, 실패)에 대해 감사 로그가 수집되고 있는가? 해당 로그에 사용자ID, 시간, 소스 IP 등이 포함되어 부인 방지에 활용되는지

RAG LLM Application 보안리뷰 전략

SalaYH — Sun, 1 Jun 2025 17:55:11 +0900

기업 내 RAG(Retrieval-Augmented Generation) 기반 LLM 애플리케이션(예: 챗봇, 검색 서비스)은 제로 트러스트(Zero Trust) 원칙 하에 철저한 보안 검토가 필요합니다. 본 글 시리즈는 인증, 인가, 데이터 보호, 애플리케이션 보안, 로깅 및 모니터링의 5대 도메인별로 위협 모델(STRIDE 기반), 보안 요구사항, OWASP LLM Top 10 대응, NIST SP 800-207 (Zero Trust) 및 NIST AI RMF 지침을 종합적으로 정리합니다. 또한 AWS 마이크로서비스 환경(특히 RAG 아키텍처)을 전제로 한 모범 사례와, 각 도메인별 보안 리뷰 체크리스트를 포함합니다. 이를 통해 제로 트러스트 접근 방식으로 RAG LLM 애플리케이션에 대한 체계적인 보안 리뷰 프로세스를 구축하는 전략을 수립할 수 있습니다.

구분	일반 애플리케이션	LLM 애플리케이션
공격자	외부 공격자, 내부 이용자	외부 공격자, 내부 이용자, LLM 애플리케이션
보호 데이터	개인정보, Confidential 데이터 등	개인정보, Confidential 데이터, 학습모델 등
MFA 요구	외부에서 접근 가능한 PIPS 계정생성, 권한부여/승인을 관리하는 애플리케이션 결제 서비스 재무 데이터를 다루는 애플리케이션	Confidential 데이터를 학습한 애플리케이션 개인정보를 학습한 애플리케이션 LLM 모델 트레이닝 애플리케이션 RAG 관리 애플리케이션
보안전략	일반적인 보안전략	제로 트러스트 기반 보안전략
권한	정적 권한	맥락기반 동적 권한
승인여부	유저 권한에 따라 승인없이 처리	접근 리소스나 처리 명령에 대해 사용자 승인 필요(휴먼 가드레일)

OAuth2 Security Checklist

SalaYH — Fri, 15 Nov 2024 04:34:05 +0900

OAuth 인증 제공자가 지켜야 하는 보안 사항

1. TLS 적용

2. 최소 범위(scope) 설정

3. Refresh Token 사용 관리

4. State 파라미터 활용

5. Redirect URI 검증 및 고정

6. 클라이언트 ID 및 비밀 보호

7. 액세스 토큰의 수명 제한

8. Implicit Grant Flow 사용 제한

9. 액세스 토큰의 안전한 전송

10. 로그 및 모니터링 (IDS/IPS 포함)

11. 동적 클라이언트 등록 제한

12. 사용자 로그아웃 시 모든 토큰 무효화

13. 클라이언트 자격 증명 보호

14. Bearer 토큰의 안전한 전송

15. 권한 부여 코드와 토큰 재사용 방지

16. 사용자 정보의 최소한 제공

17. 불필요한 인증 정보 전송 금지

18. 만료된 토큰 처리

19. 강력한 암호화 방식 적용

20. 세션 고정 공격 방지

21. Resource Owner Password Credentials Grant 사용 제한

22. 주기적인 보안 감사 및 취약점 점검

23. Open Redirect 취약점 방지

24. 다단계 인증(MFA) 지원

25. API 속도 제한 및 할당량 관리

26. 악의적인 클라이언트 차단 기능

27. 민감한 로그 데이터 마스킹

28. CSRF 공격 방지

29. 사용자 승인 화면에 정보 제공

30. 세션 만료 및 자동 로그아웃 처리

31. 로그 데이터 보호 및 감사 추적 기능

32. IDS/IPS를 통한 공격 탐지 시스템 구축

33. 타임아웃 및 계정 잠금 정책

34. 승인된 범위(scope) 세부 설정

35. 취약점 관리 및 주기적 패치 적용

36. 클라이언트 유형 구분 및 자격 증명 강화

37. 사용자 로그아웃 시 클라이언트와 동기화

38. 사용자 동의 관리 및 접근 제어

39. 리프레시 토큰의 만료 및 재사용 제한

40. 토큰 철회 기능 지원

41. 사용자 IP 및 위치 기반 접근 제어

42. 행동 기반 인증(Behavior-Based Authentication) 적용

OAuth 클라이언트가 지켜야 하는 보안 사항

1. TLS를 통한 안전한 인증 요청

2. 최소 범위(scope)만 요청

3. Refresh Token 안전하게 관리

4. State 파라미터 사용

5. Redirect URI 사전 등록 및 고정된 URI 사용

6. 액세스 토큰 안전한 전송

7. 로그아웃 시 모든 토큰 무효화 요청

8. Bearer 토큰의 안전한 전송 (HTTP 헤더로)

9. 사용자 정보 요청 시 최소한으로 설정

10. 불필요한 인증 정보 전송 금지

11. 정기적인 보안 점검

12. 사용자 승인 화면에 명확한 정보 제공 (UI/UX)

13. 세션 만료 및 자동 로그아웃 기능

14. 새로운 토큰 발급 시 사용자 알림

15. 정책 기반 접근 제어(PBAC)

16. 계정 잠금 및 타임아웃 정책 준수

17. 안전한 비밀번호 정책 적용

18. 동시 접속 제한

19. PKCE 사용 (public 클라이언트)

20. 클라이언트 자격 증명 강화 (confidential vs public)

21. 사용자 로그아웃 동기화

22. 비밀번호 없는 인증 방식 지원

23. 로그아웃 후 캐시된 데이터 제거

24. IP 및 위치 기반 접근 관리

API Security Checklist

SalaYH — Fri, 15 Nov 2024 03:51:14 +0900

인증 및 권한 부여

• API Gateway를 사용하여 인증 및 권한 관리를 중앙화한다.

• 적절한 인증 방식을 구현한다:

• API 키 기반 인증

• JWT 기반 인증

• OAuth 2.0

• 기본 인증(HTTPS 필수)

• 상호 SSL 인증

• 역할 기반 접근 제어(RBAC)를 적용한다.

• 강력한 비밀번호 정책을 수립하고 다요소 인증을 적용한다.

• 로그인 시도 제한 및 계정 잠금 정책을 도입한다.

• 토큰과 자격 증명을 안전하게 저장하고 전송한다.

입력 검증 및 데이터 유효성 검사

• 모든 입력 데이터를 서버 측에서 검증한다.

• 화이트리스트 기반의 입력 검증을 수행한다.

• 데이터 타입, 길이 제한, 형식 검증을 적용한다.

• 인젝션 공격(SQL, NoSQL, OS 명령어 등)을 방지하기 위한 입력 값 필터링을 한다.

• 구조화된 데이터(JSON, XML 등)는 스키마 검증을 통해 처리한다.

• 파일 업로드 시 파일 타입과 크기를 제한하고 검증한다.

• 입력 데이터를 표준 형식으로 정규화한다.

보안 헤더 설정

• HTTP 응답에 적절한 보안 헤더를 설정한다:

• Content Security Policy(CSP)

• X-Content-Type-Options: nosniff

• Strict-Transport-Security(HSTS)

• X-Frame-Options: DENY 또는 SAMEORIGIN

• Referrer-Policy

• Permissions-Policy(구 Feature-Policy)

• X-XSS-Protection(레거시 브라우저 대응)

• 모든 응답에 보안 헤더를 포함하고 에러 페이지나 리다이렉트에도 적용한다.

OWASP API Top 10 취약점 대응

• Broken Object Level Authorization: 객체 수준의 접근 제어를 철저히 검증한다.

• Broken User Authentication: 강력한 인증 메커니즘과 안전한 세션 관리를 구현한다.

• Excessive Data Exposure: 필요한 데이터만 응답에 포함하고 민감한 정보를 보호한다.

• Lack of Resources & Rate Limiting: 속도 제한과 자원 사용량 제한을 적용한다.

• Broken Function Level Authorization: 기능별로 적절한 권한 검증을 수행한다.

• Mass Assignment: 데이터 바인딩 시 허용된 필드만 처리하고 민감한 필드는 보호한다.

• Security Misconfiguration: 안전한 기본 설정을 적용하고 불필요한 기능을 비활성화한다.

• Injection: 파라미터 바인딩과 입력 검증을 통해 인젝션 공격을 방지한다.

• Improper Assets Management: API 자산을 체계적으로 관리하고 구버전을 적절히 폐기한다.

• Insufficient Logging & Monitoring: 충분한 로그를 기록하고 실시간 모니터링을 수행한다.

데이터 보호 및 암호화

• 모든 통신에 TLS 1.2 이상을 사용한다.

• 민감한 데이터는 안전한 알고리즘으로 암호화하여 저장한다.

• 암호화 키를 안전하게 관리하고 접근을 통제한다.

• 불필요한 민감 데이터는 저장하지 않으며, 데이터 노출을 최소화한다.

• 암호화 키와 자격 증명을 안전하게 저장하고 처리한다.

로그 및 감사

• 보안 관련 이벤트(인증 시도, 접근 권한 오류, 시스템 오류 등)를 로그로 기록한다.

• 로그에 민감한 정보를 포함하지 않는다.

• 로그의 무결성과 기밀성을 보호한다.

• 이상 징후에 대한 실시간 모니터링과 경보 체계를 구축한다.

• 규제 요구사항에 따라 로그를 보관하고 관리한다.

안전한 디자인 원칙 적용

• 최소 권한 원칙: 사용자와 시스템에 최소한의 권한만 부여한다.

• 실패-안전 기본 설정: 기본적으로 접근을 거부하고 명시적으로 허용된 경우에만 접근을 허용한다.

• 심층 방어: 여러 계층의 보안 대책을 적용하여 보안을 강화한다.

• 책임 분리: 중요한 작업이나 데이터에 대한 접근을 분리하여 관리한다.

• 보안을 고려한 설계: 개발 초기부터 보안을 고려하여 시스템을 설계한다.

• 보안에 의한 가용성: 보안성을 이유로 시스템의 가용성을 저해하지 않는다.

취약점 관리 및 유지보수

• 정기적인 보안 점검과 취약점 스캐닝을 수행한다.

• 소프트웨어와 의존성 라이브러리를 최신 상태로 유지한다.

• 취약점 보고 및 대응 프로세스를 구축한다.

• 보안 정책과 절차를 정기적으로 검토하고 업데이트한다.

• 개발자와 운영자에 대한 보안 교육을 실시한다.

기타 보안 고려사항

• 속도 제한과 트래픽 제어를 통해 서비스 남용을 방지한다.

• IP 화이트리스트나 블랙리스트를 적용한다.

• API 버전 관리를 체계적으로 수행하고 구버전을 적절히 폐기한다.

• 보안 모니터링 및 침입 탐지 시스템을 활용한다.

• CDN과 WAF를 사용하여 DDoS 및 기타 공격에 대비한다.

참고문헌

OWASP API Security Top 10 : https://owasp.org/www-project-api-security/
OWASP ASVS 4.0.3: Application Security Verification Standard : https://owasp.org/www-project-application-security-verification-standard/
OWASP Secure Headers Project : https://owasp.org/www-project-secure-headers/
OWASP Injection Prevention Cheat Sheet : https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
NIST SP 800-63B: Digital Identity Guidelines – Authentication and Lifecycle Management : https://pages.nist.gov/800-63-3/sp800-63b.html
NIST SP 800-95: Guide to Secure Web Services : https://csrc.nist.gov/publications/detail/sp/800-95/final
RFC 7519: JSON Web Token (JWT) : https://datatracker.ietf.org/doc/html/rfc7519
RFC 6749: The OAuth 2.0 Authorization Framework : https://datatracker.ietf.org/doc/html/rfc6749
ISO/IEC 27001: Information Security Management Systems – Requirements : https://www.iso.org/isoiec-27001-information-security.html

(WebGoat) A3. Injection - SQL Injection (Advanced)

SalaYH — Sun, 2 Jun 2024 18:32:36 +0900

이번 세션은 SQL Injection 중 UNION Injection과 Blind Injection에 대한 내용이다.

첫 번째 퀴즈는 UNION Injection을 이용해서 유저의 패스워드 정보를 탈취하는 퀴즈인데,

친절하게도 두 개의 테이블에 대한 정보를 제공해준다.

SQL Injection이 발생하는지 확인하기 위해 쿼리 에러가 발생할 수 있도록 입력값을 구성해서 전달해보니, 에러가 발생하는 것을 알 수 있었다. 이를 통해 SQL Injection이 가능할 수 있다는 것을 알 수 있다.

특히 에러 메시지를 통해 실제 실행되는 쿼리 구문이 무엇인지 까지 전달해주고 있어, SQL Injection에 더욱 도움이 되고 있는 상태이다.

UNION SQL Injection을 할 때에는 테이블명, 필드명을 알아야 할 뿐 아니라, 기존 쿼리로 조회되는 필드 갯수도 맞춰야 하므로, 일반적으로 Blind SQL Injection 등을 이용해서 테이블, 필드명을 확인하고, Union 구문에서는 null을 반복적으로 추가해가면서 실제로 내가 확인하고 싶은 데이터 필드를 확인하게 된다. 그런데 여기서는 테이블 정보를 알려주고 있고, 에러 메시지를 통해 몇 개의 필드가 사용되고 있는지 알 수 있기 때문에, 반복적인 노가다는 패스할 수 있었다. 지금까지 내용을 기반으로 쿼리를 작성하여 전달하면 전체 유저의 패스워드 정보를 확인할 수 있다.

a' or '1'='1' union select userid, user_name, password, NULL, NULL, NULL, NULL from user_system_data where 'a'='a

그럼 이제 문제에서 이야기 한 Dave의 계정정보를 확인해서 제출하면 이번 퀴즈도 끝이다.

코드에서도 알 수 있듯이 입력값을 검증없이 쿼리문에 문자열 결합으로 사용하고 있다.

이는 SQL Injection이 발생할 수 있는 대표적인 사례이며, Exception 등이 발생했을 때 실제 사용되는 query를 응답값에 함께 전달해주고 있어, SQL Injection을 쉽게 할 수 있는 힌트를 제공하게 된다.

src/main/java/org/owasp/webgoat/lessons/sqlinjection/advanced/SqlInjectionChallengeLogin.java

SQL Injection이 발생하지 않도록 하기 위해서는 입력값을 파라미터화 후 바인딩을 하여 쿼리문으로 인식되지 않도록 구성해야 하며, 만약 문자열 결합을 반드시 해야 할 경우에는, 입력값에 쿼리로 인식할 수 있는 특수기호나 예약어가 포함되어 있는지 검증 후 사용되어야 한다. 또한 Exception 등의 에러를 처리하는 과정에서 쿼리 등의 중요정보가 포함되지 않도록 사용자 오류 메시지를 구성하여 전달하도록 코드를 구성해야 한다.

다음은 Blind SQL Injection 이다. 실제 진단을 할 때에는 Blind SQL Injection을 많이 사용한다. 실제 공격이 통한다는 것을 빠르고 간단히 확인할 수 있기 때문이다. 하지만 이 방법으로 실제 데이터를 탈취까지 하려면 많은 노가다가 필요하기 때문에 스크립트 작성까지 진행이 필요하다.

이번 질문은 Tom이라는 유저의 계정으로 로그인하라는 것이다.

정보가 너무 적은데, 우선 Tom의 계정명이 무엇인지 부터 확인해보아야 한다. (대략적으로 tom 부터 시작한다.)

몇 번의 SQL Error을 발생시켜 보았으나 SQL Injection이 발생하지 않는 것으로 보인다. REGISTER 메뉴가 있으니 이번에는 여기를 이용해 본다. 일반적으로 회원등록 시 기존에 계정명이 사용되고 있는지 확인하기 때문에, 이 기능을 통해 Tom의 계정명은 tom인 것을 확인할 수 있다.

이제 본격적으로 Blind SQL Injection을 시도해본다. 입력한 계정명이 조회되는 쿼리가 SQL Injection이 가능하지 않을까 싶어 Blind SQL Injection 구문을 추가해본다. 각 메시지를 확인해보았을 때 username이 존재하지 않으면 계정을 생성하고, 특수기호를 삽입하면 에러가 발생하는 것을 보았을 때. SQL Injection 가능성이 존재할 것으로 보인다.

tom11 계정명 사용 시 계정생성 완료 메시지 전달

tom 이라는 계정명을 사용 시 이미 존재하는 계정명이 사용되었다는 에러메시지 전달

tom' 입력 시 에러발생했다는 메시지 전달

그럼 본격적으로 Blind SQL Injection을 시도해본다.

조회 조건 뒤에 TRUE구문을 and로 함께 전달해보면, 이미 계정이 존재한다는 메시지를 전달한다.

이는 tom이라는 계정이 이미 존재한다는 것을 앞에서 확인했기 때문에, TRUE and TRUE로 조회가 되었다는 것을 알 수 있다.

또한 이번에는 FALSE 구문을 and로 함께 전달해보면 새로운 계정이 생성되었다는 메시지를 전달한다.

이를 통해 계정명을 이용하면 SQL Injection을 이용하여 정보를 탈취하거나 인증우회가 가능할 수 있다는 것을 의미한다.

그럼 이제 본격적으로 tom의 계정정보를 탈취해본다. 실제 패스워드에 대한 입력 파라미터 명을 보았을 때, 테이블에 저장되는 패스워드의 필드명은 password가 높은 확률로 사용될 것이다. (물론 어떤 필드인지 확인하기 위해 여러번의 Blind SQL Injection을 시도해야 하지만, 여기서는 시간을 줄이기 위해 몇가지 예측을 함께 해본다.)

다행히 Password 필드의 길이를 체크하는 구문을 추가해보니 정상적으로 동작하는 것을 알 수 있었다.

그럼 이제 본격적으로 Intruder 등을 이용해서 실제 길이를 체크해본다.

23이 들어갔을 때부터 응답길이가 달라지고, 실제 메시지도 예측한 것처럼 나온다. 이를 통해 패스워드의 길이는 23자리인 것을 알 수 있다.

다음은 실제 23자리의 값을 찾는 것이다. 가장 고전적인 방식은 한자리 씩 substring 한 뒤 ASCII로 변환하여 값을 찾는 것이다.

역시 Intruder를 이용해서 한자리 씩 찾아본다.

첫 번째 문자열의 ASCIISMS 116이므로 소문자 ’t’이다.

이러한 방법을 사용하여 23자리르 모두 반복하면 패스워드를 알 수 있다.

이제 각 소스코드를 확인해보자.

로그인에 사용되는 소스코드를 확인해보면 문자열 결합없이 PreparedStatement를 이용하여 입력값을 파라미터화 및 바인드 처리를 하고 있어, SQL Injection이 불가능했다는 것을 알 수 있다.

src/main/java/org/owasp/webgoat/lessons/sqlinjection/advanced/SqlInjectionChallengeLogin.java

반면에 회원가입을 처리하는 소스코드를 보면 입력받은 ID가 이미 존재하는지 확인하기 위해 사용되는 쿼리가 문자열 결합을 통해 진행되고 있어 쿼리변조가 가능했다는 것을 알 수 있다.

src/main/java/org/owasp/webgoat/lessons/sqlinjection/advanced/SqlInjectionChallenge.java

(WebGoat) A3. Injection - SQL Injection (Intro)

SalaYH — Sun, 31 Mar 2024 22:52:50 +0900

이번 세션은 Injection 취약점 중 SQL Injection에 대한 내용이다.

세션 내용은 기본적인 Query 지식을 시작으로 간단한 SQL Injection 내용을 순으로 다루고 있다.

앞 부분에서 다루고 있는 Query에 대한 내용은 간단히 질문에 해당하는 쿼리구문을 입력만 하면 되는 문제들이므로 넘어가고, 후반부의 SQL Injection 부분을 다뤄본다. 첫 번째 문제는 주어진 쿼리구문이 SQL Injection이 발생하도록 3개의 셀렉트 박스에서 값을 선택해서 실행해보도록 디자인 되어 있다.

쿼리구문이 항상 참이 되도록 아래와 같이 선택하여 문제를 통과한다.

Smith'
or
'1'='1

두 번째는 직접 쿼리를 입력하도록 좀 더 어렵게 퀴즈가 나왔다.

이때 두 필드 중 한개의 필드에서만 인젝션이 가능하다고 나와 있으니, 우선 어떤 필드를 이용해야 할지 확인해본다.

우선 각 항목별로 특수기호 등을 포함하여 오류를 유도해본다. 이때 구문에러 내용을 확인하여 어떤 필드를 사용할지 확인해 본다.

Login_Count 필드에 특수기호 추가

User_Id 필드에 특수기호 추가

이제 두 번째 필드가 SQL Injection에 이용될 수 있는 것을 확인하였으니, 이제 Injection 구문을 추가해보면 이번 퀴즈도 통과다.

Login_Count : 1
User_Id : 1 or 'a'='a'

지금부터는 공격 사례를 들어 퀴즈를 제공하고 있다.

이번 퀴즈에서는 SQL Injection을 통해 타인의 Salary 정보를 확인하는 것이다.

이전에 진행했던 것과 큰 차이가 없이, Where 절이 무조건 True가 나오게 하여 모든 데이터가 나오도록 필드를 입력한다.

3SL99A' or '1'='1

다음은 나의 Salary를 가장 높도록 데이터베이스를 변경하기 위한 SQL Injection 공격을 시도해야 한다.

현재 기능은 조회 기능이므로 값을 변경하기 위한 UPDATE 구문을 사용하기 위해서, 멀티 쿼리가 실행될 수 있도록 필드를 구성한다.

3SL99A'; update employees set salary=90000 where userid=‘37648

마지막 퀴즈는 지금까지 진행했던 Injection 공격 흔적을 제거하는 내용이다.

우선 기록된 내용에 Injection 공격구문이 포함되어 있지 않은 일반 쿼리가 조회되었음으로 로그기록을 변경하도록 쿼리를 변조해 본다.

'; update access_log set ACTION = 'SELECT * FROM employees WHERE last_name = "Smith" AND auth_tan = "3SL99A”’ where 'a'='a

이 방법이 아닌 것으로 보여, 지문을 다시 확인해보니 데이터를 변조하는 것이 아닌 삭제를 요청하는 것으로 보인다.

'; delete from access_log where 'a' = 'a

하지만 질문에서는 레코드 삭제가 아니라 아예 테이블을 삭제해버리는 것을 희망하는 것으로 보인다.

'; drop table access_log; select * from access_log where 'a'='a

이로서 모든 퀴즈를 통과하였다.

이제 마지막 퀴즈에 대한 소스코드를 한번 확인해보자.

src/main/java/org/owasp/webgoat/lessons/sqlinjection/introduction/SqlInjectionLesson10.java

여기서 외부 입력값(action_string)을 쿼리에 문자열 결합으로 다이나믹 쿼리를 생성하고 있으며, 입력값 또한 별도의 필터링 적용없이 사용되고 있다. 이는 전형적인 SQL Injection에서 취약한 쿼리이다. 기본적으로 SQL Injection이 발생하는 취약코드는 외부 입력값을 검증없이 다이나믹 쿼리에 적용하는 것이다.

이를 안전하게 사용하기 위해서 대표적으로 아래와 같은 방법 등이 사용된다.

JPA와 같은 ORM을 사용하여 입력값이 자동으로 파라미터화 및 바인딩되도록 구성
쿼리 실행 객체를 Statement 대신 PreparedStatement를 사용하고, 이때 입력값을 적절한 Set 메서드를 사용하여 쿼리 생성
외부 입력값 내 쿼리를 변조할 수 있는 특수기호 또는 예약어가 포함되어 있는지 필터링을 적용하여 입력값 검증

여기서 조심해야 할 것은 ORM을 사용하더라도 여전히 다이나믹 쿼리를 지원하므로 다이나믹 쿼리를 사용하지 않아야 하고, 만약 외부 입력값을 포함하여 다이나믹 쿼리를 사용해야 한다면 입력값을 필터링 후에 사용되어야 한다. 그리고 PreparedStatement를 사용하더라도, 문자열 결합을 통해 쿼리를 생성해버리면 무의미해지게 되므로, 반드시 외부 입력값을 Set 메서드로 바인딩해야 한다. 상황에 따라 입력값이 다이나믹 쿼리에 포함되어야만 하는 경우가 있는데, 이 때는 필터링을 적용하는 방법을 주로 사용한다. 하지만, 서비스 목적 달성을 위해 어떤 키워드에 대해서 필터링 할 것인지는, 비즈니스 목적에 맞춰 필터링을 커스터마이징 해야 한다. 되도록 정규식으로 정할 수 있는 룰을 만드는 것이 중요하다.