공유 키를 사용하여 권한 부여

아티클
11/18/2024

공용 또는 서명된 액세스에 사용할 수 있는 Blob 또는 컨테이너 리소스에 대한 요청이 아닌 한 스토리지 서비스에 대한 모든 요청은 권한이 부여되어야 합니다. 요청에 권한을 부여하는 한 가지 옵션은 이 문서에 설명된 공유 키를 사용하는 것입니다.

중요하다

최적의 보안을 위해 Microsoft는 관리 ID와 함께 Microsoft Entra ID를 사용하여 가능한 한 Blob, 큐 및 테이블 데이터에 대한 요청에 권한을 부여하는 것이 좋습니다. Microsoft Entra ID 및 관리 ID를 사용한 권한 부여는 공유 키 권한 부여를 통해 뛰어난 보안 및 사용 편의성을 제공합니다. 자세한 내용은 Microsoft Entra ID권한 부여를 참조하세요. 관리 ID에 대한 자세한 내용은 Azure 리소스관리 ID란?을 참조하세요.

온-프레미스 애플리케이션과 같이 Azure 외부에서 호스트되는 리소스의 경우 Azure Arc를 통해 관리 ID를 사용할 수 있습니다. 예를 들어 Azure Arc 지원 서버에서 실행되는 앱은 관리 ID를 사용하여 Azure 서비스에 연결할 수 있습니다. 자세한 내용은 Azure Arc 지원 서버를 사용하여 Azure 리소스에 대해 인증을 참조하세요.

SAS(공유 액세스 서명)가 사용되는 시나리오의 경우 사용자 위임 SAS를 사용하는 것이 좋습니다. 사용자 위임 SAS는 계정 키 대신 Microsoft Entra 자격 증명으로 보호됩니다. 공유 액세스 서명에 대한 자세한 내용은 사용자 위임 SAS만들기를 참조하세요.

Blob, 큐, 테이블 및 파일 서비스는 버전 2009-09-19 이상(Blob, 큐 및 테이블 서비스용) 및 버전 2014-02-14 이상(파일 서비스의 경우)에 대해 다음과 같은 공유 키 권한 부여 체계를 지원합니다.

Blob, 큐 및 파일 서비스에 대한 공유 키입니다. 공유 키 권한 부여 체계를 사용하여 Blob, 큐 및 파일 서비스에 대한 요청을 만듭니다. 버전 2009-09-19 이상의 공유 키 권한 부여는 강화된 보안을 위해 보강된 서명 문자열을 지원하며, 이 보강된 서명을 사용하여 권한을 부여하도록 서비스를 업데이트해야 합니다.
Table Service에 대한 공유 키입니다. 공유 키 권한 부여 체계를 사용하여 REST API를 사용하여 Table Service에 대한 요청을 만듭니다. 버전 2009-09-19 이상에서 Table Service에 대한 공유 키 권한 부여는 이전 버전의 Table Service와 동일한 서명 문자열을 사용합니다.
공유 키 라이트. 공유 키 Lite 권한 부여 체계를 사용하여 Blob, 큐, 테이블 및 파일 서비스에 대한 요청을 만듭니다. 공유 키 라이트는 프리미엄 페이지 Blob에 대해 지원되지 않습니다.

Blob 및 Queue Services 버전 2009-09-19 이상에서는 공유 키 Lite 권한 부여가 이전 버전의 Blob 및 Queue Services에서 공유 키에 대해 지원된 것과 동일한 서명 문자열을 사용하도록 지원합니다. 따라서 공유 키 라이트를 사용하여 서명 문자열을 업데이트하지 않고 Blob 및 큐 서비스에 대해 요청할 수 있습니다.

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

중요하다

Azure Storage는 HTTP 및 HTTPS를 모두 지원하지만 HTTPS를 사용하는 것이 좋습니다.

메모

