هندسة نظام مجموعة AKS التنظيمي لـ PCI-DSS 3.2.1 (الجزء 2 من 9)

توضح هذه المقالة الهندسة المرجعية لنظام مجموعة Azure Kubernetes Service (AKS) الذي يقوم بتشغيل حمل عمل وفقاً لـ Payment Card Industry Data Security Standard (PCI-DSS 3.2.1). تركز هذه الهندسة على البنية الأساسية وليس على حمل عمل PCI-DSS 3.2.1.

هذا المقال جزء من سلسلة. اقرأ المقدمة.

التوصيات والأمثلة مستخرجة من هذا التطبيق المرجعي المصاحب:

GitHub: يوضح نظام المجموعة الأساسي لخدمة Azure Kubernetes (AKS) لأحمال العمل المنظمة البنية الأساسية المنظمة. يشمل هذا التطبيق تطبيقًا للخدمات المصغّرة. تم تضمينه لمساعدتك على تجربة البنية الأساسية وتوضيح عناصر التحكم في الشبكة والأمان. لا يمثل التطبيق أو ينفذ حمل عمل PCI DSS فعلياً.

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

تستند هندسة الشبكات هذه إلى مخطط مركز محوري. تحتوي الشبكة الظاهرية المركزية على جدار الحماية للتحكم في نسبة استخدام الشبكة الخارجة، وحركة مرور البوابة من الشبكات المحلية، وشبكة ثالثة للوصول إلى نظام مجموعة SRE (مهندس موثوقية الموقع). توجد شبكتان ظاهريتان محوريتان. يحتوي أحد المحاور على نظام مجموعة AKS الذي هو مكون لبيئة حامل البطاقة (CDE)، ويستضيف حمل عمل PCI DSS. في حين ينشئ المحور الآخر صوراً للجهاز الظاهري المستخدم لوصول SRE المتحكم به إلى البيئة.

المكونات

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

Azure Firewall

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

Azure Bastion

وفرت الهندسة الأساسية شبكة فرعية لـ Azure Bastion، ولكنها لم توفر المورد. تضيف هذه البنية Azure Bastion في الشبكة الفرعية وتوفر وصولا آمنا إلى مربع الانتقال.

Azure Image Builder

يتم توفيرها في شبكة ظاهرية منفصلة، وتنشئ صور VM مع الأمان والتكوين الأساسيين. في هذه الهندسة، يكون إنشاء صور آمنة للعُقد باستخدام أدوات الإدارة مخصصاً مثل Azure CLI وkubectl وFlux CLI المثبت مسبقاً.

Azure Virtual Machine Scale Sets لمثيلات جهاز الانتقال السريع

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

Azure Application Gateway مع Web Application Firewall (WAF) المتكامل

موزانة تحميل Azure Application Gateway في Layer 7. يؤمّن WAF نسبة استخدام الشبكة الواردة من الهجمات الشائعة الموجّهة إلى نسبة استخدام الشبكة على الويب. يحتوي المثيل على تكوين IP عام للواجهة الأمامية التي تتلقى طلبات المستخدم.

خدمة Azure Kubernetes (AKS)

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

مهام ACR

توفر طريقة آلية لبناء صور الحاوية والحفاظ عليها.

Azure Key Vault

يخزن ويدير البيانات السرية اللازمة لعمليات نظام المجموعة، مثل الشهادات ومفاتيح التشفير.

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

فيما يلي بعض التغييرات المهمة من الهندسة الأساسية:

تجزئة مجموعات العُقد

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

يتطلب PCI-DSS 3.2.1 عزل حمل عمل PCI عن أحمال العمل الأخرى من حيث العمليات والاتصال.

• داخل النطاق: حمل عمل PCI والبيئة الموجود فيها والعمليات.

• خارج النطاق: أحمال العمل الأخرى التي قد تشارك الخدمات، ولكنها معزولة عن المكونات داخل النطاق.

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

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

جهاز التحكم في الدخول

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

خادم Kubernetes API الخاص

قامت الهندسة الأساسية بتوزيع نظام مجموعة AKS في الوضع العام. هذا يعني أن جميع الاتصالات التي تمم باستخدام خادم Kubernetes API المُدار بواسطة AKS عبر الإنترنت العام. هذا غير مقبول في هذه البنية لأن PCI-DSS 3.2.1 يحظر التعرض العام لأي من مكونات النظام. في هذه الهندسة التنظيمية، يتم توزيع نظام المجموعة كنظام مجموعة خاص. تقتصر نسبة استخدام الشبكة إلى خادم Kubernetes AP على شبكتك الخاصة. يتم الكشف عن خادم API من خلال نقطة نهاية خاصة في شبكة نظام المجموعة. يتم تعزيز الأمان بشكل أكبر باستخدام مجموعات أمان الشبكة والميزات المضمّنة الأخرى. وهذا موضَّح في تكوين الشبكة.

