منح وصول محدود إلى موارد Azure Storage باستخدام shared access signatures (SAS)

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

  • ما هي الموارد التي قد يصل إليها العميل.

  • ما هي الأذونات التي يمتلكونها لتلك الموارد.

  • ما هي مدة صلاحية توقيعات الوصول المشترك.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • العمليات على مستوى الخدمة (على سبيل المثال، عمليات الحصول على/تعيين خصائص الخدمة والحصول على إحصائيات الخدمة).

  • قراءة وكتابة وحذف العمليات غير المسموح بها من خلال توقيعات الوصول المشترك للخدمات.

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

إشعار

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

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

  • توقيع الوصول المشترك المخصص. عند إنشاء توقيع الوصول المشترك المخصص، يتم تحديد وقت البدء ووقت انتهاء الصلاحية والأذونات في SAS URI. يمكن أن يكون أي نوع من توقيع الوصول المشترك هو توقيع وصول مشترك مخصص.

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

إشعار

يتعين أن يكون توقيع الوصول المشترك لتفويض المستخدم أو توقيع الوصول المشترك للحسابات عبارة عن توقيع وصول مشترك مخصص. لا يتم دعم نُهج الوصول المخزنة لتوقيع الوصول المشترك لتفويض المستخدم أو توقيع الوصول المشترك للحسابات.

كيفية عمل توقيع وصول مشترك

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

إشعار

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

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

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

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

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

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

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

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

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

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

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

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

رمز SAS المميز

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

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

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

Diagram showing the components of a resource URI with SAS token.

إشعار

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

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

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

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

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

    Scenario diagram: Front-end proxy service

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

    Scenario diagram: SAS provider service

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

إضافة إلى ذلك، تُطلب توقيعات الوصول المشترك لتخويل الوصول إلى الكائن المصدر في لأحد عمليات النسخ في بعض السيناريو المحددة:

  • عند نسخ كائن ثنائي كبير الحجم إلى كائن آخر موجود في حساب تخزين مختلف.

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

  • عند نسخ ملف إلى ملف آخر موجود في حساب تخزين مختلف.

    يمكنك اختيارياً استخدام توقيعات الوصول المشترك لتخويل الوصول إلى الملف الخاص بالوجهة أيضاً.

  • عند نسخ كائن ثنائي كبير الحجم إلى ملف، أو ملف إلى كائن ثنائي كبير الحجم.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

إشعار

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

البدء باستخدام SAS

لبدء استخدام توقيعات الوصول المشترك، راجع المقالات التالية لكل نوع من أنواع SAS.

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

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

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

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