Share via

المصادقة والتخويل لخدمات بيانات Azure Health

  • مقالة

المصادقة

Azure Health Data Services هي مجموعة من الخدمات المدارة الآمنة باستخدام معرف Microsoft Entra، وهو موفر هوية عمومي يدعم OAuth 2.0.

لكي تتمكن Azure Health Data Services من الوصول إلى موارد Azure، مثل حسابات التخزين ومراكز الأحداث، تحتاج إلى تمكين الهوية المدارة للنظام ومنح الأذونات المناسبة للهوية المدارة. لمزيد من المعلومات، راجع الهويات المدارة من Azure.

يتم تسجيل تطبيقات العميل في معرف Microsoft Entra ويمكن استخدامها للوصول إلى Azure Health Data Services. يتم تنفيذ عناصر التحكم في الوصول إلى بيانات المستخدم في التطبيقات أو الخدمات التي تنفذ منطق العمل.

أدوار التطبيق

يجب تعيين المستخدمين المصادق عليهم وتطبيقات العميل لخدمات بيانات Azure Health إلى دور التطبيق المناسب.

توفر خدمة FHIR® في Azure Health Data Services هذه الأدوار:

  • قارئ بيانات FHIR: قراءة بيانات FHIR والبحث فيها.
  • كاتب بيانات FHIR: قراءة بيانات FHIR وكتابتها وحذفها مبدئيا.
  • مصدر بيانات FHIR: قراءة وتصدير (عامل تشغيل $export).
  • مستورد بيانات FHIR: قراءة واستيراد (عامل تشغيل $import).
  • مساهم بيانات FHIR: تنفيذ جميع عمليات مستوى البيانات.
  • محول بيانات FHIR: استخدم المحول لإجراء تحويل البيانات.
  • مستخدم FHIR SMART: يسمح للمستخدم بقراءة وكتابة بيانات FHIR وفقا لمواصفات SMART IG V1.0.0.

توفر خدمة DICOM® في Azure Health Data Services الأدوار التالية:

  • مالك بيانات DICOM: قراءة بيانات DICOM وكتابتها وحذفها.
  • قراءة بيانات DICOM: قراءة بيانات DICOM.

لا تتطلب خدمة MedTech أدوار التطبيق، ولكنها تعتمد على Azure Event Hubs Data Receiver لاسترداد البيانات المخزنة في مركز الأحداث لاشتراك مؤسستك.

التصريح

بعد منح أدوار التطبيق المناسبة، يمكن للمستخدمين المصادق عليهم وتطبيقات العميل الوصول إلى Azure Health Data Services عن طريق الحصول على رمز وصول صالح صادر عن معرف Microsoft Entra، وتنفيذ عمليات محددة تحددها أدوار التطبيق.

  • بالنسبة لخدمة FHIR، يكون الرمز المميز للوصول خاصا بالخدمة أو المورد.
  • بالنسبة لخدمة DICOM، يتم منح رمز الوصول المميز للمورد dicom.healthcareapis.azure.com ، وليس خدمة معينة.
  • بالنسبة لخدمة MedTech، لا يلزم رمز الوصول المميز لأنه لا يتعرض للمستخدمين أو تطبيقات العميل.

خطوات التخويل

هناك طريقتان شائعتان للحصول على رمز مميز للوصول، تم توضيحهما بالتفصيل بواسطة وثائق Microsoft Entra: تدفق رمز التخويل وتدفق بيانات اعتماد العميل.

فيما يلي كيفية الحصول على رمز وصول لخدمات بيانات Azure Health باستخدام تدفق رمز التخويل:

  1. يرسل العميل طلبا إلى نقطة نهاية تخويل Microsoft Entra. يعيد معرف Microsoft Entra توجيه العميل إلى صفحة تسجيل الدخول حيث يصادق المستخدم باستخدام بيانات الاعتماد المناسبة (على سبيل المثال: اسم المستخدم وكلمة المرور أو مصادقة ثنائية). عند المصادقة الناجحة، يتم إرجاع رمز التخويل إلى العميل. يسمح Microsoft Entra-only بإعادة رمز التخويل هذا إلى عنوان URL للرد المسجل الذي تم تكوينه في تسجيل تطبيق العميل.

  2. يتبادل تطبيق العميل رمز التخويل لرمز مميز للوصول في نقطة نهاية الرمز المميز ل Microsoft Entra. عندما يطلب تطبيق العميل رمزا مميزا، قد يتعين على التطبيق توفير سر العميل (والذي يمكنك إضافته أثناء تسجيل التطبيق).

  3. يقدم العميل طلبا إلى Azure Health Data Services، على سبيل المثال، GET طلب للبحث في جميع المرضى في خدمة FHIR. يتضمن الطلب الرمز المميز للوصول في HTTP عنوان طلب، على سبيل المثال، Authorization: Bearer xxx.

  4. تتحقق Azure Health Data Services من أن الرمز المميز يحتوي على مطالبات مناسبة (خصائص في الرمز المميز). إذا كان صالحا، فإنه يكمل الطلب ويعيد البيانات إلى العميل.

