أفضل الممارسات في Azure Enclave

تصف هذه المقالة المفاهيم الرئيسية وأفضل الممارسات ل Azure Enclave.

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

يتطلب بناء وتشغيل أحمال العمل بنجاح في Azure Enclave فهم وتنفيذ بعض المفاهيم الرئيسية، بما في ذلك:

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

إعداد Azure

اقرأ هذه الخطوات لتحديد ما إذا كانت هذه الخطوات تناسب حالات استخدام Azure Enclave الخاصة بك.

تكوين مجموعات موارد Network Watcher

لتجنب المشاكل المحتملة في إنشاء سجل تدفق الشبكة الافتراضية ، قم بإعداد NetworkWatcherRG مجموعة الموارد يدويا مسبقا وخصص Mission Enclave للتطبيق Owner الدور في تلك المجموعة، أو تحقق من أن الإعداد وتعيين الأدوار تم تلقائيا قبل إنشاء أول enclave في الاشتراك.

لتقليل هذه المشكلة المحتملة، لكل اشتراك، قم يدويا بإنشاء مجموعة موارد NetworkWatcher التي تم استدعاؤها NetworkWatcherRG للاشتراكات الجديدة، ثم امنح Mission Enclave تطبيق Owner Azure Enclave على NetworkWatcherRG:

  1. اختر NetworkWatcherRG مجموعة الموارد، ثم اختر Access control (IAM)Add و Add role assignment.

لقطة شاشة تظهر مجموعة الموارد التي تضيف اختيار الأدوار في البوابة.

  1. اختر Privileged administrator roles، ثم اختر ownerNext.

لقطة شاشة تظهر عرض اختيار دور المالك الإضافي في البوابة.

  1. اختر Select members، واكتب Mission Enclave في البحث واختر Mission Enclave التطبيق، ثم اختر Select، ثم Next.

لقطة شاشة توضح كيفية اختيار تطبيق Mission Enclave في البوابة.

  1. إذا كان اشتراكك يتطلب شرطا، اختر Allow user to assign all roles except privileged administrator roles Owner, UAA, RBAC (Recommended)، ثم اختر Review + assign.

لقطة شاشة تظهر عرض إضافة الحالة إذا كان اشتراكك يتطلب ذلك.

  1. بمجرد اكتمال التحديث، يمكنك البدء في نشر موارد Azure Enclave.

عند إنشاء مجتمع أو جيب، يحاول Azure Enclave الخطوات التالية:

  1. تحقق مما إذا كان موجودا NetworkWatcherRG . إذا لم يكن كذلك، حاول إنشاء مجموعة الموارد تلك.
  2. تحقق مما إذا كان التطبيق Mission Enclave يحتوي على مهمة دائمة Owner على NetworkWatcherRG. إذا لم يكن كذلك، حاول تعيين التطبيق Mission Enclave كتعيين دائم Owner على NetworkWatcherRG. حتى إذا وجد إذن موروث Owner ، يتم محاولة إنشاء تعيين دائم Owner .
  3. إذا فشلت أي خطوة، قد تفشل عمليات نشر الشبكة عند محاولة إنشاء سجلات تدفق الشبكة الافتراضية.

أنماط الشبكات وتصميم التنظيم ل Azure Enclave

متعدد المستأجرين

تصميم الشبكات

يجمع Azure Enclave بين قدرات ومرونة عدة منتجات شبكات Azure في واجهة مستخدم مبسطة، بما في ذلك:

  • WAN ظاهرية
  • Azure Firewall
  • الشبكة الافتراضية في Azure
  • مجموعات أمان الشبكة

تقدم Azure Enclave التوصيات العامة التالية:

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

اعتبارات تصميم الشبكات المجتمعية

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

اعتبارات تصميم شبكة إنكليف

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

تعرف أكثر على أفضل الممارسات العامة لشبكات Azure.

نشر عبء العمل

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

أنماط تصميم الأمان ل Azure Enclave

ضع في اعتبارك أنماط تصميم الأمان هذه عند تصميم بيئات Azure Enclave الخاصة بك.

