Mengotorisasi akses ke sumber daya Azure Event Hubs menggunakan Tanda Tangan Akses Bersama

  • Artikel

Tanda tangan akses bersama (SAS) memberi Anda cara untuk memberikan akses terbatas ke sumber daya di namespace Hub Peristiwa Anda. SAS menjaga akses ke sumber daya Event Hubs berdasarkan aturan otorisasi. Aturan ini dikonfigurasi baik di namespace layanan, atau hub peristiwa. Artikel ini memberikan gambaran umum tentang model SAS, dan meninjau praktik terbaik SAS.

Catatan

Artikel ini membahas otorisasi akses ke sumber daya Azure Event Hubs menggunakan SAS. Untuk mempelajari tentang mengautentikasi akses ke sumber daya Azure Event Hubs menggunakan SAS, lihat Mengautentikasi dengan SAS.

Bekerja dengan tanda tangan akses bersama?

Tanda tangan akses bersama (SAS) menyediakan akses yang didelegasikan ke sumber daya Hub Acara berdasarkan aturan otorisasi. Aturan otorisasi memiliki nama, dikaitkan dengan hak-hak tertentu, dan membawa sepasang kunci kriptografi. Anda menggunakan nama dan kunci aturan melalui klien Event Hubs atau dalam kode Anda sendiri untuk menghasilkan token SAS. Klien kemudian dapat meneruskan token ke Event Hubs untuk membuktikan otorisasi untuk operasi yang diminta.

SAS adalah mekanisme otorisasi berbasis klaim menggunakan token sederhana. Ketika Anda menggunakan SAS, kunci tidak pernah diteruskan pada kawat. Kunci digunakan untuk menandatangani informasi secara kriptografis yang nantinya dapat diverifikasi oleh layanan. SAS dapat digunakan mirip dengan skema nama pengguna dan kata sandi di mana klien memiliki segera nama aturan otorisasi dan kunci yang cocok. SAS juga dapat digunakan mirip dengan model keamanan federasi, di mana klien menerima token akses terbatas waktu dan ditandatangani dari layanan token keamanan tanpa pernah memiliki kunci penandatanganan.

Catatan

Azure Event Hubs juga mendukung otorisasi ke sumber daya Azure Event Hubs menggunakan ID Microsoft Entra. Mengotorisasi pengguna atau aplikasi menggunakan token OAuth 2.0 yang dikembalikan oleh MICROSOFT Entra ID memberikan keamanan yang unggul dan kemudahan penggunaan melalui tanda tangan akses bersama (SAS). Dengan ID Microsoft Entra, Anda tidak perlu menyimpan token dalam kode Anda dan berisiko potensi kerentanan keamanan.

Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan aplikasi Azure Event Hubs Anda jika memungkinkan. Untuk informasi selengkapnya, lihat Mengotorisasi akses ke sumber daya Azure Event Hubs menggunakan ID Microsoft Entra.

Penting

Token SAS (Shared Access Signatures) sangat penting untuk melindungi sumber daya Anda. Saat menyediakan granularitas, SAS memberi klien akses ke sumber daya Event Hubs Anda. Mereka tidak boleh dibagikan secara publik. Saat berbagi, jika diperlukan untuk alasan pemecahan masalah, pertimbangkan untuk menggunakan versi berkurang dari file log apa pun atau menghapus token SAS (jika ada) dari file log, dan pastikan tangkapan layar juga tidak berisi informasi SAS.

Kebijakan otorisasi akses bersama

Setiap namespace layanan Azure Event Hubs dan setiap entitas Azure Event Hubs (hub peristiwa atau topik Kafka) memiliki kebijakan otorisasi akses bersama yang terdiri dari aturan. Kebijakan di tingkat namespace berlaku untuk semua entitas di dalam namespace, terlepas dari konfigurasi kebijakan individu mereka. Untuk setiap aturan kebijakan otorisasi, Anda memutuskan tiga bagian informasi: nama, ruang lingkup, dan hak. Namanya adalah nama unik dalam lingkup itu. Ruang lingkup adalah URI sumber daya yang dimaksud. Untuk namespace Service Bus, cakupannya adalah nama domain yang sepenuhnya memenuhi syarat (FQDN), seperti https://<yournamespace>.servicebus.windows.net/.

Hak-hak yang diberikan oleh aturan kebijakan dapat menjadi kombinasi dari:

  • Kirim - Menganugerahkan hak untuk mengirim pesan ke entitas
  • Dengarkan – Memberikan hak untuk mendengarkan atau menerima pesan dari entitas
  • Kelola – Memberikan hak untuk mengelola topologi namespace layanan, termasuk pembuatan dan penghapusan entitas. Hak Kelola mencakup hak Kirim dan Dengar.

Kebijakan namespace atau entitas dapat menyimpan hingga 12 aturan OShared Access Authorization, menyediakan ruang untuk tiga set aturan, masing-masing mencakup hak dasar dan kombinasi Kirim dan Dengarkan. Batas ini menggarisbawahi bahwa penyimpanan kebijakan SAS tidak dimaksudkan untuk menjadi toko akun pengguna atau layanan. Jika aplikasi Anda perlu memberikan akses ke Service Bus berdasarkan identitas pengguna atau layanan, aplikasi tersebut harus menerapkan layanan token keamanan yang mengeluarkan token SAS setelah pemeriksaan autentikasi dan akses.

