المصادقة باستخدام خرائط Azure

مقالة
07/05/2023

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

إشعار

لتحسين الاتصال الآمن باستخدام خرائط Azure، ندعم الآن بروتوكول أمان طبقة النقل (TLS) 1.2، وسنسحب دعم TLS 1.0 و1.1. إذا كنت تستخدم TLS 1.x حالياً، فقم بتقييم مدى استعداد TLS 1.2 لديك وقم بتطوير خطة ترحيل مع الاختبار الموضح في حل مشكلة TLS 1.0.

مصادقة المفتاح المشترك

للحصول على معلومات حول عرض المفاتيح في مدخل Microsoft Azure، راجع عرض تفاصيل المصادقة.

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

مثال على استخدام مفتاح الاشتراك كمعامل في عنوان URL الخاص بك:

https://atlas.microsoft.com/mapData/upload?api-version=1.0&dataFormat=zip&subscription-key={Your-Azure-Maps-Subscription-key}

هام

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

مصادقة Microsoft Entra

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

يقبل خرائط Azureرموز وصول OAuth 2.0 لمستأجري Microsoft Entra المقترنين باشتراك Azure الذي يحتوي على حساب خرائط Azure. يقبل خرائط Azure أيضاً الرموز المميزة لـ:

مستخدمو Microsoft Entra
التطبيقات الشريكة التي تستخدم الأذونات المفوضة من قبل المستخدمين
الهويات المُدارة لموارد Azure

تنشئ خرائط Azure معرفاً فريداً (معرف العميل) لكل حساب خرائط Azure. يمكنك طلب رموز مميزة من معرف Microsoft Entra عند دمج معرف العميل هذا مع معلمات أخرى.

لمزيد من المعلومات حول كيفية تكوين معرف Microsoft Entra وطلب الرموز المميزة خرائط Azure، راجع إدارة المصادقة في خرائط Azure.

للحصول على معلومات عامة حول المصادقة باستخدام معرف Microsoft Entra، راجع المصادقة مقابل التخويل.

الهويات المُدارة لموارد Azure وخرائط Azure

توفر الهويات المدارة لموارد Azure خدمات Azure مع أساس أمان يستند إلى تطبيق مدار تلقائيا يمكنه المصادقة باستخدام معرف Microsoft Entra. باستخدام التحكم في الوصول المستند إلى الدور Azure (Azure RBAC)، يمكن تفويض مبدأ أمان الهوية المُدار للوصول إلى خدمات خرائط Azure. تتضمن بعض أمثلة الهويات المدارة: Azure App Service وAzure Functions وأجهزة Azure الظاهرية. للحصول على قائمة بالهويات المدارة، راجع خدمات Azure التي يمكنها استخدام الهويات المدارة للوصول إلى خدمات أخرى. لمزيد من المعلومات حول الهويات المدارة، راجع إدارة المصادقة في خرائط Azure.

تكوين تطبيق مصادقة Microsoft Entra

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

بعد أن يتلقى التطبيق رمز وصول، يرسل SDK و/أو التطبيق طلب HTTPS مع المجموعة التالية من رؤوس HTTP المطلوبة بالإضافة إلى رؤوس REST API HTTP الأخرى:

اسم الرأس	القيمة‬
x-ms-client-id	30d7cc... 9f55
التخويل	حامل eyJ0e... HNIVN

إشعار

x-ms-client-id هو GUID المستند إلى حساب Azure خرائط الذي يظهر في صفحة مصادقة خرائط Azure.

فيما يلي مثال على طلب توجيه خرائط Azure يستخدم الرمز المميز لمعرف Microsoft Entra OAuth Bearer:

GET /route/directions/json?api-version=1.0&query=52.50931,13.42936:52.50274,13.43872
Host: atlas.microsoft.com
x-ms-client-id: 30d7cc….9f55
Authorization: Bearer eyJ0e…HNIVN

للحصول على معلومات بشأن عرض معرف العميل الخاص بك، راجع عرض تفاصيل المصادقة.

تلميح

الحصول على معرف العميل برمجياً

عند استخدام PowerShell، يتم تخزين معرف العميل كخاصية UniqueId في عنصر IMapsAccount. يمكنك استرداد هذه الخاصية باستخدام Get-AzMapsAccount، على سبيل المثال:

$maps = Get-AzMapsAccount -Name {Azure-Maps_Account-Name} -ResourceGroupName {Resource-Group-Name} -SubscriptionId {SubscriptionId}
$ClientId = $maps.UniqueId

عند استخدام واجهة مستوى الاستدعاء (Azure CLI)، استخدم الأمر az maps account show مع المعلمة --query، على سبيل المثال:

$ClientId = az maps account show --name {Azure-Maps_Account-Name} --resource-group {Resource-Group-Name} --subscription {SubscriptionId} --query properties.uniqueId

التخويل مع التحكم في الوصول على أساس الدور

المتطلبات الأساسية

إذا كنت جديدا على Azure RBAC، فإن نظرة عامة على التحكم في الوصول استنادا إلى الدور في Azure (Azure RBAC) توفر منح الأنواع الأساسية مجموعة من الأذونات، والمعروفة أيضا باسم تعريف الدور. يوفر تعريف الدور أذونات لإجراءات REST API. يدعم خرائط Azure الوصول إلى جميع الأنواع الأساسية ل التحكم في الوصول استنادا إلى الدور في Azure (Azure RBAC) بما في ذلك: مستخدمو Microsoft Entra الفرديون والمجموعات والتطبيقات وموارد Azure والهويات المدارة في Azure. يُعرف تطبيق الوصول إلى واحد أو أكثر من حسابات خرائط Azure بالنطاق. يتم إنشاء تعيين دور عند تطبيق أساس وتعريف دور ونطاق.

نظرة عامة

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

عندما تقوم بتكوين Azure RBAC، فإنك تختار كيان أمان وتطبقه على تعيين دور. لمعرفة كيفية إضافة تعيينات الأدوار على مدخل Microsoft Azure، راجع تعيين أدوار Azure باستخدام مدخل Microsoft Azure.

اختيار تعريف الدور

توجد أنواع تعريف الدور التالية لدعم سيناريوهات التطبيق.

تعريف دور Azure	‏‏الوصف
بحث خرائط Azure وعرض قارئ البيانات	يوفر خرائط Azure الوصول إلى البحث فقط وعرض واجهات برمجة تطبيقات REST لتقييد الوصول إلى حالات استخدام مستعرض الويب الأساسية.
قارئ بيانات خرائط Azure	توفر خرائط Azure الوصول إلى واجهات برمجة تطبيقات REST غير القابلة للتغيير.
مساهم بيانات خرائط Azure	يوفر خرائط Azure الوصول إلى واجهات برمجة تطبيقات REST القابلة للتغيير. الطفرة، التي تحددها الإجراءات: الكتابة والحذف.
خرائط Azure قراءة البيانات ودور الدفعة	يمكن استخدام هذا الدور لتعيين إجراءات القراءة والدفعة على خرائط Azure.
تعريف الدور المخصص	أنشئ دوراً مُصنَّعاً لتمكين خرائط Azure من الوصول المقيد المرن إلى واجهات برمجة تطبيقات REST.

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

خدمة الخرائط Azure	تعريف دور خرائط Azure
بيانات	مساهم بيانات خرائط Azure
الخالق	مساهم بيانات خرائط Azure
مكاني	مساهم بيانات خرائط Azure
دفعة بحث ومسار	مساهم بيانات خرائط Azure

للحصول على معلومات بشأن عرض إعدادات Azure RBAC، راجع كيفية تكوين Azure RBAC لخرائط Azure.

تعريفات دور مخصصة

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

يمكن بعد ذلك استخدام تعريف الدور المخصص في تعيين دور لأي كيان أمان. لمعرفة المزيد بشأن تعريفات الأدوار المخصصة في Azure، راجع أدوار Azure المخصصة.

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

