إدارة الوصول إلى نظام مجموعة أساس AKS لـ PCI-DSS 3.2.1 (الجزء 6 من 9)

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

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

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

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

تنفيذ مقاييس قوية للتحكم في الوصول

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

دعم ميزة AKS

AKS متكاملة تماما مع معرف Microsoft Entra كموفر الهوية.

لا يتعين عليك إدارة هويات المستخدمين وبيانات اعتمادهم المنفصلة لـ Kubernetes. يمكنك إضافة مستخدمي Microsoft Entra ل Kubernetes RBAC. هذا التكامل يجعل من الممكن تعيين أدوار لمستخدمي Microsoft Entra. باستخدام هويات Microsoft Entra، يمكنك استخدام مجموعة متنوعة من الأدوار المضمنة، مثل العارض والكاتب ومسؤول الخدمة ومسؤول نظام المجموعة. يمكنك أيضا إنشاء أدوار مخصصة لمزيد من التحكم الدقيق.

بشكل افتراضي، يتم تعيين Azure RBAC لرفض الوصول بالكامل، لذلك لا يمكن الوصول إلى مورد دون منح أذونات. AKS يحد من وصول SSH إلى عُقد عامل AKS، ويستخدم نهج شبكة AKS للتحكم في الوصول إلى أحمال العمل في pods.

لمزيد من المعلومات، راجع استخدام Azure RBAC لتفويض Kubernetes وتأمين نظام المجموعة باستخدام نهج Azure.

مسؤولياتك

المتطلبات	المسؤولية
المتطلب 7.1	قم بتقصير الوصول إلى مكونات النظام وبيانات حامل البطاقة على الأفراد الذين تتطلب وظيفتهم مثل هذا الوصول فقط.
المتطلب 7.2	أنشئ نظام التحكم في الوصول لمكونات الأنظمة التي تقيد الوصول استنادًا إلى حاجة المستخدم إلى المعرفة، ويتم تعيينها إلى "رفض الكل" ما لم يكن مسموحًا به على وجه التحديد.
المتطلب 7.3	تأكد من توثيق سياسات الأمان والإجراءات التشغيلية لتقييد الوصول إلى بيانات حامل البطاقة واستخدامها وجعلها معروفة لجميع الأطراف المتأثرة.

المتطلب 7.1

قم بتقصير الوصول إلى مكونات النظام وبيانات حامل البطاقة على الأفراد الذين تتطلب وظيفتهم مثل هذا الوصول فقط.

مسؤولياتك

موضح فيما يلي بعض الاعتبارات:

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

المتطلب 7.1.1

حدد احتياجات الوصول لكل دور، بما في ذلك:

• مكونات النظام وموارد البيانات التي يحتاجها كل دور للوصول إلى مهمته الوظيفية
• مستوى الامتياز المطلوب (على سبيل المثال، المستخدم والمسؤول، وما إلى ذلك) للوصول إلى الموارد.

مسؤولياتك

حدد الأدوار استنادًا إلى المهام والمسؤوليات المطلوبة للمكونات داخل النطاق وتفاعلها مع موارد Azure. يمكنك البدء بفئات رئيسية، مثل:

• النطاق حسب مجموعات إدارة Azure، أو الاشتراكات، أو مجموعات الموارد
• نهج Azure لحمل العمل أو الاشتراك
• عمليات الحاوية
• إدارة البيانات السرية
• إنشاء البنية الأساسية لبرنامج ربط العمليات التجارية وتوزيعها

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

• حدد تكوينات أمان التطبيق وKubernetes RBAC ونهج الشبكة ونهج Azure والاتصال بالخدمات الأخرى.
• تكوين جدار حماية Azure وجدار حماية تطبيق الويب (WAF) ومجموعات أمان الشبكة (NSGs) وDNS وصيانتها.
• قم بمراقبة أمان الخادم وإصلاحه والتصحيح والتكوين وأمان نقطة النهاية.
• تعيين اتجاه لاستخدام RBAC وMicrosoft Defender for Cloud واستراتيجية حماية المسؤول ونهج Azure للتحكم في موارد Azure.
• تحديد فريق مراقبة الحوادث والاستجابة لها. التحقيق في الحوادث الأمنية ومعالجتها باستخدام نظام إدارة معلومات الأمان والأحداث (SIEM) مثل Microsoft Sentinel أو Microsoft Defender for Cloud.

