Google API 키는 비밀이 아니었지만 Gemini가 규칙을 변경했습니다.

"Public by Design"이 보안 책임이 되는 경우

거의 20년 동안 Google 생태계를 구축하는 개발자들은 미묘하지만 중요한 교훈을 배웠습니다. Google API 키는 실제로 비밀이 아닙니다. YouTube 데이터 API 키를 JavaScript 파일에 삽입해도 Google은 놀라지 않았습니다. Maps API 키가 공개 GitHub 저장소에 표시된 경우 보안 응답은 본질적으로 어깨를 으쓱하고 도메인 제한을 설정하라는 알림이었습니다. 전체 모델은 이러한 키가 클라이언트 측 코드에 존재하고 DevTools를 연 모든 사람에게 노출된다는 가정을 바탕으로 구축되었습니다.

그 철학은 오랫동안 의미가 있었습니다. 도메인 제한 없이 노출된 Maps API 키는 예상치 못한 비용을 청구할 수 있지만 환자 기록을 손상시키거나 은행 계좌를 고갈시키지는 않습니다. 폭발 반경은 재정적으로 관리 가능했습니다. Google의 도구(리퍼러 제한, IP 허용 목록, 할당량 제한)는 노출을 완전히 방지하는 것이 아니라 피해를 억제하도록 설계되었습니다.

그런 다음 Gemini가 도착하고 규칙이 변경되었습니다. 문제는 수백만 명의 개발자가 메모를 받지 못했다는 것입니다.

이제 개발자를 지치게 만드는 레거시 정신 모델

이전 Google 개발자 환경은 의도적으로 허용되었습니다. Maps JavaScript API 키를 생성할 때 문서에서는 실제로 이를 HTML에 직접 삽입하도록 권장했습니다. 보안 모델은 비밀이 아니라 제한이었습니다. 도메인에 대한 키를 잠그고 할당량 알림을 설정한 후 계속 진행합니다. 이는 실용적인 엔지니어링이었습니다. 클라이언트 측 애플리케이션은 실제로 결정된 사용자로부터 비밀을 유지할 수 없으므로 Google은 이러한 현실을 인정하는 시스템을 구축했습니다.

이로 인해 Google API 키가 Stripe 비밀 키나 AWS 액세스 자격 증명과는 다른 정신적 범주를 차지하는 개발자 세대, 더 중요하게는 제도적 습관 세대가 탄생했습니다. Stripe 비밀 키를 공개 저장소에 붙여넣지 않을 것입니다. 그런데 지도 키는요? 이는 사실상 비밀이 아닌 구성 값이었습니다. 많은 팀에서는 NEXT_PUBLIC_ 또는 REACT_APP_ 접두사가 붙은 클라이언트 측 환경 변수에도 공개 구성 파일인 README 파일에 이를 저장했습니다.

GitHub에서 노출된 자격 증명을 검색하는 보안 연구원들은 Google API 키도 다르게 취급하는 방법을 배웠습니다. 유출된 지도 키는 심각도가 낮은 결과였습니다. 유출된 Gemini 키는 완전히 다른 대화입니다.

Gemini의 변화와 그것이 중요한 이유

Google의 Gemini API는 이전 플레이북을 따르지 않습니다. Google AI Studio를 통해 Gemini API 키를 생성하면 지도 또는 YouTube 키와 근본적으로 다른 위험 프로필을 가진 자격 증명이 생성됩니다. Gemini 키는 대규모 언어 모델 추론에 대한 액세스를 인증합니다. 이 서비스는 Google의 실제 컴퓨팅 리소스 비용을 지불하고 페이지 조회수가 아닌 토큰을 기준으로 비용을 청구합니다.

더 중요한 것은 Gemini API 키에는 다른 Google 키 노출을 지속 가능하게 만드는 것과 동일한 내장 도메인 제한 메커니즘이 없다는 것입니다. 공개 저장소에서 키를 찾은 공격자가 자신의 애플리케이션을 가동하고 다른 국가에 있는 서버에서 할당량(또는 청구 한도)을 소비하는 것을 방지할 수 있는 간단한 "내 웹 사이트 도메인에 잠금" 제어 방법은 없습니다.

