서비스 계정 키(Service Account Key) 유출 방지 및 제로 트러스트 아키텍처 전환 – 2

Google Cloud의 서비스 계정 키는 애플리케이션이나 서비스가 Google Cloud 리소스에 인증하고 접근할 수 있도록 하는 강력한 자격 증명입니다. 이 키는 만료 기간이 없는 긴 수명의 자격 증명이므로, 유출될 경우 비인가자가 클라우드 환경에 접근하여 데이터를 탈취하거나 리소스를 무단으로 사용해 막대한 비용을 발생시키는 등 심각한 보안 사고로 이어질 수 있습니다.

따라서 서비스 계정 키 유출 시 신속하게 대응하는 절차를 숙지하고, 근본적으로 유출을 방지하기 위한 전략을 수립하는 것은 매우 중요합니다. 본 블로그는 키 유출 상황에 대한 비상 대응 절차와 이를 사전에 방지하기 위한 핵심 전략을 상세하게 분석하여 제공합니다.

 

2부: 서비스 계정 키 유출 방지를 위한 핵심 전략

사후 대응도 중요하지만, 가장 좋은 보안은 유출 자체가 발생하지 않도록 사전에 방지하는 것입니다.

 

최우선 전략: 서비스 계정 키 사용하지 않기

가장 강력하고 권장되는 방법은 서비스 계정 키(JSON 파일)의 사용을 근본적으로 제거하는 것입니다.

• Google Cloud 내 워크로드의 경우
  GKE(Google Kubernetes Engine)나 GCE(Compute Engine) 등 Google Cloud 내부에서 실행되는 애플리케이션은 서비스 계정 키가 필요 없습니다. 대신, 워크로드에 서비스 계정을 직접 연결하면 메타데이터 서버를 통해 자동으로 임시 자격 증명을 얻어 Google Cloud 서비스에 안전하게 접근할 수 있습니다.
• Google Cloud 외부 워크로드의 경우 (Workload Identity Federation)
  AWS, Azure, 온프레미스 또는 GitHub Actions와 같이 Google Cloud 외부에서 실행되는 워크플로우에 가장 적합한 솔루션입니다. 외부 ID 공급자(IdP)의 자격 증명을 사용하여 서비스 계정 키 없이 Google Cloud 리소스에 접근할 수 있도록 허용합니다. 이는 수명이 긴 키 대신 단기 토큰을 사용하므로 보안성이 월등히 높습니다.

 

Workload Identity Federation 심층 분석: Google Cloud 외부 워크로드 연동

Workload Identity Federation은 외부 시스템의 ID를 Google Cloud의 IAM 역할과 연결하여, 단기적으로 유효한 액세스 토큰을 통해 인증을 수행하는 방식입니다.

• GitHub Actions 연동 예시

1. 1. Google Cloud에서 Workload Identity Federation 구성: 외부 ID(GitHub)를 신뢰하도록 워크로드 아이덴티티 풀 및 공급자를 생성합니다. 공급자 생성 시 발급자 URI는 https://token.actions.githubusercontent.com로 지정합니다. 이때 GitHub의 토큰 정보를 Google Cloud가 이해할 수 있도록 속성 매핑(예: attribute.repository = assertion.repository)을 반드시 구성하고, 이를 바탕으로 특정 저장소나 브랜치만 허용하도록 속성 조건을 설정하여 1차 보안을 강화합니다.
   2. 서비스 계정 생성 및 IAM 정책 바인딩: 워크플로우에 필요한 최소한의 권한을 가진 서비스 계정을 생성합니다(보안을 위해 서비스 계정 키는 절대 생성하지 않음). 이후, 풀 전체가 아닌 ‘특정 GitHub 저장소(principalSet 기반)’만 이 서비스 계정의 권한을 위임받을 수 있도록 대상을 엄격히 제한하여 Workload Identity 사용자(roles/iam.workloadIdentityUser) 역할을 부여합니다.
   3. GitHub Actions 워크플로우(.yml) 설정: 워크플로우에 permissions: { id-token: write, contents: read } 권한을 명시하여 OIDC 토큰 발급 및 코드 체크아웃이 가능하게 설정합니다. 이후 google-github-actions/auth 액션을 사용하여 GitHub OIDC 토큰을 단기 Google Cloud 액세스 토큰으로 안전하게 자동 교환합니다.

• AWS 환경 연동 예시

