Autentikasi dan Otorisasi untuk Azure Health Data Services

  • Artikel
  • 7 menit untuk membaca

Autentikasi

Azure Health Data Services adalah kumpulan layanan terkelola aman menggunakan Azure Active Directory (Azure AD),idP global yang mendukung OAuth 2.0.

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

Azure Health Data Services tidak mendukung penyedia identitas lain. Namun, pelanggan dapat menggunakan penyedia identitas mereka sendiri untuk mengamankan aplikasi, dan memungkinkan mereka berinteraksi dengan Layanan Data Kesehatan dengan mengelola aplikasi klien dan kontrol akses data pengguna.

Aplikasi klien terdaftar di Azure ACTIVE Directory 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 diberikan dengan peran aplikasi yang tepat.

Layanan FHIR dari Azure Health Data Services menyediakan peran berikut:

  • Pembaca Data FHIR: Dapat membaca (dan mencari) data FHIR.
  • Penulis Data FHIR: Dapat membaca, menulis, dan menghapus sementara data FHIR.
  • Pengekspor Data FHIR: Dapat membaca dan mengekspor data (operator $export).
  • Kontributor Data FHIR: Dapat melakukan semua operasi data plane.
  • FHIR Data Converter: Dapat menggunakan pengonversi untuk melakukan konversi data.

Layanan DICOM dari Azure Health Data Services menyediakan peran berikut:

  • Pemilik Data DICOM: Dapat membaca, menulis, dan menghapus data DICOM.
  • Baca Data DICOM: Dapat 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 pelanggan.

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 Azure AD, 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 Azure ACTIVE Directory: alur kode otorisasi dan alur kredensial klien.

Untuk mendapatkan token akses untuk Azure Health Data Services, berikut adalah langkah-langkah menggunakan alur kode otorisasi:

  1. Klien mengirim permintaan ke titik akhir otorisasi Azure ACTIVE Directory. Azure AD 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. Azure AD hanya memungkinkan kode otorisasi ini dikembalikan ke URL balasan terdaftar yang dikonfigurasi dalam pendaftaran aplikasi klien.

  2. Aplikasi klien menukar kode otorisasi dengan token akses di titik akhir token Azure ACTIVE Directory. Saat meminta token, aplikasi klien 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 di layanan FHIR. Saat membuat permintaan, itu termasuk 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 selesai 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 di bawah ini. Untuk informasi selengkapnya, lihat Token akses Azure.

JASON web token signature.

Anda dapat menggunakan 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 (Security Token Service - STS) yang membangun dan mengembalikan token, dan penyewa Microsoft Azure AD tempat pengguna diautentikasi. Jika token dikeluarkan oleh titik akhir v2.0, URI akan 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" (tidak sebelumnya) mengidentifikasi waktu yang sebelumnya JWT TIDAK BOLEH diterima untuk diproses.
exp (stempel waktu) Klaim "exp" (waktu kedaluwarsa) mengidentifikasi waktu kedaluwarsa yang pada atau setelahnya JWT TIDAK BOLEH diterima untuk pemrosesan. Penting untuk dicatat bahwa sumber daya dapat menolak token sebelum waktu ini juga, jika misalnya, perubahan autentikasi diperlukan, atau pencabutan token telah terdeteksi.
aio E2ZgYxxx Klaim internal yang digunakan Microsoft Azure AD untuk merekam data untuk penggunaan kembali token. Harus diabaikan.
appid e97e1b8c-xxx Ini adalah 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 Azure AD.
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 dalam 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 Azure AD), klaim idp mungkin 'live.com' atau URI STS yang berisi penyewa akun Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
oid Misalnya, tenantid Ini adalah 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 akan menerima nilai yang sama dalam klaim oid. Microsoft Graph akan 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 akan berisi ID objek yang berbeda di setiap penyewa - mereka dianggap sebagai 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 yang berbeda menggunakan dua ID klien yang berbeda, aplikasi tersebut akan menerima dua nilai berbeda untuk klaim subjek. Ini mungkin atau mungkin tidak diinginkan tergantung pada arsitektur dan persyaratan privasi Anda.
tid Misalnya, tenantid GUID yang mewakili penyewa Microsoft Azure AD asal pengguna. 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 Azure ACTIVE Directory.

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 tetap ada di penyimpanan data. Ketika metadata diekstrak dan dipertahankan 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

Dalam dokumen ini, Anda mempelajari autentikasi dan otorisasi Azure Health Data Services. Untuk mempelajari cara menyebarkan instans Azure Health Data Services, lihat

Menyebarkan ruang kerja Azure Health Data Services menggunakan portal Microsoft Azure

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