Memberikan access terbatas ke sumber daya Azure Storage menggunakan tanda tangan access bersama (SAS)

Tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan dengan aman ke sumber daya di akun penyimpanan Anda. Dengan SAS, Anda memiliki kontrol terperinci atas bagaimana klien dapat access 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 access bersama:

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 untuk data di Azure Storage.

Delegasi pengguna SAS

SAS delegasi pengguna diamankan dengan kredensial Microsoft Entra dan juga oleh izin yang ditentukan untuk SAS tersebut. SAS delegasi pengguna didukung untuk Blob Storage (termasuk titik akhir Data Lake Storage dan dfs), Queue Storage, Table Storage, atau Azure Files.

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

Layanan SAS

SAS layanan diamankan dengan kunci akun penyimpanan. SAS layanan mendelegasikan akses ke sumber daya hanya di salah satu layanan Azure Storage: Blob Storage (termasuk titik akhir Data Lake Storage dan dfs), Penyimpanan Antrian, 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. SAS akun mendelegasikan 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 access ke hal berikut:

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

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

Tanda tangan akses bersama dapat mengambil salah satu dari dua bentuk 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.
  • Service SAS dengan kebijakan akses yang disimpan. Kebijakan access tersimpan ditentukan pada kontainer sumber daya, yang dapat berupa kontainer blob, tabel, antrean, atau berbagi file. Kebijakan akses tersimpan dapat digunakan untuk mengelola batasan untuk satu atau beberapa akses tanda tangan bersama layanan. Saat Anda mengaitkan layanan SAS dengan kebijakan akses yang disimpan, SAS mewarisi batasan—waktu mulai, waktu kedaluwarsa, dan izin—yang ditentukan untuk kebijakan akses yang disimpan.

Catatan

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

Cara kerja tanda tangan access bersama

Shared access signature adalah suatu 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 access ke sumber daya storage.

Catatan

