استخدام Azure Firewall للمساعدة في حماية نظام مجموعة Azure Kubernetes Service (AKS)

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

يصف هذا الدليل كيفية إنشاء نظام مجموعة AKS خاص في مخطط شبكة محورية باستخدام Terraform وAzure DevOps. يتم استخدام Azure Firewall لفحص نسبة استخدام الشبكة من وإلى نظام مجموعة Azure Kubernetes Service (AKS). تتم استضافة نظام مجموعة بواسطة شبكة ظاهرية واحدة أو أكثر من الشبكات الظاهرية المحورية.

البنية

قم بتنزيل ملف Visio لهذه البنية.

‏‏سير العمل‬

تُستخدم وحدات Terraform النمطية لتوزيع شبكة ظاهرية جديدة بها أربع شبكات فرعية تستضيفها:

نظام مجموعة AKS (AksSubnet).
جهاز ظاهري Jump-box ونقاط نهاية خاصة (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

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

يتكون نظام مجموعة AKS من المجمعات التالية:

تجمع عقدة النظام الذي يستضيف كبسولات وخدمات النظام المهمة فقط
تجمع عقدة المستخدم الذي يستضيف أحمال عمل المستخدم والنتائج الملموسة

يتم توزيع الجهاز الظاهري في الشبكة الظاهرية التي تستضيف نظام مجموعة AKS. عند توزيع AKS كنظام مجموعة خاصة، يمكن لمسؤولي النظام استخدام هذا الجهاز الظاهري لإدارة نظام المجموعة عبر أداة Kubernetes command-line. يتم تخزين سجلات تشخيص التمهيد للجهاز الظاهري في حساب Azure Storage.

يوفر مضيف Azure Bastion اتصالاً محسناً للأمان SSH بجهاز Jump-box الظاهري عبر SSL. يتم استخدام Azure Container Registry لإنشاء صور وتشكيلات الحاوية وتخزينها وإدارتها (مثل مخططات Helm).

تتضمن البنية جدار حماية Azure الذي يستخدم للتحكم في نسبة استخدام الشبكة الواردة والصادرة عبر قواعد DNAT وقواعد الشبكة وقواعد التطبيق. كما أنه يساعد في حماية أحمال العمل باستخدام التصفية المستندة إلى التحليل الذكي للمخاطر. يتم نشر Azure Firewall و Bastion إلى شبكة ظاهرية مركزية نظيرة مع الشبكة الظاهرية التي تستضيف مجموعة AKS الخاصة. يتم استخدام جدول التوجيه والمسارات المعرفة من قبل المستخدم لتوجيه نسبة استخدام الشبكة الصادرة من مجموعة AKS الخاصة إلى جدار حماية Azure.

إشعار

نوصي بشدة باستخدام Premium SKU الخاص بجدار حماية Azure Firewall لأنه يوفر حماية عالية من التهديدات.

يتم استخدام Key Vault كمخزن سري بواسطة أحمال العمل التي تعمل على AKS لاسترداد المفاتيح والشهادات والأسرار عبر هوية حمل عمل Microsoft Entra أو Secrets Store CSI Driver أو Dapr. يمكّن Azure Private Link أحمال عمل AKS من الوصول إلى خدمات Azure PaaS، مثل Azure Key Vault، عبر نقطة نهاية خاصة في الشبكة الظاهرية.

يشمل الهيكل نقاط النهاية الخاصة ومناطق DNS الخاصة لهذه الخدمات:

حساب Azure Blob Storage
Container Registry
المخزن الرئيسي
خادم API لنظام مجموعة Kubernetes

هناك رابط شبكة ظاهرية بين شبكات "المركز والمحور" الظاهرية التي تستضيف نظام مجموعة AKS ومناطق DNS الخاصة الموضحة سابقاً.

تُستخدم مساحة عمل Log Analytics لتجميع سجلات التشخيص والقياسات من خدمات Azure.

المكونات

إن Azure Firewall عبارة عن خدمة أمان أصلية وجدار حماية ذكية للشبكة على السحابة توفر حماية من التهديدات لأحمال العمل السحابية التي يتم تشغيلها في Azure. تتسم هذه الخدمة بأنها جدار حماية ذي حالة خاصة بالكامل ذي قابلية وصول عالية مضمنة وقابلية توسع سحابة غير مقيدة. يوفر كل من التفتيش المروري بين الشرق والغرب والشمال والجنوب.
إن Container Registryعبارة عن خدمة تسجيل Docker خاصة مُدارة وتستند إلى Docker Registry 2.0 مفتوح المصدر. يمكنك استخدام سجلات حاوية Azure مع بنية تطوير وتوزيع الحاوية الأساسية الحالية أو استخدام Container Registry Tasks لإنشاء صور حاوية في Azure.
تعمل Azure Kubernetes Serviceعلى تبسيط توزيع نظم مجموعات Kubernetes المُدارة في Azure عن طريق إلغاء تحميل الحمل التشغيلي على Azure. كخدمة مستضافة من Kubernetes، يعالج Azure المهام المهمة مثل المراقبة الصحية والصيانة. نظراً لأن برامج Kubernetes الرئيسية تتم إدارتها بواسطة Azure، فأنت تدير فقط عقد العامل وتحافظ عليها.
يخزن Key Vault البيانات السرية ويتحكم في الوصول إليها مثل مفاتيح API وكلمات المرور والشهادات ومفاتيح التشفير مع تحسين الأمان. يتيح لك Key Vault أيضاً توفير شهادات Transport Layer Security/طبقة مآخذ توصيل آمنة (TLS / SSL) وإدارتها وتوزيعها بسهولة، لاستخدامها مع Azure والموارد الداخلية المتصلة.
Azure Bastion هو نظام أساسي مُدار بالكامل كخدمة (PaaS) توفره داخل شبكتك الظاهرية. يوفر Azure Bastion اتصالاً محسناً بـ Remote Desktop Protocol (RDP) وSecure Shell (SSH) بالأجهزة الظاهرية في شبكتك الظاهرية، مباشرةً من مدخل Microsoft Azure عبر TLS.
توفر Azure Virtual Machines موارد حوسبة قابلة لتغيير الحجم عند الطلب تمنحك مرونة المحاكاة الظاهرية.
شبكة Azure الظاهرية هي الركيزة الأساسية لشبكات Azure الخاصة. تمكّن Virtual Network موارد Azure (مثل الأجهزة الظاهرية) من التواصل مع بعضها، والإنترنت، والشبكات الداخلية بأمان محسّن. تشبه Azure Virtual Network شبكة تقليدية محلية، ولكنها تتضمن مزايا بنية Azure الأساسية مثل قابلية التوسع والتوافر والعزل.
تعمل Virtual Network Interfaces على تمكين أجهزة Azure الظاهرية من الاتصال بالإنترنت وAzure والموارد المحلية. يمكنك إضافة العديد من بطاقات واجهة الشبكة إلى جهاز Azure ظاهري واحد، بحيث يمكن أن يكون للأجهزة الظاهرية التابعة أجهزة واجهة الشبكة المخصصة وعناوين IP الخاصة بها.
توفر الأقراص المُدارة من Azure وحدات تخزين على مستوى الكتلة يديرها Azure على أجهزة Azure الظاهرية. تتوفر أقراص Ultra، ومحركات أقراص الحالة الصلبة المتميزة (SSD)، ومحركات SSD القياسية، ومحركات الأقراص الصلبة القياسية (HDD).
إن Blob Storage هو أحد حلول تخزين العناصر للسحابة. تم تحسين تخزين Blob النقطة لتخزين كميات هائلة من البيانات غير المهيكلة.
يمكّنك Private Link من الوصول إلى خدمات Azure PaaS (على سبيل المثال، Blob Storage وKey Vault) عبر نقطة نهاية خاصة في شبكتك الظاهرية. يمكنك أيضاً استخدامه للوصول إلى الخدمات المستضافة في Azure التي تمتلكها أو التي يوفرها أحد شركاء Microsoft.

البدائل

يمكنك استخدام جدار حماية تابع لجهة خارجية من Azure Marketplace بدلاً من Azure Firewall. إذا قمت بذلك، فمن مسؤوليتك تكوين جدار الحماية بشكل صحيح لفحص نسبة استخدام الشبكة الوارد والصادر من نظام مجموعة AKS والسماح بها أو رفضها.

تفاصيل السيناريو

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

يمكنك إنشاء مجموعة AKS خاصة في تخطيط شبكة النظام المحوري باستخدام Terraform وAzure DevOps. يتم استخدام Azure Firewall لفحص نسبة استخدام الشبكة من وإلى نظام مجموعة Azure Kubernetes Service (AKS). تتم استضافة نظام مجموعة بواسطة شبكة ظاهرية واحدة أو أكثر من الشبكات الظاهرية المحورية.

يدعم جدار حماية Azure ثلاث وحدات SKU مختلفة لتلبية مجموعة واسعة من حالات استخدام العملاء وتفضيلاتهم:

يوصى باستخدام Azure Firewall Premium لتأمين التطبيقات الحساسة للغاية، مثل معالجة الدفع. وهو يدعم قدرات متقدمة للحماية من التهديدات مثل البرامج الضارة وفحص TLS.
يوصى باستخدام Azure Firewall Standard للعملاء الذين يبحثون عن جدار حماية الطبقة 3-الطبقة 7 والذين يحتاجون إلى التحجيم التلقائي للتعامل مع فترات ذروة نسبة استخدام الشبكة التي تصل إلى 30 جيجابت في الثانية. وهو يدعم ميزات المؤسسة، مثل التحليل الذكي للمخاطر ووكيل DNS وDNS المخصص وفئات الويب.
يوصى باستخدام Azure Firewall Basic للعملاء الذين لديهم احتياجات إنتاجية أقل من 250 ميغابت في الثانية.

يعرض الجدول التالي ميزات وحدات SKU الثلاثة لجدار حماية Azure. لمزيد من المعلومات، راجع تسعير Azure Firewall.

Screenshot that shows features of the three Azure Firewall SKUs

بشكل افتراضي، تتمتع نظم مجموعات AKS بوصول غير مقيد إلى الإنترنت الصادر. يسمح هذا المستوى من الوصول إلى الشبكة، للعقد والخدمات التي تعمل في نظام مجموعة AKS بالوصول إلى الموارد الخارجية حسب الحاجة. إذا كنت ترغب في تقييد نسبة استخدام الشبكة الصادر، فيجب أن يظل عددٌ محدود من المنافذ والعناوين متاحاً للحفاظ على سلامة مهام صيانة نظام مجموعة. أسهل طريقة لتوفير الأمان لنسبة استخدام الشبكة الصادر من نظام مجموعة Kubernetes مثل AKS هي استخدام جدار حماية برمجي يمكنه التحكم في نسبة استخدام الشبكة الصادر بناءً على أسماء المجال. يمكن لـ Azure Firewall تقييد نسبة استخدام شبكة HTTP وHTTPS الصادر بناءً على اسم المجال المؤهل بالكامل (FQDN) للوجهة. يمكنك أيضاً تكوين جدار الحماية وقواعد الأمان للسماح بهذه المنافذ والعناوين المطلوبة. لمزيد من المعلومات، راجع التحكم في نسبة استخدام الشبكة الصادر لنظام مجموعة العقد في AKS.

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

حالات الاستخدام المحتملة

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

تجنب التوجيه غير المتماثل

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

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

لتوجيه نسبة استخدام الشبكة لأحمال عمل AKS إلى جدار حماية Azure في الشبكة الظاهرية المركزية، تحتاج إلى:

نشاء جدول توجيه وإرفاقه بكل شبكة فرعية تستضيف العقد العاملة في نظام المجموعة الخاص بك.
إنشاء مسار معرف من قبل المستخدم لإعادة توجيه نسبة استخدام الشبكة ل 0.0.0.0/0 CIDR إلى عنوان IP الخاص لجدار حماية Azure. حدد جهاز ظاهري لـ نوع hop التالي.

لمزيد من المعلومات، راجع البرنامج التعليمي: توزيع وتكوين جدار حماية Azure باستخدام مدخل Microsoft Azure.

لمزيد من المعلومات، راجع:

نشر أحمال العمل إلى نظام مجموعة AKS خاص عند استخدام Azure DevOps

إذا كنت تستخدم Azure DevOps، فلاحظ أنه لا يمكنك استخدام عملاء Azure DevOps Microsoft-hosted لتوزيع أحمال العمل الخاصة بك إلى نظام مجموعة AKS الخاصة. ليس لديهم حق الوصول إلى خادم API الخاص به. لتوزيع أحمال العمل على نظام مجموعة AKS الخاصة بك، تحتاج إلى توفير واستخدام عامل Azure DevOps المستضاف ذاتياً في نفس الشبكة الظاهرية مثل نظام مجموعة AKS الخاصة، أو في شبكة ظاهرية متطابقة. في الحالة الأخيرة، تأكد من إنشاء ارتباط شبكة ظاهرية بين منطقة DNS الخاصة لنظام مجموعة AKS في نظام مجموعة موارد العقدة والشبكة الظاهرية التي تستضيف عامل Azure DevOps المستضاف ذاتياً.

يمكنك نشر عامل Windows أو Linux Azure DevOps واحد على جهاز ظاهري، أو يمكنك استخدام مجموعة مقياس الجهاز الظاهري. لمزيد من المعلومات، راجع عوامل Azure Virtual Machine Scale Set. كبديل، يمكنك إعداد عامل مستضاف ذاتياً في Azure Pipelines للتشغيل داخل حاوية Windows Server Core (لمضيفي Windows) أو حاوية Ubuntu (لمضيفي Linux) باستخدام Docker. قم بتوزيعها كـ pod مع نسخة متماثلة واحدة أو عدة نسخ متماثلة في نظام مجموعة AKS الخاصة بك. لمزيد من المعلومات، راجع:

إذا تم تكوين الشبكات الفرعية التي تستضيف تجمعات العقدة لمجموعة AKS الخاصة بك لتوجيه حركة مرور الخروج إلى جدار حماية Azure عبر جدول توجيه ومسار محدد من قبل المستخدم، فتأكد من إنشاء قواعد التطبيق والشبكة المناسبة. تحتاج هذه القواعد إلى السماح للعامل بالوصول إلى المواقع الخارجية لتنزيل وتثبيت أدوات مثل Docker وKubectl وAzure CLI وHelm على الجهاز الظاهري العامل. لمزيد من المعلومات، راجع تشغيل عامل مستضاف ذاتياً في Docker وإنشاء Azure DevOps Pipeline Agent وتوزيعه على AKS.

استخدام Azure Firewall أمام Standard Load Balancer العام

تستخدم تعريفات الموارد في وحدات Terraform النمطية الوسيطة الوصفية دورة الحياة لتخصيص الإجراءات عند تغيير موارد Azure خارج تحكم Terraform. يتم استخدام الوسيطة ignore_changes لإرشاد Terraform لتجاهل التحديثات لخصائص الموارد المحددة، مثل العلامات. يحتوي تعريف مورد Azure Firewall Policy على كتلة دورة حياة لمنع Terraform من تحديث المورد عند إنشاء نظام مجموعة قواعد أو قاعدة واحدة أو تحديثها أو حذفها. وبالمثل، يحتوي Azure Route Table على كتلة دورة حياة لمنع Terraform من تحديث المورد عند إنشاء مسار معرف بواسطة المستخدم أو حذفه أو تحديثه. يتيح لك ذلك إدارة قواعد DNAT والتطبيق والشبكة الخاصة بـ Azure Firewall Policy والمسارات المحددة من قِبَل المستخدم لجدول مسار Azure خارج عنصر تحكم Terraform.

يحتوي النموذج المرتبط بهذه المقالة على تدفق Azure DevOps CD الذي يوضح كيفية توزيع حمل عمل على نظام مجموعة AKS خاصة باستخدام تدفق Azure DevOps الذي يتم تشغيله على عامل مستضاف ذاتياً. يقوم النموذج بتوزيع تطبيق ويب إدارة مشروع Bitnami redmine باستخدام مخطط Helm عام. يوضح هذا الرسم التخطيطي التخطيط الشبكي للعينة:

هذا هو تدفق الرسالة:

يتم إرسال طلب تطبيق الويب المستضاف على AKS إلى عنوان IP عام يتم عرضه بواسطة Azure Firewall عبر تكوين IP عام. يتم تخصيص كل من IP العام وتكوين IP العام لهذا الحمل للعمل.
تقوم قاعدة Azure Firewall DNAT بترجمة عنوان IP العام لـ Azure Firewall والمنفذ إلى عنوان IP العام والمنفذ المستخدم بواسطة حمل العمل في Standard Load Balancer العام Kubernetes لنظام مجموعة AKS في مجموعة موارد العقدة.
ترسل موازنة التحميل الطلب إلى إحدى مجموعات خدمة Kubernetes التي تعمل على إحدى عقد العامل في نظام مجموعة AKS.
يتم إرسال رسالة الرد إلى المتصل الأصلي عبر مسار محدد من قِبَل المستخدم. عنوان IP العام لـ Azure Firewall هو بادئة العنوان، والإنترنت هو نوع hop التالي.
يتم توجيه أي استدعاء صادر بدأه حمل العمل إلى عنوان IP الخاص بجدار حماية Azure بواسطة المسار الافتراضي المعرف من قبل المستخدم. إن 0.0.0.0/0 هي بادئة العنوان، والجهاز الظاهري هو نوع hop التالي.

لمزيد من المعلومات، راجع استخدام Azure Firewall أمام Public Standard Load Balancer لنظام مجموعة AKS.

استخدام Azure Firewall أمام Standard Load Balancer الداخلي

في العينة المرتبطة بهذه المقالة، تتم استضافة تطبيق ASP.NET Core كخدمة بواسطة نظام مجموعة AKS ويواجهه وحدة تحكم إدخال NGINX. يتم عرض وحدة تحكم إدخال NGINX عبر موازنة تحميل داخلية لها عنوان IP خاص في الشبكة الظاهرية التي تستضيف نظام مجموعة AKS. لمزيد من المعلومات، راجع إنشاء وحدة تحكم الإدخال إلى شبكة ظاهرية داخلية في AKS. عند توزيع وحدة تحكم إدخال NGINX، أو خدمة LoadBalancer أو ClusterIP بشكل عام، مع التعليق التوضيحي service.beta.kubernetes.io/azure-load-balancer-internal: "true" في قسم بيانات التعريف، يتم إنشاء موازنة تحميل قياسية داخلية تسمى kubernetes-internal ضمن نظام مجموعة موارد العقدة. لمزيد من المعلومات، راجع استخدام موازنة تحميل داخلية مع AKS. كما هو موضح في الرسم التخطيطي التالي، يتم عرض تطبيق الويب التجريبي بواسطة Azure Firewall عبر عنوان IP عام مخصص ل Azure.

هذا هو تدفق الرسالة:

يتم إرسال طلب لتطبيق ويب اختبار مستضاف من AKS إلى عنوان IP عام يتم عرضه بواسطة جدار حماية Azure عبر تكوين IP عام. يتم تخصيص كل من IP العام وتكوين IP العام لهذا الحمل للعمل.
تقوم قاعدة Azure Firewall DNAT بترجمة IP والمنفذ العام لـ Azure Firewall إلى عنوان IP الخاص والمنفذ المستخدم بواسطة وحدة تحكم إدخال NGINX في Standard Load Balancer الداخلي لنظام مجموعة AKS في مجموعة موارد العقدة.
يتم إرسال الطلب بواسطة موازنة التحميل الداخلية إلى أحد حواجز خدمة Kubernetes التي تعمل على إحدى عقد العامل في نظام مجموعة AKS.
يتم إرسال رسالة الرد إلى المتصل الأصلي عبر مسار محدد من قِبَل المستخدم. إن 0.0.0.0/0 هي بادئة العنوان، والجهاز الظاهري هو نوع hop التالي.
يتم توجيه أي مكالمة صادرة ببدء حمل العمل إلى عنوان IP الخاص للمسار المحدد من قِبَل المستخدم.

لمزيد من المعلومات، راجع استخدام Azure Firewall أمام Standard Load Balancer الداخلي.

الاعتبارات

تنفذ هذه الاعتبارات ركائز Azure Well-Architected Framework، وهو عبارة عن مجموعة من المبادئ التوجيهية التي يمكن استخدامها لتحسين جودة حمل العمل. لمزيد من المعلومات، يرجى مراجعةMicrosoft Azure Well-Architected Framework.

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

الأمان

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

يوفر النظام الأساسي ل Azure حماية محسنة من التهديدات المختلفة، مثل اختراق الشبكة وهجمات رفض الخدمة الموزعة (DDoS). يجب عليك استخدام جدار حماية تطبيق الويب (WAF) لتوفير الحماية لأي تطبيقات وخدمات ويب مستضافة من AKS والتي تعرض نقطة نهاية HTTPS عامة. تحتاج إلى توفير الحماية من التهديدات الشائعة مثل إدخال SQL والبرمجة عبر المواقع ومآثر الويب الأخرى. للقيام بذلك، استخدم قواعد Open Web Application Security Project (OWASP) والقواعد المخصصة. يوفر Azure Web Application Firewall حماية مركزية محسنة لتطبيقات الويب من عمليات الاستغلال والثغرات الأمنية الشائعة. يمكنك توزيع Azure WAF باستخدام Azure Application Gateway وAzure Front Door وAzure Content Delivery Network.

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

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

فيما يلي بعض اعتبارات الأمان الإضافية:

أنشئ نقطة نهاية خاصة لأي خدمة PaaS تستخدمها أحمال عمل AKS، مثل Key Vault وAzure Service Bus وAzure SQL Database. لا يتم عرض نسبة استخدام الشبكة بين التطبيقات وهذه الخدمات على الإنترنت العام. تنتقل نسبة استخدام الشبكة بين الشبكة الظاهرية لمجموعة AKS ومثيل خدمة PaaS عبر نقطة نهاية خاصة إلى شبكة Microsoft الأساسية، ولكن الاتصال لا يمر عبر جدار حماية Azure. توفر هذه الآلية أماناً أفضل وحماية أفضل ضد تسرب البيانات. لمزيد من المعلومات، راجع ما هو Azure Private Link؟.
عند استخدام Application Gateway أمام نظام مجموعة AKS، استخدم Web Application Firewall Policy للمساعدة في حماية أحمال العمل العامة التي يتم تشغيلها على AKS من الهجمات.
استخدم نُهج الشبكة للفصل والمساعدة في تأمين الاتصالات داخل الخدمة من خلال التحكم في المكونات التي يمكنها الاتصال ببعضها. بشكل افتراضي، يمكن لجميع الكبسولات في نظام مجموعة Kubernetes إرسال واستقبال نسبة استخدام الشبكة دون قيود. لتحسين الأمان، يمكنك استخدام نُهج شبكة Azure أو نُهج شبكة Calico لتحديد القواعد التي تتحكم في تدفق نسبة استخدام الشبكة بين الخدمات المصغرة المختلفة. لمزيد من المعلومات، راجع نهج الشبكة.
لا تعرض الاتصال عن بُعد إلى عقد AKS. إنشاء مضيف محمي أو مربع الانتقال في شبكة الإدارة الافتراضية. استخدم مضيف الأساس لتوجيه نسبة استخدام الشبكة إلى نظام مجموعة AKS الخاصة بك.
ضع في اعتبارك استخدام نظام مجموعة AKS الخاصة في بيئة التشغيل الخاصة بك، أو على الأقل الوصول الآمن إلى خادم API، باستخدام نطاقات عناوين IP المصرح بها في AKS. عند استخدام نطاقات عناوين IP المصرح بها في نظام مجموعة عامة، اسمح بجميع عناوين IP للخروج في مجموعة قواعد شبكة Azure Firewall. تستهلك العمليات داخل نظام مجموعة خادم Kubernetes API.
إذا قمت بتمكين وكيل DNS في Azure Firewall، فإن Azure Firewall يمكنه معالجة وإعادة توجيه استعلامات DNS من شبكة ظاهرية واحدة أو أكثر إلى خادم DNS الذي تختاره. هذه الوظيفة ضرورية ومطلوبة لتصفية FQDN الموثوقة في قواعد الشبكة. يمكنك تمكين وكيل DNS في إعدادات Azure Firewall وFirewall Policy. لمعرفة المزيد حول سجلات وكيل DNS، راجع سجل وقياسات Azure Firewall.
عند استخدام Azure Firewall أمام Application Gateway، يمكنك تكوين مورد دخول Kubernetes لكشف أحمال العمل عبر HTTPS، واستخدام نطاق فرعي منفصل وشهادة رقمية لكل مستأجر. تعمل Application Gateway Ingress Controller (AGIC) تلقائياً على تكوين وحدة الاستماع Application Gateway لإنهاء طبقة مآخذ توصيل آمنة (SSL).
يمكنك استخدام Azure Firewall أمام وكيل خدمة مثل وحدة تحكم الإدخال NGINX. توفر وحدة التحكم هذه وكيلاً عكسياً وتوجيهاً لنسبة استخدام الشبكة قابلاً للتكوين وإنهاء TLS لخدمات Kubernetes. يتم استخدام موارد دخول Kubernetes لتكوين قواعد الدخول وطرق خدمات Kubernetes الفردية. باستخدام وحدة تحكم الإدخال وقواعد الإدخال، يمكنك استخدام عنوان IP واحد لتوجيه نسبة استخدام الشبكة إلى خدمات متعددة في نظام مجموعة Kubernetes. يمكنك إنشاء شهادات TLS باستخدام مرجع مصدق معروف. بدلاً من ذلك، يمكنك استخدام Let's Encrypt لإنشاء شهادات TLS تلقائياً باستخدام عنوان IP عام ديناميكي أو عنوان IP عام ثابت. لمزيد من المعلومات، راجع إنشاء وحدة تحكم دخول HTTPS واستخدام شهادات TLS الخاصة بك على AKS.
يعد التنسيق الصارم بين مشغل Azure Firewall وفرق نظام المجموعة وأحمال العمل ضرورياً لتوزيع نظام المجموعة الأولي وبشكل مستمر مع توزيع أحمال العمل واحتياجات نظام المجموعة. هذا صحيح بشكل خاص عند تكوين آليات المصادقة، مثل OAuth 2.0 وOpenID Connect، التي تستخدمها أحمال العمل لمصادقة عملائها.
استخدم الإرشادات التالية للمساعدة في تأمين البيئة الموضحة في هذه المقالة:

التوافر والموثوقية

تضمن الموثوقية أن التطبيق الخاص بك يمكن أن يفي بالالتزامات التي تتعهد بها لعملائك. لمزيد من المعلومات، يرجى مراجعة نظرة عامة على ركيزة الموثوقية.

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

المرونة داخل المنطقة

أثناء التوزيع، يمكنك تكوين Azure Firewall ليشمل مناطق توفر متعددة لزيادة الإتاحة. لمعرفة النسب المئوية لوقت التشغيل، راجع Azure Firewall SLA. يمكنك أيضاً إقران Azure Firewall بمنطقة معينة من أجل التقارب، على الرغم من أن هذا التكوين يؤثر على SLA. لا توجد تكلفة إضافية لجدار حماية يتم توزيعه في منطقة توافر. ومع ذلك، هناك تكاليف إضافية لعمليات نقل البيانات الواردة والصادرة المرتبطة بمناطق التوافر. لمزيد من المعلومات، راجع تفاصيل تسعير النطاق الترددي.
ضع في اعتبارك توزيع مجموعات العقد لنظام مجموعة AKS الخاصة بك عبر جميع مناطق التوافر في منطقة واحدة. استخدم Azure Standard Load Balancer أو Application Gateway أمام تجمعات العقد. يوفر هذا الهيكل مرونة أفضل إذا كان هناك انقطاع واحد لمركز البيانات. يتم توزيع عقد نظام المجموعة عبر مراكز بيانات متعددة، في ثلاث مناطق توافر منفصلة داخل منطقة واحدة.
قم بتمكين التكرار في المنطقة في Container Registry للمرونة داخل المنطقة وقابلية الوصول العالية.
استخدم قيود انتشار الطوبولوجيا لـ pod للتحكم في كيفية انتشار pod عبر نظام مجموعة AKS الخاصة بك بين مجالات الفشل مثل المناطق ومناطق التوافر والعقد.
ضع في اعتبارك استخدام Uptime SLA من أجل نظام مجموعة AKS التي تستضيف أحمال عمل حرجة للمهام. تعد Uptime SLA ميزة اختيارية تتيح اتفاقية مستوى خدمة أعلى مدعومة مالياً لنظام مجموعة. يضمن Uptime SLA توافراً عالياً لنقطة نهاية خادم Kubernetes API لنظم المجموعات التي تستخدم مناطق التوافر. يمكنك أيضاً استخدامه لنظم المجموعات التي لا تستخدم مناطق التوافر، لكن SLA أقل. للحصول على تفاصيل SLA، راجع Uptime SLA. تستخدم اتفاقية مستوى الخدمة نُسخ متماثلة للعقدة الرئيسية عبر مجالات التحديث والأخطاء لضمان تلبية متطلبات اتفاقية مستوى الخدمة.

الإصلاح بعد كارثة واستمرارية الأعمال

ضع في اعتبارك توزيع الحل الخاص بك إلى منطقتين من مناطق Azure المقترنة على الأقل داخل منطقة جغرافية. استخدم موازنة تحميل عامة، مثل Azure Traffic Manager أو Azure Front Door، مع طريقة توجيه نشطة/نشطة أو نشطة/خاملة، لضمان استمرارية الأعمال والإصلاح بعد كارثة (DR).
تعد Azure Firewall خدمة إقليمية. إذا قمت بنشر الحل الخاص بك عبر منطقتين أو أكثر، فأنت بحاجة إلى إنشاء جدار حماية Azure في كل منطقة. يمكنك إنشاء Azure Firewall Policy عالمي لتضمين القواعد التي تفرضها المؤسسة والتي تنطبق على جميع المحاور الإقليمية. يمكنك استخدام هذا النهج كنهج أصل لنُهج Azure الإقليمية. النُهج التي تم إنشاؤها باستخدام نُهج رئيسية غير فارغة ترث جميع مجموعات القواعد من النهج الرئيسي. دائماً ما يتم إعطاء الأولوية لمجموعات قواعد الشبكة الموروثة من نهج رئيسي أعلى مجموعات قواعد الشبكة التي تم تحديدها كجزء من نهج جديد. ينطبق نفس المنطق على مجموعات قواعد التطبيق. ومع ذلك، تتم معالجة مجموعات قواعد الشبكة دائماً قبل مجموعات قواعد التطبيق، بغض النظر عن الوراثة. لمزيد من المعلومات حول نُهج Standard وPremium، راجع نظرة عامة على نهج Azure Firewall Manager.
تأكد من كتابة أي عملية تجاوز فشل إقليمية في بيئة ضمان الجودة وتوثيقها واختبارها بشكل دوري. يساعد القيام بذلك على تجنب المشكلات غير المتوقعة إذا تأثرت إحدى الخدمات الأساسية بانقطاع التيار في المنطقة الأساسية. تتحقق هذه الاختبارات أيضاً مما إذا كان نهج الإصلاح بعد كارثة يفي بأهداف RPO/RTO، جنباً إلى جنب مع العمليات اليدوية في نهاية المطاف والتدخلات اللازمة لتجاوز الفشل.
تأكد من اختبار إجراءات إعادة الفشل للتحقق من أنها تعمل على النحو المتوقع.
قم بتخزين صور الحاوية في Container Registry. قم بعمل نسخ جغرافي للسجل إلى كل منطقة AKS. لمزيد من المعلومات، راجع النسخ المتماثل الجغرافي في سجل حاوية Azure .
إذا أمكن، يجب تجنُّب تخزين حالة الخدمة في الحاوية. بدلاً من ذلك، استخدم Azure PaaS الذي يدعم النسخ المتماثل متعدد المناطق.
إذا كنت تستخدم Azure Storage، فقم بإعداد واختبار عملية لترحيل مساحة التخزين الخاصة بك من المنطقة الأساسية إلى منطقة النسخ الاحتياطي.

التميز التشغيلي

يغطي التميز التشغيلي عمليات التشغيل التي تحافظ على تشغيل التطبيق في الإنتاج. لمزيد من المعلومات، يرجى مراجعةنظرة عامة على ركيزة التميز التشغيلي.

DevOps

قم بتوزيع أحمال العمل على AKS باستخدام مخطط Helm في تكامل مستمر وتدفق للتسليم المستمر (CI/CD). استخدم نظام DevOps مثل GitHub Actions أو Azure DevOps. لمزيد من المعلومات، راجع الإنشاء والتوزيع في Azure Kubernetes Service.
لاختبار تطبيق ما بشكل صحيح قبل إتاحته للمستخدمين، استخدم اختبار A/B وعمليات التوزيع الكاناري في إدارة دورة حياة التطبيق. يوجد العديد من الأساليب التي يمكنك استخدامها لتقسيم نسبة استخدام الشبكة عبر إصدارات مختلفة من نفس الخدمة. كبديل، يمكنك استخدام إمكانيات تقسيم نسبة استخدام الشبكة التي يوفرها تنفيذ شبكة الخدمة. لمزيد من المعلومات، راجع Linkerd Traffic Split وIstio Traffic Management.
استخدم Azure Container Registry أو سجل حاوية آخر (مثل Docker Hub)، لتخزين صور Docker الخاصة التي تم توزيعها في نظام المجموعة. يمكن ل AKS المصادقة باستخدام Azure Container Registry باستخدام هوية Microsoft Entra الخاصة به.
اختبر الدخول والخروج لأحمال العمل في بيئة منفصلة لما قبل التشغيل التي تعكس هيكل الشبكة وقواعد جدار الحماية لبيئة التشغيل الخاصة بك. ستساعدك إستراتيجية الطرح المرحلي على اكتشاف أي مشاكل في الشبكة أو الأمان قبل إطلاق ميزة جديدة أو قاعدة شبكة في الإنتاج.

مراقبة‬

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

لا تقتصر اعتبارات المراقبة التالية على الشركات المتعددة في AKS، لكننا نعتقد أنها متطلبات أساسية لهذا الحل.

استخدم رؤى الحاوية لمراقبة الحالة الصحية لنظام مجموعة AKS وأحمال العمل.
هيئ جميع خدمات PaaS (مثل Container Registry وKey Vault) لتجميع سجلات وقياسات التشخيص.

تحسين التكلفة

تعتمد تكلفة البنية الناتجة على تفاصيل التكوين التالية:

مستويات الخدمة
قابلية التوسع (عدد المثيلات التي يتم تخصيصها ديناميكياً بواسطة الخدمات لدعم طلب معين)
نصوص الأتمتة
مستوى الإصلاح بعد كارثة

بعد تقييم هذه التفاصيل للتكوين، استخدم حاسبة أسعار Azure لتقدير التكاليف. لمزيد من خيارات تحسين الأسعار، راجع كيانات تحسين التكلفة في Microsoft Azure Well-Architected Framework.

نشر هذا السيناريو

شفرة المصدر لهذا السيناريو متاحة في GitHub. هذا الحل مفتوح المصدر ومُقدَّم مع ترخيص MIT.

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

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

قم بتخزين ملف حالة Terraform في حساب تخزين Azure. لمزيد من المعلومات حول استخدام حساب التخزين لتخزين حالة Terraform البعيدة، وقفل الحالة، والتشفير في حالة عدم التشغيل، راجع حالة تخزين Terraform في Azure Storage.
إنشاء مشروع Azure DevOps. لمزيد من المعلومات، راجع إنشاء مشروع في Azure DevOps.
أنشئ اتصال خدمة Azure DevOps لاشتراكك في Azure. يمكنك استخدام مصادقة الخدمة الأساسية (SPA) أو هوية خدمة مُدارة من Azure عند إنشاء اتصال الخدمة. في كلتا الحالتين، تأكد من تعيين مدير الخدمة أو الهوية المُدارة التي يستخدمها Azure DevOps للاتصال باشتراك Azure الخاص بك، دور المالك في الاشتراك بالكامل.

التوزيع في Azure

اجعل معلومات اشتراكك في Azure في متناول يديك.

استنساخ مستودع workbench GitHub:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

اتبع الإرشادات الواردة في ملف README.md.

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

باولو سالفاتوري | مهندس الخدمة الرئيسي

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

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

راجع التوصيات وأفضل الممارسات لـ AKS في Microsoft Azure Well-Architected Framework:

استخدام Azure Firewall للمساعدة في حماية نظام مجموعة Azure Kubernetes Service (AKS)