إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تشرح هذه المقالة كيفية تصميم DNS لشبكات Azure باستخدام مناطق DNS الخاصة، وحل Azure DNS الخاص، وضوابط الأمان في DNS. يغطي أنماط حل الأسماء الخاصة، وإعادة توجيه DNS الهجينة، وتكامل DNS مع النقاط النهائية الخاصة، وحماية التهديدات في طبقة DNS.
ما تغطيه هذه المقالة
DNS هو أساس الاتصال الشبكي: كل اتصال يبدأ باستعلام حل الاسم. في Azure، يحدد تصميم DNS كيف تكتشف أحمال العمل بعضها البعض عبر الشبكات الافتراضية، وكيف تحل الأنظمة المحلية الأسماء المستضافة في Azure، وكيف تصبح نقاط النهاية الخاصة قابلة للوصول عبر أسماء النطاقات المؤهلة بالكامل (FQDNs). بعيدا عن الدقة، DNS هو أيضا سطح هجوم. تمثل عمليات نفق DNS، والتسلل، والاستعلامات إلى النطاقات الخبيثة تهديدات حقيقية تتطلب ضوابط أمنية في طبقة DNS.
تتناول هذه المقالة ثلاثة مخاوف تتعلق بنظام DNS:
- حل الاسم الخاص: كيف تقوم الآلات الافتراضية، والحاويات، وخدمات المنصات بحل الأسماء داخل Azure دون تعريض استعلامات DNS إلى الإنترنت العام.
- إعادة توجيه DNS الهجينة: كيف تحل الشبكات المحلية Azure private names and how Azure workloads resolve on-premises names.
- أمان DNS: كيفية حظر استعلامات DNS الخبيثة، ومنع تسرب DNS، وتمكين تصفية الشبكة القائمة على FQDN.
من يحتاج إلى هذا المقال
اقرأ هذا المقال إذا كنت:
- قم بنشر نقاط نهاية خاصة (إذا كانت مناسبة لسيناريوك) وتحتاج إلى أحمال عمل لحل
privatelink.*مناطق DNS بشكل صحيح. - تشغيل بيئات هجينة حيث يجب على الأنظمة المحلية حل أسماء Azure الخاصة (أو العكس).
- استخدم Azure Firewall وتحتاج إلى تصفية قائمة على FQDN في قواعد الشبكة.
- أرغب في حظر استعلامات DNS إلى النطاقات الخبيثة المعروفة في طبقة المعالجة.
- إدارة بيئات متعددة VNet حيث تبسط دقة DNS المركزية العمليات.
- خطط بنية DNS لطوبولوجيات محور المحور مع خدمات مشتركة.
التركيز على الرفع والتغيير: الحفاظ على سلوك تسمية DNS الحالي أثناء الترحيل. استخدم التوجيه ثنائي الاتجاه بين DNS المحلي وAzure، وضبط المحولات الشرطية لحل الأفق المنقسم، واستضافة أسماء Azure الخاصة في مناطق Private DNS حتى تحتفظ التطبيقات بتكوين DNS الحالي.
تحديث التركيز: مركزة حل الأسماء أثناء إعادة برمجة أعباء العمل. استخدم Azure DNS Private Resolver مع مجموعات قواعد إعادة التوجيه للحل الهجين، ودمج مناطق Private DNS مع نقاط النهاية الخاصة لخدمات PaaS، وتمكين بروكسي Azure Firewall DNS بحيث تشترك قواعد FQDN وحل DNS في مسار واحد مخبأ.
التركيز عبر السحابة: خطط لتحويل DNS عبر السحب قبل ترحيل عبء العمل. استخدم Azure DNS Private Resolver لحل الأسماء عبر السحابة، وضبط التوجيه الشرطي باستخدام AWS Route 53 Resolver أو Google Cloud DNS، وخفض قيم TTL قبل الانتقال لتقليل خطر التخزين المؤقت القديم.
خدمات وميزات Azure
الجدول التالي يصف خدمات وميزات Azure المتعلقة بأمان DNS وحل الأسماء الخاصة.
| الخدمة / الميزة | الغرض | قدرة المفاتيح | وقت الاستخدام |
|---|---|---|---|
| Azure DNS (public zones) | الاستضافة الموثوقة لأسماء النطاق العام | Global anycast network, Azure RBAC integration, alias records for Azure resources | أنت تملك ملكا عاما وتريد استضافة سجلات DNS في Azure مع توفر عالي. |
| مناطق Azure Private DNS | حل الأسماء داخل الشبكات الافتراضية دون التعرض للجمهور | ربط VNet، التسجيل التلقائي لأسماء المضيفين في VM، استضافة مناطق الروابط الخاصة | حل الأسماء الداخلية لأحمال Azure. مطلوب لتكامل DNS الخاص بنقطة النهاية. |
| محلل Azure DNS الخاص | توجيه DNS بين شبكات Azure والشبكات الخارجية | نقطة النهاية الواردة (→ Azure حل في الموقع الافتراضي)، نقطة النهاية الصادرة (Azure → التوجيه المحلي)، مجموعات قواعد إعادة التوجيه | بيئات هجينة تحتاج إلى حل DNS ثنائي الاتجاه دون نشر أجهزة DNS افتراضية مخصصة. |
| Azure Firewall DNS proxy | اعتراض DNS المركزي لتصفية FQDN | يخزن استجابات DNS مؤقتا، ويمكن قواعد الشبكة المبنية على FQDN، ويوفر نقطة نهاية DNS واحدة لشبكات VNet المضطربة | أنت تنشر Azure Firewall وتحتاج إلى تصفية FQDN في قواعد الشبكة. مطلوب للحصول على دقة FQDN متسقة. |
| سياسة أمان DNS | حماية التهديدات في طبقة DNS | يمنع حل النطاقات الخبيثة المعروفة باستخدام تغذية Microsoft Threat Intelligence | تريد منع أحمال العمل من الاتصال بأنظمة الأوامر والسيطرة أو نطاقات توزيع البرمجيات الخبيثة. |
مفاهيم مناطق Private DNS
توفر مناطق Private DNS حل أسماء الشبكات الافتراضية المرتبطة دون كشف السجلات على الإنترنت. السلوكيات الرئيسية:
- ربط VNet: يمكنك ربط منطقة DNS خاصة بعدة VNets. جميع الموارد في شبكات VNet المرتبطة يمكنها حل السجلات في المنطقة.
- التسجيل التلقائي: عند تفعيله على رابط VNet، يقوم Azure تلقائيا بإنشاء سجلات A للآلات الافتراضية المنشورة في ذلك الVNet. يقوم Azure بإزالة السجلات عند توزيع أو حذف الأجهزة الافتراضية. التسجيل التلقائي يعمل فقط على الأجهزة الافتراضية (بطاقة الشبكة الأساسية فقط). يمكن ل VNet التسجيل تلقائيا في منطقة DNS خاصة واحدة فقط، لكن يمكنك ربط عدة VNet بنفس المنطقة.
- Private Endpoint DNS: تتطلب خدمات Azure التي يتم الوصول إليها عبر Private Endpoints مناطق DNS خاصة بالارتباط (على سبيل المثال،
privatelink.blob.core.windows.netمساحة تخزين Azure Blob). بدون المنطقة الصحيحة، يقوم العملاء بحل عنوان IP العام بدلا من عنوان النقطة النهائية الخاص.
بنية DNS Private Resolver
يستبدل Azure DNS Private Resolver الحاجة إلى آلات افتراضية مخصصة لنظام DNS في سيناريوهات التوجيه الهجينة. يوضح الرسم البياني التالي تدفق حل DNS الهجين من الموقع المحلي عبر Azure DNS Private Resolver إلى عنوان IP خاص لنقطة النهاية الخاصة.
يستخدم المحلل نوعين من نقاط النهاية:
-
نقطة النهاية الواردة: يوفر عنوان IP يمكن لخوادم DNS المحلية استهدافه كجهاز توجيه مشروط. يقوم Azure DNS بحل الاستعلامات المرسلة إلى هذا العنوان (بما في ذلك مناطق Private DNS المرتبطة). يتطلب شبكة فرعية مخصصة مفوضة ل
Microsoft.Network/dnsResolvers. - نقطة نهاية خارجية: تمكين أحمال عمل Azure من توجيه استعلامات DNS إلى خوادم DNS المحلية أو مزودي السحابة الآخرين أو المحللات الخارجية. كما يتطلب شبكة فرعية مخصصة. تحدد مجموعات قواعد التوجيه المرفقة بنقطة النهاية الصادرة أي لاحقات النطاق يجب توجيهها وأي خوادم DNS المستهدفة تستخدمها.
مهم
كل نقطة نهاية داخلة وخارجة تتطلب شبكة فرعية مخصصة خاصة بها. لا يمكنك نشر موارد أخرى في هذه الشبكات الفرعية. VNet المرتبط بمجموعة قواعد إعادة التوجيه لا يحتاج إلى أن يكون مرتبطا ب VNet المحلل. تعمل روابط القواعد بشكل مستقل عن نظير VNet.
طريقة الاختيار
استخدم شجرة القرار التالية لاختيار مكونات DNS المناسبة لبيئتك.
شجرة القرار
هل تستخدم نقاط النهاية الخاصة؟
- نعم، → نشر مناطق Private DNS بأسماء المناطق المناسبة
privatelink.*. ربط المناطق ب VNets التي تحتاج إلى حل عناوين نقاط النهاية الخاصة.
- نعم، → نشر مناطق Private DNS بأسماء المناطق المناسبة
هل تحتاج الأنظمة المحلية إلى حل أسماء Azure الخاصة؟
- نعم، → نشر DNS Private Resolver مع نقطة نهاية واردة. قم بتكوين خوادم DNS المحلية مع محاولات توجيه شرطية تشير إلى عنوان IP لنقطة النهاية الواردة.
هل يحتاج Azure Workloads إلى حل أسماء الموقع؟
- نعم، → نشر DNS Private Resolver مع نقطة نهاية صادرة. أنشئ مجموعات قواعد إعادة توجيه للاحق النطاق المحلي (على سبيل المثال،
corp.contoso.com).
- نعم، → نشر DNS Private Resolver مع نقطة نهاية صادرة. أنشئ مجموعات قواعد إعادة توجيه للاحق النطاق المحلي (على سبيل المثال،
هل تقوم بنشر Azure Firewall وتحتاج إلى تصفية FQDN في قواعد الشبكة؟
- نعم، → تفعيل وكيل DNS الخاص بجدار الحماية. قم بتكوين الأجهزة الافتراضية المزدوجة لاستخدام عنوان IP الخاص بجدار الحماية كخادم DNS الخاص بها.
هل تريد حظر استعلامات DNS إلى النطاقات الخبيثة المعروفة؟
- نعم، → تفعيل سياسة أمان DNS مع تغذية استخبارات التهديدات Microsoft على شبكات VNes المستهدفة.
الأنماط الشائعة
| النمط | المكونات | حالة الاستخدام |
|---|---|---|
| حل نقطة النهاية الخاصة فقط | مناطق Private DNS + روابط VNet | أحمال عمل سحابية فقط تصل إلى خدمات PaaS عبر نقاط نهاية خاصة. لا يوجد اتصال هجين. |
| الدقة ثنائية الاتجاه الهجين | مناطق Private DNS + محلل DNS خاص (وارد + خارج) | يقوم On-premises بحل الأسماء الخاصة في Azure؛ Azure resolve Active Directory محلي names. |
| DNS مركزي لمركز ال | DNS Private Resolver في مركز VNet + مجموعات قواعد إعادة التوجيه المرتبطة بالأذرع | طوبولوجيا المحور حيث تمر جميع حلول DNS عبر المركز لتسجيل وتحكم مركزي. |
| DNS الوسيط بجدار الحماية | Azure Firewall DNS proxy + مناطق Private DNS | بيئات تستخدم جدار الحماية لتصفية FQDN. يعترض جدار الحماية نظام DNS، مما يتيح دقة متسقة لقواعد الشبكة في FQDN-to-IP. |
| مكدس الأمان الكامل | جميع الخيارات السابقة، بالإضافة إلى سياسة أمان DNS | بيئات المؤسسات التي تتطلب دقة هجينة، وتصفية FQDN، وحماية التهديدات في طبقة DNS. |
أمثلة على مناطق DNS الخاصة بنقطة النهاية
الجدول التالي يسرد خدمات Azure الشائعة وأسماء مناطق Private DNS المطلوبة لديها.
| خدمة Azure | اسم منطقة Private DNS |
|---|---|
| مساحة تخزين Azure Blob | privatelink.blob.core.windows.net |
| قاعدة بيانات Azure SQL | privatelink.database.windows.net |
| Azure Key Vault | privatelink.vaultcore.azure.net |
| ملفات Azure | privatelink.file.core.windows.net |
| Azure Container Registry | privatelink.azurecr.io |
| Azure Cosmos DB (SQL API) | privatelink.documents.azure.com |
ملحوظة
للحصول على القائمة الكاملة لأسماء مناطق Private DNS لجميع خدمات Azure، انظر إعدادات DNS الخاصة بنقطة النهاية في Azure.
المتطلبات المسبقه
قبل تنفيذ أمان DNS وحل الأسماء الخاصة، تأكد من أنك تملك:
- شبكة افتراضية: جميع ميزات DNS تعمل داخل أو عبر الشبكات الافتراضية. انظر الشبكات الافتراضية والشبكات الفرعية للإرشادات الأساسية. (F1)
- الاتصال الشبكي للسيناريوهات الهجينة: تتطلب نقاط النهاية الواردة في DNS Private Resolver إمكانية الوصول إلى الشبكة من الموقع المحلي (ExpressRoute أو VPN) إلى VNet الخاص بالمحلول.
-
شبكات فرعية مخصصة ل DNS Private Resolver: كل نقطة نهاية (الواردة والخارجة) تتطلب شبكتها الفرعية الخاصة المفوضة إلى
Microsoft.Network/dnsResolvers. خطط على الأقل /28 لكل شبكة فرعية من نقطة النهاية. -
نقاط النهاية الخاصة المنتشرة (إذا استخدمت مناطق الربط الخاص): مناطق Private DNS للأسماء
privatelink.*توفر قيمة فقط عندما توجد نقاط نهاية خاصة. راجع الوصول الخاص بنظام PaaS مع نقاط النهاية الخاصة للحصول على إرشادات النشر. (C5) - Azure Firewall المنشور (إذا كان يستخدم وكيل DNS): ميزة بروكسي DNS تتطلب مثيل Azure Firewall موجود. راجع Azure Firewall وفحص حركة المرور. (الموسم 1)
- الأصوات: دور المساهم في منطقة DNS لإدارة مناطق Private DNS. مساهم الشبكة لنشر DNS Private Resolver.
اعتبارات الأمان
يقدم DNS متجهات هجوم محددة تتطلب ضوابط مخصصة. تغطي الأقسام التالية مخاطر التسرب، والحجب القائم على استخبارات التهديدات، وسلوك بروكسي DNS الجدار الناري، وقيود DNSSEC.
مخاطر تسرب DNS
يقوم نفق DNS بترميز البيانات في استعلامات DNS لاستخراج المعلومات عبر بروتوكول غير مقيد بخلاف ذلك. نظرا لأن معظم الشبكات تسمح بنظام DNS الصادر (UDP/TCP 53)، يستخدم المهاجمون DNS كقناة سرية. الحد من هذا الخطر من خلال:
- تفعيل بروكسي DNS الخاص ب Azure Firewall وتوجيه جميع حركة مرور DNS عبر جدار الحماية. جدار الحماية يسجل جميع استفسارات DNS، مما يجعل الحفر قابلا للكشف من خلال التحليلات.
- تطبيق سياسة أمان DNS على حجب حل النطاقات المرتبطة بأدوات الخروج المعروفة وبنية القيادة والسيطرة.
- مراقبة أنماط استعلامات DNS في Azure Monitor للبحث عن شذوذات مثل تسميات النطاق الفرعي الطويلة بشكل غير معتاد، أو حجم الاستعلامات العالي لنطاق واحد، أو الاستعلامات على النطاقات المسجلة حديثا.
نهج أمان DNS
سياسة أمان DNS مع Microsoft Threat Intelligence تمنع حل DNS للنطاقات الخبيثة المعروفة على مستوى VNet. عندما يحاول عبء العمل حل نطاق تم الإشارة إليه من قبل مركز استجابة خبراء الأمان من Microsoft (MSRC)، تقوم السياسة بحظر الحل قبل حدوث أي اتصال شبكي. يعمل هذا التحكم بشكل مستقل عن Azure Firewall ولا يتطلب تغييرات في تكوينات الحمل الفردي.
الخصائص الرئيسية:
- يستخدم تغذية Microsoft Threat Intelligence المستمدة من MSRC.
- يعمل عند طبقة حل DNS: يمنع الاستعلام، وليس حركة المرور.
- التطبيق حسب VNet: تفعيل على جميع VNet التي تحتوي على أحمال عمل تصل إلى الإنترنت.
- على عكس تصفية FQDN بجدار الحماية: سياسة أمان DNS تحظر النطاقات الخبيثة عالميا دون الحاجة إلى نشر جدار ناري.
وكيل DNS الجدار الناري وتصفية FQDN
يتطلب بروتوكول Azure Firewall DNS للتصفية المعتمدة على FQDN في قواعد الشبكة. بدون وكيل DNS، قد تحل طلبات DNS من أجهزة العميل الافتراضية في أوقات مختلفة عن حل جدار الحماية، مما يسبب عدم اتساق في تعيين IP إلى FQDN وعدم تطابق في القواعد.
عند تفعيل وكيل DNS:
- قم بتكوين الأجهزة الافتراضية المزدوجة لاستخدام عنوان IP الخاص بجدار الحماية كخادم DNS الخاص بها.
- يقوم جدار الحماية بحل الاستعلامات نيابة عن العملاء ويخزن النتائج (ذاكرة مؤقتة إيجابية حتى ساعة واحدة، وذاكرة تخزين مؤقت سلبية حتى 30 دقيقة).
- FQDN -to-IP تعطي تحديثات كل 15 ثانية. يقوم جدار الحماية بإزالة الإدخالات القديمة بعد 15 دقيقة.
- تستخدم قواعد التطبيق (L7) إشارة اسم الخادم (SNI) لمطابقة FQDN ولا تتطلب وكيل DNS. تتطلب قواعد الشبكة (L4) بروكسي DNS لحل FQDN.
- يدعم تصفية FQDN في قواعد الشبكة مطابقات النطاق الدقيقة فقط. أنماط البطاقات البرية غير مدعومة في شبكات FQDN ذات قواعد الشبكة. استخدم قواعد التطبيق لمطابقة FQDN غير المشروعة.
ملحوظة
إذا أصبحت جميع خوادم DNS المعدة في البداية غير متاحة، فلن يعود وكيل Azure Firewall DNS إلى حل بديل. يفشل حل DNS حتى يتعافى خادم واحد على الأقل في المراحل الصاعدة. خطط لتكرار خادم DNS في تكوين الرفع الخاص بك.
إنذار
إذا قمت بتفعيل بروكسي DNS لكن لم تقم بتكوين أجهزة العميل الافتراضية لاستخدام جدار الحماية كخادم DNS لديهم، فإن قواعد الشبكة المبنية على FQDN لن تعمل بشكل صحيح. قد يقوم العملاء وجدار الحماية بحل عناوين IP مختلفة لنفس FQDN، مما يسبب انخفاضات غير متوقعة في حركة المرور.
قيود DNSSEC
Azure DNS لا يدعم حاليا التحقق من صحة DNSSEC للمناطق الخاصة. تدعم المناطق العامة المستضافة في Azure DNS توقيع DNSSEC للاستجابات الموثوقة، لكن الحل التكراري داخل شبكات Azure الافتراضية لا يؤدي التحقق من صحة DNSSEC. إذا كانت متطلبات الأمان لديك تتطلب التحقق من صحة DNSSEC، قم بتقييم استخدام محلل DNS مخصص يدعم التحقق أو تنفيذ التحقق من طبقة التطبيق.
اعتبارات التصميم
تركيز تصميم DNS على الرفع والانتقال
- تكوين إعادة توجيه DNS ثنائية الاتجاه بين خوادم DNS المحلية وAzure DNS Private Resolver.
- استخدم المحولات الشرطية بحيث تحل الاستعلامات المحلية للأسماء المستضافة في Azure في Azure، واستعلامات Azure للأسماء المحلية تحل عبر بنية DNS الحالية لديك.
- إنشاء مناطق Private DNS لكل خدمة Azure تستخدمها أحمال العمل المنتقلة، خاصة الخدمات المدعومة من نقطة النهاية الخاصة.
- حافظ على سلوك DNS للتطبيق أثناء الترحيل باستخدام سجلات الأسماء المستمرة أو خرائط CNAME بدلا من تغيير إعدادات حل العميل.
تحديث تركيز تصميم DNS
- مركزة حل DNS في المركز باستخدام Azure DNS Private Resolver مع مجموعات قواعد إعادة توجيه مشتركة عبر الشبكات الافتراضية السريعة.
- ربط مناطق Private DNS لكل خدمة PaaS مدعومة بنقطة النهاية الخاصة بحيث تحل أحباء العمل المعاد تدويرها تلقائيا أسماء الروابط الخاصة.
- قم بتمكين بروكسي Azure Firewall DNS بحيث تستخدم قواعد الشبكة المعتمدة على FQDN وحل DNS لأعباء العمل مسار حل متسق ومخزن مؤقتا.
- استخدم التسجيل التلقائي ونظام Azure RBAC على مناطق Private DNS لتقليل إدارة السجلات اليدوية أثناء اعتمادك للبنية التحتية ككود.
تركيز تصميم DNS عبر السحابة
- استخدم Azure DNS Private Resolver كنقطة تحكم في التوجيه لحل الأسماء عبر السحابة.
- قم بتكوين التوجيه الشرطي بين Azure الخاص DNS، وAWS Route 53 Resolver، وGoogle Cloud DNS لكل مساحة اسم خاصة يجب أن تحل عبر البيئات.
- خطط لتحويل DNS على مراحل: خفض قيم TTL، التحقق من مسارات التوجيه، تغيير سجلات CNAME أو A، ومراقبة زمن استجابة الاستعلام وسلوك الكاش.
- طبق DNSSEC على المناطق الموثوقة التي تدعمه المنصات المتصلة، وقم بتوثيق حيث لا تتحقق مسارات الحلول الخاصة من صحة DNSSEC.
المقالات ذات الصلة
- الوصول الخاص PaaS مع نقاط النهاية الخاصة: نشر نقاط النهاية الخاصة وتكوين مناطق DNS الخاصة بالروابط الخاصة.
- Azure Firewall وفحص حركة المرور: تكوين بروكسي DNS في Firewall وتصفية FQDN.
- الشبكات الافتراضية والشبكات الفرعية: أساسيات VNet بما في ذلك تخطيط الشبكات الفرعية لنقاط نهاية محلل DNS.
- طوبولوجيا الشبكة ذات المحور الوسيط: حل مركزي لنظام DNS في البنى ذات الأذرع المركزية.
- مراحل التصميم بنظرة سريعة: ملخص قائم على المراحل عبر قرارات التخطيط والاتصال والأمن والعمليات.
التعرف على المزيد
- نظرة عامة حول Azure DNS
- نظرة عامة على Azure Private DNS المناطق
- Azure DNS Private Resolver overview
- تكوين DNS الخاص لنقطة النهاية
- إعدادات DNS لجدار حماية Azure Firewall
- تحليل الاسم للموارد في الشبكات الظاهرية لـ Azure
الخطوات التالية
نصيحة
تستكشف بمفردك؟ عد إلى الناظر العام للعثور على مقالك التالي حسب القدرات.
الخطوة التالية في رحلتك في الرفع والوردية:
التحكم في حركة الإنترنت الصادرة: مركزة جميع الاتصالات الصادرة عبر Azure Firewall وإيقاف الوصول الصادر الافتراضي.
الخطوة التالية في رحلتك التحديثية:
قم بإعداد مراقبة الإنتاج: تفعيل Network Watcher و Network Performance Monitor للجاهزية للإنتاج من اليوم الأول.
التالي في رحلتك عبر السحابة:
تأمين مسار النقل عبر السحابة: قم بنشر Azure Firewall في مركزك الافتراضي الآمن لفحص جميع حركة المرور عبر السحابة والفروع والمرتبطة بالإنترنت.