Nem emberi identitások és titkok kezelése a 2026-os auditokra

A 02:13-as riasztás, amelyhez senki sem tudott felelőst rendelni

Kedd hajnalban, 02:13-kor riasztás jelenik meg a biztonsági üzemeltetési csatornán. Egy belső automatizációs fiókból éles adatbázis-export indult. A hozzáférési útvonal jogosnak tűnik. A token érvényes. A forrás IP-cím a mérnöki csapat által használt felhőalapú futtatóhoz tartozik. Kártevő nem látható. Adathalászati bejelentés nincs.

Az információbiztonsági vezető (CISO) felteszi az első kézenfekvő kérdést: „Kié ez az identitás?”

Csend.

A DevOps-vezető emlékszik, hogy a token két évvel korábban, egy ügyfélmigráció során jött létre. A platformcsapat szerint talán egy számlázási integráció használja. Az adatbázis-adminisztrátor szerint azért van olvasási hozzáférése, mert az eltávolítása korábban leállított egy éjszakai feladatot. A jogi terület azt kérdezi, érintett-e személyes adatot az esemény. A megfelelőségi funkció azt kérdezi, bejelentésköteles incidens-e ez a NIS2, DORA vagy GDPR alapján. Az auditor bizonyítékot kér arra, hogy a szolgáltatásfiókok, API-kulcsok, tanúsítványok és CI/CD-titkok nyilvántartottak, felülvizsgáltak, rotáltak, monitorozottak és visszavonhatók.

09:00-ra az auditmegállapítás tervezete már körvonalazódik. Egy elfelejtett mikroszolgáltatásban beégetett, nem rotált API-kulcsot találtak. Széles körű hozzáférést biztosít egy éles ügyféltranzakciós adatbázishoz. A fejlesztő, aki létrehozta, két éve távozott. A rendszernek nincs megnevezett tulajdonosa, dokumentált célja, rotációs bejegyzése és felügyeleti szabálya.

Ez a nem emberi identitások problémája 2026-ban.

A legtöbb szervezet javított az emberi felhasználók hozzáférés-szabályozásán. Van többtényezős hitelesítésük, belépés–áthelyezés–kilépés munkafolyamatuk, emelt jogosultságú hozzáférési felülvizsgálatuk és identitásszolgáltatói naplózásuk. A gépi identitások azonban gyorsabban szaporodtak, mint ahogyan az irányítás utolérte volna őket. A szolgáltatásfiókok, workload-identitások, API-kulcsok, OAuth-tokenek, SSH-kulcsok, tanúsítványok, Kubernetes-titkok, SaaS-integrációs tokenek, robotizált folyamatautomatizálási fiókok és CI/CD-telepítési hitelesítő adatok ma már kritikus üzleti műveleteket hajtanak végre anélkül, hogy emberi értelemben „felhasználók” lennének.

A SaaS-szolgáltatók, fintechek, menedzselt szolgáltatók, felhőüzemeltetők és adatintenzív KKV-k számára a kezeletlen nem emberi identitások már nem pusztán technikai higiéniai kérdések. Igazgatósági szintű reziliencia- és megfelelőségi kockázatot jelentenek. A NIS2 a hozzáférés-szabályozást, az eszközkezelést, az ellátási lánc biztonságát, az incidenskezelést és a kiberhigiéniát alapvető kiberbiztonsági kockázatkezelési intézkedésként kezeli. A DORA az IKT-kockázatot, az operatív rezilienciát, az incidensjelentést és az IKT harmadik fél kockázatot a pénzügyi szervezetek vezető testületének elszámoltathatósága alá helyezi. A GDPR előírja, hogy az adatkezelők és adatfeldolgozók védjék a személyes adatokat, és igazolják elszámoltathatóságukat.

A nehézség nem annak bizonyítása, hogy titkok léteznek. A nehézség annak bizonyítása, hogy minden nem emberi identitásnak van tulajdonosa, célja, életciklusa, kockázati besorolása, jóváhagyott hozzáférése, biztonságos tárolási módja, rotációs szabálya, felügyeleti lefedettsége és visszavonási útvonala.

Miért váltak a nem emberi identitások az új emelt jogosultságú hozzáférési problémává?

A nem emberi identitás, vagy NHI, minden olyan digitális identitás, amelyet személy helyett szoftver, infrastruktúra vagy automatizált folyamat használ. A gyakorlatban ide tartoznak az alkalmazások által használt szolgáltatásfiókok, a SaaS-integrációk API-kulcsai, harmadik féltől származó alkalmazások OAuth- és frissítési tokenjei, automatizációs SSH-kulcsok, TLS-tanúsítványok és privát kulcsok, CI/CD-titkok, felhőalapú workload-identitások, adatbázis-kapcsolati karakterláncok, beágyazott hitelesítő adatok, RPA-botfiókok és beszállító által kezelt integrációs hitelesítő adatok.

