نمط مفتاح الخادم

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

السياق والمشكلة

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

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

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

حل

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

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

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

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

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

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

المسائل والاعتبارات

راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

موعد استخدام النمط

هذا النمط مفيد في المواقف التالية:

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

• لتقليل التكلفة التشغيلية. يعد تمكين الوصول المباشر إلى المتاجر وقوائم الانتظار أمرًا فعالاً من حيث التكلفة والموارد، ويمكن أن يؤدي إلى عدد أقل من الرحلات ذهابًا وإيابًا للشبكة، وقد يسمح بتقليل عدد موارد الحوسبة المطلوبة.

• عندما يقوم العملاء بتحميل البيانات أو تنزيلها بانتظام، لا سيما عندما يكون هناك حجم كبير أو عندما تتضمن كل عملية ملفات كبيرة.

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

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

قد لا يكون هذا النمط مفيدا في الحالات التالية:

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

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

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

• إذا كان من الضروري الحفاظ على مسارات التدقيق أو التحكم في عدد المرات التي يتم فيها تنفيذ عملية نقل البيانات، ولا تدعم آلية مفتاح الخادم المستخدمة الإشعارات التي يمكن للخادم استخدامها لإدارة هذه العمليات.

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

تصميم حمل العمل

يجب على المهندس المعماري تقييم كيفية استخدام نمط Valet Key في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:

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

مثال

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

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

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

يعالج استخدام نمط مفتاح Valet مخاوف الأمان وتحسين التكلفة والأداء.

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

2. تتحقق واجهة برمجة التطبيقات من صحة الطلب ثم تحصل على رمز SaS المميز المحدود للنطاق والوقت وترجعه.

   يقيد الرمز المميز الذي تم إنشاؤه بواسطة واجهة برمجة التطبيقات العميل بالقيود التالية:

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

3. ثم يتم استخدام هذا الرمز المميز من قبل العميل، ضمن النافذة الزمنية الضيقة، لتحميل الملف مباشرة إلى حساب التخزين.

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

يتوفر نموذج كامل على GitHub في مثال نمط مفتاح Valet. يتم تكييف قصاصات التعليمات البرمجية التالية من هذا المثال. يوضح هذا الأول كيفية إنشاء دالة Azure (الموجودة في ValetKey.Web) رمز توقيع وصول مشترك مفوض من قبل المستخدم باستخدام الهوية المدارة الخاصة ب Azure Function.

[Function("FileServices")]
public async Task<StorageEntitySas> GenerateTokenAsync([HttpTrigger(...)] HttpRequestData req, ..., 
                                                        CancellationToken cancellationToken)
{
  // Authorize the caller, select a blob storage account, container, and file name.
  // Authenticate to the storage account with the Azure Function's managed identity.
  ...

  return await GetSharedAccessReferenceForUploadAsync(blobContainerClient, blobName, cancellationToken);
}

/// <summary>
/// Return an access key that allows the caller to upload a blob to this
/// specific destination for about three minutes.
/// </summary>
private async Task<StorageEntitySas> GetSharedAccessReferenceForUploadAsync(BlobContainerClient blobContainerClient, 
                                                                            string blobName,
                                                                            CancellationToken cancellationToken)
{
  var blobServiceClient = blobContainerClient.GetParentBlobServiceClient();
  var blobClient = blobContainerClient.GetBlockBlobClient(blobName);

  // Allows generating a SaS token that is evaluated as the union of the RBAC permissions on the managed identity
  // (for example, Blob Data Contributor) and then narrowed further by the specific permissions in the SaS token.
  var userDelegationKey = await blobServiceClient.GetUserDelegationKeyAsync(DateTimeOffset.UtcNow.AddMinutes(-3),
                                                                            DateTimeOffset.UtcNow.AddMinutes(3),
                                                                            cancellationToken);

  // Limit the scope of this SaS token to the following:
  var blobSasBuilder = new BlobSasBuilder
  {
      BlobContainerName = blobContainerClient.Name,     // - Specific container
      BlobName = blobClient.Name,                       // - Specific filename
      Resource = "b",                                   // - Blob only
      StartsOn = DateTimeOffset.UtcNow.AddMinutes(-3),  // - For about three minutes (+/- for clock drift)
      ExpiresOn = DateTimeOffset.UtcNow.AddMinutes(3),  // - For about three minutes (+/- for clock drift)
      Protocol = SasProtocol.Https                      // - Over HTTPS
  };
  blobSasBuilder.SetPermissions(BlobSasPermissions.Create);

  return new StorageEntitySas
  {
      BlobUri = blobClient.Uri,
      Signature = blobSasBuilder.ToSasQueryParameters(userDelegationKey, blobServiceClient.AccountName).ToString();
  };
}

القصاصة البرمجية التالية هي كائن نقل البيانات (DTO) المستخدم من قبل كل من واجهة برمجة التطبيقات والعميل.

public class StorageEntitySas
{
  public Uri? BlobUri { get; internal set; }
  public string? Signature { get; internal set; }
}

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

...

// Get the SaS token (valet key)
var blobSas = await httpClient.GetFromJsonAsync<StorageEntitySas>(tokenServiceEndpoint);
var sasUri = new UriBuilder(blobSas.BlobUri)
{
    Query = blobSas.Signature
};

// Create a blob client using the SaS token as credentials
var blob = new BlobClient(sasUri.Uri);

// Upload the file directly to blob storage
using (var stream = await GetFileToUploadAsync(cancellationToken))
{
    await blob.UploadAsync(stream, cancellationToken);
}

...

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

قد تكون الإرشادات التالية مناسبة عند تنفيذ هذا النمط:

• يتوفر تنفيذ المثال على GitHub في مثال نمط مفتاح Valet.
• منح وصول محدود إلى موارد Azure Storage باستخدام توقيعات الوصول المشترك (SAS)
• مصادقة توقيع الوصول المشترك باستخدام ناقل خدمة Microsoft Azure

الموارد ذات الصلة

قد تكون الأنماط الموضحة أدناه مناسبة أيضًا عند تنفيذ هذا النمط:

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