أمان الجراب

عند وصف احتياجات أمان حمل العمل، استخدم إعدادات securityContext ذات الصلة للحاويات. يتضمن ذلك الإعدادات الأساسية مثل fsGroup،runAsUser / runAsGroup، وتعيين allowPrivilegeEscalation على false (ما لم يكن مطلوباً). تأكد من تحديد إمكانات Linux وإزالتها وتحديد خيارات SELinux في seLinuxOptions.

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

تكوين شبكة الاتصال

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

توفر مجموعة من خدمات وميزات Azure المختلفة وبُنى Kubernetes الأصلية المستوى المطلوب من التحكم. فيما يلي بعض الخيارات المستخدمة في هذه الهندسة.

أمان الشبكة الفرعية من خلال مجموعات أمان الشبكة (NSG)

يوجد العديد من مجموعات أمان الشبكة التي تتحكم في التدفق داخل نظام المجموعة وخارجه. إليك بعض الأمثلة:

• توضع مجموعات عُقد نظام المجموعة في شبكات فرعية مخصصة. لكل شبكة فرعية، توجد مجموعات أمان شبكة (NSG) تحظر أي وصول SSH إلى الأجهزة الظاهرية للعُقد ويسمح بنسبة استخدام الشبكة من الشبكة الظاهرية. تقتصر نسبة استخدام الشبكة من مجموعات العُقد على الشبكة الظاهرية.

• يقاطع Azure Application Gateway جميع نسب استخدام الشبكة الواردة من الإنترنت. على سبيل المثال، تتأكد قواعد مجموعات أمان الشبكة مما يلي:

  • مسموح فقط بنسبة استخدام شبكة HTTPS.
  • يسمح بنسبة استخدام الشبكة من وحدة تحكم Azure باستخدام علامات الخدمة. لمزيد من المعلومات، راجع السماح بالوصول إلى عدد قليل من عناوين IP المصدر.

• في الشبكات الفرعية حيث يوجد وكلاء Azure Container Registry، تسمح مجموعات أمان الشبكة (NSG) بنسبة استخدام الشبكة الصادرة الضرورية فقط. على سبيل المثال، يسمح بحركة المرور إلى Azure Key Vault ومعرف Microsoft Entra وAzure Monitor والخدمات الأخرى التي يحتاج سجل الحاوية إلى التحدث إليها.

• كل من الشبكة الفرعية وجهاز الانتقال السريع مخصص لعمليات الإدارة. تسمح قاعدة NSG على الشبكة الفرعية لمربع الانتقال فقط بالوصول إلى SSH من Azure Bastion في المركز، والاتصالات الصادرة المحدودة. لا تمتلك أجهزة الانتقال السريع وصول عام إلى الإنترنت، ويتم التحكم بها في كل من NSG للشبكة الفرعية وAzure Firewall.

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

أمان بين الوحدات مع نُهج الشبكة

تحاول هذه الهندسة تنفيذ مبادئ "الثقة المعدومة" لـ Microsoft قدر الإمكان.

يتم توضيح أمثلة شبكات الثقة الصفرية كمفهوم في التنفيذ، داخل a0005-i مساحات الأسماء التي يوفرها المستخدم.a0005-o يجب أن يكون لكل مساحة اسم حمل عمل نهج شبكة مقيدة مطبقة. ستعتمد تعريفات النُهج على الوحدات التي يتم تشغيلها في مساحات الأسماء هذه. تأكد من محاسبتك على الجاهزية والحيوية وفحوصات بدء التشغيل، واسمح بالمقاييس التي جمعها عامل Log Analytics. ضع في اعتبارك التوحيد على المنافذ عبر أحمال العمل بحيث يمكنك توفير NetworkPolicy وAzure Policy متسقين لمنافذ الحاوية المسموح بها.

في بعض الحالات، قد يكون تطبيق ذلك غير عملي للاتصال داخل نظام المجموعة. لا يمكن لجميع مساحات الأسماء التي يوفرها المستخدم استخدام شبكة ثقة معدومة (على سبيل المثال، لا يمكن لـ cluster-baseline-settings استخدام واحدة).

تشفير TLS

