AWS S3 보안 완전 가이드 — 암호화·접근 제어·가용성·컴플라이언스

1. S3 암호화 방식

S3의 암호화는 크게 서버 사이드 암호화(SSE)와 클라이언트 사이드 암호화(CSE)로 나뉩니다. 서버 사이드는 AWS가 데이터를 저장할 때 자동으로 암호화하고, 클라이언트 사이드는 데이터를 업로드하기 전에 사용자가 직접 암호화합니다.

방식	키 관리 주체	감사 로그	콘솔 지원	주요 사용 사례
SSE-S3	AWS (완전 관리)	미지원	지원	기본 암호화, 규정 없음
SSE-KMS	고객 (KMS CMK)	CloudTrail	지원	ISMS-P, PCI-DSS, 금융권
SSE-KMS (DSSE)	고객 (KMS CMK)	CloudTrail	지원	이중 암호화 요구 규정 (FIPS 140-3)
SSE-C	고객 (외부 키)	제한적	미지원	온프레미스 HSM 연동
CSE	고객 (완전 자체)	자체 구현	미지원	최고 기밀 데이터, 주권 클라우드

전송 중 암호화 (Encryption in Transit)

저장 시 암호화 외에 전송 중 암호화도 필수입니다. S3는 HTTP와 HTTPS를 모두 허용하므로 버킷 정책으로 HTTPS를 강제해야 합니다.

// 버킷 정책 — HTTP 요청 거부 (전송 중 암호화 강제)
{
  "Sid": "DenyNonHTTPS",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ],
  "Condition": {
    "Bool": { "aws:SecureTransport": "false" }
  }
}

2. S3 접근 경로와 제어

S3에 접근하는 경로는 크게 퍼블릭 인터넷과 VPC 내부로 나뉩니다. 접근 경로를 최소화하고 VPC 엔드포인트를 통해 트래픽이 퍼블릭 인터넷을 경유하지 않도록 하는 것이 보안의 핵심입니다.

S3 Gateway 엔드포인트 vs Interface 엔드포인트

항목	Gateway 엔드포인트	Interface 엔드포인트 (PrivateLink)
비용	무료	시간당 요금 + 데이터 처리 요금
DNS 해석	라우팅 테이블 기반	Private DNS (VPC DNS 해석)
온프레미스 연동	불가 (VPC 내부만)	가능 (Direct Connect/VPN 경유)
엔드포인트 정책	지원	지원
적합한 환경	VPC 내 EC2/Lambda	온프레미스 연동, 멀티 VPC

퍼블릭 액세스 차단 (Block Public Access)

S3에는 4가지 퍼블릭 액세스 차단 설정이 있습니다. 특별한 이유가 없다면 모두 활성화해야 합니다.

설정	차단 대상	권장
BlockPublicAcls	퍼블릭 ACL 추가 및 PUT 요청 차단	활성화
IgnorePublicAcls	기존 퍼블릭 ACL 무시	활성화
BlockPublicPolicy	퍼블릭 액세스를 허용하는 버킷 정책 차단	활성화
RestrictPublicBuckets	퍼블릭 정책이 있는 버킷에서 퍼블릭·교차 계정 액세스 제한	활성화

3. 버전 관리 & 크로스 리전 복제로 가용성 확보

