Windows ir Linux saugos konfigūracijos stiprinimas prasideda nuo sistemos paskirties. Išjunkite nereikalingas funkcijas, ribokite privilegijas ir valdykite pakeitimus, tačiau prieš diegdami griežtesnį profilį patikrinkite, ar jis nesustabdo būtinos paslaugos. Saugos bazė turi būti įgyvendinama ir patikrinama.
Šis planas skirtas turimų ir teisėtai administruojamų sistemų peržiūrai. Jį susiekite su informacijos saugumo politika, autentifikavimo taisyklėmis ir saugumo žurnalų kontrole. Čia nepateikiamas vienodas komandų rinkinys visoms operacinių sistemų versijoms.
Užfiksuokite esamą būseną
Inventoriuje nurodykite operacinę sistemą, versiją, vaidmenį, savininką, tinklo pasiekiamumą ir palaikymo būseną. Serveris, prieinamas internetu, ir izoliuota darbo stotis turi skirtingas grėsmes. Įvertinkite ir administravimo priemones: bendrą paskyrų katalogą, nuotolinę prieigą, automatines diegimo sistemas.
Patvirtinkite, kokiu techniniu etalonu remsitės. Gamintojo saugos bazė ir nepriklausomos agentūros gairės gali būti naudingos, bet jų versijos ir taikymo prielaidos skiriasi. Sprendime įrašykite dokumento versiją bei datą. Senas kontrolinis sąrašas neturėtų būti laikomas aktualiu vien todėl, kad dokumento pavadinime yra „Windows“ ar „Linux“.
Priemonių darbo lapas
| Sritis | Tikrinamas sprendimas | Priėmimo įrodymas |
|---|---|---|
| Vietinės teisės | Ar kasdienis naudotojas turi nepagrįstų administratoriaus teisių? | Paskyrų ir grupių peržiūra |
| Nuotolinis administravimas | Ar pasiekiamas tik leidžiamu keliu? | Tinklo ir prisijungimo patikra |
| Paslaugos | Ar įjungtos tik reikalingos funkcijos? | Paslaugų sąrašas su paskirties paaiškinimu |
| Atnaujinimai | Kas vertina, diegia ir tikrina pataisas? | Diegimo rezultatas ir išimtys |
| Programų vykdymas | Kaip ribojamas nepatvirtintas kodas? | Leidžiamos bei draudžiamos programos bandymas |
| Žurnalai | Ar jautrūs veiksmai pasiekia stebėjimo vietą? | Kontrolinis įvykis |
| Atkūrimas | Ar galima grįžti po nesėkmingo pakeitimo? | Atkūrimo scenarijaus patikra |
Microsoft saugos bazių dokumentacija aprašo gamintojo rekomenduojamų nustatymų paskirtį. ANSSI GNU/Linux saugos rekomendacijos yra atskiras techninis šaltinis. Šie dokumentai nėra savaiminis Lietuvos teisės normų rinkinys.
Įdiekite pakeitimus etapais
Pirmiausia parinkite reprezentatyvią, kontroliuojamą aplinką. Užrašykite būtinus verslo veiksmus ir patikrinkite juos prieš pakeitimą. Tada įdiekite vieną susijusią nustatymų grupę ir pakartokite patikrą. Taip bus aiškiau, kuri priemonė sukėlė nesuderinamumą.
Nesėkmės atveju neišjunkite visos bazės. Nustatykite konkretų parametrą, techninę priklausomybę ir galimą alternatyvą. Išimtyje įrašykite riziką, kompensuojančią priemonę, savininką ir pabaigos datą. Išimties priežastis „kitaip neveikia“ turi būti papildyta patikrinamu faktu.
Windows ir Linux skirtumai
Windows aplinkoje svarbu suprasti, kurios taisyklės ateina iš centralizuoto valdymo ir kurios liko vietinės. Patikrinkite, ar bendrojo katalogo politika realiai pasiekia įrenginius ir ar tiekėjų paskyros neapeina numatytos prieigos. Darbo stočių bei serverių taisyklės gali pagrįstai skirtis.
Linux aplinkoje įvertinkite administravimo teisių suteikimą, tarnybų paskyras, paketų šaltinius, failų teises ir prieigos kontrolės mechanizmus. Nustatymo failo pakeitimas dar neįrodo, kad tarnyba jį pritaikė. Reikalingas faktinės būsenos ir būtinos funkcijos patikrinimas.
Priėmimas ir tęstinė kontrolė
Prieš platesnį diegimą pasiruoškite IT atkūrimo veiksmus. Patikrinkite, ar liko saugus administravimo kelias ir ar atkūrimo duomenys prieinami tinkamiems žmonėms. Įjungta apsauga, kuri neleidžia valdyti incidento, gali sukelti papildomą paslaugos prieinamumo problemą.
Po diegimo stebėkite konfigūracijos nukrypimus ir atnaujinimų klaidas. Saugumo audito užduotyje apibrėžkite, kokią imtį ir įrodymus tikrins peržiūrėtojas. Baigtas rezultatas: patvirtinta bazė, faktiškai pritaikytų nustatymų įrodymas, išimtys ir grįžimo planas.
Kaip sudaryti saugos bazės pakeitimų lentelę
Kiekvieną pasirinktą nustatymą susiekite su grėsme, tikėtinu poveikiu sistemai ir tikrinimo būdu. Lentelėje nurodykite dabartinę būseną, norimą būseną, šaltinio versiją, vykdytoją ir grįžimo veiksmą. Toks formatas leidžia atskirti sąmoningą sprendimą nuo atsitiktinio parametro pakeitimo ir padeda kitam administratoriui suprasti jo priežastį.
Pavyzdžiui, išorinio administravimo ribojimas turi nurodyti, kokiu patvirtintu keliu prieiga bus teikiama ir kas pasikeis tiekėjo darbui. Jei tik uždrausite seną kelią neparengę naujo, darbuotojai gali sukurti nevaldomą alternatyvą. Pakeitimo priėmimas turi patikrinti ir neleistinos prieigos blokavimą, ir reikiamos užduoties atlikimą leidžiamu būdu.
Nustatymo atitikimą matuokite faktinėje sistemoje. Centralizuoto valdymo konsolėje matoma politika gali dar nebūti pasiekusi neprisijungusio įrenginio. Nurodykite, kaip tikrinate galutinę būseną ir ką darysite su įrenginiais, kuriems taisyklės nepritaikytos. Neprijungta darbo stotis negali būti laikoma apsaugota vien dėl priskyrimo tinkamai grupei.
Privilegijuotos paskyros ir kasdienis darbas
Atskirkite naudotojo paskyrą nuo administravimo paskyros. Tai sumažina situacijų, kai įprastas naršymas ar gautas dokumentas vykdomas su pernelyg plačiomis teisėmis. Kiekvienai administravimo paskyrai nurodykite savininką, paskirtį ir leidžiamus prisijungimo kelius. Bendros paskyros turi turėti dokumentuotą būtinybę ir veiksmų atsekamumo sprendimą.
Patikrinkite vietines administratorių grupes, senas tiekėjų paskyras ir paslaugoms suteiktas teises. Organizacijos katalogo peržiūra gali nepastebėti vietinio vartotojo, sukurto ankstesniam diegimui. Po projekto ar tiekėjo darbų užbaigimo patikrinkite, ar papildomos teisės ir laikinos taisyklės panaikintos. Šis veiksmas turėtų būti įtrauktas į darbų priėmimą.
Kai privilegija reikalinga tik konkrečiai užduočiai, įvertinkite ribotą ar laikiną suteikimą pagal sistemos galimybes. Nepaverskite jo papildoma nevaldoma programa: svarbu, kad prašymas, patvirtinimas ir faktinis panaudojimas būtų susieti. Veiksmų peržiūrai reikia prieigos prie tinkamų žurnalų, o ne vien žinoti, kad privilegija kažkada suteikta.
Pataisų diegimo prioritetai
Pataisų planą sudarykite pagal pažeidžiamumo svarbą, realų pasiekiamumą, išnaudojimo informaciją ir sistemos reikšmę. Bendras tiekėjo klasifikavimas yra vienas vertinimo elementas. Kritinis trūkumas izoliuotame bandymo įrenginyje ir ta pati spraga internetui atviroje tapatybės sistemoje gali reikalauti skirtingos reakcijos.
Nenustatykite tariamai universalaus teisinio termino vien iš techninio kontrolinio sąrašo. Jei organizacijai taikomas konkretus sektoriaus ar sutartinis reikalavimas, įrašykite jį atskirai su šaltiniu. Vidaus terminams nurodykite eskalavimą, kai diegimas negalimas, ir laikiną rizikos mažinimo priemonę. Neištaisytas trūkumas turi turėti savininką.
Patikrinkite diegimo rezultatą ir būtinas funkcijas. Sėkminga įrankio būsena ne visada reiškia, kad reikiamas komponentas perkrautas arba versija faktiškai pakeista. Po atnaujinimo patvirtinkite, kad sistema veikia, žurnalai renkami ir svarbūs nustatymai nenukrypo. Nesėkmingus atvejus grąžinkite į valdomą darbų sąrašą.
Hipotetinis senos apskaitos programos atvejis
Saugos bazė riboja seną ryšio būdą, kurį dar naudoja apskaitos programa. Verslo komanda negali iš karto jos pakeisti, nes priklauso nuo mėnesio uždarymo. Vietoje bendro bazės išjungimo komanda nustato konkrečią priklausomybę ir įvertina atskirtą prieigos kelią, tinklo ribojimą bei tiekėjo atnaujinimo planą.
Išimties byloje užrašoma paveikta sistema, reikalinga funkcija, alternatyvų vertinimas, laikinos priemonės ir sprendimą tvirtinantis asmuo. Paskiriama peržiūros data, susieta su tiekėjo galimybe atnaujinti programą. Tiekėjo pažadas „vėliau sutvarkysime“ nėra patikrinamas pabaigos kriterijus, todėl reikia aiškaus rezultato ir plano, jei jis nebus pasiektas.
Laikina išimtis neturi išplisti į visas darbo vietas. Patikrinkite, kad ji taikoma tik reikiamai grupei ar srautui. Pasibaigus poreikiui pašalinkite susijusias taisykles ir atlikite pakartotinę patikrą. Taip organizacija gali palaikyti būtiną veiklą kartu aiškiai valdydama likusią riziką.
Automatizavimas ir konfigūracijos pokyčiai
Konfigūracijos automatizavimas padeda nuosekliai taikyti taisykles, tačiau klaida gali būti greitai išplatinta dideliu mastu. Pakeitimus peržiūrėkite, pradėkite nuo ribotos grupės ir stebėkite rezultatą. Automatiniame scenarijuje neturi būti paslapčių, kurios paskui patektų į versijų istoriją ar bendrus vykdymo žurnalus.
Numatykite nukrypimų aptikimą: darbuotojas, diegimo programa ar tiekėjas gali pakeisti saugos nustatymą po pirminio priėmimo. Nukrypimo pranešime turi būti pakankamai informacijos nustatyti savininką ir reikšmę. Automatinis grąžinimas į bazę tinkamas tik tada, kai žinomas jo poveikis ir neapeinamos patvirtintos išimtys.
Galutinėje ataskaitoje pateikite taikytą apimtį, sėkmingai patikrintų sistemų dalį, nepatikrintas sistemas ir išimtis. Išvada „sistema sustiprinta“ turi remtis atliktu darbu. Kartu išsaugokite pasirinktos bazės versiją, kad kitą kartą būtų galima palyginti tikruosius pakeitimus ir nepakartoti jau atlikto vertinimo.
Tinklo ribų ir administravimo kelio priėmimas
Prieš uždarydami darbą patikrinkite, iš kokių vietų galima pasiekti administravimo sąsają. Taikykite tik organizacijos leistą patikros apimtį ir naudokite paskirtus bandomuosius prisijungimus. Nereikia atlikti neįgaliotų bandymų svetimose sistemose, kad įrodytumėte savo nustatymų tinkamumą. Tiekėjo valdomoje aplinkoje suderinkite, kokį įrodymą jis gali pateikti.
Palyginkite numatytą ir faktinį kelią: leidžiamą tinklą, autentifikavimą, paskyros vaidmenį ir sesijos registravimą. Jei egzistuoja alternatyvus senas prisijungimas, patikrinkite, ar jis panaikintas arba aiškiai įtrauktas į išimčių sąrašą. Vieno saugaus kelio įdiegimas nepašalina seno nevaldomo kelio.
Užrašykite bandymo datą, sistemą, rezultatą ir ribas. Jei patikra apėmė tik vieną darbo vietą, neapibendrinkite jos visai organizacijai be pagrindo. Platesnio diegimo metu reikia nustatyti, kaip patvirtinama kitų įrenginių būsena ir kaip tvarkomi tie, kurie buvo neprisijungę arba nepalaiko pasirinktos bazės.