Share via

المفاهيم الأساسية لـ Azure Key Vault

  • مقالة

تعد Azure Key Vault خدمة سحابية لتخزين البيانات السرية والوصول إليها بشكل آمن. السرهو أي شيء تود التحكم بشدة في الوصول إليه مثل مفاتيح API أو كلمات المرور أو الشهادات أو مفاتيح التشفير. تدعم خدمة Vault الرئيسية نوعين من الحاويات: المخازن ومجمعات وحدة أمان الأجهزة المدارة (HSM). تدعم المخازن تخزين البرامج والمفاتيح والبيانات السرية والشهادات المدعومة من HSM. لا تدعم مجموعات HSM المُدارة سوى المفاتيح المدعومة من HSM. راجع نظرة عامة على واجهة برمجة تطبيقات Azure Key Vault REST للحصول على تفاصيل كاملة.

فيما يلي مصطلحات مهمة أخرى:

  • المستأجر: المستأجر هو المؤسسة التي تمتلك وتدير مثيلاً معيناً لخدمات Microsoft السحابية. غالباً ما يستخدم للإشارة إلى مجموعة خدمات Azure وخدمات Microsoft 365 لمؤسسة.

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

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

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

  • HSM Crypto Officer/المستخدم المدار: الأدوار المضمنة التي عادة ما يتم تعيينها للمستخدمين أو أساسيات الخدمة التي ستقوم بإجراء عمليات التشفير باستخدام المفاتيح في إدارة HSM. يمكن لمستخدم التشفير إنشاء مفاتيح جديدة، ولكن لا يمكنه حذف المفاتيح.

  • مستخدم تشفير خدمة تشفير HSM المدار: دور مضمن يتم تعيينه عادة إلى هوية خدمة مدارة لحسابات الخدمة (على سبيل المثال، حساب التخزين) لتشفير البيانات الثابتة باستخدام المفتاح المدار من قبل العميل.

  • المورد - عنصر يمكن التحكم فيه ويتوافر من خلال Azure. من الأمثلة الشائعة الجهاز الظاهري وحساب التخزين وتطبيق الويب وقاعدة البيانات والشبكة الظاهرية. هناك أكثر من ذلك بكثير.

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

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

  • معرف Microsoft Entra: معرف Microsoft Entra هو خدمة Active Directory للمستأجر. يحتوي كل دليل على مجال واحد أو أكثر. يمكن أن يرتبط الدليل بالعديد من الاشتراكات المرتبطة به، ولكن يوجد مستأجر واحد فقط.

  • معرف مستأجر Azure: معرف المستأجر هو طريقة فريدة لتحديد مثيل Microsoft Entra ضمن اشتراك Azure.

  • الهويات المدارة: يوفر Azure Key Vault طريقة لتخزين بيانات الاعتماد والمفاتيح والأسرار الأخرى بأمان، ولكن يجب أن تتم مصادقة الرمز إلى مفتاح Vault لاستردادها. يؤدي استخدام هوية مدارة إلى تبسيط حل هذه المشكلة من خلال منح خدمات Azure هوية مدارة تلقائيا في Microsoft Entra ID. يمكنك استخدام هذه الهوية للمصادقة على Key Vault أو أي خدمة تدعم مصادقة Microsoft Entra، دون وجود أي بيانات اعتماد في التعليمات البرمجية الخاصة بك. لمزيد من المعلومات، راجع الصورة التالية ونظرة عامة على الهويات المدارة لموارد Azure.

المصادقة

لإجراء أي عمليات باستخدام Key Vault، تحتاج أولاً إلى المصادقة عليه. هناك ثلاث طرق للمصادقة على Key Vault:

  • الهويات المُدارة لموارد Azure:عندما توزع تطبيق على جهاز ظاهري في Azure، يمكنك تعيين هوية لجهازك الظاهري الذي لديه حق الوصول إلى Key Vault. يمكنك أيضا تعيين هويات لموارد Azure أخرى. تكمن فائدة هذا الأسلوب في أن التطبيق أو الخدمة لا تدير دوران البيانات السرية الأولى. تباشر Azure تلقائياً بتدوير الهوية. نوصي باتباع هذا النهج باعتباره أفضل ممارسة.
  • كيان الخدمة وشهادة:يمكنك استخدام كيان الخدمة والشهادة المرتبطة التي لديها حق الوصول إلى Key Vault. لا نوصي بهذا الأسلوب لأنه يجب على مالك التطبيق أو المطور تدوير الشهادة.
  • كيان الخدمة والبيانات السرية: على الرغم من أنه يمكنك استخدام كيان الخدمة وبيانات سرية للمصادقة على Key Vault، لا نوصي بذلك. من الصعب تدوير البيانات السرية الخاصة بنظام تمهيد تشغيل الكمبيوتر المستخدم للمصادقة على Key Vault تلقائياً.

تشفير البيانات قيد النقل

يفرض Azure Key Vault بروتوكول أمان طبقة النقل (TLS) لحماية البيانات عند انتقالها بين خزنة Azure Key والعملاء. يتفاوض العملاء بشأن اتصال TLS مع Azure Key Vault. يوفر بروتوكول TLS مصادقة قوية وخصوصية الرسائل وسلامتها (مما يتيح اكتشاف التلاعب بالرسائل والاعتراض والتزوير) وإمكانية التشغيل البيني ومرونة الخوارزمية وسهولة التوزيع والاستخدام.

Perfect Forward Secrecy تحمي PFS الاتصالات بين أنظمة العملاء الخاصة بالعميل والخدمات السحابية من Microsoft بواسطة مفاتيح فريدة. تستخدم الاتصالات أيضاً أطوال مفاتيح التشفير المستندة إلى RSA 2048 بت. يجعل هذا المزيج من الصعب على أي شخص اعتراض البيانات التي يجري نقلها والوصول إليها.

أدوار Vault الرئيسية

استخدم الجدول التالي لفهم أفضل لكيفية مساعدة مفتاح Vault في تلبية احتياجات المطورين ومسؤولي الأمان.

الدور بيان المشكلة تم حلها بواسطة Azure Key Vault
مطور لتطبيق Azure "أريد كتابة تطبيق لـ Azure يستخدم مفاتيح للتوقيع والتشفير. لكن أريد أن تكون هذه المفاتيح الخارجية من تطبيقي بحيث الحل مناسب لتطبيق هذا توزيعها جغرافيا.

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

√ يتم حماية المفاتيح بواسطة Azure، باستخدام خوارزميات متوافقة مع معايير الصناعة وأطوال المفاتيح ووحدات أمان الأجهزة.

√ تتم معالجة المفاتيح في وحدات HSM الموجودة في نفس مراكز بيانات Azure مثل التطبيقات. يوفر هذا الأسلوب موثوقية أفضل وزمن وصول أقل من المفاتيح الموجودة في موقع منفصل، مثل المحلي.
مطور البرامج كخدمة (SaaS) "لا أريد المسؤولية أو المسؤولية المحتملة عن مفاتيح وأسرار مستأجري عملائي.

أريد من العملاء امتلاك مفاتيحهم وإدارتها حتى أتمكن من التركيز على القيام بما أقوم به على أفضل وجه، وهو توفير ميزات البرامج الأساسية".		 √ يمكن للعملاء استيراد مفاتيحهم الخاصة إلى Azure وإدارتها. عندما يحتاج تطبيق SaaS إلى تنفيذ عمليات التشفير باستخدام مفاتيح العملاء، يقوم Key Vault بهذه العمليات نيابة عن التطبيق. لا يرى التطبيق مفاتيح العملاء.
رئيس الأمن "أريد أن أعرف أن تطبيقاتنا تتوافق مع FIPS 140 المستوى 3 HSMs لإدارة المفاتيح الآمنة.

أريد التأكد من أن منظمتي تتحكم في دورة حياة المفتاح ويمكنها مراقبة استخدام المفتاح.

وعلى الرغم من أننا نستخدم العديد من خدمات وموارد Azure، إلا أنني أريد إدارة المفاتيح من موقع واحد في Azure.		 √ اختيار الخزائن أو HSMs المدارة ل FIPS 140 HSMs التي تم التحقق من صحتها.
√ اختر مجموعات HSM المُدارة لـ FIPS 140-2 Level 3 HSMs المصادق عليها.

√ تم تصميم Key Vault بحيث لا ترى Microsoft مفاتيحك أو تستخرجها.
√ يتم تسجيل استخدام المفتاح في الوقت الفعلي القريب.

√ يوفر المخزن واجهة واحدة، بغض النظر عن عدد الخزائن الموجودة في Azure، والمناطق التي يدعمونها، والتطبيقات التي تستخدمها.

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

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

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

Overview of how Azure Key Vault works

يمكن للمطورين أيضاً إدارة المفاتيح مباشرة، باستخدام واجهات برمجة التطبيقات. لمزيدٍ من المعلومات، راجع صفحة تسعير Key Vault.

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

يتوفر Azure Key Vault في معظم المناطق. لمزيدٍ من المعلومات، راجع صفحة تسعير المخزن الرئيسي.