Azure Key Vault basic concepts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Authentication

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

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

للحصول على إرشادات شاملة للمصادقة، انظر Authentication in Azure Key Vault.

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

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

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

أدوار Key Vault

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

Role بيان المشكلة Solved by 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 المدارة لأنظمة HSM المصادقة من FIPS 140-3 المستوى 3.

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

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

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

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

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

نظرة عامة على كيفية عمل Azure Key Vault

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

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

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