السيناريو	إجراء (إجراءات) بيانات الدور المخصص
صفحة ويب عامة أو تفاعلية لتسجيل الدخول مع مربعات خرائط أساسية ولا توجد واجهات برمجة تطبيقات REST أخرى.	`Microsoft.Maps/accounts/services/render/read`
تطبيق لا يتطلب سوى ترميز جغرافي عكسي ولا يتطلب واجهات برمجة تطبيقات REST أخرى.	`Microsoft.Maps/accounts/services/search/read`
دور لمدير الأمان، الذي يطلب قراءة بيانات الخرائط المستندة إلى Azure Maps Creator وواجهات برمجة تطبيقات REST الخاصة بلوحة الخرائط الكيانية.	`Microsoft.Maps/accounts/services/data/read`, `Microsoft.Maps/accounts/services/render/read`
دور لمدير الأمان، والذي يتطلب قراءة وكتابة وحذف بيانات الخرائط المستندة إلى المنشئ. يتم تعريفه على أنه دور محرر بيانات الخريطة الذي لا يسمح بالوصول إلى واجهة برمجة تطبيقات REST الأخرى مثل تجانبات الخريطة الأساسية.	`Microsoft.Maps/accounts/services/data/read`، ، `Microsoft.Maps/accounts/services/data/writeMicrosoft.Maps/accounts/services/data/delete`

فهم النطاق

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

تلميح

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

تعطيل المصادقة المحلية

تدعم حسابات خرائط Azure خاصية Azure القياسية في واجهة برمجة تطبيقات الإدارة ل Microsoft.Maps/accounts تسمى disableLocalAuth. عند trueتعطيل جميع المصادقة إلى واجهة برمجة تطبيقات REST لمستوى البيانات خرائط Azure، باستثناء مصادقة Microsoft Entra. تم تكوين هذا باستخدام Azure Policy للتحكم في توزيع وإدارة المفاتيح المشتركة ورموز SAS. للحصول على مزيدٍ من المعلومات، راجع ما هو نهج Azure.

لا يُفعَّل تعطيل المصادقة المحلية على الفور. انتظر بضع دقائق حتى تحظر الخدمة طلبات المصادقة المستقبلية. لإعادة تمكين المصادقة المحلية، قم بتعيين الخاصية إلى false وبعد بضع دقائق يستأنف المصادقة المحلية.

{
  // omitted other properties for brevity.
  "properties": {
    "disableLocalAuth": true
  }
}

المصادقة على رمز توقيع الوصول المشترك

الرموز المميزة لتوقيع الوصول المشترك (SAS) هي رموز مصادقة تم إنشاؤها باستخدام تنسيق JSON Web token (JWT) ويتم توقيعها بشكل مشفر لإثبات المصادقة لتطبيق على Azure خرائط REST API. رمز SAS المميز، تم إنشاؤه من خلال دمج هوية مدارة معينة من قبل المستخدم مع حساب خرائط Azure في اشتراك Azure الخاص بك. يتم منح الهوية المدارة المعينة من قبل المستخدم تخويلا لحساب خرائط Azure من خلال Azure RBAC باستخدام تعريفات الأدوار المضمنة أو المخصصة.

الاختلافات الرئيسية الوظيفية رمز SAS المميز من الرموز المميزة للوصول إلى Microsoft Entra:

مدة بقاء الرمز المميز لانتهاء صلاحية الحد الأقصى ليوم واحد (24 ساعة).
موقع Azure والتحكم في الوصول إلى الموقع الجغرافي لكل رمز مميز.
حدود السعر لكل رمز تقريباً لتقريب من 1 إلى 500 طلب في الثانية.
المفاتيح الخاصة للرمز المميز هي المفاتيح الأساسية والثانوية لمورد حساب خرائط Azure.
يتم توفير عنصر الخدمة الكياني للتخويل من خلال الهوية المُدارة يعينها المستخدم.

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

فهم حدود معدل رمزية SAS

يمكن أن يتحكم الحد الأقصى لمعدل رمز SAS المميز في الفوترة لمورد خرائط Azure

عند تحديد حد أقصى للمعدل على الرمز المميز (maxRatePerSecond)، لا تتم فوترة المعدلات الزائدة إلى الحساب مما يسمح لك بتعيين حد أعلى للمعاملات القابلة للفوترة للحساب، عند استخدام الرمز المميز. ومع ذلك، يتلقى التطبيق استجابات خطأ العميل مع 429 (TooManyRequests) لكافة المعاملات بمجرد وصول هذا الحد. تقع على عاتق التطبيق مسؤولية إدارة إعادة محاولة وتوزيع رموز SAS المميزة. لا يوجد حد لعدد رموز SAS المميزة التي يمكن إنشاؤها لحساب. للسماح بزيادة أو تقليل حد الرمز المميز الحالي؛ يجب إنشاء رمز SAS مميز جديد. لا يزال رمز SAS القديم صالحا حتى انتهاء صلاحيته.

