قد يُبلغ الخادم عن إيقاف وضع FIPS حتى بعد تثبيت مالكه لتحديثات الأمان أو اختياره لملف تعريف مُحسَّن. في نظام SUSE Linux Enterprise Server 15 SP7، تتمثل الطريقة الموثقة من SUSE في تثبيت دعم FIPS اللازم للنظام، ثم تشغيل الأمر fips-mode-setup --enable، وإعادة التشغيل، والتأكد من الحالة باستخدام الأمر fips-mode-setup --check. يُغيّر هذا الإعداد سياسة التشفير الخاصة بالنظام وتكوين بدء التشغيل؛ ولكنه لا يُثبت، بحد ذاته، أن عبء العمل أو نظام التشغيل بأكمله يفي بمتطلبات الامتثال.
مثال توضيحي: تخيل فريق عمليات افتراضيًا يُجهز خادم SLES 15 SP7 لخدمة داخلية تتطلب تشفيرًا معتمدًا من FIPS. يمتلك الفريق نافذة صيانة وإمكانية الوصول إلى وحدة التحكم، لكنه لا يعلم بعد ما إذا كان أحد العملاء القدامى يستخدم خوارزمية غير متوافقة. هذا سببٌ للتحقق من المتطلبات بدقة واختبار التبعيات قبل تغيير خادم الإنتاج، وليس دليلًا على عملية نشر أو اختبار حقيقية.
حدد أولاً حزمة الخدمة وبنية النظام. قد تختلف الأوامر والحزم المستخدمة بين حزم خدمة SLES 15، لذا لا تقم بنسخ إجراء من حزمة الخدمة 7 إلى حزم الخدمة 4 أو 5 أو 6 دون مراجعة وثائق SUSE الخاصة بتلك الإصدارات.
cat /etc/os-release
uname -mبالنسبة للخادم المذكور كمثال، يسجل الفريق إصدار SLES المُثبّت، ويتحقق من نافذة التغيير الخاصة به، ويتأكد من إمكانية استعادته عبر وحدة التحكم أو مسار الإدارة عن بُعد المعتمد في حال فشل إعادة التشغيل. قد يرفض معيار FIPS خوارزميات أو بروتوكولات التشفير التي لا يزال التطبيق يتوقعها. لذا، يُنصح بتخصيص وقت لفحص التطبيقات التي تستخدم TLS أو SSH أو مشاركة الملفات أو Java أو قواعد البيانات أو مكتبات التشفير الأخرى.
يرجى توضيح متطلبات المُقيِّم بدقة. ينطبق التحقق من صحة معيار FIPS 140-3 على وحدة تشفير ضمن تكوين مُحدد؛ فتفعيل وضع نظام التشغيل لا يعني التحقق من صحة كل وحدة أو تطبيق أو عملية نشر. يُشير دليل SUSE لنظام SLES 15 SP7 إلى أن SP7 لن يُقدَّم للحصول على شهادة NIST FIPS 140-3. تنشر SUSE معلومات منفصلة حول الوحدات والتكوينات المُعتمدة. إذا كان العقد يتطلب وحدة مُعتمدة مُحددة، فتأكد من الوحدة والإصدار وبيئة التشغيل والشهادة بدقة من خلال الرجوع إلى مواد اعتماد SUSE وسجل شهادات NIST CMVP قبل المتابعة.
توصي SUSE باختيار patterns-base-fipsالنمط المناسب للتثبيت الجديد. أما إذا كنت تُجري تغييرًا على نظام قيد التشغيل، فتحذر SUSE من أنه قد يلزم إجراء تعديلات إضافية، بما في ذلك إعادة إنشاء المفاتيح ومراجعة الإعداد. تعامل مع المضيف الحالي كتغيير مُتحكم فيه، وليس كعملية اعتماد تتم بأمر واحد.
تحقق مما إذا كانت أداة الإعداد موجودة:
command -v fips-mode-setup
rpm -q crypto-policies-scriptscrypto-policies-scriptsتوفر الحزمة بعض المكونات ، fips-mode-setupوقد لا تكون مثبتة. في حال عدم وجودها، قم بتثبيتها من مستودعات SLES المعتمدة للنظام.
sudo zypper install crypto-policies-scriptsإذا لم تكن معلومات الوصول إلى المستودع، أو توفر الحزم، أو حزم FIPS المطلوبة واضحة، فتوقف واستخدم قناة الدعم وإرشادات الاعتماد الخاصة بحزمة الخدمة لديك. لا تستخدم أمر مدونة قديمًا أو تُضف معلمات نواة منسوخة يدويًا من إصدار SLES مختلف. تستخدم تعليمات SUSE SP7 الحالية أداة الإعداد لتطبيق السياسة وتكوين عملية الإقلاع.
بمجرد إجراء النسخ الاحتياطي للمضيف وفقًا للسياسة المحلية، ومراجعة التبعيات، وتفعيل نافذة الصيانة، قم بتمكين الوضع التالي:
sudo fips-mode-setup --enableراجع مخرجات الأداة. تُوثّق SUSE أنها تُفعّل سياسة تشفير FIPS وتُشير إلى ضرورة إعادة التشغيل. تُعدّ إعادة التشغيل جزءًا من الإجراء لأنّ إعدادات initramfs و boot يجب أن تُعكس الوضع الجديد. لا تعتبر نجاح تنفيذ الأمر قبل إعادة التشغيل دليلًا على أنّ نواة النظام تعمل بالفعل في وضع FIPS.
أعد تشغيل الجهاز فقط بعد التأكد من تأثير الخدمة وإمكانية الوصول إلى وضع الاسترداد:
sudo systemctl rebootبالنسبة لفريق العمليات الافتراضي، يكون مالك التطبيق حاضرًا أثناء فترة التغيير، ويمكنه إجراء اختبارات التحقق المتفق عليها بعد عودة الخادم. إذا كان الخادم بعيدًا ولا يوجد مسار استعادة، فيجب أولًا إنشاء مسار استعادة أو تأجيل التغيير. قد تكشف قيود معيار FIPS عن تشفير غير مدعوم عند بدء التشغيل أو عند بدء تشغيل الخدمات.
بعد إعادة تشغيل النظام بالكامل، قم بتشغيل فحص حالة SUSE:
sudo fips-mode-setup --checkلضمان نجاح تهيئة حزمة الخدمة SP7، تُشير وثائق SUSE إلى تفعيل وضع FIPS، وتفعيل وحدة initramfs FIPS، وأن سياسة التشفير الحالية تستند إلى سياسة FIPS. قارن المخرجات الفعلية مع وثائق حزمة الخدمة المُثبّتة لديك؛ ولا تعتمد فقط على ملف التهيئة أو على اكتمال إعادة التشغيل.
يمكنك أيضًا الاستعلام عن حالة تفعيل الأداة المساعدة:
sudo fips-mode-setup --is-enabledتُوثّق SUSE هذا كفحص حالة ذي نتيجة غير صفرية عند تعطيل معيار FIPS أو عند عدم اتساق الوضع. استخدم حالة الخروج في التشغيل الآلي بدلاً من البحث في مخرجات غير مُنسّقة. ثم اختبر الخدمات ذات الصلة بالمتطلبات: المصادقة باستخدام طريقة SSH المعتمدة، وإنشاء اتصال TLS بنقطة نهاية نموذجية، وتشغيل فحوصات سلامة خاصة بالتطبيق. لا يُثبت كون الخدمة نشطة أنها تستخدم وحدة تشفير أو تكوينًا معتمدًا.
أحد أمثلة التوافق في دليل SUSE يتعلق بـ Samba/CIFS: في بيئة FIPS، استخدم مصادقة Kerberos لأن أوضاع مصادقة Samba الأخرى تتضمن MD5. طبق هذا التوجيه فقط إذا كان المضيف يوفر أو يستهلك خدمات Samba؛ وإلا فركز على البروتوكولات والمكتبات المشمولة فعليًا.
إذا --checkأشارت التقارير إلى عدم تفعيل معيار FIPS، فراجع مخرجات الأمر بالكامل وتأكد من إعادة التشغيل المطلوبة. تحقق من الإصدار ومجموعة الحزم المثبتة، ثم راجع دليل SUSE المطابق. إذا تم الإبلاغ عن تفعيل الوضع ولكن أحد التطبيقات يفشل، فافحص سجلات ذلك التطبيق وحدد الخوارزمية أو الوحدة التي يحاول استخدامها. استبدل التبعية أو أعد تهيئتها بخيار معتمد، أو احصل على استثناء موثق من مسؤول الامتثال.
لا تقم بالعودة إلى سياسة تشفير متساهلة لمجرد تشغيل عميل قديم مع الادعاء بأنه متوافق مع معيار FIPS. في حال الضرورة، استخدم إجراءات الإبلاغ عن الحوادث والموافقة المعتمدة في المؤسسة؛ sudo fips-mode-setup --disableراجع وثائق SUSE ثم أعد تشغيل النظام لتعطيل الوضع. أعد تقييم حالة الامتثال بعد أي عملية تراجع.
قبل إغلاق التغيير، احفظ بيانات تعريف حزمة الخدمة، ومعلومات الحزمة، ومخرجات الأوامر، وسجل إعادة التشغيل، ونتائج اختبار التطبيق في سجل تغييرات النظام. في السيناريو التوضيحي، تُمكّن هذه الأدلة الفريق من التمييز بين ثلاث حقائق منفصلة: يُشير المضيف إلى تفعيل وضع FIPS، ووظيفة الخدمات المقصودة، وتوافق وحدات التشفير المُختارة مع متطلبات الامتثال. ويُمكن للمُقيّم المسؤول فقط تحديد ما إذا كانت هذه الحقائق تُلبي الضوابط المُطبقة.
للاطلاع على الإجراءات المعتمدة والتحذيرات الخاصة بالإصدار، راجع دليل الأمان والتحصين الخاص بـ SUSE Linux Enterprise Server 15 SP7 ، ومعلومات شهادة SUSE FIPS ، وسجل برنامج التحقق من صحة وحدة التشفير NIST المعمول به .
اتبع إجراء SP7 الخاص بشركة SUSE لتمكين وضع FIPS، وأعد التشغيل بأمان، وتحقق من السياسة النشطة، وتحقق مما إذا كانت متطلبات الامتثال الخاصة بك تتطلب وحدات تم التحقق من صحتها.
قم بمقارنة YaST و cryptsetup لوحدة تخزين بيانات SLES مشفرة جديدة، واختر LUKS1 أو LUKS2، وتحقق من سلوك إلغاء القفل والتركيب بأمان.
قم بإعداد RMT على SLES 15، وقم بنسخ المستودعات المرخصة، وتحقق من تسجيل HTTPS والوصول إلى الحزم من عميل اختبار.
قم بتوصيل SLES 15 بـ AD باستخدام إدارة تسجيل الدخول المستندة إلى SSSD من YaST، ثم تحقق من البحث في الدليل، وتسجيل الدخول إلى المجال، وتذاكر Kerberos.
قم بإعداد مسار التصحيح المباشر الصحيح لنظام SLES 16.0 أو 15 SP7، وقم بتطبيق إصلاحات النواة المؤهلة، وتأكد من ما هو نشط دون الخلط بينه وبين تحديث النواة الذي يتطلب إعادة التشغيل.
يمكن ترقية نظام SLES 15 SP5 إلى SP6 عبر الإنترنت، ولكن يجب إعادة تشغيل كل عقدة. استخدم ترقية متدرجة مُختبرة أو عملية نقل تدريجية (أزرق-أخضر) للحفاظ على إمكانية الوصول إلى أحمال العمل.
قم بإنشاء وتحسين والتحقق من ملف تعريف AppArmor ذي أقل الامتيازات على SLES 15 SP7، مع ملاحظة واضحة حول SELinux الافتراضي في SLES 16.
استخدم ملف تعريف STIG المدعوم من SUSE لفحص SLES 15، واختبار المعالجة، ومراجعة النتائج المتبقية، والاحتفاظ بأدلة التقييم.
تتبع فشل اتصال Cockpit من خلال DNS، والمنفذ 9090، ومقبس systemd، وfirewalld، وTLS، وإعدادات تسجيل الدخول باستخدام إرشادات SUSE الحالية.
قم بإنشاء اتصال إيثرنت زائد على SLES 15 باستخدام YaST و Wicked، وقم بتكوين ربط النسخ الاحتياطي النشط، وتحقق من كلا المنفذين والتحويل التلقائي في حالة الفشل.
