보안사고 방지를 위한 S3 권한 점검 수칙
여기서 다루는 내용
· S3 객체 노출 사고 사례
· S3 권한을 제어하는 방식
· S3 권한 점검 포인트
S3 권한을 주의깊게 살펴봐야 하는 이유
안녕하십니까, GS네오텍 최준승입니다.
오늘은 S3와 관련된 얘기를 하려고 합니다. S3는 AWS 유저라면 반드시 사용하게 되는 가장 기본적인 서비스라고 할 수 있는데요.
일반적으로 용도와 관리주체에 따라 단위 바구니인 버킷(Bucket)을 만든 후, 각 버킷에 객체(Object)를 입/출력하여 사용합니다.
저장되는 객체의 유형은 무엇이든 좋습니다.
어플리케이션에서 사용하는 데이터가 될 수도 있고, 로그도 좋고, 아님 바이너리 파일이 될 수도 있구요.
이 S3에 저장된 객체 데이터가 제한된 사용자가 아닌 일반 익명 사용자에게 Public하게 공개되는 사례가
최근 몇년간 빈번하게 발생하고 있습니다.
아이뉴스24: 잘못된 AWS 보안설정, 개인정보 유출 ‘빌미’
대부분의 사례는 버킷 단위로 Public하게 객체 권한을 열어준 것에서 기인하는데요.
작년에는 AWS에서 별도 메일을 통해, 모든 AWS 사용자를 대상으로 주의 공지를 발송하기도 했습니다.
그렇다면 이것은 누구의 책임일까요?
AWS에서 정의하는 공동 책임 모델에 따르면, 권한을 설정하고 관리하는 부분은 사용자의 책임 영역입니다.
상식적으로도 생각해봐도 집주인이 출입문에 몇겹의 자물쇠를 쓰라고 만들어 놨는데
세입자가 자물쇠는 어디다 치워 놓고 문을 활짝 열어놔서 도둑이 들었다면 그건 세입자의 관리 책임이겠죠.
오늘 포스팅에서는 리소스 기반의 S3 권한 제어 방식을 간략하게 확인한 후
현재 S3 권한 설정에 문제 요소가 없는지 점검하는 쉬운 방법 몇가지를 이어 살펴보도록 하겠습니다.
S3 권한을 제어하는 방식
S3의 권한 제어 방식을 살펴보기 위해 AWS Management Console에 접속해 Permissions 탭을 한번 보겠습니다.
ACL(Access Control List)와 Bucket Policy라는 것이 있네요. (CORS configuration은 약간 다른 성격이라 제외함)
첫번째, S3 ACL은 Bucket 단위 또는 Object 단위로 권한을 부여하는 관리 체계입니다.
권한을 아주 단순화하여 READ, WRITE, READ_ACP, WRITE_ACP 4가지로 분류하여 권한을 부여하거나 하지 않을 수 있습니다.
사용이 간편하지만, 제어할 수 있는 영역이 제한적이라 사용을 권장하지 않는 방식입니다.
두번째, S3 Bucket Policy는 하나의 Bucket에 하나의 정책을 적용하는 Bucket 단위의 권한 관리 체계입니다.
문법이 다소 어렵지만, 어려운만큼 폭넓은 권한을 세밀하게 조정할 수 있는 장점이 있어 권장하는 방식입니다.
Managing Access Permissions to Your Amazon S3 Resources
자세한 동작 방식은 매우 난해한 영역이기 때문에 관심있는 분께서는 위 공식 링크를 확인하시고
일반적으로 리소스 기반의 S3 권한을 설정하는 방식은 S3 ACL과 S3 Bucket Policy 2가지가 있구나 정도만 알고 넘어가시면 됩니다.
다음으로는 이 2가지 설정 방식을 기준으로
내가 소유하고 있는 S3 中 누가 Public하게 공개 되어 있는지 점검하는 방법을 살펴봅시다.
S3 권한 점검 포인트
AWS에서는 S3의 권한을 제어할 수 있는 자물쇠를 제공하기도 하지만
자물쇠가 제대로 잠겨져 있는지 여부를 직관적으로 확인할 수 있는 수단 또한 친절하게 제공하고 있습니다
크게 2가지 방법이 있습니다. AWS 관리 콘솔에서 확인하는 방법과 Trusted Advisor를 활용하는 방법.
:: AWS Management Console 에서 확인하기
[AWS Management Console] > [S3]로 가면 소유하고 있는 모든 S3 버킷이 기본적으로 표시됩니다.
이 중 Public한 권한이 일부 포함된 버킷은 Access 항목에 노란색으로 “Public”이라고 큼지막하게 표시해 줍니다.
제가 가진 Bucket 중에서는 “jschoi.demo”라는 이름의 버킷이 Public하다고 표시되어 있네요.
그 버킷의 어느 부분이 Public 하다는거야? 를 알고 싶다면 해당 버킷을 클릭 후 [Permissions] 탭을 클릭해 봅시다.
첫번째는 S3 ACL이 Public하게 설정되어 있는 경우입니다.
위와 같이 Access Control List 네모박스에 “Public” 마크가 붙습니다.
해당 마크가 붙는 조건은 Public Access 항목에 Everyone을 대상으로 “List objects” 또는 “Write Objects” 항목을 체크한 경우입니다.
위 캡쳐의 경우 Public Access 항목에 Everyone 그룹을 대상으로 “List objects” 항목이 체크되어 있네요.
내가 의도한 설정이 아니라면 살포시 해당 체크를 해제해 주시면 됩니다.
두번째는 S3 Bucket Policy가 Public하게 설정된 경우입니다.
위와 같이 Bucket Policy 네모박스에 노란 “Public” 마크가 붙습니다.
해당 마크를 표시하는지 여부를 결정하는 판단 로직은 정확하게 파악되지 않았는데요.
제 테스트 결과가 들쭉날쭉 한것으로 보아, 실제 자신이 의도한 권한이 맞는지 개별적으로 확인하는 절차가 꼭 필요해 보입니다.
“Resource” 항목에 일부 Prefix를 추가한 경우 ex) “arn:aws:s3:::jschoi.demo/prefix*” ▶ Public하다고 표시
“Condition” 항목에 IP조건과 같은 조건을 추가한 경우 ▶ Public하다고 미표시
암튼 S3 ACL이 Public하거나 S3 Bucket Policy가 Public하거나 둘 중 하나 이상의 조건이 만족되면
S3 콘솔의 해당 버킷에 “Public”하다는 표시를 띄워주는 방식입니다.
:: Trusted Advisor에서 확인하기
[AWS Management Console] > [Trusted Advisor] > [Security] 탭으로 가봅시다.
만약 내가 가지고 있는 S3 버킷 중 권한 이슈가 있는 버킷이 있을 경우 “Amazon S3 Bucket Permissions” 항목이 생성됩니다.
해당 항목을 클릭하면, 위와 같이 어떤 버킷에 어떤 권한이 open access 상태인지를 표시해 줍니다.
※ 단, AWS 계정의 Support 등급에 따라 일부 등급은 Trusted Advisor 사용에 제약이 발생할 수 있음
물론 사용자가 의도적으로 Public하게 설정한 것일 수도 있으니, 이 항목이 표시된다고 무조건 잘못된 것은 아닙니다.
점검 포인트로 활용하라는 의미입니다.
마치며
만일 복수의 계정을 사용하고 있다면, 이런 확인 작업을 계정 단위로 반복해야 할 수도 있습니다.
물론 수동으로 스크립트를 짜거나 람다 함수를 만들어 Cloudwatch Event에 거는 방식으로 확인작업을 자동화할 수도 있겠지요.
AWS Config Rule에 “s3-bucket-public-write-prohibited” 항목과 “s3-bucket-public-read-prohibited” 항목도 최근에 추가되었으니
관심있는 분들은 관련 항목을 참고하시구요.
오늘은 이정도로 마치도록 하겠습니다.
S3 권한과 관련된 부분은 기회가 되면 좀 더 자세하게 다루도록 하지요.
그럼 끝!
최신 댓글