Berikan akses terbatas ke sumber daya Azure Storage menggunakan tanda tangan akses bersama (SAS)

Artikel
06/07/2023

Tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan dan aman ke sumber daya di akun penyimpanan Anda. Dengan SAS, Anda memiliki kontrol terperinci atas bagaimana klien dapat mengakses data Anda. Contohnya:

Sumber daya apa yang dapat diakses klien.
Izin apa yang mereka miliki untuk sumber daya tersebut.
Berapa lama SAS berlaku.

Jenis tanda tangan akses bersama

Azure Storage mendukung tiga jenis tanda tangan akses bersama:

Delegasi pengguna SAS
Layanan SAS
Akun SAS

Penting

Untuk skenario di mana tanda tangan akses bersama digunakan, Microsoft merekomendasikan penggunaan SAS delegasi pengguna. SAS delegasi pengguna diamankan dengan kredensial Microsoft Entra alih-alih kunci akun, yang memberikan keamanan yang unggul. Untuk informasi selengkapnya tentang otorisasi untuk akses data, lihat Mengotorisasi akses ke data di Azure Storage.

Delegasi pengguna SAS

SAS delegasi pengguna diamankan dengan kredensial Microsoft Entra dan juga oleh izin yang ditentukan untuk SAS. Delegasi pengguna SAS hanya berlaku untuk penyimpanan Blob saja.

Untuk informasi selengkapnya tentang delegasi pengguna SAS, lihat Membuat delegasi pengguna SAS (REST API).

Layanan SAS

SAS layanan diamankan menggunakan kunci akun penyimpanan. Layanan SAS delegasi akses ke sumber daya hanya di salah satu layanan Azure Storage: penyimpanan Blob, penyimpanan antrean, penyimpanan Tabel, atau Azure Files.

Untuk informasi selengkapnya tentang layanan SAS, lihat Membuat layanan SAS (REST API).

Akun SAS

SAS akun diamankan dengan kunci akun penyimpanan. Akun SAS delegasikan akses ke sumber daya di satu atau beberapa layanan penyimpanan. Semua operasi yang tersedia melalui layanan atau delegasi pengguna SAS juga tersedia melalui akun SAS.

Anda juga dapat mendelegasikan akses ke yang berikut:

Operasi tingkat layanan (Misalnya, Properti Layanan Get/Set dan operasi Get Statistik Layanan).
Baca, tulis, dan hapus operasi yang tidak diizinkan dengan layanan SAS.

Untuk informasi lebih lanjut tentang akun SAS, Buat akun SAS (REST API).

Tanda tangan akses bersama bisa mengambil salah satu dari dua formulir berikut:

Ad hoc SAS. Saat Anda membuat ad hoc SAS, waktu mulai, waktu kedaluwarsa, dan izin ditentukan dalam URI SAS. Semua jenis SAS bisa menjadi ad hoc SAS.
Layanan SAS dengan kebijakan akses tersimpan. Kebijakan akses tersimpan didefinisikan pada kontainer sumber daya, yang dapat menjadi kontainer blob, tabel, antrean, atau berbagi file. Kebijakan akses tersimpan dapat digunakan untuk mengelola batasan untuk satu atau beberapa tanda tangan akses bersama layanan. Ketika Anda mengaitkan layanan SAS dengan kebijakan akses yang tersimpan, SAS mewarisi batasan, yaitu waktu mulai, waktu berakhir, dan izin yang ditentukan untuk kebijakan akses yang tersimpan.

Catatan

Delegasi pengguna SAS atau akun SAS harus menjadi ad hoc SAS. Kebijakan akses tersimpan tidak didukung untuk delegasi pengguna SAS atau akun SAS.

Cara kerja tanda tangan akses bersama

Tanda tangan akses bersama adalah token yang ditambahkan ke URI untuk sumber daya Azure Storage. Token yang berisi sekumpulan parameter kueri khusus yang menunjukkan bagaimana sumber daya dapat diakses oleh klien. Salah satu parameter kueri, tanda tangan, dibangun dari parameter SAS dan ditandatangani dengan kunci yang digunakan untuk membuat SAS. Tanda tangan ini digunakan oleh Azure Storage untuk mengotorisasi akses ke sumber daya penyimpanan.

