✍ Back-End 지식을 늘리자!
백엔드 개발자를 준비하면서 생긴 궁금증을 정리한 포스트입니다.
들어가기 전
이전 포스트에서는 AWS S3의 개념과 파일 업로드 방식에 대해 정리했습니다.
이번 포스트에서는 실제로 S3에 이미지를 올리기 전에 AWS에서 어떤 설정을 해두어야 하는지 정리해보겠습니다.
1. AWS 회원가입
먼저 AWS 계정을 생성해야 합니다.
AWS 계정을 만들면 가장 처음에는 루트(root) 사용자로 시작하게 됩니다.
다만 루트 계정은 모든 AWS 리소스에 대한 전체 권한을 가진 계정이기 때문에,
일상적인 작업에는 사용하지 않는 것이 권장됩니다.
AWS도 루트 사용자는 꼭 필요한 작업에만 사용하고, 평소에는 별도의 관리자 계정을 만들어 사용하라고 안내합니다.
또한 계정 생성 후에는 결제 정보를 등록하게 되므로, 과금이 발생하지 않도록 리소스 관리를 함께 신경 써야 합니다. :contentReference[oaicite:2]{index=2}
2. AWS 보안 설정
회원가입이 끝났다면 가장 먼저 해야 할 일은 루트 계정에 MFA를 설정하는 것입니다.
MFA는 비밀번호 외에 추가 인증 수단을 하나 더 요구하는 방식이라,
계정이 탈취되더라도 보안을 크게 높일 수 있습니다.
AWS는 루트 사용자에 MFA를 설정할 것을 강하게 권장하고 있으며,
루트 계정은 평소 사용하지 말고 안전하게 보관하라고 안내합니다.
또한 루트 사용자에 대해서는 액세스 키를 만들지 않는 것도 권장합니다. :contentReference[oaicite:3]{index=3}
3. IAM 관리자 계정 생성
루트 계정 설정이 끝났다면, 이제 일상적으로 사용할 관리자용 IAM 계정을 만듭니다.
IAM은 AWS 리소스에 대한 접근 권한을 세밀하게 제어할 수 있게 해주는 서비스입니다.
즉, 루트 계정 대신 필요한 권한만 가진 사용자나 역할을 만들어 사용할 수 있습니다.
AWS도 루트 계정 대신 별도의 관리자 사용자를 만들어 일상 작업에 사용하라고 권장합니다. :contentReference[oaicite:4]{index=4}
실습이나 개인 프로젝트라면 관리자용 IAM 사용자를 하나 만들어도 괜찮습니다.
다만 실제 운영 환경이나 팀 환경에서는 무조건 광범위한 권한을 주기보다
필요한 권한만 최소로 부여하는 것이 더 안전합니다.
AWS는 IAM 보안 모범 사례에서 최소 권한 원칙(least privilege) 과 임시 자격 증명 사용을 권장합니다. :contentReference[oaicite:5]{index=5}
4. IAM 계정으로 로그인
IAM 사용자를 만들었다면, 이제부터는 루트 계정 대신 그 IAM 계정으로 로그인해서 작업하는 것이 좋습니다.
루트 계정은 계정 설정 변경이나 정말 필요한 고권한 작업에만 쓰고,
평소 콘솔 접속과 서비스 관리, 실습은 IAM 계정으로 진행하는 편이 안전합니다. :contentReference[oaicite:6]{index=6}
그리고 가능하다면 이 IAM 관리자 계정에도 MFA를 함께 적용하는 것이 좋습니다.
AWS는 루트 사용자뿐 아니라 IAM 사용자에도 MFA를 적용할 수 있도록 지원합니다. :contentReference[oaicite:7]{index=7}
5. S3 버킷 생성
IAM 계정으로 로그인한 뒤 S3 콘솔에 들어가 버킷을 생성합니다.
버킷 이름을 만들 때는 주의할 점이 있습니다.
S3 일반 목적 버킷 이름은 전역 네임스페이스를 사용하므로,
같은 파티션 안의 모든 AWS 계정과 리전에서 고유해야 합니다.
즉, 너무 단순한 이름은 이미 다른 사용자가 쓰고 있을 가능성이 높습니다. :contentReference[oaicite:8]{index=8}
또한 버킷을 만들 때는 리전을 함께 선택하게 됩니다.
애플리케이션이 한국 사용자 대상이라면 보통 서울 리전을 선택하는 것이 자연스럽습니다.
리전은 나중에 운영 환경과 가깝게 맞추는 것이 지연 시간과 관리 측면에서 유리합니다.
버킷 이름과 리전은 생성 후 변경할 수 없는 설정이 있으므로 처음에 신중히 정하는 편이 좋습니다. :contentReference[oaicite:9]{index=9}
6. 퍼블릭 액세스 설정은 신중하게
여기서 중요한 점이 하나 있습니다.
S3는 기본적으로 새 버킷과 객체가 공개되지 않도록 설계되어 있고,
AWS는 Block Public Access를 켜 두는 것을 권장합니다.
즉, 단순히 이미지 URL이 필요하다는 이유만으로 바로 퍼블릭 액세스를 열어두는 것은 조심해야 합니다. :contentReference[oaicite:10]{index=10}
프로필 이미지처럼 외부에서 바로 보여야 하는 파일이라면 두 가지 방식 중 하나를 많이 선택합니다.
-
버킷은 비공개로 유지하고 Presigned URL을 사용한다.
이 방식은 일정 시간 동안만 접근 가능한 URL을 만들 수 있어서 더 안전합니다. :contentReference[oaicite:11]{index=11} -
정말 공개가 필요한 파일만
s3:GetObject로 공개 읽기 허용한다.
이 경우에도 업로드(PutObject)나 삭제(DeleteObject) 권한까지 공개하면 안 됩니다.
공개가 필요한 경우는 읽기 권한만 최소 범위로 열어야 합니다. :contentReference[oaicite:12]{index=12}
즉, “이미지 업로드가 목적이니 퍼블릭 액세스를 전부 해제한다”보다는
비공개 유지가 기본, 꼭 필요한 경우에만 공개 읽기 허용으로 이해하는 편이 더 안전합니다. :contentReference[oaicite:13]{index=13}
7. S3 버킷 정책 설정
버킷 정책은 JSON 형태로 S3 리소스에 대한 접근 권한을 정의하는 정책입니다.
여기서 꼭 주의해야 할 점은 버킷 정책 JSON에는 주석을 넣을 수 없다는 것입니다.
원문처럼 // 정책 버전 같은 주석을 넣으면 JSON 형식 오류가 납니다.
또한 공개 정책을 작성할 때는 PutObject, DeleteObject를 Principal: "*"로 열어두면 매우 위험합니다.
공개가 필요하다면 일반적으로 GetObject만 공개합니다. :contentReference[oaicite:14]{index=14}
공개 읽기가 정말 필요한 경우의 예시는 다음처럼 정리하는 편이 안전합니다.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadForObjects",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::your-bucket-name/*"
}
]
}이 정책은 버킷 안 객체에 대해 읽기만 공개합니다.
업로드와 삭제는 공개하지 않습니다.
AWS 문서에서도 공개 웹 액세스가 필요한 경우 s3:GetObject 공개 읽기 정책을 예시로 안내합니다. (AWS Documentation)
8. Object Ownership과 ACL도 함께 확인하기
최근 S3에서는 새 버킷을 만들면 기본적으로 Bucket owner enforced가 적용되고,
이 상태에서는 ACL이 비활성화됩니다.
즉, 예전처럼 객체 ACL 중심으로 권한을 관리하기보다
버킷 정책이나 IAM 정책 중심으로 권한을 관리하는 방식이 기본입니다. (AWS Documentation)
따라서 예전 글이나 튜토리얼에서 public-read ACL을 넣는 예시를 보더라도,
현재 설정에서는 그대로 적용되지 않을 수 있습니다.
이 경우 정책 기반 접근 제어로 생각하는 편이 더 맞습니다. (AWS Documentation)
9. 업로드용 IAM 계정 또는 역할 준비
원문처럼 S3manager용 IAM 사용자를 따로 만드는 방식은 이해하기 쉽고,
로컬 개발 환경에서는 실습용으로 사용할 수 있습니다.
다만 AWS는 가능하면 IAM 역할을 통한 임시 자격 증명 사용을 더 권장합니다.
특히 EC2, ECS, Lambda 같은 AWS 워크로드에서는 액세스 키를 코드에 넣기보다
IAM 역할을 붙여서 임시 자격 증명을 쓰는 방식이 더 안전합니다. (AWS Documentation)
그래도 로컬 개발 환경에서 IAM 사용자 액세스 키를 써야 한다면 다음 원칙을 지키는 것이 좋습니다.
- 필요한 S3 권한만 최소로 부여하기
- 액세스 키를 코드에 하드코딩하지 않기
- 환경 변수나 비밀 관리 도구로 관리하기
- Git 저장소에 올리지 않기 (AWS Documentation)
즉, AmazonS3FullAccess를 그대로 주는 것보다는
실제로 필요한 버킷과 작업만 허용하는 최소 권한 정책이 더 안전합니다. (AWS Documentation)
10. 액세스 키 발급 시 주의할 점
액세스 키를 발급받으면 Access key ID와 Secret access key가 함께 제공됩니다.
이 값은 외부에 노출되면 곧바로 리소스 접근으로 이어질 수 있으므로 매우 민감한 정보입니다.
AWS도 액세스 키 사용 시 최소 권한과 MFA, 역할 기반 임시 자격 증명을 함께 고려하라고 안내합니다. (AWS Documentation)
따라서 액세스 키는 다음처럼 관리하는 것이 좋습니다.
.env또는 환경 변수에 저장- 코드나 설정 파일에 직접 커밋하지 않기
- 더 이상 쓰지 않는 키는 즉시 비활성화 또는 삭제하기
📌 결론
이번 포스트에서는 S3에 이미지를 업로드하기 전에 AWS에서 준비해야 할 설정을 정리해보았습니다.
정리해보면 다음과 같습니다.
- 루트 계정은 가입 후 MFA를 설정하고 평소에는 사용하지 않습니다.
- 일상 작업은 IAM 관리자 계정으로 진행합니다.
- S3 버킷은 고유한 이름과 적절한 리전으로 생성합니다.
- 퍼블릭 액세스는 기본적으로 막아두고, 꼭 필요한 경우에만 최소 범위로 엽니다.
- 공개 버킷 정책이 필요하다면
GetObject만 공개하는 방식으로 신중하게 작성합니다. - 업로드용 자격 증명은 가능하면 IAM 역할을 우선 고려하고, 액세스 키는 안전하게 관리합니다. (AWS Documentation)
즉, S3를 “파일 올리는 저장소”로만 보기보다
권한과 보안 설정까지 함께 설계해야 하는 서비스로 이해하는 것이 중요합니다.
