Böngészőbővítmények irányítása NIS2-, DORA- és GDPR-megfeleléshez
Maria, egy gyorsan növekvő fintech vállalat információbiztonsági vezetője úgy látta, hogy a DORA előzetes értékelése jól halad. Csapata előkészítette a harmadik fél IKT-szolgáltatók nyilvántartását, a kritikus SaaS-szerződéseket, a beszállítói átvilágítási nyilvántartásokat, a kockázatelfogadási döntéseket és a vezető testületnek szánt jelentéscsomagot.
Ezután az auditor feltett egy kérdést, amelyre senki nem készült fel.
“Meg tudják mutatni a böngészőbővítményekre vonatkozó irányítási folyamatukat?”
A kérdés egy pénzügyi elemzővel végzett végponti felülvizsgálat során merült fel. Képernyőmegosztás közben az auditor észrevett egy harmadik féltől származó produktivitási bővítményt az elemző böngészőjében. Ártalmatlannak tűnt, de egy gyors ellenőrzés kimutatta, hogy a fejlesztőt három hónappal korábban ellátásilánc-kompromittálódás érte. A kompromittálódott bővítményt jelentős SaaS-platformok munkamenet-tokenjeinek kiszivárogtatására használták.
A fintechnek szigorú szabályzatai voltak a jogosulatlan szoftverek ellen. Rendelkezett EDR-rel, többtényezős hitelesítéssel, CASB-vel, SaaS-naplókkal és ISO/IEC 27001-hez igazított információbiztonság-irányítási rendszerrel (ISMS). A böngészőt azonban senki nem kezelte felügyelt szoftverplatformként. Senki nem vezetett nyilvántartást a bővítményekről. Senki nem hagyta jóvá a jogosultságaikat. Senki nem ellenőrizte, hogy a bővítményfejlesztők beszállítónak minősülnek-e. Senki nem képezte le a bővítménytevékenységet DORA-, NIS2- vagy GDPR-bizonyítékokra.
Egyetlen böngészőbővítmény egy látszólag megfelelő végpontot lehetséges hátsó ajtóvá alakított a pénzügyi rendszerek, az ügyféladatok és a szabályozott munkafolyamatok felé.
Ez a böngészőbővítmény-irányítás problémája 2026-ban. A böngésző már nem pusztán ablak az internetre. Itt hitelesítik magukat a munkavállalók, itt hagynak jóvá kifizetéseket, férnek hozzá CRM-nyilvántartásokhoz, kezelnek személyes adatokat, felügyelnek felhőinfrastruktúrát, és lépnek kapcsolatba kritikus SaaS-platformokkal. A bővítmények már nem kozmetikai kiegészítők. Harmadik féltől származó kódok, amelyek a modern munkavégzés legérzékenyebb rétegében futnak.
Az információbiztonsági vezetők, megfelelőségi vezetők, adatvédelmi tisztviselők és IKT-kockázatgazdák számára a nem kezelt bővítmények a végpontbiztonság, a shadow IT, a beszállítói kockázat, a változáskezelés, a sérülékenységkezelés és az adatvédelmi elszámoltathatóság metszéspontjában helyezkednek el. Az ISO/IEC 27001:2022 megadja a szervezeteknek a kockázat irányításához szükséges struktúrát. A NIS2, a DORA és a GDPR pedig szabályozói nyomást teremtenek ennek igazolására.
A böngészőbővítmények szoftverek, beszállítók és adatfeldolgozói kockázatok
A legtöbb szervezet már megtanulta kezelni a laptopokat, mobileszközöket, szervereket, SaaS-alkalmazásokat, felhőinfrastruktúrát és privilegizált fiókokat. A böngészőbővítmények azonban gyakran e programok közé esnek.
A biztonsági csapatok böngészőbeállításként tekintenek rájuk. A beszerzés nem látja őket, mert nincs szerződéskötés. A jogi terület nem látja őket, mert nem indul beszállítói beléptetési kérelem. Az adatvédelmi csapatok nem látják őket, mert a bővítményt a felhasználó telepíti, nem hivatalos alkalmazásként vezetik be. A bővítmény mégis kérhet jogosultságot arra, hogy minden webhelyen adatokat olvasson és módosítson, hozzáférjen a vágólap tartalmához, oldalmetaadatokat rögzítsen, letöltéseket kezeljen, szkripteket injektáljon, vagy külső háttérrendszerrel kommunikáljon.
Ez azt jelenti, hogy egy böngészőbővítmény egyszerre lehet az alábbiak mindegyike:
| Irányítási nézőpont | Miért fontos | Tipikus hibamód |
|---|---|---|
| Szoftver | Megváltoztatja a végpont viselkedését, és kódot futtathat felhasználói munkamenetekben | A felhasználók a jóváhagyott szoftveres munkafolyamatokon kívül telepítenek bővítményeket |
| Beszállító | A fejlesztő szabályozza a frissítéseket, az infrastruktúrát és a támogatást | Nem történik beszállítói átvilágítás |
| Felhőszolgáltatás | Sok bővítmény hosztolt API-khoz vagy SaaS-platformokhoz kapcsolódik | A bővítmény háttérrendszereit nem vizsgálják felhőszolgáltatásként |
| Adatfeldolgozói kockázat | A bővítmények ügyfél-, munkavállalói vagy pénzügyi adatokat láthatnak | Az adatvédelmi csapatok nem értékelik az adathozzáférést vagy a jogalapot |
| Sérülékenységi kitettség | A bővítmények kompromittálódhatnak, elhagyottá vagy rosszindulatúvá válhatnak | Nincs felülvizsgálat a javításkezelésről, a reputációról vagy az ismert kompromittálódásról |
| Incidensforrás | A bővítménytevékenység jogosulatlan hozzáférést vagy adatkivitelt okozhat | Hiányoznak a naplók, ami nehezíti a vizsgálatot és az értesítést |
A [ZB] Zenith Blueprint: auditorként használható 30 lépéses ütemterv az ISO/IEC 27002:2022 Control 8.19 útmutatásában pontosan megragadja az alapvető problémát. Arra figyelmeztet, hogy “még a jó szándékú munkatársak is telepíthetnek eszközöket azért, hogy gyorsabban elvégezzék a munkát – böngészőbővítményt, kódkönyvtárat vagy fájlátviteli alkalmazást –, anélkül hogy felismernék: ezzel hátsó ajtót, nem javított függőséget vagy adatkiviteli vektort vezetnek be.”
Ezt a mondatot igazgatósági szintű kockázati állításként kell kezelni. A kockázatos bővítményeket telepítő munkavállalók általában nem a biztonság megkerülésére törekednek. A produktivitásukat szeretnék javítani. Az irányítási hiba akkor következik be, amikor a szervezet nem biztosít biztonságos kérelmezési, jóváhagyási, bevezetési és felügyeleti folyamatot.
Miért teszi sürgőssé a NIS2, a DORA és a GDPR ezt a vakfoltot
A böngészőbővítmények kockázata évek óta létezik, de a szabályozói környezet megváltozott. 2026-ban a szervezetektől már nemcsak annak igazolását várják el, hogy léteznek kontrollok, hanem azt is, hogy azok kockázatalapúak, integráltak, felügyeltek és bizonyítékokkal alátámasztottak.
A NIS2 magasabb elvárásokat támaszt a kiberhigiéniával és az ellátási lánc biztonságával szemben. A DORA megköveteli, hogy a pénzügyi szervezetek az IKT-kockázatot a belső és harmadik fél függőségeken keresztül is kezeljék. A GDPR előírja, hogy az adatkezelők és adatfeldolgozók igazolják az adatkezelés biztonságát, az elszámoltathatóságot és a beépített adatvédelmet. A nem kezelt bővítmények mindhárom megfelelőséget alááshatják.
| Jogszabály | A böngészőbővítmények relevanciája | Szabályozók és auditorok által elvárt bizonyíték |
|---|---|---|
| NIS2 Article 21 | A bővítmények érintik a kiberhigiéniát, a sérülékenységkezelést, a hozzáférés-szabályozást, a szoftverbiztonságot és az ellátási lánc kockázatát | Bővítménynyilvántartás, jóváhagyott lista, kockázatértékelési feljegyzések, blokkolt telepítések naplói, incidenskezelési bizonyítékok |
| NIS2 Article 23 | Egy kompromittálódott bővítmény jelentős incidenst okozhat, amely korai figyelmeztetést és értesítést igényel | Észlelési naplók, triage-feljegyzések, hatásvizsgálat, értesítési döntés bizonyítékai |
| DORA Article 5 | A vezető testületek továbbra is elszámoltathatók az IKT-kockázat irányításáért | Szabályzatok, kockázatvállalási hajlandósággal kapcsolatos döntések, jelentések, kivétel-jóváhagyások |
| DORA Article 6 | A bővítmények érinthetik az IKT-kockázatkezelési keretrendszert | Eszközazonosítás, védelmi kontrollok, nyomon követés, rezilienciatesztelés, korrekciós intézkedések nyilvántartásai |
| DORA Article 28 | A bővítményfejlesztők és a kapcsolódó szolgáltatások harmadik fél IKT-függőségek lehetnek | Átvilágítás, kockázati besorolás, nyilvántartási bejegyzések, szerződéses értékelés, ahol alkalmazandó |
| GDPR Article 5(2) | A szervezeteknek igazolniuk kell a személyes adatok kezelésével kapcsolatos elszámoltathatóságot | Dokumentált értékelések, jóváhagyási döntések, tulajdonosi felelősség, felülvizsgálati ütemezés |
| GDPR Article 25 | A beépített és alapértelmezett adatvédelem az eszközválasztásra is vonatkozik | Jogosultság-minimalizálás, adatvédelmi felülvizsgálat, alapértelmezett tiltási konfiguráció |
| GDPR Article 32 | Az adatkezelés biztonsága megfelelő technikai és szervezeti intézkedéseket igényel | Végponti kontrollok, hozzáférési korlátozások, naplózás, felügyelet, sérülékenységkezelés |
| GDPR Article 33 | Az incidensbejelentési felkészültség az időszerű észleléstől és bizonyítékoktól függ | Incidensnaplók, személyes adatokra gyakorolt hatás elemzése, értesítési idővonal bizonyítékai |
A tanulság egyszerű. Egy böngészőbővítmény nem túl kicsi ahhoz, hogy számítson. Ha szabályozott adatokat, hitelesített munkameneteket, pénzügyi munkafolyamatokat vagy kritikus SaaS-szolgáltatásokat érhet el, irányítani kell.
Az ISO/IEC 27001:2022 használata működési modellként
Az ISO/IEC 27001:2022 azért hatékony a böngészőbővítmények irányításában, mert nem igényel külön megfelelőségi silót. Lehetővé teszi, hogy a szervezetek a meglévő ISMS-folyamatokat kiterjesszék a böngészőrétegre.
A gyakorlati kontrollmodell nyolc ISO/IEC 27001:2022 Annex A kontrollra épül:
| ISO/IEC 27001:2022 kontroll | Helyes kontrollnév | Alkalmazás böngészőbővítményekre |
|---|---|---|
| 5.10 | Acceptable use of information and other associated assets | Meg kell határozni, hogy a felhasználók mit telepíthetnek, használhatnak, kérelmezhetnek és tárolhatnak a böngészőkben |
| 5.19 | Information security in supplier relationships | A bővítményfejlesztőket és a kapcsolódó szolgáltatásokat releváns esetben beszállítói kockázatként kell kezelni |
| 5.23 | Information security for use of cloud services | Felül kell vizsgálni a külső SaaS API-khoz vagy felhőalapú háttérrendszerekhez kapcsolódó bővítményeket |
| 8.1 | User endpoint devices | A böngészőkonfigurációt a végpontvédelem részeként kell kezelni |
| 8.8 | Management of technical vulnerabilities | Nyomon kell követni a sérülékeny, elhagyott, kompromittálódott vagy magas kockázatú bővítményeket |
| 8.15 | Logging | Rögzíteni kell a telepítéseket, eltávolításokat, blokkolt kísérleteket, szabályzatmódosításokat és adminisztrátori műveleteket |
| 8.16 | Monitoring activities | Riasztani kell a rendellenes bővítménytevékenységekre és szabályzatsértésekre |
| 8.19 | Installation of software on operational systems | Jóváhagyást kell előírni, mielőtt bővítmények települnek munkahelyi rendszerekre |
A [ZC] Zenith Controls: keresztmegfelelési útmutató különösen hasznos, mert bemutatja, hogyan auditálják az ISO/IEC 27001 kontrollokat, és hogyan támogatják a több keretrendszert lefedő bizonyítékokat. A Control 8.19 esetében a Zenith Controls: keresztmegfelelési útmutató kifejti, hogy az auditorok “végigkövetik a munkafolyamatot: a kérelemtől a tesztelésen és jóváhagyáson át a bevezetésig”. Pontosan így kell kialakítani a bővítmények irányítását.
Ha egy auditor olyan bővítményt talál, amely nincs a jóváhagyott listán, nem szerepel a változásnyilvántartásokban, és nem készült róla kockázatértékelés, a probléma már nem pusztán böngészőbeállítás. Gyenge szoftvertelepítési kontrollra, gyenge végpontirányításra és lehetséges beszállítóikockázat-kezelési hibára utaló bizonyítékká válik.
1. lépés: a bővítményállomány feltárása
Maria fintech vállalatánál az első kontrollhiba a láthatóság hiánya volt. A csapata nem tudta, mely bővítmények vannak telepítve, ki telepítette őket, milyen jogosultságokat kértek, illetve kapcsolódnak-e külső szolgáltatásokhoz.
A feltárásnak ki kell terjednie minden felügyelt böngészőre, profilra, felhasználóra, eszközre és operációs rendszerre. Azonosítania kell a bővítmény nevét, egyedi azonosítóját, verzióját, kiadóját, telepítési forrását, jogosultságkészletét, telepítési dátumát, frissítési állapotát, felhasználószámát, üzleti tulajdonosát, valamint azt, hogy a bővítmény kényszerítetten telepített, felhasználó által telepített, nem hivatalos forrásból telepített vagy blokkolt.
A Control 8.1, User endpoint devices, az alapkontroll. A Zenith Blueprint: auditorként használható 30 lépéses ütemterv Control 8.1-re vonatkozó útmutatása szerint a felhasználói végponti eszközöket “meg kell erősíteni, felügyelni és kontroll alatt kell tartani”. Ez a követelmény természetes módon magában foglalja a böngészőt is, mivel a böngésző mára a SaaS- és felhőalapú munkavégzés elsődleges felhasználói végponti felülete.
A Control 5.23 szintén alkalmazandó, amikor a bővítmények felhőszolgáltatásokhoz kapcsolódnak. A Zenith Blueprint: auditorként használható 30 lépéses ütemterv ezt a kontrollt a shadow IT-re adott válaszként keretezi, ahol a felhasználók irányítás nélkül vesznek igénybe nem engedélyezett szolgáltatásokat. Az a böngészőbővítmény, amely tartalmat küld egy ismeretlen hosztolt háttérrendszernek, felhőszolgáltatás-bevezetési esemény, még akkor is, ha azt a beszerzésben senki nem hagyta jóvá.
Egy érett feltárási eredménynek minden bővítményt az alábbi öt állapot egyikébe kell sorolnia:
| Bővítményállapot | Jelentés | Szükséges intézkedés |
|---|---|---|
| Jóváhagyott | Felülvizsgált, indokolt és meghatározott felhasználók számára engedélyezett | Időszakos nyomon követés és felülvizsgálat |
| Feltételes | Korlátozásokkal engedélyezett, például meghatározott csoportokra, webhelyekre vagy jogosultságokra | A feltételek kikényszerítése és gyakoribb felülvizsgálat |
| Felülvizsgálatra vár | Feltárt vagy kérelmezett, de még nem értékelt | Blokkolás vagy karantén a jóváhagyásig |
| Blokkolt | Ismerten kockázatos, szükségtelen, nem megfelelő vagy tiltott | A telepítés megakadályozása és a meglévő példányok eltávolítása |
| Kivétel | Üzleti igény és elfogadott kockázat miatt ideiglenesen engedélyezett | Tulajdonos, lejárati dátum, kompenzáló kontrollok és jóváhagyó rögzítése |
A feltárás nem lehet egyszeri projekt. A bővítmények gyakran frissülnek, a kiadók tulajdonosi köre változik, a jogosultságok bővülnek, és az áruházak sokszor csak azután távolítják el a rosszindulatú csomagokat, hogy a felhasználók már telepítették őket. A nyilvántartásnak folyamatosnak kell lennie, vagy legalább olyan gyakorisággal kell ismétlődnie, amely támogatja a sérülékenységkezelést és az auditbizonyítékokat.
2. lépés: az elfogadható használat egyértelmű meghatározása
Miután a bővítmények láthatóvá váltak, a felhasználói elvárásokat egyértelműen meg kell határozni. Sok szervezet már rendelkezik olyan szabályzati megfogalmazással, amely támogatni tudja a bővítmények irányítását, de azt kifejezetten alkalmazni kell a böngészőre.
[P-EPM] Végpontvédelem – kártevővédelmi szabályzat – KKV kimondja, hogy a felhasználók “nem telepíthetnek jogosulatlan szoftvert vagy bővítményeket, amelyek kockázatot vezethetnek be”. Ez az egy mondat erős szabályzati alapot ad a biztonsági csapatoknak ahhoz, hogy a böngészőbővítményeket kontrollált szoftverként kezeljék.
[P03-AUP] P03 Elfogadható használati szabályzat, amelyre vállalati Elfogadható használati szabályzatként is hivatkoznak, tiltja a következőt: “Nem engedélyezett eszközök: jogosulatlan szoftver, hardver, felhőszolgáltatás vagy eszköz telepítése vagy használata”. Ez a felhasználók felé irányuló alapkövetelmény. A böngészőbővítmények irányítását technikai preferenciából betartatható magatartási és megfelelőségi követelménnyé alakítja.
Egy erős böngészőbővítmény-szabályzatnak hat gyakorlati kérdésre kell választ adnia:
| Szabályzati kérdés | Irányítási válasz |
|---|---|
| Telepíthetnek-e a felhasználók szabadon bővítményeket? | Nem, a bővítmények jóváhagyást igényelnek, kivéve ha szerepkör vagy csoport alapján előzetesen jóváhagyottak |
| Szoftvernek minősülnek-e a böngészőbővítmények? | Igen, operatív rendszerekre telepített szoftverek |
| Felhőszolgáltatásnak minősülnek-e a bővítmények háttérrendszerei? | Igen, ha szervezeti adatokat kezelnek, továbbítanak, tárolnak vagy gazdagítanak |
| Ki hagyja jóvá a bővítményeket? | A biztonság, az IT, az adatvédelem és az üzleti tulajdonosok kockázat alapján hagyják jóvá |
| Mi történik a nem jóváhagyott bővítményekkel? | Blokkolásra, eltávolításra vagy felülvizsgálatig karanténba kerülnek |
| Hogyan kell kezelni a kivételeket? | A kivételek dokumentált kockázatelfogadást, lejárati dátumot és kompenzáló kontrollokat igényelnek |
Nem arról van szó, hogy minden hasznos bővítményt tiltani kell. A cél az implicit bizalomról az explicit jóváhagyásra való áttérés. Egyes bővítmények biztonságosak, szükségesek és produktivitást javítóak lehetnek. Mások szükségtelenek, túlzott jogosultságúak, elhagyottak vagy ellenségesek. Az irányítási programnak különbséget kell tennie közöttük.
3. lépés: alapértelmezett tiltás és kivételalapú engedélyezési lista alkalmazása
A Control 8.19, Installation of software on operational systems az a kontroll, amely a szabályzatot működéssé alakítja. A böngészőbővítményeket nem szabad másképp kezelni, mint más szoftvereket pusztán azért, mert a felhasználók böngészőáruházból telepítik őket.
A Zenith Blueprint: auditorként használható 30 lépéses ütemterv ebben egyértelmű: “semmilyen szoftver nem települhet, hacsak nem indokolt, engedélyezett és biztonságossá tett”. Böngészőbővítmények esetében ez azt jelenti, hogy vállalati böngészőkezeléssel, végpontkezeléssel vagy eszközkonfigurációs eszközökkel kell kikényszeríteni a telepítési szabályokat.
A leginkább igazolható modell az alapértelmezett tiltás kivételalapú engedélyezési listával:
- Minden bővítmény alapértelmezett blokkolása a felügyelt böngészőkben.
- Csak a nélkülözhetetlen, jóváhagyott vállalati bővítmények kényszerített telepítése.
- Engedélyezési lista fenntartása jóváhagyott bővítményekhez felhasználói csoport, szervezeti egység vagy szerepkör szerint.
- A nem hivatalos forrásból telepített bővítmények és nem megbízható telepítési források blokkolása.
- Annak megakadályozása, hogy a felhasználók profilváltással vagy nem felügyelt böngészőkkel megkerüljék a szabályokat.
- A már telepített, de nem jóváhagyott bővítmények eltávolítása.
- A bővítményjogosultságok és a kiadói kockázat felülvizsgálata jóváhagyás előtt.
- Az engedélyezett, blokkolt, eltávolított és módosított bővítmények naplózása.
Egyes szervezetek az üzemeltetési összetettség miatt puhább modellel kezdenek. Először nyilvántartást készítenek, blokkolják az ismerten rossz bővítményeket, majd fokozatosan vezetik be az engedélyezési listát a magas kockázatú csoportoknál, például a pénzügy, mérnökség, privilegizált rendszergazdák, jog, HR és ügyféltámogatás esetében. Ez elfogadható, ha dokumentált ütemterv áll mögötte. Ami nem igazolható, az az ismeretlen bővítménykockázat tartós tűrése.
4. lépés: a bővítmények kockázatértékelése beszállítóként és szoftverként
A böngészőbővítmények kockázati felülvizsgálatának elég könnyűnek kell lennie ahhoz, hogy az üzlet elfogadja, ugyanakkor elég erősnek ahhoz, hogy audit során megállja a helyét. A felülvizsgálatnak egyesítenie kell a szoftverkockázatot, a beszállítói kockázatot, a felhőkockázatot, az adatvédelmet és a sérülékenységkezelést.
[P-TP] Harmadik fél és beszállítói biztonsági szabályzat előírja, hogy “minden új beszállítónak dokumentált biztonsági értékelésen kell átesnie a szerződéskötés előtt”. Nem minden bővítményfejlesztő esetében szükséges teljes vállalati beszállítói beléptetési folyamat, de a beszállítói kockázat elve továbbra is alkalmazandó. Ha egy fejlesztő kódfrissítéseket tud betolni a munkavállalók böngészőibe, vagy háttérszolgáltatáson keresztül szervezeti adatokat kezel, akkor a szervezet harmadik fél függőséggel rendelkezik.
[P-ASR] Alkalmazásbiztonsági követelmények szabályzata – KKV ugyanezt a követelményt szoftveres nézőpontból erősíti meg: “az alkalmazásban használt minden harmadik féltől származó eszközt, bővítményt vagy külső kódkönyvtárat rögzíteni kell, és évente felül kell vizsgálni biztonsági hatás és javításkezelési állapot szempontjából”.
A döntések egységesítéséhez használja az alábbi kockázati modellt:
| Kockázati tényező | Alacsony kockázat | Közepes kockázat | Magas kockázat |
|---|---|---|---|
| Jogosultságok | Nincs hozzáférés oldaladatokhoz | Hozzáférés az aktív laphoz vagy korlátozott webhelyekhez | Olvasási és írási hozzáférés minden webhelyhez |
| Kiadó | Ellenőrzött kiadó erős múlttal | Ismert vállalat adatvédelmi tájékoztatóval | Ismeretlen személy, tisztázatlan tulajdonosi háttér, nincs adatvédelmi tájékoztató |
| Adathozzáférés | Helyben működik érzékeny adatok nélkül | Korlátozott üzleti adatokat lát | Személyes adatokhoz, pénzügyi adatokhoz, titkokhoz vagy munkamenet-tartalomhoz fér hozzá |
| Kapcsolódás | Nincs külső háttérrendszer | Ismert szolgáltatáshoz kapcsolódik | Ismeretlen vagy átláthatatlan harmadik fél háttérrendszerhez kapcsolódik |
| Frissítési modell | Hivatalos áruház, rendszeres frissítések | Ritka frissítések, korlátozott változásnapló | Nem hivatalos forrásból telepített, elhagyott vagy tisztázatlan frissítési forrás |
| Üzleti igény | Jóváhagyott munkafolyamathoz szükséges | Hasznos, de kiváltható | Pusztán kényelmi célú, magas jogosultságokkal |
| Sérülékenységi előzmény | Nincs kedvezőtlen megállapítás | Korábbi problémák javítva | Ismert kompromittálódás, rosszindulatú viselkedés vagy megoldatlan sérülékenység |
| Adatvédelmi helyzet | Egyértelmű adatvédelmi tájékoztató és korlátozott gyűjtés | Széles körű tájékoztató, de elfogadható kontrollok | Nincs egyértelmű tájékoztató vagy túlzott gyűjtés |
Magas kockázatú bővítmény csak akkor hagyható jóvá, ha kritikus üzleti igény, dokumentált kompenzáló kontrollok és felsővezetői kockázatelfogadás áll fenn. Kompenzáló kontroll lehet például a használat korlátozása megerősített böngészőprofilra, meghatározott URL-ekre szűkítés, adatbevitel blokkolása érzékeny alkalmazásokban, amíg a bővítmény aktív, DLP-felügyelet alkalmazása, vagy beszállítói szerződés és adatvédelmi kiegészítés előírása.
5. lépés: adatvédelmi és GDPR-felülvizsgálat integrálása
A böngészőbővítmény-irányítás gyakran azért bukik el, mert az adatvédelmi felülvizsgálat elszakad a végponti eszközkezeléstől. Sok bővítmény azonban láthatja a SaaS-alkalmazásokban, HR-rendszerekben, támogatási jegyekben, CRM-nyilvántartásokban, e-mailben, analitikai platformokon és együttműködési eszközökben megjelenő személyes adatokat.
A GDPR Article 5(2) alapján a szervezetnek igazolnia kell az elszámoltathatóságot. Az Article 25 alapján be kell vezetnie a beépített és alapértelmezett adatvédelmet. Az Article 32 alapján megfelelő technikai és szervezeti intézkedéseket kell alkalmaznia az adatkezelés biztonságához. Ha egy bővítmény személyes adatokat visz ki, az esemény a GDPR Article 4(12) szerinti személyesadat-sértéssé válhat, amely értékelést és adott esetben Article 33 szerinti értesítési kötelezettségeket válthat ki.
Egy adatvédelmi szempontú bővítmény-felülvizsgálatnak az alábbi kérdéseket kell feltennie:
| GDPR felülvizsgálati terület | Bővítmény-felülvizsgálati kérdés | Megőrzendő bizonyíték |
|---|---|---|
| Adatkategóriák | Hozzáférhet-e a bővítmény személyes adatokhoz, különleges adatokhoz vagy pénzügyi adatokhoz? | Adathozzáférési értékelés |
| Célhoz kötöttség | Szükséges-e a bővítmény meghatározott üzleti célhoz? | Üzleti indoklás |
| Adattakarékosság | A kért jogosultságok a szükséges minimumra korlátozódnak-e? | Jogosultság-felülvizsgálat |
| Adatfeldolgozói kapcsolat | A bővítményszolgáltató a szervezet nevében kezel-e adatokat? | Beszállítói és adatvédelmi értékelés |
| Nemzetközi továbbítások | Elhagyják-e az adatok a joghatóságot vagy a jóváhagyott tárhelyrégiót? | Adattovábbítási értékelés |
| Megőrzés | Tárol-e a szolgáltató adatokat, naplókat, promptokat, képernyőképeket vagy metaadatokat? | Adatvédelmi tájékoztató és megőrzési felülvizsgálat |
| Biztonság | Megfelelőek-e a titkosítás, a hozzáférés-szabályozások és a sérülékenységkezelési gyakorlatok? | Biztonsági átvilágítás |
| Incidensreagálás | Tudja-e a szolgáltató értesíteni a szervezetet incidensekről? | Szerződéses vagy dokumentált reagálási bizonyíték |
Nem minden bővítmény igényel teljes DPIA-t. Ugyanakkor a széles körű oldalhozzáféréssel, AI-feldolgozással, képernyőrögzítéssel, e-mail-hozzáféréssel, CRM-hozzáféréssel, HR-adat-hozzáféréssel, ügyféltámogatási adatokkal vagy szabályozott pénzügyi adatokkal érintett bővítményeknek strukturált adatvédelmi értékelést kell kiváltaniuk.
6. lépés: naplózás és felügyelet audithoz és incidensreagáláshoz
A naplók nélküli bővítményirányítási program nem auditálható. Az incidensreagálást is gyengíti, mert a szervezet nem tudja megállapítani, mikor telepítettek egy bővítményt, ki használta, mely verzió volt jelen, mikor változtak a jogosultságok, vagy történt-e blokkolt telepítési kísérlet.
[P-LM] Naplózási és felügyeleti szabályzat – KKV a “szoftvertelepítések” naplóit kulcsfontosságú irányítási követelményként azonosítja. A böngészőbővítmény telepítése szoftvertelepítési esemény, és ennek megfelelően rögzíteni kell.
Minimumként a naplóknak tartalmazniuk kell:
| Naplóesemény | Miért fontos |
|---|---|
| Bővítmény telepítve | Megerősíti a bevezetést és támogatja a változásbizonyítékot |
| Bővítmény blokkolva | Mutatja a megelőző kontroll működését |
| Bővítmény eltávolítva | Megerősíti a helyesbítő intézkedést |
| Bővítmény frissítve | Támogatja a sérülékenységi és változás-felülvizsgálatot |
| Jogosultság módosítva | Észleli a jóváhagyás utáni kockázatnövekedést |
| Szabályzat módosítva | Mutatja az adminisztratív kontrollt és az elszámoltathatóságot |
| Nem hivatalos forrásból történő telepítési kísérlet | Megkerülési viselkedésre vagy malware-kockázatra utal |
| Áruházforrás módosítva | Észleli a nem megbízható telepítési útvonalat |
| Magas kockázatú bővítmény észlelve | Triage-t és eltávolítást indít |
| Felhasználói kivétel megadva | Támogatja a kockázatelfogadási bizonyítékot |
Ezeknek a naplóknak be kell kerülniük a 8.15 és 8.16 kontrollok szerinti felügyeleti folyamatokba. Kockázattól függően SIEM-be, végponti platformra vagy megfelelőségi bizonyítéktárba is továbbíthatók. Riasztásokat kell konfigurálni a blokkolt magas kockázatú bővítményekre, a bővítménykérelmek hirtelen megugrására, a jóváhagyott bővítmények jogosultságváltozásaira, a nem hivatalos forrásból történő telepítési kísérletekre és a privilegizált felhasználók telepítési kísérleteire.
A felügyelet NIS2 és DORA szempontból is előnyt jelent. A NIS2 Article 23 szerinti incidensjelentés a korai észleléstől és a hatásvizsgálattól függ. A DORA robusztus IKT-incidenskezelést és rezilienciabizonyítékokat követel meg. A GDPR szerinti incidensértékelés attól függ, hogy a szervezet tudja-e, mi történt, mikor történt, és milyen adatok lehettek érintettek.
Mit akar látni az auditor
Az auditort ritkán elégíti ki egy olyan kijelentés, hogy “blokkoljuk a kockázatos bővítményeket”. Irányítási bizonyítékot akar látni. A bizonyítéknak össze kell kapcsolnia a szabályzatot, a kockázatértékelést, a technikai kikényszerítést, a felügyeletet és a vezetői elszámoltathatóságot.
| Auditkérdés | Erős válasz | Bizonyíték-artefaktum |
|---|---|---|
| A böngészőbővítmények a hatályba tartoznak? | Igen, felhasználói végponti eszközökön futó szoftverként kezeljük őket | ISMS-hatókör, eszköznyilvántartás, végpontszabvány |
| Tiltott a felhasználóknak nem jóváhagyott bővítményeket telepíteni? | Igen, az elfogadható használati és végponti szabályzatok meghatározzák a szabályt | Végpontvédelem – kártevővédelmi szabályzat – KKV, P03 Elfogadható használati szabályzat |
| Létezik jóváhagyott bővítménylista? | Igen, a jóváhagyott bővítmények üzleti tulajdonos és felhasználói csoport szerint dokumentáltak | Engedélyezési lista exportja, jóváhagyási nyilvántartás |
| Készül kockázatértékelés az új bővítményekről? | Igen, a kérelmek szoftver-, beszállítói, sérülékenységi és adatvédelmi ellenőrzéseket indítanak | Kockázatértékelési feljegyzés |
| A bővítményfejlesztőket releváns esetben beszállítóként kezelik? | Igen, a magas kockázatú szolgáltatók átvilágításon mennek át | Beszállítói értékelés |
| Felülvizsgálják a felhőhöz kapcsolódó bővítményeket? | Igen, a külső háttérrendszereket a felhőszolgáltatások irányítása szerint értékeljük | Felhőszolgáltatás-felülvizsgálat |
| A telepítések technikailag kikényszerítettek? | Igen, az alapértelmezett tiltás és a csoportalapú engedélyezési listák a böngészőkezelésben érvényesülnek | Konfigurációexport |
| Naplózzák a változásokat? | Igen, a telepítés, blokkolás, eltávolítás, frissítés és adminisztrátori módosítások naplózásra kerülnek | SIEM- vagy adminisztrációs konzolnaplók |
| Kontrolláltak a kivételek? | Igen, a kivételek tulajdonost, lejáratot, jóváhagyót és kompenzáló kontrollokat igényelnek | Kivételnyilvántartás |
| Ismétlődnek a felülvizsgálatok? | Igen, a bővítményeket időszakosan és jelentős változások után felülvizsgáljuk | Felülvizsgálati ütemezés és bizonyíték |
Itt válik értékessé a Zenith Controls: keresztmegfelelési útmutató. Segít megmutatni, hogyan támogat egyetlen kontrolltevékenység több megfelelőségi elvárást. Egyetlen böngészőbővítmény-jóváhagyási munkafolyamat támogathatja az ISO/IEC 27001 Control 8.19-et, a NIS2 kiberhigiéniát, a DORA IKT-kockázatkezelést és a GDPR elszámoltathatóságot, ha a bizonyítékokat megőrzik és egyértelműen leképezik.
Áttekintő megfeleltetés: ISO/IEC 27001:2022, NIS2, DORA és GDPR
Egy gyakorlati megfeleltetés segít az információbiztonsági vezetőknek elmagyarázni, miért nem szűk technikai kontroll a böngészőbővítmények irányítása. Széles szabályozói értékkel bíró megfelelőségi kontrollról van szó.
| ISO/IEC 27001:2022 kontroll | NIS2 összhang | DORA összhang | GDPR összhang | Böngészőbővítmény-bizonyíték |
|---|---|---|---|---|
| 5.10 Acceptable use of information and other associated assets | Article 21 kiberhigiénia és felhasználói gyakorlatok | Article 5 irányítási elvárások | Article 5(2) elszámoltathatóság | Elfogadható használatra vonatkozó szabályok, felhasználói tudatosság, szabályzati nyilatkozatok |
| 5.19 Information security in supplier relationships | Article 21 ellátási lánc biztonsága | Article 28 harmadik fél IKT-kockázatkezelés | Articles 28 and 32, ahol adatkezelés történik | Beszállítói felülvizsgálat, szolgáltató értékelése, szerződéselemzés |
| 5.23 Information security for use of cloud services | Article 21 IKT- és hálózatbiztonság | Articles 6 and 28 IKT-kockázat és harmadik fél függőségek | Articles 25 and 32 beépített adatvédelem és biztonság | Felhőháttérrendszer-felülvizsgálat, SaaS-integráció jóváhagyása |
| 8.1 User endpoint devices | Article 21 végpontbiztonság és hozzáférés-szabályozás | Article 6 IKT-kockázatkezelési keretrendszer | Article 32 adatkezelés biztonsága | Böngészőkonfiguráció, felügyelt profilok, végpontnyilvántartás |
| 8.8 Management of technical vulnerabilities | Article 21 sérülékenységkezelés | Article 6 védelem és megelőzés | Article 32 technikai intézkedések | Sérülékeny bővítmények nyomon követése, helyesbítő intézkedések nyilvántartásai |
| 8.15 Logging | Article 23 incidensbizonyíték | IKT-incidenskezelési és rezilienciabizonyítékok | Articles 5(2), 32 and 33 elszámoltathatósági és incidensbizonyítékok | Telepítési naplók, blokkolt kísérletek, szabályzatmódosítások |
| 8.16 Monitoring activities | Article 21 észlelés és Article 23 jelentéstétel | IKT-felügyelet és incidensészlelés | Articles 32 and 33 incidensészlelés | Riasztások, SIEM-események, anomáliajelentések |
| 8.19 Installation of software on operational systems | Article 21 biztonságos konfiguráció és szoftverkontroll | IKT-változáskezelési elvárások, beleértve a COBIT BAI06 Managed IT Changes kontrollt auditnézőpontként | Articles 25 and 32 kontrollált adatkezelési környezet | Kérelem, jóváhagyás, tesztelés, bevezetés, engedélyezési lista bizonyítékai |
A DORA-leképezés külön figyelmet érdemel. Egyes auditorok és értékelők COBIT-stílusú nyelvezetet használnak az IKT-változáskezelés felülvizsgálatakor. A COBIT BAI06 általánosan Managed IT Changes néven ismert. Ha a böngészőbővítmények szoftverek, és telepítésük megváltoztatja a felhasználói számítástechnikai környezetet, akkor a bővítmények telepítése ugyanabba az irányított változáslogikába tartozik. A Zenith Controls: keresztmegfelelési útmutató támogatja ezt az auditnézőpontot azzal, hogy bemutatja, hogyan használható újra az ISO/IEC 27001 kontrollbizonyíték több megfelelőségi elvárás között.
90 napos bevezetési terv a böngészőbővítmények irányításához
A szervezeteknek nem kell mindent egyetlen hét alatt megoldaniuk. Gyakorlati program fázisokban is felépíthető, különösen akkor, ha az üzleti zavarokat körültekintően kell kezelni.
| Ütemezés | Cél | Tevékenységek | Eredménytermékek |
|---|---|---|---|
| 1–15. nap | Hatály és tulajdonosi felelősség meghatározása | IT-, biztonsági, adatvédelmi, beszerzési és üzleti tulajdonosok kijelölése; felügyelt böngészők és felhasználói csoportok megerősítése | Irányítási tulajdonosi lista, böngészőhatókör, kezdeti kockázati állítás |
| 16–30. nap | Jelenlegi állapot feltárása | Telepített bővítmények, jogosultságok, kiadók, verziók, felhasználók és telepítési források nyilvántartásba vétele | Bővítménynyilvántartás, magas kockázatú megállapítások, kezdeti vezetői összefoglaló |
| 31–45. nap | Szabályzat és döntési szabályok meghatározása | Elfogadható használati, végponti, felhő- és beszállítói eljárások frissítése a bővítmények bevonásával | Szabályzatfrissítések, jóváhagyási kritériumok, kivételkezelési folyamat |
| 46–60. nap | Kockázatértékelési munkafolyamat kialakítása | Kéreleműrlap, pontozási modell, adatvédelmi kérdések, beszállítói triage és jóváhagyási nyilvántartások létrehozása | Bővítménykérelmezési munkafolyamat, kockázati mátrix, bizonyítéksablonok |
| 61–75. nap | Technikai kontrollok kikényszerítése | Alapértelmezett tiltás vagy fokozatos engedélyezési lista konfigurálása, nem hivatalos forrásból történő telepítés blokkolása, ismert kockázatos bővítmények eltávolítása | Böngészőkezelési konfiguráció, engedélyezési lista, tiltólista |
| 76–90. nap | Felügyelet és bizonyítékkezelés | Naplók továbbítása felügyeleti eszközökbe, riasztások létrehozása, auditbizonyítékok tesztelése, jelentés a vezetésnek | Naplózási irányítópult, riasztási szabályok, auditcsomag, vezetői jelentés |
Magas kockázatú szervezeteknél, különösen DORA hatálya alá tartozó pénzügyi szervezeteknél vagy NIS2 szerinti alapvető és fontos szervezeteknél, az első kikényszerítési fázisban előnyben kell részesíteni azokat a felhasználókat, akik kritikus rendszerekhez, szabályozott adatokhoz, privilegizált adminisztrációs konzolokhoz, pénzügyi platformokhoz, ügyféltámogatási eszközökhöz és fejlesztői környezetekhez férnek hozzá.
Az igazgatósági szintű üzenet
A böngészőbővítmények irányítását nem böngészőmegerősítési projektként kell bemutatni a felsővezetőknek. Úgy kell bemutatni, mint kontrollt a szabályozott munkafolyamatokban futó, előzetesen nem ellenőrzött harmadik fél kód felett.
Az igazgatóságnak és a vezető testületnek négy pontot kell megértenie:
- A böngésző mára alapvető üzleti platform.
- A bővítmények érzékeny SaaS-adatokhoz és hitelesített munkamenetekhez férhetnek hozzá.
- A nem kezelt bővítmények beszállítói, adatvédelmi, incidens- és rezilienciakockázatot hoznak létre.
- Az ISO/IEC 27001:2022 igazolható kontrollmodellt ad, amely támogatja a NIS2-, DORA- és GDPR-bizonyítékokat.
Ez a keretezés a beszélgetést a technikai preferenciáról az operatív reziliencia irányába mozdítja. Támogatja továbbá a vállalati böngészőkezelés, a végponti integráció, a felügyelet, az adatvédelmi felülvizsgálat, a beszállítói triage és az auditbizonyíték-automatizálás finanszírozását.
Vakfoltból stratégiai kontroll
Maria auditproblémáját nem az okozta, hogy egy elemző telepített egy produktivitási eszközt. Egy nem kezelt kockázati osztály okozta. A szervezet erős megfelelőségi programot épített a látható eszközök, látható beszállítók, látható SaaS-platformok és látható végpontok köré, de a böngészőbővítmény-réteg láthatatlan maradt.
Ez a hiányosság ma már túl fontos ahhoz, hogy figyelmen kívül maradjon.
A megoldás nem bonyolult, de tudatosnak kell lennie. A böngészőt a végpont részeként kell kezelni. A bővítményeket szoftverként kell kezelni. A bővítményfejlesztőket és háttérrendszereket releváns esetben beszállítóként kell kezelni. A jogosultságokat adathozzáférésként kell kezelni. A telepítést változásként kell kezelni. A naplókat megfelelőségi bizonyítékként kell kezelni.
Egy igazolható program négy intézkedéssel indul:
- Minden bővítmény feltárása a felügyelt böngészőkben és végpontokon.
- Elfogadható használati és alapértelmezett tiltási szabályok meghatározása a Végpontvédelem – kártevővédelmi szabályzat – KKV, a P03 Elfogadható használati szabályzat és a vállalati Elfogadható használati szabályzat alapján.
- A bővítménykérelmek értékelése beszállítói, felhő-, sérülékenységi és adatvédelmi szempontok szerint a Harmadik fél és beszállítói biztonsági szabályzat és az Alkalmazásbiztonsági követelmények szabályzata – KKV alapján.
- A telepítési tevékenység kikényszerítése és felügyelete böngészőkezeléssel, naplózással és a Naplózási és felügyeleti szabályzat – KKV szerinti bizonyítékkezelési gyakorlatokkal összhangban.
A NIS2, DORA, GDPR vagy ISO/IEC 27001:2022 auditokra készülő információbiztonsági vezetők számára a böngészőbővítmények irányítása nagy értékű kontrollfejlesztés, mert valós támadási útvonalat zár le, miközben újrahasznosítható bizonyítékokat hoz létre több keretrendszerhez.
A munka felgyorsításához töltse le a Zenith Blueprint: auditorként használható 30 lépéses ütemterv, és képezze le bizonyítékait a Zenith Controls: keresztmegfelelési útmutató segítségével. Ha a böngészőbővítmények káoszát auditra kész irányítási programmá szeretné alakítani, ütemezzen Clarysec értékelést vagy demót, és kezdjen gyakorlati nyilvántartással, kockázati térképpel és 90 napos kontrolltervvel.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