Catatan

Tidak mungkin untuk mengaudit pembuatan token SAS. Setiap pengguna yang memiliki hak istimewa untuk membuat token SAS, baik dengan menggunakan kunci akun, atau melalui penetapan peran Azure, dapat melakukannya tanpa sepengetahuan pemilik akun penyimpanan. Berhati-hatilah untuk membatasi izin yang memungkinkan pengguna untuk membuat token SAS. Untuk mencegah pengguna membuat SAS yang ditandatangani dengan kunci akun untuk beban kerja blob dan antrean, Anda dapat melarang akses Kunci Bersama ke akun penyimpanan. Untuk informasi selengkapnya, lihat Mencegah otorisasi dengan Kunci Bersama.

Tanda tangan dan otorisasi SAS

Anda dapat menandatangani token SAS dengan kunci delegasi pengguna atau dengan kunci akun penyimpanan (Kunci Bersama).

Menandatangani token SAS dengan kunci delegasi pengguna

Anda dapat menandatangani token SAS dengan menggunakan kunci delegasi pengguna yang dibuat menggunakan kredensial Microsoft Entra. Delegasi pengguna SAS ditandatangani dengan kunci delegasi pengguna.

Untuk mendapatkan kunci, lalu membuat SAS, perwakilan keamanan Microsoft Entra harus diberi peran Azure yang menyertakan tindakan.Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey Untuk informasi selengkapnya, lihat Membuat delegasi pengguna SAS (REST API).

Menandatangani token SAS dengan kunci akun

SAS layanan dan SAS akun ditandatangani dengan kunci akun penyimpanan. Untuk membuat SAS yang ditandatangani dengan kunci akun, aplikasi harus memiliki akses ke kunci akun.

Ketika permintaan menyertakan token SAS, permintaan tersebut diotorisasi berdasarkan bagaimana token SAS ditandatangani. Kunci akses atau kredensial yang Anda gunakan untuk membuat token SAS juga digunakan oleh Azure Storage untuk memberikan akses ke klien yang memiliki SAS.

Tabel berikut ini meringkas bagaimana setiap jenis token SAS diotorisasi.

Jenis SAS	Jenis otorisasi
Delegasi pengguna SAS (hanya penyimpanan Blob)	Microsoft Entra ID
Layanan SAS	Kunci Bersama
Akun SAS	Kunci Bersama

Microsoft merekomendasikan menggunakan delegasi pengguna SAS jika memungkinkan untuk keamanan yang unggul.

Token SAS

Token SAS adalah untai yang Anda buat di sisi klien, misalnya dengan menggunakan salah satu pustaka klien Azure Storage. Token SAS tidak dilacak oleh Azure Storage dengan cara apa pun. Anda dapat membuat token SAS dalam jumlah tak terbatas di sisi klien. Setelah membuat SAS, Anda dapat mendistribusikannya ke aplikasi klien yang memerlukan akses ke sumber daya di akun penyimpanan Anda.

Aplikasi klien menyediakan URI SAS ke Azure Storage sebagai bagian dari permintaan. Kemudian, layanan memeriksa parameter SAS dan tanda tangan untuk memverifikasi bahwa itu berlaku. Jika layanan memverifikasi bahwa tanda tangan berlaku, maka permintaan diotorisasi. Jika tidak, permintaan ditolak dengan kode kesalahan 403 (Terlarang).

Berikut adalah contoh layanan SAS URI, memperlihatkan URI sumber daya, karakter pemisah ('?'), dan token SAS.

Diagram memperlihatkan komponen URI sumber daya dengan token SAS.

Catatan

Karakter pemisah ('?') untuk string kueri bukan bagian dari token SAS. Jika Anda membuat token SAS dari portal, PowerShell, Azure CLI, atau salah satu SDK Azure Storage, Anda mungkin perlu menambahkan karakter pemisah ke URL sumber daya.

Kapan saatnya menggunakan tanda tangan akses bersama