Ezeknek az identitásoknak gyakran három olyan jellemzőjük van, amely aggasztja az auditorokat.

Először: hosszú életűek. Egy emberi felhasználó hitelesítő adatokat rotálhat, szerepkört válthat, és formális kiléptetési folyamaton keresztül távozhat. Egy kiadási ablakban létrehozott API-token évekig aktív maradhat, mert senki nem akarja kockáztatni az éles működés megszakítását.

Másodszor: erősek. Egy telepítési token infrastruktúrát módosíthat. Egy felhőszolgáltatási principal tárhelyet hozhat létre. Egy adatbázisfiók ügyfélrekordokat exportálhat. Egy aláírókulcs kompromittálhatja a szoftverellátási lánc sértetlenségét.

Harmadszor: nehezen rendelhetők felelőshöz. Az emberi identitások HR-nyilvántartásokhoz kapcsolódnak. A nem emberi identitások gyakran szkriptekhez, pipeline-okhoz, beszállítókhoz, elfelejtett projektekhez vagy dokumentálatlan integrációkhoz kötődnek.

A Clarysec Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint a Kontrollok működés közben fázis 22. lépésében közvetlenül rámutat erre:

És ne feledkezzünk meg a nem emberi identitásokról sem. Az auditok gyakran itt tárnak fel csendes kitettséget. Nyomon követik az API-tokeneket? Az integrációs fiókok személyekhez vannak kötve, vagy gazdátlanul lebegnek? Mikor rotálták utoljára azt az adatbázis-hozzáférési karakterláncot, amely egy évtizedes szkriptbe van beágyazva?

Az identitáskezelés nem látványos, de strukturális jelentőségű. Nélküle az IBIR csak zárt ajtók gyűjteménye, miközben nincs mód megbizonyosodni arról, ki tartja a kulcsokat.

Ez az utolsó mondat a lényeg. Egy vállalatnak lehet kiforrott hozzáférés-szabályozási szabályzata, mégis megbukhat az auditon, ha a gépi identitások nincsenek kezelés alatt. Az az IBIR, amely nem tudja megmagyarázni, kié egy titok, miért létezik, és mikor vizsgálták felül utoljára, még nem kontrollált rendszerként működik.

Az ISO/IEC 27001:2022 a titkok kezelését bizonyítékokká alakítja

Az ISO/IEC 27001:2022 azért hatékony, mert a titkok kezelését nem elszigetelt mérnöki feladatként kezeli. Kockázatalapú IBIR-t követel meg meghatározott hatállyal, az érdekelt felek követelményeivel, vezetői elszámoltathatósággal, kockázatértékeléssel, kockázatkezeléssel, kontrollkiválasztással, alkalmazhatósági nyilatkozattal és folyamatos fejlesztéssel.

A nem emberi identitások esetében a szervezetnek nem eszközbeszerzéssel kell kezdenie. A hatállyal és a kötelezettségekkel kell kezdenie.

Az ISO/IEC 27001:2022 4.1–4.4 pontjai szerint a szervezet meghatározza a belső és külső tényezőket, az érdekelt feleket, a jogi, szabályozási és szerződéses követelményeket, az interfészeket és a függőségeket. NHI-kontextusban az IBIR alkalmazási területének azonosítania kell azokat a felhőkörnyezeteket, SaaS-platformokat, CI/CD-rendszereket, éles alkalmazásokat, ügyfélintegrációkat, adatfeldolgozókat, menedzselt szolgáltatókat és kriptográfiai szolgáltatásokat, ahol gépi hitelesítő adatok léteznek.

Az 5.1–5.3 pontok a vezetést teszik elszámoltathatóvá a szabályzatokért, erőforrásokért, szerepkörökért és teljesítményjelentésért. Ez azért fontos, mert az NHI-helyesbítés gyakran működési feszültséget okoz. Egy éles adatbázis-hitelesítő adat rotálása, egy örökölt megosztott szolgáltatásfiók cseréje vagy a titoktáralapú titokbefecskendezés kikényszerítése törékeny munkafolyamatokat szakíthat meg. Felsővezetői támogatás nélkül a csapatok elhalasztják a rendbetételt.

A 6.1.1–6.1.3 és 6.2 pontok adják a kontrollmotort. A szervezet meghatározza a kockázati kritériumokat, azonosítja a bizalmassági, sértetlenségi és rendelkezésre állási kockázatokat, kijelöli a kockázatgazdákat, értékeli a valószínűséget és a hatást, kockázatkezelési lehetőségeket választ, kontrollokat jelöl ki, elkészíti az alkalmazhatósági nyilatkozatot, és nyomon követi a mérhető célkitűzéseket.

