RAG LLM Application 보안 - 인가

인가는 인증된 주체에 부여된 권한을 검증하여, 적절한 권한으로만 자원에 접근하도록 통제하는 것입니다. 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 발생 등)를 로깅/모니터링하여 권한 우회 시도 탐지에 활용하고 있는가?