NIS2 beszállítói kockázatkezelés és partneri auditok

A NIS2 irányelv által leggyakrabban félreértett követelménye nem a technológiai kontrollokhoz, hanem a szervezeti határokhoz kapcsolódik. A hatálya alá tartozó szervezetek döntő többsége hajlamos kizárólag a saját belső infrastruktúrájára koncentrálni – tűzfalokra, végpontbiztonsági megoldásokra, bejelentkezési politikákra – miközben figyelmen kívül hagyja azt az egyszerű tényt, hogy a legtöbb sikeres kibertámadás ma már nem a célszervezet elsődleges védelmi vonalán tör be, hanem annak gyengébben védett, de megbízható hozzáféréssel rendelkező partnere vagy alvállalkozója révén.

Az EU 2022/2555 számú irányelv 21. cikk (2) bekezdésének d) pontja ennek megfelelően kifejezetten előírja az ellátási lánc biztonságára vonatkozó kockázatkezelési intézkedések bevezetését, beleértve az egyes szervezetek és közvetlen szállítóik, illetve szolgáltatónyújtóik közötti biztonsági vonatkozásokat. Ez a megfogalmazás a magyarországi implementációban (2023. évi XXIII. törvény) szintén megjelenik, és auditálható, bizonyítható kontrollokat vár el – nem csupán szerződéses nyilatkozatokat.

Ez a cikk technikai és módszertani szempontból elemzi, hogyan közelítsük meg a NIS2 beszállítói kockázatkezelés feladatát: mit jelent az ellátási lánc biztonságát infrastruktúra-szinten kezelni, milyen technikai bizonyítékokat kell bekérni a partnerektől, és hogyan csökkenthetők érdemben a harmadik felek által generált kockázatok.

1. A horizontális támadási felület: Hogyan válik a gyenge partner belépési ponttá

A kiberbiztonsági incidensek elemzése az elmúlt évtizedben következetesen igazol egy mintát: a célszervezet saját védelmi szintje önmagában nem elegendő garancia, ha a hálózatához megbízható csatornákon keresztül kapcsolódó partnerek biztonsági érettsége alacsonyabb. Ezt a jelenséget nevezi a szakma horizontális vagy oldalirányú (lateral) fenyegetési felületnek.

Két iparágformáló incidens alkalmas ennek szemléltetésére.

1.1. A Target kiskereskedelmi lánc esete (2013)

Az Egyesült Államok egyik legnagyobb kiskereskedelmi hálózata, a Target ellen 2013-ban végrehajtott támadás során 40 millió hitelkártyaadat és 70 millió személyes ügyfélrekord szivárgott ki. A feltörés kiindulópontja nem a Target saját rendszere volt, hanem egy külső klímatechnikai és épületfelügyeleti alvállalkozó, amelynek VPN-hozzáférési hitelesítő adatait adathalász kampányon keresztül szerezték meg a támadók. Ez a hozzáférés – amelyet az alvállalkozó kizárólag a fűtési és légkondicionálási rendszerek távoli monitorozására kapott – a Target belső hálózatának szegmentáltság hiánya miatt elegendőnek bizonyult ahhoz, hogy a támadók elérjék a pénztári terminálokat és a fizetési adatokat kezelő rendszereket.

A tanulság szempontjából lényeges, hogy a Target saját infrastruktúrájának biztonsági szintje a korabeli iparági átlag felett volt. A kompromittálódás kizárólag a harmadik fél hozzáférési politikájának és a hálózati szegmentálás hiányának következménye volt.

1.2. A SolarWinds ellátási lánc kompromittálódás (2020)

A SolarWinds-incidens az ellátási lánc alapú támadások legsúlyosabb, legjobban dokumentált példája. A támadók – az elemzések szerint orosz állami hátterű APT csoport, az SVR által üzemeltetett Cozy Bear / APT29 – a SolarWinds Orion IT-monitorozó szoftver build-folyamatát kompromittálták. A kártékony kód – a SUNBURST backdoor – a szoftver legitim frissítési csomagjába integrálódott, és digitálisan aláírva, a SolarWinds szoftverfrissítési infrastruktúráján keresztül jutott el körülbelül 18 000 szervezethez, köztük az Egyesült Államok kincstárügyi és igazságügyi minisztériumához, a Honvédelmi Minisztériumhoz és számos Fortune 500-as vállalathoz.