حدود الأمن

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

المسؤوليات الأمنية المشتركة

كخدمة على Azure، تلتزم Azure Enclave أيضا بالحفاظ على نموذج المسؤولية المشتركة في السحابة. بالنسبة ل Azure Enclave تحديدا، فإن أعباء العمل تقع على عاتقك. المسؤولية المشتركة ل Azure تورث في أحمال العمل إذا قمت بنشر خدمات PaaS في أحمال عملك.

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

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

أفضل الممارسات في Azure Security

توصي Azure Enclave باتباع أفضل الممارسات والأنماط الأمنية من Microsoft Azure لنشر موارد Azure وتنفيذ أعباء العمل.

يجب عليك اتباع أفضل ممارسات الأمان في Azure - Cloud Adoption Framework لتنظيم أنظمتك، والبنية التحتية السحابية، وهياكل موظفي تكنولوجيا المعلومات والفريق، وتدريبات التوعية بالأمن السيبراني للشركات.

سحب البيانات عبر نظام أسماء النطاقات

يمثل استخراج البيانات عبر نظام أسماء النطاقات (DNS) قلقا أمنيا كبيرا للمؤسسات، حيث يستخدم بروتوكولا يسمح عادة عبر جدران الحماية ونادرا ما يتم مراقبته للنشاط الخبيث. يمكن للمهاجمين استغلال استعلامات DNS لاستخراج بيانات حساسة سرا من الأنظمة المخترقة عن طريق ترميز المعلومات داخل أسماء النطاقات أو باستخدام تقنيات نفق DNS. هذه الطريقة خبيثة لأن حركة DNS تبدو شرعية وغالبا ما تتجاوز أدوات مراقبة الأمان التقليدية.

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

معالجة تسريب البيانات باستخدام سياسة أمان Azure DNS

توفر سياسة أمان Azure DNS حماية شاملة ضد هجمات استخراج البيانات المعتمدة على DNS من خلال توفير تحكم دقيق في حركة مرور DNS داخل شبكات Azure الافتراضية. تمكن هذه الخدمة المؤسسات من تنفيذ تدابير أمنية استباقية يمكنها اكتشاف وتنبيه وحظر نشاط DNS المشبوه قبل أن يتم استخراج البيانات بنجاح.

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

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

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

مزيد من المعلومات متاحة في وثائق سياسة أمان DNS.

تنفيذ سياسات أمان DNS بنظام الإنكار الافتراضي

لتحقيق أقصى درجات الأمان في بيئات Azure Enclave، يجب على المؤسسات تنفيذ نهج "رفض افتراضي، السماح بالاستثناء" في تصفية DNS. يضمن هذا النموذج الأمني حظر جميع استعلامات DNS ما لم يسمح بها صراحة، مما يوفر أقوى حماية ضد استخراج البيانات المعتمدة على DNS والاتصالات الأوامر والتحكم.

يتم تنفيذ نهج الرفض الافتراضي باستخدام هيكل قواعد DNS من مستويين ضمن سياسة Azure DNS Security Policy:

الخطوة 1: إنشاء قاعدة الرفض الافتراضية أنشئ قائمة نطاقات DNS تحتوي فقط على النطاق . الجذر (dot). هذا النطاق البري يتطابق مع جميع استعلامات DNS الممكنة. ربط قائمة النطاقات هذه بقاعدة حركة مرور DNS مهيأة ب:

  • الأولوية: 65000 (أقل أولوية)
  • الأكشن: بلوك
  • قائمة النطاق: النطاق الجذري (.)

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

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

  • خدمات Essential Azure (على سبيل المثال, *.azure.com, *.microsoft.com)
  • النطاقات المؤسسية والخدمات الموثوقة غير التابعة ل خدمات Microsoft
  • خدمات تحديث نظام التشغيل
  • نطاقات سلطة الشهادات

ربط قوائم التسميح بقواعد مرور DNS المكونة على:

  • الأولوية: 500-1000 (أولوية أعلى من الرفض الافتراضي)
  • الإجراء: السماح
  • قوائم النطاقات: نطاقات معتمدة محددة