Gyakorlati szinten a nem emberi identitásokra vonatkozó kockázatkezelési tervnek meg kell válaszolnia:

• Mely rendszerek és üzleti szolgáltatások függenek NHI-ktől?
• Mely titkok férhetnek hozzá személyes adatokhoz, szabályozott pénzügyi szolgáltatásokhoz, éles infrastruktúrához vagy kritikus ügyfélszolgáltatásokhoz?
• Mely identitások emelt jogosultságúak, inaktívak, megosztottak, beszállító által kezeltek vagy kezeletlenek?
• Mely kontrollok csökkentik a kockázatot, például a titoktári tárolás, rotáció, legkisebb jogosultság elve, lejárat, tanúsítvány-életciklus-kezelés, CI/CD-vizsgálat, monitorozás és sürgősségi visszavonás?
• Mely maradványkockázatok igényelnek üzleti jóváhagyást?

Az ISO/IEC 27002:2022 ezt követően biztosítja az A melléklet kontrollkatalógusát. A legrelevánsabb kontrollok: 5.9 Információk és kapcsolódó eszközök nyilvántartása, 5.15 Hozzáférés-szabályozás, 5.16 Identitáskezelés, 5.17 Hitelesítési információk, 5.18 Hozzáférési jogosultságok, 5.19 Információbiztonság a beszállítói kapcsolatokban, 5.20 Információbiztonság kezelése beszállítói megállapodásokban, 5.21 Információbiztonság kezelése az IKT ellátási láncban, 5.23 Információbiztonság felhőszolgáltatások használata során, 5.24 Incidenskezelés tervezése és előkészítése, 5.28 Bizonyítékgyűjtés, 8.2 Emelt szintű hozzáférési jogosultságok, 8.3 Információ-hozzáférés korlátozása, 8.5 Biztonságos hitelesítés, 8.15 Naplózás, 8.16 Felügyeleti tevékenységek, 8.24 Kriptográfia használata, 8.25 Biztonságos fejlesztési életciklus, 8.26 Alkalmazásbiztonsági követelmények, 8.28 Biztonságos kódolás és 8.31 Fejlesztési, teszt- és éles környezetek elkülönítése.

A Clarysec Zenith Controls: The Cross-Compliance Guide Zenith Controls ezeket az ISO/IEC 27002:2022 kapcsolatokat auditorok és kontrollgazdák számára használható módon térképezi fel. Az 5.16 Identitáskezelés kontrollnál a Zenith Controls így magyarázza az identitás és a hitelesítő adatok kapcsolatát:

Az identitáskezelés adja meg, hogy „ki”, míg a hitelesítési információk biztosítják, hogy „hogyan” ellenőrizhető: az identitást állító személy valóban jogosult. Az 5.16 az identitáséletciklus-kezelést szabályozza, míg az 5.17 biztosítja, hogy a jelszavak, tokenek, tanúsítványok és más hitelesítő adatok biztonságosan kapcsolódjanak ezekhez az identitásokhoz, és megfelelő kezelésük támogassa az erős hitelesítést.

Ez a kapcsolat alapvető az NHI-k esetében. Egy identitástulajdonos nélküli token nem auditálható. Egy hozzáférési felülvizsgálat nélküli szolgáltatásfiók nem felel meg a legkisebb jogosultság elvének. Egy életciklusállapot nélküli tanúsítvány nem kontrollált kriptográfia. Egy szerződéses feltételek nélküli beszállítói integrációs hitelesítő adat nem hatékony harmadik fél kockázatkezelés.

A Clarysec kontrollmintája: identitás, titok, jogosultság, bizonyíték

A Clarysec a nem emberi identitások és titkok kezelését ismételhető kontrollmintán keresztül valósítja meg. Nem kezeljük a „titkokat” kizárólag DevOps-kérdésként, sem a „szolgáltatásfiókokat” kizárólag IAM-kérdésként. Összekapcsoljuk az identitást, a titkot, a jogosultságot és a bizonyítékot.

A szabályzati réteg teszi mindezt kikényszeríthetővé.

KKV-k számára a Clarysec User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme kimondja:

A szolgáltatásfiókokat (amelyeket rendszerek vagy alkalmazások használnak) dokumentálni kell, meghatározott rendszerekre kell korlátozni, és soha nem használhatók interaktív bejelentkezésre.

Ez megakadályozza azt a klasszikus antimintát, amikor egy szolgáltatásfiók megosztott rendszergazdai bejelentkezéssé válik. Az auditor számára egyértelmű tesztet is ad: mutassák be a szolgáltatásfiók-nyilvántartást, a rendszerkorlátozást, valamint azt, hogy az interaktív bejelentkezés le van tiltva vagy technikailag meg van akadályozva.

