View a markdown version of this page

Authorization 헤더에 대한 서명 계산: 페이로드를 여러 청크로 전송(청크 업로드)(AWS 서명 버전 4) - Amazon Simple Storage Service
시드 서명 계산청크 본문 정의예제: PUT Object

Authorization 헤더에 대한 서명 계산: 페이로드를 여러 청크로 전송(청크 업로드)(AWS 서명 버전 4)

개요에 설명된 대로 Authorization 헤더를 사용하여 요청을 인증할 때 페이로드를 청크로 업로드할 수 있습니다. 데이터를 고정 크기 또는 가변 크기 청크로 전송할 수 있습니다. 이 섹션에서는 청크 업로드의 서명 계산 프로세스, 청크 본문을 생성하는 방법, 첫 번째 청크를 업로드하고 후속 청크에서 서명을 전송하는 지연된 서명이 작동하는 방식을 설명합니다. 예제 섹션(예제: PUT Object 참조)에는 코드를 확인하기 위한 테스트 스위트로 사용할 수 있는 서명 계산 및 결과 Authorization 헤더가 나와 있습니다.

참고

데이터를 일련의 청크로 전송할 때는 다음 중 하나를 수행해야 합니다.

  • Content-Length HTTP 헤더를 사용하여 총 콘텐츠 길이(바이트 단위의 객체 길이 및 각 청크의 메타데이터)를 명시적으로 지정합니다. 이렇게 하려면 요청을 시작하기 전에 각 청크에서 전송하는 메타데이터를 포함하여 페이로드의 총 길이를 미리 계산해야 합니다.

  • Transfer-Encoding HTTP 헤더를 지정합니다. Transfer-Encoding 헤더를 포함하고 identity 이외의 값을 지정하는 경우 Content-Length 헤더를 생략해야 합니다.

모든 요청에 대해 객체의 크기를 바이트 단위로 지정하여 x-amz-decoded-content-length 헤더를 포함해야 합니다.

각 청크 서명 계산에는 이전 청크의 서명이 포함됩니다. 시작하려면 헤더만 사용하여 시드 서명을 생성합니다. 첫 번째 청크의 서명 계산에는 시드 서명을 사용합니다. 이후의 각 청크에서는 이전 청크의 서명이 포함된 청크 서명을 생성합니다. 따라서 청크 서명은 서로 연결(체인화)됩니다. 즉, 청크 n의 서명은 F(청크 n, 서명(청크 n-1))이라는 함수입니다. 체인화를 사용하면 청크를 올바른 순서로 전송할 수 있습니다.

청크 업로드를 수행하려면 다음을 수행합니다.

  1. 페이로드 청크 크기를 결정합니다. 이 크기는 코드를 작성할 때 필요합니다.

    청크 크기는 8KB 이상이어야 합니다. 성능 향상을 위해 청크 크기를 최소 64KB로 설정하는 것이 좋습니다. 이 청크 크기는 마지막 청크를 제외한 모든 청크에 적용됩니다. 마지막으로 전송하는 청크는 8KB보다 작을 수 있습니다. 페이로드가 작고 하나의 청크에 들어갈 수 있는 경우 8KB보다 작을 수 있습니다.

  2. 첫 번째 청크에 포함할 시드 서명을 생성합니다. 자세한 내용은 시드 서명 계산 섹션을 참조하세요.

  3. 첫 번째 청크를 생성하고 스트리밍합니다. 자세한 내용은 청크 본문 정의 섹션을 참조하세요.

  4. 이후의 각 청크에 대해 서명할 문자열에 이전 서명을 포함하는 청크 서명을 계산하고 청크를 구성하여 전송합니다. 자세한 내용은 청크 본문 정의 섹션을 참조하세요.

  5. 구성의 다른 청크와 동일하지만 데이터 바이트가 0인 최종 추가 청크를 전송합니다. 자세한 내용은 청크 본문 정의 섹션을 참조하세요.

시드 서명 계산

다음 다이어그램은 시드 서명을 계산하는 프로세스를 보여줍니다.

