로깅과 모니터링은 시스템 활동을 기록하고 이상 징후를 실시간으로 감시하는 영역입니다. 제로 트러스트 환경에서는 지속적인 모니터링을 통해 정책을 개선하고 위협에 대응하는 것이 필수이며, LLM 애플리케이션에서도 사용자 활동, 모델 사용 내역, 보안 이벤트를 모두 기록하여 추적 가능하고 분석 가능해야 합니다. 또한 실시간 모니터링으로 침해 시도를 빨리 탐지하고 차단하는 체계를 갖춰야 합니다. 위협 (STRIDE):스푸핑: 적절한 모니터링이 없으면, 공격자가 시스템 내에서 악의적 활동을 해도 정상 사용자로 위장하여 지나칠 수 있습니다. 예를 들어 공격자가 탈취한 계정으로 행동해도 모니터링이 그 사용자의 일반 패턴과 비교해 이상함을 탐지 못하면 알아채지 못합니다.변조: 공격자가 로그를 임의로 조작하거나 삭제하여..
애플리케이션 보안은 LLM 애플리케이션 자체의 코드 및 운영 상 취약점을 식별하고 제거하는 영역입니다. RAG LLM 앱은 일반 웹/모바일 애플리케이션의 취약점에 더해 프롬프트 기반의 새로운 공격 벡터를 갖습니다. 예를 들어 프롬프트 인젝션을 통해 LLM의 의도치 않은 동작을 유발하거나, LLM이 생성한 출력을 악용하는 다운스트림 공격이 존재합니다. 따라서 전통적인 OWASP Top 10 웹 취약점 (XSS, SQL Injection 등)과 OWASP LLM Top 10에 나온 취약점 모두에 대비한 설계가 필요합니다. 위협 (STRIDE)스푸핑: 공격자가 애플리케이션의 합법적 부분(예: 다른 사용자나 서비스)인 것처럼 위장하여 악성 입력을 주입하거나 응답을 가로챌 수 있습니다. (예: 프롬프트에 시스템 ..
데이터 보호는 저장 중이거나 전송 중인 데이터의 기밀성, 무결성, 가용성을 보장하고, 민감 정보의 유출을 방지하는 것을 의미합니다. RAG LLM 시스템에서는 프롬프트/응답 내용, 벡터 DB의 지식베이스, 대화 기록, 사용자 개인정보 등이 모두 보호 대상입니다. 제로 트러스트 환경에서는 내부 네트워크도 불신해야 하므로, 데이터는 항상 암호화하고 접근을 엄격히 통제해야 합니다 . 또한 AI 서비스 특성상 훈련 데이터 및 모델 자산 보호도 중요한 부분입니다 (모델 유출 방지 등). 위협 (STRIDE)스푸핑: (데이터 측면에서는 주로 무결성 관련 이슈) 공격자가 데이터 접근 권한을 위조하여 무단으로 데이터에 접근하거나 변조할 수 있습니다. 예를 들어 API 요청에 위조된 자격증명을 포함해 저장된 벡터 임베딩..
인가는 인증된 주체에 부여된 권한을 검증하여, 적절한 권한으로만 자원에 접근하도록 통제하는 것입니다. RAG LLM 서비스에서는 사용자별로 볼 수 있는 데이터 제한, 기능별 관리자/일반 사용자 권한 차등, 마이크로서비스 간 권한 위임 등이 중요합니다. 제로 트러스트 맥락에서 모든 요청에 최소 권한 원칙을 적용하고, 접근 시마다 정책에 따라 권한을 재평가해야 합니다 . 위협 (STRIDE)스푸핑/권한 도용: 인증을 통과한 사용자가 다른 사용자인 척하면서 그들의 데이터나 기능에 접근할 수 있습니다. 예를 들어 URL이나 ID를 바꿔치기(IDOR 취약점)하여 남의 대화 히스토리나 프롬프트 결과를 열람하는 행위가 가능합니다.변조: 클라이언트 측에서 권한 정보(예: JWT의 role 클레임 등)를 조작하여 더 높..
인증은 사용자나 서비스의 신원을 확인하는 과정입니다. RAG 기반 LLM 애플리케이션에서는 최종 사용자, 내부 마이크로서비스, 외부 API 호출 등 다양한 주체에 대한 강력한 인증이 필수입니다. 제로 트러스트 원칙에 따라 모든 주체를 사전에 신뢰하지 않고, 모든 접근 요청마다 엄격한 신원 확인이 이루어져야 합니다 . 위협 (STRIDE)스푸핑(Spoofing): 공격자가 합법적 사용자나 서비스를 가장하여 LLM 애플리케이션에 접근할 수 있습니다. 예를 들어, 피싱이나 크리덴셜 탈취를 통해 토큰이나 세션을 가로챔으로써 공격자가 사용자로 위장할 수 있습니다.변조(Tampering): 인증 토큰이나 세션 ID가 탈취·위조되어 무단으로 사용될 수 있습니다. 전송 중 토큰이 노출되거나 위변조되면 인증 체계를 우회..
기업 내 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 애플리케이션에 대한 체계적인 ..
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. ..
인증 및 권한 부여 • API Gateway를 사용하여 인증 및 권한 관리를 중앙화한다. • 적절한 인증 방식을 구현한다: • API 키 기반 인증 • JWT 기반 인증 • OAuth 2.0 • 기본 인증(HTTPS 필수) • 상호 SSL 인증 • 역할 기반 접근 제어(RBAC)를 적용한다. • 강력한 비밀번호 정책을 수립하고 다요소 인증을 적용한다. • 로그인 시도 제한 및 계정 잠금 정책을 도입한다. • 토큰과 자격 증명을 안전하게 저장하고 전송한다. 입력 검증 및 데이터 유효성 검사 • 모든 입력 데이터를 서버 측에서 검증한다. • 화이트리스트 기반의 입력 검증을 수행한다. • 데이터 타입, 길이 제한, 형식 검증을 적용한다. • 인젝션 공격(SQL, NoSQL, OS 명령어 등)..

이번 세션은 SQL Injection 중 UNION Injection과 Blind Injection에 대한 내용이다. 첫 번째 퀴즈는 UNION Injection을 이용해서 유저의 패스워드 정보를 탈취하는 퀴즈인데, 친절하게도 두 개의 테이블에 대한 정보를 제공해준다. SQL Injection이 발생하는지 확인하기 위해 쿼리 에러가 발생할 수 있도록 입력값을 구성해서 전달해보니, 에러가 발생하는 것을 알 수 있었다. 이를 통해 SQL Injection이 가능할 수 있다는 것을 알 수 있다. 특히 에러 메시지를 통해 실제 실행되는 쿼리 구문이 무엇인지 까지 전달해주고 있어, SQL Injection에 더욱 도움이 되고 있는 상태이다. UNION SQL Injection을 할 때에는 테이블명, 필드명을 알..

이번 세션은 Injection 취약점 중 SQL Injection에 대한 내용이다. 세션 내용은 기본적인 Query 지식을 시작으로 간단한 SQL Injection 내용을 순으로 다루고 있다. 앞 부분에서 다루고 있는 Query에 대한 내용은 간단히 질문에 해당하는 쿼리구문을 입력만 하면 되는 문제들이므로 넘어가고, 후반부의 SQL Injection 부분을 다뤄본다. 첫 번째 문제는 주어진 쿼리구문이 SQL Injection이 발생하도록 3개의 셀렉트 박스에서 값을 선택해서 실행해보도록 디자인 되어 있다. 쿼리구문이 항상 참이 되도록 아래와 같이 선택하여 문제를 통과한다. Smith' or '1'='1 두 번째는 직접 쿼리를 입력하도록 좀 더 어렵게 퀴즈가 나왔다. 이때 두 필드 중 한개의 필드에서만 인..
- Total
- Today
- Yesterday