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

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

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

تركز هذه البنية والتنفيذ على البنية الأساسية وليس حِمل العمل. توفر هذه المقالة اعتبارات عامة وأفضل الممارسات لمساعدتك في اتخاذ قرارات التصميم. اتبع المتطلبات الواردة في معيار PCI-DSS 3.2.1 الرسمي واستخدم هذه المقالة كمعلومات إضافية، عند الاقتضاء.

قم بحماية بيانات حامل البطاقة

المتطلب 3— حماية البيانات المخزنة لحامل البطاقة

مسؤولياتك

المتطلب 3.1

حافظ على تخزين بيانات حامل البطاقة عند الحد الأدنى من خلال تنفيذ نُهج وإجراءات وعمليات استبقاء البيانات والتخلص منها والتي تشمل على الأقل ما يلي لجميع تخزين بيانات حامل البطاقة (CHD):

• تحديد مقدار تخزين البيانات ووقت الاحتفاظ بالمقدار المطلوب للمتطلبات القانونية والتنظيمية والتجارية
• عمليات الحذف الآمن للبيانات عند عدم الحاجة إليها
• متطلبات الاحتفاظ المحددة لبيانات حامل البطاقة
• عملية ربع سنوية لتحديد بيانات حامل البطاقة المخزنة التي تتجاوز الاحتفاظ المحدد وحذفها بشكل آمن.

مسؤولياتك

لا تخزن الحالة في مجموعة AKS. إذا اخترت تخزين CHD، فاستكشف خيارات التخزين الآمنة. تتضمن الخيارات Azure Storage لتخزين الملفات أو قواعد البيانات مثل Azure SQL Database أو Azure Cosmos DB.

يجب التقيد الصارم بالإرشادات المعيارية حول نوع أمراض الشرايين التاجية التي يمكن تخزينها. حدد نُهج استبقاء البيانات بناءً على متطلبات عملك ونوع التخزين المستخدم. بعض الاعتبارات الرئيسية هي:

• كيف وأين يتم تخزين البيانات؟
• هل البيانات المخزنة مشفرة؟
• ما هي فترة الاستبقاء؟
• ما هي الإجراءات المسموح بها خلال فترة الاحتفاظ؟
• كيف يتم حذف البيانات المخزنة بعد انتهاء فترة الاحتفاظ؟

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

راجع قائمة تعريفات النهج هذه وطبقها على المجموعة، حيثما أمكن ذلك.

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

عندما تختار تقنية تخزين، استكشف ميزات الاحتفاظ. على سبيل المثال، يوفر Azure Blob Storage نُهج استبقاء تستند إلى الوقت. خيار آخر هو تنفيذ حل مخصص يحذف البيانات وفقاً لنُهج الاستبقاء. ومن الأمثلة على ذلك إدارة دورة حياة البيانات (DLM)، التي تدير أنشطة دورة حياة البيانات. تم تصميم الحل مع خدمات مثل Azure Data Factory ومعرف Microsoft Entra وAzure Key Vault.

لمزيد من المعلومات، راجع إدارة دورة حياة البيانات باستخدام Azure Data Factory.

المتطلب 3.2

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

مسؤولياتك

(ينطبق على: المتطلب 3.2.1، المتطلب 3.2.2، المتطلب 3.2.3)

تعد معالجة البيانات وحمايتها مصدر قلق لحمل العمل وتتجاوز نطاق هذه البنية. فيما يلي بعض الاعتبارات العامة.

وفقاً للمعيار، تتكون بيانات المصادقة الحساسة من بيانات المسار الكامل، وتعليمة برمجية أو قيمة التحقق من صحة البطاقة، وبيانات PIN. كجزء من معالجة CHD، تأكد من عدم عرض بيانات المصادقة في مصادر مثل:

• السجلات التي تنبعث من الكبسولات.
• إجراءات معالجة الاستثناءات.
• أسماء الملفات.
• تخزين.

كدليل عام، يجب على التجار عدم تخزين هذه المعلومات. إذا كان هناك حاجة إلى وثيقة مبرر العمل.

المتطلب 3.3

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