시드 서명을 계산하는 프로세스입니다.

다음 표에서는 다이어그램에 표시된 함수를 설명합니다. 이러한 함수의 코드를 구현해야 합니다.

함수 설명
Lowercase() 문자열을 소문자로 변환합니다.
Hex() 소문자 16진법 인코딩.
SHA256Hash() 보안 해시 알고리즘(SHA) 암호화 해시 함수.
HMAC-SHA256() 제공된 서명 키를 포함한 SHA256 알고리즘을 사용하여 HMAC를 계산합니다. 이것이 최종 서명입니다.
Trim() 선행 또는 후행 공백을 모두 제거합니다.
UriEncode()

URI는 모든 바이트를 인코딩합니다. UriEncode()는 다음 규칙을 적용해야 합니다.

  • URI는 예약되지 않은 문자를 제외한 모든 바이트를 인코딩합니다. 'A'-'Z', 'a'-'z', '0'-'9', '-', '.', '_' 및 '~'.

  • 공백 문자는 예약된 문자이고 ‘+’가 아닌 ‘%20’로 인코딩되어야 합니다.

  • 각 URI 인코딩 바이트는 '%' 및 바이트의 두 자리 16진수 값으로 구성됩니다.

  • 16진수 값의 문자는 대문자여야 합니다(예: ‘%1A’).

  • 슬래시 문자('/')를 객체 키 이름을 제외한 모든 위치에 인코딩합니다. 예를 들어, 객체 키 이름이 photos/Jan/sample.jpg인 경우 키 이름의 슬래시는 인코딩되지 않습니다.

중요

개발 플랫폼에서 제공하는 표준 UriEncode 함수는 구현상의 차이와 기본 RFC의 관련 모호성으로 인해 효과적이지 않을 수 있습니다. 인코딩이 제대로 작동하도록 사용자 지정 UriEncode 함수를 직접 작성하는 것이 좋습니다.

다음은 Java로 작성된 UriEncode() 함수 예제입니다.

public static String UriEncode(CharSequence input, boolean encodeSlash) {
          StringBuilder result = new StringBuilder();
          for (int i = 0; i < input.length(); i++) {
              char ch = input.charAt(i);
              if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '-' || ch == '~' || ch == '.') {
                  result.append(ch);
              } else if (ch == '/') {
                  result.append(encodeSlash ? "%2F" : ch);
              } else {
                  result.append(toHexUTF8(ch));
              }
          }
          return result.toString();
      }

서명 프로세스에 대한 자세한 내용은 Authorization 헤더에 대한 서명 계산: 페이로드를 단일 청크로 전송(AWS 서명 버전 4) 섹션을 참조하세요. CanonicalRequest 생성이 다음과 같이 다르다는 점을 제외하면 프로세스는 동일합니다.

  • 추가하려는 요청 헤더 외에도 다음 헤더를 포함해야 합니다.

    헤더 설명
    x-amz-content-sha256

    이 헤더는 모든 AWS 서명 버전 4 요청에서 필수입니다. 서명이 헤더만 포함하고 페이로드가 없음을 나타내려면 값을 STREAMING-AWS4-HMAC-SHA256-PAYLOAD로 설정합니다.
    Content-Encoding

    값을 aws-chunked(으)로 설정합니다.

    Amazon S3는 여러 콘텐츠 인코딩 값을 지원합니다. 서명 버전 4 스트리밍 API를 사용하는 경우 사용자 지정 콘텐츠 인코딩을 지정할 수 있습니다.

    예제:

    Content-Encoding : aws-chunked,gzip

    Amazon S3는 결과 객체를 content-encoding 헤더에 aws-chunked 값 없이 저장합니다. aws-chunked가 content-encoding 헤더에 전달하는 유일한 값인 경우 S3는 content-encoding 헤더를 비어 있는 것으로 간주하고 사용자가 객체를 검색할 때 이 헤더를 반환하지 않습니다.
    x-amz-decoded-content-length 메타데이터는 포함하지 않고 청크할 데이터의 길이를 바이트 단위로 설정합니다. 예를 들어 4GB 파일을 업로드하는 경우 값을 4294967296으로 설정합니다. 이 값은 업로드할 객체의 원시 크기입니다(Amazon S3에 저장하려는 데이터).
    Content-Length

    값을 전송된 HTTP 본문의 실제 크기로 설정합니다. 여기에는 데이터 길이(x-amz-decoded-content-length에 설정된 값)와 청크 메타데이터가 포함됩니다. 각 청크에는 이전 청크의 서명과 같은 메타데이터가 있습니다. 청크 계산은 다음 섹션에서 설명합니다. Transfer-Encoding 헤더를 포함하고 identity 이외의 값을 지정하는 경우 Content-Length 헤더를 포함해서는 안 됩니다.

