S3 액세스 제어: 버킷 정책 및 ACL
버킷 정책을 작성하고 ACL과 비교하며, 안전한 호스팅을 위해 퍼블릭 액세스 차단 설정을 구성합니다.
S3 액세스 제어: 버킷 정책 및 ACL은(는) CoddyKit의 무료 Cloud & IT Cert Prep 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Cloud & IT Cert Prep 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Cloud & IT Cert Prep 강의에는 총 4개의 강의가 포함되어 있습니다.
S3 액세스 제어 개요
S3는 여러 가지 중첩되는 액세스 제어 메커니즘을 제공합니다. IAM 정책(자격 증명 기반, 주체가 수행할 수 있는 작업 제어), 버킷 정책(버킷에 적용하는 리소스 기반 JSON 정책), 액세스 제어 목록(ACL)(기존 객체별/버킷별 권한 부여), S3 퍼블릭 액세스 차단(다른 정책과 관계없이 모든 퍼블릭 액세스를 차단하는 계정 또는 버킷 수준 재정의)이 있습니다. 오늘날 대부분의 사용 사례에서는 버킷 정책과 퍼블릭 액세스 차단을 함께 사용하는 방식이 권장되며, ACL은 기존 방식으로 간주됩니다.
버킷 정책: 리소스 기반 JSON
버킷 정책은 S3 버킷에 직접 연결되는 JSON 문서입니다. 어떤 주체(IAM 사용자, 역할, AWS 계정, 서비스 또는 공개 사용자)가 어떤 작업을 어떤 리소스(버킷 및/또는 특정 키 접두사)에 수행할 수 있는지 지정합니다. 버킷 정책은 IAM 역할 없이도 계정 간 Access를 지원합니다. 예를 들어 다른 AWS 계정의 IAM 역할에 특정 객체에 대한 읽기 Access를 버킷 정책에서 직접 부여할 수 있습니다. 각 버킷에는 하나의 정책을 연결할 수 있으며, 최대 크기는 20 KB입니다.
# Allow a specific IAM role from another account to read objects
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': {
'AWS': 'arn:aws:iam::999999999999:role/PartnerReadRole'
},
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/partner-data/*'
}]
}객체를 공개적으로 읽을 수 있게 설정하기
정적 웹사이트 자산이나 공개 데이터세트와 같은 공개 콘텐츠를 제공하려면 버킷 정책을 통해 객체를 누구나 읽을 수 있도록 설정할 수 있습니다. 먼저 버킷 수준에서 Block Public Access를 비활성화한 다음, Principal: '*' 및 Action: s3:GetObject를 포함하는 버킷 정책 명령문을 추가합니다. Block Public Access 설정 비활성화와 버킷 정책 Allow는 함께 필요합니다. 둘 중 하나만 설정해서는 작동하지 않습니다. 모든 객체를 의도적으로 공개하려는 경우가 아니라면 Resource 범위는 전체 버킷이 아니라 특정 접두사로 항상 제한해야 합니다.
# Public read policy for static website assets
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': '*',
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-website-bucket/public/*'
}]
}S3 Block Public Access 설정
S3 Block Public Access는 버킷 정책과 ACLs를 재정의하는 네 가지 설정으로 구성된 안전장치입니다. BlockPublicAcls(공개 ACLs 설정 요청을 거부), IgnorePublicAcls(기존 공개 ACLs를 무시), BlockPublicPolicy(공개 Access를 부여하는 버킷 정책을 거부), RestrictPublicBuckets(공개 정책에 따라 Access를 제한)가 있습니다. 네 설정은 모두 기본적으로 활성화되어 있습니다. 계정 수준에서도 Block Public Access를 활성화하여 개별 버킷 설정과 관계없이 모든 버킷에서 이를 차단할 수 있습니다. 이는 실수로 공개되는 것을 방지하는 데 적합합니다.
# Enable all Block Public Access settings on a bucket
aws s3api put-public-access-block \
--bucket my-private-bucket \
--public-access-block-configuration \
BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=trueAccess Control Lists (ACLs): 레거시
S3 ACLs는 IAM보다 먼저 도입된 원래의 Access 제어 메커니즘입니다. ACL은 AWS 계정 또는 미리 정의된 그룹(모든 사용자, 인증된 AWS 사용자, 로그 전송)에 미리 정의된 권한(READ, WRITE, FULL_CONTROL)을 부여합니다. ACLs는 버킷 수준이나 개별 객체 수준에 적용할 수 있습니다. 이제 AWS는 ACLs를 비활성화하고(S3의 'Bucket Owner Enforced' 설정은 버킷 소유자가 모든 객체를 소유하게 하며 ACLs를 비활성화함) 대신 버킷 정책과 IAM을 사용할 것을 권장합니다. ACLs는 레거시 개념으로서 여전히 SAA-C03 시험에 출제됩니다.
# Disable ACLs by setting ownership to BucketOwnerEnforced
aws s3api put-bucket-ownership-controls \
--bucket my-bucket \
--ownership-controls '{"Rules":[{"ObjectOwnership":"BucketOwnerEnforced"}]}'CloudFront용 Origin Access Control
CloudFront를 통해 S3 콘텐츠를 제공할 때는 버킷을 비공개로 유지하면서 CloudFront는 객체를 가져올 수 있어야 합니다. Origin Access Identity (OAI)를 대체하는 최신 방식인 Origin Access Control (OAC)을 사용하세요. OAC는 버킷 정책에서 s3:GetObject 권한을 부여할 CloudFront ID를 생성하고, Block Public Access는 활성화된 상태로 유지합니다. 이렇게 하면 사용자는 캐싱, WAF, HTTPS를 위해 반드시 CloudFront를 거쳐야 하며 버킷에 직접 Access할 수 없습니다. 이는 SAA-C03 시험에서 흔히 다루는 보안 아키텍처 패턴입니다.
# Bucket policy granting CloudFront OAC access
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': {
'Service': 'cloudfront.amazonaws.com'
},
'Action': 's3:GetObject',
'Resource': 'arn:aws:s3:::my-bucket/*',
'Condition': {
'StringEquals': {
'AWS:SourceArn': 'arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE'
}
}
}]
}계정 간 S3 Access
다른 AWS 계정에 S3 버킷 Access 권한을 부여하는 방법은 두 가지입니다. 옵션 1 — 버킷 정책: 외부 계정의 ARN을 Principal로, 원하는 S3 작업을 포함하는 명령문을 추가합니다. 외부 계정의 IAM 사용자/역할에는 여전히 S3를 호출할 IAM 권한이 필요하며, 버킷 정책도 이들을 Allow해야 합니다. 옵션 2 — 신뢰 정책이 있는 IAM 역할: 외부 계정을 신뢰하는 역할을 내 계정에 생성합니다. 외부 계정의 ID가 해당 역할을 맡으면 내 버킷의 권한을 얻습니다. 읽기 전용 시나리오에는 버킷 정책이 더 간단하며, 운영상 Access에는 역할이 더 적합합니다.
웹 애플리케이션용 CORS 구성
Cross-Origin Resource Sharing (CORS)를 사용하면 한 도메인에서 호스팅되는 웹 애플리케이션이 다른 도메인의 S3 버킷으로 JavaScript 가져오기 요청을 보낼 수 있습니다. CORS 구성이 없으면 브라우저는 보안을 위해 이러한 요청을 차단합니다. 허용된 오리진, HTTP 메서드, 헤더를 지정하는 CORS 구성을 버킷에 추가합니다. CORS는 example.com에서 호스팅되는 React SPA가 S3 버킷 URL에서 이미지나 파일을 직접 가져올 때 흔히 필요합니다.
# Apply a CORS configuration
aws s3api put-bucket-cors \
--bucket my-website-bucket \
--cors-configuration '{"CORSRules":[{"AllowedOrigins":["https://example.com"],"AllowedMethods":["GET"],"AllowedHeaders":["*"],"MaxAgeSeconds":3600}]}'임시 Access를 위한 사전 서명 URL
사전 서명 URL은 버킷이나 객체 권한을 변경하지 않고 비공개 S3 객체에 대해 시간 제한이 있는 Access를 GET 또는 PUT 방식으로 부여합니다. URL에는 자격 증명과 만료 시간이 포함되며, URL을 가진 사람은 만료될 때까지 객체에 Access할 수 있습니다. 사전 서명 URL은 다음과 같은 경우에 사용합니다. 앱의 인증된 사용자가 비공개 파일을 다운로드하도록 허용할 때, 클라이언트가 백엔드를 거치지 않고 S3에 직접 업로드하도록 허용할 때, 또는 보고서를 일시적으로 공유할 때입니다. 만료 시간은 1초부터 7일까지 설정할 수 있으며, STS 임시 자격 증명을 사용할 경우 최대 12시간입니다.
# Generate a pre-signed GET URL valid for 24 hours
aws s3 presign s3://my-private-bucket/reports/invoice.pdf \
--expires-in 86400
# Generate a pre-signed PUT URL (for client uploads)
aws s3 presign s3://my-private-bucket/uploads/new-file.pdf \
--expires-in 3600 \
--method PUT보안을 위한 버킷 정책 조건
버킷 정책 조건을 사용하면 컨텍스트 기반 보안을 추가할 수 있습니다. 일반적인 패턴은 다음과 같습니다. aws:SourceIp는 Access를 특정 IP 범위(VPC 엔드포인트 또는 회사 네트워크 등)로 제한합니다. aws:SecureTransport: true는 HTTP 요청을 Deny하여 HTTPS를 강제하며, 민감한 데이터를 저장하는 모든 버킷의 모범 사례입니다. s3:x-amz-server-side-encryption은 객체를 서버 측 암호화와 함께 업로드하도록 보장합니다. aws:PrincipalOrgID는 Access를 AWS Organisation 내의 주체로 제한하여 외부 계정으로의 데이터 유출을 방지합니다.
# Deny non-HTTPS access to the bucket
{
'Effect': 'Deny',
'Principal': '*',
'Action': 's3:*',
'Resource': [
'arn:aws:s3:::my-secure-bucket',
'arn:aws:s3:::my-secure-bucket/*'
],
'Condition': {
'Bool': {'aws:SecureTransport': 'false'}
}
}비공개 Access를 위한 S3 VPC 엔드포인트
기본적으로 비공개 서브넷의 EC2 인스턴스는 인터넷을 통해 NAT 게이트웨이 경유로 S3에 Access합니다. 이로 인해 NAT 비용이 발생하고 트래픽이 공용 인터넷에 노출됩니다. S3 Gateway Endpoints는 추가 비용 없이 NAT 게이트웨이 없이도 VPC 내부에서 S3로 비공개 연결을 제공합니다. Gateway Endpoint를 라우팅 테이블에 추가하면 S3로 향하는 트래픽은 AWS의 비공개 네트워크를 통해 자동으로 라우팅됩니다. aws:SourceVpce를 사용하는 버킷 정책 조건을 추가하여 엔드포인트를 통해 들어오는 요청으로만 Access를 제한할 수도 있습니다.
# Create an S3 gateway endpoint and associate with route tables
aws ec2 create-vpc-endpoint \
--vpc-id vpc-12345678 \
--service-name com.amazonaws.us-east-1.s3 \
--route-table-ids rtb-12345678빠른 확인
이 레슨에서 다룬 AWS Solutions Architect (SAA-C03) 개념을 얼마나 이해했는지 확인해 보세요.
레슨 요약
이 레슨에서는 다음을 학습했습니다. 버킷 정책은 S3에 대한 계정 간 및 서비스 Access를 제어하는 리소스 기반 JSON 문서입니다, S3 Block Public Access는 실수로 공개되는 것을 방지하는 안전 재정의 기능입니다, 그리고 사전 서명 URL, VPC 엔드포인트 및 CORS 구성은 특정 Access 패턴을 안전하게 처리합니다. 다음으로 S3 버전 관리, MFA Delete, 복제를 다룹니다.
AI 튜터와 함께 Cloud & IT Cert Prep을(를) 배우세요 — 무료
브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.
- 코스
- 150
- 레슨
- 600
자주 묻는 질문
“S3 액세스 제어: 버킷 정책 및 ACL” 강의는 무료인가요?
네 — “S3 액세스 제어: 버킷 정책 및 ACL” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Cloud & IT Cert Prep 강의 전체를 잠금 해제할 수 있습니다. Cloud & IT Cert Prep 강의에는 총 4개의 강의가 포함되어 있습니다.
“S3 액세스 제어: 버킷 정책 및 ACL”에서 뭘 배우나요?
버킷 정책을 작성하고 ACL과 비교하며, 안전한 호스팅을 위해 퍼블릭 액세스 차단 설정을 구성합니다. 브라우저에서 직접 실행하는 실습 코드로 Cloud & IT Cert Prep을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
Cloud & IT Cert Prep을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 Cloud & IT Cert Prep은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.
“S3 액세스 제어: 버킷 정책 및 ACL” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 Cloud & IT Cert Prep 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 Cloud & IT Cert Prep 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 버킷, 객체 및 리전
- S3 액세스 제어: 버킷 정책 및 ACL
- 버전 관리, MFA 삭제 및 복제
- 스토리지 클래스 및 수명 주기 정책