GLPI nie je skener zraniteľností. Nespúšťa sondy Nessus ani kontroly OpenVAS. Je to však jediné miesto vo vašej infraštruktúre, ktoré už vie, aké zariadenia máte, aký softvér na nich beží, kde sa nachádzajú v sieti a kto je za ne zodpovedný. Práve preto je CMDB prirodzeným miestom na sledovanie nálezov zraniteľností pri jednotlivých aktívach — a prirodzeným miestom na zodpovedanie otázky, ktorú si každý CISO položí po zverejnení nového CVE: "Ktorých našich zariadení sa to týka?"
Problém s postupmi založenými len na skeneri
Väčšina skenerov zraniteľností produkuje správy. PDF, CSV, dashboardy. Bezpečnostný tím ich preskúma, manuálne vytvorí tikety a dúfa, že IT prevádzka sa ich ujme. Práve v medzere medzi "našli sme zraniteľnosť" a "niekto ju opravil na tomto konkrétnom zariadení" sa veci rozpadávajú.
Skenery poznajú zraniteľnosti. GLPI pozná aktíva. Prepojenie oboch uzatvára celý cyklus.
Nastavenie sledovania zraniteľností v GLPI
GLPI sa nedodáva s dedikovaným modulom na sledovanie zraniteľností, ale dá sa postaviť z funkcií, ktoré sú už k dispozícii.
Možnosť 1: vlastné polia cez plugin Additional Fields
Nainštalujte plugin Additional Fields a vytvorte blok polí na objekte Computer (alebo NetworkEquipment, prípadne inom type aktíva). Pridajte polia ako CVE ID, závažnosť (Critical / High / Medium / Low), dátum objavenia, zdroj skenera a stav nápravy. Každé aktívum tak získa viditeľnú históriu zraniteľností priamo na svojej detailnej stránke.
Možnosť 2: samostatná kategória tiketov pre zraniteľnosti
Vytvorte strom kategórií tiketov: Security > Vulnerability > [podľa závažnosti]. Keď skener nájde kritický problém, vytvorí sa tiket pod touto kategóriou, prepojený s dotknutým aktívom cez záložku "Items". Tiket sleduje nápravu — priradenie, postup, validáciu, uzavretie.
Možnosť 3: kombinácia oboch
Použite vlastné polia na surové dáta o zraniteľnostiach (čo sa našlo, kedy, akým skenerom) a tikety na workflow nápravy (kto to opravuje, aký je termín, je to hotové). Tým sa oddelí nález od opravy, čo je dôležité pre auditné záznamy.
Workflow importu
Praktický postup vyzerá takto:
- Skener beží podľa plánu (Nessus, OpenVAS, Qualys — akýkoľvek nástroj, ktorý exportuje CSV alebo má API).
- Skript spracuje výstup skenera a priradí nálezy k aktívam v GLPI podľa hostname, IP adresy alebo sériového čísla cez GLPI REST API.
- Pre každú zhodu skript buď aktualizuje vlastné polia zraniteľností na aktíve, alebo vytvorí tiket prepojený s daným aktívom — alebo oboje.
- Tikety pristanú vo fronte zodpovedného technika (GLPI vie automaticky priradiť podľa entity, lokality alebo skupiny aktív).
- Náprava sa sleduje pri každom aktíve. Keď technik systém záplatuje, uzavrie tiket a aktualizuje stav zraniteľnosti.
GLPI REST API toto všetko zvládne. Endpointy na vytváranie tiketov (POST /apirest.php/Ticket) a aktualizáciu aktív (PUT /apirest.php/Computer/{id}) sú dobre zdokumentované a stabilné.
Odpoveď na otázku "Ktorých zariadení sa týka CVE-X?"
S dátami o zraniteľnostiach uloženými v GLPI sa z toho stáva vyhľadávací dotaz. Filtrujte aktíva podľa vlastného poľa CVE ID, alebo hľadajte tikety podľa referencie CVE v názve. Uložené vyhľadávania v GLPI umožňujú tieto dotazy uložiť a zdieľať s bezpečnostným tímom.
Dajú sa vytvoriť aj reporty: koľko otvorených kritických zraniteľností existuje naprieč flotilou, ktoré entity majú najvyššie počty, aký je priemerný čas od objavenia po nápravu. Toto sú presne tie dáta, ktoré vyžadujú audítori ISO 27001 a ktoré očakávajú požiadavky NIS2 na hlásenie incidentov.
Čo tým získate
CMDB sa stane jediným zdrojom pravdy pre inventár aktív aj bezpečnostný stav. Nálezy zraniteľností nie sú uväznené v správach zo skenera — sú prepojené so skutočnými aktívami, ktoré majú skutočných vlastníkov. Náprava sa sleduje cez rovnaký tiketovací systém, ktorý IT tím už používa, takže žiadne nové nástroje a žiadne nové postupy na učenie.
GLPI nenahradí váš skener. Ale zabezpečí, že to, čo váš skener nájde, sa skutočne opraví — na správnom zariadení, správnou osobou, v sledovateľnom časovom rámci.