IT biztonság és kiberbiztonság
cégeknek: szerverek, adatok, audit

Röviden: az IT biztonság a cég informatikai rendszereinek és adatainak védelme a támadás, az adatvesztés és a leállás ellen. A kiberbiztonság ennek az internet felől érkező fenyegetésekkel foglalkozó része. Három területen dolgozunk: a szerverek védelmén, az adatok mentésén és titkosításán, valamint az IT biztonsági auditon, amely megmutatja, hol sebezhető ma a rendszer. 2009 óta fejlesztünk és üzemeltetünk webes rendszereket, a saját szervereinket is mi védjük: a 2026. októberi PHP2Shell-hibánál a hivatalos javítás után hét órával már a javított PHP futott nálunk.

Mi az IT biztonság és miért vezetői kérdés?

Egy cég ma a weboldalán, a webáruházán, a levelezésén és a felhőben tárolt adatain keresztül dolgozik. Ha ezek közül egy leáll vagy illetéktelen kézbe kerül, kiesik a bevétel, sérül az ügyfelek bizalma, személyes adatnál pedig bejelentési kötelezettség is keletkezik. Az IT biztonság ezért költségvetési és felelősségi kérdés, a döntés a vezetőé.

IT biztonság, kiberbiztonság, információbiztonság: mi a különbség?

Az információbiztonság a legtágabb fogalom: minden információ védelme, a papíron tárolt szerződéstől a munkatársak tudásáig. Az IT biztonság (informatikai biztonság) ennek az informatikai rendszerekre eső része: szerverek, hálózat, alkalmazások, adatbázisok, mentések. A kiberbiztonság az internet felől érkező fenyegetésekre összpontosít, ezt a szót használja a magyar kiberbiztonsági törvény és az uniós NIS2 irányelv is. A gyakorlatban a három nagyrészt fedi egymást, ezen az oldalon az IT biztonság a gyűjtőnév.

A három alapcél: bizalmasság, sértetlenség, rendelkezésre állás

• Bizalmasság. Az adatot csak az látja, akinek joga van hozzá. Ezt sérti egy kiszivárgott ügyféladatbázis.
• Sértetlenség. Az adat és a program pontosan az, aminek lennie kell. Ezt sérti egy feltört oldalra csempészett kód vagy egy meghamisított számlaszám.
• Rendelkezésre állás. A rendszer akkor működik, amikor szükség van rá. Ezt sérti egy túlterheléses támadás vagy egy titkosított, használhatatlanná tett szerver.

Kik támadnak és mit akarnak?

Egy átlagos cég ellen ritkán dolgozik személyre szabott támadó. A forgalom nagy része gépi: botnetek pásztázzák folyamatosan az internetet ismert hibák, gyenge jelszavak és elfelejtett adminfelületek után. A cél többnyire a pénz: adatlopás és az adatok eladása, zsarolóvírus, a szerver felhasználása levélszemét küldésére vagy további támadásokra. Ebből következik a védekezés logikája is: a tömeges, automatizált kibertámadás ellen a jól karbantartott alapok védenek a legjobban.

Szerverbiztonság: a védelem első vonala

A weboldal, a webáruház és a levelezés egy szerveren fut, minden támadás ide érkezik. A szerverbiztonság célja, hogy kívülről a lehető legkevesebb látsszon belőle, ami pedig látszik, az naprakész és felügyelt legyen.

Hardening: a támadási felület csökkentése

A hardening a szerver megerősítése: ami nem kell, az kikapcsol, ami marad, az szigorúbb beállítást kap. A legfontosabb lépései:

• Belépés SSH-n csak kulccsal, jelszavas és közvetlen root belépés nélkül.
• Csak a ténylegesen használt szolgáltatások futnak, a régi programverziók és a felejtett tesztoldalak lekerülnek.
• Webhelyenként külön rendszerfelhasználó és PHP-folyamat, így egy feltört oldal nem viszi magával a többit.
• Az adminfelületek és az adatbázis-kezelő jelszó vagy IP-szűrés mögött, a nyilvános internet elől elzárva.

