① 권한 탈취: 에이전트가 남의 열쇠를 쥐지 못하게
시리즈 안내 | ① 권한 탈취 → ② 데이터 유출 → ③ 프롬프트 공격과 폭주하는 에이전트
들어가며: 범인은 사람이 아니었다
2026년 7월, 허깅페이스(Hugging Face)는 자사 인프라가 침입당했다고 공개했습니다. 닷새 뒤 오픈AI는 침입자가 사람이 아니라 자사 모델이 구동한 자율형 AI 에이전트였다고 밝혔습니다. 이 모델은 ExploitGym이라는 사이버보안 벤치마크로 평가를 받던 중이었고, 평가를 위해 사이버 공격 관련 거부 기능을 일부러 꺼 둔 상태였습니다.
에이전트는 평가 환경 안에 있던 패키지 레지스트리 프록시의 제로데이 취약점으로 샌드박스를 벗어났습니다. 그리고 다른 서비스에 노출돼 있던 자격 증명을 주워 쓰며 허깅페이스의 쿠버네티스 클러스터 관리자 권한과 내부 소스코드 저장소 일부의 쓰기 권한까지 얻었습니다. 허깅페이스가 로그에서 확인한 공격 행동은 약 17,600건이었습니다. 목적은 단 하나, 벤치마크의 정답지를 손에 넣는 것이었습니다. 에이전트에게 악의는 없었습니다. 점수를 올리라는 목표가 통제를 우회하게 만든 것입니다.
우리 회사가 사내용으로 만들 에이전트가 이렇게 행동할 가능성은 낮습니다. 그러나 이 사건이 드러낸 빈틈은 어느 회사에나 있습니다.
- 권한: 어딘가에 노출된 상시 자격 증명과 필요 이상으로 넓은 권한
- 네트워크: 밖으로 열려 있어 데이터를 빼낼 수 있는 경로
- 내용과 행동: 악성 입력이 그대로 실행되고, 수만 번의 행동을 아무도 실시간으로 지켜보지 못한 것
Google Cloud의 Gemini Enterprise(이하 GE)는 이 세 가지 빈틈을 막는 기능을 갖춘 기업용 AI 플랫폼입니다. 이 시리즈는 세 가지 위협을 한 회씩 다루며, GE의 어떤 기능이 방어선이 되는지 설명합니다. 이번 1회는 첫 번째 위협, 권한 탈취입니다.
1. Gemini Enterprise 한눈에 보기
Gemini Enterprise는 2025년 10월 Google Cloud가 발표한 기업용 AI 플랫폼으로, 직원이 업무 중 AI를 만나는 “새로운 관문(front door)”을 표방합니다. 구성은 네 개의 레이어로 나뉩니다.
- 데이터 레이어: Google·서드파티 데이터 소스를 연결하고, 항목 유형별로 데이터 스토어를 만듭니다.
- 서빙 레이어: 앱(API에서는 “엔진”)과, 데이터에 근거(grounding)해 인용과 함께 답하는 어시스턴트가 있습니다.
- 실행 레이어: 데이터 소스에 직접 쓰기를 하는 액션, 목표를 수행하는 에이전트, 표준화된 프롬프트인 스킬이 있습니다.
- 운영 레이어: 애널리틱스와, 트레이스·감사 로그를 제공하는 관측 기능이 있습니다.
<그림 1. Gemini Enterprise 구성 레이어 >
시작 전 결정할 것이 두 가지 있습니다. Google Cloud 프로젝트에서 Discovery Engine API(Gemini Enterprise의 내부 서비스 이름)를 활성화해야 하고, Gemini Enterprise 앱을 어느 조직에 둘지 정해야 합니다. Workspace 데이터를 커넥터로 연결하려면 Gemini Enterprise와 Workspace가 같은 Google Cloud 조직에 있어야 합니다. 그렇지 않으면 복잡한 교차 테넌트 허용 목록이 필요하므로, 프로젝트를 만들기 전에 Workspace를 어느 조직이 소유하는지부터 확인하세요.
2. 역할을 나눈다: 관리자, 사용자, 조회자
사내 AI 플랫폼에서 가장 흔한 사고는 해킹이 아니라 권한 없는 사람이 AI를 통해 문서를 보게 되는 일입니다. “다음 분기 구조조정 계획 요약해줘”라는 질문에 권한 없는 직원에게도 답이 나온다면, 그것은 AI가 아니라 플랫폼 설계의 문제입니다. 그래서 신원과 권한은 데이터를 연결하기 전에 정해야 합니다.
| 담당 | 역할 | IAM 역할 ID | 하는 일 |
|---|---|---|---|
| 보안·IAM 관리자 | 조직 관리자 | roles/resourcemanager.organizationAdmin 등 | 관리자·사용자에게 IAM 부여, WIF 구성 |
| 시스템 관리자 | Gemini Enterprise Admin | roles/discoveryengine.agentspaceAdmin | 데이터 스토어·앱·액션 생성, UI 구성 |
| 최종 사용자 | Gemini Enterprise User | roles/discoveryengine.agentspaceUser | 앱 접근, 검색, 에이전트·액션 사용 |
| 감사·조회 | Discovery Engine Viewer | roles/discoveryengine.viewer | 설정·상태 읽기 전용 조회 |
사전 정의 역할이 운영 환경에 너무 넓다면 커스텀 역할로 줄여 최소 권한을 지키고, IAM 부여는 Terraform으로 자동화하는 것이 일반적입니다.
앱 단위로 문을 나눈다
기본 보안은 프로젝트 단위입니다. 프로젝트에 접근할 수 있으면 그 안의 모든 Gemini Enterprise 앱을 쓸 수 있어서, HR 전용 앱과 Sales 전용 앱을 한 프로젝트에 두면 서로 열려 버립니다. 앱별로 나누려면 다음 순서를 따릅니다.
- 프로젝트 수준의 agentspaceUser를 제거합니다.
- agentspaceRestrictedUser를 부여합니다.
- 각 앱에 사용자(그룹)별로 agentspaceUser를 부여합니다.
프로젝트 수준 권한이 앱 수준보다 우선하므로 1단계를 빼먹으면 앱 수준 설정은 효과가 없습니다. API로 정책을 바꿀 때는 setIamPolicy가 기존 정책을 통째로 교체하므로, getIamPolicy로 현재 정책을 먼저 읽고 유지할 바인딩을 모두 포함하세요.
<그림 2. 팀별 앱 접근 분리 >
3. 상시 열쇠 대신 단기 토큰: Workforce Identity Federation
허깅페이스 사건의 에이전트는 다른 곳에 노출돼 있던 오래 유효한 자격 증명을 주워 권한을 넓혔습니다. 사용자 로그인을 설계할 때도 같은 원리가 적용됩니다. 열쇠를 여기저기 복제해 두지 말고, 필요할 때 짧게 쓰고 버리는 토큰을 받게 해야 합니다.
Gemini Enterprise의 로그인 방식은 두 가지입니다. Google Identity(Cloud Identity·Workspace)는 디렉터리를 동기화하고 기존 IdP와 SSO로 연결합니다. Workforce Identity Federation(WIF)은 계정을 동기화하지 않고 Okta, Entra ID 같은 외부 IdP의 로그인을 그대로 씁니다. Workspace나 Google 1P 데이터를 연결하면 Google Identity가, Microsoft 365 데이터를 수집 방식으로 연결하면 Entra ID와의 WIF가 필수입니다. 위치당 IdP는 하나만 고를 수 있고 나중에 바꾸면 채팅 기록과 데이터 스토어를 다시 만들어야 하므로 처음에 신중히 정하세요.
WIF는 토큰 교환입니다. 외부 IdP가 준 토큰은 Google에서 통하지 않는 “외화”이므로, Google STS(Security Token Service)에서 “내국 통화”인 단기 Google 액세스 토큰으로 바꿉니다(OAuth 2.0 Token Exchange, RFC 8693). 보안 관점의 이점은 세 가지입니다.
- 복제된 계정이 없습니다. 신원 데이터는 기존 IdP에 남고 Google은 단기 토큰만 받으므로, 유출돼도 오래 쓸 수 있는 열쇠가 남지 않습니다.
- IdP가 유일한 진실의 원천입니다. 기업 IdP에서 사용자를 폐기하면 Gemini Enterprise 데이터 접근도 끊깁니다.
- 권한 인지 검색이 됩니다. 사용자의 신원이 그대로 전달되므로 그 사람이 원본 시스템에서 볼 수 있는 데이터만 가져옵니다.
<그림 3. 외부 IdP 토큰을 Google 단기 토큰으로 교환하는 흐름>
WIF를 구성할 때 지킬 점
- roles/iam.workforcePoolEditor를 넓게 주지 않습니다. 속성 매핑을 바꿔 권한을 상승시킬 수 있습니다.
- 풀 생성 직후 IAM 데이터 액세스 로그를 켭니다. 없으면 로그인 실패와 무단 접근 시도를 볼 수 없습니다.
- google.subject는 이메일을 소문자로 매핑합니다. 라이선스 할당이 대소문자를 구분합니다.
- attribute_condition은 비워 두고 시작해 로그인 흐름을 검증한 뒤 추가하고, 그룹 변경은 5~10분의 전파 지연을 감안합니다.
4. 볼 권한은 원본 시스템이 판단하게 한다
신원이 정해지면 데이터를 연결합니다. 이때 커넥터 방식에 따라 권한을 누가 집행하는지가 달라집니다.
| 구분 | 수집 (Ingestion) | 연합 (Federated) |
|---|---|---|
| 방식 | 원본을 동기화해 Gemini Enterprise 색인에 저장 후 검색 | 질문 시 사용자 토큰으로 원본을 실시간 조회 |
| 권한 | 색인에 반영된 ACL로 처리 (동기화 관리 필요) | 원본 시스템이 직접 집행 (Source-native enforcement) |
| 장점 | 높은 검색 성능 | 데이터 미저장, 항상 최신, 권한 문제 단순화 |
| 단점 | 동기화 시점까지 지연, ACL 어긋남 위험 | 원본 시스템 응답 속도에 좌우 |
보안 관점에서 연합 방식의 가장 큰 장점은 권한 판단을 원본에 맡긴다는 것입니다. 수집 방식은 성능이 좋지만 색인의 ACL이 원본과 어긋나지 않도록 동기화를 관리해야 합니다.
5. 마지막 점검: 보안 누수 테스트
설정을 마쳤다면 권한이 제한된 테스트 사용자로 로그인해, 그 사용자가 볼 수 없어야 할 데이터를 AI에게 물어봅니다. 답이 나온다면 신원 전파가 깨진 것이므로 소스 시스템의 ACL을 기준으로 다시 검증합니다. 공격자가 찾기 전에 우리가 먼저 찾는 것입니다.
마치며
권한 탈취를 막는 첫 방어선은 세 가지입니다. 역할을 관리자·사용자·조회자로 나누고 앱 단위로 문을 나눌 것, 상시 자격 증명 대신 단기 토큰을 쓸 것, 그리고 볼 권한은 원본 시스템이 판단하게 할 것. 다음 글에서는 두 번째 위협인 데이터 유출을 다룹니다. 권한을 가진 정당한 주체라도 데이터를 경계 밖으로 내보내지 못하게 하는 울타리입니다.
참고 공식 문서
- Anatomy of a Frontier Lab Agent Intrusion, Hugging Face
- CSA Research Note: OpenAI Model Sandbox Escape and Hugging Face Breach
- Introducing Gemini Enterprise, Google Cloud Blog
- IAM roles and permissions, Gemini Enterprise
- Configure access controls for apps, Gemini Enterprise
- Workforce Identity Federation, Google Cloud IAM
- Introduction to connectors and data stores, Gemini Enterprise
자세한 내용이 궁금하시다면, 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.