توفر الهندسة الأساسية نقل بيانات مشفر بواسطة TLS حتى تصبح وحدة التحكم بالدخول في نظام المجموعة، والاتصال بين الوحدة والوحدة في أمان. في هذه الهندسة، يمتد TLS ليشمل نقل البيانات بين الوحدات، مع التحقق من الصحة باستخدام Certificate Authority (CA). توفر إحدى شبكات الخدمة TLS، وهي تفرض اتصالات mTLS والتحقق قبل السماح بالاتصال.

يستخدم التطبيق mTLS. يمكن تنفيذ دعم mTLS باستخدام شبكة خدمة أو بدونها. إذا كنت تستخدم شبكة، فتأكد من أنها متوافقة مع مصدر الشهادة الذي تختاره. يستخدم هذا التطبيق Open Service Mesh.

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

قيود شبكة Azure Key Vault

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

لا يدعم Azure Application Gateway تزويد شهادات TLS لمستمع HTTP من مثيلات Key Vault التي يتم كشفها باستخدام Private Link. لذلك، يوزع التطبيق Key Vault في نموذج مختلط. لا يزال يستخدم Private Link للاتصالات التي تدعمه، ولكنه يسمح أيضا بالوصول العام لتكامل Application Gateway. إذا لم يكن هذا الأسلوب المختلط مناسباً للتوزيع، فانقل عملية إدارة الشهادة إلى Application Gateway. سيفرض ذلك تكلفة إضافية للإدارة، ولكن بعد ذلك سيتم عزل مثيل Key Vault تماماً. للحصول على معلومات، راجع:

• Azure Application Gateway وتكامل Key Vault
• إنشاء بوابة تطبيق وإنهاء TLS باستخدام Azure CLI.

حماية DDoS

إذا كان لديك أي شبكات ظاهرية مع عناوين IP عامة، فمكن Azure DDoS Network Protection. في هذه البنية المرجعية، تحتوي الشبكة الفرعية التي تحتوي على بوابة التطبيق على عنوان IP عام مرفق، لذلك فهي في نطاق حماية DDoS.

تحمي حماية شبكة Azure DDoS البنية الأساسية وعبء العمل من الطلبات الاحتيالية الجماعية. يمكن أن تتسبب هذه الطلبات في انقطاع الخدمة أو إخفاء هجوم متزامن آخر. تأتي Azure DDoS Network Protection بتكلفة كبيرة، وعادة ما يتم استهلاكها عبر العديد من أحمال العمل التي تمتد عبر العديد من عناوين IP. تعاون مع فريق الشبكات لتنسيق التغطية لأحمال العمل الخاصة بك.

إدارة الهوية والوصول

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

قم بالحد من الوصول الدائم، خاصة للحسابات عالية التأثير، مثل تفاعلات SRE/Ops مع نظام مجموعتك. تدعم وحدة التحكم AKS كلا من إدارة الوصول المتميز لمعرف Microsoft Entra (PAM) في الوقت المناسب (JIT) ونهج الوصول المشروط، والتي توفر طبقات إضافية من التحقق من صحة المصادقة المطلوبة للوصول المتميز، استنادا إلى القواعد التي تنشئها.

لمزيد من التفاصيل حول استخدام PowerShell لتكوين الوصول المشروط، راجع New-MgIdentityConditionalAccessPolicy و Get-MgIdentityConditionalAccessPolicy و Remove-MgIdentityConditionalAccessPolicy.

تشفير القرص

عند تصميم تشفير للبيانات الثابتة، ضع في اعتبارك أقراص التخزين، والأجهزة الظاهرية لعُقد عامل AKS، والأجهزة الظاهرية الأخرى، وأي أقراص مؤقتة وأقراص نظام تشغيل.

أقراص التخزين

بشكل افتراضي، يتم تشفير أقراص Azure Storage الثابتة باستخدام مفاتيح تديرها Microsoft. إذا كنت تستخدم أقراص نظام تشغيل دائمة، أو كنت قد أضفت أقراص بيانات، فمن المستحسن استخدام مفاتيح مُدارة من قبل العميل للتحكم في مفاتيح التشفير. قم بالتشفير خارج طبقة التخزين واكتب البيانات المشفرة فقط في وسط التخزين. تأكد دائماً أيضاً من أن المفاتيح ليست بجانب لطبقة التخزين. لمزيد من المعلومات، راجع إنشاء مفتاحك (BYOK) باستخدام أقراص Azure.