مسؤولياتك

يعتبر رقم الحساب الأساسي (PAN) بيانات حساسة، ويجب منع التعرض لهذه البيانات. إحدى الطرق هي تقليل الأرقام المعروضة من خلال التقنيع.

لا تنفذ إخفاء البيانات في حِمل العمل. بدلاً من ذلك، استخدم بنيات على مستوى قاعدة البيانات. يدعم خط خدمات Azure SQL، بما في ذلك Azure Synapse Analytics، إخفاء البيانات الديناميكي، ما يقلل من التعرض في طبقة التطبيق. إنها ميزة أمان مستندة إلى النهج تحدد من يمكنه عرض البيانات غير المقنعة ومقدار البيانات التي يتم كشفها من خلال التقنيع. تعرض طريقة إخفاء بطاقة الائتمان المضمنة آخر أربعة أرقام من الحقول المحددة وتضيف سلسلة ثابتة كبادئة في شكل بطاقة ائتمان.

لمزيد من المعلومات، راجع إخفاء البيانات الديناميكية.

إذا كنت بحاجة إلى إحضار بيانات غير مقنعة إلى مجموعتك، فقم بإخفاء القناع في أسرع وقت ممكن.

المتطلب 3.4

جعل PAN غير قابل للقراءة في أي مكان يتم تخزينه فيه (بما في ذلك الوسائط الرقمية المحمولة ووسائط النسخ الاحتياطي وفي السجلات) باستخدام أي من الأساليب التالية:

• تجزئة أحادية الاتجاه تعتمد على التشفير القوي، (يجب أن تكون التجزئة من PAN بالكامل)
• الاقتطاع (لا يمكن استخدام التجزئة لاستبدال المقطع المقتطع من PAN)
• الرموز المميزة والوسادات (يجب تخزين الوسادات بشكل آمن)
• تشفير قوي مع عمليات وإجراءات إدارة المفاتيح المرتبطة.

مسؤولياتك

لهذا المطلب، قد تحتاج إلى استخدام التشفير المباشر في حِمل العمل. توصي إرشادات PCI DSS باستخدام الخوارزميات التي تم اختبارها في الصناعة بحيث تصمد في وجه هجمات العالم الحقيقي. تجنب استخدام خوارزميات التشفير المخصصة.

كما تفي تقنيات إخفاء البيانات المناسبة بهذا المطلب. أنت مسؤول عن إخفاء جميع بيانات رقم الحساب الأساسي (PAN). يدعم خط خدمات Azure SQL، بما في ذلك Azure Synapse Analytics، إخفاء البيانات الديناميكي. راجع المتطلب 3.3.

تأكد من عدم كشف PAN كجزء من عمليات سير العمل. موضح فيما يلي بعض الاعتبارات:

• احتفظ بـ PAN خارج السجلات، وسجلات سير العمل وسجلات معالجة الاستثناءات (المتوقعة أو غير المتوقعة). أيضاً، يجب ألا تعرض تدفقات بيانات التشخيص، مثل رؤوس HTTP، هذه البيانات.

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

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

المتطلب 3.4.1

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

مسؤولياتك

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

يتم تشفير جميع البيانات المخزنة في Azure Storage وفك تشفيرها باستخدام تشفير قوي. تدير Microsoft المفاتيح المرتبطة. يُفضل استخدام مفاتيح التشفير المُدارة ذاتياً. قم دائماً بالتشفير خارج طبقة التخزين واكتب البيانات المشفرة فقط في وسيط التخزين، ما يضمن عدم تجاور المفاتيح أبداً مع طبقة التخزين.

باستخدام Azure Storage، يمكنك أيضاً استخدام المفاتيح المدارة ذاتياً. للحصول على تفاصيل، راجع المفاتيح المُدارة من قِبل العميل لتشفير Azure Storage.

تتوفر قدرات مماثلة لقواعد البيانات. بالنسبة لخيارات Azure SQL، راجع تشفير البيانات الشفافة في Azure SQL باستخدام المفتاح المُدار بواسطة العميل.