A szerver alapbeállításait az Ubuntu VPS üzemeltetés oldalon részletezzük, a VPS-ről általában a VPS szerver: mire jó cikkben írtunk.

Tűzfal, fail2ban és webes alkalmazás-tűzfal (WAF)

Három szűrő, három különböző feladat. A tűzfal a hálózati forgalmat engedi vagy tiltja: jó beállítás mellett kívülről csak a webes és a levelezési portok érhetők el. A fail2ban a naplókat figyeli és kitiltja azokat a címeket, amelyek jelszavakat próbálgatnak vagy sebezhetőséget keresnek. A webes alkalmazás-tűzfal (WAF) a weboldal előtt áll és a HTTP-kérésekben ismeri fel a támadásra jellemző mintákat. Webáruház elé érdemes WAF-ot tenni, mert a vásárlói fiókok és a rendelések miatt ez a leggyakrabban támadott felület.

Frissítéskezelés: biztonsági javítás órákon belül

Egy nyilvánosan ismert sebezhetőséget a javítás megjelenése után napokon belül tömegesen kezdenek kihasználni, ezért a biztonsági frissítés nem várhat a havi karbantartásig. A súlyosságot a CVSS pontszám és a saját rendszer kitettsége alapján mérjük fel. A kritikus javítást lehetőleg aznap telepítjük, utána ellenőrizzük, hogy a szolgáltatások ténylegesen a javított verzióval futnak. A rutin biztonsági frissítéseket automatikus frissítés viszi fel. Hogy ez a gyakorlatban hogyan néz ki, azt a PHP2Shell-hibáról szóló cikkünk mutatja be percre pontosan.

DDoS-támadás és túlterhelés elleni védelem

A túlterheléses (DDoS) támadás célja a megbénítás: annyi kérést küld a szerverre, hogy a valódi látogatók már nem jutnak át. Egy kis vagy közepes cég szerverét az védi hatékonyan, ha a forgalom eleve egy nagy hálózaton át érkezik. A nyilvános oldalak elé jellemzően Cloudflare-t teszünk, amely a támadó forgalom nagy részét még a szerver előtt kiszűri. A maradékot a szerveren a kérések számának és méretének korlátja fogja meg.

Naplózás, monitorozás és riasztás (SIEM)

Ami nincs naplózva, arról utólag nem derül ki, mikor és hogyan történt. A szerver, a webszerver, a PHP és a belépések naplóit érdemes egy helyen gyűjteni. Riasztás kell arra az esetre, ha egy szolgáltatás összeomlik, a webszerver felhasználója parancsot indít vagy szokatlan kimenő kapcsolat jelenik meg. Nagyobb szervezetnél ezt egy SIEM-rendszer végzi: a cég összes eszközének naplóit összeveti és a gyanús mintákat rangsorolja.

Hozzáférés-kezelés és kétlépcsős azonosítás

A legtöbb betörés egy ellopott vagy kitalált jelszóval kezdődik. Ezért minden fiók csak annyi jogot kap, amennyi a munkájához kell, a kilépő munkatárs hozzáférése még aznap megszűnik, a fontos fiókokat pedig kétlépcsős azonosítás védi. Elsőként a levelezésen, a domain és a tárhely kezelőfelületén, a webáruház adminján, valamint a Google- és a Meta-fiókokon érdemes bekapcsolni. A brute force támadás ellen a kétlépcsős azonosítás akkor is véd, ha a jelszó már kiszivárgott.

Webalkalmazás-biztonság: OWASP Top 10, SQL injection, XSS