ضع في اعتبارك استخدام BYOK لأي أقراص أخرى قد تتفاعل مع نظام المجموعة، مثل أجهزة الانتقال السريع في Azure Bastion-frontend. إذا اخترت BYOK، فسيكون اختيار SKU للأجهزة الظاهرية والتوفر عبر المناطق محدوداً لأن هذه الميزة غير مدعمة على جميع وحدات SKU أو المناطق.

مضيفو الأجهزة الظاهرية

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

يتم توسيع هذه الميزة لتشمل البيانات المخزّنة على مضيف الجهاز الظاهري لعُقد عامل AKS من خلال ميزة Host-Based Encryption. كما هو الحال مع BYOK، قد تقيد هذه الميزة خيارات المناطق ووحدات SKU للجهاز الظاهري.

يمكنك فرض هذه الميزات من خلال Azure Policy.

النسخ الاحتياطية لنظام المجموعة (الحالة والموارد)

إذا كان حمل العمل يتطلب تخزيناً في نظام المجموعة، يمكنك تشغيل النسخ الاحتياطي والاسترداد بقوة وأمان. فكر في الخدمات مثل Azure Backup (لأقراص Azure وملفات Azure)، للنسخ الاحتياطي واسترداد أي PersistentVolumeClaim. توجد مزايا إذا كان نظام النسخ الاحتياطي يدعم موارد Kubernetes الأصلية. يمكنك استكمال أسلوبك الأساسي الذي يسوي نظام المجموعة إلى حالة معروفة، بنظام النسخ الاحتياطي لتقنيات استرداد النظام الهامة. على سبيل المثال، يمكن أن يساعد في الكشف عن الانحراف وفهرسة تغييرات حالة النظام على مر الوقت على مستوى موارد Kubernetes.

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

من المتوقع أن تعمل أنظمة النسخ الاحتياطي داخل نظام المجموعة بامتيازات عالية أثناء تشغيلها. قيّم مخاطر إحضار عامل النسخ الاحتياطي إلى نظام المجموعة لديك ومزاياه. هل تتداخل قدرة العامل مع حل إدارة آخر في نظام المجموعة؟ ما أدنى حد من مجموعة الأدوات التي تحتاج إليها لإنجاز هذه المهمة دون توسيع مساحة الهجوم؟

اعتبارات Azure Policy

لا تحتوي نُهج Azure المطبقة عادة على إعدادات مضبوطة حسب حمل العمل. في التنفيذ، نحن نطبق مبادرة معايير أمان نظام مجموعة Kubernetes المقيدة لأحمال العمل المستندة إلى Linux، وهي واحدة من مبادرات السياسة المضمنة. لا تسمح هذه المبادرة بضبط الإعدادات. فكّر في تصدير هذه المبادرة وتخصيص قيمها لحمل العمل المحدد لديك. يمكنك تضمين جميع نُهج Gatekeeper deny Azure في مبادرة مخصصة واحدة، وجميع نُهج audit Azure في مبادرة أخرى. وبذلك، سيتم تصنيف إجراءات الحظر من نُهج المعلومات فقط.

ضع في اعتبارك تضمين مساحات أسماء kube-system وgatekeeper-system في النُهج الموجودة في نُهج التدقيق لرؤية إضافية. قد يؤدي تضمين مساحات الأسماء هذه في نُهج الرفض إلى فشل نظام المجموعة بسبب تكوين غير مدعم.

يمكنك فرض تشفير البيانات عن طريق تعيين بعض تنبيهات Azure Policy. على سبيل المثال، يمكنك فرض BYOK مع تنبيه يكتشف أنظمة المجموعات التي ليس بها diskEncryptionSetID في مورد نظام المجموعة. يمكن لنهج آخر الكشف عما إذا كان Host-Based Encryption ممكناً على agentPoolProfiles. لا يستخدم التطبيق المرجعي أي أقراص في نظام المجموعة، وقرص نظام التشغيل مؤقت. كل من نموذجي النُهج موجود كتذكير بميزة الأمان. يتم تعيين النهج على audit، وليس block.

إدارة الصور

استخدم الصور الأساسية بدون توزيع لأحمال العمل. في وجود هذه الصور، يتم تصغير مساحة سطح الأمان نتيجة لإزالة الصور التكميلية، مثل shells وpackage managers. وإحدى المزايا هي انخفاض معدلات CVE.

يدعم Azure Container Registry الصور التي تفي بـ Open Container Initiative (OCI) Image Format Specification. يمكن أن يضمن هذا، إلى جانب وحدة التحكم بإذن القبول التي تدعم التحقق من صحة التواقيع، أنك تقوم فقط بتشغيل الصور التي قمت بتوقيعها باستخدام مفاتيحك الخاصة. توجد حلول مفتوحة المصدر مثل SSE Connaisseur أو IBM Portieris التي تتكامل مع هذه العمليات.

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

