إرشادات التحكم في Azure Key Vault

  • مقالة

التحكم بالنطاق الترددي هو عملية تقوم بتفعيلها للحد من عدد المكالمات المتزامنة إلى خدمة Azure لمنع الإفراط في استخدام الموارد. تم تصميم Azure Key Vault (AKV) للتعامل مع عدد كبير من الطلبات. في حالة حدوث عدد هائل من الطلبات، يساعد التحكم بالنطاق الترددي لطلبات العميل في الحفاظ على الأداء الأمثل والموثوقية لخدمة AKV.

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

كيف يتعامل Key Vault مع القيود المحددة؟

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

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

تم إنشاء Key Vault في الأصل مع القيود المحددة في حدود خدمة Azure Key Vault. لزيادة معدلات نقل Key Vault إلى أقصى حد، إليك بعض الإرشادات/أفضل الممارسات الموصى بها لزيادة معدل النقل إلى أقصى حد:

  1. تأكد من وجود التحكم بالنطاق الترددي. يجب على العميل الالتزام بنهج التراجع الأسي ل 429s والتأكد من إجراء عمليات إعادة المحاولة وفقا للإرشادات أدناه.
  2. تقسيم نسبة استخدام Key Vault بين خزائن متعددة ومناطق مختلفة. استخدم خزنة منفصلة لكل مجال أمان/توفر. إذا كان لديك خمسة تطبيقات، كل منها في منطقتين، فنوصي ب 10 خزائن يحتوي كل منها على أسرار فريدة من نوعها للتطبيق والمنطقة. الحد الأقصى على مستوى الاشتراك لكافة أنواع المعاملات هو خمسة أضعاف حد key vault المنفرد. على سبيل المثال، تقتصر المعاملات الأخرى HSM لكل اشتراك على 5000 معاملة في 10 ثوان لكل اشتراك. فكر في تخزين البيانات السرية داخل الخدمة أو التطبيق أيضا لتقليل RPS مباشرة إلى key vault والتعامل مع اندفاع حركة المرور أو أي منهما. يمكنك أيضا تقسيم حركة المرور الخاصة بك بين مناطق مختلفة لتقليل زمن الوصول واستخدام اشتراك /تخزين مختلف. لا تتجاوز حد الاشتراك لخدمة Key Vault في منطقة Azure واحدة.
  3. قم بتخزين البيانات السرية التي تسترجعها منAzure Key Vault في الذاكرة، ثم أعد استخدامها من الذاكرة كلما أمكن ذلك. إعادة القراءة من Azure Key Vault فقط عندما تتوقف نسخة البيانات المخزنة مؤقتا عن العمل (على سبيل المثال لأنها استدارت عند المصدر).
  4. تم تصميم Key Vault لخدمة بياناتك السرية. إذا كنت تخزن أسرار عملائك (خاصة بالنسبة لسيناريوهات تخزين المفاتيح عالية الإنتاجية)، ففكر في وضع المفاتيح في قاعدة بيانات أو حساب تخزين مع التشفير، وتخزين المفتاح الأساسي فقط في Azure Key Vault.
  5. يمكن إجراء عمليات تشفير عمليات المفاتيح العمومية وتضمينها والتحقق منها دون الوصول إلى Key Vault، وبذلك لا ينخفض خطر التقييد فحسب، بل تتحسن الموثوقية أيضاً (طالما تقوم بتخزين مواد المفتاح العام بشكل صحيح).
  6. إذا كنت تستخدم Key Vault لتخزين بيانات الاعتماد لخدمة ما، فتحقق مما إذا كانت هذه الخدمة تدعم مصادقة Microsoft Entra للمصادقة مباشرة. وهذا يقلل من الحمل على Key Vault، ويحسن الموثوقية ويبسط التعليمات البرمجية الخاصة بك حيث يمكن ل Key Vault الآن استخدام رمز Microsoft Entra المميز. انتقلت العديد من الخدمات إلى استخدام Microsoft Entra auth. راجع القائمة الحالية في الخدمات التي تدعم الهويات المدارة لموارد Azure.
  7. فكر في توزيع الحمل / النشر الخاص بك على مدى فترة زمنية أطول لعدم تجاوز حدود RPS الحالية.
  8. إذا كان تطبيقك يتضمن عقدا متعددة تحتاج إلى قراءة نفس السر (الأسرار)، ففكر في استخدام نمط توزيع المهام، حيث يقرأ كيان واحد البيانات السرية من Key Vault، ويحب جميع العقد. قم بعمل تخزين مؤقت للبيانات السرية التي تم استردادها فقط في الذاكرة.

كيفية تنظيم حمل العمل في التطبيق الخاص بك وفقاً لحدود الخدمة

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

  • تقليل عدد العمليات لكل طلب.
  • تقليل تكرار الطلبات.
  • تجنب المحاولات الفورية.
    • تتراكم جميع الطلبات حسب حدود الاستخدام الخاصة بك.

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

فيما يلي التعليمات البرمجية التي تنفذ التراجع الأسي:

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

استخدام هذا التعليمات البرمجية في تطبيق العميل C# مباشرة.

على رمز الخطأ HTTP 429، ابدأ في التحكم بالنطاق الترددي للعميل باستخدام نهج التراجع المتكرر:

  1. انتظر 1 ثانية، إعادة محاولة الطلب
  2. انتظر 2 ثانية إذا كان التقييد لا يزال مفروض، أعد محاولة الطلب
  3. انتظر 4 ثوان إذا كان التقييد لا يزال مفروض، أعد محاولة الطلب
  4. انتظر 8 ثوان إذا كان التقييد لا يزال مفروض، أعد محاولة الطلب
  5. انتظر 16 ثوان إذا كان التقييد لا يزال مفروض، أعد محاولة الطلب

عند هذه النقطة، يجب أن لا يكون هناك حصول على رموز استجابة HTTP 429.

(راجع أيضًا )

للحصول على إرشادات متعمقة حول التحكم بالنطاق الترددي على Microsoft Cloud، راجع نمط التحكم بالنطاق الترددي.