مراقبة عمليات نظام مجموعة أساس AKS لـ PCI-DSS 3.2.1 (الجزء 7 من 9)

توضح هذه المقالة الاعتبارات الخاصة بمجموعة Azure Kubernetes Service (AKS) التي تقوم بتشغيل حِمل عمل وفقاً لمعيار أمان بيانات صناعة بطاقات الدفع (PCI-DSS 3.2.1).

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

مراقبة الشبكات واختبارها بانتظام

المتطلب 10 - تعقب ومراقبة جميع الوصول إلى موارد الشبكة وبيانات حامل البطاقة

دعم ميزة AKS

يوفر Azure ميزة Container Insights التي تراقب الحاويات، بما في ذلك أنظمة مجموعات AKS. لمزيد من المعلومات، راجع نظرة عامة على ميزة Container Insights.

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

يمكن استخدام التحكم في الوصول استناداً إلى الدور (RBAC) لإدارة نهج الوصول إلى الموارد كممارسة قياسية على Azure.

يجب تخزين جميع السجلات في حساب تخزين مملوك للعميل أو سجلات Azure Monitor. وبهذه الطريقة، يمكنك إنشاء نتائج تحليلات بسرعة من حجم كبير من البيانات. يتم الاحتفاظ بجميع السجلات بثلاث نسخ على الأقل في منطقة واحدة. يمكنك الحصول على المزيد من النسخ عن طريق تمكين النسخ الاحتياطي أو النسخ المتماثل عبر المناطق. تتوفر جميع إدخالات السجل فقط من خلال قنوات HTTP(s) الآمنة.

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

مسؤولياتك

المتطلب 11 - اختبار أنظمة الأمان والعمليات بانتظام

دعم ميزة AKS

تم دمج AKS مع خدمات مراقبة Azure:

• يوفر Microsoft Defender for Containers العديد من ميزات فحص الأمان. على سبيل المثال، يفحص Defender for Containers الصور التي تم سحبها ودفعها واستيرادها إلى سجلات الحاويات ويقدم توصيات. للحصول على التفاصيل، راجع تقييم الثغرات الأمنية.

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

مجموعات AKS محمية بواسطة Azure Application Gateway مع جدار حماية تطبيق الويب (WAF)، ويمكن تكوينها في وضع الكشف لتسجيل التنبيهات والتهديدات. يعد الوضع الأقوى هو الوضع الوقائي، الذي يمنع بنشاط عمليات الاختراق والهجمات المكتشفة. لمعرفة التفاصيل، راجع أفضل الممارسات لاتصال الشبكة والأمان في Azure Kubernetes Service (AKS).

مسؤولياتك

المتطلب 10-1

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

مسؤولياتك

نوصي باستخدام عمليات التدقيق التي يتم إجراؤها على كل مكون باستخدام الطرق التالية:

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

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

  