Egy hibátlanul beállított szerveren is betörhet a támadó, ha maga a weboldal kódja hibás. Az OWASP Top 10 a webalkalmazások tíz leggyakoribb hibatípusát gyűjti össze, köztük az SQL injectiont (adatbázis-lekérdezés módosítása egy beviteli mezőn át), a cross-site scriptinget (XSS, idegen kód futtatása a látogató böngészőjében) és a hibás jogosultságkezelést. Fejlesztőként ezeket a kód szintjén ismerjük: a saját rendszereinkben paraméterezett lekérdezést, kimeneti kódolást és szerepalapú jogosultságot használunk, idegen kódot pedig ezekre a hibákra nézünk át. Egy feltört oldal tipikus nyoma a webshell: egy ártatlan nevű fájl a feltöltési mappában.

Adatbiztonság: mentés, titkosítás, helyreállítás

A szerver pótolható, az adat sokszor nem. Az adatbiztonság azt biztosítja, hogy egy támadás, egy hibás frissítés vagy egy elromlott lemez után is meglegyen minden: a rendelések, a számlák, az ügyféladatok és a weboldal tartalma.

Adatbiztonság és adatvédelem: a GDPR kötelezettségei röviden

Az adatvédelem azt szabályozza, milyen személyes adatot, milyen célra és meddig kezelhet a cég. Az adatbiztonság ennek a technikai oldala: a GDPR 32. cikke előírja, hogy az adatkezelő a kockázattal arányos technikai és szervezési intézkedésekkel védje az adatokat. A rendelet példaként a titkosítást, a rendszerek tartós bizalmasságát és rendelkezésre állását, az adatok gyors helyreállíthatóságát és az intézkedések rendszeres tesztelését nevezi meg. Az alábbi pontok mindegyike ezekből vezethető le.

Biztonsági mentés: a 3-2-1 szabály és a visszaállítás próbája

A 3-2-1 szabály szerint az adatnak legyen három példánya, két különböző tárolón, ebből egy a cég rendszereitől elkülönített helyen. A tárhelyszolgáltató saját mentése hasznos, de ugyanannál a szolgáltatónál van, mint az eredeti, a gyakoriságát és a megőrzési idejét pedig a szolgáltató szabja meg. A mentés értéke a visszaállításon mérhető: rendszeresen ki kell próbálni, hogy egy mentésből valóban felépíthető-e a működő oldal és mennyi idő alatt.

Titkosítás tárolásnál és átvitelnél

Átvitelnél a HTTPS az alap: SSL tanúsítvány minden oldalon, a régi, gyenge titkosítási protokollok kikapcsolva. Tárolásnál a mentések titkosítva kerüljenek ki a szerverről, a jelszavakat pedig csak lassú, sózott hash formában szabad tárolni, így egy kiszivárgott adatbázisból sem olvashatók vissza. A titkosítás a GDPR szerint is számít: ha az elveszett adat titkosított volt, az érintetteket általában nem kell értesíteni.

Zsarolóvírus ellen: elszigetelt, nem módosítható mentés

A mai zsarolóvírusok először a mentéseket keresik meg, csak utána titkosítanak. Ha a mentés ugyanarról a gépről elérhető és törölhető, a támadó azt is elviszi. A védelem az elszigetelt mentés: a mentési tárhelyre a szerver csak írni tud, törölni vagy felülírni nem, a régebbi példányok pedig a megőrzési időn belül semmilyen jogosultsággal nem módosíthatók. A tűzfal a zsarolóvírus ellen önmagában kevés, mert a fertőzés jellemzően egy ellopott jelszón vagy egy megnyitott levélmellékleten át érkezik.

Adatszivárgás és adatvédelmi incidens: mi a teendő 72 órán belül?

Ha személyes adat illetéktelen kézbe kerülhetett, az adatvédelmi incidens. A GDPR szerint az adatkezelőnek a tudomásszerzéstől számított 72 órán belül be kell jelentenie a Nemzeti Adatvédelmi és Információszabadság Hatóságnak (NAIH), kivéve, ha az incidens valószínűleg nem jár kockázattal az érintettekre. Magas kockázatnál az érintetteket is tájékoztatni kell. Az első órák teendői:

1. A szivárgás megállítása: a feltört fiók zárolása, a sérült szerver leválasztása, a jelszavak cseréje.
2. A bizonyítékok megőrzése: a naplók és a gyanús fájlok mentése, mielőtt bármit takarítanánk.
3. A kör felmérése: milyen adat, hány érintett, mióta.
4. Döntés a bejelentésről. Az incidenst a belső nyilvántartásban akkor is rögzíteni kell, ha bejelentés nem szükséges.
5. A behatolási pont lezárása és a rendszer helyreállítása tiszta mentésből.

Ebben a technikai részt vállaljuk: a nyomok rögzítését, a behatolás útjának feltárását, a helyreállítást és a bejelentéshez szükséges technikai összefoglalót. A jogi minősítés az adatvédelmi tisztviselő vagy a jogász feladata.

Katasztrófa utáni helyreállítás és üzletmenet-folytonosság

A katasztrófa utáni helyreállítási terv (disaster recovery) két számra épül: mennyi ideig állhat a rendszer (RTO) és mennyi friss adat veszhet el legfeljebb (RPO). Egy webáruháznál például elfogadható lehet egy óra kiesés, egyetlen rendelés elvesztése viszont nem. A két számhoz igazodik a mentés gyakorisága, a tartalék szerver és a helyreállítás lépései, amelyeket egyszer élesben is végig kell próbálni, mielőtt baj lenne. Az üzletmenet-folytonosság ennél tágabb: azt is rögzíti, hogyan dolgozik a cég, amíg a rendszer helyreáll.

IT biztonsági audit és sérülékenységvizsgálat

Az IT biztonsági audit egy pillanatfelvétel: megmutatja, hol tart ma a rendszer és mi a legsürgősebb javítanivaló. Minden további lépés erre épül, mert egy meglévő rendszerről csak mérés után lehet felelősen dönteni.

Mit vizsgál egy IT biztonsági audit?

• Szerverek és hálózat: nyitott portok, futó szolgáltatások és verzióik, a tűzfal és az SSH beállítása, a frissítések állapota.
• Webalkalmazások: tartalomkezelő, bővítmények, egyedi kód, a leggyakoribb webes hibák (OWASP Top 10), az adminfelületek elérhetősége.
• Hozzáférések: ki milyen joggal lép be, vannak-e közös vagy gazdátlan fiókok, hol hiányzik a kétlépcsős azonosítás.
• Adatok és mentések: mi mentődik, hova és milyen gyakran, sikerül-e belőle a visszaállítás.
• Naplózás: mi rögzül, meddig marad meg, észrevenné-e valaki egy betörést.
• Levelezés és domain: az SPF, DKIM és DMARC beállítása, a domain és a DNS kezelőfelületének védelme.
• Szabályok és dokumentáció: van-e informatikai biztonsági szabályzat, eszköz- és hozzáférés-nyilvántartás.

Sérülékenységvizsgálat vagy penetrációs teszt (pentest)?

Kis és közepes cégnél a sérülékenységvizsgálat az ésszerű kezdés: olcsóbb, rendszeresen ismételhető és a hibák nagy részét megtalálja. Pentestet akkor érdemes rendelni, ha a rendszer már túl van az alapjavításokon, vagy ha szerződés, biztosító vagy jogszabály kéri.

Az audit menete lépésről lépésre