في تدفق بيانات اعتماد العميل، يتم منح الأذونات مباشرة إلى التطبيق نفسه. عندما يقدم التطبيق رمزا مميزا لمورد، يفرض المورد أن التطبيق نفسه لديه تخويل لتنفيذ إجراء نظرا لعدم وجود مستخدم مشارك في المصادقة. لذلك، يختلف عن تدفق رمز التخويل بهذه الطرق:

  • لا يحتاج المستخدم أو العميل إلى تسجيل الدخول بشكل تفاعلي.
  • رمز التخويل غير مطلوب.
  • يتم الحصول على الرمز المميز للوصول مباشرة من خلال أذونات التطبيق.

الرمز المميز للوصول

الرمز المميز للوصول عبارة عن مجموعة موقعة مشفرة من Base64 من الخصائص (المطالبات) التي تنقل معلومات حول هوية العميل وأدواره وامتيازاته الممنوحة للمستخدم أو العميل.

تتوقع Azure Health Data Services عادة رمز ويب JSON المميز. ويتكون من ثلاثة أجزاء:

  • الرأس
  • البيانات الأساسية (المطالبات)
  • التوقيع، كما هو موضح في الصورة. لمزيد من المعلومات، راجع الرموز المميزة للوصول إلى Azure.

لقطة شاشة تعرض توقيع الرمز المميز للويب

استخدم أدوات عبر الإنترنت مثل https://jwt.ms لعرض محتوى الرمز المميز. على سبيل المثال، يمكنك عرض تفاصيل المطالبات.

نوع المطالبة القيمة ملاحظات
aud https://xxx.fhir.azurehealthcareapis.com تحديد المستلم المقصود للرمز المميز. في id_tokens، يكون الجمهور هو معرف التطبيق الخاص بتطبيقك، المعين لتطبيقك في مدخل Microsoft Azure. يجب أن يتحقق تطبيقك من صحة هذه القيمة ويرفض الرمز المميز إذا لم تتطابق القيمة.
iss https://sts.windows.net/{tenantid}/ تعريف خدمة رمز الأمان المميز (STS) التي تقوم بإنشاء الرمز المميز وإرجاعه، ومستأجر Microsoft Entra الذي تمت مصادقة المستخدم فيه. إذا تم إصدار الرمز المميز بواسطة نقطة النهاية v2.0، ينتهي URI ب /v2.0. معرّف GUID الفريد الذي يشير إلى أن المستخدم يُعد مستخدماً مستهلكاً من حساب Microsoft وهو 9188040d-6c67-4c5b-b112-36a304b66dad. يجب أن يستخدم تطبيقك جزء GUID من المطالبة لتقييد مجموعة المستأجرين الذين يمكنهم تسجيل الدخول إلى التطبيق، إذا كان ذلك ممكنا.
iat (طابع زمني) تُشير عبارة "تم الإصدار في" إلى وقت حدوث المصادقة لهذا الرمز المميز.
nbf (طابع زمني) تحدد مطالبة "nbf" (ليس قبل ذلك) الوقت الذي يجب قبله عدم قبول معيار JWT لإجراء معالجة.
exp (طابع زمني) تحدد مطالبة "exp" (وقت انتهاء الصلاحية) وقت انتهاء الصلاحية الذي يجب عدم قبول معيارمط JWT لإجراء معالجة أثناء سريان مفعوله أو بعد انتهاؤه. قد يرفض المورد الرمز المميز قبل هذا الوقت، على سبيل المثال إذا كان التغيير في المصادقة مطلوبا، أو تم الكشف عن إبطال رمز مميز.
aio E2ZgYxxx مطالبة داخلية يستخدمها معرف Microsoft Entra لتسجيل البيانات لإعادة استخدام الرمز المميز. ينبغي تجاهلها.
appid e97e1b8c-xxx معرف التطبيق الخاص بالعميل باستخدام الرمز المميز. ويمكن للتطبيق أن يتصرف على أنه نفسه أو نيابة عن أحد المستخدمين. يمثل معرف التطبيق عادة كائن تطبيق، ولكن يمكن أن يمثل أيضا كائن كيان الخدمة في معرف Microsoft Entra.
appidacr 1 يشير إلى كيفية مصادقة العميل. بالنسبة للعميل العام، القيمة هي 0. إذا تم استخدام معرف العميل وسر العميل، تكون القيمة 1. إذا تم استخدام شهادة عميل للمصادقة، تكون القيمة 2.
idp https://sts.windows.net/{tenantid}/ تسجيل موفر الهوية الذي قام بمصادقة موضوع الرمز المميز. هذه القيمة مطابقة لقيمة مطالبة المصدر ما لم يكن حساب المستخدم في نفس المستأجر مثل المصدر - الضيوف، على سبيل المثال. إذا لم تكن المطالبة موجودة، فهذا يعني أنه يمكن استخدام قيمة iss بدلا من ذلك. بالنسبة للحسابات الشخصية المستخدمة في سياق تنظيمي (على سبيل المثال، حساب شخصي تمت دعوته إلى مستأجر Microsoft Entra)، قد تكون مطالبة idp "live.com" أو URI STS يحتوي على مستأجر حساب Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
معرف العنصر على سبيل المثال، tenantid المعرف الثابت لكائن في نظام هوية "Microsoft"، في هذه الحالة، حساب مستخدم. يعرف هذا المعرف المستخدم بشكل فريد عبر التطبيقات - يتلقى تطبيقان مختلفان يقومان بتسجيل الدخول إلى نفس المستخدم نفس القيمة في مطالبة oid. يقوم Microsoft Graph بإرجاع هذا المعرف كخاصية معرف لحساب مستخدم معين. نظرا لأن الoid يسمح لتطبيقات متعددة بربط المستخدمين، فإن نطاق ملف التعريف مطلوب لتلقي هذه المطالبة. ملاحظة: إذا كان مستخدم واحد موجودا في عدة مستأجرين، فإن المستخدم يحتوي على معرف عنصر مختلف في كل مستأجر - يتم اعتباره حسابات مختلفة، على الرغم من أن المستخدم يسجل الدخول إلى كل حساب بنفس بيانات الاعتماد.
rh 0.ARoxxx مطالبة داخلية يستخدمها Azure لإعادة التحقق من صحة الرموز المميزة. يجب تجاهله.
فرعي على سبيل المثال، tenantid المبدأ الذي يؤكد الرمز المميز حوله المعلومات، مثل مستخدم التطبيق. هذه القيمة غير قابلة للتغيير ولا يمكن إعادة تعيينها أو إعادة استخدامها. الموضوع هو معرف مزدوج - إنه فريد لمعرف تطبيق معين. لذلك، إذا سجل مستخدم واحد الدخول إلى تطبيقين مختلفين باستخدام معرفين مختلفين للعميل، تتلقى هذه التطبيقات قيمتين مختلفتين لمطالبة الموضوع. قد لا ترغب في هذه النتيجة استنادا إلى متطلبات البنية والخصوصية الخاصة بك.
tid على سبيل المثال، tenantid المعرف الفريد العمومي (GUID) الذي يمثل مستأجر Microsoft Entra الذي يستخدمه المستخدم. بالنسبة لحسابات العمل والمدرسة، فإن GUID هو معرف المستأجر غير القابل للتغيير للمؤسسة التي ينتمي إليها المستخدم. بالنسبة للحسابات الشخصية، القيمة هي 9188040d-6c67-4c5b-b112-36a304b66dad. نطاق ملف التعريف مطلوب لتلقي هذه المطالبة.
uti bY5glsxxx مطالبة داخلية يستخدمها Azure لإعادة التحقق من صحة الرموز المميزة. يجب تجاهله.
ver 1 يشير إلى إصدار الرمز المميز.