• إعدادات تشخيص Azure. يوفر معلومات التشخيص والتدقيق لموارد Azure والنظام الأساسي الذي ينطبق عليه الإعداد. نوصي بتمكين إعدادات التشخيص ل AKS والمكونات الأخرى في النظام، مثل Azure Blob Storage وKey Vault. استنادا إلى نوع المورد، يمكنك اختيار نوع السجلات وبيانات القياس لإرسالها إلى وجهة. يجب أن تفي وجهة التشخيص بفترات الاستبقاء المطلوبة.

  • إعداد التشخيص لـ AKS. من فئات AKS المتوفرة، قم بتمكين سجلات تدقيق Kubernetes. تتضمن kube-audit إعدادات التشخيص أو kube-audit-adminو.guard

    تمكين kube-audit-admin لمشاهدة استدعاءات خادم API المستندة إلى السجل التي قد تعدل حالة نظام المجموعة. إذا كنت بحاجة إلى سجل تدقيق لكافة تفاعلات خادم واجهة برمجة التطبيقات (بما في ذلك الأحداث غير التعديلية مثل طلبات القراءة)، فقم بتمكين kube-audit بدلاً من ذلك. يمكن أن تكون هذه الأحداث غزالية، وتخلق ضوضاء، وتزيد من تكلفة الاستهلاك الخاصة بك. تحتوي هذه السجلات على معلومات حول اسم الوصول والهوية المستخدم لتقديم الطلب.

    تمكين guard السجلات لتعقب معرف Microsoft Entra المدار وحسابات التحكم في الوصول المستندة إلى الدور (RBAC) في Azure.

  بالإضافة إلى السجلات المستندة إلى المستخدم، ضع في اعتبارك السجلات من وحدة التحكم Kubernetes، بما في ذلك kube-apiserver وkube-controller-manager. لا ترتبط هذه السجلات عادة بالمستخدم، ولكن يمكن أن تساعد في ربط تغييرات النظام التي أجراها المستخدمون.

  لمزيد من المعلومات، راجع عرض سجلات مكونات وحدة التحكم.

  يتيح cluster-autoscalerهذا التطبيق المرجعي kube-controller-managerkube-audit-adminالسجلات و و guard و وإعادة التوجيه إلى مساحة عمل Log Analytics. تم تعيين فترة استبقاء مساحة العمل إلى 90 يوما.

  

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

يجب تنفيذ آليات سجل التدقيق السابقة في وقت توزيع الموارد. يجب أن يكون نهج Azure نشطاً أيضاً لضمان عدم تعطيل هذه التكوينات عن غير قصد أو بشكل ضار في CDE الخاص بك.

المتطلب 10-2

تنفيذ سجلات التدقيق التلقائية لجميع مكونات النظام لإعادة إنشاء الأحداث التالية:

• 10-2-1 جميع المستخدمين الفرديين يصلون إلى بيانات حامل البطاقة
• 10-2-2 جميع الإجراءات التي يتخذها أي فرد يتمتع بامتيازات جذرية أو إدارية
• 10-2-3 الوصول إلى جميع سجلات التدقيق
• 10-2-4 محاولات وصول منطقية غير صحيحة
• 10.2.5 استخدام آليات تحديد الهوية والمصادقة والتغييرات فيها - بما في ذلك على سبيل المثال لا الحصر إنشاء حسابات جديدة ورفع الامتيازات - وجميع التغييرات أو الإضافات أو عمليات الحذف للحسابات ذات الامتيازات الجذر أو الإدارية
• 10-2-6 تهيئة سجلات التدقيق أو إيقافها أو إيقافها مؤقتاً
• 10-2-7 إنشاء العناصر على مستوى النظام وحذفها

مسؤولياتك

توفر AKS سجلات التدقيق على مستويات متعددة، كما هو موضح في المتطلب 10-1. فيما يلي بعض النقاط الرئيسية:

• بشكل افتراضي، توفر سجلات النشاط معلومات حول عمليات موارد Azure الهامة. تتضمن جميع السجلات الحالة والوقت والهوية التي بدأت العملية.
• تمكين إعدادات التشخيص للوصول إلى جميع سجلات جميع استدعاءات واجهة برمجة التطبيقات التي تم إجراؤها في نظام مجموعة AKS. توفر السجلات تفاصيل حول الطالب والطابع الزمني ومصدر الطلب ومحتويات الطلب. قم بتخزين السجلات في مساحة عمل Log Analytics مع فترة استبقاء مناسبة. تمكين تسجيل مساحة عمل Log Analytics للتأكد من تسجيل الوصول إلى سجل التدقيق.
• تمكين مجموعة syslog مع Container Insights لالتقاط أمان نظام التشغيل على مستوى عقدة AKS وسجلات الأحداث الصحية في مساحة عمل Log Analytics. يجب أيضا استيعاب هذه السجلات في SIEM الخاص بك.
• قم بتضمين نظام التشغيل وتسجيل تدقيق الاستخدام للحساب الآخر مثل عوامل البناء ومربعات الانتقال. تعطيل الوصول إلى الأنظمة مباشرة كجذر. تحقق من تنفيذ جميع الإجراءات ضمن هوية معينة.
• تسجيل محاولات الوصول غير الناجحة. يتضمن ذلك طلبات الوصول إلى مكونات مثل Azure Storage وAzure Key Vault وخادم AKS API وأي وصول RDP/SSH على أنظمة أخرى.
• استفد من الميزات، التي يقدمها وكلاء أمان تابعون لجهة خارجية، للمساعدة في تحليل أنماط المستخدم داخل نظام مجموعة AKS. قد تكون هذه الميزات مفيدة لبيانات تدقيق وصول المستخدم.