1. Egyeztetés és hatókör. Közösen rögzítjük, mely szerverek, alkalmazások és fiókok tartoznak a vizsgálatba, mikor dolgozhatunk és kit értesítünk, ha élesben kritikus hibát találunk.
2. Leltár. Feltérképezzük az eszközöket, a domaineket, a futó szolgáltatásokat és a hozzáféréseket. Gyakran már itt előkerül egy elfelejtett tesztoldal vagy egy régi adminfelület.
3. Vizsgálat. Automatizált szkennelés, utána kézi ellenőrzés: beállítások, verziók, jogosultságok, mentések, naplók. Ahol hozzáférünk, a webalkalmazás kódját is átnézzük.
4. Értékelés. Minden talált hibát a súlyossága és a cégre jelentett kockázata szerint rangsorolunk, a téves riasztásokat kiszűrjük.
5. Jelentés és megbeszélés. Átadjuk az írásos jelentést és végigbeszéljük a vezetővel, valamint a rendszerért felelős kollégával.
6. Javítás és utóellenőrzés. Kérésre a javítást is elvégezzük, utána újravizsgáljuk a lezárt pontokat.

Amit kézhez kap

• Vezetői összefoglaló: hol áll ma a rendszer és mi a legsürgősebb teendő.
• Részletes hibalista súlyosság szerint, mindegyiknél a bizonyíték, a kockázat és a javítás módja.
• Javítási terv ütemezéssel: mi oldható meg napokon belül és mi igényel fejlesztést vagy beruházást.
• Utóellenőrzés a javítás után, a lezárt pontok listájával.

Informatikai biztonsági szabályzat (IBSZ) és kockázatelemzés

Az informatikai biztonsági szabályzat (IBSZ) rögzíti, ki mihez fér hozzá, hogyan kezeli a cég a jelszavakat, a mentéseket, a saját eszközöket és az incidenseket. A NIS2 hatálya alá tartozó szervezeteknél a kockázatelemzés és a biztonsági szabályzat kötelező, más cégeknél a GDPR szerinti elszámoltathatóságot is ezzel lehet igazolni. A szabályzat alapja a kockázatelemzés: mely rendszerek a legfontosabbak, mi fenyegeti őket és mekkora kárt okozna a kiesésük. Az audit eredményéből elkészítjük vagy frissítjük a szabályzat technikai fejezeteit, a valós beállításokhoz igazítva.

NIS2 és a kiberbiztonsági törvény: kit érint, mi a teendő?

A NIS2 az Európai Unió kiberbiztonsági irányelve. Magyarországon a 2024. évi LXIX. törvény (kiberbiztonsági törvény) ültette át, amely 2025. január 1-jén lépett hatályba. A cégek többségénél a felügyeletet a Szabályozott Tevékenységek Felügyeleti Hatósága (SZTFH) látja el.

Kik a NIS2 érintettjei?

A törvény a mellékleteiben felsorolt ágazatokban működő közép- és nagyvállalatokra vonatkozik, például az energia, a közlekedés, az egészségügy, a víziközmű, a digitális infrastruktúra, az élelmiszer-előállítás és -forgalmazás, a gyártás, a hulladékgazdálkodás és a digitális szolgáltatások területén. Középvállalkozásnak az számít, ahol legalább 50 fő dolgozik, vagy az éves árbevétel és a mérlegfőösszeg is meghaladja a 10 millió eurót. Egyes ágazatokban a méret nem számít. A mikro- és kisvállalkozások általában kívül esnek a hatályán, de beszállítóként gyakran kapnak NIS2-es követelményeket a partnereiktől.

Lejárt az első audithatáridő: mi jön most?

A 2025 előtt működő érintetteknek az első kiberbiztonsági auditot 2026. június 30-ig kellett elvégeztetniük. A sajtóban megjelent 2026. augusztusi összesítés szerint 2194 szervezet teljesítette és közel 90 százalékuk megfelelt, a leggyakoribb hiányosság a rendszerek dokumentáltsága volt. Az audit kétévente ismétlődik, a később nyilvántartásba vett szervezetek pedig a nyilvántartásba vételtől számított két éven belül kötelesek elvégeztetni. Aki elmulasztja a bejelentkezést vagy az auditot, felszólítást, figyelmeztetést, végső esetben bírságot kap.

