منح access محدود إلى موارد Azure Storage باستخدام توقيعات access مشتركة (SAS)

يوفر توقيع access مشترك (SAS) access مفوض آمنا إلى الموارد في حساب storage الخاص بك. مع SAS، لديك تحكم دقيق في كيفية access العميل إلى بياناتك. على سبيل المثال:

  • ما هي الموارد التي يمكن للعميل الوصول إليها access.
  • ما هي الأذونات التي يمتلكونها لتلك الموارد.
  • ما هي مدة صلاحية توقيعات الوصول المشترك.

أنواع توقيعات access المشتركة

يدعم Azure Storage ثلاثة أنواع من توقيعات access المشتركة:

هام

في السيناريوهات التي تستخدم فيها توقيعات access مشتركة، توصي مايكروسوفت باستخدام SAS لتفويض المستخدم. يتم تأمين SAS لتفويض المستخدم باستخدام بيانات اعتماد Microsoft Entra بدلا من مفتاح الحساب، والذي يوفر أمانا فائقا. لمزيد من المعلومات حول التفويض access للبيانات، راجع تفويض access للبيانات في Azure Storage.

توقيعات الوصول المشترك لتفويض المستخدم

يتم تأمين SAS لتفويض المستخدم باستخدام بيانات اعتماد Microsoft Entra وأيضا من خلال الأذونات المحددة ل SAS. يدعم تفويض المستخدم SAS ل Blob Storage (بما في ذلك Data Lake Storage وdfs endpoint)، أو Storage الطابور، أو Storage الجدول، أو Azure Files.

لمزيد من المعلومات حول توقيع الوصول المشترك لتفويض مستخدم، راجع إنشاء توقيع الوصول المشترك لتفويض مستخدم (واجهة برمجة تطبيقات REST).

توقيعات الوصول المشترك للخدمات

يتم تأمين خدمة SAS باستخدام مفتاح حساب storage. تفوض خدمة SAS access إلى مورد في واحدة فقط من الخدمات Azure Storage: Blob Storage (بما في ذلك Data Lake Storage و dfs النقطتين)، Storage الطابور، الجدول Storage، أو Azure Files.

لمزيد من المعلومات حول توقيعات الوصول المشترك للخدمات، راجع إنشاء توقيعات الوصول المشترك للخدمات (واجهة برمجة تطبيقات REST).

توقيعات الوصول المشترك للحسابات

يتم تأمين SAS للحساب باستخدام مفتاح حساب storage. يقوم حساب SAS بتفويض access إلى الموارد في واحدة أو أكثر من خدمات storage. تتوفر جميع العمليات المتاحة عن طريق توقيعات الوصول المشترك للخدمات أو تفويض المستخدم أيضاً عبر توقيعات الوصول المشترك للحسابات.

يمكنك أيضا تفويض access إلى ما يلي:

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

لمزيد من المعلومات حول توقيعات الوصول المشترك للحسابات، راجع إنشاء توقيعات الوصول المشترك للحسابات (واجهة برمجة تطبيقات REST).

يمكن أن يأخذ توقيع access المشترك أحد الشكلين التاليين:

  • توقيع الوصول المشترك المخصص. عند إنشاء توقيع الوصول المشترك المخصص، يتم تحديد وقت البدء ووقت انتهاء الصلاحية والأذونات في SAS URI. يمكن أن يكون أي نوع من توقيع الوصول المشترك هو توقيع وصول مشترك مخصص.
  • Service SAS مع سياسة access مخزنة. يتم تعريف سياسة access المخزن على حاوية الموارد، والتي يمكن أن تكون حاوية blob أو جدول أو طابور أو مشاركة ملفات. يمكن استخدام سياسة access المخزن لإدارة القيود لتوقيع واحد أو أكثر من توقيعات access المشتركة للخدمة. عندما تربط SAS خدمة بسياسة access مخزنة، يرث SAS القيود — وقت البدء، وقت انتهاء الصلاحية، والأصوات — المعرفة لسياسة access المخزنة.

إشعار

يتعين أن يكون توقيع الوصول المشترك لتفويض المستخدم أو توقيع الوصول المشترك للحسابات عبارة عن توقيع وصول مشترك مخصص. سياسات access المخزنة غير مدعومة لنظام تفويض المستخدم SAS أو SAS للحساب.

