미리 서명된 URL 개요

미리 서명된 URL은 AWS Identity and Access Management (IAM) 서비스에서 인식하는 일종의 HTTP 요청입니다. 이 유형의 AWS 요청을 다른 모든 요청과 차별화하는 것은 X-Amz-Expires 쿼리 파라미터입니다. 다른 인증된 요청과 마찬가지로 미리 서명된 URL 요청에는 서명이 포함됩니다. 미리 서명된 URL 요청의 경우 이 서명이 전송됩니다. X-Amz-Signature 서명은 서명 버전 4 암호화 작업을 사용하여 다른 모든 요청 파라미터를 인코딩합니다.

참고

• 서명 버전 2는 현재 지원 중단될 예정이지만 일부 버전에서는 여전히 지원됩니다. AWS 리전이 가이드는 서명 버전 4 서명에 적용됩니다.

• 수신 서비스에서 서명되지 않은 헤더를 처리할 수 있지만, 모범 사례에 따라 해당 옵션에 대한 지원은 제한적이며 타겟팅되어 있습니다. 달리 명시되지 않는 한, 요청을 수락하려면 모든 헤더에 서명해야 한다고 가정해 보십시오.

이 X-Amz-Expires 매개 변수를 사용하면 인코딩된 날짜 시간과의 편차가 큰 서명을 유효한 것으로 처리할 수 있습니다. 서명 유효성의 다른 측면은 여전히 평가되고 있습니다. 서명 자격 증명이 일시적인 경우 서명이 처리되는 시점에 만료되어서는 안 됩니다. 서명 자격 증명은 처리 당시 충분한 승인을 받은 IAM 보안 주체에게 첨부해야 합니다.

사전 서명된 URL은 사전 서명된 요청의 하위 집합입니다.

미리 서명된 URL이 향후 요청에 서명하는 유일한 방법은 아닙니다. Amazon S3는 일반적으로 미리 서명되는 POST 요청도 지원합니다. 미리 서명된 POST 서명을 사용하면 서명된 정책을 준수하고 해당 정책에 만료 날짜가 포함되어 있는 업로드가 허용됩니다.

요청에 대한 서명은 흔하지 않지만 미래 날짜일 수도 있습니다. 기본 자격 증명이 유효하기만 하면 서명 알고리즘이 미래의 데이트를 금지하지 않습니다. 그러나 이러한 요청은 유효 기간 전까지는 성공적으로 처리될 수 없으므로 대부분의 사용 사례에서 미래 데이트는 실용적이지 않습니다.

사전 서명된 요청은 무엇을 허용하나요?

미리 서명된 요청은 요청에 서명하는 데 사용된 자격 증명으로 허용된 작업만 허용할 수 있습니다. 자격 증명이 미리 서명된 요청에 지정된 작업을 암시적 또는 명시적으로 거부하는 경우, 미리 서명된 요청은 전송 시 거부됩니다. 이는 다음과 같은 경우에 적용됩니다.

• 자격 증명과 관련된 세션 정책

• 자격 증명에 연결된 보안 주체와 관련된 정책

• 세션 또는 주도자에 영향을 미치는 리소스 정책

• 세션 또는 주도자에 영향을 미치는 서비스 제어 정책

미리 서명된 요청을 사용하는 동기

보안 엔지니어라면 솔루션 빌더가 미리 서명된 URL을 사용하는 동기가 무엇인지 알고 있어야 합니다. 무엇이 필요하고 무엇이 선택적인지 이해하면 솔루션 빌더와 소통하는 데 도움이 됩니다. 동기에는 다음이 포함될 수 있습니다.

• Amazon S3의 확장성을 활용하면서 비 IAM 인증 메커니즘을 지원합니다. 핵심 동기는 Amazon S3와 직접 통신하여 이 서비스가 제공하는 내장된 확장성을 활용하는 것입니다. 이러한 직접 통신이 없다면 솔루션은 전송된 바이트와 호출의 재전송으로 인한 부하를 지원해야 합니다. PutObjectGetObject 이 요구 사항은 총 부하량에 따라 솔루션 빌더가 피하고 싶어하는 확장 문제를 가중시킵니다.

  AWS Security Token Service (AWS STS) 에서 임시 자격 증명을 사용하거나 URL 외부의 서명 버전 4 서명을 사용하는 등 Amazon S3와 직접 통신하는 다른 방법은 사용 사례에 적합하지 않을 수 있습니다. Amazon S3는 AWS 자격 증명을 통해 사용자를 식별하는 반면, 사전 서명된 요청은 자격 증명 이외의 메커니즘을 통한 식별을 가정합니다. AWS 사전 서명된 요청을 통해 데이터에 대한 직접 통신을 유지하면서 이러한 차이를 해소할 수 있습니다.