Gunakan SAS untuk memberikan akses aman ke sumber daya di akun penyimpanan Anda kepada klien mana pun yang tidak memiliki izin ke sumber daya tersebut.

Skenario umum di mana SAS berguna adalah layanan di mana pengguna membaca dan menulis data mereka sendiri ke akun penyimpanan Anda. Dalam skenario di mana akun penyimpanan menyimpan data pengguna, ada dua pola desain yang khas:

Klien mengunggah dan mengunduh data melalui layanan proksi front-end, yang melakukan autentikasi. Layanan proksi front-end ini memungkinkan validasi aturan bisnis. Tetapi untuk data dalam jumlah besar, atau transaksi volume tinggi, membuat layanan yang dapat menskalakan untuk mencocokkan permintaan mungkin mahal atau sulit.
Layanan ringan mengautentikasi klien sesuai kebutuhan dan kemudian membuat SAS. Setelah aplikasi klien menerima SAS, ia dapat mengakses sumber daya akun penyimpanan secara langsung. Izin akses ditentukan oleh SAS dan untuk interval yang diizinkan oleh SAS. SAS mengurangi kebutuhan untuk merutekan semua data melalui layanan proksi front-end.

Banyak layanan dunia nyata dapat menggunakan hibrida dari dua pendekatan ini. Misalnya, beberapa data mungkin diproses dan divalidasi melalui proksi front-end. Data lain disimpan dan/atau dibaca langsung menggunakan SAS.

Selain itu, SAS diperlukan untuk mengotorisasi akses ke objek sumber dalam operasi salinan dalam skenario tertentu:

Saat Anda menyalin blob ke blob lain yang berada di akun penyimpanan yang berbeda.

Anda dapat secara opsional menggunakan SAS untuk mengotorisasi akses ke blob tujuan juga.
Saat Anda menyalin file ke file lain yang berada di akun penyimpanan yang berbeda.

Anda dapat secara opsional menggunakan SAS untuk mengotorisasi akses ke file tujuan juga.
Saat Anda menyalin blob ke file, atau file ke blob.

Anda harus menggunakan SAS meskipun objek sumber dan tujuan berada dalam akun penyimpanan yang sama.

Praktik terbaik saat menggunakan SAS

Saat Anda menggunakan shared access signatures di aplikasi, Anda perlu mengetahui dua risiko potensial:

Jika SAS bocor, SAS dapat digunakan oleh siapa saja yang mendapatkannya, yang berpotensi membahayakan akun penyimpanan Anda.
Jika SAS yang disediakan untuk aplikasi klien kedaluwarsa dan aplikasi tidak dapat mengambil SAS baru dari layanan Anda, maka fungsionalitas aplikasi dapat terhambat.

Rekomendasi berikut untuk menggunakan shared access signatures dapat membantu mengurangi risiko ini:

Selalu gunakan HTTPS untuk membuat atau mendistribusikan SAS. Jika SAS dilewatkan melalui HTTP dan dicegat, penyerang yang melakukan serangan man-in-the-middle dapat membaca SAS. Kemudian, mereka dapat menggunakan SAS seperti yang bisa dilakukan pengguna yang dimaksud. Ini dapat berpotensi membahayakan data sensitif atau memungkinkan kerusakan data oleh pengguna berbahaya.
Gunakan delegasi pengguna SAS jika memungkinkan. Delegasi pengguna SAS memberikan keamanan yang unggul untuk layanan SAS atau akun SAS. SAS delegasi pengguna diamankan dengan kredensial Microsoft Entra, sehingga Anda tidak perlu menyimpan kunci akun dengan kode Anda.
Memiliki rencana pencabutan di tempat untuk SAS. Pastikan Anda siap untuk menanggapi jika SAS dikompromikan.
Konfigurasikan kebijakan kedaluwarsa SAS untuk akun penyimpanan. Kebijakan kedaluwarsa SAS menentukan interval yang disarankan di mana SAS valid. Kebijakan kedaluwarsa SAS berlaku untuk SAS layanan atau akun SAS. Ketika pengguna menghasilkan SAS layanan atau akun SAS dengan interval validitas yang lebih besar dari interval yang disarankan, mereka akan melihat peringatan. Jika pengelogan Azure Storage dengan Azure Monitor diaktifkan, maka entri ditulis ke log Azure Storage. Untuk mempelajari selengkapnya, lihat Membuat kebijakan kedaluwarsa untuk tanda tangan akses bersama.
Buat kebijakan akses tersimpan untuk LAYANAN SAS. Kebijakan akses tersimpan memberi Anda opsi untuk mencabut izin untuk layanan SAS tanpa harus membuat ulang kunci akun penyimpanan. Atur kedaluwarsa pada ini sangat jauh di masa depan (atau tak terbatas) dan pastikan itu secara teratur diperbarui untuk memindahkannya lebih jauh ke masa depan. Ada batas lima kebijakan akses tersimpan per kontainer.
Gunakan waktu kedaluwarsa jangka pendek pada layanan SAS ad hoc SAS atau akun SAS. Dengan cara ini, bahkan jika SAS dikompromikan, itu hanya berlaku untuk waktu yang singkat. Praktik ini sangat penting jika Anda tidak dapat mereferensikan kebijakan akses yang tersimpan. Waktu kedaluwarsa jangka pendek juga membatasi jumlah data yang dapat ditulis ke blob dengan membatasi waktu yang tersedia untuk mengunggahnya.
Minta klien untuk memperbarui SAS secara otomatis jika perlu. Klien harus memperbarui SAS jauh sebelum kedaluwarsa, untuk memberikan waktu untuk mencoba lagi jika layanan yang menyediakan SAS tidak tersedia. Ini mungkin tidak perlu dalam beberapa kasus. Misalnya, Anda mungkin berniat agar SAS digunakan untuk sejumlah kecil operasi langsung dan berumur pendek. Operasi ini diharapkan selesai dalam jangka waktu kedaluwarsa. Akibatnya, Anda tidak mengharapkan SAS diperbarui. Namun, jika Anda memiliki klien yang secara rutin membuat permintaan melalui SAS, maka kemungkinan kedaluwarsa mulai berlaku.
Hati-hati dengan waktu mulai SAS. Jika Anda mengatur waktu mulai untuk SAS ke waktu saat ini, kegagalan mungkin terjadi sewaktu-waktu selama beberapa menit pertama. Ini karena komputer yang berbeda memiliki waktu saat ini yang sedikit berbeda (dikenal sebagai condong jam). Secara umum, setel waktu mulai setidaknya 15 menit sebelumnya. Atau, jangan mengaturnya sama sekali, yang akan membuatnya langsung berlaku di semua kasus. Hal yang sama umumnya berlaku untuk waktu kedaluwarsa juga--ingat bahwa Anda dapat mengamati hingga 15 menit jam condong di kedua arah pada permintaan apa pun. Untuk klien yang menggunakan versi REST sebelum 2012-02-12, durasi maksimum untuk SAS yang tidak mereferensikan kebijakan akses yang disimpan adalah 1 jam. Setiap kebijakan yang menentukan jangka panjang dari 1 jam akan gagal.
Hati-hati dengan format tanggalwaktu SAS. Untuk beberapa utilitas (seperti AzCopy), nilai tanggal/waktu harus diformat sebagai '+%Y-%m-%dT%H:%M:%SZ'. Format ini secara khusus mencakup detik.
Berikan hak istimewa sekecil mungkin dengan SAS. Praktik terbaik keamanan adalah memberi pengguna hak istimewa minimum yang diperlukan ke sumber daya sekecil mungkin. Gunakan SAS baca-saja jika memungkinkan. Jika pengguna hanya memerlukan akses baca ke satu objek, beri mereka akses baca ke satu objek tersebut, dan bukan akses baca/tulis/hapus ke semua objek. Ini juga membantu mengurangi kerusakan jika SAS dikompromikan karena SAS memiliki lebih sedikit kekuatan di tangan penyerang.

