# Google API 키는 비밀이 아니었다. 그러나 Gemini가 규칙을 바꿨다 > Clean Markdown view of GeekNews topic #27026. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27026](https://news.hada.io/topic?id=27026) - GeekNews Markdown: [https://news.hada.io/topic/27026.md](https://news.hada.io/topic/27026.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-02-26T17:32:57+09:00 - Updated: 2026-02-26T17:32:57+09:00 - Original source: [trufflesecurity.com](https://trufflesecurity.com/blog/google-api-keys-werent-secrets-but-then-gemini-changed-the-rules) - Points: 5 - Comments: 1 ## Summary Google이 오랫동안 “API 키는 비밀이 아니다”라고 안내해 왔지만, **Gemini API 활성화 이후 동일 키가 민감한 인증 수단으로 변하는 구조적 변화**가 드러났습니다. 과거 공개된 Maps·Firebase용 키가 자동으로 Gemini 접근 권한을 얻게 되면서, 공개 코드만으로도 개인 데이터 접근이나 요금 청구가 가능해졌습니다. Google은 누출 키 차단과 **Gemini 전용 기본 설정**을 도입 중이지만, 기존 키의 소급 점검은 아직 완료되지 않았습니다. 개발자는 즉시 프로젝트의 Gemini 활성화 여부와 키 노출 상태를 점검할 필요가 있습니다. ## Topic Body - Google이 10년 넘게 **API 키는 비밀이 아니며 공개해도 안전하다**고 안내해 왔으나, **Gemini API 활성화 이후 동일 키가 민감한 인증 수단으로 변함** - 기존에 **Google Maps, Firebase 등에서 사용되던 공개 키**가 Gemini API 접근 권한을 자동으로 얻게 되어, **공개된 키로 개인 데이터 접근 및 요금 청구 가능** - Truffle Security는 **2,863개의 실사용 Google API 키**가 인터넷에 노출되어 있으며, 이 중 일부는 **Google 자체 서비스의 키**도 포함됨을 확인 - Google은 문제를 인정하고 **누출 키 차단, Gemini 전용 기본 설정, 노출 알림 기능**을 도입 중이나, **기존 키의 소급 점검은 미완료 상태** - 이번 사례는 **AI 기능 통합으로 인한 기존 자격 증명의 권한 확장 위험**을 보여주며, 개발자들은 즉시 **Gemini API 활성화 여부와 키 노출 상태 점검**이 필요함 --- ### 핵심 문제 - Google Cloud는 `AIza...` 형식의 **단일 API 키 구조**를 사용하며, 이는 **공개 식별용**과 **민감 인증용** 두 목적을 동시에 수행 - 과거 Google은 개발자에게 API 키를 **클라이언트 코드에 직접 포함해도 안전하다**고 명시 - Firebase 보안 체크리스트에서도 “API 키는 비밀이 아니다”라고 안내 - 그러나 Gemini API가 활성화되면, **기존 프로젝트의 모든 API 키가 자동으로 Gemini 엔드포인트 접근 권한**을 얻게 됨 - **경고, 확인 절차, 이메일 알림 없이** 권한이 확장됨 - 이로 인해 두 가지 문제가 발생 - **권한의 소급 확장(Retroactive Privilege Expansion)**: 과거 공개된 Maps 키가 Gemini 접근 자격으로 변함 - **불안전한 기본값(Insecure Defaults)**: 새 키 생성 시 기본 설정이 “Unrestricted”로 되어 있어, Gemini 포함 모든 API 접근 가능 - 결과적으로 수천 개의 **청구용 토큰이 실제 인증 자격으로 변해 인터넷에 노출된 상태** ### 공격 가능 시나리오 - 공격자는 웹사이트의 소스코드에서 `AIza...` 키를 복사해 단순한 **curl 요청으로 Gemini API에 접근 가능** - 예: `curl "https://generativelanguage.googleapis.com/v1beta/files?key=$API_KEY"` - 정상 응답(`200 OK`)을 받으면 **업로드된 파일, 캐시 데이터 등 민감 정보 접근 가능** - 공격자는 이를 통해 - **비공개 데이터 접근** (`/files/`, `/cachedContents/` 엔드포인트) - **Gemini API 사용 요금 부과** - **쿼터 소진으로 서비스 중단 유발** - 공격자는 피해자의 인프라를 침입하지 않고, **공개 웹페이지에서 키만 추출**해 공격 수행 가능 ### 공개된 키의 규모 - Truffle Security는 **Common Crawl 2025년 11월 데이터셋(약 700TiB)** 을 분석해 **2,863개의 활성 Google API 키**를 발견 - 이 키들은 원래 **Google Maps 등 공개 서비스용**으로 사용되었으나, Gemini API 접근 권한을 보유 - 피해 대상에는 **금융기관, 보안기업, 글로벌 리크루팅사, 그리고 Google 자체**가 포함 - Google조차 동일한 구조적 위험에 노출되어 있었음 ### Google 내부 키 사례 - Truffle Security는 **Google 제품 웹사이트의 공개 소스코드에 포함된 키**로 Gemini API 접근을 시연 - 해당 키는 **2023년 2월 이전부터 공개되어 있었으며**, 원래는 단순 프로젝트 식별용으로 사용 - `/models` 엔드포인트 호출 시 **정상 응답(200 OK)** 을 반환, **민감 API 접근 가능** 확인 - 즉, **과거 무해했던 키가 개발자 개입 없이 민감 권한을 획득**한 사례 ### 취약점 보고 및 대응 타임라인 - **2025년 11월 21일**: Google VDP에 보고 - **11월 25일**: Google은 “의도된 동작”으로 판단 - **12월 1일~2일**: Truffle Security가 Google 내부 키 사례 제시 후, Google이 **버그로 재분류 및 심각도 상향** - **12월 12일**: Google이 **누출 키 탐지 파이프라인 확장 및 Gemini 접근 제한 조치** 시작 - **2026년 1월 13일**: Google이 취약점을 **“단일 서비스 권한 상승(Single-Service Privilege Escalation, READ)”** 으로 분류 - **2월 2일**: 근본 원인 수정 작업 진행 중 확인 ### Google의 후속 조치 - Google은 공식 문서에서 다음과 같은 **보안 강화 계획**을 발표 - **Scoped defaults**: AI Studio에서 생성된 새 키는 **Gemini 전용 접근만 허용** - **Leaked key blocking**: **누출된 키의 Gemini API 접근 자동 차단** - **Proactive notification**: **누출 키 탐지 시 사용자에게 즉시 알림 발송** - 일부 개선은 이미 진행 중이나, **기존 노출 키의 소급 점검 및 사용자 통보는 미완료** ### 개발자 점검 가이드 - **1단계:** 모든 GCP 프로젝트에서 **Generative Language API 활성화 여부 확인** - **2단계:** 활성화된 경우, **API 키 설정에서 ‘Unrestricted’ 또는 Gemini 포함 키** 식별 - **3단계:** 해당 키가 **공개 코드나 웹페이지에 포함되어 있는지 확인** - 노출된 키는 즉시 **회전(rotating)** 필요 - **보너스:** TruffleHog 도구를 사용해 **Gemini 접근 가능한 실사용 키 자동 탐지** 가능 - 명령 예시: `trufflehog filesystem /path/to/your/code --only-verified` ### 결론 - 이번 사례는 **AI 기능 추가로 인해 기존 공개 자격 증명이 민감 권한을 얻게 되는 구조적 위험**을 보여줌 - Google은 문제를 인식하고 대응 중이나, **안전한 기본값과 키 분리 설계의 중요성**이 다시 부각됨 - 개발자와 기업은 **Gemini API 활성화 여부 및 키 노출 상태를 즉시 점검**해야 함 ## Comments ### Comment 51958 - Author: neo - Created: 2026-02-26T17:32:57+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47156925) - Google AI Studio 문서가 **오픈 프록시**를 통해 앱을 배포하도록 권장하고 있음 이 방식은 API 키가 프록시 뒤에 있으니 안전하다고 착각하게 만들지만, 실제로는 **AI 과금 남용**이 가능해짐 AI 기능이 전혀 없는 앱조차도 키 범위가 수동으로 제한되지 않으면 고비용 모델에 노출됨 이런 취약한 앱들은 Google, Twitter, Hacker News 검색만으로도 쉽게 찾을 수 있음 관련 분석은 [이 글](https://github.com/qudent/qudent.github.io/blob/master/_posts/2026-01-16-aistudio-proxy.md)에 정리되어 있음 - Google이 유출된 키를 차단한다고 하지만, 애초에 그 키들을 **비밀로 취급하지 않았음** Gemini 출시 이전에 생성된 모든 키가 Gemini에 접근하지 못하도록 막는 게 이상적이었음 만약 유출 탐지 시스템이 오탐을 낸다면, 정상적인 Gemini 키까지 차단될 위험이 있음 - 이 문제는 단순히 차단으로 해결될 수준이 아님 최소한 **Generative Language API 권한**을 모든 기존 키에서 제거해야 하지만, 그마저도 완전한 해결책은 아님 결국 모든 키에서 해당 권한을 일괄 제거해야 할 수도 있음 이는 수많은 애플리케이션을 깨뜨릴 것이며, Google이 문제를 인정하지 않으려는 이유가 됨 더 심각한 건 키가 **캐시된 컨텍스트와 업로드 데이터**까지 노출한다는 점임 - 예전 안드로이드 이미지에 하드코딩된 Google 키들이 실제로 Gemini에 사용 가능했음을 발견했음 일부는 이미 많은 사람이 사용 중이라 속도 제한이 걸렸지만, 몇몇은 여전히 작동했음 두 달 전쯤 이 키들이 유출된 것으로 간주되어 모두 비활성화되었음 - 오래전에 생성된 키들이 원래는 Firebase나 Firestore 같은 제한된 서비스용이었음 그런데 Gemini 출시 후, 기존 키에도 Gemini 접근이 **자동으로 활성화**되어 악용이 쉬워졌음 APK 파일에 포함된 공개 키가 그대로 Gemini 접근 키가 되어버린 셈임 - Gemini API는 기본적으로 비활성 상태이지만, 프로젝트 단위로 활성화되면 문제가 생김 예를 들어 개발자 X가 Maps용 키를 만들고, 다른 개발자 Y가 같은 프로젝트에서 Gemini를 켜면 X의 키가 Gemini 접근 권한을 얻게 됨 따라서 **프로젝트 재사용을 피하고**, 서비스별로 분리된 GCP 프로젝트를 써야 함 - 이렇게 명백한 보안 결함이 왜 사전에 걸러지지 않았는지 의문임 Google 같은 대기업이라면 **표준화된 테스트나 스펙**이 있어야 하는데 말임 - Google은 예전의 Google이 아님 조직이 커지고 복잡해질수록 이런 **감시 사각지대**가 오히려 늘어남 - 이런 기본적인 보안 검증을 인터뷰 항목으로 넣자는 제안도 있었지만, 그들은 여전히 **이진 트리 뒤집기** 문제에만 몰두했음 - Google의 진짜 전문성은 **광고 판매**에 있음 - 보안은 여전히 개발자들이 가장 신경 안 쓰는 **마지막 프런티어**임 - 거대한 조직에서는 왼손이 오른손이 뭘 하는지 모르는 경우가 많음 - 이 사태는 과거 **SSN(사회보장번호)** 남용 사례를 떠올리게 함 원래는 단순 식별용 번호였는데, 어느 순간 인증 키로 쓰이기 시작하면서 문제가 커졌던 것처럼 빠르고 싸게 구현하려다 결국 비용은 사용자에게 전가되는 구조임 - Google이 아직 이 문제를 완전히 **해결하지 못한 것처럼 보임** Gemini를 서둘러 출시하려다 생긴 대형 실수이며, 문제를 고치려면 기존 키를 비활성화해야 해서 고객 워크플로우가 망가질 가능성이 큼 Google 입장에서도 매우 **치명적인 이미지 손상**임 - 이건 일종의 **권한 역확장(Retroactive Privilege Expansion)** 문제임 예전 Maps 키를 웹사이트에 공개해뒀는데, 팀의 다른 개발자가 Gemini를 켜면 그 공개 키가 곧바로 Gemini 접근 자격이 되어버림 결과적으로 누구나 그 키로 파일 업로드나 캐시 데이터에 접근할 수 있게 됨 - 새 기능은 기존 키가 아니라 **명시적으로 옵트인한 새 키**에만 적용했어야 함 예전 문서에 따라 공개 키를 사용한 사용자들이 피해를 보고 있음 - 물론 Maps 키를 공개하는 건 원래 위험함 공격자가 그 키를 훔쳐 **과금 폭탄**을 일으킬 수 있음 - 쉽게 설명하자면, 수천 개의 기존 API 키가 단순 과금 토큰에서 갑자기 **Gemini 접근 자격**으로 바뀌어버린 상황임 Maps API 키는 원래 사용자에게 지도 서비스를 제공하면서 내 카드로 결제되도록 설계된 것임 문제는 이런 키들이 이제 Gemini에도 접근할 수 있게 되었다는 점임 내부용 프로젝트를 따로 만들어 키를 분리했어야 했는데, 빠르게 배포하려다 **LLM이 생성한 코드**를 그대로 쓰고, 문제가 생기자 Google 탓을 하는 구조임 - 하지만 실제 문제는 Maps 키가 이제 Gemini의 **민감한 콘텐츠**까지 접근할 수 있다는 점임 - 이 문제를 분석한 보안 회사의 이전 연구도 인상적이었음 예를 들어 [“Anyone can Access Deleted and Private Repository Data on GitHub”](https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github) 글처럼 **삭제된 GitHub 저장소 데이터 접근 취약점**을 밝혀낸 사례가 있음 이번에도 그들의 분석이 큰 도움이 되었음