Zero Trust-architektúra 2026-ban: auditkész bizonyítékok

A hétfő reggeli Zero Trust-audit, amelyre senki sem készült

Hétfőn 08:12-kor egy európai SaaS fintech vállalat információbiztonsági vezetője öt percen belül három üzenetet kap.

Az első egy banki ügyféltől érkezik: „Kérjük, küldjék meg a Zero Trust-architektúrára vonatkozó bizonyítékcsomagot az éves IKT-beszállítói felülvizsgálatunkhoz.”

A második a jogi területtől jön: „Egy tagállamban a NIS2 szerint fontos szervezetnek minősülhetünk, és néhány ügyfél azt kérdezi, hogy a DORA követelményei IKT-szolgáltatóként ránk is továbbhárulnak-e.”

A harmadik a mérnöki vezetőtől érkezik: „Van MFA, SSO, EDR, Kubernetes hálózati szabályok és SIEM-riasztások. Ez már Zero Trust?”

Itt akad el sok szervezet. Vannak biztonsági eszközeik, de nincs Zero Trust megfelelési működési modelljük. Tudnak MFA-képernyőképeket mutatni, de nem tudják elmagyarázni, hogyan illeszkedik egymáshoz az identitás, az eszközállapot, a legkisebb jogosultság elve, a szegmentálás, a felügyelet, az incidensbejelentés, az adatvédelmi intézkedések és a beszállítói függőségek rendszere. Kontrollokat tudnak bemutatni, de visszakövethetőséget nem.

2026-ban a NIST SP 800-207 alapú Zero Trust-architektúrának többnek kell lennie annál, mint hogy „soha ne bízz, mindig ellenőrizz”. A CISO-k, a megfelelőségért felelős vezetők, az auditorok és az üzleti tulajdonosok számára a gyakorlati kérdés ennél pontosabb:

Hogyan alakítható a Zero Trust olyan bizonyítékká, amely megfelel az ISO/IEC 27001:2022, a NIS2 kiberhigiéniai elvárásai, a DORA IKT-kockázatkezelése, a GDPR Article 32 szerinti adatkezelés biztonsága, az ügyféloldali kellő gondosság és az igazgatósági felügyelet követelményeinek?

A válasz nem egy újabb eszköz. A válasz egy kockázatalapú bizonyítékmodell, amely összekapcsolja a szabályzatokat, a kontrollokat, a technikai megvalósítást, a felügyeletet és a vezetői elszámoltathatóságot.

Zero Trust 2026-ban: biztonsági stratégiából megfelelési bizonyíték

A NIST SP 800-207 a Zero Trust fogalmát olyan elvek összességeként határozza meg, amelyek biztonságos rendszerek tervezésére és üzemeltetésére szolgálnak olyan környezetben, ahol a bizalom soha nem implicit. A hozzáférés identitás, kontextus, szabályzat, vagyonelem-állapot és folyamatos értékelés alapján adható meg.

A NIST hét Zero Trust alapelve különösen hasznos, mert egy homályos biztonsági jelmondatot leképezhető, tesztelhető és auditálható rendszerré alakít:

1. Minden adatforrás és számítási szolgáltatás erőforrásnak minősül.
2. Minden kommunikációt védeni kell, függetlenül a hálózati helytől.
3. Az egyes vállalati erőforrásokhoz való hozzáférés munkamenetenként adható meg.
4. Az erőforrásokhoz való hozzáférést dinamikus szabályzat határozza meg, beleértve az identitás-, eszköz-, alkalmazás- és viselkedési attribútumokat.
5. A vállalat figyeli és méri a saját és kapcsolódó vagyonelemek sértetlenségét és biztonsági állapotát.
6. Minden erőforrás hitelesítése és engedélyezése dinamikus, és a hozzáférés engedélyezése előtt szigorúan érvényesített.
7. A vállalat információkat gyűjt a vagyonelemekről, az infrastruktúráról és a kommunikációról, majd ezeket a kockázati helyzet javítására használja.

Egy modern SaaS-szolgáltató, digitális bank, menedzselt szolgáltató vagy felhőnatív platform esetében ezek az elvek gyakorlati kontrollterületekké alakíthatók:

• Az identitás ellenőrzött és irányított.
• Az eszközöket a hozzáférés megadása előtt értékelik.
• Az emelt jogosultságú hozzáférés minimalizált és felülvizsgált.
• A hálózati útvonalak szegmentáltak és szabályozottak.
• Az alkalmazások, API-k és adattárak érvényesítik az engedélyezést.
• A naplók és telemetriai adatok támogatják a folyamatos felügyeletet.
• Az incidensek elszigetelést, jelentéstételt és helyreállítást indítanak el.
• A bizonyítékok igazolják, hogy a kontrollok működnek, nem csupán megtervezettek.

Ezen az utolsó ponton lép be a megfelelés.

Az ISO/IEC 27001:2022 előírja, hogy a szervezetek határozzák meg a kontextust, az érdekelt feleket, az alkalmazandó jogi és szerződéses követelményeket, a hatókört, az interfészeket és a függőségeket. Előírja továbbá a kockázatértékelést, a kockázatkezelést, az alkalmazhatósági nyilatkozatot, a vezetői elszámoltathatóságot, a belső auditot, a vezetőségi felülvizsgálatot és a folyamatos fejlesztést.

A Zero Trust természetesen illeszkedik ebbe a struktúrába, ha kontrollrendszerként kezelik. Nem állhat az IBIR-en kívül mérnöki kezdeményezésként. A kockázatértékelés, a kontrollkiválasztás, a szabályzatirányítás, a beszállító-kezelés, az adatvédelem, az incidensreagálás és az igazgatósági jelentéstétel részének kell lennie.

A Zero Trust-bizonyítékok mögötti szabályozói nyomás

A Zero Trust-bizonyítékok iránti igény általában átfedő kötelezettségekből ered, nem egyetlen szabványból.

A NIS2 alkalmazandó lehet az I. melléklet vagy II. melléklet szerinti ágazatokba tartozó köz- vagy magánszervezetekre, ha megfelelnek a méret- és tevékenységi küszöbértékeknek, továbbá bizonyos kisebb, de kritikus szervezetekre is. Az I. melléklet körébe tartoznak a felhőszolgáltatók, adatközpont-szolgáltatók, tartalomszolgáltató hálózati szolgáltatók, bizalmi szolgáltatók, menedzselt szolgáltatók, menedzselt biztonsági szolgáltatók, valamint banki és pénzügyi piaci infrastruktúra-szervezetek. A II. melléklet olyan digitális szolgáltatókat tartalmaz, mint az online piacterek, keresőmotorok és közösségi hálózati platformok.

A NIS2 Article 20 a kiberbiztonságot a vezető testület felelősségévé teszi. Az igazgatóságnak jóvá kell hagynia a kiberbiztonsági kockázatkezelési intézkedéseket, felügyelnie kell azok végrehajtását, és kiberbiztonsági képzésben kell részesülnie. Az Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő, amelyek kiterjednek a kockázatelemzésre, az incidenskezelésre, az üzletmenet-folytonosságra, az ellátási lánc biztonságára, a biztonságos fejlesztésre, a sérülékenységek kezelésére, az eredményesség értékelésére, a kiberhigiéniára, a képzésre, a kriptográfiára, a HR-biztonságra, a hozzáférés-szabályozásra, az eszközkezelésre, valamint adott esetben az MFA-ra vagy a folyamatos hitelesítésre. Az Article 23 szakaszos jelentéstételt vezet be a jelentős incidensekre, beleértve a 24 órás korai figyelmeztetést, a 72 órás értesítést és a zárójelentést.

A DORA 2025. január 17-től alkalmazandó, és egységes digitális működési reziliencia-rendszert hoz létre a pénzügyi szervezetek számára. Kiterjed az IKT-kockázatkezelésre, a jelentős IKT-vonatkozású incidensek jelentésére, a működési reziliencia tesztelésére, a fenyegetettségi információk megosztására és az IKT harmadik félhez kapcsolódó kockázatra. A DORA Articles 5 és 6 irányítást és dokumentált IKT-kockázatkezelési keretrendszert ír elő. Az Article 9 a védelemmel és megelőzéssel foglalkozik, beleértve az IKT-rendszerek védelmét szolgáló szabályzatokat, eljárásokat, protokollokat és eszközöket. Az Article 17 IKT-vonatkozású incidenskezelési folyamatot ír elő.