컨테이너 또는 Blob은 컨테이너의 사용 권한을 설정하여 공용 액세스에 사용할 수 있습니다. 자세한 내용은 Azure Storage 리소스대한 액세스 관리를 참조하세요. 공유 액세스 서명을 통해 서명된 액세스에 컨테이너, Blob, 큐 또는 테이블을 사용할 수 있습니다. 공유 액세스 서명은 다른 메커니즘을 통해 권한이 부여됩니다. 자세한 내용은 공유 액세스 서명 위임 액세스를 참조하세요.

날짜 머리글 지정

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

스토리지 서비스는 서비스에 도달할 때까지 요청이 15분 이하인지 확인합니다. 재생 공격을 비롯한 특정 보안 공격을 방지합니다. 이 검사가 실패하면 서버는 응답 코드 403(사용할 수 없음)을 반환합니다.

메모

일부 HTTP 클라이언트 라이브러리 및 프록시가 자동으로 Date 헤더를 설정하고 개발자가 권한 있는 요청에 포함하기 위해 해당 값을 읽을 수 있는 기회를 제공하지 않기 때문에 x-ms-date 헤더가 제공됩니다. x-ms-date설정하는 경우 Date 헤더에 대한 빈 값으로 서명을 생성합니다.

권한 부여 헤더 지정

권한 있는 요청에는 Authorization 헤더가 포함되어야 합니다. 이 헤더가 포함되지 않은 경우 요청은 익명이며 공용 액세스로 표시된 컨테이너 또는 Blob 또는 위임된 액세스를 위해 공유 액세스 서명이 제공된 컨테이너, Blob, 큐 또는 테이블에 대해서만 성공합니다.

요청에 권한을 부여하려면 요청을 만드는 계정의 키로 요청에 서명하고 요청의 일부로 해당 서명을 전달해야 합니다.

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

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

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

메모

해당 리소스에 공개적으로 액세스할 수 있는 경우 다른 계정 아래에 있는 리소스를 요청할 수 있습니다.

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

서명 문자열 생성

서명 문자열을 생성하는 방법은 권한을 부여하는 서비스 및 버전과 사용 중인 권한 부여 체계에 따라 달라집니다. 서명 문자열을 생성할 때는 다음 사항에 유의하세요.

문자열의 VERB 부분은 GET 또는 PUT과 같은 HTTP 동사이며 대문자여야 합니다.
Blob, 큐 및 파일 서비스에 대한 공유 키 권한 부여의 경우 서명 문자열에 포함된 각 헤더는 한 번만 표시할 수 있습니다. 헤더가 중복된 경우 서비스는 상태 코드 400(잘못된 요청)을 반환합니다.
모든 표준 HTTP 헤더의 값은 헤더 이름 없이 서명 형식으로 표시된 순서대로 문자열에 포함되어야 합니다. 이러한 헤더는 요청의 일부로 지정되지 않은 경우 비어 있을 수 있습니다. 이 경우 새 줄 문자만 필요합니다.
x-ms-date 헤더가 지정된 경우 요청에 지정되었는지 여부에 관계없이 Date 헤더를 무시하고 서명 문자열의 Date 부분에 대해 빈 줄을 지정하면 됩니다. 이 경우 x-ms-date 헤더를 추가하기 위한 정식 헤더 문자열 섹션 생성의 지침을 따릅니다.

x-ms-date 및 Date;를 모두 지정할 수 있습니다. 이 경우 서비스는 x-ms-date값을 사용합니다.
x-ms-date 헤더를 지정하지 않으면 헤더 이름을 포함하지 않고 서명 문자열에 Date 헤더를 지정합니다.
표시된 모든 새 줄 문자(\n)는 서명 문자열 내에 필요합니다.
서명 문자열에는 정식화된 헤더와 정식화된 리소스 문자열이 포함됩니다. 이러한 문자열을 정식화하면 Azure Storage에서 인식하는 표준 형식으로 전환됩니다. 서명 문자열의 일부를 구성하는 CanonicalizedHeaders 및 CanonicalizedResource 문자열을 생성하는 방법에 대한 자세한 내용은 이 항목의 뒷부분에 나오는 적절한 섹션을 참조하세요.