ثم أضف الطابع الرسمي على التعريف عن طريق تحديد مستوى الوصول المطلوب للدور فيما يتعلق بحمل العمل والبنية الأساسية. فيما يلي تعريفًا بسيطًا لأغراض توضيحية.

الدور	المسؤوليات	مستويات الوصول
أصحاب التطبيقات	تعريف الميزات التي تتماشى مع نتائج الأعمال وتحديد أولوياتها. إنهم يفهمون كيف تؤثر الميزات على نطاق الامتثال لحمل العمل، وتوازن حماية بيانات العملاء وملكيتهم بأهداف العمل.	اقرأ الوصول إلى السجلات والمقاييس المنبعثة من التطبيق. لا يحتاجون إلى أذونات للوصول إلى حمل العمل أو نظام المجموعة.
مطورو التطبيقات	قم بتطوير التطبيق. جميع التعليمات البرمجية للتطبيق تخضع لبوابات التدريب والجودة التي تدعم عمليات الامتثال والإثبات وإدارة الإصدار. قد تدير البنية الأساسية لبرنامج ربط العمليات التجارية للإنشاء، ولكنها عادة ليست مسارات التوزيع.	اقرأ الوصول إلى مساحات أسماء Kubernetes وموارد Azure الموجودة في نطاق حمل العمل. لا يوجد وصول للكتابة لتوزيع أو تعديل أي حالة للنظام.
عوامل تشغيل التطبيق (أو SRE)	لديك فهم عميق لقاعدة التعليمات البرمجية وإمكانية المراقبة والعمليات. افرز الموقع المباشر واستكشاف الأخطاء وإصلاحها. جنبًا إلى جنب مع مطوري التطبيقات، حسِّن توفر التطبيق وقابليته للتوسع وأدائه. قم بإدارة مسار توزيع "الميل الأخير" والمساعدة في إدارة البنية الأساسية لبرنامج ربط العمليات التجارية للبناء.	مميز للغاية ضمن نطاق التطبيق الذي يتضمن مساحات أسماء Kubernetes ذات الصلة وموارد Azure. من المحتمل أن يكون لديك إمكانية وصول دائم إلى أجزاء من نظام مجموعة Kubernetes.
ملاك البنية الأساسية	قم بتصميم بنية فعالة من حيث التكلفة، بما في ذلك اتصالها ووظائف المكونات. يمكن للنطاق أن يتضمن الخدمات السحابية والخدمات المحلية. حدد استبقاء بيانات القدرات، وميزات استمرارية الأعمال، وغيرها.	قم بالوصول إلى سجلات النظام الأساسي وبيانات مركز التكلفة. غير مطلوب الوصول داخل نظام المجموعة.
عوامل تشغيل البنية الأساسية (أو SRE)	العمليات المتعلقة بنظام المجموعة والخدمات التابعة. أنشئ البنية الأساسية لبرنامج ربط العمليات التجارية لنظام المجموعة التي يتم توزيع حمل العمل فيها وقم بتوزيعها وتمهيدها. تعيين تجمعات العقد المستهدفة ومتطلبات تغيير الحجم والمقياس المتوقعة. راقب صحة البنية الأساسية لاستضافة الحاوية والخدمات التابعة.	اقرأ الوصول إلى مساحات أسماء حمل العمل. الوصول المتميز للغاية للمجموعة.
النهج، ملاك الأمان	لديك خبرة في الامتثال للأمان أو التنظيم. حدد النُهج التي تحمي الأمان والامتثال التنظيمي لموظفي الشركة وأصولها وأصول عملاء الشركة. يعمل مع جميع الأدوار الأخرى لضمان تطبيق النهج وأن يكون قابل التدقيق خلال كل مرحلة.	اقرأ الوصول إلى حمل العمل ونظام المجموعة. قم أيضًا بالوصول إلى بيانات السجل والتدقيق.
عوامل تشغيل الشبكة	خصص الشبكة الظاهرية والشبكات الفرعية على مستوى المؤسسة. قم بتكوين Azure Firewall وWAF وNSGs وصيانتها وتكوين DNS.	مميز للغاية في طبقة الشبكات. لا يوجد إذن كتابة داخل نظام المجموعة.

المتطلب 7.1.2

قم بتقييد الوصول إلى معرفات المستخدم المميزة إلى أقل الامتيازات اللازمة لأداء مسؤوليات الوظيفة.

مسؤولياتك

