Un server poate raporta că modul FIPS este dezactivat chiar și atunci când proprietarul său a instalat actualizări de securitate sau a selectat un profil securizat. Pe SUSE Linux Enterprise Server 15 SP7, metoda documentată de SUSE este de a instala suportul FIPS necesar pentru sistem, de a rula fips-mode-setup --enable, de a reporni și de a confirma starea cu fips-mode-setup --check. Setarea modifică politica criptografică a sistemului și configurația de bootare; nu dovedește, în sine, că o sarcină de lucru sau întregul sistem de operare îndeplinește o cerință de conformitate.
Exemplu ilustrativ: Imaginați-vă o echipă operațională fictivă care pregătește un server SLES 15 SP7 pentru un serviciu intern care necesită criptografie aprobată de FIPS. Echipa are o fereastră de mentenanță și acces la consolă, dar nu știe încă dacă un client vechi utilizează un algoritm incompatibil. Acesta este un motiv pentru a verifica cerințele exacte și a testa dependențele înainte de a schimba gazda de producție - nu o dovadă a unei implementări sau a unui test real.
Mai întâi identificați pachetul service pack și arhitectura. Comenzile și pachetele exacte pot diferi între pachetele service pack-uri SLES 15, așadar nu copiați o procedură SP7 în SP4, SP5 sau SP6 fără a verifica documentația SUSE a versiunii respective.
cat /etc/os-release
uname -mPentru serverul exemplu, echipa înregistrează versiunea SLES instalată, verifică fereastra de modificare a acesteia și confirmă că se poate recupera printr-o consolă sau o cale de gestionare la distanță aprobată dacă o repornire eșuează. FIPS poate respinge algoritmi sau protocoale criptografice pe care o aplicație le așteaptă încă. Programați timp pentru a verifica aplicațiile care utilizează TLS, SSH, partajarea de fișiere, Java, baze de date sau alte biblioteci criptografice.
De asemenea, clarificați ce necesită de fapt evaluatorul. Validarea FIPS 140-3 se aplică unui modul criptografic într-o configurație definită; activarea unui mod de sistem de operare nu este același lucru cu validarea fiecărui modul, aplicație sau implementare. Ghidul SLES 15 SP7 de la SUSE precizează că SP7 nu va fi trimis pentru certificarea NIST FIPS 140-3. SUSE publică separat informații despre modulele și configurațiile validate. Dacă un contract necesită un anumit modul validat, confirmați exact modulul, versiunea, mediul de operare și certificatul în raport cu materialul de certificare SUSE și cu înregistrarea certificatului NIST CMVP înainte de a continua.
SUSE recomandă selectarea patterns-base-fipsmodelului pentru o instalare nouă. Dacă modificați un sistem care rulează, SUSE avertizează că pot fi necesare ajustări suplimentare, inclusiv regenerarea cheilor și auditarea configurării. Tratați o gazdă existentă ca pe o modificare controlată, nu ca pe o certificare cu o singură comandă.
Verificați dacă utilitarul de configurare este prezent:
command -v fips-mode-setup
rpm -q crypto-policies-scriptsPachetul crypto-policies-scriptsfurnizează fips-mode-setupși este posibil să nu fie instalat. Dacă lipsește, instalați-l din depozitele SLES autorizate ale sistemului:
sudo zypper install crypto-policies-scriptsDacă accesul la depozit, disponibilitatea pachetelor sau pachetele FIPS necesare sunt neclare, opriți procesul și utilizați canalul de asistență și îndrumările de certificare pentru pachetul service pack exact. Nu înlocuiți o comandă blog veche și nu adăugați manual un parametru de kernel copiat dintr-o altă versiune SLES. Instrucțiunile actuale ale SP7 ale SUSE utilizează utilitarul de configurare pentru a aplica politica și a configura procesul de bootare.
După ce gazda este copiată de rezervă conform politicii locale, dependențele au fost revizuite și fereastra de întreținere este activă, activați modul:
sudo fips-mode-setup --enableExaminați rezultatul utilitarului. SUSE documentează faptul că a setat politica de criptare FIPS și raportează că este necesară o repornire. Repornirea face parte din procedură, deoarece initramfs și configurația de boot trebuie să reflecte noul mod. Nu considerați comanda care returnează cu succes înainte de repornire ca dovadă că kernelul care rulează funcționează deja în modul FIPS.
Reporniți doar după ce ați confirmat impactul asupra serviciilor și accesul la recuperare:
sudo systemctl rebootPentru echipa de operațiuni fictivă, proprietarul aplicației este prezent în timpul ferestrei de modificare și poate rula testele de tip „fume test” convenite după ce serverul revine. Dacă serverul este la distanță și nu există o cale de recuperare, stabiliți mai întâi una sau amânați modificarea. Restricțiile FIPS pot expune criptografia neacceptată la pornire sau la pornirea serviciilor.
După ce sistemul a repornit complet, rulați verificarea stării SUSE:
sudo fips-mode-setup --checkPentru o configurare SP7 reușită, SUSE documentează ieșirea care declară că modul FIPS este activat, modulul FIPS initramfs este activat și politica criptografică curentă se bazează pe politica FIPS. Comparați ieșirea reală cu documentația pachetului service pack instalat; nu vă bazați doar pe un fișier de configurare sau pe faptul că repornirea s-a finalizat.
De asemenea, puteți interoga starea de activare a utilitarului:
sudo fips-mode-setup --is-enabledSUSE documentează acest lucru ca o verificare a stării cu un rezultat diferit de zero atunci când FIPS este dezactivat sau când modul este inconsistent. Folosiți starea de ieșire în automatizare, în loc să căutați ieșiri formatate liber. Apoi testați serviciile relevante pentru cerință: autentificați-vă cu metoda SSH aprobată, stabiliți o conexiune TLS la un punct final reprezentativ și executați verificări de stare specifice aplicației. Un serviciu activ nu stabilește că utilizează un modul sau o configurație criptografică aprobată.
Un exemplu de compatibilitate din ghidul SUSE se referă la Samba/CIFS: într-un mediu FIPS, utilizați autentificarea Kerberos deoarece celelalte moduri de autentificare Samba includ MD5. Aplicați aceste îndrumări numai dacă gazda furnizează sau consumă servicii Samba; în caz contrar, concentrați-vă pe protocoalele și bibliotecile care sunt efectiv incluse în domeniul de aplicare.
Dacă --checkse raportează că FIPS nu este activat, examinați ieșirea completă a comenzii și confirmați că a avut loc repornirea necesară. Verificați versiunea instalată și setul de pachete, apoi consultați ghidul SUSE corespunzător. Dacă modul este raportat ca activat, dar o aplicație eșuează, inspectați jurnalele aplicației respective și identificați algoritmul sau modulul pe care încearcă să îl utilizeze. Înlocuiți sau reconfigurați dependența cu o opțiune aprobată sau obțineți o excepție documentată de la proprietarul conformității.
Nu reveniți la o politică cripto permisivă doar pentru a face un client vechi să funcționeze în timp ce revendică funcționarea FIPS. Dacă este necesară o revenire la sistemul anterior, utilizați procesul de incidente și aprobare al organizației; documentele SUSE sudo fips-mode-setup --disableurmate de o repornire pentru a dezactiva modul. Reevaluați starea de conformitate după orice revenire la sistemul anterior.
Înainte de a închide modificarea, salvați identificarea pachetului service pack, informațiile despre pachet, ieșirea comenzii, înregistrarea de repornire și rezultatele testelor aplicației în înregistrarea modificărilor sistemului. În scenariul ilustrativ, aceste dovezi permit echipei să distingă trei fapte separate: gazda raportează modul FIPS activat, funcția de servicii dorită și modulele criptografice selectate corespund cerinței de conformitate. Doar evaluatorul responsabil poate decide dacă aceste fapte îndeplinesc controlul aplicabil.
Pentru procedura autorizată și avertismentele specifice versiunii, consultați Ghidul de securitate și consolidare SUSE Linux Enterprise Server 15 SP7 , informațiile despre certificarea SUSE FIPS și înregistrarea Programului de validare a modulelor criptografice NIST aplicabilă .
Urmați procedura SP7 a SUSE pentru a activa modul FIPS, reporniți în siguranță, verificați politica activă și verificați dacă cerința de conformitate necesită module validate.
Comparați YaST și cryptsetup pentru un nou volum de date SLES criptat, alegeți LUKS1 sau LUKS2 și verificați comportamentul de deblocare și montare în siguranță.
Configurați RMT pe SLES 15, oglindiți repozitoriile autorizate și verificați înregistrarea HTTPS și accesul la pachet de la un client de testare.
Conectați SLES 15 la AD cu ajutorul gestionării logon-ului bazate pe SSSD din YaST, apoi verificați căutarea în directoare, conectarea la domeniu și tichetele Kerberos.
Configurați calea corectă pentru Live Patching pentru SLES 16.0 sau 15 SP7, aplicați corecțiile eligibile ale kernelului și confirmați ce este activ fără a-l confunda cu o actualizare a kernelului care necesită repornire.
SLES 15 SP5 poate migra online la SP6, dar fiecare nod trebuie să repornească. Folosiți o actualizare continuă testată sau o trecere de la un sistem blue-green la altul pentru a menține accesibile sarcinile de lucru.
Creați, rafinați și verificați un profil AppArmor cu privilegii minime pe SLES 15 SP7, cu o notă clară privind setările implicite SELinux pentru SLES 16.
Folosește profilul STIG acceptat de SUSE pentru a scana SLES 15, a testa remedierea, a revizui constatările rămase și a păstra dovezile evaluării.
Urmăriți o conexiune Cockpit eșuată prin DNS, portul 9090, socketul systemd, firewalld, TLS și setările de conectare folosind instrucțiunile SUSE actuale.
Creați o conexiune Ethernet redundantă pe SLES 15 cu YaST și Wicked, configurați legătura activă de backup și verificați ambele porturi și failover-ul.