معالجة القواعد القائمة على الأولوية تقوم Azure DNS Security Policy بمعالجة القواعد بترتيب الأولوية (أرقام أقل = أولوية أعلى). عند إجراء استعلام DNS:

  1. يقوم النظام أولا بتقييم قواعد التصريح ذات الأولوية العالية (الأولوية من 500 إلى 1000)
  2. إذا تطابق النطاق قائمة التصاريح، يكون الاستعلام مسموحا به
  3. إذا لم allow تتطابق القواعد، ينتقل الاستعلام إلى قاعدة الرفض الافتراضية (الأولوية 65000) ويتم حظر حركة المرور

يوفر هذا النهج عدة مزايا أمنية:

  • نموذج الثقة الصفرية: لا يسمح باستعلامات DNS إلا إذا تم تفويضها صراحة
  • التحكم الدقيق: يمكن للمؤسسات التحكم بدقة في النطاقات المتاحة
  • مسار التدقيق: يتم تسجيل جميع الاستعلامات المحجوبة، مما يوفر رؤية للتهديدات المحتملة
  • تحديثات تدريجية: يمكن إضافة نطاقات جديدة معتمدة للسماح بالقوائم دون تعديل قاعدة الرفض الافتراضية

مثال على التنفيذ:

Priority 500: Allow rule for Azure services
- Domain List: azure-services (contains azure.com., microsoft.com.)
- Action: Allow

Priority 600: Allow rule for business applications
- Domain List: business-domains (contains company.com., partner1.com., partner2.com.)
- Action: Allow

Priority 65000: Default deny rule
- Domain List: deny-all (contains .)
- Action: Block

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

تنفيذ سياسات رفض DNS بالافتراضي مع خادم DNS في Windows

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

يدعم Windows DNS Server (Windows Server 2016 وما بعده) وظائف سياسة DNS التي تمكن المؤسسات من تنفيذ قواعد تصفية DNS متقدمة. يمكن تحقيق نموذج الرفض الافتراضي من خلال مزيج من قواعد سياسة DNS وتكوينات المناطق.

مجموعات الموارد المدارة في Azure Enclave

مجموعات الموارد التي تحتوي على موارد تديرها Azure Enclave.

مجموعة الموارد المدارة مجتمعيا

تحتوي مجموعة الموارد المدارة للمجتمع على موارد البنية التحتية الموصوفة في ما هو المجتمع؟.

اسم مجموعة الموارد المدارة من قبل المجتمع يتبع هذا التقليد: myCommunityName-HostedResources-<GUID>. كل نشر مجتمعي ينشئ هذه المجموعة من الموارد ويضع البنية التحتية المجتمعية داخلها. عندما تحذف مجتمعك، يقوم مزود الموارد في Azure Enclave تلقائيا بحذف مجموعة الموارد المدارة من قبل المجتمع.

لقطة شاشة تظهر مثالا على موارد المجتمع التي تديرها Azure Enclave.

مجموعة الموارد المدارة مجتمعيا لديها القيود التالية:

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

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

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

ملحوظة

إذا لم يكن لديك قفل مجموعة الموارد المدارة من المجتمع مفعلا، يمكنك تعديل أي مورد في مجموعة الموارد المدارة بشكل مباشر. تعديل الموارد مباشرة في مجموعة الموارد المدارة من قبل المجتمع يمكن أن يجعل منطقتك غير مستقرة أو غير مستجيبة.

مجموعة الموارد المدارة في إنكليف

تحتوي مجموعة الموارد المدارة في الإنكليف على موارد البنية التحتية الموصوفة في ما هو الجبل؟.

يتبع اسم مجموعة الموارد المدارة في الإنكليف هذا التقليد: myEnclaveName-HostedResources-<GUID>. كل نشر للمنطقة يخلق هذه المجموعة من الموارد ويضع البنية التحتية للإنكليف داخلها. عندما تحذف المركز الخاص بك، يقوم مزود موارد Azure Enclave تلقائيا بحذف مجموعة الموارد المدارة في ال enclave.