A Clarysec Asset Management Policy-sme Asset Management Policy-sme az eszközök definícióját kiterjeszti a következőkre:

Digitális hitelesítő adatok és szolgáltatások: domainnevek, digitális tanúsítványok, API-kulcsok, e-mail-fiókok, felhőbejelentkezések

Ez azért fontos, mert sok szervezet csak szervereket, laptopokat és alkalmazásokat tart nyilván. 2026-ban egy API-kulcs érzékenyebb lehet, mint egy laptop. Egy tanúsítvány privát kulcsa éles hitelesítési eszköz lehet. Egy automatizáció által használt felhőbejelentkezés szabályozott adatkitettséget hozhat létre. A hitelesítő adatok eszközként kezelése az auditra kész titokkezelés alapja.

Nagyvállalati környezetekben a Clarysec User Account and Privilege Management Policy User Account and Privilege Management Policy magasabb bizonyítéki szintet ír elő:

A szervezetnek részletes nyilvántartást kell vezetnie minden aktív és inaktív hitelesítő adatról, emelt jogosultságú fiókról és rendszerszintű szolgáltatásfiókról. A nyilvántartást folyamatosan frissíteni kell, és negyedévente felül kell vizsgálni.

A negyedéves felülvizsgálat során kerül felszínre sok hiányosság. Az inaktív hitelesítő adatok, gazdátlan service principalok, régi integrációs felhasználók, kezeletlen beszállítói fiókok és sürgősségi tokenek csak akkor válnak láthatóvá, amikor valaki összeveti a nyilvántartást a tényleges IAM-, titoktár-, CI/CD- és felhőbejegyzésekkel.

A titkok hitelesítési információk, nem fejlesztői kényelmi eszközök

A titkok kezelésében a legveszélyesebb kifejezés az „ideiglenes kulcs”.

Az ideiglenes kulcsok állandóvá válnak. A tesztelési hitelesítő adatok eljutnak éles környezetbe. A forráskód tokeneket fed fel. A buildnaplók jelszavakat tesznek láthatóvá. A támogatási csapatok jegyeken keresztül osztanak meg tanúsítványokat. A fejlesztők környezeti fájlokat másolnak chatbe. Egy vállalkozó létrehoz egy felhőszolgáltatási principalt, majd távozik.

A Zenith Blueprint Kontrollok működés közben fázisának 22. lépése tágan írja le a hitelesítési információkat:

Ez a kontroll nem csak a jelszavakról szól, bár a jelszavak természetesen részei a képnek. Minden olyan hitelesítő adatról szól, amely identitás igazolására szolgál: jelszavak, PIN-ek, kriptográfiai kulcsok, biometrikus sablonok, smartcardok, tokenek, tanúsítványok, OAuth-tokenek, SSH-kulcsok, API- titkok. Ezek a királyság kulcsai, és az 5.17 kontroll biztosítja, hogy ezeket a kulcsokat a jelentőségüknek megfelelő szigorral kezeljék.

Legyünk egyértelműek: a gyenge hitelesítéskezelés továbbra is az incidensek egyik leggyakoribb gyökéroka. Gyenge vagy megosztott jelszavak. Forráskódban beégetett hitelesítő adatok. Változatlan alapértelmezett bejelentkezések adminisztrációs portálokon. Lejárt vagy ismeretlen tulajdonú tanúsítványok. Ezekben az esetekben nem az identitás hibázik, hanem az a hiba, hogy nem sikerült megvédeni és irányítás alá vonni az identitás igazolására használt mechanizmust.

A Clarysec szabályzatai ezt működési szabályokká alakítják.

A Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme kimondja:

A kulcsokat tilos olvasható szövegként tárolni, illetve forráskódba, dokumentumokba vagy e-mailekbe beágyazni.

A Secure Development Policy-sme Secure Development Policy-sme kimondja:

Forráskódban nem lehetnek beégetett hitelesítő adatok vagy titkok.

Nagyvállalati csapatok esetében a Secure Development Policy Secure Development Policy kimondja:

A titkokat tilos beégetni vagy olvasható szövegként adattárakban tárolni.

Az Application Security Requirements Policy Application Security Requirements Policy még közvetlenebb:

Jelszavak vagy kriptográfiai kulcsok olvasható szövegként történő tárolása szigorúan tilos.

Ezek a szabályzati pontok egyértelmű auditnyomot teremtenek. A biztonsági csapatok explicit követelmények alapján tesztelhetik az adattárakat, CI/CD-változókat, konténerképeket, konfigurációs tárakat, hibajegykezelő rendszereket, dokumentációs platformokat és naplókat. Támogatják a GDPR Article 32 szerinti adatkezelés biztonságát is, mert a titkok kitettsége közvetlenül vezethet személyes adatokhoz való jogosulatlan hozzáféréshez.