첫 번째 청크를 시드 서명과 함께 전송합니다. 다음 섹션에 설명된 대로 청크를 구성해야 합니다.

청크 본문 정의

모든 청크에는 일부 메타데이터가 포함됩니다. 각 청크는 다음 구조를 준수해야 합니다.

string(IntHexBase(chunk-size)) + ";chunk-signature=" + signature + \r\n + chunk-data + \r\n

위치:

  • IntHexBase()는 정수 청크 크기를 16진수로 변환하기 위해 작성하는 함수입니다. 예를 들어 청크 크기가 65536인 경우 16진수 문자열은 '10000'입니다.

  • chunk-size는 메타데이터를 포함하지 않은 청크 데이터의 바이트 단위 크기입니다. 예를 들어 65KB 객체를 업로드하면서 청크 크기를 64KB로 사용하는 경우 데이터를 세 개의 청크로 업로드합니다. 첫 번째 청크는 64KB, 두 번째 청크는 1KB, 마지막 청크는 0바이트입니다.

  • signature 각 청크에 대해 다음 서명할 문자열을 사용하여 서명을 계산합니다. 첫 번째 청크의 경우 seed-signature를 이전 서명으로 사용합니다.

    서명할 문자열의 다양한 구성 요소를 보여주는 시드 서명 계산 프로세스입니다.

전송하는 최종 청크 데이터의 크기는 0이지만 청크 본문에는 이전 청크의 서명을 포함한 메타데이터가 여전히 포함되어 있습니다.

예제: PUT Object

이 섹션의 예제는 코드의 서명 계산을 점검하기 위한 참조로 사용할 수 있습니다. 예제를 검토하기 전에 다음 사항에 유의하세요.

  • 이러한 예제의 서명 계산은 다음 예제 보안 자격 증명을 사용합니다.

    파라미터 값
    AWSAccessKeyId AKIAIOSFODNN7EXAMPLE
    AWSSecretAccessKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

  • 모든 예제는 요청 타임스탬프 20130524T000000Z(Fri, 24 May 2013 00:00:00 GMT)를 사용합니다.

  • 모든 예제는 examplebucket을 버킷 이름으로 사용합니다.

  • 버킷은 미국 동부(버지니아 북부) 리전에 있는 것으로 가정하며, 자격 증명 Scope 및 Signing Key 계산은 us-east-1을 리전 지정자로 사용합니다. 자세한 내용은 Amazon Web Services 일반 참조의 리전 및 엔드포인트를 참조하세요.

  • 경로 방식 또는 가상 호스팅 방식 요청을 사용할 수 있습니다. 다음 예제에서는 가상 호스팅 방식 요청을 사용합니다.

    https://examplebucket.s3.amazonaws.com/photos/photo1.jpg

    자세한 내용은 Amazon Simple Storage Service 사용 설명서의 버킷의 가상 호스팅을 참조하세요.