A SolarWinds-eset azért különösen tanulságos a NIS2 szempontjából, mert a célszervezetek – amelyek közül sok rendelkezett fejlett biztonsági képességekkel – semmilyen belső kontrollal nem tudták megelőzni a kompromittálódást. Az általuk megbízhatónak ítélt szoftverszállító build-folyamatának integritása sérült meg. Ez a forgatókönyv pontosan az az ellátási lánc kockázat, amelyre a NIS2 21. cikkének d) pontja vonatkozik.

1.3. A tipikus hazai kockázati profil

A fenti, nagyvállalati példákon túl a hazai vállalati környezetben az alábbi, rendszeresen előforduló harmadik fél típusok hordozzák a legnagyobb kockázati koncentrációt:

Külső IT-üzemeltetők és MSP-k (Managed Service Providers): Széleskörű, legtöbbször nem auditált adminisztratív hozzáféréssel rendelkeznek a megbízó teljes infrastruktúráján. Egyetlen kompromittált MSP-hozzáférés ezért párhuzamosan érinthet több tucat ügyfelét.
Könyvelő és bérszámfejtő irodák: Tipikusan hozzáféréssel rendelkeznek a megbízó pénzügyi és HR-rendszereihez, sok esetben VPN-en keresztül, fix hitelesítő adatokkal, 2FA nélkül.
Szoftverfejlesztő alvállalkozók: Forráskódtár-hozzáféréssel, éles deployment jogosultságokkal és CI/CD pipeline-integrációval rendelkezhetnek.
SaaS-szolgáltatók és felhőalapú eszközök: Adatfeldolgozóként kezelik a szervezet érzékeny adatait, miközben biztonsági szintjük nem transzparens és sokszor nem auditált.

2. Hozzáférés-minimalizálás: Least Privilege és Zero Trust a harmadik fél kapcsolatoknál

A horizontális támadási felület csökkentésének leghatásosabb infrastruktúra-szintű eszköze a harmadik fél hozzáférések szigorú minimalizálása és szegmentálása. Ez a terület az, ahol a legtöbb szervezet a legjelentősebb, azonnal orvosolható biztonsági résekkel rendelkezik.

2.1. A hagyományos site-to-site VPN kockázatai

A rögzített, állandó site-to-site VPN-kapcsolatok – amelyek a legelterjedtebb technológiai megoldást jelentik a harmadik fél hozzáférések biztosítására – strukturális biztonsági problémát hordoznak: implicit, kiterjedt megbízhatósági szintet biztosítanak a csatlakozó partner számára. Egy aktív site-to-site tunnel esetén a partnerhálózatból kompromittált eszköz közvetlenül érheti el mindazokat a hálózati erőforrásokat, amelyekre az alagút engedélye kiterjed – és az engedély tipikusan nem kerül rendszeresen felülvizsgálatra.

A hagyományos VPN-architektúra fő problémái harmadik fél kontextusban:

Az alagút folyamatosan aktív, akkor is, amikor a partnernek nincs aktív munkavégzése.
A hitelesítés tipikusan statikus tanúsítványon vagy PSK (pre-shared key) alapul, amelynek rotációja ritkán rendszeres.
A hozzáférési hatókör (scope) nehezen granulálható: az alagúton belül az oldalirányú mozgás (lateral movement) akadálytalan.
A partner infrastruktúrájának biztonsági állapota nem monitorozható a saját hálózatról.

2.2. Zero Trust Network Access (ZTNA) mint architekturális váltás