كيف يعمل توقيع access مشترك

توقيع access المشترك هو رمز يتم إضافته إلى URI لمورد Azure Storage. الرمز المميز الذي يحتوي على مجموعة خاصة من معلمات الاستعلام التي تشير إلى كيفية الوصول إلى الموارد من قبل العميل. إحدى معلمات الاستعلام التوقيع، يتم إنشاؤها من المعلمات توقيعات الوصول المشترك وتوقيعها بواسطة المفتاح الذي تم استخدامه لإنشاء توقيعات الوصول المشترك. يستخدم هذا التوقيع من قبل Azure Storage لتفويض access إلى مورد storage.

إشعار

لا يمكن تدقيق إنشاء رموز SAS المميزة. أي مستخدم لديه صلاحيات لإنشاء رمز SAS، سواء باستخدام مفتاح الحساب أو عبر تعيين دور Azure، يمكنه القيام بذلك دون علم مالك حساب storage. احرص على تقييد الأذونات التي تسمح للمستخدمين بإنشاء رموز SAS المميزة. لمنع المستخدمين من إنشاء SAS موقعة بمفتاح الحساب لأحمال blob وقوائم الانتظار، يمكنك منع Shared Key access إلى حساب storage. للحصول على مزيد من المعلومات، انظر منع التخويل باستخدام مفتاح مشترك.

توقيع SAS والتخويل

يمكنك توقيع رمز SAS باستخدام مفتاح تفويض المستخدم أو بمفتاح حساب storage (مفتاح مشترك).

توقيع رمز SAS المميز باستخدام مفتاح تفويض المستخدم

يمكنك توقيع رمز SAS المميز باستخدام مفتاح تفويض مستخدم تم إنشاؤه باستخدام بيانات اعتماد Microsoft Entra. يتم توقيع SAS لتفويض المستخدم باستخدام مفتاح تفويض المستخدم.

للحصول على المفتاح، ثم إنشاء SAS، يجب تعيين مبدأ أمني في Microsoft Entra إلى دور Azure يتضمن إجراء Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. لمزيد من المعلومات، راجع إنشاء توقيع الوصول المشترك لتفويض مستخدم (واجهة برمجة تطبيقات REST).

توقيع رمز SAS المميز باستخدام مفتاح حساب

كل من SAS الخدمي وSAS الحساب موقعان بمفتاح حساب storage. لإنشاء SAS موقعة بمفتاح الحساب، يجب أن يكون لدى التطبيق access إلى مفتاح الحساب.

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

يلخص الجدول التالي كيفية تفويض كل نوع من أنواع رموز SAS المميزة.

نوع SAS نوع التفويض
توقيعات الوصول المشترك لتفويض المستخدم Microsoft Entra ID
توقيعات الوصول المشترك للخدمات المفتاح المشترك
توقيعات الوصول المشترك للحسابات المفتاح المشترك

توصي Microsoft باستخدام تفويض مستخدم SAS عند الإمكان للحصول على أمان فائق.

رمز SAS المميز

رمز SAS هو سلسلة تنشئها على جانب العميل، على سبيل المثال باستخدام إحدى مكتبات عملاء Azure Storage. رمز SAS لا يتم تتبعه من قبل Azure Storage بأي شكل من الأشكال. يمكنك إنشاء عدد غير محدود من رموز SAS المميزة على جانب العميل. بعد إنشاء SAS، يمكنك توزيعه على تطبيقات العميل التي تتطلب access to resources في حساب storage الخاص بك.

توفر تطبيقات العميل SAS URI إلى Azure Storage كجزء من طلب. بعد ذلك، تتحقق الخدمة من معلمات SAS والتوقيع للتحقق من صحتها. إذا تحققت الخدمة من صحة التوقيع، فإنه يتم تفويض الطلب. وإلا، فإنه يتم رفض الطلب باستخدام رمز الخطأ 403 (ممنوع).

فيما يلي مثال على خدمة SAS URI، تظهر URI للمورد وحرف المحدد ('؟') ورمز SAS المميز.

مخطط يوضح مكونات URI للمورد مع رمز SAS.

إشعار

