내보내기(0) 인쇄
모두 확장

Azure 저장소 서비스에 대한 인증

업데이트 날짜: 2014년 5월

저장소 서비스에 대한 모든 요청은 해당 요청이 공용 또는 서명된 액세스용으로 제공된 blob 또는 컨테이너 리소스에 대한 요청이 아닌 한 인증을 수행해야 합니다.

Important중요
Microsoft Azure 저장소 서비스는 HTTP 및 HTTPS를 모두 지원하지만 HTTPS를 사용하는 것이 좋습니다.

Blob, 큐, 테이블 및 파일 서비스는 버전 2009-09-19(Blob, 큐 및 테이블 서비스의 경우) 및 버전 2014-02-14(파일 서비스의 경우)부터 다음 공유 키 인증 체계를 지원합니다.

  • Blob, 큐 및 파일 서비스에 대한 공유 키. 공유 키 인증 체계를 사용해서 Blob, 큐 및 파일 서비스에 대한 요청을 수행할 수 있습니다. 2009-09-19 버전의 공유 키 인증에서는 향상된 보안을 위한 보강된 서명 문자열이 지원되며, 이 보강된 서명을 사용해서 인증을 수행하도록 서비스를 업데이트해야 합니다.

  • 테이블 서비스에 대한 공유 키. 공유 키 인증 체계를 사용해서 REST API를 사용하여 테이블 서비스에 대한 요청을 수행할 수 있습니다. 2009-09-19 버전의 테이블 서비스에 대한 공유 키 인증에서는 이전 버전의 테이블 서비스와 동일한 서명 문자열이 사용됩니다.

  • Shared Key Lite. Shared Key Lite 인증 체계를 사용하여 Blob, 큐, 테이블 및 파일 서비스에 대한 요청을 수행할 수 있습니다.

    2009-09-19 버전의 Blob 및 큐 서비스에 대해 Shared Key Lite 인증은 이전 버전의 Blob 및 큐 서비스에서 공유 키에 대해 지원된 것과 동일한 서명 문자열 사용을 지원합니다. 따라서 서명 문자열을 업데이트하지 않고도 Shared Key Lite를 사용해서 Blob 및 큐 서비스에 대해 요청을 수행할 수 있습니다.

인증된 요청에는 Date 또는 x-ms-date 헤더와 Authorization 헤더가 필요합니다. 다음 섹션에서는 이러한 헤더를 생성하는 방법을 설명합니다.

note참고
컨테이너 또는 Blob은 해당 컨테이너의 권한을 설정해서 공용 액세스에 사용하도록 설정할 수 있습니다. 자세한 내용은 Azure 저장소 리소스에 대한 액세스 관리를 참조하십시오. 컨테이너, Blob, 큐 또는 테이블은 공유 액세스 서명을 통해 서명된 액세스에 사용하도록 설정할 수 있습니다. 공유 액세스 서명은 다른 메커니즘을 통해 인증됩니다. 자세한 내용은 공유 액세스 서명으로 액세스 위임를 참조하십시오.

인증된 모든 요청은 해당 요청에 대한 UTC(협정 세계시) 타임스탬프를 포함해야 합니다. 타임스탬프는 x-ms-date 헤더 또는 표준 HTTP/HTTPS Date 헤더에 지정할 수 있습니다. 요청에 두 헤더가 모두 지정된 경우 x-ms-date의 값이 해당 요청의 생성 시간으로 사용됩니다.

저장소 서비스는 요청이 서비스에 도착할 때 15분이 경과되지 않았는지 확인합니다. 이렇게 해서 재생 공격을 포함하여 특정 보안 공격으로부터 보호합니다. 이 검사가 실패하면 서버가 응답 코드 403(금지됨)을 반환합니다.

