Share via

Autentikasi dan otorisasi untuk Azure Health Data Services

  • Artikel

Autentikasi

Azure Health Data Services adalah kumpulan layanan terkelola aman menggunakan ID Microsoft Entra, idP global yang mendukung OAuth 2.0.

Agar Azure Health Data Services mengakses sumber daya Azure, seperti akun penyimpanan dan hub peristiwa, Anda perlu mengaktifkan identitas terkelola sistem dan memberikan izin yang tepat ke identitas terkelola. Untuk informasi selengkapnya, lihat Identitas terkelola Azure.

Aplikasi klien terdaftar di ID Microsoft Entra dan dapat digunakan untuk mengakses Azure Health Data Services. Kontrol akses data pengguna dilakukan dalam aplikasi atau layanan yang menerapkan logika bisnis.

Peran aplikasi

Pengguna terautentikasi dan aplikasi klien Azure Health Data Services harus ditetapkan ke peran aplikasi yang tepat.

Layanan FHIR® di Azure Health Data Services menyediakan peran ini:

  • Pembaca Data FHIR: Membaca dan mencari data FHIR.
  • Penulis Data FHIR: Membaca, menulis, dan menghapus sementara data FHIR.
  • Pengekspor Data FHIR: Membaca dan mengekspor data (operator $export).
  • Pengimpor Data FHIR: Membaca dan mengimpor data (operator $import).
  • Kontributor Data FHIR: Lakukan semua operasi sarana data.
  • FHIR Data Converter: Gunakan pengonversi untuk melakukan konversi data.
  • FHIR SMART User: Memungkinkan pengguna untuk membaca dan menulis data FHIR sesuai dengan spesifikasi SMART IG V1.0.0.

Layanan DICOM® di Azure Health Data Services menyediakan peran berikut:

  • Pemilik Data DICOM: Membaca, menulis, dan menghapus data DICOM.
  • Baca Data DICOM: Membaca data DICOM.

Layanan MedTech tidak memerlukan peran aplikasi, tetapi mengandalkan Penerima Data Azure Event Hubs untuk mengambil data yang disimpan di pusat aktivitas langganan organisasi Anda.

Authorization

Setelah diberikan peran aplikasi yang tepat, pengguna dan aplikasi klien yang diautentikasi dapat mengakses Azure Health Data Services dengan mendapatkan token akses valid yang dikeluarkan oleh ID Microsoft Entra, dan melakukan operasi tertentu yang ditentukan oleh peran aplikasi.

  • Untuk layanan FHIR, token akses khusus untuk layanan atau sumber daya.
  • Untuk layanan DICOM, token akses diberikan ke dicom.healthcareapis.azure.com sumber daya, bukan layanan tertentu.
  • Untuk layanan MedTech, token akses tidak diperlukan karena tidak diekspos ke pengguna atau aplikasi klien.

Langkah-langkah untuk otorisasi

Ada dua cara umum untuk mendapatkan token akses, yang diuraikan secara rinci oleh dokumentasi Microsoft Entra: alur kode otorisasi dan alur kredensial klien.

Berikut adalah bagaimana token akses untuk Azure Health Data Services diperoleh menggunakan alur kode otorisasi:

  1. Klien mengirim permintaan ke titik akhir otorisasi Microsoft Entra. ID Microsoft Entra mengalihkan klien ke halaman masuk tempat pengguna mengautentikasi menggunakan kredensial yang sesuai (misalnya: nama pengguna dan kata sandi, atau autentikasi dua faktor). Setelah autentikasi berhasil, kode otorisasi dikembalikan ke klien. Microsoft Entra-only memungkinkan kode otorisasi ini dikembalikan ke URL balasan terdaftar yang dikonfigurasi dalam pendaftaran aplikasi klien.

  2. Aplikasi klien bertukar kode otorisasi dengan token akses di titik akhir token Microsoft Entra. Ketika aplikasi klien meminta token, aplikasi mungkin harus memberikan rahasia klien (yang dapat Anda tambahkan selama pendaftaran aplikasi).

  3. Klien membuat permintaan ke Azure Health Data Services, misalnya, GET permintaan untuk mencari semua pasien dalam layanan FHIR. Permintaan mencakup token akses di HTTP header permintaan, misalnya, Authorization: Bearer xxx.

  4. Azure Health Data Services memvalidasi bahwa token berisi klaim yang sesuai (properti dalam token). Jika valid, permintaan akan menyelesaikan permintaan dan mengembalikan data ke klien.

