Kontrol akses Service Bus dengan Shared Access Signatures

Artikel ini membahas Tanda Tangan Akses Bersama (SAS), cara kerjanya, dan cara menggunakannya dengan cara agnostik platform dengan Azure Bus Layanan.

SAS melindungi akses ke Bus Layanan berdasarkan aturan otorisasi yang dikonfigurasi baik pada namespace layanan, atau entitas olahpesan (antrean, atau topik). Aturan otorisasi memiliki nama, dikaitkan dengan hak-hak tertentu, dan membawa sepasang kunci kriptografi. Anda menggunakan nama dan kunci aturan melalui Service Bus SDK atau dalam kode Anda sendiri untuk menghasilkan token SAS. Klien kemudian dapat meneruskan token ke Service Bus untuk membuktikan otorisasi untuk operasi yang diminta.

• Autentikasi dan otorisasi aplikasi dengan ID Microsoft Entra untuk mengakses entitas Azure Bus Layanan.
• Mengautentikasi identitas terkelola dengan ID Microsoft Entra untuk mengakses sumber daya Azure Bus Layanan

Anda dapat menonaktifkan autentikasi kunci lokal atau SAS untuk namespace Bus Layanan dan hanya mengizinkan autentikasi Microsoft Entra. Untuk instruksi langkah demi langkah, lihat Menonaktifkan autentikasi lokal.

Gambaran umum SAS

Shared Access Signatures 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.

Autentikasi SAS dalam Bus Layanan dikonfigurasi dengan kebijakan otorisasi akses bersama bernama yang memiliki hak akses terkait, dan sepasang kunci kriptografi primer dan sekunder. Kuncinya adalah nilai 256-bit dalam representasi Base 64. Anda dapat mengonfigurasi aturan di tingkat namespace, pada antrean dan topik Microsoft Azure Service Bus.

Token Tanda Tangan Akses Bersama berisi nama kebijakan otorisasi yang dipilih, URI sumber daya yang harus diakses, instans kedaluwarsa, dan tanda tangan kriptografi HMAC-SHA256 yang dihitung pada bidang ini menggunakan kunci kriptografi primer atau sekunder dari aturan otorisasi yang dipilih.

Kebijakan otorisasi akses bersama

Setiap namespace Bus Layanan dan setiap entitas Bus Layanan memiliki kebijakan otorisasi akses bersama yang terdiri dari aturan. Kebijakan di tingkat namespace berlaku untuk semua entitas di namespace layanan, terlepas dari konfigurasi kebijakan individual mereka.

Untuk setiap aturan kebijakan otorisasi, Anda memutuskan tiga bagian informasi: nama, ruang lingkup, dan hak. Nama hanya itu; nama unik dalam lingkup tersebut. Ruang lingkupnya cukup mudah: itu adalah URI sumber daya yang dimaksud. Untuk namespace Microsoft Azure Service Bus, cakupannya adalah namespace yang sepenuhnya memenuhi syarat, seperti https://<yournamespace>.servicebus.windows.net/.

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

• Kirim - Memberikan hak untuk mengirim pesan ke entitas
• Dengar - Memberikan hak untuk menerima (antrean, langganan) dan semua penanganan pesan terkait
• Kelola - Memberikan hak untuk mengelola topologi namespace layanan, termasuk membuat dan menghapus entitas

Hak Kelola mencakup hak Kirim dan Dengar.

Kebijakan namespace atau entitas dapat menampung hingga 12 aturan Otorisasi Akses Bersama, menyediakan ruang untuk tiga set aturan, masing-masing mencakup hak dasar, dan kombinasi Kirim dan Dengarkan. Batas ini adalah per entitas, yang berarti namespace dan setiap entitas dapat memiliki hingga 12 aturan Otorisasi Akses Bersama. 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 Kunci Utama dan Kunci Sekunder. Ini adalah kunci yang kuat secara kriptografis. Jangan kehilangan atau membocorkannya - mereka akan selalu tersedia di portal Microsoft 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 yang sedang berlangsung yang dibuat berdasarkan token tersebut terus berfungsi hingga token kedaluwarsa.