مثال تقديري:

المعدل التقريبي الأقصى لكل ثانية	المعدل الفعلي لكل ثانية	مدة المعدل المستمر بالثواني	إجمالي العمليات القابلة للفوترة
10	20	600	6,000

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

يتم فرض حدود السعر لكل موقع Azure، وليس على مستوى العالم أو جغرافياً

على سبيل المثال، يمكن استخدام رمز SAS واحد مع maxRatePerSecond من 10 للحد من المعدل نقل في الموقع East US. إذا تم استخدام نفس الرمز المميز في West US 2، فسيتم إنشاء عداد جديد لقصر معدل النقل على 10 في ذلك الموقع، بغض النظر عن موقع East US. للتحكم في التكاليف وتحسين القدرة على التوقع، نوصي بما يلي:

قم بإنشاء رموز SAS المميزة بمواقع Azure المعينة المسموح بها للجغرافيا المستهدفة. تابع القراءة لفهم إنشاء الرموز المميزة لـ SAS.
استخدم نقاط نهاية واجهة برمجة تطبيقات REST لمستوى البيانات الجغرافية، https://us.atlas.microsoft.com أو https://eu.atlas.microsoft.com.

ضع في اعتبارك هيكل التطبيق حيث توجه نقطة النهاية https://us.atlas.microsoft.com إلى نفس المواقع الأمريكية التي تستضيف خدمات خرائط Azure، مثل East US، West Central US أو West US 2. تنطبق الفكرة نفسها على نقاط النهاية الجغرافية الأخرى مثل https://eu.atlas.microsoft.com بين West Europe وNorth Europe. لمنع رفض التخويل غير المتوقع، استخدم رمز SAS المميز الذي يستخدم نفس مواقع Azure التي يستهلكها التطبيق. يتم تحديد موقع نقطة النهاية باستخدام واجهة برمجة تطبيقات REST لإدارة خرائط Azure.

حدود المعدل الافتراضي لها الأسبقية على حدود معدل الرمز المميز لـ SAS

كما هو موضح في حدود سعر خرائط Azure، فإن عروض الخدمة الفردية لها حدود أسعار مختلفة يتم فرضها كمجموعة للحساب.

ضع في اعتبارك حالة خدمة البحث - عكس غير دفعي، بحد أقصى 250 استعلارا في الثانية (QPS) للجداول التالية. يمثل كل جدول إجمالي العمليات الناجحة المقدرة من استخدام المثال.

يعرض الجدول الأول رمزا مميزا واحدا يحتوي على طلب أقصى في الثانية من 500، والاستخدام الفعلي للتطبيق هو 500 طلب في الثانية لمدة 60 ثانية. خدمة البحث - يبلغ الحد الأقصى للسعر غير الدفعي 250 طلبا، مما يعني إجمالي 30000 طلب تم تقديمها في غضون 60 ثانية؛ 15,000 من هذه الطلبات هي معاملات قابلة للفوترة. تؤدي الطلبات المتبقية إلى رمز 429 (TooManyRequests)الحالة .

الاسم	المعدل التقريبي الأقصى لكل ثانية	المعدل الفعلي لكل ثانية	مدة المعدل المستمر بالثواني	إجمالي العمليات الناجحة التقريبية
الرمز المميز	500	500	60	~15,000

على سبيل المثال، إذا تم إنشاء رمزين مميزين في SAS، واستخدموا نفس الموقع مثل حساب خرائط Azure، فإن كل رمز يشترك الآن في حد المعدل الافتراضي البالغ 250 QPS. إذا تم استخدام كل رمز مميز في نفس الوقت مع نفس رمز معدل النقل 1 والرمز 2 فسوف يمنح بنجاح 7500 عملية ناجحة لكل منهما.

الاسم	المعدل التقريبي الأقصى لكل ثانية	المعدل الفعلي لكل ثانية	مدة المعدل المستمر بالثواني	إجمالي العمليات الناجحة التقريبية
الرمز 1	250	250	60	7500
الرمز 2	250	250	60	7500

