제7장 — 접근 제어 구현

LLM Primer III: RAG로 강화하는 엔터프라이즈 AI를 챕터별로 소개하는 시리즈의 일곱 번째 글입니다. 관계형 데이터베이스와 파일시스템을 위해 설계된 권한 모델은 검색에 꼭 맞지 않습니다. 접근의 단위는 더 이상 행이나 파일이 아니라 임베딩이고 — 임베딩은 문서 자체에 잠금이 걸려 있어도 유사도를 통해 원본을 흘릴 수 있습니다.

이 장이 존재하는 이유

제6장은 위협 모델을 만들어 냈습니다. 그것이 함의하는 가장 중요한 통제 — 그리고 초기 프로덕션 시스템의 대부분이 가장 자주 놓치는 통제 — 는 검색 층에서의 접근 제어이며, 그렇게 함으로써 LLM은 사용자가 볼 수 없는 콘텐츠를 결코 보지 않습니다. 순진한 대안인 「생성 시점에 필터링」은 헷갈린 대리자를 짓습니다: 모델은 잠금이 걸린 문서를 이미 읽었고, 그 요지를 패러프레이즈로 흘려 낼 것입니다.

이 장은 동작하는 접근 제어 스택으로 합성되는 네 메커니즘을 걷습니다 — 토대로서의 문서 수준 ACL, 엔터프라이즈의 기존 민감도 레이블과 통합되는 RBAC, 엔터프라이즈 지식의 관계 중심 현실을 위한 ReBAC, 그리고 그 모두 아래에서 도는 사전 필터와 사후 필터의 규율.

7.1 문서 수준 ACL과 메타데이터 필터링

모든 청크는 누가 볼 수 있는지를 압니다. 설명상 구현은 간단합니다. 실패 모드는, 거의 모든 초기 프로덕션 시스템이 적어도 한 번은 틀릴 만큼 미묘합니다. 가장 중요한 세부가 셋. 그래뉼래리티: 긴 보고서에 공개 요약과 기밀 부록이 있고, 청크에 균일하게 복사된 단일 문서 수준 ACL은 부록을 과도 공유하거나 요약을 과소 공유합니다. 규모에서 통하는 패턴은 레이아웃 인지 파싱을 거쳐 섹션 수준 권한을 함께 옮기는 것입니다.

신선도: 권한은 바뀝니다. 인덱싱 시점에 ACL을 청크에 굽고 결코 다시 평가하지 않으면, 거짓말하는 시스템을 얻게 됩니다. 청크 메타데이터에 안정 식별자를 저장하고, 쿼리 시점에 짧은 TTL 캐시 뒤에서 원천 시스템에 대해 살아 있는 ACL을 해석하십시오. 음의 공간: 답이 잠금이 걸린 문서 안에 살고 있다면, 시스템은 환각하거나 자신만만하게 「모릅니다」라고 말해서는 안 됩니다 — 「이 주제에 자료가 있지만 당신은 그것을 볼 권한이 없습니다」라고 말해야 합니다. 그러려면 두 번째 필터링 없는 호출이 필요하거나, 벡터 데이터베이스가 「매치 없음」과 「매치되었지만 필터링됨」을 구분해야 하며, 대부분의 구현은 이 부분을 미뤄 둡니다.

7.2 RBAC와 Microsoft Purview 민감도 레이블

RBAC는 권한 공간을 압축합니다 — 사용자-문서 간선 수백만 개 대신, 정책은 역할-분류 간선 수백 개로 줄어들고, 이는 감사 가능하고 유지 가능합니다. 엔터프라이즈가 이미 RBAC 위에 굴러가고 있다면 RAG에 깔끔하게 들어맞습니다. Microsoft 환경에서는 그것이 Entra ID 그룹과 Purview 민감도 레이블을 의미합니다: 공개, 일반, 기밀, 극비, 그리고 선택적 하위 레이블. 레이블은 문서와 함께 움직이고, 파서는 인덱싱 시점에 그것을 읽어 안정 레이블 ID를 청크 메타데이터에 씁니다.

통합은 단순하지만, 드리프트는 그렇지 않습니다. 인덱서가 무엇이든 복호화할 수 있는 서비스 계정으로 돌고, 그 위에 검색 시스템이 역할 기반 필터를 강제한다면, 일반에서 기밀로 재레이블된 문서는 — 인덱서가 그 변경을 알아채지 않는 한 — 이미 인덱싱된 청크가 재레이블되지 않습니다. 이를 맞게 하는 시스템은 원천에 대한 지속 조정을 돌립니다. 틀리는 시스템은 감사 중에 드리프트를 발견하고, 그 발견은 무겁습니다.