Saat Anda membuat namespace Service Bus, aturan kebijakan bernama RootManageSharedAccessKey secara otomatis dibuat untuk namespace. Kebijakan ini memiliki izin Kelola untuk seluruh namespace. Disarankan agar Anda memperlakukan aturan ini seperti akun root administratif dan tidak menggunakannya di aplikasi Anda. Anda dapat membuat aturan kebijakan lainnya di tab Kebijakan akses bersama untuk namespace layanan di portal, melalui PowerShell atau Azure CLI.

Kami menyarankan agar Anda secara berkala meregenerasi kunci yang digunakan dalam objek SharedAccessAuthorizationRule . Slot kunci primer dan sekunder ada sehingga Anda dapat memutar tombol secara bertahap. Jika aplikasi Anda umumnya menggunakan kunci utama, Anda dapat menyalin kunci utama ke slot kunci sekunder, lalu meregenerasi kunci utama. Nilai kunci utama baru kemudian dapat dikonfigurasi ke dalam aplikasi klien, yang telah melanjutkan akses menggunakan kunci utama lama di slot sekunder. Setelah semua klien diperbarui, Anda dapat meregenerasi kunci sekunder untuk akhirnya pensiun kunci utama lama.

Jika Anda tahu atau menduga bahwa kunci disusupi dan Anda harus mencabut kunci, Anda dapat meregenerasi PrimaryKey dan SecondaryKey dari SharedAccessAuthorizationRule, menggantinya dengan kunci baru. Prosedur ini membatalkan semua token yang ditandatangani dengan kunci lama.

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 Service Bus Anda.
• Jika SAS yang disediakan untuk aplikasi klien kedaluwarsa dan aplikasi tidak dapat mengambil SAS baru dari layanan Anda, fungsionalitas aplikasi mungkin 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 beberapa 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).
• Berhati-hatilah dengan waktu mulai SAS: Jika Anda mengatur waktu mulai untuk SAS ke sekarang, maka karena kemiringan jam (perbedaan waktu saat ini sesuai dengan komputer yang berbeda), Anda mungkin melihat kegagalan secara terputus-putus 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 mungkin mengamati hingga 15 menit jam condong 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 Azure Service Bus Anda lebih besar daripada manfaat SAS. Untuk operasi semacam itu, buat layanan tingkat menengah yang menulis ke Azure Service Bus Anda setelah validasi, autentikasi, dan audit aturan bisnis.
• Selalu gunakan HTTP: Selalu gunakan Https untuk membuat atau mendistribusikan SAS. Jika SAS dilewatkan melalui HTTP dan dicegat, penyerang yang melakukan lampirkan man-in-the-middle dapat membaca SAS dan kemudian menggunakannya seperti yang bisa dimiliki pengguna yang dimaksudkan, berpotensi mengorbankan data sensitif atau memungkinkan kerusakan data oleh pengguna jahat.

Konfigurasi untuk autentikasi Shared Access Signature

Anda dapat mengonfigurasi Kebijakan Otorisasi Akses Bersama di namespace, antrean, atau topik Microsoft Azure Service Bus. Konfigurasi pada langganan Microsoft Azure Service Bus saat ini tidak didukung, tetapi Anda dapat menggunakan aturan yang dikonfigurasi pada namespace atau topik untuk mengamankan akses ke langganan.

Dalam gambar ini, aturan otorisasi manageRuleNS, sendRuleNS, dan listenRuleNS berlaku untuk antrean Q1 dan topik T1, sementara listenRuleQ dan sendRuleQ hanya berlaku untuk antrean Q1 dan sendRuleT hanya berlaku untuk topik T1.

Menghasilkan token Shared Access Signature

Setiap klien yang memiliki akses ke nama aturan otorisasi dan salah satu kunci penandatanganannya dapat menghasilkan token SAS. Token dihasilkan dengan membuat string dalam format berikut:

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

