Kas yra saugumo architektūra?
Kaip išdėstytas sistemos saugumas: dalys, ribos tarp jų ir sprendimai, kurie galioja, kai kas nors nutinka ne taip.
Trumpas apibrėžimas
Saugumo architektūra – tai sistemos saugumo užtikrinimo būdas. Ji apima, kurios dalys egzistuoja, kur yra ribos tarp jų, kuo pasitikima, kuo ne ir kas nutinka, kai viena dalis sugenda. Tai struktūros ir tikslo aprašymas, o ne produktas, kurį diegiate.
Naudingas būdas patikrinti, ar turite tokią architektūrą: pasirinkite sistemą ir paklauskite, iš kur jos duomenys patenka, iš kur jie išeina, kas gali ją pasiekti neautentifikuodamasis ir ką užpuolikas pasiektų perėmęs bet kurį komponentą. Jei šie atsakymai yra pateikti raštu ir žmonės dėl jų sutaria, turite saugumo architektūrą. Jei kiekvienas atsakymas priklauso nuo to, ko klausiate, turite kontrolės priemonių rinkinį.
Saugumo architektūra ir IT architektūra
IT architektūra apibūdina, kaip sistema sukonstruota, kad atliktų savo darbą. Saugumo architektūra apibūdina tą pačią sistemą iš to požiūrio taško, kas neturėtų vykti. Tai yra vienos sistemos, o ne dviejų atskirų projektų, vaizdai, todėl saugumo architektūros darbai paprastai pradedami nuo IT architektūros, kurios niekas neužrašė, rekonstrukcijos.
Loginis, fizinis ir žodžiai tarp jų
Ta pati sistema aprašoma skirtingais lygmenimis, o terminai visoje pramonės šakoje vartojami laisvai. Praktiškai verta atskirti tris:
- Loginis: komponentai, pasitikėjimo ribos ir duomenų srautai, nepriklausomi nuo to, kur viskas veikia. Tai yra lygmuo, kuriame iš tikrųjų priimami dauguma saugumo sprendimų.
- Fizinis arba diegimo: kompiuteriai, tinklai, debesijos paskyros ir regionai, kuriuose veikia šie komponentai. Čia logiškas sprendimas arba galioja, arba tyliai negalioja.
- Veikimo lygmuo: kas turi kokią prieigą, kaip tvirtinami pakeitimai ir kaip sistema stebima bei atkuriama. Architektūra, kuri ignoruoja šį lygį, dažniausiai apibūdina sistemą, kurios niekas nenaudoja.
Formalūs modeliai, tokie kaip SABSA, TOGAF saugumo peržiūros arba ISO/IEC 27001 A priede pateikti sluoksniuoti aprašymai, suteikia tam žodyną. Jie naudingi aprašymui organizuoti ir nepakeičia savo priklausomybių žinojimo.
Kas yra saugumo architektūros apžvalga?
Apžvalgos metu nagrinėjama esama sistema ir pateikiama ataskaita apie jos struktūros reikšmę saugumui. Tai yra projekto vertinimas, o ne veikiančių mašinų skenavimas. Skverbties testo metu klausiama: „ar galiu patekti šiuo konkrečiu keliu?“; architektūros apžvalgos metu klausiama: „ką pasiektų patekimas bet kur ir ar tai buvo numatyta?“
Peržiūra paprastai pateikia šiuos rezultatus:
- Dabartinės būsenos aprašymas: komponentai, duomenų srautai, pasitikėjimo ribos ir išorinės priklausomybės, pateikta forma, kurią jūsų komanda atpažįsta kaip tikslią.
- Sprendimai, kurie yra laikantys naštą, įskaitant tuos, kurie niekada nebuvo užrašyti, ir tuos, kurie nebeatitinka sistemos veikimo principo.
- Kai viena nesėkmė ar kompromisas išplinta toliau, nei kas nors manė.
- Prioritetizuotas pakeitimų sąrašas, kuriame atskirti tie, kuriuos reikia atkurti, nuo tų, kuriems reikia pakeisti nustatymus.
- Kas buvo tikrinama, kas ne ir kokiais įrodymais remiantis.
Kai apžvalga uždirba savo kainą
Paprastai pokyčių ar spaudimo metu: migracijos, susijungimo, pirmojo įmonės kliento saugumo klausimyno išsiuntimo, reguliavimo termino, pvz., NIS2 ar Kibernetinio atsparumo akto, arba trečio incidento su ta pačia priežastimi atveju. Peržiūrint stabilią sistemą, kurios niekas neketina keisti, dažniausiai sukuriamas dokumentas, o ne rezultatas.
Ar architektūrą galima išbandyti?
Ne taip, kaip testuojama veikianti sistema, nes nėra į ką siųsti srauto. Galima patikrinti, ar reali sistema atitinka aprašytąją. Būtent čia slypi didžiausia vertė, nes architektūra kinta: diagramoje nubrėžta riba tampa saugumo grupe, kuri incidento metu buvo praplatinta ir niekada nesusiaurėjo.
Praktiniai patikrinimai apima tinklo taisyklių ir tapatybės leidimų palyginimą su numatytomis ribomis, vienos realios užklausos atsekimą nuo pradžios iki galo ir diegimo srauto leidimų gamybinėje aplinkoje peržiūrą. Grėsmių modeliavimas yra projektavimo laiko atitikmuo: komponento galimo netinkamo panaudojimo patikrinimas prieš jį sukuriant.
Riba, kuri nebuvo viena.
Ataskaitų teikimo paslauga nuskaito duomenis iš kopijos ir negali tiesiogiai pasiekti kliento duomenų.
Replika bendrina prisijungimo duomenis su pagrindiniu serveriu, todėl bet koks ataskaitų teikimo pažeidimas pasiekia gamybos duomenis.
Mažo jautrumo paslauga yra didžiausio jautrumo ribose, ir joks įdiegtas valdiklis to nerodytų.
Sudėtinis dažno modelio pavyzdys, o ne kliento atvejis.
Dažnai užduodami klausimai
Ar saugumo architektūra yra tas pats, kas saugumo sistema?
Ne. Tokia sistema kaip ISO 27001 arba NIST kibernetinio saugumo sistema nurodo, kurias sritis reikia aprėpti. Saugumo architektūra apibūdina, kaip išdėstyta jūsų konkreti sistema. Dvi organizacijos gali atitikti tą pačią sistemą su labai skirtingomis architektūromis.
Ar mums reikia saugumo architekto, kad turėtume saugumo architektūrą?
Ne. Kiekviena sistema tokią turi, nesvarbu, ar kas nors ją sąmoningai pasirinko, ar užsirašė. Kyla klausimas, ar ji pakankamai gerai suprantama, kad būtų galima priimti sprendimus prieš ją, ir ar ji atitinka tai, kas veikia.
Kuo tai skiriasi nuo pažeidžiamumo skenavimo?
Skenavimo metu randami žinomi komponentų, kurie jau egzistuoja, trūkumai. Architektūros apžvalgos metu randami šių komponentų išdėstymo trūkumai, kurių skeneris negali matyti, nes kiekviena dalis gali būti atskirai atnaujinta ir teisingai sukonfigūruota.
Kiek laiko trunka peržiūra?
Tai priklauso nuo to, kiek sistemų apima apžvalga ir kiek jau yra dokumentuota. Vieno produkto tikslinė peržiūra su bendradarbiaujančia komanda paprastai trunka savaites, o ne mėnesius. Nedokumentuoto turto atkūrimas užtrunka gerokai ilgiau, ir šis atkūrimas paprastai sudaro didžiąją darbo dalį.
Ką mums reikia paruošti?
Bet koks jau egzistuojantis aprašymas, net jei jis pasenęs, bei prieiga prie žmonių, kurie gali paaiškinti, kaip sistema iš tikrųjų veikia. Tikslūs inžinierių atsakymai yra vertingesni nei tvarkinga schema.
Jums nereikia žinoti techninių terminų.
Papasakokite, kas vyksta, kokį poveikį tai daro ir kada jums reikia pagalbos. Aptarsime, ar galime padėti ir koks būtų naudingas pirmasis darbas.