지난 3년 동안 AI 환경은 엄청난 변화를 겪었습니다. 기본 언어 모델에서 본격적인 AI 에이전트 단 몇 년 안에 우리를 대신해 행동할 수 있는 인공지능이 등장할 것입니다. AI는 모든 곳에서 새로운 유행어입니다. 우리 모두 농담처럼 말하지만 실제로는 엄청난 붐을 일으키고 있으며 매우 강력합니다. 그리고 보시다시피 AI는 새로운 것이 아닙니다. 오래 전부터 사용되어 왔지만 2023년 LLM과 생성형 AI가 도입된 이후 그 사용이 급증했습니다.
AI를 활용한 생산성 향상의 잠재력은 크지만, AI 에이전트와 같은 자율 시스템으로 작업할 때는 보안 문제를 해결해야 합니다. 데이터에 대한 액세스 정책을 잘못 구성하면 AI가 민감한 내부 문서를 검색하거나 기밀 데이터가 노출될 수 있습니다. 따라서 이 블로그에서는 AI 시스템이 규모와 속도에 맞는 컨텍스트 기반의 문서 수준 권한이 필요할 때 기존의 접근 제어 접근 방식이 어떻게 부족한지 살펴봅니다. 또한 세분화된 권한 부여(FGA)가 검색 증강 세대(RAG) 및 에이전트 AI 시스템을 위한 강력한 보안을 제공하는 방법에 대해서도 설명합니다. 따라서 민감한 정보를 보호하는 동시에 AI가 승인된 데이터에만 액세스할 수 있도록 하는 권한 모델을 구현하는 방법을 알아보세요.
변화하는 AI 환경과 보안 격차
AI 에이전트는 API를 호출하고 오류를 통해 학습하며 때로는 사람의 감독 없이도 작업을 수행하여 사람을 대신하여 작업을 수행합니다. 하지만 이러한 빠른 성장에는 당연히 위험도 따르며, 그 중 가장 큰 위험 중 하나는 보안입니다. 우리는 여러 트윗을 보았을 뿐만 아니라 업계 내 많은 사람들이 인공지능과 인공지능 에이전트를 활용할 때 보안과 인증의 중요성에 대해 논의하는 것을 들었습니다. 현재 AI를 애플리케이션에 안전하게 구축하기 위한 보편적인 청사진은 존재하지 않습니다.
OWASP는 LLM 애플리케이션 상위 10위 2023은 AI 애플리케이션과 관련된 보안 문제를 강조하고 해결하기 위한 커뮤니티 주도의 노력으로, 2025년에는 상위 10가지 사항이 있습니다. 그 중 하나는 민감한 정보 공개입니다. AI 에이전트는 자율적이기 때문에 적절한 처리를 하지 않으면 민감한 정보나 기업 기밀 데이터가 노출될 수 있으며, 이는 고의적인 공격이나 실수로 발생할 수 있습니다.
AI는 데이터에 액세스할 때 사용자 권한을 고려해야 합니다. 에이전트가 기존 기록을 수정하거나 런타임에 다른 직원에게만 제한된 문서에 액세스할 수 없도록 하려면 어떻게 해야 할까요?
그 해답은 권한 부여. 우리 인공지능이 시스템은 올바른 사용자에게만 올바른 정보를 표시합니다.
기존 인증이 부족한 이유
역할 기반 액세스 제어: RBAC는 사람들이 애플리케이션과 웹사이트에서 권한 부여를 구현하는 가장 일반적인 방법입니다. RBAC를 사용할 때는 역할을 확인합니다. 액세스 결정을 내리기 전에 사용자에게 특정 역할이 할당되어 있는지 여부를 확인합니다. 역할이 있는 경우 액세스 권한이 부여되고, 없는 경우 403 금지됨 오류가 발생합니다. RBAC의 가장 큰 단점은 주로 확장성입니다. 역할이 여러 개일 때는 잘 확장되지 않습니다.
속성 기반 액세스 제어(ABAC): ABAC는 세분화된 액세스를 위해 RBAC에서 한 단계 발전한 것으로, 일부 사용자에게는 개별 문서에 대한 액세스 권한을 부여하고 다른 사용자에게는 다른 문서에 대한 액세스 권한을 부여할 수 있습니다.
그러나 문서가 중첩된 폴더에 있는 경우에는 여전히 부족하며, 모든 폴더를 재귀적으로 체인 위로 검색해야 합니다. 사용자가 중첩된 그룹에 있는 경우에도 동일한 작업을 수행해야 합니다. 그리고 요청을 승인하려면 이 모든 작업을 수행해야 합니다.
그렇다면 인증을 수행하는 더 나은 방법은 무엇인지 살펴봅시다. 바로 이 부분에서 ReBAC(관계 기반 액세스 제어)가 등장합니다. ReBAC을 사용하면 시스템 내 사용자와 개체가 서로 맺고 있는 관계를 기반으로 권한 부여 규칙을 표현할 수 있습니다. ReBAC 서비스는 권한 부여 결정에 도달하기 위해 시스템 내 여러 엔터티 간의 관계에 대한 지식을 사용합니다. RebAC의 장점은 이러한 관계를 어떻게 정의하느냐에 따라 RBAC와 ABAC를 모두 수행할 수 있다는 것입니다.
세분화된 권한 부여 - 누락된 계층
세분화된 권한 부여(FGA) 에서 액세스 규칙을 동적으로 적용합니다. 리소스 수준. FGA는 포괄적인 권한을 부여하는 대신 쿼리 시점에 사용자가 볼 수 있는 문서를 정확히 결정합니다.
FGA는 누가 어떤 종류의 리소스로 무엇을 할 수 있는지를 개별 수준까지 제어하는 것입니다. 역할 기반 시스템을 보여주는 일반적인 시나리오에서는 “관리자는 모든 것을 볼 수 있지만 일반 사용자는 일부 하위 집합만 볼 수 있습니다.”라고 말할 수 있습니다. 하지만 실제 앱, 특히 많은 문서를 다루는 앱에서는 이러한 방식이 충분히 유연하지 않을 수 있습니다. 이것이 바로 OpenFGA가 필요한 이유입니다.
OpenFGA 는 CNCF에서 호스팅하는 오픈 소스 프로젝트입니다. 이 프로젝트는 Google의 모든 서비스에 대한 권한 부여 방식을 설명하는 Google의 잔지바르 시스템에서 영감을 받았습니다. OpenFGA는 권한 부여 관계를 정의할 수 있도록 함으로써 위의 문제를 해결합니다. 권한 부여 모델에 정의된 관계는 직접 또는 간접 관계일 수 있습니다. 간단히 말해, 직접 관계는 사용자와 개체 간에 직접 할당되어 데이터베이스에 저장됩니다. 간접 관계는 데이터와 권한 부여 모델을 기반으로 유추할 수 있는 관계입니다.
OpenFGA ReBAC 설정
OpenFGA에 대한 4가지 주요 개념과 작동 방식이 있습니다:
-
- Store: 스토어는 권한 부여 모델과 튜플을 구성하는 데 사용되는 OpenFGA 엔티티입니다. 말 그대로 데이터를 저장하는 곳입니다.
- 권한 부여 모델: 권한 부여 모델은 누가 어떤 조건에서 어떤 작업을 수행할 수 있는지 정의하는 곳입니다. 이것이 바로 모델에 표현된 권한 부여 정책이 됩니다. 모델에서는 권한 부여 결정을 내릴 때 관련성이 있는 엔티티를 정의해야 합니다.
- 관계 튜플: 관계 튜플은 사용자, 관계 및 개체로 구성된 기본 튜플 또는 트리플렛입니다. 튜플은 권한 부여 시스템의 “팩트'라고 생각할 수 있습니다. 사용자 대 객체 관계의 한 형태가 있습니다. 관계 튜플에 있는 데이터는 기본적으로 시스템의 상태를 정의하며, 시스템 상태가 발전함에 따라 튜플을 수정합니다.
- 쿼리: 마지막으로, 이를 사용하여 인증을 확인하려면 시스템을 쿼리할 수 있어야 합니다. 그리고 이 질문에 답하기 위해 OpenFGA 시스템이 하는 일은 그래프를 가로지르는 것입니다. 따라서 FGA 시스템은 리소스(경비 보고서)에서 시작하여 위에서 아래로 다음과 같이 질문합니다.
요약하면, 관계 튜플의 데이터가 그래프를 정의합니다. 권한 부여 모델은 그래프를 탐색하기 위한 규칙을 정의합니다. 그리고 시스템에 쿼리하면 쿼리는 규칙에 따라 그래프를 탐색하고 결과에 따라 “예, 권한이 있습니다” 또는 “아니오, 권한이 없습니다”를 반환합니다.
OpenFGA 관계 기반 액세스 제어
|
1 2 3 4 5 6 7 8 9 10 11 12 |
# Model definition type user type team relations define member: [user] type document relations define viewer: [team#member] # Relationship tuples team:finance#member@user:kate document:forecast.pdf#viewer@team:finance |
의미: Kate는 해당 문서에 대한 보기 권한이 있는 재무 팀의 멤버이기 때문에 forecast.pdf를 볼 수 있습니다.
RAG AI 파이프라인에서 FGA 구현하기
RAG는 LLM의 한계를 극복하고 보다 정확하고 상세한 답변을 제공하기 위해 고안된 프레임워크입니다. LLM은 방대한 데이터 세트에 대한 훈련을 받았지만 전문 지식, 최신 정보, 사실과 다른 결과물, 즉 “환각”을 생성하는 데 어려움을 겪는 경우가 많습니다. RAG는 외부 소스에서 관련 데이터를 실시간으로 동적으로 검색하여 이러한 문제를 완화합니다.
RAG 시스템은 사전 학습된 지식에만 의존하는 대신 도메인별 데이터를 검색합니다. 이는 데이터가 공개되어 있거나 자유롭게 공유할 수 있는 경우에 유용합니다. 하지만 일부 데이터가 제한되거나 기밀인 경우에는 어떻게 해야 할까요? 각 사용자가 볼 수 있는 권한이 있는 정보에만 액세스할 수 있도록 해야 한다는 중요한 과제가 발생합니다. 안전한 RAG 시스템은 속도나 확장성을 희생하지 않으면서도 세분화된 액세스 제어를 시행할 수 있어야 합니다. 역할이 변경되고 프로젝트가 재할당될 수 있으며 시간이 지남에 따라 권한이 진화할 수 있습니다. 이 모든 것을 효율적으로 처리하는 것이 진정으로 안전하고 견고한 RAG 애플리케이션을 구축하는 핵심입니다.
바로 이 지점에서 OpenFGA가 등장합니다. OpenFGA를 RAG 파이프라인과 통합하면 액세스 제어 로직을 핵심 RAG 애플리케이션에서 분리할 수 있습니다. 실시간으로 권한 모델을 적용하고, 검색된 컨텍스트가 응답을 생성하기 위해 LLM으로 전송되기 전에 항상 사용자 권한에 따라 필터링되도록 할 수 있습니다.
다음과 같은 벡터 데이터베이스와 통합할 때 카우치베이스, 를 구현하는 데는 크게 두 가지 전략이 있습니다:
1. 필터링 후
-
- 카우치베이스 벡터 검색에서 문서 검색하기
- 결과를 OpenFGA로 전달하여 승인되지 않은 문서를 제거합니다.
- 필터링된 결과를 AI 모델에 보내기
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 |
def search_authorized_documents(self, query: str, user_id: str, top_k: int = 5) -> List[Dict[str, Any]]: """Search for documents using the pre-query filtering pattern""" try: # Step 1: Get authorized document IDs from OpenFGA authorized_docs = self.get_authorized_documents(user_id) if not authorized_docs: print(f"No authorized documents found for user: {user_id}") return [] # Step 2: Generate embedding for search query query_embedding = self.generate_embeddings(query, "text-embedding-ada-002") # Step 3: Perform vector search with metadata filter for authorized documents search_req = SearchRequest.create(MatchNoneQuery()).with_vector_search( VectorSearch.from_vector_query( VectorQuery("embedding", query_embedding, num_candidates=top_k * 2) ) ) # Execute search result = self.scope.search(self.search_index_name, search_req) rows = list(result.rows()) # Step 4: Filter results to only include authorized documents authorized_results = [] for row in rows: try: # Get the full document doc = self.collection.get(row.id) if doc and doc.value: doc_content = doc.value doc_source = doc_content.get("source", "") # Check if this document is in the authorized list if doc_source in authorized_docs: authorized_results.append({ "id": row.id, "text": doc_content.get("text", ""), "source": doc_source, "score": row.score, "metadata": doc_content.get("metadata", {}) }) # Stop if we have enough results if len(authorized_results) >= top_k: break except Exception as doc_error: print(f"Could not fetch document {row.id}: {doc_error}") return authorized_results |
2. 사전 필터링
-
- OpenFGA를 호출하여 승인되지 않은 문서를 제거하세요.
- 벡터 검색 쿼리에 사전 필터를 추가하여 검색 범위를 제한합니다.
- 사용자가 액세스할 수 있는 문서에 대한 임베딩만 검색합니다.
RAG를 사용한 FGA의 예
개발자가 AI 비서를 사용하여 회사의 예측을 얻고자 한다고 가정해 봅시다. 이 경우 시스템은 재무팀에만 공개되는 비공개 재무 보고서가 아닌 공개 예측 데이터만 볼 수 있도록 해야 합니다. 적절한 안전장치가 없다면 이는 민감한 정보 공개 위험에 해당하며, LLM 애플리케이션에 대한 OWASP Top 10에서 강조하는 문제와 정확히 일치합니다.
세분화된 권한 부여(FGA)로 이 문제를 해결하는 방법은 다음과 같습니다:
1단계 - 권한 확인: OpenFGA가 액세스 권한을 확인합니다. 액세스 권한이 재무팀에 속하지 않으면 비공개 재무 문서가 제외됩니다.
2단계 - 필터링: OpenFGA(SDK를 통해)는 사용자에게 표시되지 않아야 하는 결과를 필터링합니다.
3단계 - 문서 검색: 적용된 필터로 벡터 검색을 수행하여 사용자가 볼 수 있도록 허용된 문서만 검색합니다.
4단계 - 답변 생성: LLM은 승인된 문서 하위 집합에서만 응답을 생성합니다.
실제 애플리케이션
AI 애플리케이션에 세분화된 인증을 적용하면 많은 이점이 있습니다. 몇 가지 인기 있는 사용 사례를 살펴보겠습니다:
-
- 멀티 테넌트 SaaS: 한 테넌트의 AI 쿼리는 다른 테넌트의 데이터를 검색하지 않습니다.
- 헬스케어: 권한이 있는 의료진으로만 제한되는 환자 기록 검색
- 금융: 관련 팀만 액세스 가능한 민감한 예측 및 규제 데이터
- 법률: 의뢰인-변호사 배정에 따라 제한되는 사건 문서
최종 생각: 속도 저하 없는 보안
적절한 보안이 없으면 에이전트 AI를 사용하는 애플리케이션에 완전히 새로운 공격 표면이 추가될 위험이 있습니다. 이제 AI 애플리케이션은 민감한 사용자 데이터를 처리하며 단순히 정보를 처리하는 데 그치지 않고 API와 상호 작용하고, 의사 결정을 자동화하며, 사용자를 대신하여 행동합니다.
에이전트는 사용자 데이터에 대한 최소 권한 액세스, 비정적 액세스 자격 증명, 세분화된 액세스 제어 기능을 갖춰야 합니다. OpenFGA는 앱에서 AI를 보호하는 동시에 에이전트 에코시스템이 성장함에 따라 애플리케이션이 수억 명의 활성 사용자를 원활하게 확장할 수 있는 방법을 제공합니다.
따라서 OpenFGA로 구동되고 Couchbase Vector Search와 통합된 세분화된 인증은 AI 시스템의 강력함과 안전성을 모두 보장하여 보안에 영향을 주지 않으면서 AI 혁신을 실현합니다.