Tidak mungkin untuk mengaudit pembuatan token SAS. Setiap pengguna yang memiliki hak istimewa untuk menghasilkan token SAS, baik dengan menggunakan kunci akun, atau melalui penetapan peran Azure, dapat melakukannya tanpa sepengetahuan pemilik akun storage. 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 storage (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 access ke kunci akun.

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

Tabel berikut ini meringkas bagaimana setiap jenis token SAS diotorisasi.

Jenis SAS Jenis otorisasi
Delegasi pengguna SAS 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 string yang Anda hasilkan 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 access ke sumber daya di akun storage Anda.

Aplikasi klien menyediakan URI SAS untuk 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.

Waktu yang tepat untuk menggunakan tanda tangan akses bersama

Gunakan SAS untuk memberikan access aman ke sumber daya di akun storage 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 storage Anda. Dalam skenario di mana akun storage menyimpan data pengguna, ada dua pola desain umum:

  1. 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.

    Diagram skenario: Layanan proksi front-end

  2. Layanan ringan mengautentikasi klien sesuai kebutuhan dan kemudian membuat SAS. Setelah aplikasi klien menerima SAS, aplikasi tersebut dapat mengakses sumber daya penyimpanan akun secara langsung. Izin akses ditentukan oleh SAS dan untuk jangka waktu yang diizinkan oleh SAS. SAS mengurangi kebutuhan untuk merutekan semua data melalui layanan proksi front-end.

    Diagram Skenario: Layanan penyedia SAS

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 access ke objek sumber dalam operasi salin dalam skenario tertentu:

  • Saat Anda menyalin blob ke blob lain yang berada di akun storage yang berbeda. Anda dapat secara opsional menggunakan SAS untuk mengotorisasi access ke blob tujuan juga.
  • Saat Anda menyalin file ke file lain yang berada di akun storage yang berbeda. Anda dapat secara opsional menggunakan SAS untuk mengotorisasi access ke file tujuan juga.
  • Saat Anda menyalin objek data ke file, atau file ke objek data. Anda harus menggunakan SAS meskipun objek sumber dan tujuan berada dalam akun storage yang sama.

Praktik terbaik saat menggunakan SAS

Saat Anda menggunakan tanda tangan access bersama di aplikasi, Anda perlu mengetahui dua potensi risiko:

  • Jika SAS bocor, SAS dapat digunakan oleh siapa saja yang mendapatkannya, yang dapat membahayakan akun storage 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 tanda tangan access bersama 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.

  • Siapkan rencana pencabutan untuk SAS. Pastikan Anda siap untuk menanggapi jika SAS dikompromikan.

  • Konfigurasikan kebijakan kedaluwarsa SAS untuk akun storage. 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 dari yang disarankan, mereka akan melihat peringatan. Jika pengelogan Azure Storage dengan Azure Monitor diaktifkan, entri ditulis ke log Azure Storage. Untuk mempelajari selengkapnya, lihat Buat kebijakan kedaluwarsa untuk tanda tangan akses bersama.

  • Buat kebijakan access tersimpan untuk LAYANAN SAS. Kebijakan akses yang tersimpan memberi Anda opsi untuk mencabut izin untuk SAS layanan (Shared Access Signature) tanpa harus menghasilkan ulang kunci akun penyimpanan. Atur kedaluwarsa pada elemen ini sangat lama di masa depan (atau tak terbatas) dan pastikan diperbarui secara teratur untuk memperpanjang masa berlakunya lebih panjang ke masa depan. Ada batas lima kebijakan access tersimpan per kontainer.

  • Gunakan waktu kedaluwarsa jangka pendek untuk layanan SAS ad hoc 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 merujuk pada kebijakan akses 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 mesin yang berbeda memiliki waktu saat ini yang sedikit berbeda (dikenal sebagai deviasi 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 penyimpangan waktu ke arah mana pun pada setiap permintaan. Untuk klien yang menggunakan versi REST sebelum 2012-02-12, durasi maksimum untuk SAS yang tidak mereferensikan kebijakan access tersimpan adalah 1 jam. Setiap kebijakan yang menentukan jangka panjang dari 1 jam akan gagal.

  • Hati-hati dengan format tanggal waktu 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, maka berikan mereka akses baca ke objek tersebut, dan bukan akses baca/menulis/menghapus 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 SAS, bidang IP yang ditandatangani (sip), waktu mulai 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 bisa mengunggah blob 200 GB. Jika Anda telah memberi mereka akses membaca juga, mereka dapat memilih untuk mengunduhnya 10 kali, dengan biaya egress 2 TB yang dibebankan kepada 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. Saat aplikasi klien menulis data ke akun storage 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 storage Anda melebihi manfaat menggunakan SAS. Untuk operasi tersebut, buat layanan tingkat menengah yang menulis ke akun storage Anda setelah melakukan validasi, autentikasi, dan audit aturan bisnis. Selain itu, mengelola akses dengan cara lain terkadang lebih mudah. Misalnya, jika Anda ingin membuat semua blob dalam kontainer dapat dibaca secara publik, Anda dapat membuat kontainer menjadi Publik, daripada menyediakan SAS kepada setiap klien untuk akses.

  • Gunakan log Azure Monitor dan 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 disimpan secara tidak sengaja. Anda dapat menggunakan Azure Monitor dan pengelogan storage analytics untuk mengamati lonjakan apa pun dalam jenis kegagalan otorisasi ini. Untuk informasi selengkapnya, lihat metrik Azure Storage di Azure Monitor dan pengelogan Azure Storage Analytics.

  • Konfigurasikan kebijakan kedaluwarsa SAS untuk akun storage. Praktik terbaik merekomendasikan agar Anda membatasi selang waktu untuk SAS jika terjadi pelanggaran. Dengan menetapkan kebijakan kedaluwarsa SAS untuk akun storage Anda, Anda dapat memberikan batas kedaluwarsa atas yang direkomendasikan saat pengguna membuat layanan SAS atau AKUN SAS. Untuk informasi selengkapnya, lihat Buat kebijakan kedaluwarsa tanda tangan akses bersama.

Catatan

Storage tidak melacak jumlah tanda tangan access bersama yang telah dihasilkan untuk akun storage, 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 jumlahnya secara manual.

Mulai dengan SAS

Untuk memulai dengan tanda tangan akses bersama, lihat artikel berikut untuk setiap jenis SAS.

Delegasi pengguna SAS

Layanan SAS

Akun SAS

Langkah berikutnya

  • Last updated on