تأكد من تخزين المفاتيح في مخزن مفاتيح مدار مثل Azure Key Vault أو Azure Managed HSM أو حل إدارة مفاتيح تابع لجهة خارجية.

إذا كنت بحاجة إلى تخزين البيانات مؤقتاً، فقم بتمكين ميزة تشفير المضيف في AKS للتأكد من تشفير البيانات المخزنة على عقد VM.

المتطلب 3.5

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

مسؤولياتك

تم وصف هذه النقاط في الأقسام الفرعية:

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

المتطلب 3.5.1

متطلبات إضافية لمقدمي الخدمة فقط: الاحتفاظ بوصف موثق لبنيوية التشفير يتضمن:

• تفاصيل جميع الخوارزميات والبروتوكولات والمفاتيح المستخدمة لحماية بيانات حامل البطاقة، بما في ذلك قوة المفتاح وتاريخ انتهاء الصلاحية
• وصف استخدام المفتاح لكل مفتاح
• جرد أي HSMs وSCDs الأخرى المستخدمة لإدارة المفاتيح

مسؤولياتك

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

بشكل افتراضي، يستخدم Azure المفاتيح المُدارة من Microsoft لجميع البيانات المشفرة، لكل عميل. ومع ذلك، تدعم بعض الخدمات أيضاً المفاتيح ذاتية الإدارة للتشفير. إذا كنت تستخدم مفاتيح مُدارة ذاتياً للتشفير أثناء الراحة، فتأكد من حساب العملية والإستراتيجية التي تتعامل مع مهام إدارة المفاتيح.

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

المتطلب 3.5.2

قصر الوصول إلى مفاتيح التشفير على أقل عدد ضروري من الأمناء.

مسؤولياتك

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

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

المتطلب 3.5.3

تخزين المفاتيح السرية والخاصة المستخدمة لتشفير/فك تشفير بيانات حامل البطاقة في واحد (أو أكثر) من الأشكال التالية في جميع الأوقات:

• مشفر بمفتاح تشفير يكون على الأقل بنفس قوة مفتاح تشفير البيانات، ويتم تخزينه بشكل منفصل عن مفتاح تشفير البيانات
• داخل جهاز تشفير آمن (مثل وحدة أمان (مضيف) للأجهزة (HSM) أو جهاز نقطة تفاعل معتمد من PTS)
• كمكونين رئيسيين كاملين على الأقل أو مشاركات رئيسية، وفقاً لطريقة مقبولة في الصناعة

مسؤولياتك

سيحتاج حِمل العمل PCI-DSS 3.2.1 إلى استخدام أكثر من مفتاح تشفير واحد كجزء من إستراتيجية حماية البيانات في حال الثبات (عدم تنقلها). يتم استخدام مفتاح تشفير البيانات (DEK) لتشفير وفك تشفير CHD، لكنك مسؤول عن مفتاح تشفير مفتاح إضافي (KEK) لحماية هذا DEK. أنت مسؤول أيضاً عن ضمان تخزين KEK في جهاز تشفير.

يمكنك استخدام Azure Key Vault لتخزين DEK واستخدام Azure Dedicated HSM لتخزين KEK. للحصول على معلومات حول إدارة مفتاح HSM، راجع ما هو Azure المخصص HSM؟.

المتطلب 3.6

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

مسؤولياتك

(ينطبق على: المتطلب 3.6.1، المتطلب 3.6.2، المتطلب 3.6.3، المتطلب 3.2.4)

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

اتبع إرشادات NIST حول إدارة المفاتيح. للحصول على التفاصيل، راجع:

• إدارة مفاتيح التشفير.
• SP 800-133 Rev.2، توصية لإنشاء مفتاح التشفير
• SP 800-57 الجزء 1 Rev. 5، توصية لإدارة المفاتيح

راجع أيضاً Microsoft Defender for Key Vault.

المتطلب 3.6.7

منع الاستبدال غير المصرح به لمفاتيح التشفير.

مسؤولياتك

