사용자 역할과 권한

Gemini Enterprise의 역할 모델, IAM 매핑, ACL 기반 검색 권한

Gemini Enterprise의 사용자 역할(Role), Google Cloud IAM과의 매핑, 그리고 데이터 소스 ACL이 어떻게 검색 권한으로 이어지는지 정리합니다.

목차

역할 개요
Google Cloud IAM 매핑
ACL 기반 권한 인지 검색
모범 사례

1. 역할 개요

역할	책임	주요 작업
Admin	조직 전체 관리	App 생성/삭제, 라이선스 할당, 데이터 스토어 정책 수립
Editor	특정 App·데이터 운영	데이터 스토어 추가, 에이전트 등록, 검색 튜닝
Viewer	설정 조회	콘솔 열람만 가능, 변경 불가
End User	실제 사용자	Search/Assistant 사용, 자기 권한 범위의 결과 조회

역할 분리의 이유

데이터 스토어를 잘못 변경하면 검색 품질이 즉시 떨어집니다 → Editor와 Viewer 분리 필요.
에이전트는 외부 시스템에 쓰기 작업을 수행할 수 있습니다 → 등록 권한은 신중히 부여.

2. Google Cloud IAM 매핑

Gemini Enterprise의 역할은 내부적으로 다음 IAM Role과 매핑됩니다(명칭은 변경될 수 있음).

Gemini Enterprise 역할	대표 IAM Role
Admin	`roles/discoveryengine.admin`
Editor	`roles/discoveryengine.editor`
Viewer	`roles/discoveryengine.viewer`
End User	`roles/discoveryengine.user` (혹은 OAuth 기반 직접 접근)

부여 예시

# 특정 사용자에게 Editor 권한 부여
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="user:editor@example.com" \
    --role="roles/discoveryengine.editor"

# 그룹에 End User 권한 부여 (권장)
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
    --member="group:gemini-users@example.com" \
    --role="roles/discoveryengine.user"

사용자 단위가 아닌 그룹 단위 부여를 권장합니다. 인사 이동 시 그룹 멤버십만 갱신하면 됩니다.

3. ACL 기반 권한 인지 검색

작동 원리

[원본 데이터 소스 ACL]
        ↓ (커넥터가 색인 시 함께 수집)
[Gemini Enterprise 색인]
        ↓ (사용자 ID로 필터)
[검색/Assistant 응답]

ACL 흐름의 의미

사용자 A가 Confluence 페이지 X에 접근 권한이 없다면, 그 페이지의 내용은 A의 검색 결과에 나타나지 않습니다.
권한이 없는 정보가 LLM 응답에 누설되지 않으므로, 데이터 거버넌스 부담이 줄어듭니다.

주의사항

상황	대응
원본 시스템에서 권한 변경	색인 새로고침 주기까지 반영 지연 가능
권한 위임/공유 링크	커넥터별 지원 범위 확인 필요
익명 공개 페이지	모든 사용자에게 노출됨에 유의

4. 모범 사례

Admin 계정은 최소화: 보통 2~3명만 부여하고 활동을 감사 로그로 추적
그룹 기반 권한: 사용자가 아닌 Cloud Identity / Workspace 그룹에 IAM 부여
정기 권한 리뷰: 분기마다 Admin/Editor 명단 점검
데이터 스토어별 분리: 민감도 높은 자료는 별도 데이터 스토어로 분리하여 노출 그룹 제한
에이전트 등록 승인 절차: 등록·수정 시 코드 리뷰/보안 리뷰 단계 수립

5. 참고 자료