이번에 S3 키가 의도치 않게 github에 공개되면서
보안에 정말 신경써야 한다는 점을 배우게 됐다.
다행이도 AWS에서 키가 공개되자마자 메일을 보내고 키를 비활성화해주었다.
이상하게 commit에 application.properties 정보가 들어가있었고
파일은 github에 올라가있지 않았다. 어떤 캐시같은 게 남아있던 것으로 보인다.
S3를 안전하게 설정하자
그전엔 S3보안에 대해서 딱히 크게 신경을 쓰지 않았다.
그런데, 이번에 Plaything 오프라인 모임을 하면서 전반적인 보안에 대해서도 신경을 쓰면 좋겠다는 이야기가 나왔다.
배민 기술블로그에 있는 글을 참고해보자.
지금 우리는 웹페이지를 s3에 올려서 서빙하는 게 아니라
jpg나 png같은 프로필 사진을 s3에 올려놓고 사용하고 있다.
여기서는 CloudFront를 통해서 이미지를 전송하는 것을 권하고 있다.
s3에서 퍼블릭 액세스를 허용하면 url을 통해서 이미지를 전달하는 방식을 쓰게 되는데, 이러면 s3의 엔드포인트가 노출된다는 문제가 발생한다.
S3 엔드포인트 주소는 버킷명을 포함하고 있어, 권한을 갖지 않은 유저가 버킷 내 다른 Object에도 접근할 수 있는 위험성이 존재한다.
aws에서도 퍼블릭 액세스를 막으라고 조언한다.
s3에서 url에 나오는 파일명을 난수로 하면 이런 문제들을 해결할 수 있지 않을까 싶지만... 그래도 사람의 실수가 존재할 수 있다면 이는 조심하는 게 좋지 않을까?
이 글을 보면
실제 첨부파일을 S3에 올릴 때 파일명(Object Key)을 난수로 생성하여 업로드하기 때문에 파일 경로를 유추하기 매우 어렵지만 Brutal Force Attack의 위험에는 충분히 노출돼있었다. 그리고 한 번 노출된 URL은 누군가가 외부로 유출한다면 모든 사람들이 접근할 수 있기 때문에 보안 평가에서 지적사항으로 나온 것이다.
여전히 위험성이 있는 것으로 보인다.
CloudFront를 통해서 캐싱도 가능하다고 하니 사용해볼 법 하다.
추가로 s3는 http만 지원하지만, cloudfront는 https를 지원한다.
OAI란?
OAI(Origin Access Identity)란 Origin 즉 S3에 접근할때 사용할 식별자입니다. 이 식별자만을 통한 S3의 접근을 허용할 수 있다.
설정하기
퍼블릭 액세스를 차단한다.
cloudFront에서 원본 액세스 제어를 설정하고 OAC를 생성해준다.
cloudFront를 생성하고 다시 들어가면 정책 복사 버튼이 있다. 그걸 누르고 s3 버킷 정책에 넣어주면 된다.
이제 s3 엔드포인트로 접속하면 위처럼 접근 권한이 없다고 뜬다.
cloudfront 도메인으로 접속하면 위 사진이 바로 뜬다.
cloudfront의 또 다른 이점은 캐싱을 통한 성능 향상이다.
권한 설정
이렇게 정책도 fullaccess로 하지말고 위처럼 제한적인 내용만 iam 사용자에게 허락해주었다.
그런데, 이렇게 하니까 cors 설정도 직접 해주어야 했다.
스프링에서 사진을 업로드해보니 문제가 있었다.
s3 엔드포인트로도 사진이 조회가 된다는 것이다.
이 부분이 문제였다.
private 설정으로 바꿔주었다.
s3엔드포인트로는 접근이 안된다.
cloudfront 도메인 주소로 접근해야 조회가 된다.