S3는 99.999999999%(11 9's) 내구성을 제공하지만, 랜섬웨어·실수 삭제·리전 장애에 대비하려면 버전 관리(Versioning)와 복제(Replication)를 함께 사용해야 합니다.

버전 관리 (Versioning)

항목	설명
동작 방식	같은 키로 업로드 시 새 버전 ID 부여 — 기존 버전 보존
삭제 동작	DELETE 요청 시 삭제 마커(Delete Marker) 생성 — 이전 버전 유지
MFA Delete	버전 영구 삭제 시 MFA 토큰 필요 — 랜섬웨어·내부자 공격 대응
수명 주기 정책	오래된 버전을 Glacier로 전환하거나 자동 삭제해 비용 절감
Object Lock	WORM(쓰기 1회·읽기 다수) 모드 — Compliance 또는 Governance 모드

복제 (Replication)

유형	설명	사용 사례
CRR (Cross-Region Replication)	다른 리전의 버킷으로 자동 복제	재해 복구(DR), 지역 규정(데이터 주권), 지연 시간 감소
SRR (Same-Region Replication)	같은 리전 내 다른 버킷으로 복제	로그 집계, 개발/운영 환경 데이터 동기화, 계정 간 복제
RTC (Replication Time Control)	99.99% 객체를 15분 내 복제 SLA 보장	RPO 15분이 요구되는 규정 환경

4. 버킷 정책 실전 예시

버킷 정책은 JSON 기반의 리소스 기반 정책으로, IAM 정책과 함께 S3 접근의 핵심 제어 수단입니다. 아래는 실무에서 자주 사용하는 패턴입니다.

패턴 1 — 특정 VPC 엔드포인트에서만 접근 허용

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowVPCEOnly",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::my-private-bucket",
        "arn:aws:s3:::my-private-bucket/*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:sourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

패턴 2 — SSE-KMS 암호화 강제 (암호화되지 않은 PUT 차단)

{
  "Sid": "DenyUnencryptedObjectUploads",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "aws:kms"
    }
  }
}

패턴 3 — CloudFront OAC를 통한 정적 웹사이트 배포

{
  "Sid": "AllowCloudFrontOAC",
  "Effect": "Allow",
  "Principal": {
    "Service": "cloudfront.amazonaws.com"
  },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-website-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
    }
  }
}

패턴 4 — 특정 IAM 역할만 허용 + 다른 모든 접근 차단

{
  "Sid": "DenyAllExceptSpecificRole",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::my-sensitive-bucket",
    "arn:aws:s3:::my-sensitive-bucket/*"
  ],
  "Condition": {
    "ArnNotLike": {
      "aws:PrincipalArn": [
        "arn:aws:iam::123456789012:role/DataAccessRole",
        "arn:aws:iam::123456789012:role/AuditRole"
      ]
    }
  }
}

패턴 5 — 교차 계정 접근 (백업 계정으로 데이터 전송)

{
  "Sid": "CrossAccountBackup",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::BACKUP-ACCOUNT-ID:role/BackupRole"
  },
  "Action": [
    "s3:GetObject",
    "s3:PutObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::my-backup-bucket",
    "arn:aws:s3:::my-backup-bucket/*"
  ]
}

5. S3 보안 침해 사례

S3 보안 사고의 대부분은 잘못된 설정(Misconfiguration)에서 비롯됩니다. 대표적인 실제 사례를 통해 어떤 설정이 공격 경로가 되는지 살펴봅니다.

사례에서 얻는 교훈

공격 패턴	대응 방법
SSRF + IMDS 자격증명 탈취	IMDSv2 강제 적용, EC2 역할에 최소 권한만 부여
퍼블릭 버킷 노출	Block Public Access 4개 설정 전체 활성화, AWS Config 규칙으로 지속 감시
과도한 IAM 권한	특정 버킷·접두사 단위 권한 부여, IAM Access Analyzer 사용
유출 지연 탐지	S3 Server Access Logging + CloudTrail Data Events + GuardDuty S3 보호 활성화
민감 데이터 무분별 저장	Macie로 PII/민감 데이터 자동 탐지 및 분류

6. 컴플라이언스별 S3 설정

주요 보안 규정은 S3에 저장·전송되는 데이터에 대해 구체적인 기술 요건을 요구합니다. 아래 체크리스트는 ISMS-P, PCI-DSS v4, 금융보안원 클라우드 가이드 기준입니다.

마무리

S3는 설정이 쉬운 만큼 보안 실수도 쉽게 발생합니다. 핵심 원칙을 정리하면 다음과 같습니다.

영역	핵심 원칙
암호화	SSE-KMS CMK + HTTP 차단 버킷 정책 = 저장·전송 모두 암호화
접근 제어	Block Public Access 전체 활성화 + VPC 엔드포인트 + 최소 권한 IAM
가용성	Versioning + MFA Delete + CRR = 삭제·랜섬웨어·리전 장애 대응
감사	CloudTrail Data Events + Macie + GuardDuty = 탐지·분류·대응
거버넌스	AWS Config + Security Hub + SCP = 지속적 컴플라이언스 자동화