حرف المحدد ('?') لسلسلة الاستعلام ليس جزءا من رمز SAS المميز. إذا قمت بإنشاء رمز SAS من البوابة أو PowerShell أو Azure CLI أو أحد Azure Storage SDK، فقد تحتاج إلى إضافة رمز المحدد إلى عنوان URL الخاص بالمورد.

متى تستخدم توقيع access مشترك

استخدم SAS لمنح access آمن إلى الموارد في حساب storage الخاص بك لأي عميل لا يملك صلاحيات لتلك الموارد.

سيناريو شائع يكون فيه SAS مفيدا هو خدمة يقرأ فيها المستخدمون بياناتهم الخاصة ويتطلبون منها حساب storage الخاص بك. في سيناريو يخزن فيه حساب storage بيانات المستخدم، هناك نمطان نموذجيان في التصميم:

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

    <>><مخطط السيناريو: خدمة وكيل الواجهة الأمامية

  2. تصادق خدمة بسيطة العميل حسب الحاجة ثم يقوم بإنشاء توقيعات الوصول المشترك. بمجرد استلام تطبيق العميل لخدمة SAS، يمكنه access storage موارد الحساب مباشرة. أما صلاحيات Access فهي محددة من قبل SAS ولفترة زمنية مسموح بها من قبل SAS. تخفف توقيعات الوصول المشترك للحاجة لتوجيه جميع البيانات من خلال خدمة الوكيل الأمامي.

    مخطط السيناريو: خدمة مزود SAS

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

بالإضافة إلى ذلك، يطلب من SAS تفويض access إلى الكائن المصدر في عملية نسخ في سيناريوهات معينة:

  • عندما تنسخ كتلة إلى كتلة أخرى تكون في حساب storage مختلف. يمكنك أيضا استخدام SAS لتفويض access إلى كتلة الوجهة.
  • عندما تنسخ ملفا إلى ملف آخر يكون في حساب storage مختلف. يمكنك أيضا استخدام SAS لتفويض access إلى ملف الوجهة.
  • عند نسخ كائن ثنائي كبير الحجم إلى ملف، أو ملف إلى كائن ثنائي كبير الحجم. يجب عليك استخدام SAS حتى لو كانت كائنات المصدر والوجهة موجودة داخل نفس حساب storage.

أفضل الممارسات عند استخدام توقيعات الوصول المشترك

عند استخدام توقيعات access المشتركة في تطبيقاتك، يجب أن تكون على دراية بخطرين محتملين:

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