Dalam alur kredensial klien, izin diberikan langsung ke aplikasi itu sendiri. Ketika aplikasi menyajikan token ke sumber daya, sumber daya memberlakukan bahwa aplikasi itu sendiri memiliki otorisasi untuk melakukan tindakan karena tidak ada pengguna yang terlibat dalam autentikasi. Oleh karena itu, ini berbeda dari alur kode otorisasi dengan cara berikut:

  • Pengguna atau klien tidak perlu masuk secara interaktif.
  • Kode otorisasi tidak diperlukan.
  • Token akses diperoleh langsung melalui izin aplikasi.

Token akses

Token akses adalah kumpulan properti (klaim) yang dikodekan Base64 yang ditandatangani yang menyampaikan informasi tentang identitas, peran, dan hak istimewa klien yang diberikan kepada pengguna atau klien.

Azure Health Data Services biasanya mengharapkan JSON Web Token. Ini terdiri dari tiga bagian:

  • Header
  • Payload (klaim)
  • Tanda tangan, seperti yang ditunjukkan pada gambar. Untuk informasi selengkapnya, lihat Token akses Azure.

Cuplikan layar memperlihatkan tanda tangan token web

Gunakan alat online seperti https://jwt.ms untuk melihat konten token. Misalnya, Anda dapat melihat detail klaim.

Jenis klaim Nilai Catatan
aud https://xxx.fhir.azurehealthcareapis.com Mengidentifikasi penerima token yang dimaksud. Dalam id_tokens, audiens adalah ID Aplikasi dari aplikasi Anda, yang ditetapkan untuk aplikasi Anda di portal Microsoft Azure. Aplikasi Anda harus memvalidasi nilai ini dan menolak token jika nilainya tidak cocok.
iss https://sts.windows.net/{tenantid}/ Mengidentifikasi layanan token keamanan (STS) yang membangun dan mengembalikan token, dan penyewa Microsoft Entra tempat pengguna diautentikasi. Jika token dikeluarkan oleh titik akhir v2.0, URI berakhir di /v2.0. GUID yang menunjukkan bahwa pengguna adalah pengguna konsumen dari akun Microsoft adalah 9188040d-6c67-4c5b-b112-36a304b66dad. Aplikasi Anda harus menggunakan bagian GUID dari klaim untuk membatasi kumpulan penyewa yang dapat masuk ke aplikasi, jika berlaku.
iat (stempel waktu) "Issued At" (Dikeluarkan Pada) menunjukkan kapan autentikasi untuk token ini terjadi.
nbf (stempel waktu) Klaim "nbf" (bukan sebelumnya) mengidentifikasi waktu sebelumnya yang di mana JWT TIDAK BOLEH diterima untuk diproses.
exp (stempel waktu) Klaim "exp" (waktu kedaluwarsa) mengidentifikasi waktu kedaluwarsa pada atau setelahnya yang di mana JWT TIDAK BOLEH diterima untuk diproses. Sumber daya mungkin menolak token sebelum waktu ini, misalnya jika perubahan autentikasi diperlukan, atau pencabutan token terdeteksi.
aio E2ZgYxxx Klaim internal yang digunakan oleh ID Microsoft Entra untuk merekam data untuk penggunaan kembali token. Harus diabaikan.
appid e97e1b8c-xxx ID aplikasi klien yang menggunakan token. Aplikasi dapat bertindak sebagai dirinya sendiri atau atas nama pengguna. ID aplikasi biasanya mewakili objek aplikasi, tetapi juga dapat mewakili objek perwakilan layanan di ID Microsoft Entra.
appidacr 1 Menunjukkan bagaimana klien diautentikasi. Untuk klien publik, nilainya adalah 0. Jika ID klien dan rahasia klien digunakan, nilainya adalah 1. Jika sertifikat klien digunakan untuk autentikasi, nilainya adalah 2.
idp https://sts.windows.net/{tenantid}/ Merekam penyedia identitas yang mengautentikasi subjek token. Nilai ini identik dengan nilai klaim Pengeluar Sertifikat kecuali akun pengguna tidak berada di penyewa yang sama dengan penerbit - tamu, misalnya. Jika klaim tidak ada, itu berarti bahwa nilai iss dapat digunakan sebagai gantinya. Untuk akun pribadi yang digunakan dalam konteks organisasi (misalnya, akun pribadi yang diundang ke penyewa Microsoft Entra), klaim idp mungkin 'live.com' atau URI STS yang berisi penyewa akun Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
oid Misalnya, tenantid Pengidentifikasi yang tidak dapat diubah untuk objek dalam sistem identitas Microsoft, dalam hal ini, akun pengguna. ID ini secara unik mengidentifikasi pengguna di seluruh aplikasi - dua aplikasi berbeda yang masuk ke pengguna yang sama menerima nilai yang sama dalam klaim oid. Microsoft Graph mengembalikan ID ini sebagai properti ID untuk akun pengguna tertentu. Karena oid memungkinkan beberapa aplikasi untuk menghubungkan pengguna, cakupan profil diperlukan untuk menerima klaim ini. Catatan: Jika satu pengguna ada di beberapa penyewa, pengguna berisi ID objek yang berbeda di setiap penyewa - mereka dianggap akun yang berbeda, meskipun pengguna masuk ke setiap akun dengan kredensial yang sama.
rh 0.ARoxxx Klaim internal yang digunakan azure untuk memrevalidasi ulang token. Ini harus diabaikan.
sub Misalnya, tenantid Ini adalah perwakilan yang tokennya menegaskan informasi, seperti pengguna aplikasi. Nilai ini tidak dapat diubah dan tidak dapat ditetapkan kembali atau digunakan kembali. Subjek adalah pengidentifikasi berpasangan - ini unik untuk ID aplikasi tertentu. Oleh karena itu, jika satu pengguna masuk ke dua aplikasi berbeda menggunakan dua ID klien yang berbeda, aplikasi tersebut menerima dua nilai berbeda untuk klaim subjek. Anda mungkin tidak menginginkan hasil ini tergantung pada arsitektur dan persyaratan privasi Anda.
tid Misalnya, tenantid GUID yang mewakili penyewa Microsoft Entra tempat pengguna berasal. Untuk akun kantor dan sekolah, GUID adalah ID penyewa yang tidak dapat diubah dari organisasi tempat pengguna berada. Untuk akun pribadi, nilainya adalah 9188040d-6c67-4c5b-b112-36a304b66dad. Cakupan profil diperlukan untuk menerima klaim ini.
uti bY5glsxxx Klaim internal yang digunakan azure untuk memrevalidasi ulang token. Ini harus diabaikan.
ver 1 Menunjukkan versi token.

