[주의] S3 API의 Signature 2 버전 폐지 및 Path Style 경로 제한 안내
여기서 다루는 내용
· 시작
· Signature V2 폐지건 안내
· Path Style 경로 제한건 안내
· 마치며
도입
안녕하십니까. GS네오텍 최준승입니다.
오늘은 S3 관련 2가지 중요 업데이트 소식을 전해드리려고 합니다.
관련 내용은 블로그에도 있고 AWS 포럼에도 있고 여러곳에 있지만. 포럼 기준의 링크는 다음과 같습니다.
AWS Signature Version 4 to replace AWS Signature Version 2 for signing S3 API requests
Amazon S3 will no longer support path-style API requests starting September 30th, 2020
두가지 모두 S3와 관련된 무엇인가가 deprecated(폐지)된다는 내용인데요.
그럼 대체 무엇이. 언제부터 폐지되고. 어떻게 대비해야 하는지. 핵심 위주로 짧게 살펴보도록 하겠습니다.
AWS Signature Version 4 to replace AWS Signature Version 2 for signing S3 API requests
편의상 요약을 먼저 하고 설명을 뒤에 하겠습니다.
- 대상: S3 API 요청시 Signature Version 2 사용 불가
- 시점: 2019/06/24 ~
- 영향: 해당 시점 이후 Signature Version 2 방식으로 API 요청시 Error
- 대책: SigV2 사용 여부 추적, 있다면 SDK 업데이트 / 코드 수정하여 SigV4 방식으로 변경
※ 변경 사항 공지 (19/06/14)
위 내용의 적용 시점과 기준이 변경되었으니 참고 바랍니다
- 기존: 모든 S3 버킷을 기준으로 19/06/24 부터 일괄 적용
- 변경: 20/06/24 이후에 생성되는 S3 버킷으로 한정하여 적용
- 참고 링크
※ AWS 리전별 엔드포인트의 S3 항목에 가면 리전별로 사용하는 Signature Version이 기재되어 있다
여기서 말하는 Signature Version이란 S3 API 요청을 인증할때 사용하는 일종의 표준 프로세스입니다. 위의 캡쳐를 보시면 Virginia의 경우 Version 2와 4를 지원하고, Ohio는 Version 4만 지원하는 것을 알 수 있죠. 일반적으로 2014년 1월 이전에 런칭된 Region의 경우에는 Version 2와 4를 지원하고, 이후에 런칭된 Region의 경우에는 Version 4만 지원합니다. 따라서 2014년 이후에 런칭된 서울 리전은 Version 4만 지원하는 반면, 이전에 런칭된 도쿄 리전은 Version 2와 4를 지원하죠. 이말인 즉슨 (도쿄 리전같이) 두가지 서명 버전을 지원하는 리전에서 S3 API를 여러분이 사용중이라면. `19년 6월 이전에 무언가 한번 체크를 하고 넘어가셔야 한다는 말입니다.
대책은 단순합니다. Signature Version 2 방식으로 인증하고 있는 로직이 있는지 점검하시면 됩니다.
우선 AWS에서는 아래 SDK 버전 중 일부에 대해 업그레이드를 권고하고 있습니다.
- AWS SDK for Java v1 ▷ Java 1.11.x or v2 in 2018.4Q로 업그레이드
- AWS SDK for Java v2 (preview) ▷ 업그레이드 불필요
- AWS SDK for .NET v1 ▷ 3.1.10 이상으로 업그레이드
- AWS SDK for .NET v2 ▷ 3.1.10 이상으로 업그레이드
- AWS SDK for .NET v3 ▷ 업그레이드 불필요
- AWS SDK for JavaScript v1 ▷ 2.68.0 이상으로 업그레이드
- AWS SDK for JavaScript v2 ▷ 2.68.0 이상으로 업그레이드
- AWS SDK for JavaScript v3 ▷ 업그레이드 불필요, 차후 V3 in 2019.3Q으로 업그레이드 권장
- AWS SDK for PHP v1 ▷ v2.7.3 이상 버전으로 업그레이드 권장
- AWS SDK for PHP v2 ▷ v2.7.3 이상 버전으로 업그레이드 권장
- AWS SDK for PHP v3 ▷ 업그레이드 불필요
- Boto2 ▷ Boto2 v2.49.0로 업그레이드
- Boto3 ▷ 1.5.71 (Botocore), 1.4.6 (Boto3)로 업그레이드
- AWS CLI ▷ 1.11.108로 업그레이드
- AWS CLI v2 (preview) ▷ 업그레이드 불필요
- AWS SDK for Ruby v1 ▷ Ruby V3로 업그레이드
- AWS SDK for Ruby v2 ▷ Ruby V3로 업그레이드
- AWS SDK for Ruby v3 ▷ 업그레이드 불필요
- Go SDK ▷ 업그레이드 불필요
- C++ ▷ 업그레이드 불필요
SDK 업그레이드와 무관하게. 요청하는 클라이언트의 일부 코드 수정이 필요할 수 있습니다.
좀 더 자세한 내용은 AWS 공식 문서의 뒷부분을 참고하시기 바랍니다.
그렇다면 내가 지금 SigV2 방식의 요청을 사용하고 있는지는 어떻게 확인할 수 있을까요?
참고로 CloudTrail Log와 S3 Access Log에서 각 요청의 서명 버전이 SigV2 인지 SigV4인지 확인할 수 있는 로그 필드를 제공하고 있습니다. 제 사견으로는 S3 Access Log 데이터를 바탕으로 Athena로 SigV2를 사용한 요청이 있는지 쿼리하고, 다른 필드값 정보를 통해 어디에서 요청이 들어오는지 확인하면 좋을듯 한데. 이 부분은 따로 소개드릴 수 있는 기회가 생기면 공유드리도록 하겠습니다.
Amazon S3 will no longer support path-style API requests starting September 30th, 2020
마찬가지로 요약으로 시작합니다.
- 대상: Path 형식의 S3 주소값 사용 불가
- 시점: 2020/09/30 ~
- 영향: 해당 시점 이후에 생성하는 S3 Bucket에 대해 Path 형식의 S3 주소 사용불가
- 대책: 가상-호스트(Virtual-hosted) 기반의 S3 주소값을 사용하도록 권장
S3 Object를 지칭하는 주소값은 크게 2가지 형태가 있습니다. 만약 버킷명이 jschoi이고 키값이 image/baki.jpg라면
-
- https://s3-ap-northeast-2.amazonaws.com/jschoi/image/baki.jpg (Path style)
- https://jschoi.s3-ap-northeast-2.amazonaws.com/image/baki.jpg (Virtual-hosted style)
※ 물론 버지니아 리전의 경우 s3.amazonaws.com 형태의 주소도 사용하지만 여기서는 논외로 합니다
잘 보시면 호스트 부분에 버킷명이 포함되느냐(Virtual-hosted) 포함되지 않느냐(Path)에 따라 주소 형태가 달라지는데요. 이 중에서 리전별 공용 도메인을 사용하는 Path 형식의 S3 주소값을 2020년 9월 이후로 지원하지 않는다는 내용입니다. AWS 공식 블로그 내용에 따르면 S3 버킷별로 개별 도메인 주소값을 부여하는것이 관리 편의성 및 기능 적용, 장애 영향도 측면에서 몇몇 이점이 있다고 하네요. 단, 2020년 9월 30일 이전에 생성된 버킷의 경우에는 해당 시점 이후에도 Path 형식의 주소값을 계속 사용할 수 있습니다. 다시 말하면 오직 2020년 9월 30일 이후에 생성하는 S3 버킷만 Path 형식의 주소값을 사용할 수 없게 됩니다.
하지만 관성이라는것을 무시할 수 없으니. 아무래도 앞으로의 개발은 Virtual-hosted 방식의 주소값을 기준으로 만드는 것이 여러모로 좋을 것입니다. 이 방식의 경우 버킷명이 도메인 주소값에 포함되다 보니 대소문자 식별 등 몇가지 제약사항을 추가적으로 고려해야 합니다. 그렇게 되면 S3 버킷명을 정의하는 순간부터 사전-고려해야할 부분이 생길 수 있습니다.
그렇다면 이것도 마찬가지로 내가 지금 Path 방식의 요청을 처리하고 있는지는 어떻게 확인할 수 있을까요?
S3 Access Log의 Host Header 필드와 CloudTrail Data Event의 requestParameters – host 값을 참조할 수 있습니다. 이 부분도 별도 포스팅을 통해 다시 한번 방법론을 다루도록 하겠습니다.
마치며
어떻게 보면 참 계획적인 친구들입니다. 2019년 6월부터 적용되는 내용을 2018년 6월에 공지하고. 2020년 9월부터 적용되는 내용을 2019년 5월에 공지합니다. 아마 내부적으로 디펜던시가 있는 수많은 개발 아이템의 순서가 정해져 있을 것이고. 여기에 따라 사전 안내를 만들어 사용자에게 미리 배포하고. 이런 프로세스는 AWS가 참 잘한다고 느낄때가 많습니다. 반대로 사용자 입장에서는 이런 부분을 미리 알 수 있기 때문에. 사전에 내 어플리케이션을 점검하고 대비하고. 서비스에 영향이 가지 않도록 충분한 준비시간을 확보할 수 있게 됩니다.
제 생각에는 날짜상 일단 SigV2를 사용하는 S3 API 요청이 없는지 점검하는게 가장 우선일듯 합니다. 이 부분은 기회가 되면 다다음주 정도 데모글을 통해 추가 안내를 드릴 수 있도록 하겠습니다.
마칩니다. 끝!
최신 댓글