• se - Token kedaluwarsa instan. Bilangan bulat mencerminkan detik sejak zaman 00:00:00 UTC pada 1 Januari 1970 (zaman UNIX) ketika token berakhir.

• skn - Nama aturan otorisasi.

• sr - URI berkode URL sumber daya yang diakses.

• sig - Tanda tangan HMACSHA256 yang dikodekan URL. Perhitungan hash terlihat mirip dengan kode pseudo berikut dan mengembalikan base64 dari output biner mentah.

  urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
  

Token berisi nilai yang tidak di-hash sehingga penerima dapat mengalah ulang hash dengan parameter yang sama, memverifikasi bahwa penerbit memiliki kunci penandatanganan yang valid.

Sumber daya URI adalah URI penuh dari sumber daya Azure Service Bus yang aksesnya diklaim. Misalnya, http://<namespace>.servicebus.windows.net/<entityPath> atau sb://<namespace>.servicebus.windows.net/<entityPath>; yaitu, http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

URI harus dikodekan persen.

Aturan shared access authorization yang digunakan untuk penandatanganan harus dikonfigurasi pada entitas yang ditentukan oleh URI ini, atau oleh salah satu orang tua hierarkinya. Misalnya, http://contoso.servicebus.windows.net/contosoTopics/T1 atau http://contoso.servicebus.windows.net di contoh sebelumnya.

Token SAS berlaku untuk semua sumber daya yang diasingkan dengan <resourceURI> yang digunakan dalam signature-string.

Meregenerasi kunci

Kami menyarankan agar Anda secara berkala meregenerasi kunci yang digunakan dalam Kebijakan Otorisasi Akses Bersama. Slot kunci primer dan sekunder ada sehingga Anda dapat memutar tombol secara bertahap. Jika aplikasi Anda umumnya menggunakan kunci utama, Anda dapat menyalin kunci utama ke slot kunci sekunder, lalu meregenerasi kunci utama. Nilai kunci utama baru kemudian dapat dikonfigurasi ke dalam aplikasi klien, yang telah melanjutkan akses menggunakan kunci utama lama di slot sekunder. Setelah semua klien diperbarui, Anda dapat meregenerasi kunci sekunder untuk akhirnya pensiun kunci utama lama.

Jika Anda mengetahui atau mencurigai bahwa kunci telah disusupi dan Anda harus membatalkan kunci tersebut, Anda dapat membuat ulang kunci primer dan sekunder dari Kebijakan Otorisasi Akses Bersama dan menggantinya dengan kunci baru. Prosedur ini membatalkan semua token yang ditandatangani dengan kunci lama.

Untuk meregenerasi kunci primer dan sekunder di portal Azure, ikuti langkah berikut:

1. Buka namespace Bus Layanan di portal Azure.

2. Pilih Kebijakan Akses Bersama di menu sebelah kiri.

3. Pilih kebijakan dari daftar. Dalam contoh berikut, RootManageSharedAccessKey dipilih.

4. Untuk meregenerasi kunci utama, pada halaman Kebijakan SAS: RootManageSharedAccessKey , pilih Regenerasi kunci utama pada bilah perintah.

   

5. Untuk meregenerasi kunci sekunder, pada halaman Kebijakan SAS: RootManageSharedAccessKey , pilih ... dari bilah perintah, lalu pilih Regenerasi kunci sekunder.

   

Jika Anda menggunakan Azure PowerShell, gunakan New-AzServiceBusKey cmdlet untuk meregenerasi kunci primer dan sekunder untuk namespace Bus Layanan. Anda juga dapat menentukan nilai untuk kunci primer dan sekunder yang sedang dibuat, dengan menggunakan parameter -KeyValue.

Jika Anda menggunakan Azure CLI, gunakan az servicebus namespace authorization-rule keys renew perintah untuk meregenerasi kunci primer dan sekunder untuk namespace Bus Layanan. Anda juga dapat menentukan nilai untuk kunci primer dan sekunder yang sedang dibuat, dengan menggunakan parameter --key-value.

