-
S3와 CloudFront를 이용한 객체 보안 (1)AWS 2020. 2. 10. 23:17
오랫동안 서비스에서 첨부파일을 별다른 보안없이 S3에 업로드하여 제공하였다. 시간이 흘러 필연적으로 구글로 부터 보안 검사를 해야 Gmail API를 계속 사용할 수 있다는 경고를 받았다. 우리 서비스에서 사용하는 API 범위가 개인정보를 민감하게 다루기 때문에 구글에서 인가된 업체를 통해 평가(Assessment)를 받아야 한다는 것이다. 이 이야기에 대해서는 나중에 다루도록 하겠다.
어쨌든 보안 평가에서 나온 지적사항 중 하나가 첨부파일이 보안되지 않은 채 Public URL접근이 가능하다는 것이다. 실제 첨부파일을 S3에 올릴 때 파일명(Object Key)을 난수로 생성하여 업로드하기 때문에 파일 경로를 유추하기 매우 어렵지만 Brutal Force Attack의 위험에는 충분히 노출돼있었다. 그리고 한 번 노출된 URL은 누군가가 외부로 유출한다면 모든 사람들이 접근할 수 있기 때문에 보안 평가에서 지적사항으로 나온 것이다. 당연히 서비스 개발 초기부터 개념을 잡고 갔어야 했지만 산더미 같은 업무와 중요도가 낮다고 생각하여 계속 미루고 있었다. 물론 핑계다. 시간이 없는 건 안핑계. 각설하고 구글링을 통해 어떻게 해야 할지 자료 조사를 했고 이미 다른 회사 블로그에서 많은 포스트를 발견할 수 있었다. 감사합니다.
우선 개요는 다음과 같다. 기존에 퍼블릭 접근 권한으로 오픈되어있었던 S3버킷을 외부에서 접근할 수 없게 닫아버린다. S3에는 CloudFront만 접근이 가능하게 해준다. 참고로 S3와 CloudFront가 뭔지 안다는 전제 하에 글을 작성하도록 하겠다.
흐름은 이해했을 거라 믿고 블로그의 제목처럼 "Make it work"하자.
1. S3 퍼블릭 엑세스 차단
너무 쉽다 설명할 것이 없다. 버킷을 선택하고 권한에 가서 모든 퍼블릭 엑세스 차단을 누르고 모든 침입자들을 막아버리자. 이후 오브젝트에 직접 접근하면 다음과 같은 화면을 만날 것이다.
HostId와 RequestId는 뭔지 모르겠는데 그냥 찝찝해서 지웠다. (다 보이는 거 같다)
2. CloudFront 설정
Distributions가 하나도 없다고 가정하고 진행해보자. Create Distribution을 누른다.
우리는 Web서비스를 하니까 Web항목에서 Get started를 누른다.
그럼 다음과 같이 설정화면이 나온다.
일단 CloudFront에 연결하고 싶은(배포하고 싶은) 버킷을 선택한다. 그러면 Origin ID가 자동으로 박힌다.
다음설정이 중요한데 Restrict Bucket Access 부분이다. 말 그대로 버킷 엑세스를 제한할 것인지 선택하는 부분이다. Yes를 선택하면 추가 설정이 아래 나오는데 Origin Access Identity를 만들건지 기존것을 사용할 건지 물어본다. 처음하니까 그냥 만들자. Grant Read Permissions on Bucket 설정은 Yes로 하자. 아까 S3버킷 설정을 어떤 접근도 못하게 했는데 이 설정을 통해서 우리가 선택한 버킷에게 현재 설정 중인 CloudFront Distribution이 접근할 수 있게 권한을 주는 것이다. 여기서 S3 버킷 설정을 대신 해준다고 생각하면 된다. CloudFront도 하나의 손님(객체)이기 때문에 Identity를 만들어주는 것이고 그 Identity에 접근할 수 있는 권한을 주는 것이다. 사람이 직접 접근하는가 AWS내의 서비스가 접근하는 가 차이뿐이지 S3 입장에서는 같은 손님이다.
이제 서명된 URL(Signed URL)을 만들기 위해 AWS ROOT 계정으로 CloudFront용 키페어를 만들어야 하는데 내가 생각했던 귀차니즘 보다 더 귀찮아져서 다음 글로 이어 작성하도록 한다. 아직 Create Distribution에 머물고 있으니 설정을 마무리하지 말고 다음 글을 기다려주세요. 감사합니다.
반응형'AWS' 카테고리의 다른 글
S3와 CloudFront를 이용한 객체 보안 (2) (3) 2020.02.11