위험은 금전적인 것만이 아닙니다. 노출된 Gemini 키는 유해한 콘텐츠를 생성하거나, 즉각적인 삽입 공격을 수행하거나, Google 서비스 약관을 위반하는 도구를 구축하는 데 사용될 수 있습니다. 이 모든 비용은 귀하의 계정으로 청구되고 귀하의 신원을 추적할 수 있습니다.

2024년에 보안 연구원들은 GitHub에서만 노출된 수천 개의 Gemini API 키를 식별했으며, 그 중 다수는 이전에 사고 없이 다른 Google API 키를 호스팅했던 저장소에 있었습니다. 개발자들은 자신들의 역사적 기준에 따라 무모하게 행동한 것이 아니라 Google 자체에서 사용하도록 교육한 정신적 모델을 적용하고 있었습니다. 습관보다 환경이 더 빨리 변했다.

우발적 노출의 해부학

이러한 노출이 어떻게 발생하는지 이해하는 것이 이를 예방하기 위한 첫 번째 단계입니다.

Related Posts

• DJB의 암호학적 오디세이: 코드 영웅에서 표준 비판자로
• CXMT, DDR4 칩을 시장 평균 가격의 절반 수준에 공급 중
• 눈 내리는 곳에서 살면서 배울 수 있는 교훈
• IRS, '효율성' 개편으로 IT 직원 40%, 기술 리더 80% 잃어

Frequently Asked Questions

Google API 키가 비밀이 아니라고 되어 있는 이유는 무엇입니까?

Google API 키는 클라이언트 측 코드에 노출되어도 안전한 경우를 위해 설계되었습니다. YouTube, Maps 및 다른 API는 도메인 제한, IP 허용 목록, 할당량 관리와 같은 기능으로 노출된 키의 피해를 최소화할 수 있습니다. 20년 동안 Google은 이러한 키가 공개 GitHub 또는 브라우저 개발자 도구에서 쉽게 보일 수 있다는 것을 인정했습니다.

Gemini의 규칙 변경이 기존 Google API 키 사용법과 어떻게 다릅니다?

Gemini API는 기존 Google API와 달리 더 엄격한 보안 요건을 적용합니다. 이전에는 클라이언트 측에서 노출된 API 키를 허용했지만, Gemini는 키 노출에 대한 엄격한 제한을 도입했습니다. 이는 AI 모델의 보안 위험이 더 높기 때문에 필요합니다. 백엔드에서만 키를 관리하고 클라이언트 측 코드에서 노출되지 않도록해야 합니다.

Gemini API 키를 어떻게 안전한 방법으로 사용해야 합니까?

Gemini API 키는 반드시 백엔드 서버에서만 관리되어야 합니다. 프론트엔드 JavaScript 코드에 직접 삽입하거나 공개 GitHub 저장소에 노출되지 않도록 해야 합니다. REST API 엔드포인트를 사용하거나 사용자 정의 백엔드 서비스를 구축해 클라이언트 요청을 서버 측에서 처리한 후 Gemini API와 통신하도록 구성해야 합니다. 이러한 방법으로 키가 노출되는 것을 방지할 수 있습니다.

기존에 Google Maps API 키를 사용했던 방법으로 Gemini API 키를 사용할 수 있습니까?

아닙니다. Google Maps API의 관용적 허용 방식을 Gemini API에 적용하면 정책 위반이 될 수 있습니다. Gemini는 AI 모델에 대한 보안 위험이 더 높기 때문에 특히 엄격한 보안 요건을 요구합니다. 이전 방식은 비용만 발생시킬 수 있으므로, 반드시 Gemini의 공식 가이드라인에 따라 백엔드에서만 키를 관리하는 방법을 전환해야 합니다.