note참고
x-ms-date 헤더가 제공되는 이유는 일부 HTTP 클라이언트 라이브러리 및 프록시에서는 Date 헤더가 자동으로 설정되고, 개발자가 이를 인증된 요청에 포함하기 위해 해당 값을 읽을 수 없기 때문입니다. x-ms-date를 설정할 경우, Date 헤더에 대해 빈 값을 사용해서 서명을 생성합니다.

인증된 요청은 Authorization 헤더를 포함해야 합니다. 이 헤더가 포함되지 않으면, 요청이 익명으로 처리되고, 공용 액세스용으로 표시된 컨테이너 또는 Blob에 대해 또는 위임된 액세스를 위해 공유 액세스 서명이 제공된 컨테이너, Blob, 큐 또는 테이블에 대해서만 요청이 성공할 수 있습니다.

요청을 인증하려면 요청을 수행하는 계정의 키를 사용해서 요청을 서명하고 이 서명을 요청에 포함해서 전달해야 합니다.

Authorization 헤더의 형식은 다음과 같습니다.

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

여기서 SharedKey 또는 SharedKeyLite는 권한 부여 체계의 이름이고, AccountName은 리소스 요청 계정의 이름이며, Signature는 요청으로부터 생성되고, SHA256 알고리즘을 사용해서 계산된 후 Base64 인코딩을 사용해서 인코딩된 HMAC(해시 기반 메시지 인증 코드)입니다.

note참고
공개적으로 액세스할 수 있는 리소스면 다른 계정에 있는 해당 리소스도 요청할 수 있습니다.

다음 섹션에서는 Authorization 헤더 생성 방법을 설명합니다.

서명 문자열 생성 방법은 인증을 수행하는 서비스 및 버전과 사용 중인 인증 체계에 따라 달라집니다. 서명 문자열을 생성할 때는 다음에 유의해야 합니다.

  • 문자열의 VERB 부분은 HTTP 동사(예: GET 또는 PUT)이며, 대문자여야 합니다.

  • Blob, 큐 및 파일 서비스에 대한 공유 키 인증의 경우, 서명 문자열에 포함된 각 헤더는 한 번만 나타날 수 있습니다. 헤더가 중복되면 서비스가 상태 코드 400(잘못된 요청)을 반환합니다.

  • 모든 표준 HTTP 헤더의 값은 헤더 이름 없이 서명 형식에 표시된 순서로 문자열에 포함되어야 합니다. 요청의 일부로 지정되지 않은 경우에는 이러한 헤더가 비어 있을 수 있으며, 이 경우 줄 바꿈 문자만 필요합니다.

  • x-ms-date 헤더가 지정된 경우 요청에 지정되었는지 여부에 관계없이 Date 헤더를 무시할 수 있으며, 서명 문자열의 Date 부분에 빈 줄만 지정할 수 있습니다. 이 경우 CanonicalizedHeaders 요소 생성 섹션의 지침에 따라 x-ms-date 헤더를 추가합니다.

    이 경우 x-ms-dateDate를 모두 지정할 수 있으며, 서비스에는 x-ms-date 값이 사용됩니다.

  • x-ms-date 헤더가 지정되지 않은 경우에는 헤더 이름을 포함하지 않고 서명 문자열에 Date 헤더를 지정합니다.

  • 표시된 모든 줄 바꿈 문자(\n)는 서명 문자열 내에도 필요합니다.

  • 서명 문자열을 구성하는 CanonicalizedHeadersCanonicalizedResource 문자열을 생성하는 방법에 대한 자세한 내용은 이 항목의 뒷부분에 있는 해당 섹션을 참조하십시오.

버전 2009-09-19 이상의 Blob 또는 큐 서비스에 대한 요청과 버전 2014-02-14 이상의 파일 서비스에 대한 요청에 대해 공유 키 서명 문자열을 인코딩하려면 다음 형식을 사용합니다.