A Zero Trust biztonsági modell – amelynek alapelve, hogy egyetlen felhasználó, eszköz vagy hálózati szegmens sem kap alapértelmezett megbízhatóságot, pozíciójától függetlenül – a harmadik fél hozzáférések kezelésére különösen alkalmas architekturális keretet nyújt. A ZTNA (Zero Trust Network Access) megközelítés a fix VPN-tunnelek helyett hozzáférési bróker-rétegen keresztül, szükséglet- és identitásalapú, munkamenet-szintű hozzáférést biztosít.

A ZTNA alkalmazásának lényege harmadik fél kontextusban:

Alkalmazásszintű, nem hálózatszintű hozzáférés: A partner kizárólag a konkrétan szükséges alkalmazáshoz vagy rendszerhez kap hozzáférést, nem a teljes hálózati szegmenshez. Egy könyvelőiroda például csak a számlázási rendszerhez férhet hozzá, nem az azt futtató szerver teljes hálózati szomszédságához.
Folyamatos hitelesítés és jogosultságellenőrzés: A hozzáférés minden munkamenet elején újraigazolódik, és folyamatosan monitorozásra kerül. Szokatlan viselkedés esetén (eltérő geolokáció, szokatlan időpont, nagy adatmennyiség-mozgás) automatikus munkamenet-megszakítás vagy riasztás konfigurálható.
Eszközbiztonsági állapot-ellenőrzés (Device Posture Check): A belépés feltétele lehet, hogy a csatlakozó eszköz megfelel meghatározott biztonsági követelményeknek (operációs rendszer frissítési szint, végpontvédelmi szoftver jelenléte, lemeztitkosítás státusza).
Naplózás és auditálhatóság: Minden hozzáférési esemény, fájlmanipuláció és rendszerhívás naplózható és SIEM-rendszerbe exportálható, amelyre a NIS2 monitorozási követelménye vonatkozik.

Hazai és európai vállalati környezetben elérhető ZTNA-megoldások közé tartozik a Cloudflare Access, a Zscaler Private Access, a Microsoft Entra Private Access és a Palo Alto Prisma Access – ezek mindegyike integrálható meglévő identitásmenedzsment infrastruktúrával (Entra ID, Okta).

2.3. Privilegizált hozzáférések kezelése (PAM) harmadik felek esetén

Az adminisztratív jogosultságokkal rendelkező harmadik felek – például az infrastruktúrát üzemeltető MSP-k – esetén a ZTNA-n túl Privileged Access Management (PAM) megoldás alkalmazása szükséges. A PAM-rendszer (például CyberArk, BeyondTrust, Delinea) lehetővé teszi:

A privilegizált hitelesítő adatok tárolását és automatikus rotációját – a partner soha nem látja a tényleges jelszót, csak a PAM-rendszeren keresztül kap időkorlátozott, munkamenet-specifikus hozzáférést.
A teljes munkamenet videórögzítését és billentyűzet-naplózását (session recording), amely visszajátszható és auditálható.
Jóváhagyási munkafolyamat (approval workflow) bevezetését: a partner privilegizált hozzáférése csak belső felelős jóváhagyása után nyílik meg, és automatikusan zárul a jóváhagyott időablak lejártával.

3. NIS2 Beszállítói Audit Csekklista – technikai bizonyítékok mérnöki szemmel

A NIS2 beszállítói kockázatkezelés egy kritikus és az üzemeltetők által legtöbbször alulbecsült mozzanata az, hogy a partnerektől nem elegendő nyilatkozatot vagy kitöltött kérdőívet kérni – auditálható, konkrét technikai bizonyítékokat (artifacts) kell bekérni és értékelni. Az alábbiakban azokat a bizonyítékkategóriákat ismertetjük, amelyek egy mérnöki szempontból megalapozott partnerbiztonság-értékelés alapját képezik.

3.1. Sérülékenységvizsgálati és penetrációtesztelési dokumentáció

Bekérendő dokumentumok és az értékelési szempontok:

Legutóbbi külső penetrációtesztelési jelentés: Kizárólag independent, minősített tesztelő (OSCP, CREST, CHECK minősítés) által elvégzett, 12 hónapnál nem régebbi vizsgálat fogadható el. A partner által saját maga elvégzett, vagy általa megbízott, de nem auditálható minősítésű cég által készített jelentés nem elegendő. A jelentésben elvárás a kritikus és magas besorolású megállapítások feltüntetése és a remediation státuszuk dokumentálása.
Sérülékenységkezelési szabályzat és SLA: Milyen határidőn belül javítja a partner a kritikus CVE-ket (általánosan elfogadott elvárás: kritikus – 24–72 óra, magas – 7 nap, közepes – 30 nap)?
ASM (Attack Surface Management) riport: A partner által externálisan látható hálózati lábnyom dokumentálása, nyitott portok és expozíciós pontok listájával.

3.2. Logkezelési és monitorozási politika

SIEM-megoldás meglétének igazolása: Milyen biztonsági eseménynaplókat gyűjt, milyen megőrzési idővel (NIS2 szempontjából ajánlott minimum: 12 hónap online elérhetőség)?
Napló integritásvédelem: A naplófájlok módosítás ellen védett, write-once tárolón vagy külső SIEM-ben tárolódnak-e?
Incidensészlelési képesség: Van-e SOC (Security Operations Center) vagy MDR (Managed Detection and Response) szolgáltatás? Mi az átlagos észlelési és reagálási idő (MTTD/MTTR)?

3.3. Hozzáférés-kezelési érettség

MFA/2FA igazolása: Minden felhasználó számára kötelező-e a többfaktoros azonosítás, különösen a privilegizált hozzáférésekhez és a VPN-belépésekhez? Képernyőkép vagy konfigurációs export formájában kérhető bizonyíték.
Hozzáférési felülvizsgálati folyamat (Access Review): Milyen rendszerességgel kerülnek felülvizsgálatra a felhasználói jogosultságok? Van-e dokumentált, automatizált folyamat a kilépő alkalmazottak hozzáférésének visszavonására?
Privilegizált hozzáférések kezelése: Alkalmaz-e a partner PAM-megoldást? Rotálódnak-e a servicefiókok és az API kulcsok automatikusan?

3.4. Adatkezelési és titkosítási kontrollok

Titkosítás nyugalmi állapotban (encryption at rest): A partner által tárolt, a megbízó szervezetéhez tartozó adatok titkosítva tárolódnak-e (AES-256 vagy azzal egyenértékű)?
Titkosítás átvitel közben (encryption in transit): Kizárólag TLS 1.2 vagy újabb protokoll alkalmazása igazolható-e? A régi, elavult protokollok (SSL 3.0, TLS 1.0, TLS 1.1) letiltásra kerültek-e?
Adatkezelési helyek: A megbízó szervezet adatai kizárólag az EU-n vagy az EGT-n belül kerülnek-e tárolásra és feldolgozásra? Harmadik országba történő adattovábbítás esetén az adatátvitel jogalapja dokumentált-e?

3.5. Üzletmenet-folytonossági képesség (BCP/DR)

BCP és DR terv: Létezik-e tesztelt üzletmenet-folytonossági és katasztrófa-helyreállítási terv? Az utolsó DR-teszt dokumentációja bekérhető és értékelhető.
Mentési stratégia: Milyen mentési frekvenciával és megőrzési idővel rendelkezik a partner az érintett rendszerekre vonatkozóan? A mentések visszaállíthatóságát rendszeresen tesztelik-e?
RTO/RPO értékek: A partner által vállalt helyreállítási idő-célérték (RTO) és helyreállítási pont célérték (RPO) szerződésben rögzített-e, és reálisan teljesíthető-e az infrastruktúra alapján?

3.6. Incidenskezelési és értesítési kötelezettség

A NIS2 irányelv szigorú incidensbejelentési határidőket ír elő. Ezt a kötelezettséget a szerződéses kapcsolatokon keresztül a partnerekre is ki kell terjeszteni:

A partner szerződésben vállalja-e, hogy a megbízó szervezetet érintő biztonsági incidenst – annak észlelésétől számított meghatározott időn belül (ajánlott: 24 óra) – értesíti?
Rendelkezik-e a partner dokumentált, tesztelt incidenskezelési folyamattal (IR Plan)?
Ki a partner oldalán a biztonsági incidensek kapcsolattartója, és ez az elérhetőség naprakész-e?