• URL에 대한 브라우저의 기본 이해를 활용하기 위함입니다. URL은 브라우저에서 인식되지만 AWS STS 자격 증명과 서명 버전 4 서명은 인식하지 못합니다. 이는 브라우저 기반 솔루션과 통합할 때 유용합니다. 대체 솔루션은 더 많은 코드가 필요하고 대용량 파일에 더 많은 메모리를 사용하며 멀웨어 및 바이러스 스캐너와 같은 확장 프로그램에 따라 다르게 처리될 수 있습니다.

임시 AWS STS 자격 증명과의 비교

임시 자격 증명은 미리 서명된 요청과 비슷합니다. 둘 다 만료되며 액세스 범위를 지정할 수 있으며 일반적으로 비 IAM 자격 증명을 AWS 자격 증명이 필요한 사용과 연결하는 데 사용됩니다. 

임시 AWS STS 자격 증명의 범위를 단일 S3 객체 및 작업으로 한정할 수 있지만, API에는 제한이 있기 때문에 확장에 문제가 발생할 수 있습니다. AWS STS (자세한 내용은 IAM 및 AWS STS AWS re:Post 웹 사이트의 API 제한 또는 “속도 초과” 오류를 해결하는 방법 문서를 참조하십시오.) 또한 생성된 각 자격 증명에는 AWS STS API 호출이 필요하므로 지연 시간과 복원력에 영향을 미칠 수 있는 새로운 종속성이 추가됩니다. 또한 임시 AWS STS 자격 증명의 최소 만료 시간은 15분이지만 사전 서명된 요청은 더 짧은 기간을 지원할 수 있습니다. (적절한 조건에서는 60초가 실용적입니다.)

서명 전용 솔루션과의 비교

사전 서명된 요청의 고유한 비밀 구성 요소는 서명 버전 4 서명뿐입니다. 클라이언트가 요청의 다른 세부 정보를 알고 있고 해당 세부 정보와 일치하는 유효한 서명을 제공받으면 유효한 요청을 보낼 수 있습니다. 유효한 서명이 없으면 할 수 없습니다.

미리 서명된 URL과 서명 전용 솔루션은 암호학적으로 유사합니다. 그러나 서명 전용 솔루션은 쿼리 문자열 파라미터 대신 HTTP 헤더를 사용하여 서명을 전송할 수 있는 기능과 같은 실용적인 이점이 있습니다 (로깅 상호 작용 및 완화 섹션 참조). 또한 관리자는 쿼리 문자열이 메타데이터로 취급되는 경우가 더 많지만 헤더는 메타데이터로 취급되는 경우가 적다는 점도 고려해야 합니다.

반면 AWS SDK는 서명을 직접 생성하고 사용하는 데 대한 지원이 적습니다. 서명 전용 솔루션을 구축하려면 더 많은 사용자 지정 코드가 필요합니다. 실용적인 관점에서 보안을 위해 사용자 지정 코드 대신 라이브러리를 사용하는 것이 일반적인 모범 사례이므로 서명 전용 솔루션용 코드에는 추가 조사가 필요합니다.

서명 전용 솔루션은 X-Amz-Expires 쿼리 문자열을 사용하지 않으며 명시적인 유효 기간을 제공하지 않습니다. IAM은 명시적 만료 시간이 없는 서명의 암시적 유효 기간을 관리합니다. 이러한 암시적 기간은 게시되지 않습니다. 일반적으로 변경되지는 않지만 보안을 염두에 두고 관리되므로 유효 기간에 의존해서는 안 됩니다. 만료 날짜를 명시적으로 제어하는 것과 IAM이 만료를 관리하도록 하는 것 사이에는 절충점이 있습니다.

관리자는 서명 전용 솔루션을 선호할 수 있습니다. 하지만 실제로는 구축된 솔루션을 그대로 지원해야 합니다.