보안 & 아이덴티티

스토리지 보안 강화: 방치된 버킷 점유를 방지하는 베스트 프랙티스

2025년 8월 7일

Raman Bansal

Senior Software Engineer

Maksim Shudrak

Information Security Engineer

Try Gemini 2.5

Our most intelligent model is now available on Vertex AI

Try now

해당 블로그의 원문은 2025년 8월 8일 Google Cloud 블로그(영문)에 게재되었습니다.

클라우드 스토리지 버킷은 디지털 부동산과 마찬가지로, 클라우드에 데이터를 저장하는 공간이자 인터넷상의 고유한 영역입니다. 특정 버킷이 더 이상 필요하지 않아 사용을 중단하고 이동하게 되면, 해당 버킷이 가리키던 주소가 여전히 공개 상태일 경우 다른 사람이 그 영역을 재사용할 수 있습니다.

이것이 바로 방치된 버킷(dangling bucket) 공격의 핵심 원리입니다. 이 공격은 스토리지 버킷을 삭제했음에도 불구하고 애플리케이션 코드, 모바일 앱, 공개 문서에 해당 버킷에 대한 참조가 남아 있을 때 발생합니다. 공격자는 간단히 동일한 버킷 이름을 자신의 프로젝트에서 점유하여, 더 이상 공식적으로 사용되지 않는 버킷에 의존하고 있는 사용자에게 멀웨어를 배포하거나 데이터를 탈취하는 등 기존 주소를 악용할 수 있습니다.

다행히도 다음 네 가지 단계를 통해 애플리케이션과 사용자를 이러한 위협으로부터 보호할 수 있습니다.

안전한 서비스 해제 계획 구현

버킷을 삭제할 때는 신중해야 합니다. 의도적인 서비스 해제(decommissioning) 프로세스는 매우 중요합니다. gcloud storage rm 명령어를 입력하기 전에 다음 단계를 따르세요.

1단계: 감사 및 학습

무엇이든 삭제하기 전에 시간을 들여 버킷에 액세스하는 주체와 원인을 파악하세요. 로그를 사용하여 최근 트래픽을 확인하고, 오래된 앱 버전, 타사 서비스 및 사용자로부터 활성 트래픽 요청이 오고 있다면 조사해야 합니다. 특히 실행 가능한 코드, 머신러닝 모델, 동적 웹 콘텐츠(예: 자바스크립트), 민감한 구성 파일을 가져오려는 요청에 각별히 주의하세요.

요청자의 사용자 에이전트를 확인하면 봇, 데이터 크롤러, 스캐너로부터 오는 많은 요청을 볼 수 있습니다. 이들의 요청은 기본적으로 백그라운드 노이즈이며, 시스템이 올바르게 기능하기 위해 버킷이 활발히 사용되고 있음을 의미하지는 않습니다. 이는 애플리케이션 및 사용자로부터 오는 정상적인 트래픽이 아니기 때문에 위험하지 않으며 안전하게 무시할 수 있습니다.

2단계: 자신감 있는 삭제

많은 자동 프로세스 및 사용자 활동은 매일 발생하지 않으므로, 버킷을 삭제하기 전에 최소 일주일은 기다려야 합니다. 일주일 이상 기다리면 다음을 포함한 전체 활동 주기를 관찰했음을 확신할 수 있습니다.

주간 보고서: 주간 일정으로 보고서를 생성하고 데이터 백업을 수행하는 스크립트.
일괄 작업: 주말이나 특정 요일에만 실행될 수 있는 자동화된 작업.
드문 사용자 액세스: 버킷의 데이터에 의존하는 기능을 일주일에 한 번만 사용하는 사용자.

버킷에 대한 정상적인 트래픽이 최소 일주일 동안 발생하지 않았음을 확인하고 모든 레거시 코드를 업데이트했다면, 버킷 삭제를 진행할 수 있습니다. Google Cloud 프로젝트를 삭제하면 모든 Google Cloud Storage 버킷을 포함하여 해당 프로젝트와 관련된 모든 리소스가 효과적으로 삭제됩니다.

다음, 방치된 버킷을 참조하는 코드 찾기 및 수정

향후 문제가 발생하는 것을 방지하는 것이 중요하지만, 현재 환경에 방치된 버킷에 대한 참조가 있을 수 있습니다. 다음은 이를 찾아내고 수정하는 계획입니다.

3단계: 사전 예방적 발견

로그 분석: 이것은 가장 강력한 도구 중 하나입니다. Cloud Logging 데이터에서 스토리지 URL에 대한 반복적인 404 Not Found 오류를 보여주는 서버 및 애플리케이션 로그를 쿼리합니다. 예를 들어, 존재하지 않는 동일한 버킷 이름에 대한 실패한 요청이 많다는 것은 중대한 위험 신호입니다(이를 해결하려면 3단계를 계속 진행한 후 4단계로 넘어가세요).

코드베이스 및 문서 스캔: 모든 비공개 및 오픈소스 코드 저장소(오래된 저장소 및 보관된 저장소 포함), 구성 및 문서에서 더 이상 사용되지 않는 스토리지 버킷 이름에 대한 모든 참조를 포괄적으로 스캔합니다. 다음 패턴을 찾아낼 수 있습니다.