• تمكين التشخيص في جميع المخازن الرئيسية. استخدم Azure Monitor لـ Key Vault. يقوم بتجميع السجلات والقياسات وإرسالها إلى Azure Monitor. لمزيد من المعلومات، راجع مراقبة خدمة المخزن الرئيسي باستخدام Azure Monitor for Key Vault.
• امنح أذونات للقراءة فقط لجميع المستهلكين.
• ليس لديك أذونات دائمة لمستخدمي الإدارة أو الأساسيين. بدلاً من ذلك، استخدم تعيينات الأدوار في الوقت المناسب (JIT) وتنشيط الدور المستند إلى الوقت وتنشيط الدور المستند إلى الموافقة.
• إنشاء عرض مركزي من خلال دمج السجلات والتنبيهات في معلومات الأمان وحلول إدارة الأحداث (SIEM)، مثل Microsoft Azure Sentinel.
• اتخذ إجراءً بشأن التنبيهات والإشعارات، خاصةً فيما يتعلق بالتغييرات غير المتوقعة.

المتطلب 3.6.8

اشتراط أن يقر أمناء حفظ مفتاح التشفير رسمياً بأنهم يفهمون ويقبلون مسؤوليات الحافظ الرئيسي المنوطة بهم.

مسؤولياتك

احتفظ بالوثائق التي تصف مسؤوليات الأطراف المسؤولة في عمليات الإدارة الرئيسية.

المتطلب 3.7

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

مسؤولياتك

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

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

المتطلب 4 - تشفير نقل بيانات حامل البطاقة عبر الشبكات العامة المفتوحة

مسؤولياتك

المتطلب 4.1

استخدم بروتوكولات التشفير والأمان القوية (على سبيل المثال، TLS وIPSEC وSSH وما إلى ذلك.) لحماية بيانات حامل البطاقة الحساسة أثناء الإرسال عبر الشبكات العامة المفتوحة، بما في ذلك ما يلي:

مسؤولياتك

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

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

استخدم نهج Azure للتحكم في إنشاء الموارد:

• رفض إنشاء أي مورد دخول بخلاف HTTPS.
• رفض إنشاء أي عنوان IP عام أو أي موازين تحميل عامة في مجموعتك، لضمان مرور حركة مرور الويب عبر النفق عبر البوابة الخاصة بك.

لمزيد من المعلومات، راجع نظرة عامة على تشفير Azure.

المتطلب 4.1.1

تأكد من أن الشبكات اللاسلكية تنقل بيانات حامل البطاقة أو متصلة ببيئة بيانات حامل البطاقة، واستخدم أفضل ممارسات الصناعة (على سبيل المثال، IEEE 802.11i) لتنفيذ تشفير قوي للمصادقة والإرسال.

مسؤولياتك

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

المتطلب 4.2

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

مسؤولياتك

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

يجب أن يتم التحقق من الصحة على مستوى حِمل العمل وعملية التحكم في التغيير. يجب أن تفهم بوابات الموافقة المتطلبات.

بالنسبة للاعتبارات، راجع الإرشادات الواردة في معيار PCI-DSS 3.2.1 الرسمي.

المتطلب 4.3

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

مسؤولياتك

من المهم الاحتفاظ بوثائق شاملة حول العمليات والسياسات. هذا صحيح بشكل خاص عند إدارة النُهج المتعلقة بأمان طبقة النقل (TLS). فيما يلي بعض المجالات:

• نقاط دخول الإنترنت العامة. مثال على ذلك هو دعم Azure Application بوابة لأصفار TLS.
• قفزات الشبكة بين الشبكة المحيطة وأقراص حِمل العمل.
• تشفير pod إلى pod (إذا تم تنفيذه). يمكن أن يتضمن ذلك تفاصيل حول تكوين شبكة الخدمة.
• pod للتخزين (إذا كانت جزءاً من الهندسة البنيوية).
• Pod إلى الخدمات الخارجية أو خدمات Azure PaaS التي تستخدم TLS أو بوابة دفع أو نظام الكشف عن الاحتيال.

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

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

حماية جميع الأنظمة من البرامج الضارة وتحديث برامج أو برامج مكافحة الفيروسات بانتظام. تطوير وصيانة أنظمة وتطبيقات آمنة.