기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
미리 서명된 URLs 개요
미리 서명된 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 보안 주체에 연결되어야 합니다.
미리 서명된 URLs 미리 서명된 요청의 하위 집합입니다.
미리 서명된 URL이 향후 요청에 서명하는 유일한 방법은 아닙니다. Amazon S3는 일반적으로 미리 서명된 POST 요청도 지원합니다. 미리 서명된 POST 서명은 서명된 정책을 준수하고 해당 정책에 포함된 만료 날짜가 있는 업로드를 허용합니다.
요청에 대한 서명은 미래 날짜일 수 있지만 흔하지 않습니다. 기본 자격 증명이 유효한 한 서명 알고리즘은 미래 날짜를 금지하지 않습니다. 그러나 이러한 요청은 유효한 타이밍 기간까지 성공적으로 처리되지 않으므로 대부분의 사용 사례에서 미래 날짜는 실용적이지 않습니다.
미리 서명된 요청은 무엇을 허용하나요?
미리 서명된 요청은 요청에 서명하는 데 사용된 자격 증명에서 허용하는 작업만 허용할 수 있습니다. 자격 증명이 미리 서명된 요청에 의해 지정된 작업을 암시적으로 또는 명시적으로 거부하는 경우 미리 서명된 요청은 전송될 때 거부됩니다. 이는 다음에 적용됩니다.
-
자격 증명과 연결된 세션 정책
-
자격 증명과 연결된 보안 주체와 연결된 자격 증명 기반 정책
-
세션 또는 보안 주체에 영향을 미치는 리소스 정책
-
세션 또는 보안 주체에 영향을 미치는 서비스 제어 정책
-
세션 또는 보안 주체에 영향을 미치는 리소스 제어 정책
미리 서명된 요청 사용에 대한 동기 부여
보안 엔지니어는 솔루션 빌더가 미리 서명된 URLs을 사용하도록 동기를 부여하는 요인을 알고 있어야 합니다. 무엇이 필요하고 무엇이 선택 사항인지 이해하면 솔루션 빌더와 통신하는 데 도움이 됩니다. 동기 부여에는 다음이 포함될 수 있습니다.
-
Amazon S3의 확장성을 활용하면서 비 IAM 인증 메커니즘을 지원합니다. 핵심 동기는 Amazon S3와 직접 통신하여이 서비스에서 제공하는 기본 제공 확장성의 이점을 활용하는 것입니다. 이러한 직접 통신이 없으면 솔루션은 PutObject 및 GetObject 호출로 전송되는 재전송 바이트의 로드를 지원해야 합니다. 총 부하에 따라이 요구 사항에는 솔루션 빌더가 피하고 싶을 수 있는 조정 문제가 추가됩니다.
URLs 외부에서 임시 자격 증명 AWS Security Token Service (AWS STS) 또는 서명 버전 4 서명을 사용하는 등 Amazon S3와 직접 통신하는 다른 방법은 사용 사례에 적합하지 않을 수 있습니다. Amazon S3는 자격 증명을 통해 AWS 사용자를 식별하는 반면, 미리 서명된 요청은 AWS 자격 증명 이외의 메커니즘을 통해 식별을 수임합니다. 미리 서명된 요청을 통해 데이터에 대한 직접 통신을 유지하면서 이러한 차이를 브리징할 수 있습니다.
-
브라우저의 URL에 대한 URLs. URLs은 브라우저에서 이해되지만 자격 AWS STS 증명 및 서명 버전 4 서명은 이해되지 않습니다. 이는 브라우저 기반 솔루션과 통합할 때 유용합니다. 대체 솔루션은 더 많은 코드가 필요하고, 대용량 파일에 더 많은 메모리를 사용하며, 맬웨어 및 바이러스 스캐너와 같은 확장명으로 다르게 취급될 수 있습니다.
임시 AWS STS 자격 증명과의 비교
임시 자격 증명은 미리 서명된 요청과 유사합니다. 둘 다 만료되고, 액세스 범위 조정을 허용하며, 일반적으로 비 IAM 자격 증명을 AWS 자격 증명이 필요한 사용과 연결하는 데 사용됩니다.
임시 AWS STS 자격 증명의 범위를 단일 S3 객체 및 작업으로 엄격하게 지정할 수 있지만 AWS STS APIs에는 제한이 있기 때문에 조정 문제가 발생할 수 있습니다. (자세한 내용은 IAM 및 AWS re:Post 웹 사이트의 API 제한을 해결하려면 어떻게 해야 합니까? 또는 "Rate exceeded" 오류를 AWS STS
서명 전용 솔루션과의 비교
미리 서명된 요청의 유일한 고유 비밀 구성 요소는 서명 버전 4 서명입니다. 클라이언트가 요청의 다른 세부 정보를 알고 있고 해당 세부 정보와 일치하는 유효한 서명이 제공된 경우 유효한 요청을 보낼 수 있습니다. 유효한 서명이 없으면 할 수 없습니다.
미리 서명된 URLs과 서명 전용 솔루션은 암호화 방식으로 유사합니다. 그러나 서명 전용 솔루션은 쿼리 문자열 파라미터 대신 HTTP 헤더를 사용하여 서명을 전송하는 기능(로깅 상호 작용 및 완화 섹션 참조)과 같은 실질적인 이점이 있습니다. 또한 관리자는 쿼리 문자열이 메타데이터로 더 일반적으로 처리되는 반면 헤더는 덜 일반적으로 처리된다는 점을 고려해야 합니다.
반면, AWS SDKs 서명을 직접 생성하고 사용하는 데 대한 지원을 덜 제공합니다. 서명 전용 솔루션을 구축하려면 더 많은 사용자 지정 코드가 필요합니다. 실제 관점에서 보안을 위해 사용자 지정 코드 대신 라이브러리를 사용하는 것이 일반적인 모범 사례이므로 서명 전용 솔루션의 코드에는 추가 조사가 필요합니다.
서명 전용 솔루션은 X-Amz-Expires 쿼리 문자열을 사용하지 않으며 명시적인 유효 기간을 제공하지 않습니다. IAM은 명시적 만료 시간이 없는 서명의 암시적 유효 기간을 관리합니다. 이러한 암시적 기간은 게시되지 않습니다. 일반적으로 변경되지는 않지만 보안을 염두에 두고 관리되므로 유효 기간에 종속되어서는 안 됩니다. 만료 날짜를 명시적으로 제어하는 것과 IAM이 만료를 관리하는 것 사이에는 장단점이 있습니다.
관리자는 서명 전용 솔루션을 선호할 수 있습니다. 그러나 실제적으로는 구축된 대로 솔루션을 지원해야 합니다.
