Hacker News 의견들

• 최근 AWS 계정 삭제 후에도 루트 사용자 이메일 주소를 재사용할 수 없다는 사실을 알게 되었음
  우리 조직의 한 사람이 회사 메인 이메일로 폐쇄된 계정의 루트 사용자를 만들었고, 다른 이메일로 새 계정을 만들었는데 이제는 삭제 복구 기간도 지나버림
  그 결과, 해당 이메일이 삭제된 루트 계정에 영구적으로 묶여 있어서 외부 IdP를 통한 SSO 로그인이 불가능해졌음
  AWS 지원팀에 문의했지만 도움을 거의 받지 못했음

  • 최근 고객 지원을 돕던 중, 이전 핵심 엔지니어가 퇴사하면서 루트 계정의 MFA가 그의 휴대폰에 연결된 채로 남은 사례를 겪었음
    비밀번호는 문서화되어 있었지만 MFA를 해제할 방법이 없어 AWS 지원, 계정 담당자 등에게 문의했으나 해결 불가였음
    결국 루트 계정 접근이 막혀 있고, 복잡한 환경을 통째로 새 계정으로 옮겨야 할지도 모르는 상황임
  • 이메일 제공자가 지원한다면 플러스 주소(plus addressing) 를 활용할 수 있음
    AWS는 플러스가 붙은 이메일을 별개의 주소로 인식함
  • 루트 계정은 사람용으로 쓰지 말고, 비상용 특수 계정으로 만들어 자격 증명을 안전하게 보관해야 함
    정말 심각한 문제가 생겼을 때만 사용하는 것이 좋음
  • 보안이란 게 얼마나 허무한지 새삼 느껴짐
    결국 어떤 피셔가 고객 지원팀을 속여 10점짜리 평가를 받으면 모든 게 무너질 수도 있음
  • IdP의 이메일을 역할(role)에 매핑하는 방식이라면 “삭제된 루트 계정에 영구적으로 묶였다”는 게 무슨 의미인지 궁금함
    어떤 메커니즘이 실제로 사용을 막는지 알고 싶음

• Azure Blob Storage의 account name 개념을 저자가 잘못 이해한 듯함
  사실상 S3의 버킷 이름과 동일한 수준이며, 전역적으로 고유해야 해서 여전히 큰 불편이 있음
  특히 이름 길이가 24자 제한이라 더 답답함
  Microsoft도 AWS처럼 고객별 네임스페이스를 도입하길 바람

  • 약 10년 전 S3 팀에서도 이 문제를 인식하고 있었음
    하지만 초기 설계의 제약 때문에 바꾸지 못했음
    개인적으로는 왜 아직도 S3 v2 API를 만들지 않았는지 이해가 안 됨
    새 API로 점진적 마이그레이션을 유도할 수도 있었을 텐데, 결국 고객과 엔지니어 모두 불필요한 고통을 겪고 있음
  • 처음 Azure를 써봤을 때, 리소스들이 계정 단위로 네임스페이스되지 않는 걸 보고 정말 이상한 설계라고 느꼈음
  • 글쓴이 본인이 직접 등장해, 피드백을 반영해 글을 업데이트했다고 밝힘
  • 이름 제한이 24자뿐 아니라, 하이픈·언더스코어·점도 불가해서
    숫자와 소문자만 써야 하는 점이 너무 불편함
    S3나 GCS처럼 대시라도 허용했으면 좋겠음
  • 스토리지 계정 이름에 하이픈조차 못 쓰는 건 정말 엉망인 설계라고 생각함
    컨테이너 레지스트리 등 다른 리소스도 마찬가지임