Tidak ada cara langsung untuk mengidentifikasi klien mana yang telah mengakses sumber daya. Namun, Anda dapat menggunakan bidang unik di bidang SAS, IP yang ditandatangani (sip), awal yang ditandatangani (st), dan kedaluwarsa yang ditandatangani (se), untuk melacak akses. Misalnya, Anda dapat menghasilkan token SAS dengan waktu kedaluwarsa unik yang kemudian dapat Anda korelasikan dengan klien yang dikeluarkan.
Pahami bahwa akun Anda akan ditagih untuk penggunaan apa pun, termasuk melalui SAS. Jika Anda memberikan akses tulis ke blob, pengguna dapat memilih untuk mengunggah blob 200 GB. Jika Anda telah memberi mereka akses baca juga, mereka dapat memilih untuk mengunduhnya 10 kali, dikenakan biaya keluar 2 TB untuk Anda. Sekali lagi, berikan izin terbatas untuk membantu mengurangi potensi tindakan pengguna jahat. Gunakan SAS berumur pendek untuk mengurangi ancaman ini (tetapi berhati-hatilah dengan condongnya jam pada waktu akhir).
Validasi data yang ditulis menggunakan SAS. Ketika aplikasi klien menulis data ke akun penyimpanan Anda, perlu diingat bahwa mungkin ada masalah dengan data tersebut. Jika Anda berencana untuk memvalidasi data, lakukan validasi tersebut setelah data ditulis dan sebelum digunakan oleh aplikasi Anda. Praktik ini juga melindungi dari data yang rusak atau berbahaya yang ditulis ke akun Anda, baik oleh pengguna yang memperoleh SAS dengan benar, atau oleh pengguna yang mengeksploitasi SAS yang bocor.
Ketahui waktu yang tepat untuk tidak menggunakan SAS. Terkadang risiko yang terkait dengan operasi tertentu terhadap akun penyimpanan Anda lebih besar daripada manfaat menggunakan SAS. Untuk operasi semacam itu, buat layanan tingkat menengah yang menulis ke akun penyimpanan Anda setelah melakukan validasi aturan bisnis, autentikasi, dan pengauditan. Juga, kadang-kadang lebih mudah untuk mengelola akses dengan cara lain. Misalnya, jika Anda ingin membuat semua blob dalam kontainer yang dapat dibaca publik, Anda dapat membuat kontainer Publik, daripada menyediakan SAS kepada setiap klien untuk akses.
Gunakan Azure Monitor dan log Azure Storage untuk memantau aplikasi Anda. Kegagalan otorisasi dapat terjadi karena pemadaman di layanan penyedia SAS Anda. Mereka juga dapat terjadi dari penghapusan kebijakan akses yang tersimpan secara tidak sengaja. Anda dapat menggunakan Azure Monitor dan log analitik penyimpanan untuk mengamati lonjakan apa pun dalam jenis kegagalan otorisasi ini. Untuk informasi selengkapnya, lihat metrik Azure Storage di Azure Monitor dan pembuatan log Azure Storage Analytics.
Konfigurasikan kebijakan kedaluwarsa SAS untuk akun penyimpanan. Praktik terbaik merekomendasikan agar Anda membatasi interval untuk SAS jika dikompromikan. Dengan menetapkan kebijakan kedaluwarsa SAS untuk akun penyimpanan Anda, Anda dapat memberikan batas kedaluwarsa lebih dari yang direkomendasikan saat pengguna membuat SAS. Untuk informasi selengkapnya, lihat Membuat kebijakan kedaluwarsa untuk tanda tangan akses bersama.

Catatan

Penyimpanan tidak melacak jumlah tanda tangan akses bersama yang telah dibuat untuk akun penyimpanan, dan tidak ada API yang dapat memberikan detail ini. Jika Anda perlu mengetahui jumlah tanda tangan akses bersama yang telah dibuat untuk akun penyimpanan, Anda harus melacak jumlah tersebut secara manual.

Mulai menggunakan SAS

Untuk mulai menggunakan tanda tangan akses bersama, lihat artikel berikut ini untuk setiap jenis SAS.

Bagikan melalui

Berikan akses terbatas ke sumber daya Azure Storage menggunakan tanda tangan akses bersama (SAS)