Google이 내 회사의 Google Cloud 계정을 세 번째로 정지시켰다

5 days ago 4

SSLMate의 Google Cloud 계정이 세 번째로 예고 없이 정지되며, 서비스 통합 기능이 반복적으로 중단됨
고객의 Cloud DNS 및 Cloud Domains 통합을 위해 Google 문서에 따라 서비스 계정을 생성·위임하는 구조를 사용했으나, 이 방식이 지속적으로 정지 대상이 됨
첫 번째 정지(2024년)는 복구 과정의 비효율성과 불명확한 원인으로 큰 혼란을 초래했고, 이후 두 차례 정지도 사전 통보 없이 자동화된 이메일만 반복됨
대안으로 장기 키 기반 인증은 보안상 취약하고, OIDC(OpenID Connect) 는 설정 절차가 과도하게 복잡함
결과적으로 Google Cloud 통합에서는 보안·편의성·안정성 중 두 가지밖에 선택할 수 없는 구조적 한계가 드러남

Google Cloud 계정 반복 정지 사례

SSLMate의 Google Cloud 계정이 2024년과 2025년 두 차례 연속된 금요일마다 사전 통보 없이 정지됨
- 이전에도 2024년에 동일한 정지가 있었으며, 세 번 모두 명확한 사유나 재발 방지 방법이 제공되지 않음
SSLMate는 고객의 Google Cloud 계정과 통합하기 위해 서비스 계정 위임 방식을 사용
- 각 고객별로 SSLMate 프로젝트 하에 서비스 계정을 만들고, 고객이 해당 계정에 Cloud DNS 및 Cloud Domains 접근 권한을 부여
- SSLMate는 필요 시 해당 서비스 계정을 가상으로 가장(impersonate) 하여 접근
- 이 구조는 Google 공식 문서의 권장 방식에 기반하며, 장기 자격 증명 없이 안전하고 설정이 간단한 방식임

첫 번째 정지 시 고객 통합 기능이 모두 실패하고 콘솔 접근이 차단됨
- Google 지원팀은 응답했으나, 계정이 비활성화되어 이메일이 반송되는 등 복구 절차가 비효율적이었음
- 프로젝트 ID를 요청받았으나 콘솔 접근이 불가해 제공할 수 없었음
- 전화번호 인증 후 일부 프로젝트만 복구되었고, 다음날 다시 자동 이메일로 접근 제한 통보를 받음
- 이후 여러 자동 이메일을 거쳐 약 19시간 후 전체 복구
Google은 정지 사유를 밝히지 않았으며, 사전 이메일 통보도 없었음
- SSLMate는 이후 통합 오류 비율을 감시하는 헬스 체크 기능을 추가해 조기 감지를 시도

헬스 체크가 실패하며 대부분의 통합이 “Invalid grant: account not found” 오류를 반환
- 콘솔 로그인은 가능했으나, 각 프로젝트별로 “제공된 정보에 따라 복구됨”이라는 이메일만 수신
- 정지 통보 이메일은 여전히 수신되지 않음
- 이후 통합 기능이 정상화됨

다시 헬스 체크 실패 후 콘솔 접근 시 새로운 유형의 오류 메시지 표시
- 대부분의 프로젝트가 정지되었으며, 고객 통합용 프로젝트도 포함
- 금요일에 이의 신청을 제출했으나, 일요일에는 전체 계정 정지 통보 이메일을 수신
- 월요일, 해당 글이 Hacker News에 올라온 직후 대부분의 프로젝트가 복구되고, 몇 시간 후 전체 접근이 회복
- 이번에도 정지 원인이나 예방 방법은 제공되지 않음

모든 정지 기간 동안에도 한 고객의 통합만 정상 작동
- 동일한 프로젝트 내 서비스 계정을 사용했음에도 영향받지 않음
- 원인에 대한 추가 설명 없음

SSLMate는 프로덕션 환경에서 Google 계정에 의존할 수 없다고 판단
- Google 시스템은 계정, 프로젝트, 또는 GCP 전체가 임의로 정지될 수 있는 구조
대안 1: 고객이 직접 서비스 계정을 만들고 장기 키(long-lived key) 로 SSLMate에 인증 제공
- 설정은 간단하지만, 키 유출 위험과 회전 불가능성으로 보안이 취약
대안 2: OpenID Connect(OIDC) 사용
- GitHub Actions나 Azure 통합에서 사용되는 표준 방식으로, 장기 자격 증명 없이 안전한 접근 가능
- 그러나 Google Cloud에서의 설정은 7단계 절차로 과도하게 복잡함

OIDC를 사용하려면 다음 단계 필요
1. IAM Service Account Credentials API 활성화
2. 서비스 계정 생성
3. Workload Identity Pool 생성
4. Pool 내에 Workload Identity Provider 생성
5. SSLMate가 서비스 계정을 가장할 수 있도록 권한 부여
6. 서비스 계정에 역할(Role) 부여
7. 생성된 서비스 계정 및 Provider ID를 SSLMate에 전달
각 단계가 이전 단계의 리소스 ID를 필요로 해 고객이 따라 하기 어려움
작성자는 다음 단계를 불필요한 절차로 지적
- 서비스 계정 생성 없이도 역할을 직접 부여할 수 있어야 함
- 대부분의 경우 Pool은 Provider 하나만 포함하므로 Pool 생성 자체가 불필요한 중복 작업
- Provider 생성 없이도 OIDC 발급자 URL과 주체(subject) 에 직접 역할을 부여할 수 있어야 함

현재 Google Cloud 통합은 다음 세 가지 중 두 가지 선택만 가능
1. 장기 자격 증명 없음
2. 고객이 쉽게 설정 가능
3. 임의 정지로부터 안전
SSLMate의 서비스 계정 기반 방식은 보안과 편의성은 확보하지만 정지 위험 존재
서비스 계정+키 방식은 설정이 쉽고 정지 위험은 낮지만 보안이 약함
OIDC 방식은 보안과 정지 안전성은 높지만 설정이 복잡함
Google이 OIDC를 1급 통합 방식으로 단순화하지 않는 한, 안전하고 안정적인 통합은 어렵다는 결론