7.3 Zanzibar와 SpiceDB로 가는 ReBAC

RBAC는 「세일즈 부서에 있으면서 동시에 Acme Corp 거래에 배정된 누구든」을 표현하지 못합니다. 그것은 단순한 역할이 아니라 사용자와 자원 사이의 관계에 대한 추론을 요구합니다. 구글의 Zanzibar 논문에서 형식화되고 SpiceDB와 OpenFGA로 오픈소스에서 사용 가능한 관계 기반 접근 제어는 그래프를 저장합니다: 「Alice는 엔지니어링의 멤버」, 「엔지니어링은 폴더 Specs의 뷰어」, 「Spec-101은 Specs에 있음」. 권한 검사가 그래프 순회가 됩니다.

RAG와의 통합 패턴은 깔끔합니다. SpiceDB는 이 사용자가 볼 수 있는 문서가 무엇입니까?라는 질문을 받아 문서 ID 목록을 돌려주고, 검색 시스템은 그 목록을 벡터 검색에 메타데이터 필터로 넘깁니다. Zanzibar의 주키(zookie)는 검색 호출이 방금 부여된 접근만큼은 최신의 일관성을 요구하도록 합니다 — 10시 정각에 프로젝트에 추가되어 10시 1분에 질문을 던지는 사용자가 새 문서를 보게 됩니다. 운영 비용은 SpiceDB가 HA와 사용자별 문서 목록의 공격적인 짧은 TTL 캐싱이 필요한 쿼리 경로의 핵심 의존성이 된다는 점입니다. 성숙한 시스템은 종종 RBAC와 ReBAC를 함께 씁니다 — 광범위한 민감도 정책에는 RBAC, 세밀한 관계 정책에는 ReBAC를, 허용된 집합의 교집합으로 결합합니다.

7.4 사전 필터, 사후 필터, 그리고 그 모두 아래의 규율

사전 필터링은 벡터 검색 전에 인가 술어를 적용합니다 — 인덱스가 먼저 후보 집합을 제한하고, 그 제한 위에서 유사도를 돌립니다. 개념적으로 깔끔하고 안전한 기본값이지만, 성능은 인덱스 구조에 달려 있습니다. 매우 선택적인 필터를 가진 HNSW는 그래프 순회가 매치되지 않는 노드를 많이 지나며 가파르게 퇴화할 수 있고, Weaviate와 Qdrant의 filterable-HNSW 변종, Pinecone과 Milvus의 테넌트별 네임스페이스는 비용을 완화하지만 없애지는 않습니다.

사후 필터링은 순서를 뒤집습니다. HNSW의 전속력, 약해진 보안: top-K 누수, 타이밍 기반 정보 누수, 그리고 전체 top-K가 필터로 사라질 때의 정확성 누수. 실용적인 프로덕션 답은 둘을 층층이 쌓는 것입니다 — 가장 거칠고 빠른 술어(테넌트, 광범위한 역할)에는 사전 필터, 비싸고 정밀한 술어(SpiceDB 목록, Purview 레이블)에는 사후 필터, 그리고 사후 필터에도 충분한 순위 집합이 남도록 top-10 대신 top-50으로 과 회수합니다. 누수 자리가 두 곳 더 있습니다: 기밀 문서 제목을 인용하는 프롬프트 템플릿과, 쿼리 문자열만으로 키를 만든 응답 캐시. 둘 모두 인가 표면의 일부가 되어야 합니다.

제7장이 준비하는 것

접근 제어는 누가 무엇을 볼 수 있는지에 답합니다. 가둘 무엇이 있다는 것을 가정합니다. 청크가 그 형태로 임베드되었어야 했는지는 묻지 않습니다 — 고객 이름, 사회보장번호, 독점 코드 경로가 올바른 인가만 떨어지면 표면화되기를 기다리며 벡터 스토어에 앉아 있어도 되는지. 그것이 비식별화의 질문이고, 다음 장의 주제입니다.

다음 → 제8장: RAG 파이프라인의 데이터 비식별화. 생성 전 대 생성 후, 마스킹 대 합성 치환 대 차분 프라이버시, 그리고 모든 선택이 통과해야 하는 효용-프라이버시 트레이드오프.