Aturan otorisasi diberi satu kunci primer dan satu kunci sekunder. Ini adalah kunci yang kuat secara kriptografis. Jangan kehilangan mereka atau membocorkannya. Mereka akan selalu tersedia di portal Azure. Anda dapat menggunakan salah satu kunci yang dihasilkan, dan Anda dapat meregenerasinya kapan saja. Jika Anda meregenerasi atau mengubah kunci dalam kebijakan, semua token yang dikeluarkan sebelumnya berdasarkan kunci tersebut menjadi tidak valid secara instan. Namun, koneksi berkelanjutan yang dibuat berdasarkan token tersebut akan terus berfungsi sampai token kedaluwarsa.

Saat Anda membuat namespace Event Hubs, aturan kebijakan bernama RootManageSharedAccessKey secara otomatis dibuat untuk namespace. Kebijakan ini memiliki izin kelola untuk seluruh namespace layanan. Disarankan agar Anda memperlakukan aturan ini seperti akun root administratif dan tidak menggunakannya di aplikasi Anda. Anda bisa membuat aturan kebijakan tambahan di tab Konfigurasi untuk namespace di portal, melalui PowerShell atau Azure CLI.

Praktik terbaik saat menggunakan SAS

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

  • Jika SAS bocor, itu dapat digunakan oleh siapa saja yang mendapatkannya, yang berpotensi membahayakan sumber daya Event Hubs 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:

  • Minta klien memperbarui SAS secara otomatis jika perlu: Klien harus memperbarui SAS dengan baik sebelum kedaluwarsa, untuk memungkinkan waktu untuk mencoba kembali jika layanan yang menyediakan SAS tidak tersedia. Jika SAS Anda dimaksudkan untuk digunakan untuk sejumlah kecil operasi langsung berumur pendek yang diharapkan selesai dalam periode kedaluwarsa, maka mungkin tidak perlu karena SAS tidak diharapkan untuk diperpanjang. Namun, jika Anda memiliki klien yang secara rutin membuat permintaan melalui SAS, maka kemungkinan kedaluwarsa mulai berlaku. Pertimbangan utama adalah menyeimbangkan kebutuhan SAS untuk berumur pendek (seperti yang dinyatakan sebelumnya) dengan kebutuhan untuk memastikan bahwa klien meminta perpanjangan cukup awal (untuk menghindari gangguan karena SAS kedaluwarsa sebelum pembaruan yang berhasil).
  • Hati-hati dengan waktu mulai SAS: Jika Anda mengatur waktu mulai untuk SAS hingga sekarang, maka karena condong jam (perbedaan dalam waktu saat ini menurut komputer yang berbeda), kegagalan dapat diamati sewaktu-waktu selama beberapa menit pertama. Secara umum, setel waktu mulai setidaknya 15 menit sebelumnya. Atau, jangan mengaturnya sama sekali, yang akan membuatnya valid segera dalam semua kasus. Hal yang sama umumnya berlaku untuk waktu kedaluwarsa juga. Ingatlah bahwa Anda dapat melihat hingga 15 menit penyimpangan jam ke kedua arah pada permintaan apa pun.
  • Khusus dengan sumber daya yang akan diakses: Praktik terbaik keamanan adalah memberikan hak istimewa minimum yang diperlukan kepada pengguna. Jika pengguna hanya memerlukan akses baca ke satu entitas, maka beri mereka akses baca ke entitas tunggal tersebut, dan tidak membaca/menulis/menghapus akses ke semua entitas. Ini juga membantu mengurangi kerusakan jika SAS dikompromikan karena SAS memiliki lebih sedikit kekuatan di tangan penyerang.
  • Jangan selalu menggunakan SAS: Terkadang risiko yang terkait dengan operasi tertentu terhadap Event Hub Anda melebihi manfaat SAS. Untuk operasi tersebut, buat layanan tingkat menengah yang menulis ke Event Hub Anda setelah validasi, autentikasi, dan audit aturan bisnis.
  • Selalu gunakan HTTP: Selalu gunakan Https untuk membuat atau mendistribusikan SAS. Jika SAS diteruskan melalui HTTP dan dicegat, penyerang yang melakukan serangan man-in-the-middle dapat membaca SAS dan kemudian menggunakannya sama seperti yang dapat dimiliki pengguna yang dimaksudkan, berpotensi mengorbankan data sensitif atau memungkinkan kerusakan data oleh pengguna berbahaya.

Kesimpulan

Berbagi tanda tangan akses berguna untuk memberikan izin terbatas ke sumber daya Hub Acara kepada klien Anda. Mereka adalah bagian penting dari model keamanan untuk aplikasi apa pun menggunakan Azure Event Hubs. Jika Anda mengikuti praktik terbaik yang tercantum dalam artikel ini, Anda dapat menggunakan SAS untuk memberikan fleksibilitas akses yang lebih besar ke sumber daya Anda, tanpa mengorbankan keamanan aplikasi Anda.

Langkah berikutnya

Lihat artikel terkait berikut ini: