المفاهيم الأساسية لـ Azure Key Vault
Azure Key Vault هي خدمة سحابية لتخزين بيانات سرية والوصول إليها بأمان. السر هو أي شيء تريد التحكم بإحكام في الوصول إليه، مثل مفاتيح API أو كلمات المرور أو الشهادات أو مفاتيح التشفير. تدعم خدمة Vault الرئيسية نوعين من الحاويات: المخازن ومجمعات وحدة أمان الأجهزة المدارة (HSM). تدعم Vaults تخزين البرامج والمفاتيح والبيانات السرية والشهادات المدعومة من HSM. تدعم تجمعات HSM المدارة المفاتيح المدعومة من HSM فقط. راجع نظرة عامة على واجهة برمجة تطبيقات Azure Key Vault REST للحصول على تفاصيل كاملة.
فيما يلي مصطلحات مهمة أخرى:
المستأجر: المستأجر هو المؤسسة التي تمتلك وتدير مثيلاً معيناً لخدمات Microsoft السحابية. غالباً ما يستخدم للإشارة إلى مجموعة خدمات Azure وخدمات Microsoft 365 لمؤسسة.
مالك مخزن: يمكن لمالك مخزن إنشاء مخزن مفتاح والحصول على الوصول الكامل والسيطرة عليه. يمكن لمالك المخزن أيضاً إعداد التدقيق لتسجيل من يصل إلى البيانات السرية والمفاتيح. يمكن للمسؤولين التحكم في دورة حياة المفتاح. يمكنهم الانتقال إلى إصدار جديد من المفتاح، ونسخه نسخاً خلفياً، والقيام بالمهام ذات الصلة.
مستهلك المخزن: يمكن للمستهلك المخزن تنفيذ إجراءات على الأصول داخل مخزن المفتاح عندما يمنح صاحب المخزن الوصول المستهلك. تعتمد الإجراءات المتوفرة على الأذونات الممنوحة.
إدارة مسؤولي HSM: المستخدمين الذين تم تعيين دور المسؤول لديهم تحكم كامل في تجمع HSM المدار. يمكنهم إنشاء المزيد من تعيينات الأدوار لتفويض الوصول الخاضع للرقابة إلى مستخدمين آخرين.
HSM Crypto Officer/المستخدم المدار: الأدوار المضمنة التي عادة ما يتم تعيينها للمستخدمين أو أساسيات الخدمة التي ستقوم بإجراء عمليات التشفير باستخدام المفاتيح في إدارة HSM. يمكن لمستخدم التشفير إنشاء مفاتيح جديدة، لكن لا يمكنه حذف المفاتيح.
مستخدم تشفير HSM Crypto المدار: مدمج في الدور الذي عادة ما يتم تعيينه إلى حسابات خدمة مدارة هوية الخدمة (على سبيل المثال حساب التخزين) لتشفير البيانات الثابتة باستخدام مفتاح العميل المدار.
المورد - عنصر يمكن التحكم فيه ويتوافر من خلال Azure. من الأمثلة الشائعة الجهاز الظاهري وحساب التخزين وتطبيق الويب وقاعدة البيانات والشبكة الظاهرية. هناك أكثر من ذلك بكثير.
مجموعة موارد: تعد مجموعة الموارد حاوية تضم الموارد ذات الصلة لحل من حلول Azure. يمكن أن تتضمن مجموعة الموارد كافة الموارد للحل أو الموارد التي تريد إدارتها كمجموعة فقط. أنت تقرر كيف تريد تخصيص الموارد لمجموعات الموارد، بناءً على ما هو أكثر منطقية لمؤسستك.
أساس الأمان: أساس أمان Azure هو هوية أمان تستخدمها التطبيقات والخدمات وأدوات التنفيذ التلقائي التي أنشأها المستخدم للوصول إلى موارد Azure محددة. فكر في الأمر على أنه "هوية المستخدم" (اسم المستخدم وكلمة المرور أو الشهادة) مع دور معين، وأذونات خاضعة لرقابة مشددة. يجب أن يحتاج أساس الأمان فقط إلى القيام بأشياء محددة، على عكس هوية المستخدم العامة. يحسن الأمان إذا منحته الحد الأدنى من مستوى الإذن الذي يحتاجه لتنفيذ مهام الإدارة الخاصة به. يسمى أساس الأمان المستخدم مع تطبيق أو خدمة بشكل خاص أساس الخدمة.
Microsoft Azure Active Directory: تعد Microsoft Azure Active Directory خدمة للمستأجر. يحتوي كل دليل على مجال واحد أو أكثر. يمكن أن يرتبط الدليل بالعديد من الاشتراكات المرتبطة به، ولكن يوجد مستأجر واحد فقط.
معرف مستأجر Azure: معرف المستأجر هو طريقة فريدة لتعريف مثيل Microsoft Azure Active Directory ضمن اشتراك Azure.
الهويات المدارة: يوفر Azure Key Vault طريقة لتخزين بيانات الاعتماد والمفاتيح والأسرار الأخرى بأمان، ولكن يجب أن تتم مصادقة الرمز إلى مفتاح Vault لاستردادها. استخدام هوية مدارة يجعل حل هذه المشكلة أسهل من خلال منح خدمات Azure هوية مدارة تلقائيا في مدخل Microsoft Azure. يمكنك استخدام هذه الهوية للمصادقة على مخزن المفتاح أو أي خدمة تدعم Microsoft Azure Active Directory، دون الحاجة إلى بيانات اعتماد في التعليمة البرمجية الخاصة بك. لمزيد من المعلومات، راجع الصورة التالية ونظرة عامة على الهويات المدارة لموارد Azure.
المصادقة
لإجراء أي عمليات باستخدام Key Vault، تحتاج أولاً إلى المصادقة عليه. هناك ثلاث طرق للمصادقة على Key Vault:
- الهويات المدارة لموارد Azure:عند نشر تطبيق على جهاز ظاهري في Azure، يمكنك تعيين هوية للجهاز الظاهري الذي لديه حق الوصول إلى مفتاح 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-2 المستوى 2 أو FIPS 140-2 المستوى 3 HSMs لإدارة مفتاح آمن. أريد التأكد من أن منظمتي تتحكم في دورة حياة المفتاح ويمكنها مراقبة استخدام المفتاح. وعلى الرغم من أننا نستخدم العديد من خدمات وموارد Azure، إلا أنني أريد إدارة المفاتيح من موقع واحد في Azure. |
√ اختر خزائن لـ FIPS 140-2 المستوى 2 HSMs تم التحقق من صحتها. √ اختر مجموعات HSM المُدارة لـ FIPS 140-2 Level 3 HSMs المصادق عليها. √ تم تصميم Key Vault بحيث لا ترى Microsoft مفاتيحك أو تستخرجها. √ يتم تسجيل استخدام المفتاح في الوقت الفعلي القريب. √ يوفر المخزن واجهة واحدة، بغض النظر عن عدد الخزائن الموجودة في Azure، والمناطق التي يدعمونها، والتطبيقات التي تستخدمها. |
يمكن لأي شخص لديه اشتراك Azure إنشاء مخازن المفاتيح واستخدامها. على الرغم من أن مفتاح Vault يفيد المطورين ومسؤولي الأمان، إلا أنه يمكن تنفيذه وإدارته من قبل مسؤول المؤسسة الذي يدير خدمات Azure الأخرى. على سبيل المثال، يمكن لهذا المسؤول تسجيل الدخول باستخدام اشتراك Azure، وإنشاء خزنة للمؤسسة لتخزين المفاتيح، ثم يكون مسؤولا عن مهام تشغيلية مثل:
- إنشاء مفتاح أو سر أو استيراده
- إبطال مفتاح أو سر أو حذفه
- السماح للمستخدمين أو التطبيقات بالوصول إلى خزنة المفاتيح، حتى يتمكنوا بعد ذلك من إدارة مفاتيحها وأسرارها أو استخدامها
- تكوين استخدام المفتاح (على سبيل المثال، التوقيع أو التشفير)
- مراقبة استخدام المفتاح
ثم يعطي هذا المسؤول المطورين URIs للاتصال من التطبيقات الخاصة بهم. هذا المسؤول أيضا يعطي معلومات تسجيل استخدام المفتاح إلى مسؤول الأمان.
يمكن للمطورين أيضاً إدارة المفاتيح مباشرة، باستخدام واجهات برمجة التطبيقات. لمزيدٍ من المعلومات، راجع صفحة تسعير Key Vault.
الخطوات التالية
- تعرف على ميزات أمان Azure Key Vault.
- تعرف على كيفية تأمين مجموعات HSM المُدارة
يتوفر Azure Key Vault في معظم المناطق. لمزيدٍ من المعلومات، راجع صفحة تسعير Key Vault.