1. 1. Google Cloud 구성 (속성 매핑 및 조건 추가):
      워크로드 아이덴티티 풀을 생성하고, 공급자 유형으로 ‘AWS’를 선택하여 12자리 AWS 계정 ID를 입력합니다. 이때, AWS의 식별 정보를 Google Cloud가 이해할 수 있도록 속성 매핑(예: attribute.aws_role에 AWS ARN을 매핑)을 구성하고, 속성 조건(Attribute Condition)을 설정하여 특정 AWS 역할(Role)이나 태그를 가진 요청만 풀(Pool)에 접근하도록 1차 보안을 적용합니다.
   2. IAM 정책 설정 (PrincipalSet 기반 바인딩):
      Google Cloud 서비스 계정에 roles/iam.workloadIdentityUser 역할을 부여하여 권한을 위임합니다. 이때 AWS 역할을 직접 지정하는 것이 아니라, 앞서 매핑한 속성을 바탕으로 풀의 특정 주체 집합(예: principalSet://…/attribute.aws_role/AWS_역할_ARN)으로 대상을 엄격하게 제한하여 권한을 부여합니다.
   3. 자격 증명 구성:
      gcloud 명령어로 대상 워크로드 아이덴티티 풀과 Google Cloud 서비스 계정을 연결하는 인증 설정 파일(Google Cloud-cred-for-aws.json)을 생성합니다.
   4. 애플리케이션 코드 및 EC2 보안 (IMDSv2 강제):
      SSRF 공격 방지를 위해 IMDSv2 사용이 강제된 EC2 인스턴스에 해당 IAM 역할을 할당합니다. EC2 내부에서 GOOGLE_APPLICATION_CREDENTIALS 환경 변수에 생성한 설정 파일 경로를 지정하면, Google Cloud 클라이언트 라이브러리가 자동으로 안전하게 AWS 자격 증명을 사용하여 Google Cloud 단기 토큰으로 교환합니다.

• 온프레미스(On-premise) 환경 연동 예시 (Keycloak)

1. 1. Google Cloud 구성 (Audience 검증 및 JWKS 설정)
      워크로드 아이덴티티 풀과 OIDC 공급자를 생성합니다. 온프레미스 IdP(Keycloak)의 Issuer URI를 등록하며, 폐쇄망인 경우 Google STS가 서명을 검증할 수 있도록 JWKS JSON을 Google Cloud 공급자에 직접 등록합니다. 또한, 토큰 탈취/재사용 방지를 위해 IdP가 발급한 토큰의 aud 클레임을 Google Cloud가 검증하도록 설정하고, 토큰의 식별자(sub나 groups)를 Google Cloud 속성으로 매핑한 뒤 엄격한 속성 조건(Attribute Condition)을 걸어 1차 보안을 적용합니다.
   2. IAM 정책 설정 (정확한 식별자 기반 바인딩)
      매핑된 온프레미스 속성을 바탕으로, 포괄적인 부여가 아닌 특정 사용자나 특정 그룹(예: principalSet://…/attribute.group/DevTeam)을 정확히 지정하여 Google Cloud 서비스 계정의 roles/iam.workloadIdentityUser 역할을 부여합니다.
   3. 자격 증명 구성 및 자체 토큰 갱신(Rotation) 구현
      gcloud 명령어로 대상 OIDC 토큰 파일 경로가 지정된 인증 설정 파일(Google Cloud-cred-config.json)을 생성합니다. 이때 온프레미스 환경에는 Keycloak OIDC 토큰이 만료되기 전 주기적으로 새 토큰을 발급받아 해당 파일 경로에 덮어쓰는 별도의 백그라운드 프로세스(데몬)를 반드시 구현해야 합니다.
   4. 애플리케이션 적용
      애플리케이션 코드에서 GOOGLE_APPLICATION_CREDENTIALS 환경 변수를 설정 파일 경로로 지정하면, Google Cloud 클라이언트 라이브러리가 파일 내의 항상 최신 상태로 유지되는 OIDC 토큰을 읽어 단기 Google Cloud 액세스 토큰으로 안전하게 교환합니다.

 

키 사용이 불가피할 경우의 관리 모범 사례

부득이하게 서비스 계정 키를 사용해야 한다면, 다음 원칙을 철저히 준수하여 위험을 최소화해야 합니다.

1. Secret Manager를 통한 중앙 집중형 관리 및 안전한 주입(Injection)
   키 파일을 개발자 PC나 코드 저장소에 보관하지 않고, Secret Manager에 저장하여 엄격한 IAM(roles/secretmanager.secretAccessor)으로 관리합니다.
   • 안전한 주입: 애플리케이션 코드가 직접 키를 호출하는 대신(이는 불필요한 또 다른 인증을 요구함), CI/CD 파이프라인(예: GitHub Actions, Jenkins)이나 인프라 배포 도구(Terraform, Vault)가 배포 시점에 Secret Manager에서 키를 읽어와 격리된 런타임 환경(예: Kubernetes Secret)에 주입하도록 설계합니다.
2.  무중단(Grace Period)을 고려한 키 교체(Key Rotation) 자동화
   키 유출 피해를 줄이기 위해 주기적(예: 90일)으로 키를 교체해야 합니다. Cloud Scheduler, Pub/Sub, Cloud Functions를 활용하여 이를 자동화할 수 있습니다.

• • 무중단 교체 아키텍처: 서비스 장애를 막기 위해 새 키 생성 직후 구버전 키를 즉시 삭제해선 안 됩니다.

3. 조직 정책(Organization Policy)을 활용한 선제적 방어

• • 키 생성 원천 금지 및 조건부 허용: V2 조직 정책 API를 사용하여 서비스 계정 키 생성을 기본적으로 차단(iam.disableServiceAccountKeyCreation)합니다. 특정 레거시 프로젝트에만 예외를 두려면 리소스 태그(Tag)와 CEL(Common Expression Language) 조건을 결합한 YAML 정책을 적용합니다. 
  • 자동 비활성화 대응: 키가 공용 GitHub 등에 유출될 경우 Google Cloud가 이를 감지하여 즉시 차단하는 iam.serviceAccountKeyExposureResponse 정책을 DISABLE_KEY 상태로 유지합니다 (기본값 적용됨). 

4. 기타 핵심 보안 원칙

• • 최소 권한 원칙: 서비스 계정에 ‘편집자(Editor)’ 등의 기본(Primitive) 역할을 피하고 필요한 권한만 세분화하여 부여합니다.
  • 소스 코드 내 하드코딩 절대 금지: GitHub Advanced Security의 Push Protection(사전 차단)과 Secret Scanning(사후 탐지) 기능을 활용하여, 키 파일이나 값이 저장소에 커밋되는 것을 원천 차단하고 모니터링합니다.

 

요약

Google Cloud 서비스 계정 키의 보안은 클라우드 환경 전체의 안전과 직결됩니다. 키 유출 사고 발생 시에는 즉시 키를 비활성화하고, Cloud Audit Logs와 SCC, SecOps 같은 고급 도구를 통해 피해 범위와 공격 경로를 정밀하게 분석한 후 신속하게 복구하는 비상 대응 절차를 따라야 합니다. 특히, 키 유출로 인한 악의적인 리소스 생성(크립토마이닝 등) 비용은 전적으로 고객 책임(공동 책임 모델)이므로, 사전에 Cloud Billing 예산 알림(Budgets and Alerts)을 설정하고 한도 초과 시 자동으로 리소스를 차단하는 파이프라인을 구축해 두는 것이 필수적입니다.

하지만 더 중요한 것은 예방과 조기 탐지입니다. 가장 효과적인 예방책은 서비스 계정 키 자체를 사용하지 않는 것입니다. Google Cloud 외부 워크로드(AWS, 온프레미스 등)는 Workload Identity Federation을, 내부 워크로드는 연결된 서비스 계정을 사용하는 것이 최선의 방법입니다. Workload Identity Federation은 서비스 계정 키 파일 없이 단기 토큰 기반의 안전한 인증을 구현할 수 있게 해주는 강력한 솔루션입니다.

만약 키 사용이 불가피하다면, Secret Manager에 저장하고 정기적으로 자동 교체하며 최소 권한 원칙을 준수해야 합니다. 또한 SCC(Security Command Center)의 유출된 크리덴셜 탐지(Leaked Credentials Detection) 기능을 활성화하여 퍼블릭 저장소 등에 키가 노출될 경우 즉각적으로 알림을 받도록 해야 합니다. 더 나아가 iam.disableServiceAccountKeyCreation 조직 정책을 기본으로 적용하되, 태그를 이용해 필요한 경우에만 조건부로 예외를 허용하는 선제적 방어 전략을 구축해야 합니다. 이러한 다층적 방어 전략을 통해 서비스 계정 키 유출 위험을 최소화하고 안전한 클라우드 환경을 구축할 수 있습니다.

 

자세한 내용이 궁금하시다면, 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.