A GDPR alkalmazandó az EU-ban lévő tevékenységi hely keretében végzett adatkezelésre, valamint az EU-n kívüli adatkezelőkre vagy adatfeldolgozókra is, ha az EU-ban tartózkodó személyeknek kínálnak árukat vagy szolgáltatásokat, illetve figyelik viselkedésüket. A GDPR Article 5 elszámoltathatóságot ír elő. Az Article 32 megfelelő technikai és szervezési intézkedéseket követel meg a kockázatnak megfelelő biztonsági szint biztosítására. Az Article 33 előírja a személyesadat-sértés bejelentését a felügyeleti hatóságnak indokolatlan késedelem nélkül, és lehetőség szerint a jogsértésről való tudomásszerzéstől számított 72 órán belül.

A Zero Trust bizonyítékmodell azért hasznos, mert ugyanaz a kontroll több keretrendszert is támogathat. Az MFA támogathatja az ISO/IEC 27001:2022 hozzáférés-szabályozását, a NIS2 hitelesítési intézkedéseit, a DORA védelmi követelményeit és a GDPR szerinti adatkezelés biztonságát. De csak akkor, ha a szervezet igazolni tudja a hatályt, a felelősséget, a megvalósítást, a felügyeletet és a felülvizsgálatot.

A NIST Zero Trust alapelvek megfeleltetése az ISO/IEC 27001:2022 kontrolloknak

Az ISO/IEC 27001:2022 A melléklet szerinti kontrolljai, az ISO/IEC 27002:2022 megvalósítási útmutatásával támogatva, megadják azt az auditnyelvet, amelyre a legtöbb szervezetnek szüksége van. Az alábbi táblázat a NIST Zero Trust alapelveit olyan ISO-kontrollterületekre fordítja le, amelyeket az auditorok felismernek.

Ez a megfeleltetés nem pusztán technikai tervezési feladat. Ez adja a kockázati nyilvántartás, az alkalmazhatósági nyilatkozat, a bizonyítékcsomag és a vezetőségi felülvizsgálati napirend szerkezetét.

Például egy olyan kockázati forgatókönyvet, mint „kompromittálódott fejlesztői fiók módosítja az éles kódot és hozzáfér az ügyféladatokhoz”, az identitáskezeléshez, az MFA-hoz, az emelt jogosultságú hozzáféréshez, a hálózati szegmentáláshoz, a naplózáshoz, a felügyelethez, a biztonságos fejlesztéshez, a változáskezeléshez és az incidensreagáláshoz kell rendelni. Ez az egy forgatókönyv támogathatja az ISO/IEC 27001:2022, a NIS2 Article 21, a DORA IKT-kockázatkezelés és a GDPR Article 32 követelményeit.

A Clarysec Zero Trust kontrollrétege

A Clarysec a Zero Trust modellt öt bizonyítékterület köré építi: identitás, eszköz, hálózat, alkalmazás és adat, mind az öt felett felügyelettel és irányítással.

Az alapot a hozzáférés-szabályozás és az identitáskezelés adja. A Zenith Controls: keretrendszereken átívelő megfelelési útmutató szerint az ISO/IEC 27002:2022 5.15 kontroll, Hozzáférés-szabályozás, megelőző kontrollként van besorolva, amely a bizalmasságot, sértetlenséget és rendelkezésre állást támogatja, összhangban a Protect kiberbiztonsági koncepcióval és az Identity and Access Management képességgel. Az 5.16 kontroll, Identitáskezelés, szintén megelőző jellegű, és ugyanazokhoz a CIA-tulajdonságokhoz, valamint IAM-képességhez kapcsolódik. A 8.16 kontroll, Felügyeleti tevékenységek, észlelő és helyesbítő kontrollként van besorolva, amely az információbiztonsági eseménykezelésen keresztül támogatja a Detect és Respond funkciókat.

Ez a kombináció lényeges. A Zero Trust nem pusztán hozzáférés-szabályozás. Hozzáférés-szabályozás, identitáséletciklus, eszközállapot, hálózati szegmentálás, felügyelet és reagálás együttese.

A Clarysec szabályzati pontjai ezt a modellt betartatható irányítássá alakítják.

A vállalati Hozzáférés-szabályozási szabályzat Célkitűzések szakaszának 3.4 pontja szerint:

A Zero Trust-elvek támogatása azzal, hogy a hozzáférés alapértelmezetten tiltott, kivéve, ha azt kifejezetten jóváhagyták és indokolták.