استنادًا إلى وظائف الوظيفة، اسعَ جاهدة لتقليل الوصول دون التسبب في اضطرابات. فيما يلي مجموعة من أفضل الممارسات:

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

المتطلب 7.1.3

قم بتعيين الوصول استنادًا إلى تصنيف وظائف الأفراد ووظائفهم.

مسؤولياتك

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

وإليك بعض الأمثلة.

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

المتطلب 7.1.4

يتطلب موافقة موثقة من الأطراف المعتمدة التي تحدد الامتيازات المطلوبة.

مسؤولياتك

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

المتطلب 7.2

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

مسؤولياتك

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

استنادًا إلى الأدوار والمسؤوليات، عيِّن الأدوار للتحكم في الوصول المستند إلى الدور للبنية الأساسية (RBAC). ويمكن أن تكون هذه الآلية كما يلي:

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

لنفترض أنك بحاجة إلى منح أذونات لعوامل تشغيل نظام المجموعة (المعيَّنة لدور عامل تشغيل البنية الأساسية). ينتمي جميع الأشخاص الذين تم تعيينهم لمسؤوليات مشغل البنية الأساسية إلى مجموعة Microsoft Entra. كما تم توضيحه في 7.1.1، يتطلب هذا الدور أعلى امتياز في نظام المجموعة. يحتوي Kubernetes على أدوار التحكم في الوصول استنادًا إلى الدور المضمنة، مثل cluster-admin، التي تلبي هذه المتطلبات. ستحتاج إلى ربط مجموعة Microsoft Entra لمشغل البنية الأساسية بإنشاء cluster-admin روابط الأدوار. توجد طريقتان رئيسيتان. يمكنك اختيار الأدوار المضمَّنة. أو، إذا كانت الأدوار المضمنة لا تفي بمتطلباتك (على سبيل المثال، قد تكون متساهلة بشكل مفرط)، قم بإنشاء أدوار مخصصة للروابط الخاصة بك.

التنفيذ المرجعي يوضح المثال السابق باستخدام Kubernetes RBAC الأصلي. يمكن تحقيق نفس الاقتران باستخدام Azure RBAC. لمزيد من المعلومات، راجع التحكم في الوصول إلى موارد نظام المجموعة باستخدام التحكم في الوصول المستند إلى الدور Kubernetes وهويات Microsoft Entra في خدمة Azure Kubernetes.

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

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

بصرف النظر عن الأشخاص وأدوارهم، فإن موارد Azure وحتى الجرابات داخل نظام المجموعة لديها هويات مُدارة. هذه الهويات تحتاج إلى مجموعة من الأذونات من خلال Azure RBAC، ويجب تحديد نطاقها بإحكام استنادًا إلى المهام المتوقعة. على سبيل المثال، يجب أن تكون لدى Azure Application بوابة أذونات للحصول على البيانات السرية (شهادات TLS) من Azure Key Vault. يجب ألا يكون لديه أذونات لتعديل البيانات السرية.

فيما يلي مجموعة من أفضل الممارسات:

• الاحتفاظ بوثائق دقيقه حول كل دور والأذونات المعينة، بالإضافة إلى التبريرات. احتفظ بتمييزات واضحة حول الأذونات التي تكون JIT وأيها قائمة.

• راقب الأدوار للتغييرات، مثل تغييرات التعيين أو تعريفات الأدوار. إنشاء تنبيهات حول التغييرات، حتى لو كان متوقعا، للحصول على رؤية في النوايا وراء التغييرات.

المتطلب 7.2.1

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

مسؤولياتك

فيما يلي بعض أفضل الممارسات للحفاظ على تدابير التحكم في الوصول:

• ليس لديك حق الوصول الدائم. ضع في اعتبارك استخدام عضوية مجموعة AD في الوقت المناسب. تتطلب هذه الميزة إدارة الهويات المتميزة Microsoft Entra.

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

  إشعار

  تتطلب كل من خيارات تقنية JIT والوصول المشروط تراخيص Microsoft Entra ID P1 أو P2.

• قم بتعطيل وصول SSH إلى عقد نظام المجموعة بشكل مثالي. هذا التنفيذ المرجعي لا ينشئ تفاصيل اتصال SSH لهذا الغرض.

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

المتطلب 7.2.2

قم بتعيين الامتيازات للأفراد على أساس تصنيف الوظيفة والوظيفة.

مسؤولياتك

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

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