4. Szoftveres ellátási lánc és az SBOM (Software Bill of Materials)

A SolarWinds-incidens nyomán az iparági figyelem a szoftver-ellátási lánc biztonságára összpontosul. Ha a partner szervezet egyedi szoftvert fejleszt vagy üzemeltet a megbízó számára – legyen az egyedi alkalmazás, integráció, WordPress-bővítmény, ERP-modul vagy API-összekötő – az ellátási lánc kockázata nem csupán a partner saját hálózati biztonsági szintjére korlátozódik, hanem kiterjed a szoftverben felhasznált nyílt forráskódú komponensekre is.

4.1. Mi az SBOM és miért vált kötelező elvárássá

Az SBOM (Software Bill of Materials) egy szoftvercsomag összes komponensét, függőségét, licencét és verziószámát tartalmazó strukturált leltár – a szoftver „összetevőlistája". Az Egyesült Államokban Biden elnök 2021-es kiberbiztonsági végrehajtási rendelete (EO 14028) kötelezővé tette az SBOM-ot a szövetségi kormánynak szállított szoftverek esetén; az EU Cyber Resilience Act (CRA) hasonló irányban halad és a várható hatálybalépést követően az európai szoftverszállítókra is vonatkozni fog.

NIS2 kontextusban az SBOM bekérése a partnertől az ellátási lánc kockázatkezelés egyik konkrét, mérnökileg operacionalizálható intézkedése.

4.2. Az SBOM tartalma és formátumai

Iparágban elfogadott SBOM-formátumok:

SPDX (Software Package Data Exchange): Linux Foundation által fejlesztett, ISO/IEC 5962:2021 szabványként is elfogadott formátum.
CycloneDX: OWASP által fejlesztett, elsősorban biztonsági fókuszú SBOM-formátum; közvetlen integrációt biztosít a sebezhetőségi adatbázisokkal.

Egy érdemi SBOM minimálisan a következőket tartalmazza: minden komponens neve és verziószáma, eredete (package registry vagy egyedi kód), licence típusa, és a komponens hashlenyomata (SHA-256 vagy erősebb).

4.3. SBOM-alapú sebezhetőségelemzés a gyakorlatban

Az SBOM önmagában nem nyújt védelmet – az értéke a felhasználásában van. Az SBOM-ból generált komponenslista automatikusan összevethető az NVD (National Vulnerability Database), az OSV (Open Source Vulnerabilities) vagy a GitHub Advisory Database sebezhetőségi adatbázisaival. Ez az összevetés elvégezhető:

A Dependency-Track (OWASP nyílt forráskódú platform) segítségével, amely folyamatosan monitorozza az SBOM-ban szereplő komponenseket és automatikus riasztást küld új CVE esetén.
CI/CD pipeline-ba integrált eszközökkel (Grype, Trivy, Syft), amelyek minden build során ellenőrzik a komponensek ismert sebezhetőségeit.
Kereskedelmi SCA (Software Composition Analysis) megoldásokkal (Snyk, Mend, Black Duck).

A partnerrel szemben elvárható minimumkövetelmény: az általuk fejlesztett szoftver minden kiadásához aktuális SBOM-ot csatolnak, és kötelezik magukat arra, hogy kritikus vagy magas besorolású CVE esetén meghatározott határidőn belül javítást szállítanak.

5. A kockázatarányos megközelítés: Nem minden partner egyforma

A NIS2 kockázatkezelési kötelezettségei arányosságot is várnak el: az erőforrásokat és az audit intenzitását a tényleges kockázati szinthez kell igazítani. Egy kis könyvelőirodát nem szükséges ugyanolyan mélységű technikai auditnak alávetni, mint egy olyan MSP-t, amely root hozzáféréssel rendelkezik a teljes szerver-infrastruktúrán.

5.1. Partnerminősítési mátrix

A partnerek kockázati szint szerinti besorolásához az alábbi két dimenzió kombinációja ad megbízható keretet:

Hozzáférési szint: Milyen mélységű és szélességű hozzáféréssel rendelkezik a partner a szervezet rendszereihez, adataihoz és hálózatához?
Adatérzékenység: Milyen kategóriájú adatokhoz fér hozzá vagy dolgoz fel a partner (nyilvános, belső, bizalmas, különleges kategóriájú személyes adat)?

Kockázati szint	Jellemző partnertípus	Minimálisan elvárt audit mélység
Kritikus	Külső IT-üzemeltető, MSP, felhőszolgáltató éles rendszerekkel	Teljes technikai audit, penetrációteszt-dokumentáció, PAM igazolás, helyszíni vagy remote audit évente
Magas	Szoftverfejlesztő alvállalkozó, ERP-integrátor, SOC-szolgáltató	SBOM, sebezhetőségkezelési SLA, 2FA igazolás, kérdőíves audit évente kiegészítő dokumentumokkal
Közepes	SaaS-szolgáltató, könyvelőiroda, HR-rendszer kezelője	Tanúsítvány (ISO 27001, SOC 2 Type II), adatfeldolgozói szerződés, 2FA igazolás, éves kérdőív
Alacsony	Irodaszerszállító, nem digitális partneri kapcsolat	Alapvető szerződéses nyilatkozat, önértékelési kérdőív

5.2. Folyamatos monitorozás a pontszerű audit helyett

Az éves partneraudit szükséges, de nem elegendő: a kockázati állapot folyamatosan változik. A partnerek kiberkockázati szintjének folyamatos nyomon követéséhez külső fenyegetésintelligencia és digitálislábnyom-monitorozó (DRPS – Digital Risk Protection Service) megoldások integrálhatók, amelyek automatikusan jelzik, ha egy partner által üzemeltetett rendszerben ismert CVE jelenik meg, ha a partner domainjét adathalász infrastruktúraként azonosítják, vagy ha a partner IP-tartományából kompromittált forgalom mintázatát azonosítják.

6. A NIS2-konform partnerbiztonság-kezelés folyamata – összefoglalás

A fentieket összefoglalva, a NIS2 beszállítói kockázatkezelés érett, auditálható folyamata öt egymásra épülő lépésből áll:

Partnerinventár és kockázati besorolás: Az összes aktív harmadik fél kapcsolat feltérképezése, hozzáférési szint és adatérzékenység alapján történő kockázati osztályba sorolással.
Szerződéses keret kialakítása: Adatfeldolgozói szerződések, biztonsági mellékletek és incidensértesítési SLA-k beépítése minden releváns partnerszerződésbe.
Technikai audit végrehajtása: Kockázati szint alapján differenciált, bizonyíték-alapú technikai ellenőrzés a jelen cikkben ismertetett szempontrendszer szerint.
Hozzáférés-minimalizálás és ZTNA-bevezetés: A harmadik fél hozzáférések infrastruktúra-szintű felülvizsgálata és szükség esetén ZTNA/PAM-alapú architektúrára való átállás.
Folyamatos monitorozás és rendszeres felülvizsgálat: A partnerek biztonsági állapotának folyamatos nyomon követése, az audit évente, kockázati esemény esetén soron kívül megismétlendő.

A fenti folyamat nemcsak a NIS2 szerinti megfelelőséget alapozza meg, hanem azokat a szervezeteket is védi, amelyek jelenleg nem esnek közvetlenül a szabályozás hatálya alá – a partneri elvárások és a láncreakció-hatás révén az ellátási lánc biztonságának javítása a teljes ökoszisztéma ellenálló képességét növeli.

Ez a cikk kizárólag tájékoztató jellegű és nem minősül jogi tanácsadásnak. A konkrét szervezeti kockázatértékelés, partnerbiztonság-kezelési folyamat és NIS2-megfelelőségi stratégia kialakításához minősített kiberbiztonsági tanácsadó bevonása szükséges.

NIS2 beszállítói kockázatkezelés: Hogyan auditáljuk a külső partnereket és alvállalkozókat?