클라우드 침해사고 사례 분석 #3 - Accenture S3 Data Breach(일 뻔했던)

hwup·2026년 3월 22일

클라우드 침해사고

목록 보기
4/10

사건 개요

2017년 9월 17일, Accenture의 AWS S3 버킷 4개가 퍼블릭으로 노출되어 누구나 접근 가능한 상태였음이 발견되었다.
이 버킷들은 인증 없이 HTTP 요청만으로 접근 가능했으며, 브라우저를 통해 직접 데이터 다운로드가 가능한 상태였다.

노출된 버킷은 다음과 같다.

  • acp-deployment
  • acpcollector
  • acp-software
  • acp-ssl

해당 버킷들은 모두 Accenture Cloud Platform(Azure/GCP도 포함)과 관련된 내부 운영 데이터 및 고객 데이터를 포함하고 있었으며, 발견 직후 Accenture 측에 발견한 UpGuard의 연구원이 제보하였고, 다음 날 접근이 차단되었다고 한다.

사고 발생 원인 분석

1. S3 버킷 퍼블릭 접근 허용

S3 버킷이 Public Read 상태로 설정됨
인증 없이 누구나 접근 가능
결과적으로 외부 공격자가 별도의 침투 과정 없이 데이터 확보 가능

즉, 공격자는 단순히 S3 URL을 아는 것만으로 내부 데이터에 접근할 수 있었다.

2. 민감 정보가 저장된 스토리지의 보안 부족

S3는 객체 저장소일 뿐이며, 별도의 보안 설정이 없으면 인터넷에 그대로 노출된다.
Accenture는 내부 시스템 데이터와 동일한 수준의 민감 정보를 S3에 저장하면서도, 네트워크 레벨의 보호를 적용하지 않았다.

3. 접근 제어 및 키 관리 실패

버킷 내부에는 다음과 같은 정보가 포함되어 있었다.

  • AWS KMS Master Key (평문)
  • AWS Access Key 및 Secret Key
  • VPN Key
  • 인증서 및 Private Signing Key
  • JKS(Java KeyStore) 파일 및 비밀번호
  • 클라우드 접근 정보 (AWS, GCP, Azure)

노출 데이터 분석

각각의 버킷에 어떠한 데이터가 있었는지 상세히 나와있어 확인이 가능했는데, 내용은 다음과 같다.

acp-deployment

  • Identity API 관련 인증 정보
  • 내부 access key 및 credential
  • AWS KMS master key (평문)

acpcollector

  • 클라우드 인프라 구성 정보
  • VPN 키
  • 전체 클라우드 환경에 대한 뷰

acp-software

  • 137GB 규모 데이터
  • 고객 계정 정보
  • hashed password + plaintext password (약 40,000개)
  • 세션 정보 (JSession ID)

acp-ssl

  • 인증서 및 키스토어
  • SSL/TLS 관련 키

S3 Bucket Policy

취약한 경우 가정 사례

당시 s3의 외부 접근이 가능했고 브라우저로 직접 다운로드가 가능했다는 점을 보았을때, 아마도 s3에 적용된 정책은 다음과 같이 매우 단순하게 모든 것을 허용하고 있었을 가능성이 높아보인다.

(아래에 사용된 s3 policy들은 모두 샘플로 제작한 것이다. accenture 사고에서 공개된 관련 자료는 아니다)

외부 접근 + 다운로드 가능

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadObjects",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::acp-software/*"
    }
  ]
}
  • Principal: "*" 는 모든 사용자(인터넷 전체)
  • s3:GetObject 허용으로 객체 다운로드가 가능
  • 브라우저, curl, aws cli 등 어떤 방식으로든 접근 가능

ACL까지 열려 있었을 때

우선 ACL과 Bucket policy의 차이점/개념에 대해 먼저 알아보자.

  • ACL: 단순한 권한 부여 (누가 읽고/쓰는지만 지정)
  • Bucket Policy: 조건 기반의 정교한 접근 제어 (누가, 언제, 어디서, 어떻게까지 제어)