لقطة شاشة تظهر مثالا على موارد ال enclave التي تديرها Azure Enclave.

مجموعة الموارد المدارة في الإنكليف لها القيود التالية:

  • لا يمكنك تحديد مجموعة موارد موجودة لمجموعة الموارد المدارة في الجيب.
  • لا يمكنك تحديد اشتراك مختلف لمجموعة الموارد المدارة في Enclave.
  • لا يمكنك تغيير اسم مجموعة الموارد المدارة في ال enclave بعد إنشاء المحاصرة.
  • لا يمكنك تحديد أسماء للموارد المدارة ضمن مجموعة الموارد المدارة في ال enclave.
  • لا يمكنك تعديل أو حذف العلامات التي أنشأتها Azure للموارد المدارة ضمن مجموعة الموارد المدارة في enclave.

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

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

التحذير

تعديل الموارد في مجموعة الموارد المدارة في الإنكليف قد يجعل الجندي غير مستقر أو غير مستجيب.

مجموعة موارد عبء العمل

يرتبط عبء العمل بمجموعة أو أكثر من الموارد حيث يمكنك إنشاء وتنظيم موارد Azure الخاصة بك.

إضافة مجموعة موارد إلى عبء العمل

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

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

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

بعد إنشاء مجموعة موارد عبء عمل باستخدام الخيار 3، ترى تحذيرا بأن الخيار 3 لا يمكن استخدامه لمجموعات موارد عبء العمل التالية على ذلك العبء. يمكنك أيضا إنشاء عبء عمل جديد ثم إنشاء مجموعة موارد عبء عمل جديدة باستخدام الخيار 3 مرة أخرى.

أضف مجموعة موارد إلى منطقتك:

  1. افتح صفحة بوابة Azure لتحميل عبء العمل.
  2. اختر Manage ثم Resource Groups.
  3. حدد Add a resource group.
  4. في النافذة الجانبية التي تفتح، اختر Create new إدخال اسم مجموعة الموارد الفارغة الجديدة، أو اختر Resource Group القائمة المنسدلة لاختيار مجموعة موارد موجودة.
  5. اختر OK ثم Save.

كيف تختلف مجموعة موارد عبء العمل عن مجموعات موارد Azure الأخرى؟

مجموعة موارد عبء العمل هي عنصر أساسي في أمان والامتثال في Azure Enclave لأن الموارد المهمة تنشأ هناك. نظرا لأن مجموعات موارد عبء العمل هذه مرتبطة بعبء عمل، وعبء العمل مرتبط ب enclave، يدير Azure Enclave حذف مجموعات الموارد المدارة من خلال عبء العمل.

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

تنظيم الموارد في مجموعات موارد عبء العمل

إذا أردت تقسيم مواردك إلى مجموعتين من الموارد، يمكنك اختيار أي من هذين الخيارين:

  • قسم تلك الموارد بين مجموعتين من الموارد مرتبطتين بعبء عمل واحد
  • قسم تلك الموارد بين عبء عمل، كل منهما يحتوي على مجموعة موارد أو أكثر

حذف عبء العمل

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

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

مجموعة الموارد المدارة في عبء العمل لها القيود التالية:

  • لا يمكنك تحديد مجموعة موارد موجودة لمجموعة الموارد المدارة في عبء العمل.
  • لا يمكنك تحديد اشتراك مختلف لمجموعة الموارد المدارة في عبء العمل.
  • لا يمكنك تغيير اسم مجموعة الموارد المدارة في عبء العمل بعد إنشاء عبء العمل.
  • لا يمكنك تعديل أو حذف العلامات التي أنشأتها Azure للموارد المدارة ضمن مجموعة الموارد المدارة في عبء العمل.

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

أفضل الممارسات الأخرى ل Azure

أثناء بناء مجتمعاتك وجيوبك وأعباء العمل في Azure، من المهم أن تضع في اعتبارك المبادئ التصميمية العالمية التالية:

  • Last updated on