Aki a júniusi határidőre nem készült el, vagy csak most derült ki róla, hogy érintett, annak a teendői: nyilvántartásba vétel, biztonsági osztályba sorolás (alacsony, jelentős vagy magas), a hiányosságok pótlása és szerződés egy nyilvántartott auditorral.

Miben segítünk a NIS2 megfelelésben?

A hivatalos kiberbiztonsági auditot kizárólag az SZTFH nyilvántartásában szereplő auditor végezheti. Mi nem vagyunk nyilvántartott auditor, ezért hivatalos NIS2 auditot nem állítunk ki. Az audit előtti és utáni munkát viszont mélyen ismerjük, ezekben dolgozunk:

• NIS2 próbaaudit. A hivatalos audit szempontjai szerint átvilágítjuk a rendszert és megmutatjuk, hol nem felelne meg ma.
• A hiányosságok technikai javítása. Hozzáférés-kezelés, kétlépcsős azonosítás, naplózás, mentés, frissítés- és sérülékenységkezelés a szervereken és a webes rendszereken.
• Dokumentáció. A szabályzatok technikai fejezetei, eszköz- és hozzáférés-nyilvántartás, a valós beállításokhoz igazítva. Az első auditkörben ez volt a leggyakoribb hiányosság.
• Támogatás az auditor mellett. Az audit alatt műszaki oldalról válaszolunk az auditor kérdéseire, a feltárt hiányosságok lezárásában pedig a következő auditig segítünk.

ISO 27001 és NIS2: hogyan függ össze?

Az ISO/IEC 27001 az információbiztonsági irányítási rendszer nemzetközi szabványa, a tanúsítványt akkreditált tanúsító szervezet adja ki. A NIS2 kötelező jogszabályi követelmény, az ISO 27001 önkéntes szabvány, a tartalmuk viszont nagyrészt fedi egymást: kockázatelemzés, szabályzatok, hozzáférés-kezelés, incidenskezelés, folytonosság. Egy ISO 27001 szerint működő cégnek a NIS2 megfelelés jóval kevesebb új munkát jelent.

Az emberi tényező: adathalászat, jelszavak, szabályok

A technikai védelmet egyetlen rossz kattintás is megkerülheti. A betörések jelentős része ma is egy adathalász levéllel vagy egy kiszivárgott jelszóval kezdődik.

Adathalász levelek felismerése

Az adathalász levél sürget és egy ismerős nevében ír: a bank, a futárszolgálat, a NAV, a tárhelyszolgáltató vagy a saját vezető nevében. Néhány jel, amire érdemes figyelni:

• A feladó címe eltér a megszokottól, akár csak egy betűben.
• A levél azonnali cselekvést kér: fizetést, jelszócserét, különben „a fiókja felfüggesztésre kerül”.
• A gomb vagy a link másik címre mutat, mint amit a szöveg ígér. Ez kattintás nélkül is látszik, ha az egeret fölé viszi.
• Számlaszám-változást jelentenek be e-mailben. Ezt mindig telefonon, egy már ismert számon kell visszaellenőrizni.

Technikai oldalon az SPF, DKIM és DMARC beállítása megnehezíti, hogy a cég nevében hamis levél menjen ki, a levelezőszerver szűrője pedig a beérkező kártevők nagy részét megfogja.

Jelszókezelő és jelszószabályzat

Ötven különböző, erős jelszót senki nem tud fejben tartani, ezért a jelszavak ismétlődnek, a támadók pedig egy kiszivárgott jelszóval az összes ismert szolgáltatásba megpróbálnak belépni. A megoldás a jelszókezelő: minden fiókhoz külön, hosszú, véletlenszerű jelszó, amelyet a program tárol és tölt ki. Cégnél a közös fiókokat is ebben érdemes megosztani, így egy munkatárs kilépésekor pontosan tudható, mit kell lecserélni.

Munkatársak felkészítése