A nagyvállalati kriptográfiai irányításnak tulajdonosi felelősségre is szüksége van. A Clarysec Cryptographic Controls Policy Cryptographic Controls Policy előírja:

Központi Kulcskezelési Nyilvántartást kell fenntartani valamennyi kriptográfiai kulcs, azok életciklusállapota, kijelölt gondnokai és felhasználási kontextusai rögzítésére.

A nem emberi identitások esetében ennek a nyilvántartásnak össze kell kapcsolnia a tanúsítványkulcsokat, aláírókulcsokat, API-kulcsokat és felhőben kezelt kulcsokat a tágabb NHI-nyilvántartással. Az auditornak képesnek kell lennie egy éles tanúsítvány visszakövetésére az üzleti szolgáltatástól a tulajdonoson és gondnokon át a lejáratig, a rotációs bizonyítékig és az incidensreagálási eljárásig.

NIS2, DORA és GDPR: egy bizonyítékmodell, több felügyelet

A nem emberi identitások irányítása keresztmegfelelési probléma, mert ugyanaz a hiba több kötelezettséget is kiválthat.

Egy SaaS-szolgáltatónál kiszivárgott API-token szolgáltatáskiesést okozhat a NIS2 alapján, személyes adatok kitettségét a GDPR alapján, valamint szerződéses incidensjelentési kötelezettséget pénzügyi ügyfelek felé a DORA ellátási lánccal kapcsolatos elvárásai szerint. Egy IKT-szolgáltatónál kompromittálódott CI/CD-titok érintheti az ügyfelek rezilienciáját, a szoftver sértetlenségét és az operatív folytonosságot. Egy elfelejtett beszállítói integrációs fiók megfelelő kellő gondosság vagy szerződéses kontrollok nélkül hozhat létre hozzáférést szabályozott rendszerekhez.

A NIS2 Article 21 megfelelő és arányos technikai, operatív és szervezeti intézkedéseket ír elő. A minimális területek közé tartozik a kockázatelemzés, az információs rendszerek biztonsági szabályzatai, az incidenskezelés, az üzletmenet-folytonosság, az ellátási lánc biztonsága, a biztonságos beszerzés, fejlesztés és karbantartás, a sérülékenységkezelés, a hatékonyság értékelése, a kiberhigiénia, a kriptográfia, a HR-biztonság, a hozzáférés-szabályozás és az eszközkezelés, valamint adott esetben az MFA vagy a folyamatos hitelesítés. A nem emberi identitások szinte mindegyik területet érintik. A NIS2 Article 23 szakaszos jelentéstételt is létrehoz a jelentős incidensekre, beleértve a 24 órán belüli korai figyelmeztetést, a 72 órán belüli incidensbejelentést és az incidensbejelentést követő legkésőbb egy hónapon belüli zárójelentést.

A DORA 2025. január 17-től alkalmazandó, és lefedi az IKT-kockázatkezelést, a jelentős IKT-vonatkozású incidensek jelentését, az operatív rezilienciatesztelést, az információmegosztást és az IKT harmadik fél kockázatot. Az Article 5 és 6 irányítást, vezető testületi elszámoltathatóságot és dokumentált IKT-kockázatkezelési keretrendszert ír elő. Az Article 8 megköveteli az IKT által támogatott üzleti funkciók, információs vagyon és függőségek azonosítását. Az Article 17–19 incidenskezelést, besorolást és jelentéstételt ír elő. Az Article 28–30 az IKT harmadik fél kockázatkezelést, szerződéses nyilvántartásokat, kellő gondosságot, biztonsági szabványokat, auditálási jogokat, incidens-támogatást, alvállalkozói kontrollokat és kilépési stratégiákat követel meg.

A GDPR minden olyan esetben alkalmazandó, amikor személyes adatot a területi hatálya alatt kezelnek. Az Article 5 sértetlenséget, bizalmasságot és elszámoltathatóságot ír elő. Az Article 32 megfelelő technikai és szervezeti intézkedéseket követel meg az adatkezelés biztonságához. Ha egy szolgáltatásfiók vagy API-kulcs személyes adatokhoz férhet hozzá, a kezeletlen titkok adatvédelmi kontrollhibává válnak, nem csupán IT-problémává.

Ugyanaz a bizonyíték képes támogatni az ISO/IEC 27001:2022 tanúsítást, a NIS2 felügyeletet, a DORA vizsgálatokat és a GDPR szerinti elszámoltathatóságot, ha megfelelően strukturált.

