[AWS] S3 bucket 보안에 관하여 -[1]

 

AWS S3 bucket 객체의 권한을 다 풀어헤치는 것은 꺼려진다는 우리 구독자님의 의견이 있어서 ACL 권한설정에 대해 공부하던 중 굳이 ACL은 필요없다는 것을 알았다.

 

AWS측의 공식 답변이다.

 

즉  ACL은 필요하지않고 S3 버킷 정책을 사용하여 원하는 권한을 부여하라는 것이 AWS 측의 답변이다.

 

근데 문득 든 생각이 보안이 정말 중요하다는 것은 알겠지만 무엇때문에, 그니까 무슨 위험때문인지는 모르고 있단 생각이 들었다. 너무 막연하게 형체도 보이지 않는 괴물과 싸우는 것은 어렵지 않겠는가?

하여 대체 어떤 위험이 숨어있는지 그 그림자부터 걷어내보도록 하자.

 

단순히 개인의 프로젝트에 쓰는 사람들은 대부분 그냥 다 풀어헤치고 쓰는데 이러면 최소한 S3의 AccessKey는 무슨 일이 있어도 세상에 공개하지마라.

 

자 시작해보자.

 

S3는 사용자들이 너무나 쉽게 사용할 수 있게 되어있다. 이 지점에서 문제가 생기는데 용법은 쉬운데 권한 설정은 너무 복잡하다. 보안을 설정하니 다 막혀버리게 되고 이를 해결하자니 너무 어렵고.

 

보안이란게 언제나 철저한 것만이 중요한게 아니라 사용자의 편의성과 적절한 무게중심의 이동이 필요하다.

 

S3 버킷을 다방면하게 이용할 수 있지만

 

우리는 일단 정적 리소스 파일 서빙용과 원격 파일 저장용으로 사용하는 두 가지만 알아보자.

 

정적 리소스 파일인 js,jpg,png,css 등등을 서빙하기 위한 저장소로 bucket을 사용하는 경우 서빙용 파일을 업로드하여 퍼블릭 공개 설정을 하고 GetObject를 모두에게 액세스 허용시키는데

 

이때 AWS의 엔드포인트 URL과 함께

 

우리의 버킷명까지 이미지 주소로 사용되는데 심지어 매우 퍼블릭하게 열려있다는 점이다.

 

당신의 집주소를 그대로 알려준 상태가 되는 것이다.

 

만약 여기서 당신의 AccessKey까지 알려준다면 집주소도 부족해서 도어락 비밀번호까지 알려주게 되는 것이다.

 

자 이제 우리의 괴물이 형체를 드러냈다. 뭐 당연한 소리 아닌가 생각들 수 있겠지만 문제를 명확하게 바라본다면 해결책이 떠오르는법이다.

이제 이 주소를 바꿔주고 버킷권한을 설정해준다면 이 괴물은 더이상 우리의 위협이 되지 못하고 귀여워질 것이다.

 

다음시간은 우리의 주소를 바꾸고 버킷권한을 설정하는 시간이다.

 

 

Thanks for watching, Have a nice day.