إطار الأمان: المصادقة | التخفيفات من المخاطر

المنتج /الخدمة مقالة
تطبيق ويب
قاعدة بيانات
مركز الحدث Azure
Azure Trust Boundary
حدود الثقة في Service Fabric
Identity Server
حد ثقة الجهاز
WCF
واجهة برمجة تطبيقات الويب
معرِّف Microsoft Entra
بوابة حقل IoT
بوابة سحابة IoT
تخزين Azure

ضع في اعتبارك استخدام آلية مصادقة قياسية للمصادقة على تطبيق الويب

‏‫العنوان التفاصيل
المكون تطبيق ويب
مرحلة SDL إنشاء
التقنيات المعمول بها العام
السمات ‏‫غير متوفر‬
المراجع ‏‫غير متوفر‬
التفاصيل

المصادقة هي العملية التي يثبت فيها الكيان هويته، عادةً من خلال معلومات تسجيل الدخول، مثل اسم المستخدم وكلمة المرور. هناك بروتوكولات مصادقة متعددة متاحة والتي يمكن أخذها في الاعتبار. بعضها مذكور أدناه:

  • شهادات العميل
  • ويندوز مقرها
  • النماذج القائمة
  • الاتحاد - ADFS
  • الاتحاد - معرف Microsoft Entra
  • الاتحاد - خادم الهوية

ضع في اعتبارك استخدام آلية مصادقة قياسية لتحديد عملية المصدر

يجب أن تتعامل التطبيقات بشكل آمن مع سيناريوهات المصادقة الفاشلة

‏‫العنوان التفاصيل
المكون تطبيق ويب
مرحلة SDL إنشاء
التقنيات المعمول بها العام
السمات ‏‫غير متوفر‬
المراجع ‏‫غير متوفر‬
التفاصيل

يجب أن تتعامل التطبيقات التي تصادق المستخدمين بشكل صريح مع سيناريوهات المصادقة الفاشلة بشكل آمن. يجب أن تكون آلية المصادقة:

  • رفض الوصول إلى الموارد المميزة عند فشل المصادقة
  • عرض رسالة خطأ عامة بعد حدوث فشل في المصادقة ورفض الوصول

اختبار ل:

  • حماية الموارد المميزة بعد فشل عمليات تسجيل الدخول
  • يتم عرض رسالة خطأ عامة عند فشل المصادقة وحدث (أحداث) رفض الوصول
  • تم تعطيل الحسابات بعد عدد كبير من المحاولات الفاشلة

    تمكين مصادقة الإعداد أو المصادقة التكيفية

    ‏‫العنوان التفاصيل
    المكون تطبيق ويب
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع ‏‫غير متوفر‬
    التفاصيل

    تحقق من أن التطبيق لديه تخويل إضافي (مثل المصادقة المتقدمة أو التكيفية، عبر المصادقة متعددة العوامل مثل إرسال OTP في الرسائل القصيرة أو البريد الإلكتروني وما إلى ذلك أو المطالبة بإعادة المصادقة) بحيث يتم تحدي المستخدم قبل منحه حق الوصول إلى المعلومات الحساسة. تنطبق هذه القاعدة أيضاً على إجراء تغييرات مهمة على حساب أو إجراء

    هذا يعني أيضاً أنه يجب تنفيذ تكييف المصادقة بطريقة يفرض فيها التطبيق بشكل صحيح ترخيصاً حساساً للسياق بحيث لا يسمح بالتمشغل غير المصرح به عن طريق، على سبيل المثال، التمشغل بالمعلمات

    تأكد من تأمين الواجهات الإدارية بشكل مناسب

    ‏‫العنوان التفاصيل
    المكون تطبيق ويب
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع ‏‫غير متوفر‬
    التفاصيل الحل الأول هو منح الوصول فقط من نطاق IP مصدر معين إلى الواجهة الإدارية. إذا لم يكن هذا الحل ممكنا، فمن المستحسن دائما فرض مصادقة تصعيدية أو تكيفية لتسجيل الدخول إلى الواجهة الإدارية

    تنفيذ وظائف نسيت كلمة المرور بشكل آمن

    ‏‫العنوان التفاصيل
    المكون تطبيق ويب
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع ‏‫غير متوفر‬
    التفاصيل

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

    قد يؤدي هذا إلى هجوم رفض الخدمة عندما يقرر المهاجم تعمد تأمين المستخدمين بهجوم آلي. ثالثاً، كلما تم تعيين طلب كلمة المرور الجديدة قيد التقدم، يجب تعميم الرسالة التي تعرضها لمنع تعداد اسم المستخدم. رابعاً، لا تسمح دائماً باستخدام كلمات المرور القديمة وتطبيق نهج كلمات مرور قوية.

    تأكد من تنفيذ نهج الحساب وكلمة المرور

    ‏‫العنوان التفاصيل
    المكون تطبيق ويب
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع ‏‫غير متوفر‬
    التفاصيل

    يجب تنفيذ نهج كلمة المرور والحساب وفقاً للنهج التنظيمية وأفضل الممارسات.

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

    قد يتم تنفيذ نهج تأمين الحساب بالطريقة التالية:

    • تأمين ناعم: يمكن أن يكون هذا خياراً جيداً لحماية المستخدمين من هجمات القوة الغاشمة. على سبيل المثال، عندما يقوم المستخدم بإدخال كلمة مرور خاطئة ثلاث مرات، يمكن للتطبيق قفل الحساب لمدة دقيقة من أجل إبطاء عملية الإجبار الغاشم على كلمة المرور الخاصة به مما يجعل استمرار المهاجم أقل ربحية. إذا كنت ستنفذ إجراءات مضادة للإغلاق الصارم في هذا المثال، فستحقق "DoS" من خلال إغلاق الحسابات بشكل دائم. بدلا من ذلك، قد يقوم التطبيق بإنشاء OTP (كلمة مرور لمرة واحدة) وإرسالها خارج النطاق (من خلال البريد الإلكتروني والرسائل القصيرة وما إلى ذلك) إلى المستخدم. قد يكون هناك نهج آخر هو تنفيذ CAPTCHA بعد الوصول إلى الحد الأدنى لعدد المحاولات الفاشلة.
    • حظر صارم: يجب تطبيق هذا النوع من الحظر عندما تكتشف مستخدماً يهاجم تطبيقك ويواجههم عن طريق إغلاق حساباتهم بشكل دائم إلى أن يتاح لفريق الاستجابة الوقت الكافي للقيام بالأدلة الجنائية الخاصة بهم. بعد هذه العملية، يمكنك أن تقرر إعادة حساب المستخدم أو اتخاذ مزيد من الإجراءات القانونية ضده. يمنع هذا النوع من النهج المهاجم من اختراق تطبيقك وبنيتك الأساسية بشكل أكبر.

    للدفاع ضد الهجمات على الحسابات الافتراضية والمتوقعة، تحقق من أن جميع المفاتيح وكلمات المرور قابلة للاستبدال، وأنه تم إنشاؤها أو استبدالها بعد وقت التثبيت.

    إذا كان على التطبيق إنشاء كلمات مرور تلقائياً، فتأكد من أن كلمات المرور التي تم إنشاؤها عشوائية ولها إنتروبيا عالية.

    تنفيذ عناصر التحكم لمنع تعداد اسم المستخدم

    ‏‫العنوان التفاصيل
    المكون تطبيق ويب
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع ‏‫غير متوفر‬
    الخطوات يجب تعميم جميع رسائل الخطأ لمنع تعداد اسم المستخدم. أيضا في بعض الأحيان لا يمكنك تجنب تسرب المعلومات في وظائف مثل صفحة التسجيل. تحتاج هنا إلى استخدام طرق تحديد المعدل مثل CAPTCHA لمنع هجوم آلي من قبل المهاجم.

    عندما يكون ذلك ممكناً، استخدم مصادقة Windows للاتصال بـ Microsoft SQL Server

    ‏‫العنوان التفاصيل
    المكون قاعدة البيانات
    مرحلة SDL إنشاء
    التقنيات المعمول بها محلي
    السمات إصدار SQL - الكل
    المراجع Microsoft SQL Server - اختر وضع المصادقة
    الخطوات تستخدم مصادقة Windows بروتوكول أمان Kerberos، وتوفر فرض نهج كلمة المرور فيما يتعلق بالتحقق من صحة التعقيد لكلمات المرور القوية، وتوفر الدعم لقفل الحساب، وتدعم انتهاء صلاحية كلمة المرور.

    عندما يكون ذلك ممكنا، استخدم مصادقة Microsoft Entra للاتصال بقاعدة بيانات SQL

    ‏‫العنوان التفاصيل
    المكون قاعدة البيانات
    مرحلة SDL إنشاء
    التقنيات المعمول بها SQL Azure
    السمات إصدار SQL - الإصدار 12
    المراجع الاتصال بقاعدة بيانات SQL باستخدام مصادقة Microsoft Entra
    الخطوات الحد الأدنى من الإصدار: مطلوب Azure SQL Database V12 للسماح لقاعدة بيانات Azure SQL باستخدام مصادقة Microsoft Entra مقابل دليل Microsoft

    عند استخدام وضع مصادقة SQL، تأكد من فرض نهج الحساب وكلمة المرور على خادم SQL

    ‏‫العنوان التفاصيل
    المكون قاعدة البيانات
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع نهج كلمة مرور Microsoft SQL Server
    الخطوات عند استخدام مصادقة SQL Server، يتم إنشاء عمليات تسجيل الدخول في SQL Server التي لا تستند إلى حسابات مستخدمي Windows. يتم إنشاء اسم المستخدم وكلمة المرور باستخدام SQL Server وتخزينهما في SQL Server. يمكن لـ SQL Server استخدام آليات نهج كلمة مرور Windows. يمكنه تطبيق نفس التعقيد ونُهج انتهاء الصلاحية المستخدمة في Windows على كلمات المرور المستخدمة داخل SQL Server.

    لا تستخدم مصادقة SQL في قواعد البيانات المضمنة

    ‏‫العنوان التفاصيل
    المكون قاعدة البيانات
    مرحلة SDL إنشاء
    التقنيات المعمول بها محلي، SQL Azure
    السمات إصدار SQL - MSSQL2012، إصدار SQL - V12.0
    المراجع أفضل ممارسات الأمان مع قواعد البيانات المضمنة
    الخطوات قد يؤدي عدم وجود نهج كلمة مرور مفروضة إلى زيادة احتمال إنشاء بيانات اعتماد ضعيفة في قاعدة بيانات مضمنة. الاستفادة من مصادقة Windows.

    استخدام بيانات اعتماد المصادقة لكل جهاز باستخدام الرموز المميزة SaS

    ‏‫العنوان التفاصيل
    المكون مراكز أحداث Azure
    مرحلة SDL إنشاء
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع نظرة عامة على نموذج الأمان ومصادقة مراكز الأحداث
    الخطوات

    يعتمد نموذج أمان مراكز الأحداث على مجموعة من الرموز المميزة لتوقيع الوصول المشترك (SAS) وناشري الأحداث. يمثل اسم الناشر DeviceID الذي يتلقى الرمز المميز. سيساعد هذا في ربط الرموز المميزة التي تم إنشاؤها بالأجهزة المعنية.

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

    تمكين مصادقة Microsoft Entra متعددة العوامل لمسؤولي Azure

    ‏‫العنوان التفاصيل
    المكون Azure Trust Boundary
    مرحلة SDL التوزيع
    التقنيات المعمول بها العام
    السمات ‏‫غير متوفر‬
    المراجع ما هي مصادقة Microsoft Entra متعددة العوامل؟
    الخطوات

    المصادقة متعددة العوامل (MFA) هي طريقة مصادقة تتطلب أكثر من طريقة تحقق واحدة وتضيف طبقة ثانية هامة من الأمان إلى عمليات تسجيل دخول المستخدم والمعاملات. إنه يعمل عن طريق طلب أي طريقتين أو أكثر من طرق التحقق التالية:

    • شيء تعرفه (عادة كلمة مرور)
    • شيء لديك (جهاز موثوق به لا يتم تكراره بسهولة، مثل الهاتف)
    • شيء أنت (القياسات الحيوية)

      تقييد الوصول المجهول إلى Service Fabric Cluster

      ‏‫العنوان التفاصيل
      المكون حدود الثقة في Service Fabric
      مرحلة SDL التوزيع
      التقنيات المعمول بها العام
      السمات البيئة - Azure
      المراجع سيناريوهات أمان نظام مجموعة Service Fabric
      الخطوات

      يجب تأمين المجموعات دائماً لمنع المستخدمين غير المصرح لهم من الاتصال بالمجموعة الخاصة بك، خاصةً عندما يكون لديها أعباء إنتاج تعمل عليها.

      أثناء إنشاء مجموعة نسيج خدمة، تأكد من تعيين وضع الأمان على "آمن" وتكوين شهادة خادم X.509 المطلوبة. سيسمح إنشاء مجموعة "غير آمنة" لأي مستخدم مجهول بالاتصال بها إذا كان يعرض نقاط نهاية الإدارة للإنترنت العام.

      تأكد من اختلاف شهادة عميل إلى عقدة Service Fabric عن شهادة عقده إلى عقدة

      ‏‫العنوان التفاصيل
      المكون حدود الثقة في Service Fabric
      مرحلة SDL التوزيع
      التقنيات المعمول بها العام
      السمات البيئة - Azure، البيئة - قائمة بذاتها
      المراجع أمان شهادة عميل إلى عقدة Service Fabric، الاتصال بمجموعة آمنة باستخدام شهادة العميل
      الخطوات

      يتم تكوين أمان الشهادة من عميل إلى عقدة أثناء إنشاء المجموعة إما من خلال مدخل Microsoft Azure أو قوالب إدارة الموارد أو قالب JSON مستقل عن طريق تحديد شهادة عميل المسؤول و/أو شهادة عميل المستخدم.

      يجب أن تكون شهادات عميل المسؤول وعميل المستخدم التي تحددها مختلفة عن الشهادات الأساسية والثانوية التي تحددها لأمان Node-to-node.

      استخدام معرف Microsoft Entra لمصادقة العملاء على مجموعات نسيج الخدمة

      ‏‫العنوان التفاصيل
      المكون حدود الثقة في Service Fabric
      مرحلة SDL التوزيع
      التقنيات المعمول بها العام
      السمات البيئة - Azure
      المراجع سيناريوهات أمان المجموعة - توصيات الأمان
      الخطوات يمكن للمجموعات التي تعمل على Azure أيضا تأمين الوصول إلى نقاط نهاية الإدارة باستخدام معرف Microsoft Entra، بصرف النظر عن شهادات العميل. بالنسبة لمجموعات Azure، يوصى باستخدام أمان Microsoft Entra لمصادقة العملاء والشهادات لأمان العقدة إلى العقدة.

      تأكد من الحصول على شهادات Service Fabri من مرجع مصدق (CA) معتمد

      ‏‫العنوان التفاصيل
      المكون حدود الثقة في Service Fabric
      مرحلة SDL التوزيع
      التقنيات المعمول بها العام
      السمات البيئة - Azure
      المراجع شهادات X.509 وService Fabric
      الخطوات

      تستخدم Service Fabric شهادات خادم X.509 لمصادقة العقد والعملاء.

      بعض الأشياء المهمة التي يجب مراعاتها أثناء استخدام الشهادات في أقمشة الخدمة:

      • يجب إنشاء الشهادات المستخدمة في المجموعات التي تقوم بتشغيل أحمال عمل الإنتاج باستخدام خدمة شهادة Windows Server تم تكوينها بشكل صحيح أو الحصول عليها من مرجع مصدق (CA) معتمد. يمكن أن يكون المرجع المصدق (CA) عبارة عن مرجع مصدق خارجي معتمد أو بنية أساسية للمفتاح العام (PKI) داخلية مُدارة بشكل صحيح
      • لا تستخدم أبداً أي شهادات مؤقتة أو شهادات اختبار في الإنتاج التي تم إنشاؤها باستخدام أدوات مثل MakeCert.exe
      • يمكنك استخدام شهادة موقعة ذاتياً، ولكن يجب القيام بذلك فقط لمجموعات الاختبار وليس في الإنتاج

      استخدم سيناريوهات المصادقة القياسية التي يدعمها خادم الهوية

      ‏‫العنوان التفاصيل
      المكون خادم الهوية
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع IdentityServer3 - الصورة الكبيرة
      الخطوات

      فيما يلي التفاعلات النموذجية التي يدعمها خادم الهوية:

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

      تجاوز ذاكرة التخزين المؤقت الافتراضية لرمز خادم الهوية باستخدام بديل قابل لتغيير الحجم

      ‏‫العنوان التفاصيل
      المكون خادم الهوية
      مرحلة SDL التوزيع
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع توزيع خادم الهوية - التخزين المؤقت
      الخطوات

      IdentityServer لديها ذاكرة تخزين مؤقت بسيطة مدمجة في الذاكرة. في حين أن هذا مفيد للتطبيقات المحلية صغيرة الحجم، إلا إنه لا يتناسب مع تطبيقات الطبقة المتوسطة والخلفية للأسباب التالية:

      • يتم الوصول إلى هذه التطبيقات من قبل العديد من المستخدمين في وقت واحد. يؤدي حفظ جميع رموز الوصول في نفس المخزن إلى حدوث مشكلات في العزل ويطرح تحديات عند العمل على نطاق واسع: يمكن أن يعني العديد من المستخدمين، لكل منهم عدد كبير من الرموز المميزة مثل الموارد التي يصل إليها التطبيق نيابة عنهم، وأعداد ضخمة وعمليات بحث باهظة الثمن
      • يتم توزيع هذه التطبيقات عادةً على طوبولوجيا موزعة، حيث يجب أن يكون للعقد المتعددة حق الوصول إلى نفس ذاكرة التخزين المؤقت
      • يجب أن تنجو الرموز المميزة المخزنة مؤقتاً من عمليات إعادة التدوير وإلغاء التنشيط
      • لجميع الأسباب المذكورة أعلاه، أثناء تنفيذ تطبيقات الويب، يوصى بتجاوز ذاكرة التخزين المؤقت الافتراضية لخادم الهوية باستخدام بديل قابل لتغيير الحجم مثل Azure Cache for Redis

      تأكد من أن ثنائيات التطبيق التي تم توزيعها موقعة رقمياً

      ‏‫العنوان التفاصيل
      المكون حد ثقة الجهاز
      مرحلة SDL التوزيع
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع ‏‫غير متوفر‬
      الخطوات تأكد من توقيع ثنائيات التطبيق المنشور رقمياً بحيث يمكن التحقق من سلامة الثنائيات

      تمكين المصادقة عند الاتصال بقوائم انتظار MSMQ في WCF

      ‏‫العنوان التفاصيل
      المكون WCF
      مرحلة SDL إنشاء
      التقنيات المعمول بها عام، NET Framework 3
      السمات ‏‫غير متوفر‬
      المراجع MSDN
      الخطوات فشل البرنامج في تمكين المصادقة عند الاتصال بقوائم انتظار MSMQ، يمكن للمهاجم إرسال رسائل بشكل مجهول إلى قائمة الانتظار للمعالجة. إذا لم يتم استخدام المصادقة للاتصال بقائمة انتظار MSMQ المستخدمة لتسليم رسالة إلى برنامج آخر، يمكن للمهاجم إرسال رسالة مجهولة ضارة.

      مثال

      يرشد العنصر <netMsmqBinding/> لملف تكوين WCF أدناه إلى WCF لتعطيل المصادقة عند الاتصال بقائمة انتظار MSMQ لتسليم الرسالة.

      <bindings>
          <netMsmqBinding>
              <binding>
                  <security>
                      <transport msmqAuthenticationMode=""None"" />
                  </security>
              </binding>
          </netMsmqBinding>
      </bindings>
      

      قم بتكوين MSMQ لطلب مصادقة مجال Windows أو شهادة في جميع الأوقات لأي رسائل واردة أو صادرة.

      مثال

      يوجه العنصر <netMsmqBinding/> لملف تكوين WCF أدناه WCF لتمكين مصادقة الشهادة عند الاتصال بقائمة انتظار MSMQ. تمت مصادقة العميل باستخدام شهادات X.509. يجب أن تكون شهادة العميل موجودة في مخزن الشهادات الخاص بالخادم.

      <bindings>
          <netMsmqBinding>
              <binding>
                  <security>
                      <transport msmqAuthenticationMode=""Certificate"" />
                  </security>
              </binding>
          </netMsmqBinding>
      </bindings>
      

      WCF- لا تقم بتعيين Message clientCredentialType على لا شيء

      ‏‫العنوان التفاصيل
      المكون WCF
      مرحلة SDL إنشاء
      التقنيات المعمول بها .NET Framework 3
      السمات نوع بيانات اعتماد العميل - لا شيء
      المراجع MSDN، حصن
      الخطوات يعني عدم وجود المصادقة أن الجميع قادر على الوصول إلى هذه الخدمة. الخدمة التي لا تصادق على عملائها تسمح بالوصول إلى جميع المستخدمين. تكوين التطبيق للمصادقة مقابل بيانات اعتماد العميل. يمكن القيام بذلك عن طريق تعيين clientCredentialType للرسالة إلى Windows أو Certificate.

      مثال

      <message clientCredentialType=""Certificate""/>
      

      WCF- لا تقم بتعيين Transport clientCredentialType إلى لا شيء

      ‏‫العنوان التفاصيل
      المكون WCF
      مرحلة SDL إنشاء
      التقنيات المعمول بها عام، .NET Framework 3
      السمات نوع بيانات اعتماد العميل - لا شيء
      المراجع MSDN، حصن
      الخطوات يعني عدم وجود المصادقة أن الجميع قادر على الوصول إلى هذه الخدمة. الخدمة التي لا تصادق على عملائها تسمح لجميع المستخدمين بالوصول إلى وظائفها. تكوين التطبيق للمصادقة مقابل بيانات اعتماد العميل. يمكن القيام بذلك عن طريق تعيين نقل clientCredentialType إلى Windows أو Certificate.

      مثال

      <transport clientCredentialType=""Certificate""/>
      

      تأكد من استخدام تقنيات المصادقة القياسية لتأمين واجهات برمجة تطبيقات الويب

      ‏‫العنوان التفاصيل
      المكون واجهة API للويب
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع المصادقة والتفويض في ASP.NET Web API، خدمات المصادقة الخارجية باستخدام ASP.NET Web API (C#)
      الخطوات

      المصادقة هي العملية التي يثبت فيها الكيان هويته، عادةً من خلال معلومات تسجيل الدخول، مثل اسم المستخدم وكلمة المرور. هناك بروتوكولات مصادقة متعددة متاحة والتي يمكن أخذها في الاعتبار. بعضها مذكور أدناه:

      • شهادات العميل
      • ويندوز مقرها
      • النماذج القائمة
      • الاتحاد - ADFS
      • الاتحاد - معرف Microsoft Entra
      • الاتحاد - خادم الهوية

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

      استخدام سيناريوهات المصادقة القياسية التي يدعمها معرف Microsoft Entra

      ‏‫العنوان التفاصيل
      المكون Microsoft Entra ID
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع سيناريوهات المصادقة لمعرف Microsoft Entra ونماذج التعليمات البرمجية ل Microsoft Entra ودليل مطور Microsoft Entra
      الخطوات

      يبسط معرف Microsoft Entra المصادقة للمطورين من خلال توفير الهوية كخدمة، مع دعم البروتوكولات القياسية في الصناعة مثل OAuth 2.0 وOpenID Connect. فيما يلي سيناريوهات التطبيق الأساسية الخمسة المدعومة من قبل معرف Microsoft Entra:

      • مستعرض ويب إلى تطبيق ويب: يحتاج المستخدم إلى تسجيل الدخول إلى تطبيق ويب مؤمن بواسطة معرف Microsoft Entra
      • تطبيق صفحة واحدة (SPA): يحتاج المستخدم إلى تسجيل الدخول إلى تطبيق صفحة واحدة مؤمن بواسطة معرف Microsoft Entra
      • التطبيق الأصلي إلى واجهة برمجة تطبيقات الويب: يحتاج التطبيق الأصلي الذي يتم تشغيله على هاتف أو كمبيوتر لوحي أو كمبيوتر شخصي إلى مصادقة مستخدم للحصول على موارد من واجهة برمجة تطبيقات الويب التي يتم تأمينها بواسطة معرف Microsoft Entra
      • تطبيق ويب إلى واجهة برمجة تطبيقات الويب: يحتاج تطبيق الويب إلى الحصول على موارد من واجهة برمجة تطبيقات ويب مؤمنة بواسطة معرف Microsoft Entra
      • Daemon أو تطبيق الخادم إلى واجهة برمجة تطبيقات الويب: يحتاج تطبيق خفي أو تطبيق خادم بدون واجهة مستخدم ويب إلى الحصول على موارد من واجهة برمجة تطبيقات ويب مؤمنة بواسطة معرف Microsoft Entra

      يرجى الرجوع إلى الروابط في قسم المراجع للحصول على تفاصيل التنفيذ منخفضة المستوى

      تجاوز ذاكرة التخزين المؤقت الافتراضية للرمز المميز MSAL مع ذاكرة تخزين مؤقت موزعة

      ‏‫العنوان التفاصيل
      المكون Microsoft Entra ID
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع إنشاء تسلسل ذاكرة التخزين المؤقت الخاصة بالرمز المميز في MSAL.NET
      الخطوات

      ذاكرة التخزين المؤقت الافتراضية التي تستخدمها MSAL (مكتبة مصادقة Microsoft) هي ذاكرة تخزين مؤقت في الذاكرة، وهي قابلة للتطوير. ومع ذلك، هناك خيارات مختلفة متوفرة يمكنك استخدامها كبديل، مثل ذاكرة التخزين المؤقت للرمز المميز الموزع. تحتوي هذه على آليات L1/L2، حيث L1 في الذاكرة وL2 هو تنفيذ ذاكرة التخزين المؤقت الموزعة. يمكن تكوين هذه وفقا لذلك للحد من ذاكرة L1 أو تشفير نهج الإخلاء أو تعيينها. تتضمن البدائل الأخرى ذاكرة التخزين المؤقت Redis أو SQL Server أو Azure Comsos DB. يمكن العثور على تنفيذ ذاكرة التخزين المؤقت للرمز المميز الموزع في البرنامج التعليمي التالي : بدء استخدام ASP.NET Core MVC.

      تأكد من استخدام TokenReplayCache لمنع إعادة تشغيل رموز مصادقة MSAL

      ‏‫العنوان التفاصيل
      المكون Microsoft Entra ID
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع المصادقة الحديثة مع معرف Microsoft Entra لتطبيقات الويب
      الخطوات

      تسمح خاصية TokenReplayCache للمطورين بتعريف ذاكرة التخزين المؤقت لإعادة تشغيل الرمز المميز، وهو مخزن يمكن استخدامه لحفظ الرموز بغرض التحقق من عدم إمكانية استخدام أي رمز أكثر من مرة.

      هذا إجراء ضد هجوم شائع، يسمى هجوم إعادة الرمز المميز بشكل مناسب: قد يحاول المهاجم الذي يعترض الرمز المميز الذي تم إرساله عند تسجيل الدخول إرساله إلى التطبيق مرة أخرى ("إعادة تشغيله") لإنشاء جلسة جديدة. على سبيل المثال، في تدفق منح كود OIDC، بعد مصادقة المستخدم الناجحة، يتم إجراء طلب لنقطة النهاية "/ signin-oidc" للطرف المعتمد باستخدام معلمات "id_token" و"code" و"state".

      يقوم الطرف المعتمد بالتحقق من صحة هذا الطلب وإنشاء جلسة جديدة. إذا التقط الخصم هذا الطلب وأعاده، فيمكنه/يمكنها إنشاء جلسة ناجحة وانتحال المستخدم. يمكن أن يؤدي وجود العنصر nonce في OpenID Connect إلى الحد من الظروف التي يمكن فيها تنفيذ الهجوم بنجاح ولكن لا يلغيها تماماً. لحماية تطبيقاتهم، يمكن للمطورين توفير تنفيذ ITokenReplayCache وتعيين مثيل لـ TokenReplayCache.

      مثال

      // ITokenReplayCache defined in MSAL
      public interface ITokenReplayCache
      {
      bool TryAdd(string securityToken, DateTime expiresOn);
      bool TryFind(string securityToken);
      }
      

      مثال

      فيما يلي نموذج تنفيذ لواجهة ITokenReplayCache. (يرجى تخصيص وتنفيذ إطار عمل التخزين المؤقت الخاص بالمشروع)

      public class TokenReplayCache : ITokenReplayCache
      {
          private readonly ICacheProvider cache; // Your project-specific cache provider
          public TokenReplayCache(ICacheProvider cache)
          {
              this.cache = cache;
          }
          public bool TryAdd(string securityToken, DateTime expiresOn)
          {
              if (this.cache.Get<string>(securityToken) == null)
              {
                  this.cache.Set(securityToken, securityToken);
                  return true;
              }
              return false;
          }
          public bool TryFind(string securityToken)
          {
              return this.cache.Get<string>(securityToken) != null;
          }
      }
      

      يجب الإشارة إلى ذاكرة التخزين المؤقت التي تم تنفيذها في خيارات OIDC عبر خاصية "TokenValidationParameters" على النحو التالي.

      OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
      {
          AutomaticAuthenticate = true,
          ... // other configuration properties follow..
          TokenValidationParameters = new TokenValidationParameters
          {
              TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
          }
      }
      

      يرجى ملاحظة أنه لاختبار فعالية هذا التكوين، قم بتسجيل الدخول إلى التطبيق المحلي المحمي ب OIDC والتقاط الطلب إلى "/signin-oidc" نقطة النهاية في fiddler. عندما لا تكون الحماية في مكانها الصحيح، فإن إعادة تشغيل هذا الطلب في عازف الكمان ستؤدي إلى تعيين ملف تعريف ارتباط جلسة جديد. عند إعادة الطلب بعد إضافة الحماية TokenReplayCache، سيقوم التطبيق بطرح استثناء على النحو التالي: SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

      استخدام مكتبات MSAL لإدارة طلبات الرمز المميز من عملاء OAuth2 إلى معرف Microsoft Entra (أو AD المحلي)

      ‏‫العنوان التفاصيل
      المكون Microsoft Entra ID
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع MSAL
      الخطوات

      تمكن مكتبة مصادقة Microsoft (MSAL) المطورين من الحصول على رموز الأمان المميزة من النظام الأساسي للهويات في Microsoft لمصادقة المستخدمين والوصول إلى واجهات برمجة تطبيقات الويب الآمنة. يمكنك استخدامه لتوفير وصول آمن إلى Microsoft Graph، أو واجهات برمجة تطبيقات Microsoft الأخرى، أو واجهات برمجة تطبيقات شبكة الإنترنت العالمية التابعة لجهات خارجية، أو واجهة برمجة تطبيقات شبكة الإنترنت العالمية الخاصة بك. Microsoft Authentication Library يدعم العديد من مختلف بنيات التطبيقات والمنصات بما في ذلك .NET، JavaScript، Java Python، Android وiOS.

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

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

      مصادقة الأجهزة المتصلة بـ Field بوابة

      ‏‫العنوان التفاصيل
      المكون بوابة حقل IoT
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع ‏‫غير متوفر‬
      الخطوات تأكد من مصادقة كل جهاز بواسطة Field بوابة قبل قبول البيانات منه وقبل تسهيل الاتصالات الأوَّلية مع Cloud بوابة. تأكد أيضاً من اتصال الأجهزة ببيانات اعتماد لكل جهاز بحيث يمكن التعرُّف على الأجهزة الفردية بشكل فريد.

      تأكد من مصادقة الأجهزة المتصلة ببوابة السحابة

      ‏‫العنوان التفاصيل
      المكون بوابة سحابة IoT
      مرحلة SDL إنشاء
      التقنيات المعمول بها عام، C#، Node.JS,
      السمات غير متاح، اختيار البوابة - Azure IoT Hub
      المراجع غير متاح، Azure IoT hub with .NET، Getting Started with IoT hub and Node JS، IoT with SAS and Certificate، Git repository
      الخطوات
      • عام: مصادقة الجهاز باستخدام بروتوكول أمان طبقة النقل (TLS) أو IPSec. يجب أن تدعم البنية الأساسية استخدام المفتاح المشترك مسبقا على تلك الأجهزة التي لا يمكنها التعامل مع التشفير الكامل غير المتماثل. استفد من معرف Microsoft Entra، Oauth.
      • C#‎: عند إنشاء مثيل DeviceClient، بشكل افتراضي، تقوم طريقة الإنشاء بإنشاء مثيل DeviceClient يستخدم بروتوكول AMQP للتواصل مع IoT Hub. لاستخدام بروتوكول HTTPS، استخدم تجاوز طريقة الإنشاء التي تمكنك من تحديد البروتوكول. إذا كنت تستخدم بروتوكول HTTPS، فيجب أيضاً إضافة حزمة Microsoft.AspNet.WebApi.Client NuGet إلى مشروعك لتضمين مساحة الاسم System.Net.Http.Formatting.

      مثال

      static DeviceClient deviceClient;
      
      static string deviceKey = "{device key}";
      static string iotHubUri = "{iot hub hostname}";
      
      var messageString = "{message in string format}";
      var message = new Message(Encoding.ASCII.GetBytes(messageString));
      
      deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));
      
      await deviceClient.SendEventAsync(message);
      

      مثال

      Node.JS: المصادقة

      مفاتيح متماثلة

      • أنشئ IoT Hub على Azure
      • إنشاء إدخال في سجل هوية الجهاز
        var device = new iothub.Device(null);
        device.deviceId = <DeviceId >
        registry.create(device, function(err, deviceInfo, res) {})
        
      • إنشاء جهاز محاكاة
        var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
        var Message = require('azure-iot-device').Message;
        var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
        var client = clientFromConnectionString(connectionString);
        

        رمز SAS المميز

      • يتم إنشاؤه داخلياً عند استخدام المفتاح المتماثل ولكن يمكننا إنشاؤه واستخدامه بشكل صريح أيضاً
      • تحديد بروتوكول: var Http = require('azure-iot-device-http').Http;
      • إنشاء رمز sas المميز :
        resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
        var deviceName = "<deviceName >";
        var expires = (Date.now() / 1000) + expiresInMins * 60;
        var toSign = resourceUri + '\n' + expires;
        // using crypto
        var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
        const hmac = crypto.createHmac('sha256', decodedPassword);
        hmac.update(toSign);
        var base64signature = hmac.digest('base64');
        var base64UriEncoded = encodeURIComponent(base64signature);
        // construct authorization string
        var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
        + base64UriEncoded + "&se=" + expires;
        if (policyName) token += "&skn="+policyName;
        return token;
        
      • الاتصال باستخدام رمز sas المميز:
        Client.fromSharedAccessSignature(sas, Http);
        

        الشهادات

      • قم بإنشاء شهادة X509 موقعة ذاتياً باستخدام أي أداة مثل OpenSSL لإنشاء ملفات .cert و. key لتخزين الشهادة والمفتاح على التوالي
      • توفير جهاز يقبل الاتصال الآمن باستخدام الشهادات.
        var connectionString = '<connectionString>';
        var registry = iothub.Registry.fromConnectionString(connectionString);
        var deviceJSON = {deviceId:"<deviceId>",
        authentication: {
            x509Thumbprint: {
            primaryThumbprint: "<PrimaryThumbprint>",
            secondaryThumbprint: "<SecondaryThumbprint>"
            }
        }}
        var device = deviceJSON;
        registry.create(device, function (err) {});
        
      • توصيل جهاز باستخدام شهادة
        var Protocol = require('azure-iot-device-http').Http;
        var Client = require('azure-iot-device').Client;
        var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
        var client = Client.fromConnectionString(connectionString, Protocol);
        var options = {
            key: fs.readFileSync('./key.pem', 'utf8'),
            cert: fs.readFileSync('./server.crt', 'utf8')
        };
        // Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
        client.setOptions(options);
        //call fn to execute after the connection is set up
        client.open(fn);
        

      استخدم بيانات اعتماد المصادقة لكل جهاز

      ‏‫العنوان التفاصيل
      المكون بوابة سحابة IoT
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات اختيار البوابة - Azure IoT Hub
      المراجع رموز أمان Azure IoT Hub
      الخطوات استخدام بيانات اعتماد المصادقة لكل جهاز باستخدام الرموز المميزة SaS بناءً على مفتاح الجهاز أو شهادة العميل، بدلاً من نُهج الوصول المشتركة على مستوى IoT Hub. هذا يمنع إعادة استخدام رموز المصادقة الخاصة بجهاز أو بوابة حقل بواسطة جهاز آخر

      تأكد من منح الحاويات والنقاط الكبيرة فقط وصولاً مجهولاً للقراءة

      ‏‫العنوان التفاصيل
      المكون تخزين Azure
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات StorageType - Blob
      المراجع إدارة الوصول المجهول للقراءة إلى الحاويات والنقاط الكبيرة، توقيعات الوصول المشترك، الجزء 1: فهم نموذج SAS
      الخطوات

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

      توفر الحاويات الخيارات التالية لإدارة الوصول إلى الحاوية:

      • الوصول الكامل للقراءة العامة: يمكن قراءة بيانات الحاوية والنقطة الثنائية الكبيرة عبر طلب مجهول. يمكن للعملاء ذِكر الكائنات الثنائية كبيرة الحجم داخل الحاوية عبر طلب مجهول الهوية، ولكن لا يمكنهم ذِكر الحاويات داخل حساب التخزين.
      • الوصول العام للقراءة للنقاط الثنائية الكبيرة فقط: يمكن قراءة بيانات Blob الموجودة داخل هذه الحاوية عبر طلب مجهول، لكن بيانات الحاوية غير متاحة. لا يمكن للعملاء تعداد النقط داخل الحاوية عبر طلب مجهول
      • لا يوجد وصول عام للقراءة: لا يمكن قراءة بيانات الحاوية والنقطة الثنائية الكبيرة إلا من قبل مالك الحساب

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

      منح وصول محدود إلى العناصر في تخزين Azure باستخدام SAS أو SAP

      ‏‫العنوان التفاصيل
      المكون تخزين Azure
      مرحلة SDL إنشاء
      التقنيات المعمول بها العام
      السمات ‏‫غير متوفر‬
      المراجع توقيعات الوصول المشتركة، الجزء 1: فهم نموذج SAS، توقيعات الوصول المشتركة، الجزء 2: إنشاء واستخدام SAS مع تخزين Blob، كيفية تفويض الوصول إلى العناصر في حسابك باستخدام تواقيع الوصول المشترك ونُهج الوصول المخزنة
      الخطوات

      يعد استخدام توقيع الوصول المشترك (SAS) طريقة فعالة لمنح وصول محدود إلى العناصر الموجودة في حساب التخزين لعملاء آخرين، دون الحاجة إلى كشف مفتاح الوصول إلى الحساب. SAS هو عنوان URI يشتمل في معلمات الاستعلام الخاصة به على جميع المعلومات اللازمة للوصول المصدق إلى مورد التخزين. للوصول إلى موارد التخزين باستخدام توقيع الوصول المشترك يحتاج العميل فقط لتمرير في توقيع الوصول المشترك إلى المنشئ المناسب أو الأسلوب.

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

      إذا كانت لديك مجموعة منطقية من المعلمات المتشابهة في كل مرة، فإن استخدام نهج الوصول المخزن (SAP) يعد فكرة أفضل. نظراً لأن استخدام SAS المشتق من نهج الوصول المخزن يمنحك القدرة على إبطال SAS على الفور، فمن أفضل الممارسات الموصى بها لاستخدام نُهج الوصول المخزن دائماً عندما يكون ذلك ممكناً.