Token akses berlaku selama satu jam secara default. Anda dapat memperoleh token baru atau memperbaruinya menggunakan token refresh sebelum kedaluwarsa.

Untuk mendapatkan token akses, Anda dapat menggunakan alat seperti Postman, ekstensi Klien REST di Visual Studio Code, PowerShell, CLI, curl, dan pustaka autentikasi Microsoft Entra.

Enkripsi

Saat Anda membuat layanan baru Azure Health Data Services, data Anda dienkripsi menggunakan kunci yang dikelola Microsoft secara default.

  • Layanan FHIR menyediakan enkripsi data tidak aktif saat data disimpan di penyimpanan data.
  • Layanan DICOM menyediakan enkripsi data tidak aktif saat data pencitraan termasuk metadata yang disematkan disimpan di penyimpanan data. Ketika metadata diekstrak dan disimpan dalam layanan FHIR, metadata dienkripsi secara otomatis.
  • Layanan MedTech, setelah pemetaan dan normalisasi data, mempertahankan pesan perangkat ke layanan FHIR, yang dienkripsi secara otomatis. Dalam kasus di mana pesan perangkat dikirim ke Azure Event Hubs, yang menggunakan Azure Storage untuk menyimpan data, data secara otomatis dienkripsi dengan Azure Storage Service Encryption (Azure SSE).

Langkah berikutnya

Menyebarkan ruang kerja Azure Health Data Services dengan menggunakan portal Azure

Menggunakan Azure Active Directory B2C untuk memberikan akses ke layanan FHIR

Catatan

FHIR® adalah merek dagang terdaftar HL7 dan digunakan dengan izin HL7.

DICOM® adalah merek dagang terdaftar dari Asosiasi Produsen Listrik Nasional untuk publikasi Standar yang berkaitan dengan komunikasi digital informasi medis.