• 패키지명, 버킷명, GitHub 계정명 등은 Discord처럼 @이름-랜덤4자리 형식을 쓰면 어떨까 생각함
  이렇게 하면 이름 공간을 민주화하고, 스쿼팅이나 재사용 공격을 막을 수 있음
  계정이 삭제되면 전체 이름을 폐기하면 되므로 깔끔함

  • 하지만 Discord는 2년 전 이 형식을 폐지하고 전역 고유 이름 체계로 전환했음
    이유는 공식 공지에 설명되어 있는데,
    4자리 숫자를 기억해야 하고 대소문자 구분까지 해야 하는 불편함 때문이었음
  • 개인적으로는 UUID + petname 시스템이 더 낫다고 생각함
    특히 채팅 앱에서는 내부 ID를 쓰고, 사용자는 별칭만 쓰게 하는 게 깔끔함
    버킷의 경우엔 사람이 읽기 쉬운 이름이 핵심이라, 차라리 자신의 도메인을 쓰는 게 낫다고 봄
  • 버킷에는 괜찮지만, 패키지 하이재킹 방지에는 4자리 코드가 별 도움이 안 됨
    오히려 오타 위험만 늘어남
  • 그냥 도메인 검증 기반 이름(@example.com) 을 어디서나 쓸 수 있으면 좋겠음
  • 나는 내부 도구를 만들 때 사용자에게 불투명한 내부 ID를 부여하고, 이름은 자유롭게 바꾸게 했음
    온라인 커뮤니티에서 이름이 겹치는 게 자연스러운 일인데,
    왜 굳이 전역 고유 이름을 강제하는지 의문임

• 글쓴이 Ian Mckay에게 감사함
  AWS가 공식적으로 계정·리전 단위 네임스페이스를 도입한 건 좋은 변화임
  Terraform 같은 IaC 도구들이 이 규칙을 기본값으로 채택하면 더 좋겠음
  이미 Terraform은 버킷 이름 끝에 랜덤 해시 접미사를 붙여 충돌을 방지하고 있음
  AWS 공식 블로그에도 관련 내용이 있음

• 클라우드 제공자들이 예측 가능한 버킷 이름을 내부 스크래치 공간에 쓸 때 생기는 버킷 스쿼팅 공격이 흥미로움
  AWS에서는 해시 때문에 실제 공격은 어려웠지만, GCP는 최근에도 이런 문제를 겪었음
  관련 발표: DC32 AWS 버킷 스쿼팅 토크,
  GCP 취약점: CVE-2026-1727

  • 그 발표 정말 인상 깊었음
    버킷 이름이 예측 가능하다는 걸 보는 순간 위험을 직감했음
    버킷 스쿼팅 + 공개 버킷 + CloudFormation의 TOCTOU 문제 조합이면
    충분히 다른 계정에 리소스를 배포할 수도 있었음
    AWS 보안팀이 이걸 더 일찍 발견하지 못한 게 놀라움

• DNS 이름도 비슷한 문제를 가짐
  도메인을 갱신하지 않으면 재등록이 가능해지고,
  누군가 MX 레코드를 설정해 비밀번호 재설정 메일 등을 가로챌 수 있음

  • 이런 방식으로 레거시 IPv4 블록 같은 자산을 되찾는 경우도 있음

• AWS 버킷은 여전히 호스트명과 동일한 이름일 때만 특수 기능을 제공함
  관련 문서: Virtual Hosting in S3

• 이름은 그것이 지칭하는 대상과 동일해서는 안 됨
  이름이 재사용되면 전혀 다른 대상을 가리키게 되고,
  그 의미는 문맥에 따라 달라짐
  스스로 이름을 재할당할 때만 동일한 것으로 간주할 수 있음

• 계정 ID를 공개하는 게 보안상 위험한지 궁금했음

  • AWS는 공식적으로 계정 ID는 비밀 정보가 아니라고 명시함
    공식 문서에 따르면,
    신중히 다루되 민감 정보로 간주하지 않음
  • 개인적인 의견으로는 이메일 주소처럼 식별자이지 인증 수단은 아님
    너무 노출시키지만 않으면 괜찮음
  • 위생적으로는 좋지 않지만, 계정 ID만으로는 공격 불가임
    IAM 규칙에서 공격자가 *를 쓸 수 있으므로, 결국 방어 측의 정책 설정이 중요함
  • S3 서명 URL을 공유하면 그 안에 Access Key ID가 포함되어 있음
    이를 base32로 디코딩하면 Account ID를 추출할 수 있음
    참고: 관련 분석 글

• S3가 버킷 이름만을 접근 키로 사용한 것은 설계상 가장 짜증나는 결정 중 하나였음