Atvykstame į įmonę, kurioje nėra jokios IT dokumentacijos. Nuo ko pradedame?
Nežinomi slaptažodžiai, nepažymėti kabeliai, neaiškūs VLAN, senas administratorius nebepasiekiamas, o vienintelis backup „turėtų veikti“. Tokia situacija nėra reta. Pirmą dieną nepradedame nuo įrangos keitimo – pirmiausia atkuriame matomumą ir kontrolę.
8:30 – pirmiausia klausomės, o ne jungiame nešiojamą kompiuterį
Susitinkame su vadovu ir žmonėmis, kurie kasdien susiduria su IT. Klausiame ne tik, kokia įranga stovi spintoje, bet ir kas sustabdytų veiklą: apskaita, gamybos sistema, failų serveris, el. paštas, kasos, sandėlio terminalai, kameros ar nuotolinis ryšys su filialu.
Šiame etape dažnai išgirstame frazes „slaptažodį gal žino buvęs darbuotojas“, „šitą kompiuterį geriau neišjungti“ arba „kopijos lyg ir daromos į NAS“. Tai nėra kaltų paieška. Tai informacija, pagal kurią nustatome, ką tikrinti pirmiausia ir kur bet koks neapgalvotas pakeitimas galėtų sukelti prastovą.
Verslo procesai
↓
Kritinės sistemos ir jų savininkai
↓
Administravimo prieigos
↓
Tinklas → serveriai → debesija → backup
↓
Rizikų planas ir dokumentacija9:15 – sustabdome chaotišką slaptažodžių medžioklę
Sudarome administravimo prieigų sąrašą: domeno administratoriai, Microsoft 365 ir Entra, domenų registratorius, DNS, priegloba, ugniasienė, komutatoriai, Wi‑Fi valdiklis, virtualizacija, backup, NAS, kameros, UPS ir nuotolinės prieigos įrankiai.
Jeigu prieiga egzistuoja tik vieno žmogaus asmeninėje paskyroje, ją pažymime kaip kritinę riziką. Kuriame vardines administratorių paskyras, atskiriame kasdienes ir privilegijuotas teises, įjungiame MFA ten, kur tai galima padaryti saugiai, ir sutariame, kur bus laikomi atkūrimo kodai. Bendrų slaptažodžių nekeičiame aklai – prieš tai nustatome, kokios paslaugos, skriptai ar įrenginiai gali juos naudoti.
10:00 – nuo interneto įvado iki paskutinio switch porto
Apžiūrime ryšio įvadus, rack spintą, maršrutizatorių, komutatorius, patch paneles ir belaidžio tinklo įrangą. Užfiksuojame modelius, serijinius numerius, programinės įrangos versijas, uplink'us, PoE apkrovą ir fizinį kabelių sujungimą.
MikroTik ar kito gateway konfigūraciją pirmiausia eksportuojame ir išsaugome. Tik tada analizuojame WAN, NAT, firewall, VPN, DHCP, DNS, maršrutus ir VLAN. Ieškome tiesiogiai iš interneto pasiekiamo valdymo, nebereikalingų taisyklių, senų VPN naudotojų ir tinklų, kurie egzistuoja konfigūracijoje, bet niekas nebežino jų paskirties.
| Sritis | Ką fiksuojame | Dažna rizika |
|---|---|---|
| Internetas ir gateway | Tiekėjas, vieši IP, WAN, VPN, firewall ir atsarginis ryšys. | Atviras valdymas, sena programinė įranga arba vienintelis interneto kanalas. |
| Komutatoriai | Uplink, trunk, access portai, PoE ir valdymo adresai. | Nežymėti kabeliai ir „default“ VLAN visiems įrenginiams. |
| Wi‑Fi | SSID, autentifikavimas, AP vietos, kanalai ir svečių tinklas. | Bendras darbuotojų, svečių ir IoT tinklas. |
| VLAN | Potinkliai, gateway, DHCP, ACL ir leidžiamas srautas. | Segmentai sukurti, bet tarp jų nėra realios kontrolės. |
11:30 – braižome faktinę, o ne numanomą tinklo schemą
Remiamės ne vien konfigūracijos pavadinimais. Tikriname MAC ir ARP lenteles, LLDP kaimynus, DHCP nuomas, maršrutizavimą ir pasirinktus switch portus. Taip nustatome, kur iš tikrųjų prijungti serveriai, darbo vietos, spausdintuvai, kameros, telefonija, gamybos įranga ir prieigos kontrolė.
Pirmoji schema nebūna graži. Ji turi būti teisinga. Joje pažymime interneto įvadą, pagrindinį gateway, komutatorius, trunk jungtis, VLAN, serverius, Wi‑Fi taškus ir kritines priklausomybes. Nežinomus mazgus paliekame pažymėtus kaip tikrintinus – geriau aiškus klaustukas nei išgalvotas atsakymas.
13:00 – AD, virtualizacija ir serveriai
Patikriname Active Directory struktūrą, domeno valdiklius, DNS, laiko sinchronizavimą, administratorių grupes, neaktyvias paskyras, Group Policy ir replikacijos būseną. Vertiname ne tik tai, ar vartotojai gali prisijungti, bet ir ar domeną būtų įmanoma atkurti sugedus pagrindiniam serveriui.
Virtualizacijos aplinkoje fiksuojame hostus, klasterį, storage, virtualias mašinas, tinklo tiltus, snapshotus ir resursų apkrovą. Proxmox, VMware ar Hyper‑V konsolėje matomas VM sąrašas dar nėra dokumentacija: būtina žinoti, kokią verslo funkciją kiekviena VM atlieka, nuo ko ji priklauso ir kokia tvarka turi būti paleidžiama po gedimo.
14:15 – Microsoft 365, domenai ir išorinės paslaugos
Peržiūrime tenant administratorių paskyras, MFA, licencijas, Exchange, SharePoint, OneDrive, Teams ir įtartinus persiuntimus. Patikriname, kieno vardu registruoti įmonės domenai, kas valdo DNS zonas, kada baigiasi registracija ir kokie tiekėjai turi administravimo teises.
Čia dažnai slepiasi verslo tęstinumo problema: domenas registruotas buvusio darbuotojo el. paštu, vienintelis „Global Administrator“ yra išorinės įmonės paskyra arba kritinės DNS zonos valdomos paskyroje, prie kurios niekas nebegali prisijungti.
15:00 – backup užduoties „Success“ nelaikome įrodymu
Inventorizuojame, kas kopijuojama, kur laikomos kopijos, kokia jų retencija ir kokiomis paskyromis jos pasiekiamos. Tikriname, ar backup sistema nėra tame pačiame administravimo ir pasitikėjimo domene kaip produkcinė aplinka, ar yra immutable arba offline kopija ir ar kas nors stebi nesėkmingas užduotis.
Svarbiausias klausimas – kada paskutinį kartą buvo atliktas atkūrimo testas. Pasirenkame nedidelį, kontroliuojamą objektą ir patikriname atkūrimą nepaveikdami produkcijos. Tik po tokio testo galime sakyti, kad egzistuoja ne tik kopija, bet ir reali atkūrimo galimybė.
15:45 – kameros, UPS ir „nematoma“ infrastruktūra
Į bendrą inventorių įtraukiame NVR, kameras, durų kontrolę, signalizacijos integracijas, UPS, temperatūros jutiklius ir kitą IoT įrangą. Šie įrenginiai dažnai turi senas paskyras, numatytuosius VLAN arba nekontroliuojamą interneto prieigą, nors fiziškai yra lengviau pasiekiami nei serveriai.
UPS atveju svarbu ne tik akumuliatoriaus indikatorius. Tikriname apkrovą, numatomą veikimo laiką, pranešimų siuntimą, serverių saugaus išjungimo logiką ir datą, kada baterijos paskutinį kartą buvo keistos ar testuotos.
16:30 – įjungiame matomumą
Neįmanoma prižiūrėti to, ko nematome. Pirmiausia nustatome bazinį monitoringą: interneto ryšys, gateway, switch'ai, AP, serverių pasiekiamumas, CPU, RAM, diskai, storage, backup užduotys, UPS ir sertifikatų galiojimas. Zabbix ar kita stebėsenos sistema turi parodyti gedimą anksčiau, nei apie jį paskambina darbuotojas.
Saugumo stebėseną atskiriame nuo paprasto pasiekiamumo. Wazuh ar kitas SIEM/XDR sprendimas padeda matyti prisijungimus, privilegijų pokyčius, pažeidžiamumus, failų pakeitimus ir kitus įvykius, kurių vien „ping“ patikra neparodys.
17:15 – dieną baigiame ne įrangos sąrašu, o sprendimų planu
Pirmos dienos rezultatas nėra šimto puslapių dokumentas. Parengiame trumpą faktinės situacijos santrauką ir suskirstome darbus pagal poveikį:
- Kritiška: nėra administravimo prieigos, neveikia backup, viešai pasiekiamas valdymas, baigiasi domeno registracija ar yra vienas gedimo taškas.
- Svarbu: nėra MFA, tinklas nesegmentuotas, neatnaujinta įranga, neaiškios privilegijos arba nėra monitoringo.
- Planuojama: kabelių žymėjimas, įrangos standartizavimas, Wi‑Fi optimizavimas, licencijų ir resursų tvarkymas.
Kokia dokumentacija lieka įmonei?
Dokumentaciją kuriame taip, kad ji būtų naudinga incidento metu, o ne tik gražiai atrodytų. Joje turi būti:
- įrangos, serverių, virtualių mašinų ir paslaugų inventorius;
- fizinė ir loginė tinklo schema, VLAN bei IP planas;
- administravimo paskyrų ir atsakomybių registras be atvirai įrašytų slaptažodžių;
- domenų, licencijų, sertifikatų ir sutarčių galiojimo datos;
- backup apimtis, retencija, atkūrimo testai ir paleidimo eiliškumas;
- monitoringo objektai, perspėjimų gavėjai ir eskalavimo tvarka;
- pakeitimų žurnalas ir darbų prioritetai.
Jūsų IT infrastruktūra taip pat „žinoma tik iš atminties“?
INsec gali atlikti IT ūkio inventorizaciją, saugiai perimti administravimą, sudaryti tinklo ir sistemų dokumentaciją bei parengti prioritetinį rizikų mažinimo planą.
Aptarti IT infrastruktūros perėmimą