فهم التحكم في الوصول إلى رمز SAS

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

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

هناك خياران لإبطال الوصول إلى رمز (رموز) SAS المميزة:

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

تحذير

سيؤدي حذف الهوية المُدارة المستخدمة بواسطة رمز SAS المميز أو إبطال التحكم في الوصول للهوية المُدارة إلى إرجاع مثيلات التطبيق الخاص بك باستخدام رمز SAS المميز والهوية المُدارة 401 Unauthorized أو 403 Forbidden من واجهات برمجة تطبيقات REST لخرائط Azure ما سيؤدي إلى تعطيل التطبيق.

لتجنب الاضطراب:

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

إنشاء رموز SAS

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

هام

لا تدعم حسابات خرائط Azure الحالية التي تم إنشاؤها في موقع Azure global الهويات المدارة.

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

تلميح

يجب عليك استخدام نفس الموقع لكل من الهوية المُدارة وحساب خرائط Azure.

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

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

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

معلمات الرمز المميز لـ SAS:

اسم المعلمة	مثال للقيمة	‏‏الوصف
signingKey	`primaryKey`	مطلوب، يتم استخدام قيمة قائمة تعداد السلسلة ل signingKey إما `primaryKey`، `secondaryKey` أو الهوية المدارة لإنشاء توقيع SAS.
principalId	`<GUID>`	مطلوب، معرف الأساسي هو معرف الكائن (الأساسي) للهوية المدارة المعينة من قبل المستخدم والمرفقة بحساب الخريطة.
المناطق	`[ "eastus", "westus2", "westcentralus" ]`	اختياري، القيمة الافتراضية هي `null`. تتحكم المناطق في المناطق التي يمكن استخدام رمز SAS المميز فيها في واجهة برمجة تطبيقات مستوى بيانات خرائط AZURE REST. تسمح معلمة حذف المناطق باستخدام رمز SAS المميز دون أي قيود. عند استخدامه بالاشتراك مع نقطة نهاية جغرافية خرائط Azure مستوى البيانات مثل `us.atlas.microsoft.com` ويسمح `eu.atlas.microsoft.com` للتطبيق بالتحكم في الاستخدام مع في الجغرافيا المحددة. هذا يسمح بمنع الاستخدام في مناطق جغرافية أخرى.
maxRatePerSecond	500	مطلوب، الحد الأقصى التقريبي المحدد للطلب في الثانية الذي يتم منحه رمز SAS. بمجرد الوصول إلى الحد الأقصى، يكون معدل النقل أكثر محدودا مع رمز `429 (TooManyRequests)`حالة HTTP .
بدء	`2021-05-24T10:42:03.1567373Z`	مطلوب، تاريخ UTC يحدد التاريخ والوقت الذي يصبح فيه الرمز المميز نشطاً.
تاريخ انتهاء الصلاحية	`2021-05-24T11:42:03.1567373Z`	مطلوب، تاريخ UTC يحدد تاريخ ووقت انتهاء صلاحية الرمز المميز. لا يمكن أن تكون المدة بين البدء وانتهاء الصلاحية أكثر من 24 ساعة.

تكوين التطبيق برمز SAS

بعد أن يتلقى التطبيق رمز SAS المميز، ترسل خرائط Azure SDK و/أو التطبيقات طلب HTTPS برأس HTTP المطلوب التالي بالإضافة إلى رؤوس واجهة برمجة تطبيقات REST HTTP الأخرى:

اسم الرأس	القيمة‬
التصريح	jwt-sas eyJ0e….HNIVN

إشعار

jwt-sas هو مخطط المصادقة للدلالة على استخدام رمز SAS. لا تقم بتضمين x-ms-client-id أو رؤوس مصادقة أخرى أو subscription-key معامِلات سلسلة طلب البحث.

CORS هو بروتوكول HTTP يمكّن تطبيق ويب يعمل ضمن نطاق واحد من الوصول إلى الموارد في مجال آخر. تنفذ متصفحات الويب قيوداً أمنية تُعرف باسم نهج نفس المصدر والتي تمنع صفحة الويب من استدعاء واجهات برمجة التطبيقات في مجال مختلف؛ يوفر CORS طريقة آمنة للسماح لمجال واحد (المجال الأصلي) باستدعاء واجهات برمجة التطبيقات في مجال آخر. باستخدام مورد حساب خرائط Azure، يمكنك تكوين الأصول المسموح لها بالوصول إلى خرائط Azure REST API من تطبيقاتك.