StringToSign = VERB + "\n" +
               Content-Encoding + "\n"
               Content-Language + "\n"
               Content-Length + "\n"
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               If-Modified-Since + "\n"
               If-Match + "\n"
               If-None-Match + "\n"
               If-Unmodified-Since + "\n"
               Range + "\n"
               CanonicalizedHeaders + 
               CanonicalizedResource;

다음 예에서는 Blob 가져오기 작업의 서명 문자열을 보여줍니다. 헤더 값이 없는 곳에는 줄 바꿈 문자만 지정됩니다.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

아래 예는 위 문자열의 각 부분을 한 줄씩 구분해서 보여줍니다.


GET\n /*HTTP Verb*/
\n    /*Content-Encoding*/
\n    /*Content-Language*/
\n    /*Content-Length*/
\n    /*Content-MD5*/
\n    /*Content-Type*/
\n    /*Date*/
\n    /*If-Modified-Since */
\n    /*If-Match*/
\n    /*If-None-Match*/
\n    /*If-Unmodified-Since*/
\n    /*Range*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/
/myaccount/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

그런 다음 UTF-8로 인코딩된 서명 문자열에 HMAC-SHA256 알고리즘을 사용해서 이 문자열을 인코딩하고, Authorization 헤더를 생성하고, 헤더를 요청에 추가합니다. 다음 예는 동일 작업에 대한 Authorization 헤더를 보여줍니다.

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

2009-09-19 버전의 Blob 및 큐 서비스에 공유 키 인증을 사용하려면 이 보강된 서명 문자열을 사용하도록 코드를 업데이트해야 합니다.

코드를 최소한으로만 변경해서 2009-09-19 버전의 Blob 및 큐 서비스로 마이그레이션하려는 경우 공유 키 대신 Shared Key Lite를 사용하도록 기존 Authorization 헤더를 수정할 수 있습니다. Shared Key Lite에 필요한 서명 형식은 2009-09-19 이전 버전의 Blob 및 큐 서비스 공유 키에 필요한 형식과 동일합니다.

서비스에서 요청 수행을 위해 REST API를 사용하는 경우 공유 키 인증을 사용해서 테이블 서비스에 대해 수행된 요청을 인증해야 합니다. 테이블 서비스에 대한 공유 키의 서명 문자열 형식은 모든 버전에 대해 동일합니다.

테이블 서비스에 대한 요청의 공유 키 서명 문자열은 문자열의 CanonicalizedHeaders 부분이 포함되지 않으므로 Blob 또는 큐 서비스에 대한 요청의 문자열과 조금 다릅니다. 또한 이 경우 Date 헤더는 요청에 x-ms-date 헤더가 설정되더라도 비어 있지 않습니다. 요청에 x-ms-date가 설정된 경우 해당 값이 Date 헤더의 값에도 사용됩니다.

REST API를 사용해서 수행된 테이블 서비스에 대한 요청의 서명 문자열을 인코딩하려면 다음 형식을 사용합니다.

StringToSign = VERB + "\n" + 
               Content-MD5 + "\n" + 
               Content-Type + "\n" +
               Date + "\n" +
               CanonicalizedResource;

note참고
2009-09-19 버전부터 테이블 서비스를 사용하려면 모든 REST 호출에 DataServiceVersionMaxDataServiceVersion 헤더가 포함되어야 합니다. 자세한 내용은 OData 데이터 서비스 버전 헤더 설정을 참조하십시오.

Shared Key Lite 인증을 사용하여 2009-09-19 버전의 Blob 및 큐 서비스와 2014-02-14 버전의 파일 서비스에 대해 수행된 요청을 인증할 수 있습니다.

Shared Key Lite의 서명 문자열은 2009-09-19 이전 버전의 Blob 및 큐 서비스에서 공유 키 인증에 필요한 서명 문자열과 동일합니다. 따라서 코드를 최소한으로만 변경해서 2009-09-19 버전의 Blob 및 큐 서비스로 마이그레이션하려면 서명 문자열 자체를 변경하지 않고 Shared Key Lite를 사용하도록 코드를 수정할 수 있습니다. Shared Key Lite를 사용하면 2009-09-19 버전의 API에 공유 키를 사용할 때의 향상된 보안 기능을 얻을 수 없습니다.

Blob 또는 큐 서비스에 대해 요청의 서명 문자열을 인코딩하려면 다음 형식을 사용합니다.

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +
               Date + "\n" +
               CanonicalizedHeaders + 
               CanonicalizedResource;

다음 예에서는 Blob 배치 작업의 서명 문자열을 보여줍니다. Content-MD5 헤더 줄은 비어 있습니다. 문자열에 표시된 헤더는 새 blob에 대한 사용자 지정 메타데이터 값을 지정하는 이름-값 쌍입니다.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

그런 다음 UTF-8로 인코딩된 서명 문자열에 HMAC-SHA256 알고리즘을 사용해서 이 문자열을 인코딩하고, Authorization 헤더를 생성하고, 헤더를 요청에 추가합니다. 다음 예는 동일 작업에 대한 Authorization 헤더를 보여줍니다.

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Shared Key Lite 인증을 사용하여 모든 버전의 테이블 서비스에 대해 수행된 요청을 인증할 수 있습니다.

Shared Key Lite를 사용해서 수행된 테이블 서비스에 대한 요청의 서명 문자열을 인코딩하려면 다음 형식을 사용합니다.

StringToSign = Date + "\n" 
               CanonicalizedResource

다음 예에서는 테이블 만들기 작업의 서명 문자열을 보여줍니다.

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

그런 다음 HMAC-SHA256 알고리즘을 사용해서 이 문자열을 인코딩하고, Authorization 헤더를 생성한 후 헤더를 요청에 추가합니다. 다음 예는 동일 작업에 대한 Authorization 헤더를 보여줍니다.

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

서명 문자열의 CanonicalizedHeaders 부분을 생성하려면 다음 단계를 수행합니다.

  1. x-ms- 헤더를 포함하여 x-ms-date로 시작하는 리소스의 모든 헤더를 검색합니다.

  2. 각 HTTP 헤더 이름을 소문자로 변환합니다.

  3. 헤더 이름에 따라 오름차순으로 헤더를 정렬합니다. 각 헤더는 문자열에 한 반만 나타날 수 있습니다.

  4. 분리 공백을 단일 공백으로 바꿔서 문자열을 펼칩니다.

  5. 헤더에서 콜론 주위의 공백을 정리합니다.

  6. 마지막으로 결과 목록에서 각 정규화된 헤더에 줄 바꿈 문자를 추가합니다. 이 목록의 모든 헤더를 단일 문자열로 연결하여 CanonicalizedHeaders 문자열을 생성합니다.

서명 문자열의 CanonicalizedResource 부분은 요청의 대상 저장소 서비스 리소스를 나타냅니다. 리소스의 URI에서 파생된 CanonicalizedResource 문자열의 모든 부분은 URI에 있는 것과 정확히 동일하게 인코딩되어야 합니다.

CanonicalizedResource 문자열에 지원되는 두 가지 형식은 다음과 같습니다.

  • 버전 2009-09-19의 Blob 및 큐 서비스와 버전 2014-02-14의 파일 서비스에 대해 공유 키 인증을 지원하는 형식

  • 모든 버전의 테이블 서비스에 대해 공유 키 및 Shared Key Lite를 지원하고, 2009-09-19 버전의 Blob 및 큐 서비스에 대해 Shared Key Lite를 지원하는 형식. 이 형식은 이전 버전의 저장소 서비스에 사용된 것과 동일합니다.

액세스하는 리소스의 URI 생성에 대한 자세한 내용은 다음 항목 중 하나를 참조하십시오.

note참고
저장소 에뮬레이터에 대해 인증을 수행하는 경우 계정 이름이 CanonicalizedResource 문자열에 두 번 나타납니다. 이 동작은 정상적인 동작입니다. Microsoft Azure 저장소 서비스에 대해 인증을 수행하는 경우에는 계정 이름이 CanonicalizedResource 문자열에 한 번만 나타납니다.

2009-09-19 공유 키 형식

이 형식은 2009-09-19 버전의 Blob 및 큐 서비스와 2014-02-14 버전의 파일 서비스에 대한 공유 키 인증을 지원합니다. CanonicalizedResource 문자열을 이 형식으로 생성하려면 다음을 수행합니다.

  1. 빈 문자열("")로 시작해서 슬래시를 추가하고, 액세스 중인 리소스를 소유하는 계정의 이름을 추가합니다.

  2. 쿼리 매개 변수 없이 리소스의 인코딩된 URI 경로를 추가합니다.

  3. comp 매개 변수를 포함하여(있는 경우) 리소스 URI에서 모든 쿼리 매개 변수를 검색합니다.

  4. 모든 매개 변수 이름을 소문자로 변환합니다.

  5. 매개 변수 이름에 따라 오름차순으로 쿼리 매개 변수를 정렬합니다.

  6. 각 쿼리 매개 변수 이름 및 값에 대해 URL 디코딩을 수행합니다.

  7. 다음 형식으로 문자열에 각 쿼리 매개 변수 이름 및 값을 추가하고 이름과 값 사이에 콜론(:)이 있는지 확인합니다.

    parameter-name:parameter-value

  8. 쿼리 매개 변수에 값이 두 개 이상 포함된 경우, 모든 값을 사전순으로 정렬한 후 쉼표로 구분된 목록으로 값을 포함합니다.

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

  9. 각 이름-값 쌍 뒤에 줄 바꿈 문자(\n)를 추가합니다.

정규화된 리소스 문자열을 생성할 때는 다음 규칙에 주의하십시오.

  • 쿼리 매개 변수 값에 줄 바꿈 문자(\n)를 사용하지 마십시오. 반드시 사용해야 할 경우에는 정규화된 리소스 문자열의 형식에 영향을 주지 않는지 확인합니다.

  • 쿼리 매개 변수 값에 쉼표를 사용하지 마십시오.

다음 예에서는 제공된 요청 URI로부터 생성될 수 있는 서명 문자열의 CanonicalizedResource 부분을 보여줍니다.


Get Container Metadata
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata 
CanonicalizedResource:
    /myaccount/mycontainer\ncomp:metadata\nrestype:container

List Blobs operation:
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs
CanonicalizedResource:
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container

2009-09-19 Shared Key Lite 및 테이블 서비스 형식

이 형식은 모든 버전의 테이블 서비스에 대해 공유 키 및 Shared Key Lite를 지원하고, 2009-09-19 버전의 Blob 및 큐 서비스와 2014-02-14 버전의 파일 서비스에 대해 Shared Key Lite를 지원합니다. 이 형식은 이전 버전의 저장소 서비스에 사용된 것과 동일합니다. CanonicalizedResource 문자열을 이 형식으로 생성하려면 다음을 수행합니다.

  1. 빈 문자열("")로 시작해서 슬래시를 추가하고, 액세스 중인 리소스를 소유하는 계정의 이름을 추가합니다.

  2. 리소스의 인코딩된 URI 경로를 추가합니다. 요청 URI가 리소스의 구성 요소 주소를 지정하는 경우 적합한 쿼리 문자열을 추가합니다. 쿼리 문자열에는 물음표와 comp 매개 변수가 포함되어야 합니다(예: ?comp=metadata). 다른 매개 변수는 쿼리 문자열에 포함하지 않아야 합니다.

서명을 인코딩하려면 UTF-8로 인코딩된 서명 문자열에서 HMAC-SHA256 알고리즘을 호출하고 결과를 Base64로 인코딩합니다. 다음 형식을 사용합니다(의사 코드로 표시됨).

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

참고 항목

표시:
© 2014 Microsoft