Amazon Web Services 한국 블로그

Amazon S3 업데이트 – SigV2 사용 중지 기간 연장 및 수정 계획

Amazon S3 API 모든 요청은 진짜임을 보장할 수 있도록 암호화 서명을 추가하도록 되어 있습니다. AWS 초기에는 SigV2(서명 버전 2)라는 서명 모델이 사용되었습니다. 그리고 AWS는 2012년에 보다 유연한 서명 방식인 SigV4를 발표하여 이를 2013년 이후 출시되는 모든 리전에서 사용되는 유일한 서명 방식으로 지정하였습니다. 당시에 AWS에서는 모든 신규 S3 애플리케이션에 이 모델을 사용할 것을 권장해 드렸습니다.

작년에 AWS에서는 SigV2에 대한 지원이 이번 달 말에 종료될 것이라고 발표했습니다. 많은 고객이 SigV4를 사용하도록 애플리케이션을 업데이트했으며, 이러한 작업은 때로는 간단한 SDK 업데이트만으로 완료되었습니다. 그러나, 한편으로 지원을 연장해 달라는 요청도 많이 있었습니다.

새로운 날짜, 새로운 계획

기존 계획에 대한 고객들의 지속적인 피드백에 대한 응답으로 AWS에서는 계획을 다음과 같이 변경하게 되었습니다. 변경 사항은 다음과 같이 요약됩니다.

  • 기존 계획 – SigV2 지원을 2019년 6월 24일부로 종료합니다.
  • 수정된 계획 – 2020년 6월 24일 이후 생성된 모든 신규 버킷은 SigV2로 서명된 요청을 지원하지 않지만 기존 버킷은 계속 SigV2를 지원합니다. 그 동안 AWS는 고객이 이 기존 요청 서명 방식에서 새 방식으로 이전할 수 있도록 계속 고객과 협력할 것입니다.

기본 버킷 및 SigV2를 지원하는 AWS 리전의 하위 지역에서 SigV2를 계속 사용할 수 있지만, 중요한 보안 및 효율 관련 이점을 제공하는 SigV4로 이전할 것을 권장합니다. 새 서명 방식은 장기 AWS 액세스 키에서 파생된 별도의 특수 서명 키를 사용합니다. 이 키는 서비스, 리전 및 날짜에 고유합니다. 이 방식은 서비스와 리전 간에 추가적인 격리를 제공하며 키의 반복 사용에 대한 향상된 보호를 제공합니다. 내부적으로, AWS의 SigV4 구현은 인증 확인 결과를 안전하게 캐싱할 수 있게 해 주므로 지연 시간을 단축하고 애플리케이션의 전반적인 탄력성을 향상해 줍니다. 자세한 내용은 서명 버전 4의 변경 사항을 참조하십시오.

SigV2 사용 식별

Amazon S3는 2006년부터 제공되어 왔으며 과거와 현재의 고객이 오래 전에 작성했던 코드가 아직도 사용되면서 SigV2로 서명된 요청을 제출하고 있을 수 있습니다. CloudTrail 데이터 이벤트 또는 S3 서버 액세스 로그를 사용하면 오래 전에 작성된 요청을 찾고 업데이트가 필요한 애플리케이션을 식별할 수 있습니다.

CloudTrail 데이터 이벤트 – 각 CloudTrail 이벤트 입력 항목의 additionalDataElement에서 SignatureVersion 요소를 찾습니다(자세한 내용은 AWS CloudTrail를 사용하여 Amazon S3 서명 버전 2 요청 식별 참조).

S3 서버 액세스 로그 – 로그의 SignatureVersion 요소를 찾습니다(자세한 내용은 Amazon S3 액세스 로그를 사용하여 서명 버전 2 요청 식별 참조).

SigV4로 업데이트


“코드를 변경해야 하나요?”

유럽(프랑크푸르트), 미국 동부(오하이오), 캐나다(중부), 유럽(런던), 아시아 태평양(서울), 아시아 태평양(뭄바이), 유럽(파리), 중국(닝샤), 유럽(스톡홀름), 아시아 태평양(오사카 로컬), AWS GovCloud(US-East) 및 아시아 태평양(홍콩) 리젼은 2013년 후에 출시되었으며 SigV4는 지원하지만 SigV2는 지원하지 않습니다.

해당 리전에서 S3 버킷에 액세스하는 코드가 있는 경우, 이러한 코드는 이미 SigV4를 독점적으로 사용하고 있습니다.

최신 버전의 AWS SDK를 사용 중인 경우, 2020년 6월 24일부터 시행되는 새 버킷에 대한 SigV4 요구 사항을 이미 충족하고 있거나 충족할 준비가 된 상태입니다. 이전 버전의 SDK를 사용 중인 경우, 서명 버전 2에서 서명 버전 4로 전환에서 세부적인 버전 목록을 확인하십시오.

일부 경우에는 코드에 대해 몇 가지 변경을 수행해야 할 수 있습니다. 예를 들어, AWS Java, JavaScript (node.js) 또는 Python SDK에 미리 서명된 URL을 사용하는 경우 클라이언트 구성에서 올바른 리전 및 서명 버전을 설정해야 합니다. 또한, SigV4로 미리 서명된 URL은 최대 7일까지 유효한 반면, SigV2로 미리 서명된 URL은 수 주에서 수년에 이르는 최대 만료 시간을 가지도록 생성될 수 있습니다(거의 모든 경우, 시간이 제한된 URL을 사용하는 것이 더 모범적인 사례임). SigV4를 사용하면 보안 프로필이 향상되지만 미리 서명된 URL을 생성, 저장 및 사용하는 방식을 변경해야 할 수도 있습니다. 오랫동안 애용했던 미리 서명된 URL을 사용하는 것이 개발자 입장에서 쉽고 편리할 수 있지만, SigV4로 서명되고 한정된 만료 시간을 가진 URL을 사용하는 것이 훨씬 더 모범적인 보안 사례입니다.

Amazon EMR을 사용하는 경우, S3에 대한 모든 요청이 SigV4를 사용하도록 클러스터를 버전 5.22.0 이상으로 업그레이드해야 합니다(자세한 내용은 Amazon EMR 5.x 릴리스 버전 참조).

S3 객체가 Amazon CloudFront를 통해 제공되며 사용자가 자신의 요청을 직접 서명하는 경우, 코드가 SigV4를 사용하는지 확인하십시오. 원본 액세스 ID를 사용하여 S3에 대한 액세스를 제한하는 경우, x-amz-content-sha256 헤더 및 올바른 리전별 S3 도메인 엔드포인트를 포함했는지 확인하십시오.

언제든지 문의하십시오
AWS 팀은 귀하의 SigV4로의 전환이 원활하고 문제 없이 진행될 수 있도록 도와드리고자 합니다. 문제가 발생한 경우, AWS Support 시작하기에 설명된 대로 AWS Support를 적극 활용하시기 바랍니다.

Reddit에서 이 게시물에 대한 토론에 참여하실 수도 있습니다!

Jeff;