Blob, 큐 및 파일 서비스(공유 키 권한 부여)

Blob 또는 Queue 서비스의 2009-09-19 버전 이상 및 파일 서비스의 버전 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;

중요하다

현재 버전에서 요청의 콘텐츠 길이가 0인 경우 Content-Length 필드는 빈 문자열이어야 합니다. 버전 2014-02-14 이하에서는 콘텐츠 길이가 0인 경우에도 포함되었습니다. 이전 동작에 대한 자세한 내용은 아래를 참조하세요.

다음 예제에서는 Blob 가져오기 작업에 대한 서명 문자열을. 헤더 값이 없는 경우 새 줄 문자만 지정됩니다.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

이 줄 바꿈을 줄 바꿈하면 동일한 문자열의 각 부분이 표시됩니다.

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\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:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

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

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

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

가능한 변경이 가장 적은 Blob 및 Queue 서비스의 버전 2009-09-19 이상으로 코드를 마이그레이션하려는 경우 공유 키 대신 공유 키 라이트를 사용하도록 기존 Authorization 헤더를 수정할 수 있습니다. 공유 키 라이트에 필요한 서명 형식은 2009-09-19 이전 버전의 Blob 및 Queue Services에서 공유 키에 필요한 서명 형식과 동일합니다.

중요하다

읽기 액세스 지역 복제(RA-GRS)가 사용하도록 설정된 스토리지 계정의 보조 위치에 액세스하는 경우 권한 부여 헤더에 -secondary 지정을 포함하지 마세요. 권한 부여를 위해 계정 이름은 보조 액세스의 경우에도 항상 기본 위치의 이름입니다.

버전 2014-02-14 이하의 Content-Length 헤더

버전 2014-02-14 이하를 사용하는 경우 Content-Length 0인 경우 StringToSignContent-Length 부분을 0. 일반적으로 빈 문자열입니다.

예를 들어 다음 요청의 경우 Content-Length 헤더 값은 0인 경우에도 StringToSign 포함됩니다.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

StringToSign 다음과 같이 생성됩니다.

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

2014-02-14 이후 버전에서는 StringToSignContent-Length빈 문자열을 포함해야 합니다.

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Table Service(공유 키 권한 부여)

서비스에서 REST API를 사용하여 요청을 만드는 경우 공유 키 권한 부여를 사용하여 Table Service에 대한 요청에 권한을 부여해야 합니다. Table Service에 대한 공유 키에 대한 서명 문자열의 형식은 모든 버전에서 동일합니다.

테이블 서비스에 대한 요청에 대한 공유 키 서명 문자열은 문자열의 CanonicalizedHeaders 부분을 포함하지 않는다는 점에서 Blob 또는 Queue Service에 대한 요청의 경우와 약간 다릅니다. 또한 요청이 x-ms-date 헤더를 설정하더라도 이 경우 Date 헤더는 비어있지 않습니다. 요청이 x-ms-date설정하면 해당 값도 Date 헤더의 값에 사용됩니다.

REST API를 사용하여 만든 Table Service에 대한 요청에 대한 서명 문자열을 인코딩하려면 다음 형식을 사용합니다.

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

메모

버전 2009-09-19부터 Table Service에서는 모든 REST 호출에 DataServiceVersion 및 MaxDataServiceVersion 헤더가 포함되어야 합니다. 자세한 내용은 OData Data Service 버전 헤더 설정을 참조하세요.

Blob, 큐 및 파일 서비스(공유 키 라이트 권한 부여)

공유 키 라이트 권한 부여를 사용하여 2009-09-19 버전 이상 Blob 및 큐 서비스 및 파일 서비스 버전 2014-02-14 이상에 대한 요청에 권한을 부여할 수 있습니다. 공유 키 라이트는 프리미엄 페이지 Blob에 대해 지원되지 않습니다.