A vállalati Felhasználói fiók- és jogosultságkezelési szabályzat A szabályzat végrehajtásának követelményei szakaszának 6.2.1 pontja szerint:

Minden felhasználóhoz a munkaköri feladatai ellátásához szükséges minimális hozzáférési szintet kell hozzárendelni.

A vállalati Hálózatbiztonsági szabályzat Irányítási követelmények szakaszának 5.2 pontja szerint:

Minden zónák közötti forgalmat tűzfalakkal vagy szoftveresen meghatározott peremvédelmi megoldásokkal kell szabályozni, kifejezett, alapértelmezett tiltáson alapuló konfigurációkkal.

A vállalati Naplózási és felügyeleti szabályzat Célkitűzések szakaszának 3.4 pontja szerint:

Központi naplózási és riasztási rendszereket kell létrehozni (pl. SIEM), amelyek közel valós időben aggregálják, korrelálják és eszkalálják a gyanús tevékenységeket.

A vállalati Információbiztonsági szabályzat A szabályzat végrehajtásának követelményei szakaszának 6.6.1 pontja szerint:

Minden bevezetett kontrollnak auditálhatónak kell lennie, dokumentált eljárásokkal és a működés megőrzött bizonyítékaival alátámasztva.

KKV-k esetében ugyanez az irányítási szándék könnyített szabályzati dokumentációval is megvalósítható. A Felhasználói fiók- és jogosultságkezelési szabályzat – KKV Célkitűzések szakaszának 3.2 pontja kimondja:

A legkisebb jogosultság elvének érvényesítése, biztosítva, hogy a felhasználók kizárólag a feladataik ellátásához szükséges minimális hozzáférési szintet kapják meg.

A Hozzáférés-szabályozási szabályzat – KKV Irányítási követelmények szakaszának 5.4.3 pontja hozzáteszi:

Az emelt jogosultságú fiókoknak többtényezős hitelesítést (MFA) kell használniuk, ahol ez támogatott.

A Hálózatbiztonsági szabályzat – KKV A szabályzat végrehajtásának követelményei szakaszának 6.2.3 pontja szerint:

A szegmensek közötti forgalmat szűrni kell, és a szegmensek közötti hozzáférésnek a legkisebb jogosultság elvét kell követnie.

A Naplózási és felügyeleti szabályzat – KKV Cél szakaszának 1.3 pontja szerint:

A naplózás és a felügyelet támogatja a fenyegetésészlelést, a jogszabályi megfelelést, az incidensbejelentést és -kezelést, valamint a forenzikus elemzést.

Az adatvédelem által vezérelt Zero Trust esetében az Adatvédelmi és magánszféra-védelmi szabályzat – KKV Irányítási követelmények szakaszának 5.3.2 pontja kimondja:

A személyes adatokhoz való felhasználói hozzáférést dokumentált üzleti igénnyel rendelkező szerepkörökre kell korlátozni.

Ezek a pontok auditálási horgonyokat hoznak létre. Az auditor tesztelheti, hogy a hozzáférés alapértelmezetten tiltott-e, a jogosultság minimalizált-e, a zónák közötti forgalom szabályozott-e, a naplók központosítottak-e, és a bizonyítékokat megőrzik-e.

Keretrendszereken átívelő Zero Trust bizonyítéktérkép

Egy erős Zero Trust bizonyítékmodellnek kerülnie kell a széttöredezett képernyőképeket. A bizonyítékoknak az irányítást, a tervezést, a megvalósítást, a felügyeletet és a felülvizsgálatot kell bemutatniuk.

Ez a táblázat egy igazgatóság számára is értelmezhető Zero Trust program magja. Megmutatja, hogyan támogathat egyetlen kontrollkörnyezet több bizonyossági igényt anélkül, hogy minden keretrendszerhez külön bizonyítékcsomag készülne.

Visszakövethetőség kialakítása a Zenith Blueprint segítségével

A Clarysec Zenith Blueprint: 30 lépéses auditütemterv arra készült, hogy megakadályozza a Zero Trust dokumentálatlan mérnöki filozófiává válását. A Kockázatkezelés fázis 13. lépése, Kockázatkezelési tervezés és alkalmazhatósági nyilatkozat, így magyarázza:

Az SoA lényegében áthidaló dokumentum: összekapcsolja a kockázatértékelést és kockázatkezelést a
ténylegesen meglévő kontrollokkal. Kitöltésével azt is ellenőrizheti, hogy kimaradt-e bármely kontroll.

Ugyanez a lépés javasolja a kontrollok kockázatokhoz rendelését, az A melléklet szerinti kontrollhivatkozások hozzáadását a kockázatkezelési bejegyzésekhez, valamint az olyan szabályozások kereszthivatkozását, mint a GDPR, NIS2 vagy DORA, amennyiben a kontrollokat e kötelezettségek teljesítésére vezették be.

A Zero Trust esetében ez a hiányzó híd. Ha egy auditor megkérdezi, miért vezettek be feltételes hozzáférést, a válasz nem lehet az, hogy „mert a Zero Trust ezt mondja”. Jobb válasz:

• A kockázati forgatókönyv az ügyféladatokhoz történő jogosulatlan hozzáférés kompromittálódott hitelesítő adatokkal.
• A kockázatgazda a CTO vagy a mérnöki vezető.
• A kockázatkezelés része az SSO, az MFA, a feltételes hozzáférés, a végponti eszközállapot ellenőrzése, a legkisebb jogosultság elve, a szegmentálás és a felügyelet.
• Az SoA a kockázatkezelést hozzáférés-szabályozáshoz, identitáskezeléshez, naplózáshoz, felügyelethez, kriptográfiához, sérülékenységkezeléshez és felhőszolgáltatás-kezeléshez rendeli.
• Ugyanez a kockázatkezelés támogatja a NIS2 Article 21, a DORA IKT-kockázatkezelés és a GDPR Article 32 követelményeit.
• A bizonyítékok közé tartoznak a szabályzati pontok, hozzáférés-felülvizsgálatok, SIEM-riasztások, EDR eszközállapot-jelentések, tűzfalszabályok, IAM-exportok, incidensgyakorlatok és vezetőségi felülvizsgálati jegyzőkönyvek.

Így válik a Zero Trust-architektúra auditkész rendszerré.

Végponti bizalom, API-k és hálózati szegmentálás a gyakorlatban

A Zero Trust gyakran azért bukik el, mert a szervezetek az identitásra koncentrálnak, miközben figyelmen kívül hagyják az eszköz-, munkaterhelés-, adat- és hálózati kontextust.

A Zenith Blueprint 19. lépése, Technikai kontrollok I., világosan bemutatja a végponti eszközállapot követelményét:

Az információkhoz végpontokon keresztül történő hozzáférésnek kontextusfüggőnek kell lennie. Például megfelel-e az eszköz
a minimális biztonsági szabványoknak, mielőtt vállalati erőforrásokhoz férne hozzá? Nemrég sikeresen lefutott-e rajta
kártékony kód elleni vizsgálat? Szokatlan helyről vagy hálózatról csatlakozik-e? A Zero
Trust elvekkel integrálva a végponti eszközállapot feltételes hozzáférésbe táplálható, és megtagadhatja a belépést, amíg az
eszköz nem igazolja, hogy biztonságos.

Ez az eszközt az engedélyezési döntés részévé teszi. Egy nem felügyelt laptopról érkező érvényes jelszót nem szabad ugyanúgy kezelni, mint egy megfelelő, titkosított és felügyelt vállalati végpontról érkező érvényes bejelentkezést.

Ugyanez a lépés hangsúlyozza, hogy a hozzáférési korlátozások az alkalmazásokra, szolgáltatásokra és API-kra is vonatkoznak, nem csak a felhasználókra:

A hozzáférési korlátozásokat alkalmazásokra, szolgáltatásokra és API-kra is alkalmazni kell, nem csak személyekre.
Például egy mikroszolgáltatásnak lehet, hogy csak olvasási hozzáférésre van szüksége egy adatbázistáblához, nem teljes CRUD
jogosultságokra. Egy biztonsági mentési eszköznek lehet, hogy csak meghatározott tároló bucketekhez kell hozzáférnie, nem minden tenant erőforráshoz.

Ez az útmutatás kritikus a felhőnatív környezetekben. Az API-hatóköröknek, szolgáltatásfiókoknak, munkaterhelés-identitásoknak, Kubernetes-szerepköröknek és felhő IAM-szabályzatoknak mind a legkisebb jogosultság elvét kell követniük. Az emberi hozzáférés csak a kontrollfelület egyik része.