• كيف يجب عليهم الوصول إلى نظام المجموعة؟
• ما هي المصادر المسموح بالوصول إليها؟
• ما هي الأذونات التي يجب أن تكون لديهم على نظام المجموعة؟
• متى يتم تعيين هذه الأذونات؟

تأكد من توثيق التعريفات في وثائق الحوكمة والنهج ومواد التدريب حول عامل تشغيل حمل العمل ومشغل نظام المجموعة.

المتطلب 7.2.3

الإعداد الافتراضي "رفض الكل".

مسؤولياتك

عند بدء التكوين، ابدأ بنُهج الثقة المعدومة. قم بإجراء استثناءات حسب الحاجة وقم بتوثيقها بالتفصيل.

• يقوم Kubernetes RBAC بتنفيذ رفض الكل بشكل افتراضي. لا تتجاوز عن طريق إضافة روابط دور نظام المجموعة المتساهلة للغاية التي عكس الإعداد رفض كافة.

• يقوم Azure RBAC أيضًا بتنفيذ رفض الكل بشكل افتراضي. لا تتجاوز عن طريق إضافة تعيينات التحكم في الوصول استنادا إلى الدور التي عكست الإعداد رفض الكل.

• ترفض جميع خدمات Azure، بما في ذلك Azure Key Vault وAzure Container Registry، جميع الأذونات بشكل افتراضي.

• يجب أن ترفض أي نقاط وصول إدارية، مثل مربع انتقال، كل إمكانيات الوصول في التكوين الأولي. يجب تعريف كافة الأذونات المرتفعة بشكل صريح لتجاوز قاعدة الرفض بالكامل.

المتطلب 7.3

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

مسؤولياتك

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

المتطلب 8 - تحديد الوصول إلى مكونات النظام ومصادقته

دعم ميزة AKS

بسبب تكامل AKS وMicrosoft Entra، يمكنك الاستفادة من إمكانات إدارة الهوية والتخويل، بما في ذلك إدارة الوصول وإدارة عناصر المعرف وغيرها. لمزيد من المعلومات، راجع تكامل Microsoft Entra المدار بواسطة AKS.

مسؤولياتك

المتطلبات	المسؤولية
المتطلب 8.1	قم بتحديد وتنفيذ النهج والإجراءات لضمان الإدارة السليمة لتعريف المستخدم للمستخدمين والمسؤولين غير المستهلكين على جميع مكونات النظام على النحو التالي:
المتطلب 8.2	بالإضافة إلى تعيين معرف فريد، تأكد من إدارة مصادقة المستخدم المناسبة للمستخدمين والمسؤولين غير المستهلكين على جميع مكونات النظام من خلال استخدام طريقة واحدة على الأقل من الطرق التالية لمصادقة جميع المستخدمين:
المتطلب 8.3	تأمين كل الوصول الإداري الفردي غير التابع لوحدة التحكم وكل الوصول عن بُعد إلى CDE باستخدام المصادقة متعددة العوامل.
المتطلب 8.4	قم بتوثيق إجراءات المصادقة وسياساتها وإجراءاتها وإبلاغ جميع المستخدمين بها، بما في ذلك:
المتطلب 8.5	لا تستخدم معرفات المجموعة أو المشتركة أو العامة أو كلمات المرور أو أساليب المصادقة الأخرى، كما يلي:
المتطلب 8.6	حيث يتم استخدام آليات مصادقة الأخرى (على سبيل المثال، رموز الأمان المادية أو المنطقية، والبطاقات الذكية، والشهادات، وما إلى ذلك)، يجب تعيين استخدام هذه الآليات، كما يلي:
المتطلب 8.7	يتم تقييد كل الوصول إلى أي قاعدة بيانات تحتوي على بيانات حامل البطاقة (بما في ذلك الوصول من قبل التطبيقات والمسؤولين وجميع المستخدمين الآخرين)، كما يلي:
المتطلب 8.8	تأكد من توثيق السياسات الأمنية والإجراءات التشغيلية لتحديد الهوية والمصادقة واستخدامها وإعلام جميع الأطراف المتأثرة بها.

المتطلب 8.1

قم بتحديد وتنفيذ النهج والإجراءات لضمان الإدارة السليمة لتعريف المستخدم للمستخدمين والمسؤولين غير المستهلكين على جميع مكونات النظام على النحو التالي:

• 8.1.1 قم بتعيين معرف فريد لجميع المستخدمين قبل السماح لهم بالوصول إلى مكونات النظام أو بيانات حامل البطاقة.
• 8.1.2 تحكم في إضافة معرفات المستخدم وبيانات الاعتماد وعناصر المعرف الأخرى واحذفها وعدلها.
• 8.1.3 قم بإبطال الوصول لأي مستخدمين منتهين على الفور.
• 8.1.4 قم بإزالة/ تعطيل حسابات المستخدمين غير النشطة في غضون 90 يومًا.
• 8.1.5 إدارة المعرفات المستخدمة من قبل جهات خارجية للوصول إلى مكونات النظام أو دعمها أو صيانتها عبر الوصول عن بعد على النحو التالي:
  • لا تقم بالتمكين إلا خلال الفترة الزمنية المطلوبة والمعطلة عندما لا تكون قيد الاستخدام.
  • راقب وقت الاستخدام.
• 8.1.6 قم بالحد من محاولات الوصول المتكررة عن طريق تأمين معرف المستخدم بعد ما لا يزيد عن ست محاولات.
• 8.1.7 عيِّن مدة التأمين إلى 30 دقيقة كحد أدنى أو حتى يقوم المسؤول بتمكين معرف المستخدم.
• 8.1.8 إذا كانت جلسة العمل خاملة لأكثر من 15 دقيقة، اطلب من المستخدم إعادة المصادقة لإعادة تنشيط المحطة الطرفية أو الجلسة.

مسؤولياتك

فيما يلي الاعتبارات العامة لهذا المطلب:

ينطبق على: 8.1.1، 8.1.2، 8.1.3

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

قم بتوسيع أساس الهوية هذا إلى تعيينات الهوية المُدارة في Azure. لا تشارك الهويات التي يديرها المستخدم عبر موارد Azure. عيِّن كل مورد Azure لهويته المُدارة الخاصة به. وبالمثل، عند استخدام هوية حمل عمل Microsoft Entra في مجموعة AKS، تأكد من أن كل مكون في حمل العمل الخاص بك يتلقى هويته الخاصة بدلا من استخدام هوية واسعة النطاق. لا تشارك أبدا نفس الهوية المدارة بين بيئات الإنتاج والبيئات غير الإنتاجية.

تعرف على المزيد حول خيارات الوصول والهوية لخدمة Azure Kubernetes (AKS).

ينطبق على: 8.1.2، 8.1.3، 8.1.4

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

ينطبق على: 8.1.5

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

يجب أن يكون لدى مؤسستك نمط واضح وموثق من المورد والوصول المماثل.

ينطبق على: 8.1.6، 8.1.7، 8.1.8

مسؤولياتك

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

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

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

المتطلب 8.2

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

• 8.2.1 باستخدام التشفير القوي، اعرض جميع بيانات اعتماد المصادقة (مثل كلمات المرور/العبارات) غير قابلة للقراءة أثناء الإرسال والتخزين على جميع مكونات النظام.
• 8.2.2 التحقق من هوية المستخدم قبل تعديل أي بيانات اعتماد مصادقة - على سبيل المثال، قم بإجراء إعادة تعيين كلمة المرور أو قم بتوفير رموز مميزة جديدة أو قم بإنشاء مفاتيح جديدة.
• 8.2.3 يجب أن تفي كلمات المرور/العبارات بالآتي:
  • تتطلب طولاً لا تقل عن سبعة أحرف.
  • تحتوي على كل من الأحرف الرقمية والهجائية.
• 8.2.4 قم بتغيير كلمات مرور المستخدم/ عبارات المرور مرة واحدة على الأقل كل 90 يومًا.
• 8.2.5 لا تسمح للفرد بإرسال كلمة مرور/ عبارة جديدة مماثلة لأي من كلمات المرور/ العبارات الأربعة الأخيرة التي استخدمها.
• 8.2.6 قم بتعيين كلمات المرور/ العبارات للاستخدام لأول مرة وعند إعادة التعيين إلى قيمة فريدة لكل مستخدم، وقم بتغييرها مباشرة بعد الاستخدام الأول.

مسؤولياتك

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

تتم معالجة العديد من مجموعة المتطلبات السابقة تلقائيا بواسطة معرف Microsoft Entra. إليك بعض الأمثلة:

• أمان كلمة المرور

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

  إشعار

  نوصي بشدة بأن تفكر في خيارات بدون كلمة مرور. لمزيد من المعلومات، راجع التخطيط لنشر مصادقة بدون كلمة مرور في معرف Microsoft Entra.

• التحقق من الهوية

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