المتطلب 10-3

سجل على الأقل إدخالات سجل التدقيق التالية لجميع مكونات النظام لكل حدث:

• 10-3-1 تعريف المستخدم
• 10-3-2 نوع الحدث
• 10-3-3 التاريخ والوقت
• 10-3-4 مؤشر النجاح أو الفشل
• 10-3-5 نشأة الحدث
• 10-3-6 هوية أو اسم البيانات المتأثرة أو مكون النظام أو المورد المتأثر.

مسؤولياتك

كما هو موضح في المتطلب 10-2، يمكنك الحصول على سجلات التدقيق من نظام المجموعة عن طريق تمكين إعداد التشخيص لخدمة AKS. تحتوي السجلات على معلومات مفصلة حول أحداث الحصول على الأحداث وإدراجها وإنشائها وتحديثها وحذفها وتصحيحها ونشرها. تحتوي السجلات على معلومات في القائمة ضمن «المتطلبات». قم بتخزين السجلات في حساب تخزين بحيث يمكنك الاستعلام عن المعلومات.

على سبيل المثال، تريد عرض مجموعة المعلومات السابقة لأحداث kube-audit-admin عن طريق تشغيل هذا الاستعلام:

AzureDiagnostics
| where Category == 'kube-audit-admin'
| project TimeGenerated, ResourceId, log_s,  pod_s
| top 200 by TimeGenerated desc

تعرض مجموعة النتائج المعلومات كجزء من حقل log_s.

للحصول على معلومات حول السجل الرئيسي، راجع عرض سجلات مكونات وحدة التحكم.

المتطلب 10-4

استخدم تقنية مزامنة الوقت لمزامنة جميع ساعات وأوقات النظام الهامة، والتحقق من تنفيذ ما يلي للحصول على الوقت وتوزيعه وتخزينه.

• 10-4-1 تمتع الأنظمة المهمة بالوقت الصحيح والمتناسق.
• 10-4-2 بيانات الوقت محمية.
• 10-4-3 يتم تلقي إعدادات الوقت من مصادر الوقت المقبولة من قبل الصناعة.

ملاحظة: أحد الأمثلة على تقنية مزامنة الوقت هو بروتوكول وقت الشبكة (NTP).

مسؤولياتك

تستخدم AKS NTP من مضيفي Azure الأساسيين ولا تتطلب أي بدلات نسبة استخدام الشبكة الصادرة لدعم NTP. قد تستخدم الأجهزة الظاهرية الأخرى التي تضيفها إلى CDE خوادم NTP الخارجية مثل ntp.ubuntu.org (وتجمعها) كمصدر مزامنة الوقت. يجب أن تستخدم الحوسبة الإضافية التي تجلبها إلى CDE بشكل صريح مصدر NTP الذي تختاره ويجب توثيقه.

المتطلب 10-5

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

• 10.5.1 تقييد عرض مسارات التدقيق للأشخاص الذين يعانون من حاجة متعلقة بالوظيفة.
• 10-5-2 حماية ملفات سجل التدقيق من التعديلات غير المصرح بها.
• 10-5-3 قم على الفور بنسخ ملفات سجل التدقيق احتياطياً إلى خادم سجل مركزي أو وسائط يصعب تغييرها.
• 10-5-4 كتابة سجلات للتقنيات الخارجية على خادم سجل داخلي آمن ومركزي أو جهاز وسائط.
• 10-5-5 استخدم برنامج مراقبة تكامل الملفات أو الكشف عن التغيير على السجلات للتأكد من أنه لا يمكن تغيير بيانات السجل الموجودة دون إنشاء تنبيهات (على الرغم من أن البيانات الجديدة التي تتم إضافتها يجب ألا تسبب تنبيها).