ACL은 객체 또는 버킷 단위로 허용만 제어하고 매우 단순한 권한 구조를 갖고 있다. 다만 이는 과거의 방식으로 최근에는 Bucket Policy 사용을 권장하고 있다고 한다.

구분ACLBucket Policy
적용 범위Bucket / ObjectBucket
표현 방식단순 권한JSON 정책
Allow / DenyAllow만 가능Allow + Deny
조건 제어불가능가능 (IP, VPC, TLS 등)
세밀한 제어어려움매우 정교함
사용 권장 여부거의 비권장권장

따라서 이 사례에서는 Bucket Policy뿐 아니라, 아래와 같이 ACL 기반 퍼블릭 공개가 함께 있었을 수도 있다.

예를 들면,

  • 버킷 ACL: public-read
  • 객체 ACL: public-read

이 경우 Bucket Policy가 아니더라도 외부 접근이 가능해질 수 있다.

  • Bucket Policy에서 public 허용
  • ACL에서 public 허용
  • S3 Block Public Access 미적용
  • 민감 버킷을 private 자산으로 분류하지 않음

이런 이유는 S3가 모든 정책을 합쳐서 평가하고, 그 중 하나라도 Allow가 있으면 접근이 가능해지기 때문이다.

  • IAM Policy (사용자/Role)
  • Bucket Policy
  • ACL (Bucket / Object)
  • S3 Block Public Access 설정

이러한 정책들을 모두 고려하여 평가한다. 평가 기준은 다음과 같다.

  1. 명시적 Deny → 무조건 차단
  2. Deny가 없다면 → Allow가 하나라도 있으면 허용
  3. 아무것도 없으면 → 기본적으로 Deny

따라서 퍼블릭 접근을 막으려면 1) allow가 없거나 2) 명시적 deny 정책이 하나라도 있거나 해야한다.

Best Practice

특정 IAM Role만

AccentureDeploymentRole만 읽고 쓰기가 가능하게 하려면 다음과 같이 설정할 수 있다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOnlySpecificRoleReadWrite",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AccentureDeploymentRole"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::acp-software/*"
    },
    {
      "Sid": "AllowOnlySpecificRoleListBucket",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AccentureDeploymentRole"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::acp-software"
    }
  ]
}
  • 특정 Role만 허용
  • 버킷과 객체 권한을 분리

HTTPS(TLS) 아닌 요청을 전부 차단

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::acp-software",
        "arn:aws:s3:::acp-software/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}
  • 이건 허용 정책이 아니라 명시적 Deny
  • HTTP 요청을 차단

VPC Endpoint를 통해서만 접근 허용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRequestsNotFromApprovedVPCE",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::acp-software",
        "arn:aws:s3:::acp-software/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:SourceVpce": "vpce-0abc123def4567890"
        }
      }
    }
  ]
}
  • 지정된 S3 Gateway/Interface Endpoint를 통하지 않은 접근은 전부 차단
  • 인터넷 직접 접근을 막음
  • 내부 워크로드 전용 버킷에 적합

인프라를 분석해볼 때도 이런 s3, dynamodb같은 경우 vpc endpoint를 사용해 퍼블릭 접근을 막고 내부에서만 사용할 수 있도록 하는 것을 여러 차례 언급했었는데 이런식으로 bucket policy에도 명시하여 해당 엔드포인트로만 접근할 수 있도록 설정한다.

Bucket Policy 외에도, 다음과 같은 설정이 필요하다.

  • S3 Block Public Access
  • ACL 사용 금지
  • Secrets를 S3에 저장하지 말 것

출처:

profile
hwup
Level up!
이전 포스트

클라우드 침해사고 사례 분석 #2 - Drizly

다음 포스트

클라우드 침해사고 사례 분석 #4 - Malindo Air(2019)

0개의 댓글