Autentikasi Service Bus dengan Shared Access Signatures

Skenario yang dijelaskan sebagai berikut termasuk konfigurasi aturan otorisasi, pembuatan token SAS, dan otorisasi klien.

Untuk contoh aplikasi Service Bus yang mengilustrasikan konfigurasi dan menggunakan otorisasi SAS, lihat Autentikasi Shared Access Signature dengan Service Bus.

Mengakses aturan Shared Access Authorization pada entitas

Gunakan operasi dapatkan/perbarui pada antrean atau topik di pustaka manajemen untuk Microsoft Azure Service Bus untuk mengakses/memperbarui Aturan Otorisasi Akses Bersama yang sesuai. Anda juga dapat menambahkan aturan saat membuat antrean atau topik melalui pustaka ini.

Menggunakan otorisasi Shared Access Signature

Aplikasi yang menggunakan salah satu SDK Bus Layanan dalam salah satu bahasa yang didukung secara resmi seperti .NET, Java, JavaScript, dan Python dapat menggunakan otorisasi SAS melalui string koneksi yang diteruskan ke konstruktor klien.

String koneksi dapat mencakup nama aturan (SharedAccessKeyName) dan kunci aturan (SharedAccessKey) atau token yang dikeluarkan sebelumnya (SharedAccessSignature). Ketika ada dalam string koneksi yang diteruskan ke konstruktor atau metode pabrik yang menerima string koneksi, penyedia token SAS secara otomatis dibuat dan diisi.

Untuk menggunakan otorisasi SAS dengan langganan Service Bus, Anda dapat menggunakan kunci SAS yang dikonfigurasi pada namespace Service Bus atau pada topik.

Menggunakan Shared Access Signature (di tingkat HTTP)

Sekarang setelah Anda tahu cara membuat Tanda Tangan Akses Bersama untuk setiap entitas di Bus Layanan, Anda siap untuk melakukan POST HTTP:

POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8

Ingat, ini bekerja untuk segalanya. Anda dapat membuat SAS untuk antrean, topik, atau langganan.

Jika Anda memberikan token SAS kepada pengirim atau klien, mereka tidak memiliki kunci secara langsung, dan mereka tidak dapat membalikkan hash untuk mendapatkannya. Dengan demikian, Anda memiliki kendali atas apa yang dapat mereka akses, dan untuk berapa lama. Hal penting yang perlu diingat adalah bahwa jika Anda mengubah kunci utama dalam kebijakan, Shared Access Signatures yang dibuat darinya tidak valid.

Menggunakan Shared Access Signature (di tingkat AMQP)

Di bagian sebelumnya, Anda melihat cara menggunakan token SAS dengan permintaan HTTP POST untuk mengirim data ke Service Bus. Seperti yang Anda ketahui, Anda dapat mengakses Service Bus menggunakan Advanced Message Queuing Protocol (AMQP) yang merupakan protokol pilihan untuk digunakan karena alasan performa, dalam banyak skenario. Penggunaan token SAS dengan AMQP dijelaskan dalam dokumen AMQP Claim-Based Security Version 1.0 yang sedang dalam draf kerja sejak 2013 tetapi didukung oleh Azure hari ini.

Sebelum mulai mengirim data ke Service Bus, penerbit harus mengirim token SAS di dalam pesan AMQP ke node AMQP yang ditentukan dengan baik bernama $cbs (Anda dapat melihatnya sebagai antrean "khusus" yang digunakan oleh layanan untuk memperoleh dan memvalidasi semua token SAS). Penerbit harus menentukan bidang ReplyTo di dalam pesan AMQP; ini adalah node di mana layanan membalas penerbit dengan hasil validasi token (pola permintaan/balasan sederhana antara penerbit dan layanan). Node balasan ini dibuat "dengan cepat," berbicara tentang "pembuatan node jarak jauh yang dinamis" seperti yang dijelaskan oleh spesifikasi AMQP 1.0. Setelah memeriksa bahwa token SAS valid, penerbit dapat melanjutkan dan mulai mengirim data ke layanan.