A NIST CSF 2.0 kommunikációs rétegként használható ugyanahhoz a bizonyítékkészlethez. GOVERN funkciója lefedi az érdekelt felek elvárásait, a jogi és szerződéses kötelezettségeket, a kockázatvállalási hajlandóságot, a vezetői elszámoltathatóságot, a szabályzatokat és a felügyeletet. Működési eredményei lefedik az eszköznyilvántartásokat, a beszállító által nyújtott szolgáltatásokat, az identitás- és hitelesítőadat-kezelést, a legkisebb jogosultság elvét, az adatbiztonságot, a naplózást, a monitorozást, az incidensreagálást és a helyreállítást.

A COBIT 2019 és az ISACA-jellegű bizonyossági csapatok jellemzően az irányítást és a folyamatképességet vizsgálják. Azt kérdezik, kijelölték-e a felelősséget, beépültek-e a kontrollok a működési folyamatokba, jóváhagyták-e a kivételeket, jelentik-e a mutatókat a vezetésnek, és a bizonyítékok ismételhetőséget mutatnak-e, nem csupán egyszeri rendbetételt.

Gyakorlati sprint nem emberi identitás nyilvántartásának kialakítására

Egy gyakorlati Clarysec-megbízás gyakran fókuszált sprinttel indul, nem hat hónapos eszközprogrammal. A cél olyan igazolható NHI-nyilvántartás, kockázati rangsor és helyesbítési terv létrehozása, amely beépíthető az ISO/IEC 27001:2022 kockázatkezelési tervbe és az alkalmazhatósági nyilatkozatba.

Egyetlen üzleti szolgáltatással kell kezdeni, például ügyfélszámlázási platformmal, kereskedési alkalmazással, betegportállal vagy SaaS tenant-kezelő rendszerrel. Be kell vonni az éles és előéles környezetet, a CI/CD-t, a felhőinfrastruktúrát, a monitorozási eszközöket, az adatbázisokat, a SaaS-integrációkat és a beszállító által kezelt szolgáltatásokat.

Ezt a Zenith Blueprint Kockázatkezelési fázisának 14. lépéséhez kell kapcsolni, ahol a Clarysec a kezelési szabályzatokat szabályozói kereszthivatkozásokkal hangolja össze. Ebben a lépésben a biztonságos fejlesztési és pipeline-kontrollok közé tartozik a beégetett titkok tilalma, a társfelülvizsgálat, az automatizált statikus elemzés, a függőségvizsgálat, a fejlesztési, teszt- és éles környezet elkülönítése, az MFA a pipeline-hozzáféréshez, a build-artefaktumok sértetlensége és a CI/CD-naplózás.

Az identitásokat és titkokat az identitásszolgáltatóból, a felhő IAM-ből, a titoktárból, a Kubernetesből, a CI/CD-változókból, az adattár-beállításokból, az adatbázis-felhasználókból, a SaaS-adminisztrációs konzolokból, a tanúsítványkezelő eszközökből és a beszállítói dokumentációból kell összegyűjteni.

Kockázat alapján kell besorolni azokat az identitásokat, amelyek éles hozzáféréssel, emelt jogosultságokkal, személyesadat-hozzáféréssel, kritikus vagy fontos funkciófüggőséggel, beszállítói kontrollal, hosszú életű tokenekkel, tulajdonos nélküliséggel, rotációhiánnyal, monitorozás hiányával vagy beégetett tárolással rendelkeznek. Az ISO/IEC 27001:2022 kockázati kritériumai alapján kell pontozni a valószínűséget és a hatást. Ahol alkalmazandó, a DORA kritikus vagy fontos funkció elemzését kell használni. Személyesadat-hozzáférés esetén figyelembe kell venni a GDPR hatásmegfontolásait. A NIS2 szolgáltatási hatását ott kell alkalmazni, ahol a zavar vagy ügyfélkár reális.

Minden magas kockázatú NHI esetében kezelési intézkedéseket kell alkalmazni. A titkokat át kell helyezni a forráskódból, dokumentumokból és CI/CD olvasható szöveges változókból titoktárba vagy felügyelt titokkezelőbe. A megosztott szolgáltatásfiókokat egyedi workload-identitásokkal kell kiváltani. A szolgáltatásfiókok interaktív bejelentkezését le kell tiltani. Alkalmazni kell a legkisebb jogosultság elvét és a környezetspecifikus hitelesítő adatokat. Be kell állítani a rotációt, a lejáratot és a sürgősségi visszavonást. A titkokat tulajdonosokhoz és gondnokokhoz kell kötni. Naplózást kell bevezetni a hitelesítésre, tokenhasználatra és érzékeny műveletekre. Riasztást kell hozzáadni rendellenes földrajzi hely, szokatlan időpont, szokatlan mennyiség vagy új erőforrás-hozzáférés esetére. Frissíteni kell a beszállítói szerződéseket a hitelesítő adatok kezelésére, incidens-támogatásra és auditálási jogokra. A kivételeket kockázatgazdai jóváhagyással és lejárati dátummal kell dokumentálni.