gs://{bucket-name}
storage.googleapis.com/{bucket-name}
{bucket-name}.storage.googleapis.com
commondatastorage.googleapis.com/{bucket_name}
{bucke 이것은 가장 강력한 도구 중 하나입니다. Cloud Logging 데이터에서 스토리지 URL에 대한 반복적인 404 Not Found 오류를 보여주는 서버 및 애플리케이션 로그를 쿼리합니다. 예를 들어, 존재하지 않는 동일한 버킷 이름에 대한 실패한 요청이 많다는 것은 중대한 위험 신호입니다(이를 해결하려면 3단계를 계속 진행한 후 4단계로 넘어가세요)

버킷이 여전히 존재하는지 확인하려면 https://storage.googleapis.com/{your-bucket-name}를 쿼리하면 됩니다. 응답에서 NoSuchBucket이 표시되면 방치된 버킷 참조를 식별했다는 의미입니다

로드 중...

For your convenience, we provide a script below that can find dangling references in a given file.

버킷이 존재하고 NoSuchBucket 오류가 발생하지 않는다면, 해당 버킷이 실제로 귀사의 소유인지 확인해야 합니다. 이는 위협 행위자가 이미 해당 이름을 점유했을 수도 있기 때문입니다.

소유권을 확인하는 가장 쉬운 방법은 버킷의 IAM(Identity and Access Management) 권한을 읽어보는 것입니다.

gcloud storage buckets get-iam-policy gs://{bucket-name}와 같은 명령어를 실행했을 때 'Access Denied' 또는 '403 Forbidden' 오류가 발생한다면, 이는 버킷이 다른 사람에 의해 점유되었음을 나타내는 신호입니다. 이는 버킷이 존재하지만, 귀하의 계정에는 이를 관리할 권한이 없음을 의미하며, 버킷이 이미 점유되었다는 것을 보여줍니다. 이러한 참조는 위험으로 간주되어 삭제해야 합니다.

편의를 위해 주어진 파일에서 방치된 참조를 찾을 수 있는 스크립트를 아래에 제공합니다.

로드 중...

import re
import sys
from typing import Optional, Set

import requests
from requests.exceptions import RequestException

def check_bucket(bucket_name: str) -> Optional[requests.Response]:
    try:
        with requests.Session() as session:
            response = session.head(f"https://storage.googleapis.com/{bucket_name}")
        return response
    except RequestException as e:
        print(f"An error occurred while checking bucket {bucket_name}: {e}")
        return None

def sanitize_bucket_name(bucket_name: str) -> Optional[str]:
    # Remove common prefixes and quotes
    bucket_name = bucket_name.replace("gs://", "")
    bucket_name = bucket_name.replace("\"", "")
    bucket_name = bucket_name.replace("\'", "")
    bucket_name = bucket_name.split("/")[0]

# Validate the bucket name format according to GCS naming conventions
    if re.match("^[a-z0-9-._]+$", bucket_name) is None:
      return None
    return bucket_name

def extract_bucket_names(line: str) -> Set[str]:
    all_buckets: Set[str] = set()

pattern = re.compile(
        r'gs://([a-z0-9-._]+)|'
        r'([a-z0-9-._]+)\.storage\.googleapis\.com|'
        r'storage\.googleapis\.com/([a-z0-9-._]+)|'
        r'([a-z0-9-._]+)\.commondatastorage\.googleapis\.com|'
        r'commondatastorage\.googleapis\.com/([a-z0-9-._]+)',
        re.IGNORECASE
    )

for match in pattern.finditer(line):
        # The first non-empty group is the bucket name
        if raw_bucket := next((g for g in match.groups() if g is not None), None):
            if sanitized_bucket := sanitize_bucket_name(raw_bucket):
                all_buckets.add(sanitized_bucket)

return all_buckets

def main(filename: str) -> None:
  with open(filename, 'r') as f:
      for i, line in enumerate(f, 1):
          bucket_names = extract_bucket_names(line)
          for bucket_name in bucket_names:
              response = check_bucket(bucket_name)
              if response.status_code == 404:
                  print(f"Dangling bucket found: {bucket_name} (line {i}), {line}")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        print("Usage: python find_dangling_buckets.py <filename>")
        sys.exit(1)
    
    main(sys.argv[1])

하지만 이 스크립트와 권장 사항은 하드코딩된 참조만 찾을 수 있으며, 런타임 중에 동적으로 생성되는 참조는 찾을 수 없습니다. 또한, 코드베이스에는 패턴을 따르지 않지만 Google Cloud Storage 클라이언트에서 사용되는 하드코딩된 버킷 이름이 있을 수도 있습니다.

4단계: 재점유 및 보안 강화

만약 귀사 또는 고객에게 보안 위험이 될 수 있는 방치된 버킷 이름을 발견했다면 신속하게 조치를 취해야 합니다.

방치된 버킷을 소유하지 않은 경우:

이전 단계에서 얻은 모든 데이터를 활용해 방치된 버킷을 찾아내고, 코드 또는 문서에 하드코딩된 모든 참조를 제거하세요. 사용자에게 수정된 버전을 배포하여 문제를 영구적으로 해결합니다.

방치된 버킷을 소유한 경우:

이름 재점유: 관리하는 보안 프로젝트에 정확히 동일한 이름으로 새 스토리지 버킷을 생성합니다. 이렇게 하면 공격자가 버킷을 점유하는 것을 방지할 수 있습니다.
Lock it down: Apply a restrictive IAM policy to the reclaimed bucket. Deny all access to allUsers and allAuthenticatedUsers and enable Uniform Bucket-Level Access. Enable Public Access Prevention control to turn the bucket into a private "sinkhole."
잠금 설정: 재점유한 버킷에 제한적인 IAM 정책을 적용합니다. allUsers 및 allAuthenticatedUsers에 대한 모든 액세스를 거부하고 균일한 버킷 수준 액세스(Uniform Bucket-Level Access)를 활성화합니다. 공개 액세스 방지(Public Access Prevention) 제어를 활성화하여 버킷을 비공개 '블랙홀(sinkhole)'로 만듭니다