S3 Encryption for Objects & Security

AWS를 공부하면서 알게된 S3 Encryption for Objects와 Security에 대하여 간단하게 정리하겠습니다. 

이미 아시는분은 참고만 해주시면 감사드리겠습니다. 

---

# SSE-S3 

amazon s3에 객체를 업로드 [HTTP, HTTPS 이용함]
-> “x-amz-server-side-encryption": "AES256" 헤더를 추가함
-> amazon s3는 이 헤더를 통해 고유의 s3관리 데이터키를 사용해야 한다는 사실을 인식함
-> s3관리데이터키와 객체를 사용하여 암호화가 이루어짐
-> 객체는 암호화되어 amazon s3 버킷에 저장이 됨
즉 amzon s3에서 데이터키를 전부 소유, 관리함. 

 

# SSE-KMS 

원리는 SSE-S3 와 같지만 KMS에서 처리 및 관리하는 키를 사용한 암호화. 

서버측에서 객체가 암호화되고 SSE-S3와 마찬가지로  “x-amz-server-side-encryption": ”aws:kms" 헤더가 필요함. 

KMS의 장점으로 CloudFront의 감사추적을 사용하여 누가 어떤키에 접근할 수 있을지 제어가 가능하고 감사추적이 가능함.  

 

# SSE-C 

AWS 외부에서 고객이 완전히 관리하는 데이터 키를 사용한 서버 측 암호화. 

Amazon S3는 사용자가 제공한 암호화 키를 저장하지 않고 HTTPS를 반드시 사용해야됨. 

키는 한번 사용후 폐기되기 때문에 모든 HTTP 요청에 대해 HTTP 헤더에 암호화 키를 제공하여야됨. 

 

# Client Side Encryption 

Amazon S3에 객체를 업로드하기 전 클라이언트[우리]가 객체를 암호화 하기 때문에 클라이언트가 완전히  키 및 암호화 주기를 완전히 관리함. 

---

Security 

 

# IAM Policies 

 

# Resource Based Policies 

 

#  네트워킹[VPC 앤드포인트를 지원함] 

 

# 로깅과 감사 

- S3접근 로그는 S3버킷에 저장가능함. 

- API 호출은 AWS CloudTrail에 기록될 수 있음. 

-> cf) 검증된 로그 파일을 사용하면 로그 파일 자체가 변경되지 않았음을 또는 특정 사용자 자격 증명이 특정 API 활동을 수행했음을 확실하게 주장할 수 있습니다. 또한 CloudTrail 로그 파일 무결성 검증 프로세스를 사용하면 로그 파일이 삭제 또는 변경되었는지 여부를 알 수 있거나 특정 시간 동안 사용자 계정으로 로그 파일이 전송되지 않았음을 확실하게 주장할 수 있음. 

 

# MFA Delete 

특정 버전 객체를 버킷에서 삭제하고 싶은 경우에 MFA삭제를 활성화하면 됨. 그러면 MFA로 인증이 되어야만 객체를 삭제할 수 있음. 
-> 의도하지 않은 버킷의 삭제를 방지할 수 있음.  

 

# Pre - Signed URLs