مسؤولياتك

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

عندما يكون ذلك ممكناً، ادمج السجلات. تشكل الميزة القدرة على مراجعة البيانات وتحليلها والاستعلام عن البيانات بكفاءة. يوفر Azure خيارات تقنية متعددة. يمكنك استخدام نتائج تحليلات حاوية Azure Monitor لكتابة السجلات في مساحة عمل Log Analytics. يوجد خيار آخر، وهو دمج البيانات في حلول إدارة الأحداث ومعلومات الأمان (SIEM)، مثل Microsoft Sentinel. إن خيارات الجهات الخارجية الشائعة أخرى هي Splunk، وQRadar، وArcSight. يدعم Microsoft Defender for Cloud وAzure Monitor كل هذه الحلول. هذه الحلول عبارة عن متلقيات بيانات إلحاقية فقط للتأكد من عدم إمكانية تغيير المسار.

يمكن لـ Defender for Cloud تصدير النتائج على فترات زمنية تم تكوينها. لمزيد من المعلومات، راجع التصدير المستمر.

يتم الاحتفاظ بجميع السجلات بثلاث نسخ على الأقل في منطقة واحدة. كاستراتيجية نسخ احتياطي، يمكنك الحصول على المزيد من النسخ عن طريق تمكين النسخ الاحتياطي أو النسخ المتماثل عبر المناطق. تتوفر جميع إدخالات السجل فقط من خلال قنوات HTTP(s) الآمنة.

يدعم Log Analytics وMicrosoft Azure Sentinel العديد من ضوابط الوصول المستندة إلى الأدوار لإدارة الوصول إلى مسار التدقيق. تأكد من تعيين الأدوار إلى أدوار المؤسسة ومسؤولياتها.

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

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

المتطلب 10-6

راجع السجلات وأحداث الأمان لجميع مكونات النظام لتحديد الحالات الشاذة أو النشاط المشبوه.

• 10.6.1 راجع ما يلي يوميا على الأقل:
  • جميع الأحداث الأمنية
  • سجلات جميع مكونات النظام التي تخزن أو تعالج أو تنقل CHD و/أو SAD
  • سجلات جميع مكونات النظام الهامة
  • سجلات جميع الخوادم ومكونات النظام التي تؤدي وظائف الأمان (على سبيل المثال، جدران الحماية، وأنظمة الكشف عن التسلل/أنظمة منع الاختراق (IDS/IPS)، وخوادم المصادقة، وخوادم إعادة توجيه التجارة الإلكترونية، وما إلى ذلك)."
• 10-6-2 استعراض سجلات جميع مكونات النظام الأخرى بشكل دوري استناداً إلى نهج المؤسسة واستراتيجية إدارة المخاطر، على النحو الذي يحدده التقييم السنوي للمخاطر الذي تقوم به المؤسسة.
• 10-6-3 متابعة الاستثناءات والحالات الشاذة التي تم تحديدها أثناء عملية المراجعة.

مسؤولياتك

يمكن لخدمات مراقبة Azure، Azure Monitor وMicrosoft Defender for Cloud، إنشاء إعلامات أو تنبيهات عند اكتشاف نشاط غير طبيعي. تتضمن هذه التنبيهات معلومات السياق، مثل الخطورة والحالة ووقت النشاط.

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

مركزية البيانات في طريقة عرض واحدة باستخدام حلول SIEM، مثل Microsoft Sentinel. يمكن أن يوفر تكامل البيانات سياق تنبيه منسقًا.

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

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

المتطلب 10-7

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

مسؤولياتك

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

المتطلب 10-8

• 10-8-1 متطلبات إضافية لموفري الخدمات فقط: الاستجابة لحالات فشل أي عناصر تحكم أمنية هامة في الوقت المناسب. يجب أن تتضمن عمليات الاستجابة لحالات الفشل في عناصر التحكم في الأمان ما يلي:

• استعادة وظائف الأمان

• تحديد وتوثيق مدة فشل الأمان (التاريخ والوقت من البداية إلى النهاية)

• تحديد وتوثيق سبب (أسباب) الفشل، بما في ذلك السبب الجذري، وتوثيق المعالجة المطلوبة لمعالجة السبب الجذري

• تحديد ومعالجة أي مشكلات أمنية نشأت أثناء الفشل

• إجراء تقييم للمخاطر لتحديد ما إذا كانت هناك حاجة إلى مزيد من الإجراءات نتيجة لفشل الأمان

• تنفيذ عناصر التحكم لمنع سبب الفشل من تكرار -استئناف مراقبة عناصر تحكم الأمان"

مسؤولياتك

عندما يكون الأمر عملياً، تكون لديك تنبيهات تشير إلى وجود عناصر تحكم أمنية هامة. وإلا، فتأكد من أن عملية التدقيق الخاصة بك يمكنها اكتشاف عدم وجود عنصر تحكم أمني متوقع في الوقت المناسب. ضع في اعتبارك عناصر التحكم مثل عوامل الأمان التي تعمل في مجموعة AKS وعناصر التحكم في الوصول (IAM والشبكة) على موارد Azure. قم بتضمين إعدادات للتحقق مما إذا كان نظام مجموعة AKS عبارة عن مجموعة خاصة، لنقاط التعرض للشبكة من خلال قواعد مجموعة أمان الشبكة (NSG)، أو تحقق من وجود عناوين IP عامة غير متوقعة. قم أيضا بتضمين تغييرات غير متوقعة في DNS وتوجيه الشبكة وجدار الحماية ومعرف Microsoft Entra.

المتطلب 10-9

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

مسؤولياتك

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

المتطلب 11-1

تنفيذ عمليات لاختبار وجود نقاط وصول لاسلكية (802.11)، واكتشاف وتحديد جميع نقاط الوصول اللاسلكية المعتمدة وغير المصرح بها على أساس ربع سنوي.

الشبكات الخارجية تقع خارج نطاق هذه الوثائق، ويجب تقييمها بشكل منفصل.

مسؤولياتك

لم يتم تصميم هذه البنية وتنفيذها لدعم المعاملات المحلية أو المعاملات من شبكة إلى سحابة للشركات عبر الاتصالات اللاسلكية. بالنسبة للاعتبارات، راجع الإرشادات الواردة في معيار PCI-DSS 3.2.1 الرسمي.

المتطلب 11-2

تشغيل عمليات فحص الثغرات الأمنية الداخلية والخارجية للشبكة كل ثلاثة أشهر على الأقل وبعد أي تغييرات هامة في الشبكة، مثل:

• عمليات تثبيت مكونات النظام الجديدة
• التغييرات في طبولوجيا الشبكة
• تعديلات قاعدة جدار الحماية
• ترقيات المنتجات

لمزيد من المعلومات، راجع موردو الفحص المعتمدين لمعيار أمان البيانات (PCI) في صناعة بطاقات الدفع.

مسؤولياتك

توجد لديك عملية تتحقق من التغييرات في نظام مجموعة AKS وتكوين الشبكة وسجلات الحاويات والمكونات الأخرى للبنية.

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

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

• تكوين قواعد NSG أو Azure Firewall
• نظائر الشبكة الظاهرية
• إعدادات DNS
• تكوينات Azure Private Link
• مكونات الشبكة الأخرى

ينطبق على 11-2-1

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

يجب أن يتضمن هذا الفحص أيضاً شبكات داخل نظام المجموعة (pod-to-pod).

ينطبق على 11-2-2 حدد مورد فحص معتمدًا (ASV) يتمتع بخبرة واسعة مع شبكات Azure وKubernetes. وهذا يوفر العمق والخصوصية في المعالجة المقترحة.

المتطلب 11-3