공유 키 라이트의 서명 문자열은 2009-09-19 이전 버전의 Blob 및 Queue Services에서 공유 키 권한 부여에 필요한 서명 문자열과 동일합니다. 따라서 Blob 및 Queue Services 버전 2009-09-19의 변경 횟수가 가장 적은 코드를 마이그레이션하려는 경우 서명 문자열 자체를 변경하지 않고 공유 키 라이트를 사용하도록 코드를 수정할 수 있습니다. 공유 키 라이트를 사용하면 버전 2009-09-19 이상에서 공유 키를 사용하여 제공하는 향상된 보안 기능을 얻을 수 없습니다.

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

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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

테이블 서비스(공유 키 라이트 권한 부여)

공유 키 라이트 권한 부여를 사용하여 모든 버전의 Table Service에 대한 요청에 권한을 부여할 수 있습니다.

공유 키 라이트를 사용하여 Table Service에 대한 요청에 대한 서명 문자열을 인코딩하려면 다음 형식을 사용합니다.

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 부분을 생성하려면 다음 단계를 수행합니다.

x-ms-date 헤더를 포함하여 x-ms-시작하는 리소스에 대한 모든 헤더를 검색합니다.
각 HTTP 헤더 이름을 소문자로 변환합니다.
머리글을 머리글 이름으로 사전순으로 오름차순으로 정렬합니다. 각 헤더는 문자열에 한 번만 나타날 수 있습니다.

메모

어휘 순서 항상 기존의 사전순 순서와 일치하지 않을 수 있습니다.
헤더 값의 선형 공백을 단일 공백으로 바꿉다.

선형 공백에는 CRLF(캐리지 리턴/줄 바꿈), 공백 및 탭이 포함됩니다. 자세한 내용은 RFC 2616, 섹션 4.2 참조하세요. 따옴표 붙은 문자열 안에 공백을 바꾸지 마세요.

헤더의 콜론 주위에 공백을 잘라 내어 집니다.
마지막으로 결과 목록의 정식화된 각 헤더에 새 줄 문자를 추가합니다. 이 목록의 모든 헤더를 단일 문자열로 연결하여 CanonicalizedHeaders 문자열을 생성합니다.

다음은 정식화된 헤더 문자열의 예를 보여 줍니다.

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

메모

서비스 버전 2016-05-31 이전에는 빈 값이 있는 헤더를 서명 문자열에서 생략했습니다. 이제 종료되는 새 줄이 있는 콜론 문자 바로 다음에 의해 CanonicalizedHeaders에 표시됩니다.

정식화된 리소스 문자열 생성

서명 문자열의 CanonicalizedResource 부분은 요청이 대상으로 하는 스토리지 서비스 리소스를 나타냅니다. 리소스의 URI에서 파생된 CanonicalizedResource 문자열의 모든 부분은 URI에 있는 그대로 인코딩되어야 합니다.

CanonicalizedResource 문자열에 대해 지원되는 형식은 두 가지입니다.

Blob 및 Queue 서비스 버전 2009-09-19 이상 및 파일 서비스 버전 2014-02-14 이상에 대한 공유 키 권한 부여를 지원하는 형식입니다.
모든 버전의 Table Service에 대해 공유 키 및 공유 키 라이트를 지원하는 형식이며 Blob 및 큐 서비스 버전 2009-09-19 이상에 대한 공유 키 라이트입니다. 이 형식은 이전 버전의 스토리지 서비스에서 사용한 형식과 동일합니다.

액세스하는 리소스에 대한 URI를 구성하는 데 도움이 되는 내용은 다음 항목 중 하나를 참조하세요.

Blob 서비스: 컨테이너, Blob 및 메타데이터 명명 및 참조
큐 서비스: 큐 서비스 리소스 주소 지정
테이블 서비스: Table Service 리소스 주소 지정
파일 서비스: 공유, 디렉터리, 파일 및 메타데이터 명명 및 참조

중요하다

스토리지 계정이 읽기 액세스 지역 복제(RA-GRS)로 복제되고 보조 위치의 리소스에 액세스하는 경우 CanonicalizedResource 문자열에 –secondary 지정을 포함하지 마세요. CanonicalizedResource 문자열 URI에 사용되는 리소스 URI는 기본 위치에 있는 리소스의 URI여야 합니다.