Rövid, rendszeres alkalmak többet érnek egy évi egyszeri előadásnál: mit tegyen a munkatárs, ha gyanús levelet kapott, kinek szóljon, ha rákattintott, mi a teendő elveszett telefonnál vagy laptopnál. A legfontosabb szabály, hogy a hibát azonnal és büntetés nélkül jelezni lehessen, mert a gyorsan jelzett incidens kezelhető.

Tapasztalatunk: valós esetek

2009 óta fejlesztünk és üzemeltetünk webes rendszereket: saját tartalomkezelőt és webáruház-motort, WordPress és Magento 2 oldalakat, valamint a szervereket, amelyeken ezek futnak. A biztonság nálunk napi üzemeltetési munka. Két eset a saját rendszereinkből, a szerver naplóiból mért adatokkal:

PHP2Shell: kritikus PHP-hiba javítása hét óra alatt

2026. október 21-én a PHP két kritikus, belépés nélkül kihasználható hibát javított (CVSS 9,2). A saját szerverünkön a hivatalos kiadás után hét órával már a javított PHP futott. Utána augusztus elejéig visszamenőleg átnéztük a PHP és a webszerver naplóit, a behatolás-ellenőrző sem talált nyomot. A PHP csomagtárolója azóta az automatikus biztonsági frissítések között van. A teljes idővonal és a naplórészletek a PHP2Shell-cikkben olvashatók.

Saját üzemeltetésünk: több réteg a támadó és a kód között

A saját és ügyfeleink WebPotCMS oldalai egy általunk üzemeltetett Ubuntu LTS szerveren futnak, a tesztkörnyezetekkel és az adminfelületekkel együtt harmincegy webhely. Előttük Cloudflare szűr, az adminfelületeket az nginx kér jelszót még a PHP előtt, a fail2ban pedig hét figyelővel tiltja ki a próbálkozókat egyszerre a szerver tűzfalán és a Cloudflare-en. A PHP2Shell utáni napokban, október 22. és 25. között csak az SSH-figyelő közel hatszáz címet tiltott ki. Az ugyanekkor előrehozott átvilágításon a memória felosztását is áthangoltuk, a szabad memória 2,6 GB-ról 6,5 GB-ra nőtt.

Így dolgozunk: felmérés, javítás, folyamatos felügyelet

1. Felmérés. IT biztonsági audit vagy rövidebb állapotfelmérés: hol áll ma a rendszer és mi a legsürgősebb.
2. Azonnali javítások. A kritikus hibákat zárjuk le elsőként: nyitott adminfelület, ismerten sebezhető szoftververzió, működésképtelen mentés.
3. Javítási terv. A többi pontot ütemezve, a cég kapacitásához és költségvetéséhez igazítva visszük végig.
4. Folyamatos felügyelet. Biztonsági frissítések, naplófigyelés, mentésellenőrzés és időszakos újravizsgálat: saját szervernél az Ubuntu VPS üzemeltetés, WordPress oldalnál a WordPress-karbantartás része.

A fejlesztés, az üzemeltetés és a biztonság egy kézben marad: ugyanaz a csapat javítja a hibát a kódban, amelyik a szervert is ismeri, így a hiba ott javul, ahol keletkezett.

Ajánlatkérés: mitől függ a díj?

Az IT biztonsági munkát egyedi ajánlat alapján végezzük, mert két cég rendszere ritkán hasonlít. A díjat ezek határozzák meg:

• A rendszer mérete: hány szerver, webhely, alkalmazás és felhasználói fiók tartozik a vizsgálatba.
• A vizsgálat mélysége: gyors állapotfelmérés, sérülékenységvizsgálat vagy teljes IT biztonsági audit kódátnézéssel.
• NIS2 érintettség: a cég biztonsági osztálya, valamint hogy próbaauditra, dokumentációra vagy auditor melletti támogatásra van-e szükség.
• Egyszeri vagy folyamatos munka: egy audit a javítási tervvel, vagy havi felügyelet frissítéssel, naplófigyeléssel és mentésellenőrzéssel.