هام

CORS ليس آلية تخويل. يحتاج أي طلب يتم إجراؤه إلى حساب خريطة باستخدام REST API، عند تمكين CORS، أيضا إلى نظام مصادقة حساب خريطة صالح مثل المفتاح المشترك أو معرف Microsoft Entra أو رمز SAS المميز.

يتم دعم CORS لجميع طبقات أسعار حساب الخرائط ونقاط نهاية مستوى البيانات والمواقع.

المتطلبات الأساسية

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

إذا لم تكن معتادا على CORS، فشاهد مشاركة الموارد عبر المنشأ (CORS)، فإنه يتيح لعنوان Access-Control-Allow-Origin الإعلان عن الأصول المسموح لها باستدعاء نقاط النهاية لحساب خرائط Azure. بروتوكول CORS غير خاص خرائط Azure.

طلبات CORS

قد يتكون طلب CORS من مجال أصلي من طلبين منفصلين:

طلب اختبار مبدئي يستفسر عن قيود CORS التي تفرضها الخدمة. طلب الاختبار المبدئي مطلوب ما لم يكن الطلب هو الأسلوب القياسي GET أو HEAD أو POST أو الطلبات التي تحتوي على Authorization عنوان الطلب.
الطلب الفعلي، المقدم مقابل المورد المطلوب.

طلب ما قبل الرحلة

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

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

تستجيب الخدمة لطلب الاختبار المبدئي برؤوس Access-Control المطلوبة إذا تم استيفاء المعايير التالية:

يحتوي طلب OPTIONS على رؤوس CORS المطلوبة (رؤوس المنشأ وطريقة التحكم في الوصول والطلب)
تمت المصادقة بنجاح وتم تمكين قاعدة CORS للحساب الذي يطابق طلب الاختبار المبدئي.
تم تخطي المصادقة بسبب رؤوس الطلبات المطلوبة Authorization التي لا يمكن تحديدها في طلب الاختبار المبدئي.

عندما ينجح طلب الاختبار المبدئي، تستجيب الخدمة بتعليمة برمجية الحالة 200 (OK)، وتتضمن رؤوس التحكم في الوصول المطلوبة في الاستجابة.

ترفض الخدمة طلبات الاختبار المبدئي في حالة حدوث الشروط التالية:

إذا لم يحتوي طلب OPTIONS على رؤوس CORS المطلوبة (عناوين Origin وAcces-Control-Request-Method)، تستجيب الخدمة برمز 400 (Bad request)الحالة .
إذا نجحت المصادقة في طلب الاختبار المبدئي ولم تتطابق قاعدة CORS مع طلب الاختبار المبدئي، تستجيب الخدمة برمز 403 (Forbidden)الحالة . قد يحدث هذا إذا تم تكوين قاعدة CORS لقبول أصل لا يتطابق مع عنوان طلب أصل عميل المستعرض الحالي.

إشعار

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

الطلب الفعلي

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

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

تمكين نهج CORS

عند إنشاء حساب Map أو تحديثه، تحدد خصائصه الأصول المسموح بتكوينها. يمكنك تعيين قاعدة CORS على خصائص حساب خرائط Azure من خلال خرائط Azure Management SDK وواجهة برمجة تطبيقات REST لإدارة خرائط Azure والمدخل. بمجرد تعيين قاعدة CORS للخدمة، يتم تقييم طلب معتمد بشكل صحيح إلى الخدمة من مجال مختلف لتحديد ما إذا كان مسموحا به وفقا للقاعدة التي حددتها. على سبيل المثال:

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
    "cors": {
      "corsRules": [
        {
          "allowedOrigins": [
            "https://www.azure.com",
            "https://www.microsoft.com"
          ]
        }
      ]
    }
  }
}

يمكن تحديد قاعدة CORS واحدة فقط بقائمة الأصول المسموح بها. يسمح كل أصل بتقديم طلب HTTP إلى واجهة برمجة تطبيقات REST لخرائط Azure في مستعرض الويب الخاص بالأصل المحدد.

