🔹 CORS란?
- 웹 브라우저 보안 메커니즘으로 웹 페이지가 다른 오리진(Origin)의 리소스 요청을
허용할지 판단하는 규칙
🔸 오리진(Origin) 정의
오리진은 다음 3가지 구성요소가 모두 동일해야 같은 오리진이야:
| 구성 요소 | 예시 |
|---|---|
| 프로토콜 | https |
| 호스트(도메인) | www.example.com |
| 포트 | 443 (HTTPS), 80 (HTTP 기본) |
🔁 하나라도 다르면 교차 오리진 요청(Cross-Origin) 필요!
🔸 CORS 작동 방식 예시
-
사용자가 웹사이트에 접속해 index.html 요청
-
HTML 안에서 다른 오리진의 자원(image, API 등) 요청
-
브라우저는 해당 요청을 보내기 전,
OPTIONS 사전 요청(Preflight)을 보냄
-
대상 서버(예: S3)가 CORS 설정을 통해 오리진과 메서드를 허용했는지 판단
-
허용 시 → 요청 실행
거부 시 → 브라우저가 요청 차단
🔸 Amazon S3에서 CORS는?
💡 S3 정적 웹 호스팅 시,
- A 버킷에서 HTML
- B 버킷에서 이미지, JS, CSS 등
🔐 왜?
브라우저가 보기엔 서로 다른 오리진이기 때문 (도메인 다름)
✅ 5. S3 CORS 설정 예시
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>*</AllowedOrigin> <!-- 모든 오리진 허용 -->
<AllowedMethod>GET</AllowedMethod> <!-- 허용할 메서드 -->
<AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>✳️ 실제 운영 환경에서는 * 대신 특정 오리진(https://www.example.com)을 명시하는 것이 보안상 더 좋음
🔸 S3 Glacier Vault Lock vs S3 Object Lock
| 항목 | S3 Glacier Vault Lock | S3 Object Lock |
|---|---|---|
| 📦 대상 | Glacier Vault (아카이브 전체) | S3 객체의 개별 버전 |
| 🔐 목적 | WORM 보장, 변경/삭제 방지→ 규정 준수용 장기 보관 | WORM 보장, 삭제/수정 방지→ 감사, 법적 증거 등 보존 |
| 🛠 설정 위치 | Vault 단위 정책 (JSON 형식) | 객체 단위 (버저닝 활성화, 버전 관리 필요) |
| 🧾 적용 시점 | 정책 설정 후 ‘잠금 완료’(Complete) 시 적용 | 객체 업로드 시 Retention/Legal Hold 설정 |
| ⏳ 보존 방식 | Vault에 있는 모든 객체에 일괄 적용 | 객체마다 보존 기간/법적 보존 설정 가능 |
| 🧱 삭제 불가 수준 | 매우 강력 (AWS도 삭제 못함) | 보존 모드에 따라 다름 (아래 참고) |
🔹 S3 잠금 정책 (Glacier Vault Lock, Object Lock)
🔸 S3 Glacier Vault Lock vs S3 Object Lock
| 항목 | S3 Glacier Vault Lock | S3 Object Lock |
|---|---|---|
| 📦 대상 | Glacier Vault (아카이브 전체) | S3 객체의 개별 버전 |
| 🔐 목적 | WORM 보장, 변경/삭제 방지→ 규정 준수용 장기 보관 | WORM 보장, 삭제/수정 방지→ 감사, 법적 증거 등 보존 |
| 🛠 설정 위치 | Vault 단위 정책 (JSON 형식) | 객체 단위 (버저닝 활성화, 버전 관리 필요) |
| 🧾 적용 시점 | 정책 설정 후 ‘잠금 완료’(Complete) 시 적용 | 객체 업로드 시 Retention/Legal Hold 설정 |
| ⏳ 보존 방식 | Vault에 있는 모든 객체에 일괄 적용 | 객체마다 보존 기간/법적 보존 설정 가능 |
| 🧱 삭제 불가 수준 | 매우 강력 (AWS도 삭제 못함) | 보존 모드에 따라 다름 (아래 참고) |
🔸 (번외) Lock vs 암호화 개념 비교
🔒Object Lock = 삭제/변경 방지 (불변성)
🔐 S3 암호화 = 데이터 보안 (내용 보호)
✅ 암호화는 언제든지 적용 가능 vs ❌ Object Lock은 버킷 생성 시에만 설정 가능!
🔹 S3 객체 접근 방식 (엑세스 포인트, Object Lambda)
| 항목 | S3 Access Point | S3 Object Lambda |
|---|---|---|
| 🎯 목적 | 다양한 사용자/애플리케이션이 정책과 네트워크 경계를 분리해서 S3에 접근하도록 허용 | Lambda 함수를 통해 객체 내용을 수정/필터링 후 응답 반환 |
| 📦 원본 객체 변경 여부 | ❌ 없음 (객체 그대로 반환) | ❌ 없음 (Lambda 함수가 응답만 수정함) |
| ⚙️ 내부 작동 방식 | S3 버킷 위에 별도의 엔드포인트 생성, IAM 정책 + VPC 제한 가능 | S3 Access Point 위에 Lambda 함수 연결, 접근 시 실시간 가공 |
| 🧠 사용 사례 | 대규모 사용자에게 S3 버킷을 분리된 정책으로 열어야 할 때(예: 각 부서별 접근 정책) | 민감 정보 제거, 포맷 변환, 특정 필드 마스킹 등 동적 객체 가공 |
| 🔐 보안 관점 | 세분화된 IAM 정책 설정 가능+ VPC 접근 제어 | S3 반환 전에 람다를 통해 데이터 가공/필터링 보안 강화 |
| 💡 특징 | 최대 수천 개 Access Point 생성 가능VPC 전용 설정도 가능 | 람다 함수 비용 + Object Lambda 호출 비용 발생 |
| 🧪 시험 출제 포인트 | “다중 사용자 환경에서 버킷에 접근 제어하려면?”➡️ Access Point 사용 | “S3 객체에서 민감 정보 제거하고 싶을 때?”➡️ Object Lambda 사용 |
📝 상황별 적합한 기능
| 상황 | 답 |
|---|---|
| 🚪 S3에 대한 다양한 정책 기반 접근 경로 만들고 싶어 | S3 Access Point |
| 🧹 객체 읽기 전에 민감 정보 제거하거나 포맷 바꾸고 싶어 | S3 Object Lambda |
| 🤖 객체 직접 수정은 안 하고, 응답만 바꾸고 싶어 | S3 Object Lambda |
| 🧍 사용자마다 S3 접근 제어를 다르게 하고 싶어 | S3 Access Point |
how to define. how to solve.