A Test Data and Test Environment Policy Test Data and Test Environment Policy támogatja a környezetek elkülönítését:

A CI/CD pipeline-ekkel való integrációnak ki kell kényszerítenie a környezetek és a hitelesítési adatok elkülönítését.

Ez a pont gyakran döntő. Ha a fejlesztési, teszt- és éles környezet titkokat oszt meg, egy alacsony kockázatú környezet éles incidensútvonallá válhat.

A sprintnek nem csupán megállapításlistával, hanem bizonyítékcsomaggal kell zárulnia. Tartalmazza az NHI-nyilvántartás exportját, a kockázatértékelési bejegyzéseket, a kezelési tervet, az alkalmazhatósági nyilatkozat megfeleltetését, a szabályzati hivatkozásokat, a titoktári képernyőképeket, a rotációs naplókat, a hozzáférés-felülvizsgálati jóváhagyásokat, a CI/CD-titokvizsgálati eredményeket, a felügyeleti szabálydefiníciókat, a beszállítói hitelesítő adatok felelősségi mátrixát, az incidens-forgatókönyvet, valamint a tulajdonossal és lejárati dátummal rendelkező kivételeket.

Naplózás és észlelés: annak bizonyítása, hogy a gépi identitások használata látható

Az a gépi identitás, amely jól nyilvántartott, de a naplókban láthatatlan, továbbra is veszélyes. Az észlelés a kontrolltörténet része.

A Clarysec Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme hitelesítési bizonyítékokat is tartalmaz:

Hitelesítési naplók: sikeres és sikertelen bejelentkezési kísérletek, munkamenet-időtartam, MFA-használat

NHI-k esetében ezt a követelményt gépi hitelesítésre kell adaptálni. Egy workload-identitásnál nem feltétlenül van MFA-használat, de rendelkezésre kell állniuk hitelesítési eseményeknek, tokenhasználatnak, tanúsítványhasználatnak, API-hívási metaadatoknak, forrás workloadnak, cél szolgáltatásnak, tokenélettartamnak, hibaeseményeknek és emelt jogosultságú műveleteknek.

A Zenith Controls az ISO/IEC 27002:2022 8.2 Emelt szintű hozzáférési jogosultságok kontrollját a naplózáshoz és monitorozáshoz köti, mert az emelt jogosultságú fiókok részletes nyilvántartást és felügyeletet igényelnek. A Zenith Controls a 8.2 kontrollt az identitáskezeléshez, a hozzáférési jogosultságokhoz, az információ-hozzáférés korlátozásához és a biztonságos hitelesítéshez is kapcsolja. Auditorok számára ez azt jelenti, hogy az emelt jogosultságú nem emberi identitásokat ugyanolyan komolysággal kell felülvizsgálni és monitorozni, mint az emberi rendszergazdákat – esetenként még nagyobbal.

Jó felügyeleti kérdések:

• Hitelesített-e egy szolgáltatásfiók váratlan workloadból vagy IP-tartományból?
• Hozzáfért-e egy API-kulcs új végponthoz vagy adatkészlethez?
• Használtak-e egy tanúsítványt a cseréje után?
• Telepített-e egy CI/CD-token jóváhagyott pipeline-on kívül?
• Írási műveletet kísérelt-e meg egy csak olvasható fiók?
• Aktívvá vált-e egy inaktív hitelesítő adat?
• Hozzáfért-e egy beszállítói integráció az adatokhoz a megállapodott időablakon vagy mennyiségen kívül?

Amikor bekövetkezik a 02:13-as riasztás, meg kell tudni válaszolni, milyen identitást használtak, milyen titok hitelesítette, milyen hozzáférési jogosultságokat gyakoroltak, milyen adatokat vagy rendszereket érintett, várható volt-e a tevékenység, mely tulajdonos tudja megerősíteni, és teljesülnek-e az incidensjelentési küszöbértékek.

Az auditor nézőpontja: ugyanaz a folyamat, eltérő kérdések

A legerősebb auditpozíció nem az, hogy „mindennek megfelelünk”. Hanem az, hogy „egy kontrollált folyamatot működtetünk, amely több kötelezettséghez termel bizonyítékot”. A különböző auditorok eltérő módon vizsgálják ezt a folyamatot.

Ezekben a nézőpontokban visszatérő megállapítások kiszámíthatók: nincs egységes NHI-nyilvántartás, nincs tulajdonosa a gépi identitásoknak, a titkok kódban vagy dokumentációban vannak tárolva, a hitelesítő adatok környezetek között megosztottak, nincs rotáció vagy lejárat, a beszállító által kezelt hitelesítő adatok kimaradnak a hozzáférés-felülvizsgálatokból, a monitorozás az embereket lefedi, a gépeket nem, az incidens-forgatókönyvek pedig figyelmen kívül hagyják a titkok kiszivárgását.