الوصول التشغيلي لخادم Kubernetes API

يمكنك الحد من الأوامر التي يتم تنفيذها على نظام المجموعة، دون إنشاء عملية تشغيلية تستند بالضرورة إلى أجهزة انتقال سريع. إذا كان لديك نظام أساسي للتشغيل التلقائي لـ IAM-gated IT، فاستخدم الإجراءات المحددة مسبقاً للتحكم في نوع الإجراءات وتدقيقها.

بناء عوامل

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

على الرغم أنه من الشائع استخدام Kubernetes كبنية أساسية مرنة لعميل البناء، لا تقم بتشغيل هذه العملية ضمن حدود وقت تشغيل حمل العمل التنظيمي. لا ينبغي أن يكون لعملاء البناء لديك حق الوصول المباشر إلى نظام المجموعة. على سبيل المثال، يمكنك فقط منح شبكة عملاء البناء حق الوصول إلى Azure Container Registry لدفع صور الحاوية ومخططات helm وما إلى ذلك. بعد ذلك، قم بالتوزيع من خلال GitOps. كممارسة شائعة، يجب ألا يكون لمهام سير عمل الإصدار والبناء حق الوصول المباشر إلى Kubernetes Cluster API (أو العُقد الخاصة به).

عمليات المراقبة

الأنشطة داخل نظام المجموعة

وحدات omsagent الموجودة داخل نظام المجموعة والتي يتم تشغيلها في kube-system هي عامل مجموعة Log Analytics. إنها تجمع بيانات تتبع الاستخدام وتستخرج سجلات الحاوية لـ stdout وstderr، وتجمع مقاييس Prometheus. يمكنك ضبط إعدادات المجموعة الخاصة بها عن طريق تحديث ملف ConfigMap container-azm-ms-agentconfig.yaml. في هذا التطبيق المرجعي، يتم تمكين التسجيل عبر kube-system وجميع أحمال العمل. بشكل افتراضي، يتم استبعاد kube-system من التسجيل. تأكد من ضبط عملية جمع السجلات لتحقيق أهداف التكلفة المتوازنة وفعالية SRE عند مراجعة السجلات ومتطلبات التوافق.

مراقبه الأمان

استخدم Defender for Containers في Microsoft Defender for Cloud لعرض توصيات الأمان ومعالجتها، ولعرض تنبيهات الأمان بشأن موارد الحاوية. قم بتمكين خطط Microsoft Defender لأنها تنطبق على مكونات متنوعة لبيئة بيانات حامل البطاقة.

ادمج السجلات بحيث تتمكن من مراجعة البيانات وتحليلها والاستعلام عنها بكفاءة. يوفر Azure العديد من الخيارات. يمكنك تشغيل سجلات تشخيص AKS وإرسالها إلى مساحة عمل Log Analytics التي تعد جزءا من Azure Monitor. خيار آخر هو دمج البيانات في معلومات الأمان وحلول إدارة الأحداث (SIEM)، مثل Microsoft Sentinel.

كما هو مطلوب من قبل المعيار، تُعين جميع مساحات عمل Log Analytics على فترة استبقاء تقدر بـ 90 يوماً. ضع في اعتبارك إعداد التصدير المستمر للتخزين على المدى الطويل. لا تخزن المعلومات الحساسة في بيانات السجل، وتأكد من أن الوصول إلى بيانات السجل المؤرشفة يخضع لنفس مستويات عناصر التحكم في الوصول مثل بيانات السجل الأخيرة.

للحصول نظرة شاملة، راجع دليل إلحاق Microsoft Defender for Cloud Enterprise. يتناول هذا الدليل كيفية التسجيل وتصدير البيانات إلى حلول SIEM والاستجابة إلى التنبيهات والتشغيل التلقائي لسير عمل البناء.

خدمات Azure ذات الصلة

فيما يلي ارتباطات وثائق الميزات المرتبطة ببعض المكوّنات الرئيسية لهذه الهندسية.

• خدمة Azure Kubernetes (AKS)
• Azure Firewall
• Azure Bastion
• Azure Image Builder
• مجموعات توسعة الأجهزة الظاهرية في Azure
• Azure Application Gateway مع Web Application Firewall (WAF) المتكامل
• مهام Azure Container Registry
• Azure Key Vault

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

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