Google Cloud의 서비스 계정 키는 애플리케이션이나 서비스가 Google Cloud 리소스에 인증하고 접근할 수 있도록 하는 강력한 자격 증명입니다. 이 키는 만료 기간이 없는 긴 수명의 자격 증명이므로, 유출될 경우 비인가자가 클라우드 환경에 접근하여 데이터를 탈취하거나 리소스를 무단으로 사용해 막대한 비용을 발생시키는 등 심각한 보안 사고로 이어질 수 있습니다.
따라서 서비스 계정 키 유출 시 신속하게 대응하는 절차를 숙지하고, 근본적으로 유출을 방지하기 위한 전략을 수립하는 것은 매우 중요합니다. 본 블로그는 키 유출 상황에 대한 비상 대응 절차와 이를 사전에 방지하기 위한 핵심 전략을 상세하게 분석하여 제공합니다.
1부: 서비스 계정 키 유출 시 비상 대응 절차
서비스 계정 키가 외부에 노출되었다고 의심되는 즉시, 피해를 최소화하기 위해 다음 단계를 순서대로 실행해야 합니다.
1단계: 즉각적인 키 비활성화 및 삭제
가장 먼저 해야 할 일은 유출된 키를 통해 더 이상의 접근이 불가능하도록 차단하는 것입니다. 대응 방법은 유출이 감지된 경로에 따라 달라질 수 있습니다.
사례: 공개 GitHub 저장소에 키가 유출된 경우 (자동 대응)
Google Cloud는 GitHub와의 파트너십을 통해 공개 저장소에 유출된 서비스 계정 키를 자동으로 탐지하고 비활성화하는 강력한 기능을 제공합니다.
수동 대응 (그 외의 경우)
자동 탐지되지 않은 경로로 키가 유출되었거나, 내부적으로 유출을 인지한 경우에는 즉시 수동으로 키를 무력화해야 합니다.
- 키 비활성화: GCP는 키를 즉시 삭제하는 것이 부담스러울 경우를 대비해 비활성화 기능을 제공합니다 . gcloud CLI(명령줄 인터페이스)를 사용하여 특정 키를 비활성화할 수 있습니다. 이 방법은 키를 일시적으로 정지시켜 영향을 분석하고, 만약의 경우 다시 활성화할 여지를 둡니다.
- 키 삭제: 유출된 키가 악의적으로 사용된 것이 확실하다면 즉시 삭제해야 합니다 . GCP 콘솔의 ‘IAM 및 관리자’ > ‘서비스 계정’ 메뉴에서 해당 계정을 선택한 후, ‘키’ 탭에서 유출된 키를 찾아 삭제합니다.
2단계: 유출 키 활동 및 공격 경로 심층 분석
키를 차단한 후에는 해당 키를 통해 어떤 작업이 수행되었는지 파악해야 합니다. 이때 GCP의 Cloud Audit Logs가 결정적인 역할을 하지만, 더 정교한 분석을 위해 Security Command Center(SCC)와 같은 도구를 활용하는 것이 좋습니다.
기본 분석: Cloud Audit Logs 활용
키 유출 사고 시에는 다음 두 가지 로그를 중점적으로 확인해야 합니다.
- 관리자 활동(Admin Activity) 로그: 리소스의 구성이나 메타데이터를 변경하는 모든 API 호출을 기록합니다. VM 인스턴스 생성, IAM 정책 변경, 방화벽 규칙 수정 등 인프라에 직접적인 변화를 주는 활동이 여기에 해당합니다. 이 로그는 기본적으로 활성화되어 있으며, 공격자가 인프라를 변경하려는 시도를 파악하는 데 가장 중요합니다.
- 데이터 액세스(Data Access) 로그: 리소스에 저장된 데이터를 읽거나 쓰는 API 호출을 기록합니다. Cloud Storage 버킷에서 객체를 다운로드하거나 BigQuery에서 데이터를 조회하는 등의 활동이 포함됩니다. 데이터 유출 여부를 확인하는 데 필수적이지만, 로그 양이 많아 기본적으로 비활성화되어 있습니다. 따라서 민감 데이터를 다루는 서비스에 대해서는 사전에 반드시 활성화해야 합니다.
gcloud logging read 명령어를 사용하면 유출된 서비스 계정의 이메일(principalEmail)을 필터로 사용하여 의심스러운 활동을 신속하게 추적할 수 있습니다.
고급 분석: SCC Event Threat Detection, SecOps를 활용한 공격 경로 재구성
단순 로그 조회를 넘어 공격자의 전체 활동(Kill Chain)을 파악하기 위해서는 SCC Premium Event Threat Detection(ETD), SecOps와 같은 고급 보안 도구를 활용해야 합니다.
시나리오: 개발자가 실수로 서비스 계정 키를 공개 GitHub 저장소에 커밋
- 초기 위협 탐지 (SCC Premium & Event Threat Detection)
-
- 초기 경보: ETD는 인터넷에 공개된 키가 사용되는 것을 감지하고 SCC Premium 대시보드에 Initial Access: Leaked Service Account Key Used 또는 account_has_leaked_credentials와 같은 심각도 높은 탐지 결과를 생성합니다.
- 탐지 내용 확인: 분석가는 SCC에서 해당 탐지 결과를 통해 유출된 키의 서비스 계정, 공격자가 사용한 IP 주소, 접근 시도한 API 메서드, 그리고 키가 유출된 위치(예: GitHub URL)까지 상세 정보를 확인할 수 있습니다.
-
- 공격 경로 재구성 (SecOps)
SecOps의 타임라인 뷰와 자산 뷰를 활용하면 이러한 일련의 활동들을 시간순으로 재구성하여 공격자의 전체 Kill Chain을 시각적으로 파악하고 숨겨진 피해 범위를 정확히 분석할 수 있습니다.
3단계: 피해 범위 평가 및 복구
로그 분석을 통해 파악된 피해 범위를 기반으로 복구 조치를 수행합니다.
- 무단 생성 리소스 삭제: 공격자에 의해 생성된 VM, 스토리지, 네트워크 리소스 등을 모두 삭제합니다.
- 데이터 복원: 데이터가 변경되거나 삭제된 경우, 사전에 마련된 백업을 사용하여 원래 상태로 복원합니다.
- 권한 재설정: 변경된 IAM 정책이나 사용자 권한이 있다면 원래의 보안 설정으로 되돌립니다.
4단계: 새로운 키 생성 및 안전한 배포
영향을 받은 애플리케이션의 기능을 복구하기 위해 새로운 자격 증명을 배포해야 합니다. 이때, 동일한 실수를 반복하지 않도록 아래 2부에서 설명할 ‘유출 방지 전략’을 반드시 적용해야 합니다.
5단계: 금전적 피해 구제 절차
키 유출로 인해 승인되지 않은 리소스가 대량 생성되어 막대한 요금이 발생했다면, 신속하게 Google Cloud 지원팀에 환불을 요청할 수 있습니다.
- 환불 요청 절차:
- 준비해야 할 증거 자료 (Cloud Audit Logs)
지원팀에 제출할 객관적인 증거로 다음 정보가 포함된 Cloud Audit Logs 기록을 준비해야 합니다.- protoPayload.authenticationInfo.principalEmail: 공격에 사용된 서비스 계정 이메일
- protoPayload.requestMetadata.callerIp: 공격자의 IP 주소 (조직의 정상 IP 대역과 다르다는 것을 증명)
- protoPayload.methodName: compute.instances.insert 등 비용을 발생시킨 리소스 생성 API 호출 내역
- timestamp: 공격이 발생한 정확한 시간대
- Google의 환불 검토 시 중요 고려 요소
Google은 다음과 같은 요소들을 중요하게 고려하는 것으로 보입니다.- 신속한 대응 및 신고: 사고 인지 후 얼마나 빨리 리소스를 중지하고 지원팀에 연락했는가
- 명확한 증거: 감사 로그를 통해 승인되지 않은 사용임을 얼마나 잘 입증했는가
- 계정 이력: 과거에 유사한 요청이 없었는지 여부
자세한 내용이 궁금하시다면, 메가존소프트 문의포탈을 통해 궁금한 부분을 남겨주세요.
