Otorisasi dengan Kunci Bersama
Setiap permintaan yang dibuat terhadap layanan penyimpanan harus diotorisasi, kecuali permintaannya adalah untuk sumber daya blob atau kontainer yang telah tersedia untuk akses publik atau ditandatangani. Salah satu opsi untuk mengotorisasi permintaan adalah dengan menggunakan Kunci Bersama, yang dijelaskan dalam artikel ini.
Penting
Untuk keamanan optimal, Microsoft merekomendasikan penggunaan Microsoft Entra ID dengan identitas terkelola untuk mengotorisasi permintaan terhadap data blob, antrean, dan tabel, jika memungkinkan. Otorisasi dengan Microsoft Entra ID dan identitas terkelola memberikan keamanan yang unggul dan kemudahan penggunaan melalui otorisasi Kunci Bersama. Untuk mempelajari selengkapnya, lihat Mengotorisasi dengan Microsoft Entra ID. Untuk mempelajari selengkapnya tentang identitas terkelola, lihat Apa itu identitas terkelola untuk sumber daya Azure.
Untuk sumber daya yang dihosting di luar Azure, seperti aplikasi lokal, Anda dapat menggunakan identitas terkelola melalui Azure Arc. Misalnya, aplikasi yang berjalan di server dengan dukungan Azure Arc dapat menggunakan identitas terkelola untuk menyambungkan ke layanan Azure. Untuk mempelajari selengkapnya, lihat Mengautentikasi terhadap sumber daya Azure dengan server yang didukung Azure Arc.
Untuk skenario di mana tanda tangan akses bersama (SAS) digunakan, Microsoft merekomendasikan penggunaan SAS delegasi pengguna. SAS delegasi pengguna diamankan dengan kredensial Microsoft Entra alih-alih kunci akun. Untuk mempelajari tentang tanda tangan akses bersama, lihat Create SAS delegasi pengguna.
Layanan Blob, Antrean, Tabel, dan File mendukung skema otorisasi Kunci Bersama berikut untuk versi 2009-09-19 dan yang lebih baru (untuk layanan Blob, Antrean, dan Tabel) dan versi 2014-02-14 dan yang lebih baru (untuk layanan File):
Kunci Bersama untuk Blob, Antrean, dan Layanan File. Gunakan skema otorisasi Kunci Bersama untuk membuat permintaan terhadap layanan Blob, Antrean, dan File. Otorisasi Kunci Bersama dalam versi 2009-09-19 dan yang lebih baru mendukung string tanda tangan tambahan untuk keamanan yang ditingkatkan dan mengharuskan Anda memperbarui layanan Anda untuk mengotorisasi menggunakan tanda tangan tambahan ini.
Kunci Bersama untuk Layanan Tabel. Gunakan skema otorisasi Kunci Bersama untuk membuat permintaan terhadap layanan Table menggunakan REST API. Otorisasi Kunci Bersama untuk layanan Table dalam versi 2009-09-19 dan yang lebih baru menggunakan string tanda tangan yang sama seperti pada versi layanan Tabel sebelumnya.
Shared Key Lite. Gunakan skema otorisasi Shared Key Lite untuk membuat permintaan terhadap layanan Blob, Queue, Table, dan File.
Untuk layanan Blob dan Antrean versi 2009-09-19 dan yang lebih baru, otorisasi Shared Key Lite mendukung penggunaan string tanda tangan yang identik dengan apa yang didukung terhadap Kunci Bersama di versi layanan Blob dan Antrean sebelumnya. Oleh karena itu, Anda dapat menggunakan Shared Key Lite untuk membuat permintaan terhadap layanan Blob dan Antrean tanpa memperbarui string tanda tangan Anda.
Permintaan yang diotorisasi memerlukan dua header: Date header atau x-ms-date dan Authorization header . Bagian berikut menjelaskan cara membuat header ini.
Penting
Azure Storage mendukung HTTP dan HTTPS, tetapi menggunakan HTTPS sangat disarankan.
Catatan
Kontainer atau blob dapat disediakan untuk akses publik dengan mengatur izin kontainer. Untuk informasi selengkapnya, lihat Mengelola Akses ke Sumber Daya Azure Storage. Kontainer, blob, antrean, atau tabel dapat disediakan untuk akses yang ditandatangani melalui tanda tangan akses bersama; tanda tangan akses bersama diotorisasi melalui mekanisme yang berbeda. Lihat Mendelegasikan akses dengan tanda tangan akses bersama untuk detail selengkapnya.
Menentukan header Tanggal
Semua permintaan yang diotorisasi harus menyertakan tanda waktu Waktu Universal Terkoordinasi (UTC) untuk permintaan tersebut. Anda dapat menentukan tanda waktu baik di x-ms-date header, atau di header HTTP/HTTPS Date standar. Jika kedua header ditentukan pada permintaan, nilai x-ms-date digunakan sebagai waktu pembuatan permintaan.
Layanan penyimpanan memastikan bahwa permintaan tidak lebih dari 15 menit pada saat mencapai layanan. Ini melindungi dari serangan keamanan tertentu, termasuk serangan pemutaran ulang. Ketika pemeriksaan ini gagal, server mengembalikan kode respons 403 (Terlarang).
Catatan
Header x-ms-date disediakan karena beberapa pustaka klien HTTP dan proksi secara otomatis mengatur Date header, dan tidak memberi pengembang kesempatan untuk membaca nilainya untuk menyertakannya dalam permintaan yang diotorisasi. Jika Anda mengatur x-ms-date, buat tanda tangan dengan nilai kosong untuk Date header .
Menentukan header Otorisasi
Permintaan yang diotorisasi harus menyertakan Authorization header . Jika header ini tidak disertakan, permintaan bersifat anonim dan hanya berhasil terhadap kontainer atau blob yang ditandai untuk akses publik, atau terhadap kontainer, blob, antrean, atau tabel yang tanda tangan akses bersamanya telah disediakan untuk akses yang didelegasikan.
Untuk mengotorisasi permintaan, Anda harus menandatangani permintaan dengan kunci untuk akun yang membuat permintaan dan meneruskan tanda tangan tersebut sebagai bagian dari permintaan.
Format untuk Authorization header adalah sebagai berikut:
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
di mana SharedKey atau SharedKeyLite adalah nama skema otorisasi, AccountName adalah nama akun yang meminta sumber daya, dan Signature merupakan Kode Autentikasi Pesan berbasis Hash (HMAC) yang dibangun dari permintaan dan dihitung dengan menggunakan algoritma SHA256, lalu dikodekan dengan menggunakan pengodean Base64.
Catatan
Dimungkinkan untuk meminta sumber daya yang berada di bawah akun yang berbeda, jika sumber daya tersebut dapat diakses publik.
Bagian berikut menjelaskan cara membuat Authorization header.
Membuat string tanda tangan
Cara Anda membuat string tanda tangan tergantung pada layanan dan versi mana yang Anda otorisasi dan skema otorisasi mana yang Anda gunakan. Saat membuat string tanda tangan, ingatlah hal berikut:
Bagian KATA KERJA dari string adalah kata kerja HTTP, seperti GET atau PUT, dan harus huruf besar.
Untuk otorisasi Kunci Bersama untuk layanan Blob, Antrean, dan File, setiap header yang disertakan dalam string tanda tangan hanya dapat muncul sekali. Jika ada header yang diduplikasi, layanan mengembalikan kode status 400 (Permintaan Buruk).
Nilai semua header HTTP standar harus disertakan dalam string dalam urutan yang diperlihatkan dalam format tanda tangan, tanpa nama header. Header ini dapat kosong jika tidak ditentukan sebagai bagian dari permintaan; dalam hal ini, hanya karakter baris baru yang diperlukan.
x-ms-dateJika header ditentukan, Anda dapat mengabaikanDateheader, terlepas dari apakah header ditentukan pada permintaan, dan cukup tentukan baris kosong untukDatebagian string tanda tangan. Dalam hal ini, ikuti instruksi di bagian Membuat string header kanonis untuk menambahkanx-ms-dateheader.Dapat diterima untuk menentukan dan
x-ms-dateDate; dalam hal ini, layanan menggunakan nilaix-ms-date.x-ms-dateJika header tidak ditentukan, tentukanDateheader dalam string tanda tangan, tanpa menyertakan nama header.Semua karakter baris baru (\n) yang ditampilkan diperlukan dalam string tanda tangan.
String tanda tangan mencakup header kanonis dan string sumber daya kanonis. Canonicalizing string ini menempatkannya ke dalam format standar yang dikenali oleh Azure Storage. Untuk informasi terperinci tentang membangun
CanonicalizedHeadersstring danCanonicalizedResourceyang membentuk bagian dari string tanda tangan, lihat bagian yang sesuai nanti dalam topik ini.
Blob, Antrean, dan Layanan File (otorisasi Kunci Bersama)
Untuk mengodekan string tanda tangan Kunci Bersama untuk permintaan terhadap versi 2009-09-19 dan yang lebih baru dari layanan Blob atau Antrean, dan versi 2014-02-14 dan yang lebih baru dari layanan File, gunakan format berikut:
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;
Penting
Dalam versi saat ini, bidang Content-Length harus berupa string kosong jika panjang konten permintaan adalah nol. Dalam versi 2014-02-14 dan yang lebih lama, panjang konten disertakan bahkan jika nol. Lihat di bawah ini untuk informasi selengkapnya tentang perilaku lama.
Contoh berikut menunjukkan string tanda tangan untuk operasi Dapatkan Blob . Jika tidak ada nilai header, karakter baris baru hanya ditentukan.
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
Memecah baris demi baris ini menunjukkan setiap bagian dari string yang sama:
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*/
Selanjutnya, kodekan string ini dengan menggunakan algoritma HMAC-SHA256 melalui string tanda tangan yang dikodekan UTF-8, buat Authorization header, dan tambahkan header ke permintaan. Contoh berikut menunjukkan Authorization header untuk operasi yang sama:
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Untuk menggunakan otorisasi Kunci Bersama dengan versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, Anda harus memperbarui kode Anda untuk menggunakan string tanda tangan tambahan ini.
Jika Anda lebih suka memigrasikan kode Anda ke versi 2009-09-19 atau yang lebih baru dari layanan Blob dan Antrean dengan perubahan sesingkat Authorization mungkin, Anda dapat memodifikasi header yang ada untuk menggunakan Shared Key Lite alih-alih Kunci Bersama. Format tanda tangan yang diperlukan oleh Shared Key Lite identik dengan yang diperlukan untuk Kunci Bersama berdasarkan versi layanan Blob dan Antrean sebelum 2009-09-19.
Penting
Jika Anda mengakses lokasi sekunder di akun penyimpanan tempat replikasi geografis akses baca (RA-GRS) diaktifkan, jangan sertakan penandaan -secondary di header otorisasi. Untuk tujuan otorisasi, nama akun selalu merupakan nama lokasi utama, bahkan untuk akses sekunder.
Header Content-Length dalam versi 2014-02-14 dan yang lebih lama
Saat menggunakan versi 2014-02-14 atau yang lebih lama, jika Content-Length adalah nol, maka atur Content-Length bagian dari StringToSign ke 0. Biasanya ini akan menjadi string kosong.
Misalnya, untuk permintaan berikut, nilai Content-Length header disertakan dalam StringToSign bahkan ketika nol.
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 dibangun sebagai berikut:
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
Sedangkan dalam versi setelah 2014-02-14, StringToSign harus berisi string kosong untuk 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
Layanan tabel (otorisasi Kunci Bersama)
Anda harus menggunakan otorisasi Kunci Bersama untuk mengotorisasi permintaan yang dibuat terhadap layanan Table jika layanan Anda menggunakan REST API untuk membuat permintaan. Format string tanda tangan untuk Kunci Bersama terhadap layanan Table sama untuk semua versi.
String tanda tangan Kunci Bersama untuk permintaan terhadap layanan Table sedikit berbeda dari itu untuk permintaan terhadap layanan Blob atau Antrean, karena tidak menyertakan CanonicalizedHeaders bagian string. Selain itu, Date header dalam hal ini tidak pernah kosong meskipun permintaan mengatur x-ms-date header. Jika permintaan menetapkan x-ms-date, nilai tersebut juga digunakan untuk nilai Date header.
Untuk mengodekan string tanda tangan untuk permintaan terhadap layanan Table yang dibuat menggunakan REST API, gunakan format berikut:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
Catatan
Dimulai dengan versi 2009-09-19, layanan Tabel mengharuskan semua panggilan REST menyertakan DataServiceVersion header dan MaxDataServiceVersion . Lihat Mengatur Header Versi Layanan Data OData untuk informasi selengkapnya.
Layanan Blob, Antrean, dan File (otorisasi Shared Key Lite)
Anda dapat menggunakan otorisasi Shared Key Lite untuk mengotorisasi permintaan yang dibuat terhadap versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, dan versi 2014-02-14 dan yang lebih baru dari layanan File.
String tanda tangan untuk Shared Key Lite identik dengan string tanda tangan yang diperlukan untuk otorisasi Kunci Bersama dalam versi layanan Blob dan Antrean sebelum 2009-09-19. Jadi, jika Anda ingin memigrasikan kode Anda dengan jumlah perubahan paling sedikit pada versi 2009-09-19 dari layanan Blob dan Antrean, Anda dapat memodifikasi kode Anda untuk menggunakan Shared Key Lite, tanpa mengubah string tanda tangan itu sendiri. Dengan menggunakan Shared Key Lite, Anda tidak akan mendapatkan fungsionalitas keamanan yang ditingkatkan yang disediakan dengan menggunakan Kunci Bersama dengan versi 2009-09-19 dan yang lebih baru.
Untuk mengodekan string tanda tangan untuk permintaan terhadap layanan Blob atau Antrean, gunakan format berikut:
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
Contoh berikut menunjukkan string tanda tangan untuk operasi Put Blob . Perhatikan bahwa baris header Content-MD5 kosong. Header yang ditampilkan dalam string adalah pasangan nama-nilai yang menentukan nilai metadata kustom untuk blob baru.
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
Selanjutnya, kodekan string ini dengan menggunakan algoritma HMAC-SHA256 melalui string tanda tangan yang dikodekan UTF-8, buat Authorization header, dan tambahkan header ke permintaan. Contoh berikut menunjukkan Authorization header untuk operasi yang sama:
Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
Layanan tabel (otorisasi Shared Key Lite)
Anda dapat menggunakan otorisasi Shared Key Lite untuk mengotorisasi permintaan yang dibuat terhadap versi layanan Tabel apa pun.
Untuk mengodekan string tanda tangan untuk permintaan terhadap layanan Table menggunakan Shared Key Lite, gunakan format berikut:
StringToSign = Date + "\n"
CanonicalizedResource
Contoh berikut menunjukkan string tanda tangan untuk operasi tabel Create.
Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables
Selanjutnya, kodekan string ini dengan menggunakan algoritma HMAC-SHA256, buat Authorization header, lalu tambahkan header ke permintaan. Contoh berikut menunjukkan Authorization header untuk operasi yang sama:
Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=
Membuat string header kanonis
Untuk membuat CanonicalizedHeaders bagian string tanda tangan, ikuti langkah-langkah berikut:
Ambil semua header untuk sumber daya yang dimulai dengan
x-ms-, termasukx-ms-dateheader .Konversikan setiap nama header HTTP menjadi huruf kecil.
Urutkan header secara leksikografis menurut nama header, dalam urutan naik. Setiap header hanya dapat muncul sekali dalam string.
Catatan
Urutan leksikografis mungkin tidak selalu bertepatan dengan urutan alfabet konvensional.
Ganti spasi kosong linier apa pun di nilai header dengan spasi tunggal.
Spasi kosong linier mencakup pengembalian pengangkutan/umpan baris (CRLF), spasi, dan tab. Lihat RFC 2616, bagian 4.2 untuk detailnya. Jangan ganti spasi kosong apa pun di dalam string yang dikutip.
Pangkas spasi kosong apa pun di sekitar titik dua di header.
Terakhir, tambahkan karakter baris baru ke setiap header kanonis dalam daftar yang dihasilkan. Buat
CanonicalizedHeadersstring dengan menggabungkan semua header dalam daftar ini menjadi satu string.
Berikut ini memperlihatkan contoh string header kanonis:
x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n
Catatan
Sebelum versi layanan 2016-05-31, header dengan nilai kosong dihilangkan dari string tanda tangan. Ini sekarang diwakili dalam CanonicalizedHeaders dengan segera mengikuti karakter titik dua dengan baris baru yang mengakhiri.
Membangun string sumber daya kanonis
Bagian CanonicalizedResource dari string tanda tangan mewakili sumber daya layanan penyimpanan yang ditargetkan oleh permintaan. Bagian apa pun dari CanonicalizedResource string yang berasal dari URI sumber daya harus dikodekan persis seperti dalam URI.
Ada dua format yang didukung untuk CanonicalizedResource string:
Format yang mendukung otorisasi Kunci Bersama untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, dan untuk versi 2014-02-14 dan yang lebih baru dari layanan File.
Format yang mendukung Kunci Bersama dan Shared Key Lite untuk semua versi layanan Table, dan Shared Key Lite untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean. Format ini identik dengan yang digunakan dengan versi layanan penyimpanan sebelumnya.
Untuk bantuan membuat URI untuk sumber daya yang Anda akses, lihat salah satu topik berikut:
Layanan blob: Penamaan dan Referensi Kontainer, Blob, dan Metadata
Layanan antrean: Mengatasi Sumber Daya Layanan Antrean
Layanan tabel: Mengatasi Sumber Daya Layanan Tabel
Layanan file: Penamaan dan Referensi Berbagi, Direktori, File, dan Metadata
Penting
Jika akun penyimpanan Anda direplikasi dengan replikasi geografis akses baca (RA-GRS), dan Anda mengakses sumber daya di lokasi sekunder, jangan sertakan –secondary penunjukan dalam CanonicalizedResource string. URI sumber daya yang CanonicalizedResource digunakan dalam URI string harus menjadi URI sumber daya di lokasi utama.
Catatan
Jika Anda mengotorisasi terhadap emulator penyimpanan, nama akun akan muncul dua kali dalam CanonicalizedResource string. Ini yang diharapkan. Jika Anda mengotorisasi terhadap layanan penyimpanan Azure, nama akun hanya akan muncul satu kali dalam CanonicalizedResource string.
Format Kunci Bersama untuk 2009-09-19 dan yang lebih baru
Format ini mendukung otorisasi Kunci Bersama untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean, dan versi 2014-02-14 dan yang lebih baru dari layanan File. Buat CanonicalizedResource string dalam format ini sebagai berikut:
Dimulai dengan string kosong (""), tambahkan garis miring (/), diikuti dengan nama akun yang memiliki sumber daya yang diakses.
Tambahkan jalur URI yang dikodekan sumber daya, tanpa parameter kueri apa pun.
Ambil semua parameter kueri pada URI sumber daya, termasuk
compparameter jika ada.Konversikan semua nama parameter menjadi huruf kecil.
Urutkan parameter kueri secara leksikografis menurut nama parameter, dalam urutan naik.
URL-decode setiap nama dan nilai parameter kueri.
Sertakan karakter baris baru (\n) sebelum setiap pasangan nama-nilai.
Tambahkan setiap nama parameter kueri dan nilai ke string dalam format berikut, pastikan untuk menyertakan titik dua (:) antara nama dan nilai:
parameter-name:parameter-valueJika parameter kueri memiliki lebih dari satu nilai, urutkan semua nilai secara leksikografis, lalu sertakan dalam daftar yang dipisahkan koma:
parameter-name:parameter-value-1,parameter-value-2,parameter-value-n
Perlu diingat aturan berikut untuk membuat string sumber daya kanonis:
Hindari menggunakan karakter baris baru (\n) dalam nilai untuk parameter kueri. Jika harus digunakan, pastikan bahwa itu tidak memengaruhi format string sumber daya kanonis.
Hindari menggunakan koma dalam nilai parameter kueri.
Berikut adalah beberapa contoh yang menunjukkan CanonicalizedResource bagian string tanda tangan, karena dapat dibangun dari URI permintaan tertentu:
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
Format layanan Shared Key Lite dan Table untuk 2009-09-19 dan yang lebih baru
Format ini mendukung Kunci Bersama dan Kunci Bersama Lite untuk semua versi layanan Tabel, dan Shared Key Lite untuk versi 2009-09-19 dan yang lebih baru dari layanan Blob dan Antrean dan versi 2014-02-14 dan yang lebih baru dari layanan File. Format ini identik dengan yang digunakan dengan versi layanan penyimpanan sebelumnya. Buat CanonicalizedResource string dalam format ini sebagai berikut:
Dimulai dengan string kosong (""), tambahkan garis miring (/), diikuti dengan nama akun yang memiliki sumber daya yang diakses.
Tambahkan jalur URI yang dikodekan sumber daya. Jika URI permintaan membahas komponen sumber daya, tambahkan string kueri yang sesuai. String kueri harus menyertakan tanda tanya dan
compparameter (misalnya,?comp=metadata). Tidak ada parameter lain yang harus disertakan pada string kueri.
Mengodekan tanda tangan
Untuk mengodekan tanda tangan, panggil algoritma HMAC-SHA256 pada string tanda tangan yang dikodekan UTF-8 dan enkode hasilnya sebagai Base64. Perhatikan bahwa Anda juga perlu mendekode Base64 kunci akun penyimpanan Anda. Gunakan format berikut (ditampilkan sebagai pseudocode):
Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))