Minden megállapítás természetesen leképezhető Clarysec kontrollokra, szabályzatokra és helyesbítési sablonokra. Ennél is fontosabb, hogy mindegyik mérhető bizonyítékká alakítható az IBIR-ben.

Hogyan segít a Clarysec az auditra való felkészülésben?

A Clarysec megközelítése azért gyakorlati, mert az auditorok által kért bizonyítékokból indul ki, és ezekből vezet vissza a kontrollokra, szabályzatokra és működési rutinokra.

A Zenith Blueprint Kontrollok működés közben fázisának 19. lépésében a Clarysec közvetlen útmutatást ad a gép–gép hitelesítéshez:

Gép–gép hitelesítésnél, például szolgáltatásfiókok vagy API-hívások esetében, a kulcsokat, tanúsítványokat és tokeneket ugyanolyan szigorúan kell védeni. Kerülni kell a hitelesítő adatok kódba ágyazását. Titokkezelő rendszereket vagy titoktárakat kell használni a biztonságos tároláshoz és rotációhoz.

Egy tipikus Clarysec nem emberi identitás munkafolyamat magában foglalja az NHI-feltárást felhőben, SaaS-ben, CI/CD-ben, adattárakban, titoktárakban és adatbázisokban; a szabályzati hiányosságok értékelését a Clarysec KKV- vagy nagyvállalati szabályzatkészleteihez képest; az ISO/IEC 27001:2022 kockázatértékelési és kezelési megfeleltetést; az alkalmazhatósági nyilatkozat frissítését; a NIS2, DORA, GDPR és NIST CSF bizonyíték-megfeleltetést; az NHI-nyilvántartás kialakítását; a kulcskezelési nyilvántartás összehangolását; a titokvizsgálatot; a hozzáférés-felülvizsgálati folyamatokat; a beszállítói hitelesítő adatok felelősségi mátrixait; az incidens-forgatókönyveket; valamint auditcsomagokat képernyőképekkel, exportokkal, naplókkal, jóváhagyásokkal és kivételbejegyzésekkel.

KKV-k esetében a megközelítés arányos. Egy 70 fős SaaS-szolgáltatónak nincs szüksége ugyanarra az eszközparkra, mint egy globális banknak, de szüksége van tulajdonosi felelősségre, szabályzatra, kockázatkezelésre és bizonyítékra. Szabályozott pénzügyi szervezetek és IKT-szolgáltatók esetében ugyanez a modell kiterjeszthető a DORA szerinti kritikus funkciók leképezésére, a harmadik fél kockázatirányításra és a rezilienciatesztelésre.

Ha a következő audit 2026-ban esedékes, ne várja meg, hogy az auditor fedezze fel a nem emberi identitásokat. Kezdje egy kritikus szolgáltatással, és tegyen fel öt kérdést:

1. Ismerjük-e az összes szolgáltatásfiókot, API-kulcsot, tokent, tanúsítványt és CI/CD-titkot, amelyet ez a szolgáltatás használ?
2. Van-e minden NHI-nek megnevezett tulajdonosa, gondnoka, célja és kockázati besorolása?
3. Titoktárban vannak-e a titkok, rotálják-e őket, és védettek-e a forráskódtól, dokumentumoktól, e-mailektől és olvasható szöveges tárolástól?
4. Felülvizsgálják, monitorozzák és interaktív használattól korlátozzák-e az emelt jogosultságú gépi identitásokat?
5. Tudunk-e egyetlen kontrollált folyamatból bizonyítékot előállítani az ISO/IEC 27001:2022, NIS2, DORA és GDPR számára?

Használja a Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint útmutatót az IBIR bevezetési útjának strukturálásához. Használja a Zenith Controls: The Cross-Compliance Guide Zenith Controls útmutatót az ISO/IEC 27002:2022 identitáskezelési, hitelesítési, jogosultsági, naplózási, kriptográfiai, biztonságos fejlesztési és beszállítói kontrolljainak szabályozói bizonyítékokhoz kapcsolásához. Használja a Clarysec KKV- és nagyvállalati szabályzattárát, beleértve a User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme, Cryptographic Controls Policy Cryptographic Controls Policy, Secure Development Policy Secure Development Policy és Application Security Requirements Policy Application Security Requirements Policy dokumentumokat, hogy a jó szándékokat kikényszeríthető követelményekké alakítsa.

A 02:13-as riasztás valahol be fog következni. A kérdés az, hogy szervezete bizonyítékokkal alátámasztva meg tudja-e válaszolni, kinél volt a kulcs, mit nyitott ki, miért létezett, és milyen gyorsan tudja biztonságossá tenni.