메모

스토리지 에뮬레이터에 대해 권한을 부여하는 경우 계정 이름이 CanonicalizedResource 문자열에 두 번 표시됩니다. 이 작업이 필요합니다. Azure Storage 서비스에 대해 권한을 부여하는 경우 계정 이름은 CanonicalizedResource 문자열에 한 번만 표시됩니다.

2009-09-19 이상에 대한 공유 키 형식

이 형식은 2009-09-19 버전 이상 Blob 및 큐 서비스 및 2014-02-14 버전 이상 파일 서비스에 대한 공유 키 권한 부여를 지원합니다. 다음과 같이 이 형식으로 CanonicalizedResource 문자열을 생성합니다.

빈 문자열("")부터 슬래시(/)를 추가한 다음 액세스 중인 리소스를 소유하는 계정의 이름을 추가합니다.
쿼리 매개 변수 없이 리소스의 인코딩된 URI 경로를 추가합니다.
리소스 URI에 있는 경우 comp 매개 변수를 포함하여 모든 쿼리 매개 변수를 검색합니다.
모든 매개 변수 이름을 소문자로 변환합니다.
쿼리 매개 변수를 사전순으로 매개 변수 이름으로 오름차순으로 정렬합니다.
각 쿼리 매개 변수 이름 및 값을 URL로 디코딩합니다.
각 이름-값 쌍 앞에 줄 바꿈 문자(\n)를 포함합니다.
각 쿼리 매개 변수 이름과 값을 다음 형식으로 문자열에 추가하여 이름과 값 사이에 콜론(:) 포함해야 합니다.

parameter-name:parameter-value
쿼리 매개 변수에 둘 이상의 값이 있는 경우 모든 값을 사전순으로 정렬한 다음 쉼표로 구분된 목록에 포함합니다.

parameter-name:parameter-value-1,parameter-value-2,parameter-value-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  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

2009-09-19 이상에 대한 공유 키 라이트 및 테이블 서비스 형식

이 형식은 모든 버전의 Table Service에 대해 공유 키 및 공유 키 라이트를 지원하고, Blob 및 큐 서비스 버전 2009-09-19 이상 및 파일 서비스 버전 2014-02-14 이상에 대한 공유 키 라이트를 지원합니다. 이 형식은 이전 버전의 스토리지 서비스에서 사용한 형식과 동일합니다. 다음과 같이 이 형식으로 CanonicalizedResource 문자열을 생성합니다.

빈 문자열("")부터 슬래시(/)를 추가한 다음 액세스 중인 리소스를 소유하는 계정의 이름을 추가합니다.
리소스의 인코딩된 URI 경로를 추가합니다. 요청 URI가 리소스의 구성 요소를 해결하는 경우 적절한 쿼리 문자열을 추가합니다. 쿼리 문자열에는 물음표와 comp 매개 변수(예: ?comp=metadata)가 포함되어야 합니다. 쿼리 문자열에 다른 매개 변수를 포함해서는 안 됩니다.

서명 인코딩

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

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))

참고 항목

Blob Service REST API
Queue Service REST API
table Service REST API
스토리지 서비스 REST

다음을 통해 공유

공유 키를 사용하여 권한 부여

날짜 머리글 지정

권한 부여 헤더 지정

서명 문자열 생성

Blob, 큐 및 파일 서비스(공유 키 권한 부여)

버전 2014-02-14 이하의 Content-Length 헤더

Table Service(공유 키 권한 부여)

Blob, 큐 및 파일 서비스(공유 키 라이트 권한 부여)

테이블 서비스(공유 키 라이트 권한 부여)

정식화된 헤더 문자열 생성

정식화된 리소스 문자열 생성

2009-09-19 이상에 대한 공유 키 형식

2009-09-19 이상에 대한 공유 키 라이트 및 테이블 서비스 형식

서명 인코딩

참고 항목

추가 리소스