تنفيذ منهجية لاختبار الاختراق تتضمن ما يلي:

• يستند إلى نهج اختبار الاختراق المقبولة من قبل الصناعة (على سبيل المثال، NIST SP800-115)
• يتضمن تغطية لمحيط CDE بأكمله والأنظمة الحرجة
• يتضمن الاختبار من داخل الشبكة وخارجها
• يتضمن الاختبار للتحقق من صحة أي عناصر تحكم في التقسيم وتقليل النطاق
• تعريف اختبارات اختراق طبقة التطبيق لتضمين، كحد أدنى، الثغرات الأمنية المدرجة في المتطلب 6-5
• تعريف اختبارات اختراق طبقة الشبكة لتضمين المكونات التي تدعم وظائف الشبكة وأنظمة التشغيل
• يتضمن استعراض التهديدات والثغرات الأمنية التي واجهتها في الأشهر الـ 12 الماضية والنظر فيها
• تحديد استبقاء نتائج اختبار الاختراق ونتائج أنشطة المعالجة.

مسؤولياتك

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

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

يجب أن تغطي الاختبارات طبقات التطبيق والبيانات التي تعمل في CDE.

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

المتطلب 11-4

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

مسؤولياتك

حماية نظام مجموعة AKS عن طريق فحص نسبة استخدام الشبكة الواردة باستخدام جدار حماية تطبيق ويب (WAF). في هذه البنية، تمنع بوابة تطبيق Azure مع WAF المتكامل الاختراق. استخدم وضع منع لمنع الاختراقات والهجمات المكتشفة بنشاط. لا تستخدم وضع الكشف فقط. لمعرفة المزيد من التفاصيل، راجع أفضل الممارسات لاتصال الشبكة والأمان في Azure Kubernetes Service (AKS).

يتمثل الخيار البديل في الكشف عن التطفل و/أو إمكانات منع التطفل في Azure Firewall Premium. لمزيدٍ من المعلومات، راجع IDPS.

خيار آخر هو تمكين Azure Monitor Network Insights، الذي يوفر الوصول إلى قدرات مراقبة الشبكة مثل Connection Monitor وتسجيل التدفق لمجموعات أمان الشبكة (NSGs) وتحليلات نسبة استخدام الشبكة.

قم بتمكين خطط Microsoft Defender كما تنطبق على مكونات مختلفة من CDE. على سبيل المثال، إذا تم استخدام Azure SQL لتخزين CHD، فسيتأكد Microsoft Defender for SQL من اكتشاف اختراقات طبقة البيانات.

أيضاً، اكتشف الحالات الشاذة في أنماط نسبة استخدام الشبكة عن طريق توصيل سجلات تدفق NSG بحل SIEM مركزي، مثل Microsoft Sentinel. في هذا التطبيق المرجعي، تكون السجلات في وضع الإلحاق فقط، ما يقلل من تعقب التغييرات على سجلات التدقيق. ومع ذلك، يجب عدم تعديل جميع السجلات التي يتم إرسالها إلى متلقيات خارجية للتخزين طويل الأجل. يجب أن يتبعوا نهج الكتابة مرة واحدة / القراءة المتعددة. تأكد من أن حل مراقبة تكامل الملفات (FIM) يغطي تلك الكيانات الخارجية للكشف عن التغييرات.

المتطلب 11-5

نشر حل تعقب التغيير (على سبيل المثال، حل مراقبة تكامل الملفات) لتنبيه الموظفين إلى التعديل غير المصرح به لملفات النظام الهامة أو ملفات التكوين أو ملفات المحتوى. قم بتكوين المنتج لإجراء مقارنات الملفات الهامة أسبوعيا على الأقل.

مسؤولياتك

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

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

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

يجب تمكين تعقب التغييرات لأي حساب آخر في CDE.

المتطلب 11-6

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

مسؤولياتك

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

هذا مهم للأشخاص الذين هم جزء من عملية الموافقة من منظور النهج.

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

احتفظ بنهج يعالج أمان المعلومات لجميع الموظفين.