A Zenith Blueprint 20. lépése a hálózatok szétválasztásával foglalkozik:

A szétválasztás a kiberbiztonság egyik legrégebbi és leghatékonyabb elve: korlátozni a
terjedést, csökkenteni a kockázatot és elszigetelni a kárt. A 8.22 kontroll a hálózatok
szétválasztására összpontosít, vagyis a rendszerek, szolgáltatások és felhasználók különböző logikai vagy
fizikai zónákba történő elkülönítésére a jogosulatlan hozzáférés megelőzése és kompromittálódás esetén
a laterális mozgás korlátozása érdekében.

Ez kritikus a DORA és a NIS2 szerinti reziliencia szempontjából. Egy Zero Trust hálózatnak abból kell kiindulnia, hogy egy fiók, munkaterhelés vagy végpont kompromittálódhat. A szegmentálás megakadályozza, hogy egy helyi esemény rendszerszintű incidenssé váljon.

10 napos Zero Trust bizonyítékcsomag

Képzeljünk el egy SaaS fintech vállalatot, amely csaláselemzést nyújt bankoknak. Személyes adatokat kezel, felhőinfrastruktúrát használ, menedzselt Kubernetesre támaszkodik, ügyfél API-kkal integrálódik, és harmadik fél identitásszolgáltatót használ. Egy ügyfél Zero Trust-bizonyítékokat kér, a vállalatnak pedig tíz munkanapja van.

Egy gyakorlati Clarysec bizonyíték-sprint így nézne ki.

A cél nem annak színlelése, hogy a szervezet tíz nap alatt tökéletes Zero Trust állapotot ért el. A cél egy igazolható bizonyítéklánc létrehozása a legfontosabb kockázatokhoz, valamint annak bizonyítása, hogy a program irányított, mérhető és fejlődik.

Hogyan tesztelik a különböző auditorok a Zero Trust modellt

Gyakori hiba egyetlen technikai történetet előkészíteni, és feltételezni, hogy minden auditor ugyanazokat a kérdéseket teszi fel. Nem fogják.

Egy ISO/IEC 27001:2022 auditor az irányítási rendszert fogja keresni. Megkérdezi, hogy a Zero Trust kockázatok szerepelnek-e a kockázatértékelésben, a kezelések jóváhagyottak-e, az SoA teljes-e, a szabályzatok kontrollált dokumentumok-e, történnek-e hozzáférés-felülvizsgálatok, a belső auditok tesztelik-e a kontrollokat, és a vezetőségi felülvizsgálatok követik-e a teljesítményt.

Egy DORA felülvizsgáló azt kérdezi majd, hogy a Zero Trust kontrollok részei-e a dokumentált IKT-kockázatkezelési keretrendszernek. Elvárja a vagyonelem- és függőségi nyilvántartásokat, a kritikus vagy fontos funkciók feltérképezését, az incidensosztályozást, az igazgatósági eszkalációt, a tesztelést, a harmadik felekre vonatkozó szerződéses követelményeket, az auditálási jogokat, a kilépési stratégiákat és a helyesbítő intézkedések követését.

Egy NIS2 értékelő a vezető testület elszámoltathatóságára, az Article 21 szerinti kiberbiztonsági kockázatkezelési intézkedésekre és az Article 23 szerinti incidensbejelentési felkészültségre összpontosít. Bizonyítékot vár arra is, hogy az ellátási lánc biztonsága, az üzletmenet-folytonosság, a sérülékenységek kezelése, a hozzáférés-szabályozás és a kiberhigiénia irányított.

Egy GDPR felülvizsgáló vagy adatvédelmi auditor azt kérdezi majd, hogy a személyes adatokhoz való hozzáférés szükséges, dokumentált, korlátozott, felügyelt és összhangban van-e az adatkezelési célokkal. Vizsgálni fogja az adatkezelői és adatfeldolgozói szerepeket, a személyesadat-sértés észlelését, a szerepköralapú hozzáférést, a titkosítást, adott esetben az álnevesítést, a megőrzést és az elszámoltathatóságot.

Ugyanaz a kontroll több kérdést is megválaszolhat, de csak akkor, ha a bizonyítékok rendezettek.

Beszállítói, felhő- és IKT harmadik félhez kapcsolódó kockázat

