공유 키로 권한 부여

아티클
05/13/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 Create 참조하세요.

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

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

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

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

중요

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

참고

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

Date 헤더 지정

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

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

참고

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(해시 기반 메시지 인증 코드)입니다.

참고

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

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

서명 문자열 생성

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

문자열의 VERB 부분은 HTTP 동사(예: GET 또는 PUT)이며, 대문자여야 합니다.
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, 큐 및 파일 서비스(공유 키 권한 부여)

버전 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;

중요

현재 버전에서 요청의 콘텐츠 길이가 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 및 큐 서비스의 버전 2009-09-19 이상에서 공유 키 권한 부여를 사용하려면 이 보강된 서명 문자열을 사용하도록 코드를 업데이트해야 합니다.

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

중요

RA-GRS(읽기 액세스 지역 복제)가 활성화되어 있는 저장소 계정의 보조 위치에 액세스하는 경우 인증 헤더의 -secondary 지정을 포함하면 안 됩니다. 권한 부여를 위해서는 보조 액세스에 대해서도 계정 이름이 항상 기본 위치의 이름이어야 합니다.

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

버전 2014-02-14 이하를 사용하는 경우 가 0이면 Content-Length 의 StringToSign0일부를 로 설정합니다Content-Length. 일반적으로 빈 문자열입니다.

예를 들어 다음 요청의 경우 헤더 값 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 StringToSign 이후 버전에서는 에 대한 Content-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

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

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

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

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

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

참고

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

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

공유 키 라이트 권한 부여를 사용하여 Blob 및 Queue 서비스의 2009-09-19 버전 이상 및 파일 서비스의 버전 2014-02-14 이상에 대한 요청에 권한을 부여할 수 있습니다.

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

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

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

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

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

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

StringToSign = Date + "\n"
               CanonicalizedResource

다음 예제에서는 Create 테이블 작업에 대한 서명 문자열을 보여줍니다.

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- 헤더를 포함하여 x-ms-date로 시작하는 리소스의 모든 헤더를 검색합니다.
각 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 이상에 대한 공유 키 권한 부여를 지원하는 형식입니다.
모든 버전의 테이블 서비스에 대해 공유 키 및 Shared Key Lite를 지원하고, 2009-09-19 버전 이상의 Blob 및 큐 서비스에 대해 Shared Key Lite를 지원하는 형식. 이 형식은 이전 버전의 저장소 서비스에 사용된 것과 동일합니다.

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

중요

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

참고

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

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

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

빈 문자열("")로 시작해서 슬래시를 추가하고, 액세스 중인 리소스를 소유하는 계정의 이름을 추가합니다.
쿼리 매개 변수 없이 리소스의 인코딩된 URI 경로를 추가합니다.
comp 매개 변수를 포함하여(있는 경우) 리소스 URI에서 모든 쿼리 매개 변수를 검색합니다.
모든 매개 변수 이름을 소문자로 변환합니다.
매개 변수 이름에 따라 오름차순으로 쿼리 매개 변수를 정렬합니다.
각 쿼리 매개 변수 이름 및 값에 대해 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 이상에 대한 공유 키 라이트 및 테이블 서비스 형식

이 형식은 모든 버전의 테이블 서비스에 대해 공유 키 및 Shared Key Lite를 지원하고, 2009-09-19 이상 버전의 Blob 및 큐 서비스와 2014-02-14 이상 버전의 파일 서비스에 대해 Shared Key Lite를 지원합니다. 이 형식은 이전 버전의 저장소 서비스에 사용된 것과 동일합니다. 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>)))

다음을 통해 공유