Acasă
» Cum să
»
Aplicați SLES 15 STIG în siguranță cu OpenSCAP
Aplicați SLES 15 STIG în siguranță cu OpenSCAP
Folosește profilul DISA STIG acceptat de SUSE pentru SLES 15, scanează serverul cu OpenSCAP și remediază problema doar după ce analizezi linia de bază pe un sistem de testare. De exemplu, imaginează-ți un administrator fictiv pe nume Alex care pregătește un server SLES 15 pentru un serviciu reglementat: Alex folosește fluxul de lucru de mai jos pentru a identifica constatările, a testa modificările și a aduna dovezi, dar nu tratează o scanare automată curată ca o aprobare de conformitate.
Comenzile respectă îndrumările STIG actuale ale SUSE pentru SLES 15. Conținutul profilului se poate modifica odată cu actualizările pachetului și versiunile de benchmark DISA, așadar verificați versiunea aplicabilă și cerințele specifice sistemului înainte de a utiliza această procedură. Imaginile terminalului ilustrează comenzile și nu prezintă rezultatul real al scanării.
1. Confirmați ținta și criteriul de referință actual
Începeți prin a înregistra pachetul service pack SLES al gazdei, scopul, rolul de rețea și aplicațiile. Alex notează ce servicii trebuie să rămână disponibile, cum se conectează administratorii și metoda de recuperare dacă o modificare de securizare întrerupe accesul. Acest domeniu de aplicare este important: o gazdă de bază de date și un server de uz general pot avea excepții aprobate diferite, chiar și atunci când ambele utilizează același profil STIG al sistemului de operare.
Un terminal afișează comenzi pentru verificarea versiunii sistemului de operare și a identității gazdei înainte de lucrul cu STIG.
Verificați versiunea instalată înainte de a selecta conținut:
cat /etc/os-release
hostnamectl
Apoi, obțineți lista de verificare SLES 15 STIG aplicabilă și revizia benchmark-ului prin intermediul paginii oficiale de descărcări DISA STIG . Potriviți lista de verificare cu familia de sisteme și urmați instrucțiunile de evaluare ale organizației dvs. SUSE documentează suportul pentru profilul SCAP „DISA STIG pentru SUSE Linux Enterprise 15”, dar acest lucru în sine nu stabilește ce versiune necesită autoritatea dvs. sau nu certifică o gazdă.
2. Instalați și verificați conținutul SCAP
Pe un sistem SLES înregistrat cu acces la depozitele corespunzătoare, instalați utilitarele din linia de comandă OpenSCAP și conținutul Ghidului de securitate SCAP:
Vizualizare conceptuală a terminalului pentru comanda de instalare zypper; barele de progres generice nu reprezintă un rezultat verificat al instalării pachetului.
Numele pachetelor și locația fluxului de date SLES 15 de mai jos sunt documentate în ghidul de consolidare OpenSCAP de la SUSE și în procedura STIG de la SUSE . Depozitele de pachete și reviziile profilului pot diferi în funcție de service pack și nivelul de actualizare. Enumerați fluxurile de date instalate și inspectați fișierul candidat în loc să presupuneți un nume de fișier sau un profil:
Un terminal listează fluxul de date SLES 15 SCAP și verifică profilul său disponibil cu informații oscap.
ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml
Confirmați că fluxul de date SLES 15 este prezent și că lista de profiluri include stig. Dacă fișierul sau profilul lipsește, opriți și rezolvați nepotrivirea pachetului sau a depozitului; nu înlocuiți testul de performanță al unui alt sistem de operare.
3. Capturați o bază, apoi testați remedierea
Creați un director de dovezi protejat înainte de a genera rapoarte. Scanați mai întâi, fără a modifica setările de sistem:
Un terminal afișează comanda de evaluare OpenSCAP de bază cu căi de raport XML și HTML.
Deschideți raportul HTML și examinați fiecare rezultat, în special erorile, erorile și regulile care nu au putut fi verificate. Păstrați fișierul XML și raportați-l ca dovezi sensibile de configurare. Acestea pot dezvălui detalii despre gazdă și starea de securitate, așadar stocați-le sau transferați-le doar prin canale aprobate.
Apoi, clonați sau faceți o instantanee a serverului într-un mediu non-producție. Validați comportamentul aplicației, accesul prin identitate, rețeaua, monitorizarea și recuperarea înainte de a aplica modificări automate. SUSE avertizează administratorii să testeze mai întâi remedierea în afara producției, deoarece aceasta modifică configurația sistemului. Pe gazda de testare, metoda documentată din mers este:
Un terminal afișează comanda de remediere STIG care trebuie rulată mai întâi pe un sistem de testare izolat.
Rezultatul generat poate include un rezultat al testului pre-remediere și un test post-remediere. O regulă marcată fixedindică faptul că a fost aplicată corecția automată și că regula a trecut evaluarea respectivă; errorînseamnă că remedierea a eșuat pentru regula respectivă. Niciuna dintre stări nu înlocuiește testarea operațională sau revizuirea cerinței subiacente.
4. Re-scanare, rezolvare excepții și păstrare dovezi
După examinarea comportamentului testului, rulați o scanare separată cu căi de ieșire noi. O evaluare bazată doar pe scanare ajută la distingerea stării curente de rularea remedierii:
Un terminal afișează comanda de scanare pentru generarea unui rezultat XML proaspăt și a unui raport HTML după remediere.
Nu vă așteptați ca fiecare regulă să fie remediabilă automat. Investigați erorile în raport cu textul complet de verificare și remediere al regulii, în versiunea exactă a listei de verificare DISA selectată pentru sistem. Unele reguli necesită o decizie deliberată a proprietarului serviciului, o configurație specifică amplasamentului sau dovezi manuale. Dacă o regulă nu este aplicabilă sau nu poate fi îndeplinită, documentați justificarea și controalele compensatorii prin procesul formal de excepții al organizației; modificarea sau adaptarea unui profil nu determină în sine îndeplinirea unei cerințe.
Pentru revizuirea listei de verificare, SUSE documentează exportul unui fișier XCCDF care poate fi importat în DISA STIG Viewer. Generați-l cu opțiunea acceptată și apoi importați-l în Viewer conform instrucțiunilor actuale pentru utilizator:
Un terminal afișează opțiunea oscap pentru exportarea unui rezultat XCCDF pentru revizuire în DISA STIG Viewer.
Pachetul de dovezi al lui Alex pentru serverul fictiv înregistrează identitatea gazdei și a service-pack-ului, revizia benchmark-ului, versiunea conținutului SCAP, data scanării, rapoartele de referință și finale, acțiunile de remediere, verificările manuale și excepțiile aprobate. Confirmați că fișierele există și rămân lizibile numai pentru recenzorii autorizați:
Un terminal afișează o comandă pentru verificarea prezenței fișierelor cu dovezi de scanare așteptate; nu se afișează nicio ieșire a fișierului.
sudo ls -l /root/stig-review
Înainte de a declara sarcina finalizată, verificați dacă raportul final reflectă o scanare efectuată după modificări, dacă fiecare constatare rămasă are un proprietar și o dispoziție și dacă serviciile necesare ale serverului funcționează în continuare. Conformitatea STIG este o stare evaluată legată de un anumit criteriu de referință și de domeniul de aplicare al sistemului; OpenSCAP acceptă această evaluare, dar nu acordă acreditare și nu garantează că fiecare cerință a site-ului a fost îndeplinită.