A Zero Trust nem áll meg a tűzfalnál, és felhőkörnyezetekben hagyományos tűzfalhatár egyáltalán nem is feltétlenül létezik. Az identitásszolgáltatók, felhőplatformok, CI/CD eszközök, menedzselt észlelési szolgáltatók, fizetési szolgáltatók, API-átjárók és kiszervezett fejlesztési csapatok mind a bizalmi szövet részévé válnak.

A NIS2 Article 21 kifejezetten tartalmazza az ellátási lánc biztonságát a közvetlen beszállítók és szolgáltatók esetében, beleértve a beszállítói sérülékenységeket, a termék- és szolgáltatásrezilienciát, a beszállítói kiberbiztonsági gyakorlatokat és a biztonságos fejlesztési eljárásokat.

A DORA előírja, hogy az IKT harmadik félhez kapcsolódó kockázatot az IKT-kockázatkezelési keretrendszer részeként kell kezelni, IKT-szolgáltatási szerződések nyilvántartásával, szerződéskötés előtti kellő gondossággal, a kritikusság értékelésével, koncentrációs kockázattal, szerződéses biztonsági követelményekkel, incidenskezelési támogatással, hatósági együttműködéssel, auditálási jogokkal, felmondási jogokkal, kilépési stratégiákkal és átállási tervekkel.

A Zero Trust gyakorlati szabálya egyszerű: a beszállítói kapcsolatban nem szabad megbízni pusztán azért, mert szerződéses. Technikai kontrollokat és bizonyítékokat kell megkövetelni.

Egy ügyfél API-integrációnak célzott tokenekkel, sebességkorlátozással, felügyelettel, rotációval, tulajdonosi felelősséggel és visszavonással kell rendelkeznie. Egy menedzselt szolgáltatónak MFA-t, névre szóló felhasználói fiókokat, a legkisebb jogosultság elvét, munkamenet-naplózást és időkorlátos hozzáférést kell használnia. Egy felhőszolgáltatói kapcsolatnak megosztott felelősségi megfeleltetést, titkosítási konfigurációt, naplómegőrzést, biztonsági mentési tesztelést és kilépési tervezést kell tartalmaznia.

Ezért a beszállítói és felhőbizonyítékoknak a Zero Trust modellben van a helyük, nem egy külön beszerzési mappában.

Mutatók, amelyek igazolják, hogy a Zero Trust működik

Az igazgatóságok és auditorok nem csak architektúra-ábrákat akarnak. Működési bizonyítékokat és javulási trendeket várnak.

Hasznos Zero Trust mutatók többek között:

• Az MFA-val védett emelt jogosultságú fiókok aránya.
• A feltételes hozzáféréssel lefedett felhasználók aránya.
• Az állandó emelt jogosultságú fiókok száma a just-in-time fiókokhoz képest.
• A lejárt határidejű hozzáférés-felülvizsgálatok száma.
• Az eszközállapot-követelményeknek megfelelő végpontok aránya.
• EDR-lefedettség a kritikus vagyonelemeken.
• Az eszköz- vagy helyalapú kockázat miatt megtagadott hozzáférési kísérletek száma.
• A gyanús emelt jogosultságú tevékenység észleléséig eltelt átlagos idő.
• A kiléptetés utáni hozzáférés-visszavonásig eltelt átlagos idő.
• Az elmúlt negyedévben felülvizsgált zónák közötti tűzfalszabályok aránya.
• Aktuális biztonsági bizonyítékokkal rendelkező kritikus beszállítók száma.
• A helyesbítési határidőn túli Zero Trust kivételek száma.
• A SIEM-be naplókat küldő kritikus alkalmazások aránya.
• Hitelesítő adatok kompromittálódására vonatkozó incidensszimulációk eredményei.

Ezek a mutatók támogatják az ISO/IEC 27001:2022 szerinti folyamatos fejlesztést, a NIS2 eredményességértékelését, a DORA tesztelési és helyesbítési elvárásait, valamint a GDPR szerinti elszámoltathatóságot.

Gyakori Zero Trust bizonyítékhiányosságok

A leggyakoribb hibákat nem az eszközök hiánya okozza. A probléma a gyenge visszakövethetőség.