Langkah-langkah berikut menunjukkan cara mengirim token SAS dengan protokol AMQP menggunakan pustaka AMQP.NET Lite. Ini berguna jika Anda tidak dapat menggunakan SDK Bus Layanan resmi (misalnya, pada WinRT, .NET Compact Framework, .NET Micro Framework, dan Mono) yang dikembangkan di C#. Tentu saja, pustaka ini berguna untuk membantu memahami cara kerja keamanan berbasis klaim di tingkat AMQP, seperti yang Anda lihat cara kerjanya di tingkat HTTP (dengan permintaan POST HTTP dan token SAS yang dikirim ke dalam header "Otorisasi"). Jika Anda tidak memerlukan pengetahuan mendalam tentang AMQP, Anda dapat menggunakan SDK Bus Layanan resmi dalam salah satu bahasa yang didukung seperti .NET, Java, JavaScript, Python, dan Go, yang akan melakukannya untuk Anda.

C#

/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
    bool result = true;
    Session session = new Session(connection);

    string cbsClientAddress = "cbs-client-reply-to";
    var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
    var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");

    // construct the put-token message
    var request = new Message(sasToken);
    request.Properties = new Properties();
    request.Properties.MessageId = Guid.NewGuid().ToString();
    request.Properties.ReplyTo = cbsClientAddress;
    request.ApplicationProperties = new ApplicationProperties();
    request.ApplicationProperties["operation"] = "put-token";
    request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
    request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
    cbsSender.Send(request);

    // receive the response
    var response = cbsReceiver.Receive();
    if (response == null || response.Properties == null || response.ApplicationProperties == null)
    {
        result = false;
    }
    else
    {
        int statusCode = (int)response.ApplicationProperties["status-code"];
        if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
        {
            result = false;
        }
    }

    // the sender/receiver might be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

Metode PutCbsToken() ini menerima koneksi (instans kelas koneksi AMQP sebagaimana disediakan oleh pustaka AMQP .NET Lite) yang mewakili koneksi TCP ke layanan dan parameter sasToken yang merupakan token SAS untuk dikirim.

Selanjutnya, penerbit membuat dua tautan AMQP untuk mengirim token SAS dan menerima balasan (hasil validasi token) dari layanan.

Pesan AMQP berisi sekumpulan properti, dan lebih banyak informasi daripada pesan sederhana. Token SAS adalah isi pesan (menggunakan konstruktornya). Properti "ReplyTo" diatur ke nama node untuk menerima hasil validasi pada tautan receiver (Anda dapat mengubah namanya jika Anda mau, dan itu akan dibuat secara dinamis oleh layanan). Tiga properti aplikasi/kustom terakhir digunakan oleh layanan untuk menunjukkan jenis operasi apa yang harus dijalankannya. Seperti yang dijelaskan oleh spesifikasi draf CBS, mereka harus menjadi nama operasi ("put-token"), jenis token (dalam hal ini, a servicebus.windows.net:sastoken), dan "nama" pemirsa tempat token berlaku (seluruh entitas).

Setelah mengirim token SAS pada link pengirim, penerbit harus membaca balasan pada link penerima. Balasan adalah pesan AMQP sederhana dengan properti aplikasi bernama "kode status" yang dapat berisi nilai yang sama dengan kode status HTTP.

Hak yang diperlukan untuk operasi Service Bus

Tabel berikut menunjukkan hak akses yang diperlukan untuk berbagai operasi pada sumber daya Service Bus.

Langkah berikutnya

Untuk mempelajari selengkapnya tentang olahpesan Service Bus, lihat topik berikut ini.

• Antrean, topik, dan langganan Microsoft Azure Service Bus
• Cara menggunakan antrean Service Bus
• Cara menggunakan topik dan langganan Microsoft Azure Service Bus