التوصيات التالية لاستخدام توقيعات access المشتركة يمكن أن تساعد في التخفيف من هذه المخاطر:

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

  • استخدام تفويض مستخدم توقيعات الوصول المشترك عند الإمكان. يوفر تفويض مستخدم توقيعات الوصول المشترك أماناً فائقاً لخدمة توقيعات الوصول المشترك أو حساب الوصول المشترك. يتم تأمين SAS لتفويض المستخدم باستخدام بيانات اعتماد Microsoft Entra، بحيث لا تحتاج إلى تخزين مفتاح حسابك مع التعليمات البرمجية الخاصة بك.

  • لديك خطة إلغاء تم إعدادها لتوقعات الوصول المشترك. تأكد من أنك مستعد للرد إذا تم اختراق توقيعات الوصول المشترك.

  • قم بتكوين سياسة انتهاء صلاحية SAS لحساب storage. يحدد نهج انتهاء صلاحية SAS الفاصل الزمني الموصى به الذي يكون SAS صالحًا خلاله. تنطبق نُهج انتهاء صلاحية SAS على SAS للخدمة أو للحساب. عندما ينشئ مستخدم SAS للخدمة أو SAS للحساب بفاصل زمني للصلاحية أكبر من الفاصل الزمني الموصى به، سيظهر له تحذير. إذا كان تسجيل Azure Storage مع Azure Monitor مفعلا، فيتم كتابة إدخال إلى سجلات Azure Storage. لمعرفة المزيد، راجع إنشاء سياسة انتهاء للتوقيعات access المشتركة.

  • أنشئ سياسة access مخزن لخدمة SAS. تمنحك سياسات access المخزن خيار إلغاء صلاحيات خدمة SAS دون الحاجة لإعادة توليد مفاتيح حساب storage. تعيين انتهاء الصلاحية على هذه بعيدة جداً في المستقبل (أو لانهائية) وتأكد من تحديثها بانتظام لنقلها على نحو أبعد في المستقبل. هناك حد أقصى لخمس سياسات access مخزن لكل حاوية.

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

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

  • توخي الحيطة والحذر مع وقت بدء SAS. إذا قمت بتعيين وقت البدء لتوقيعات الوصول المشترك إلى الوقت الحالي، قد تحدث عمليات فاشلة بشكل متقطع في الدقاق القليلة الأولى. يرجع ذلك إلى الأجهزة المختلفة ذات الأوقات الحالية المختلفة على نحو طفيف (المعروفة باسم انحراف على مدار الساعة). بشكل عام، عيِّن وقت البدء ليكون 15 دقيقة على الأقل في الماضي. أو، لا تعيِّنه على الإطلاق، مما يجعله صالحاً على الفور في جميع الحالات. وينطبق الأمر نفسه بشكل عام على وقت انتهاء الصلاحية أيضاً -- تذكر أنه يمكنك ملاحظة ما يصل إلى 15 دقيقة من الانحراف الزمني في أي اتجاه بأي طلب. بالنسبة للعملاء الذين استخدموا نسخة REST قبل 2012-02-12، الحد الأقصى لمدة لنظام SAS الذي لا يشير إلى بوليصة access مخزن هو ساعة واحدة. ستفشل أي نهج تحدد مدة أطول من ساعة واحدة.

  • توخَ الحذر عند تنسيق وقت تاريخ توقيعات الوصول المشترك. بالنسبة لبعض الأدوات المساعدة (مثل AzCopy)، يتعين تنسيق قيم التاريخ/الوقت على النحو التالي '+%Y-%m-%dT%H:%M:%SZ'. يشمل هذا التنسيق الثواني بشكل خاص.

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

    لا توجد طريقة مباشرة لتحديد العملاء الذين قاموا بالوصول إلى مورد. ومع ذلك، يمكنك استخدام الحقول الفريدة في SAS، مثل IP الموقع (sip)، وبداية الموقع (st)، وحقل انتهاء النهاية الموقعة (se)، لتتبع access. على سبيل المثال، يمكنك إنشاء رمز SAS مميز بوقت انتهاء صلاحية فريد يمكنك بعد ذلك ربطه بالعميل الذي تم إصداره إليه.

  • معرفة أنه سيتم فوترة حسابك نظير أي استخدام، بما في ذلك من خلال توقيعات الوصول المشترك. إذا وفرت access للكتابة إلى blob، قد يختار المستخدم رفع كتلة بحجم 200 جيجابايت. إذا منحتهم access قراءة أيضا، قد يختارون تحميله 10 مرات، مما يكلفك 2 تيرابايت كتكاليف خروج. مرة أخرى، احرص على تقديم أذونات محدودة للمساعدة في الحد من الأعمال المحتملة التي يمكن أن يقدم عليها المستخدمون الضارون. استخدم SAS قصيرة الأمد للحد من هذا التهديد (لكن ضع في اعتبارها الانحراف الزمني في وقت الانتهاء).

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

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

  • Use Azure Monitor و Azure Storage logs لمراقبة تطبيقك. يمكن أن تحث عمليات فاشلة في التخويل بسبب انقطاع في خدمة موفر توقيعات الوصول المشترك. يمكن أن تحدث أيضا نتيجة إزالة غير مقصودة لسياسة access المخزنة. يمكنك استخدام Azure Monitor وتسجيل storage analytics لملاحظة أي ارتفاع في هذه الأنواع من فشل التفويض. لمزيد من المعلومات، راجع مقاييس Azure Storage في Azure Monitor و Azure Storage Analytics logging.

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

إشعار

لا يتتبع Storage عدد توقيعات access المشتركة التي تم إنشاؤها لحساب storage، ولا يمكن لأي واجهة برمجة تطبيقات تقديم هذه التفاصيل. إذا كنت بحاجة لمعرفة عدد توقيعات access المشتركة التي تم إنشاؤها لحساب storage، يجب عليك تتبع الرقم يدويا.

Get started مع SAS

للget started with shared access signatures، راجع المقالات التالية لكل نوع من أنواع SAS.

توقيعات الوصول المشترك لتفويض المستخدم

توقيعات الوصول المشترك للخدمات

توقيعات الوصول المشترك للحسابات

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

  • Last updated on