Először: a szervezetek bevezetik az MFA-t, de nem tudják igazolni, hogy az emelt jogosultságú fiókok teljes körűen lefedettek. A szolgáltatásfiókok, a vészhelyzeti rendszergazdai fiókok és a helyi adminisztrátori fiókok gyakran kívül maradnak a kontrollon.

Másodszor: a hozzáférés-felülvizsgálatokat manuálisan elvégzik, de nem kapcsolják üzleti szerepkörökhöz, adatérzékenységhez vagy kockázatgazdákhoz. A bizonyíték azt mutatja, hogy valaki rákattintott a „felülvizsgálva” gombra, nem azt, hogy a szükségtelen hozzáférést eltávolították.

Harmadszor: a hálózati szegmentálás létezik az ábrákon, de nincs tesztelt szabályokkal alátámasztva. Az auditorok meg fogják kérdezni, hogy a szegmensek közötti hozzáférés alapértelmezetten tiltott-e, és a kivételek jóváhagyottak-e.

Negyedszer: a naplókat gyűjtik, de nem hasznosíthatók. Egy SIEM meghatározott használati esetek, riasztási előszűrés és reagálási eljárások nélkül nem igazolja a folyamatos felügyeletet.

Ötödször: a beszállítói hozzáférés nincs kezelve. A beszállítók használhatnak megosztott fiókokat, tartós VPN-hozzáférést vagy túl széles felhőszerepköröket munkamenet-megfigyelés nélkül.

Hatodszor: az adatvédelmi bizonyítékok el vannak választva a biztonsági bizonyítékoktól. A GDPR a személyes adatok igazolható védelmét követeli meg, ezért az identitás- és hozzáférési kontrolloknak kapcsolódniuk kell az adatkategóriákhoz és az adatkezelési célokhoz.

Végül: a kivételek dokumentálatlanok. A Zero Trust el tud viselni kivételeket, ha azok kockázatértékeltek, jóváhagyottak, időkorlátosak és felügyeltek. Láthatatlan kivételeket nem tud elviselni.

Építse fel Zero Trust bizonyítékcsomagját a Clarysec segítségével

A Zero Trust-architektúra 2026-ban nem jelmondat. Megfelelési működési modell, amely az identitást, az eszközöket, az alkalmazásokat, a hálózati szegmentálást, a legkisebb jogosultság elvét, a folyamatos felügyeletet, a beszállítói kontrollt és az adatvédelmi intézkedéseket egyetlen auditálható rendszerbe kapcsolja össze.

Ha ISO/IEC 27001:2022 tanúsításra készül, NIS2 ügyfélmegkeresésekre válaszol, DORA IKT-kockázatkezeléshez igazodik, vagy a GDPR Article 32 szerinti adatkezelés biztonságát kívánja igazolni, kezdje a visszakövethetőséggel.

Használja a Zenith Blueprint: 30 lépéses auditütemterv anyagot a Zero Trust kockázatok kockázati nyilvántartásba, kockázatkezelési tervbe és SoA-ba történő leképezéséhez. Használja a Zenith Controls: keretrendszereken átívelő megfelelési útmutató anyagot a hozzáférés-szabályozás, identitáskezelés és felügyelet több keretrendszeren átívelő elvárásokhoz igazításához. Használja a Clarysec szabályzattárát, beleértve a vállalati Hozzáférés-szabályozási szabályzatot, a vállalati Felhasználói fiók- és jogosultságkezelési szabályzatot, a vállalati Hálózatbiztonsági szabályzatot, a vállalati Naplózási és felügyeleti szabályzatot, a vállalati Információbiztonsági szabályzatot és az Adatvédelmi és magánszféra-védelmi szabályzat – KKV, hogy az architektúrát betartatható irányítássá alakítsa.

A következő gyakorlati lépés egy magas kockázatú forgatókönyv kiválasztása, például az ügyféladatokhoz történő kompromittálódott emelt jogosultságú hozzáférés, majd egy teljes Zero Trust bizonyítéklánc felépítése köré. Ha ezt a forgatókönyvet végponttól végpontig igazolni tudja, megvan az alapja egy skálázható, auditálható és szabályozói szempontból felkészült Zero Trust programnak.

Töltse le a Clarysec szabályzatcsomagokat, vagy foglaljon stratégiai konzultációt, és nézze meg, hogyan alakíthatja a Zenith Blueprint és a Zenith Controls a Zero Trust modellt auditkockázatból megfelelési előnnyé.