الرمز المميز للوصول صالح لمدة ساعة واحدة بشكل افتراضي. يمكنك الحصول على رمز مميز جديد أو تجديده باستخدام رمز التحديث المميز قبل انتهاء صلاحيته.

للحصول على رمز مميز للوصول، يمكنك استخدام أدوات مثل Postman وملحق عميل REST في Visual Studio Code وPowerShell وCLI و curl ومكتبات مصادقة Microsoft Entra.

التشفير

عند إنشاء خدمة جديدة من Azure Health Data Services، يتم تشفير بياناتك باستخدام مفاتيح تديرها Microsoft بشكل افتراضي.

  • توفر خدمة FHIR تشفير البيانات الثابتة عند استمرار البيانات في مخزن البيانات.
  • توفر خدمة DICOM تشفير البيانات الثابتة عند استمرار بيانات التصوير بما في ذلك بيانات التعريف المضمنة في مخزن البيانات. عند استخراج بيانات التعريف واستمرارها في خدمة FHIR، يتم تشفيرها تلقائيا.
  • تستمر خدمة MedTech، بعد تعيين البيانات وتطبيعها، في إرسال رسائل الجهاز إلى خدمة FHIR، التي يتم تشفيرها تلقائيا. في الحالات التي يتم فيها إرسال رسائل الجهاز إلى Azure Event Hubs، والتي تستخدم Azure Storage لتخزين البيانات، يتم تشفير البيانات تلقائيا باستخدام تشفير خدمة تخزين Azure (Azure SSE).

الخطوات التالية

نشر مساحة عمل Azure Health Data Services باستخدام مدخل Microsoft Azure

استخدام Azure Active Directory B2C لمنح حق الوصول إلى خدمة FHIR

إشعار

FHIR® هي علامة تجارية مسجلة ل HL7 وتستخدم بإذن من HL7.

DICOM® هي العلامة التجارية المسجلة للجمعية الوطنية لمصنعي الكهرباء لمنشورات المعايير المتعلقة بالاتصالات الرقمية للمعلومات الطبية.