قد يكون لديك مكونات لا تستخدم معرف Microsoft Entra، مثل الوصول إلى مربعات الانتقال باستخدام SSH. في مثل هذه الحالات، استخدم تشفير المفتاح العام بحجم مفتاح RSA 2048 على الأقل. حدد دائمًا عبارة مرور. لديك عملية تحقق من الصحة تتعقب المفاتيح العامة المعروفة المعتمدة. يجب ألا تتعرض الأنظمة التي تستخدم الوصول إلى المفتاح العام للإنترنت. بدلا من ذلك، يجب السماح بجميع الوصول إلى SSH فقط من خلال وسيط، مثل Azure Bastion، لتقليل تأثير تسرب المفتاح الخاص. تعطيل الوصول المباشر إلى كلمة المرور واستخدام حلاً بديلاً بدون كلمة مرور.

المتطلب 8.3

تأمين كل الوصول الإداري الفردي غير التابع لوحدة التحكم وكل الوصول عن بُعد إلى CDE باستخدام المصادقة متعددة العوامل. ملاحظة: تتطلب المصادقة متعددة العوامل استخدام اثنين على الأقل من أساليب المصادقة الثلاثة (راجع المتطلب 8.2 لوصف أساليب المصادقة) للمصادقة. لا يعتبر استخدام عامل واحد مرتين (على سبيل المثال، استخدام كلمتي مرور منفصلتين) مصادقة متعددة العوامل.

مسؤولياتك

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

هذا النهج يمكن زيادة تقويته باستخدام نُهج إضافية. إليك بعض الأمثلة:

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

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

• الوصول المشروط: طلب مصادقة متعددة العوامل (MFA) للمسؤولين
• الوصول المشروط: طلب أجهزة متوافقة
• الوصول المشروط: المصادقة متعددة العوامل المستندة إلى مخاطر تسجيل الدخول

المتطلب 8.4

قم بتوثيق إجراءات المصادقة وسياساتها وإجراءاتها وإبلاغ جميع المستخدمين بها، بما في ذلك:

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

مسؤولياتك

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

المتطلب 8.5

لا تستخدم معرفات المجموعة أو المشتركة أو العامة أو كلمات المرور أو أساليب المصادقة الأخرى، كما يلي:

• يتم تعطيل معرفات المستخدم العامة أو إزالتها.
• معرفات المستخدم المشتركة غير موجودة لإدارة النظام والوظائف الهامة الأخرى.
• لا يتم استخدام معرفات المستخدم المشتركة والعامة لإدارة أي مكونات للنظام.

مسؤولياتك

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

تعطيل مستخدمي الجذر في CDE. قم بتعطيل استخدام حسابات Kubernetes المحلية بحيث لا يمكن للمستخدمين استخدام الوصول المضمن --admin إلى المجموعات داخل CDE.

المتطلب 8.6

حيث يتم استخدام آليات مصادقة الأخرى (على سبيل المثال، رموز الأمان المادية أو المنطقية، والبطاقات الذكية، والشهادات، وما إلى ذلك)، يجب تعيين استخدام هذه الآليات، كما يلي:

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

مسؤولياتك

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

المتطلب 8.7

يتم تقييد كل الوصول إلى أي قاعدة بيانات تحتوي على بيانات حامل البطاقة (بما في ذلك الوصول من قبل التطبيقات والمسؤولين وجميع المستخدمين الآخرين)، كما يلي:

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

مسؤولياتك

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

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

المتطلب 8.8

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

مسؤولياتك

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

المتطلب 9 — تقييد الوصول الفعلي إلى بيانات حامل البطاقة

دعم ميزة AKS

لا توجد أي ميزات AKS قابلة للتطبيق لهذا المطلب.

مسؤولياتك

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

فيما يلي بعض الاقتراحات لتطبيق عناصر التحكم التقنية:

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

• اضبط نُهج الوصول المشروط لتقليل TTL على رموز الوصول المميزة لـ Azure من نقاط الوصول، مثل مدخل Microsoft Azure. للحصول على معلومات، راجع هذه المقالات:

  • تكوين نهج مدة بقاء جلسة العمل التكيفية
  • مدة بقاء الرمز المميز القابل للتكوين في النظام الأساسي للهويات في Microsoft

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

• قم بتقليل تصدير النسخ الاحتياطية CHD إلى الوجهات المحلية. استخدم الحلول المستضافة في Azure للحد من الوصول الفعلي إلى النسخ الاحتياطية.

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

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

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