نهج إزالة CORS

يمكنك إزالة CORS:

يدويا في مدخل Microsoft Azure
برمجيا باستخدام:
- خرائط Azure SDK
- واجهة برمجة تطبيقات REST لإدارة خرائط Azure
- قالب ARM

تلميح

إذا كنت تستخدم واجهة برمجة تطبيقات REST لإدارة خرائط Azure، فاستخدم PUT أو PATCH مع قائمة corsRule فارغة في نص الطلب.

{
  "location": "eastus",
  "sku": {
    "name": "G2"
  },
  "kind": "Gen2",
  "properties": {
        "cors": {
          "corsRules": []
        }
    }
  }
}

فهم عمليات الفواتير

لا يحسب خرائط Azure معاملات الفوترة ل:

5xx أكواد حالة HTTP
401 (غير مصرح به)
403 (محظور)
408 (المهلة)
429 (TooManyRequests)
طلبات الاختبار المبدئي CORS

لمزيد من المعلومات حول معاملات الفوترة ومعلومات تسعير خرائط Azure الأخرى، راجع تسعير خرائط Azure.

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

لمعرفة المزيد حول أفضل ممارسات الأمان، راجع:

أفضل ممارسات المصادقة والتخويل

لمعرفة المزيد حول مصادقة تطبيق باستخدام معرف Microsoft Entra خرائط Azure، راجع:

إدارة المصادقة في خرائط Azure

لمعرفة المزيد حول مصادقة خرائط Azure Control باستخدام معرف Microsoft Entra، راجع:

استخدام عنصر التحكم في Azure Maps

Share via

المصادقة باستخدام خرائط Azure

مصادقة المفتاح المشترك

مصادقة Microsoft Entra

الهويات المُدارة لموارد Azure وخرائط Azure

تكوين تطبيق مصادقة Microsoft Entra

التخويل مع التحكم في الوصول على أساس الدور

المتطلبات الأساسية

نظرة عامة

اختيار تعريف الدور

تعريفات دور مخصصة

فهم النطاق

تعطيل المصادقة المحلية

المصادقة على رمز توقيع الوصول المشترك

فهم حدود معدل رمزية SAS

يمكن أن يتحكم الحد الأقصى لمعدل رمز SAS المميز في الفوترة لمورد خرائط Azure

يتم فرض حدود السعر لكل موقع Azure، وليس على مستوى العالم أو جغرافياً

حدود المعدل الافتراضي لها الأسبقية على حدود معدل الرمز المميز لـ SAS

فهم التحكم في الوصول إلى رمز SAS

إنشاء رموز SAS

تكوين التطبيق برمز SAS

المتطلبات الأساسية

طلبات CORS

طلب ما قبل الرحلة

الطلب الفعلي

تمكين نهج CORS

نهج إزالة CORS

فهم عمليات الفواتير

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

الموارد الإضافية

Share via

المصادقة باستخدام خرائط Azure

مصادقة المفتاح المشترك

مصادقة Microsoft Entra

الهويات المُدارة لموارد Azure وخرائط Azure

تكوين تطبيق مصادقة Microsoft Entra

التخويل مع التحكم في الوصول على أساس الدور

المتطلبات الأساسية

نظرة عامة

اختيار تعريف الدور

تعريفات دور مخصصة

فهم النطاق

تعطيل المصادقة المحلية

المصادقة على رمز توقيع الوصول المشترك

فهم حدود معدل رمزية SAS

يمكن أن يتحكم الحد الأقصى لمعدل رمز SAS المميز في الفوترة لمورد خرائط Azure

يتم فرض حدود السعر لكل موقع Azure، وليس على مستوى العالم أو جغرافياً

حدود المعدل الافتراضي لها الأسبقية على حدود معدل الرمز المميز لـ SAS

فهم التحكم في الوصول إلى رمز SAS

إنشاء رموز SAS

تكوين التطبيق برمز SAS

تبادل الموارد عبر المنشأ (CORS)

المتطلبات الأساسية

طلبات CORS

طلب ما قبل الرحلة

الطلب الفعلي

تمكين نهج CORS

نهج إزالة CORS

فهم عمليات الفواتير

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

الموارد الإضافية