다음 예제에서는 객체를 업로드하기 위한 PUT 요청을 전송합니다. 서명 계산은 다음을 가정합니다.

  • 65KB 텍스트 파일을 업로드하고 있으며 파일 콘텐츠는 문자 'a'로 구성된 1자 문자열입니다.

  • 청크 크기는 64KB입니다. 따라서 페이로드는 세 개의 청크, 즉 64KB 청크, 1KB 청크, 청크 데이터가 0바이트인 최종 청크로 업로드됩니다.

  • 결과 객체의 키 이름은 chunkObject.txt입니다.

  • x-amz-storage-class 요청 헤더를 추가하여 REDUCED_REDUNDANCY를 스토리지 클래스로 요청하고 있습니다.

이 API 작업에 대한 자세한 내용은 PutObject를 참조하세요. 전체 요청 구문은 다음과 같습니다.

PUT /examplebucket/chunkObject.txt HTTP/1.1
Host: s3.amazonaws.com
x-amz-date: 20130524T000000Z 
x-amz-storage-class: REDUCED_REDUNDANCY
Authorization: SignatureToBeCalculated
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD
Content-Encoding: aws-chunked
x-amz-decoded-content-length: 66560
Content-Length: 66824
<Payload>

다음 단계에서는 서명 계산을 보여줍니다.

  1. 시드 서명 - 서명할 문자열 생성
    1. CanonicalRequest

      PUT
/examplebucket/chunkObject.txt

content-encoding:aws-chunked
content-length:66824
host:s3.amazonaws.com
x-amz-content-sha256:STREAMING-AWS4-HMAC-SHA256-PAYLOAD
x-amz-date:20130524T000000Z
x-amz-decoded-content-length:66560
x-amz-storage-class:REDUCED_REDUNDANCY

content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class
STREAMING-AWS4-HMAC-SHA256-PAYLOAD

      정식 요청에서 세 번째 줄은 요청에 쿼리 파라미터가 없기 때문에 비어 있습니다. 마지막 줄은 해시된 페이로드의 값으로 제공된 상수 문자열로, x-amz-content-sha256 header의 값과 동일해야 합니다.

    2. StringToSign

      AWS4-HMAC-SHA256
20130524T000000Z
20130524/us-east-1/s3/aws4_request
cee3fed04b70f867d036f722359b0b1f2f0e5dc0efadbc082b76c4c60e316455

      참고

      서명할 문자열의 각 줄에 대한 자세한 내용은 시드 서명 계산을 설명하는 다이어그램을 참조하세요.

  2. SigningKey

    signing key = HMAC-SHA256(HMAC-SHA256(HMAC-SHA256(HMAC-SHA256("AWS4" + "<YourSecretAccessKey>","20130524"),"us-east-1"),"s3"),"aws4_request")

  3. 시드 서명

    4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9

  4. Authorization 헤더

    결과 Authorization 헤더는 다음과 같습니다.

    AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class,Signature=4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9

  5. 청크 1: (65536바이트, 문자 'a'의 경우 값 97)

    1. 서명할 청크 문자열:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
bf718b6f653bebc184e1479f1935b8da974d701b893afcf49e701f3e2f9f9c5a

      참고

      서명할 문자열의 각 줄에 대한 자세한 내용은 서명할 문자열의 다양한 구성 요소를 보여주는 이전 다이어그램을 참조하세요(예: 마지막 세 줄은 previous-signature, hash(""), hash(current-chunk-data)).

    2. 청크 서명:

      ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648

    3. 전송된 청크 데이터:

      10000;chunk-signature=ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648
<65536-bytes>
  6. 청크 2: (1024바이트, 문자 'a'의 경우 값 97)

    1. 서명할 청크 문자열:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
2edc986847e209b4016e141a6dc8716d3207350f416969382d431539bf292e4a

    2. 청크 서명:

      0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497

    3. 전송된 청크 데이터:

      400;chunk-signature=0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497
<1024 bytes>
  7. 청크 3: (0바이트 데이터)

    1. 서명할 청크 문자열:

      AWS4-HMAC-SHA256-PAYLOAD
20130524T000000Z
20130524/us-east-1/s3/aws4_request
0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

    2. 청크 서명:

      b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9

    3. 전송된 청크 데이터:

      0;chunk-signature=b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9