Upravljanje razširitev brskalnikov za NIS2, DORA in GDPR

Maria, vodja informacijske varnosti v hitro rastočem fintech podjetju, je menila, da predhodna presoja DORA poteka dobro. Njena ekipa je pripravila register tretjih oseb za IKT, kritične pogodbe SaaS, zapise skrbnega pregleda dobaviteljev, odločitve o sprejemu tveganj in poročilni paket za organ upravljanja.

Nato je presojevalec postavil vprašanje, na katero ni bil nihče pripravljen.

“Ali nam lahko pokažete svoj proces upravljanja razširitev brskalnikov?”

Vprašanje je izhajalo iz pregleda končne točke pri finančnem analitiku. Med deljenjem zaslona je presojevalec v analitikovem brskalniku opazil razširitev tretje osebe za produktivnost. Videti je bila neškodljiva, vendar je hiter pregled pokazal, da je bil razvijalec tri mesece prej žrtev kompromitacije dobavne verige. Kompromitirana razširitev je bila uporabljena za prestrezanje sejnih žetonov za večje platforme SaaS.

Fintech podjetje je imelo stroge politike proti nepooblaščeni programski opremi. Imelo je EDR, MFA, CASB, dnevnike SaaS in sistem upravljanja informacijske varnosti (ISMS), usklajen z ISO/IEC 27001. Vendar nihče ni obravnaval brskalnika kot upravljane programske platforme. Nihče ni popisal razširitev. Nihče ni odobril njihovih dovoljenj. Nihče ni preveril, ali so razvijalci razširitev dobavitelji. Nihče ni preslikal dejavnosti razširitev v dokazila za DORA, NIS2 ali GDPR.

Ena sama razširitev brskalnika je končno točko, ki je bila videti skladna, spremenila v morebitna stranska vrata do finančnih sistemov, podatkov strank in reguliranih delovnih tokov.

To je problem upravljanja razširitev brskalnikov v letu 2026. Brskalnik ni več zgolj okno v internet. V njem se zaposleni avtenticirajo, odobravajo plačila, dostopajo do evidenc CRM, obdelujejo osebne podatke, upravljajo infrastrukturo v oblaku in uporabljajo kritične platforme SaaS. Razširitve niso več kozmetični dodatki. So koda tretjih oseb, ki se izvaja znotraj najbolj občutljive plasti sodobnega dela.

Za vodje informacijske varnosti, vodje skladnosti, pooblaščene osebe za varstvo podatkov (DPO) in lastnike IKT-tveganj neupravljane razširitve ležijo na stičišču varnosti končnih točk, neodobrene IT, tveganj dobaviteljev, upravljanja sprememb, upravljanja ranljivosti in odgovornosti za zasebnost. ISO/IEC 27001:2022 organizacijam daje strukturo za upravljanje tega tveganja. NIS2, DORA in GDPR pa ustvarjajo regulativni pritisk, da ga organizacije tudi dokažejo.

Razširitve brskalnikov so programska oprema, dobavitelji in obdelovalci podatkov

Večina organizacij se je že naučila upravljati prenosnike, mobilne naprave, strežnike, aplikacije SaaS, infrastrukturo v oblaku in privilegirane račune. Razširitve brskalnikov pa pogosto padejo med te programe.

Varnostne ekipe jih vidijo kot nastavitev brskalnika. Nabava jih ne vidi, ker ni podpisane pogodbe. Pravna služba jih ne vidi, ker ni odprte zahteve za uvedbo dobavitelja. Ekipe za zasebnost jih ne vidijo, ker razširitev namesti uporabnik in ni uvedena kot uradna aplikacija. Kljub temu lahko razširitev zahteva dovoljenje za branje in spreminjanje podatkov na vseh spletnih mestih, dostop do vsebine odložišča, zajem metapodatkov strani, upravljanje prenosov, vstavljanje skript ali komunikacijo z zunanjim zaledjem.

To pomeni, da je lahko razširitev brskalnika hkrati vse od naslednjega:

[ZB] Zenith Blueprint: An Auditor’s 30-Step Roadmap zajame bistvo problema v svojih smernicah ISO/IEC 27002:2022 za kontrolo 8.19. Opozarja, da lahko “tudi dobronamerni zaposleni namestijo orodja, da bi ‘delo opravili hitreje’ — razširitev brskalnika, knjižnico kode ali aplikacijo za prenos datotek — ne da bi se zavedali, da so pravkar uvedli stranska vrata, nepopravljeno odvisnost ali vektor iznosa podatkov.”

Ta stavek je treba obravnavati kot izjavo o tveganju na ravni upravnega odbora. Zaposleni, ki nameščajo tvegane razširitve, običajno ne poskušajo obiti varnosti. Poskušajo izboljšati produktivnost. Odpoved upravljanja nastane, kadar organizacija ne zagotovi varnega procesa za zahtevo, odobritev, uvedbo in spremljanje.

Zakaj NIS2, DORA in GDPR zahtevajo nujno obravnavo te slepe pege

Tveganje razširitev brskalnikov obstaja že leta, vendar se je regulativni kontekst spremenil. V letu 2026 se od organizacij pričakuje, da ne dokažejo le obstoja kontrol, temveč tudi, da so te utemeljene na tveganjih, integrirane, spremljane in podprte z dokazili.

NIS2 zvišuje pričakovanja glede kibernetske higiene in varnosti dobavne verige. DORA od finančnih subjektov zahteva upravljanje IKT-tveganj v notranjih odvisnostih in odvisnostih od tretjih oseb. GDPR od upravljavcev in obdelovalcev zahteva dokazovanje varnosti obdelave, odgovornosti ter vgrajenega in privzetega varstva podatkov. Neupravljane razširitve lahko spodkopljejo vse tri.

Sporočilo je preprosto. Razširitev brskalnika ni premajhna, da bi bila pomembna. Če lahko poseže v regulirane podatke, avtenticirane seje, finančne delovne tokove ali kritične storitve SaaS, mora biti upravljana.

Uporabite ISO/IEC 27001:2022 kot operativni model

ISO/IEC 27001:2022 je učinkovit za upravljanje razširitev brskalnikov, ker ne zahteva ločenega silosa skladnosti. Organizacijam omogoča, da obstoječe procese ISMS razširijo na plast brskalnika.

Praktični kontrolni model temelji na osmih kontrolah iz Priloge A ISO/IEC 27001:2022:

[ZC] Zenith Controls: The Cross-Compliance Guide je posebej uporaben, ker pojasnjuje, kako se kontrole ISO/IEC 27001 presojajo in kako podpirajo dokazila med različnimi okviri. Za kontrolo 8.19 Zenith Controls: The Cross-Compliance Guide pojasnjuje, da bodo presojevalci “sledili delovnemu toku: od zahteve do testiranja, odobritve in implementacije.” Tako mora biti zasnovano tudi upravljanje razširitev.

Če presojevalec najde razširitev, ki ni na odobrenem seznamu, ni dokumentirana v zapisih o spremembah in ni bila predmet ocene tveganja, težava ni več zgolj nastavitev brskalnika. Postane dokaz šibkega nadzora nad nameščanjem programske opreme, šibkega upravljanja končnih točk in morebitne odpovedi pri obvladovanju tveganj dobaviteljev.

Korak 1: odkrijte okolje razširitev

Prva odpoved kontrole v Marijinem fintech podjetju je bila pomanjkanje vidnosti. Njena ekipa ni vedela, katere razširitve so nameščene, kdo jih je namestil, katera dovoljenja zahtevajo ali ali se povezujejo z zunanjimi storitvami.

Odkrivanje mora zajeti vse upravljane brskalnike, profile, uporabnike, naprave in operacijske sisteme. Identificirati mora ime razširitve, enolični ID, različico, izdajatelja, vir namestitve, nabor dovoljenj, datum namestitve, stanje posodobitev, število uporabnikov, poslovnega lastnika ter ali je razširitev prisilno nameščena, nameščena s strani uporabnika, nameščena izven uradne trgovine ali blokirana.

Kontrola 8.1, Uporabniške končne naprave, je izhodiščna kontrola. Smernice Zenith Blueprint: An Auditor’s 30-Step Roadmap za kontrolo 8.1 navajajo, da morajo biti uporabniške končne točke “utrjene, spremljane in nadzorovane.” Ta zahteva naravno vključuje brskalnik, ker je brskalnik danes primarni uporabniški vmesnik končne točke za delo s SaaS in oblakom.

Kontrola 5.23 velja tudi, kadar se razširitve povezujejo s storitvami v oblaku. Zenith Blueprint: An Auditor’s 30-Step Roadmap to kontrolo postavlja kot odziv na neodobreno IT, kjer uporabniki brez upravljanja sprejemajo neodobrene storitve. Razširitev brskalnika, ki pošilja vsebino v neznano gostovano zaledje, je dogodek uvedbe storitve v oblaku, tudi če ga ni odobrila nabava.

Zrel rezultat odkrivanja mora vsako razširitev razvrstiti v eno od petih stanj:

Odkrivanje ne sme biti enkraten projekt. Razširitve se pogosto posodabljajo, izdajatelji spreminjajo lastništvo, dovoljenja se širijo, trgovine pa odstranijo zlonamerne pakete šele potem, ko so jih uporabniki že namestili. Popis mora postati neprekinjen ali vsaj dovolj pogost, da podpira upravljanje ranljivosti in revizijska dokazila.

Korak 2: izrecno določite sprejemljivo uporabo

Ko so razširitve vidne, morajo biti pričakovanja do uporabnikov jasna. Številne organizacije že imajo besedilo politik, ki lahko podpira upravljanje razširitev, vendar ga je treba izrecno uporabiti za brskalnik.

[P-EPM] Endpoint Protection - Malware Policy - SME določa, da uporabniki “ne smejo nameščati nepooblaščene programske opreme ali vtičnikov, ki lahko uvedejo tveganje.” Ta en stavek daje varnostnim ekipam močno podlago v politiki, da razširitve brskalnikov obravnavajo kot nadzorovano programsko opremo.

[P03-AUP] P03 Acceptable Use Policy, imenovana tudi podjetniška Acceptable Use Policy, prepoveduje “neodobrena orodja: nameščanje ali uporabo nepooblaščene programske opreme, strojne opreme, storitev v oblaku ali naprav”. To je uporabniški temelj. Upravljanje razširitev brskalnikov iz tehnične preference pretvori v izvršljivo vedenjsko zahtevo in zahtevo skladnosti.

Močna politika razširitev brskalnikov mora odgovoriti na šest praktičnih vprašanj:

Namen ni prepovedati vsake uporabne razširitve. Namen je prehod od implicitnega zaupanja k izrecni odobritvi. Nekatere razširitve so lahko varne, potrebne in koristne za produktivnost. Druge so lahko nepotrebne, preveč privilegirane, opuščene ali škodljive. Program upravljanja mora znati razlikovati med njimi.

Korak 3: uveljavite privzeto zavračanje z izjemami na seznamu dovoljenih

Kontrola 8.19, Nameščanje programske opreme na operativne sisteme, je kontrola, ki politiko pretvori v operativno delovanje. Razširitev brskalnikov se ne sme obravnavati drugače od druge programske opreme samo zato, ker jih uporabniki nameščajo prek trgovine brskalnika.

Zenith Blueprint: An Auditor’s 30-Step Roadmap je pri tem neposreden: “nobena programska oprema se ne namesti, razen če je utemeljena, odobrena in zavarovana.” Za razširitve brskalnikov to pomeni uporabo upravljanja brskalnikov na ravni podjetja, upravljanja končnih točk ali orodij za konfiguracijo naprav za uveljavljanje pravil namestitve.

Najbolj zagovorljiv model je privzeto zavračanje z izjemami na seznamu dovoljenih:

1. Privzeto blokirajte vse razširitve za upravljane brskalnike.
2. Prisilno namestite samo bistvene, odobrene poslovne razširitve.
3. Vzdržujte seznam dovoljenih razširitev po uporabniški skupini, oddelku ali vlogi.
4. Blokirajte razširitve, nameščene izven uradne trgovine, in nezaupanja vredne vire namestitve.
5. Uporabnikom preprečite obid politik s preklapljanjem profilov ali uporabo neupravljanih brskalnikov.
6. Odstranite že nameščene razširitve, ki niso odobrene.
7. Pred odobritvijo preglejte dovoljenja razširitve in tveganje izdajatelja.
8. Beležite dovoljene, blokirane, odstranjene in spremenjene razširitve.

Nekatere organizacije začnejo z mehkejšim modelom zaradi operativne zahtevnosti. Najprej lahko izvedejo popis, blokirajo znano slabe razširitve in nato postopoma uvedejo sezname dovoljenih za visoko tvegane skupine, kot so finance, inženiring, privilegirani administratorji, pravna služba, kadrovska služba in podpora strankam. To je sprejemljivo, če obstaja dokumentiran časovni načrt. Ni pa zagovorljivo trajno dopuščanje neznanega tveganja razširitev.

Korak 4: ocenjujte tveganje razširitev kot pri dobaviteljih in programski opremi

Pregled tveganja razširitve brskalnika mora biti dovolj lahek za poslovno uporabo, vendar dovolj robusten za presojo. Pregled mora združevati tveganje programske opreme, tveganje dobaviteljev, tveganje oblaka, varstvo podatkov in upravljanje ranljivosti.

[P-TP] Third party and supplier security policy zahteva, da “morajo vsi novi dobavitelji pred sklenitvijo pogodbe opraviti dokumentirano varnostno presojo.” Vsak razvijalec razširitve ne bo zahteval celotnega podjetniškega procesa uvedbe dobavitelja, vendar načelo tveganja dobavitelja še vedno velja. Če lahko razvijalec potiska posodobitve kode v brskalnike zaposlenih ali obdeluje podatke organizacije prek zaledne storitve, ima organizacija odvisnost od tretje osebe.

[P-ASR] Application Security Requirements Policy - SME isto zahtevo utrjuje z vidika programske opreme: “Vsako orodje tretje osebe, vtičnik ali zunanja knjižnica kode, uporabljena v aplikaciji, mora biti evidentirana in letno pregledana glede varnostnega vpliva in stanja popravkov.”

Za standardizacijo odločitev uporabite naslednji model tveganja:

Visoko tvegane razširitve se ne sme odobriti, razen če obstajajo kritična poslovna potreba, dokumentirane kompenzacijske kontrole in sprejem tveganja s strani višjega vodstva. Primeri kompenzacijskih kontrol vključujejo omejitev uporabe na utrjen profil brskalnika, omejitev na določene URL-je, blokiranje vnosa podatkov v občutljive aplikacije, ko je razširitev aktivna, uporabo spremljanja DLP ali zahtevo po pogodbi z dobaviteljem in dodatku o zasebnosti.

Korak 5: vključite pregled zasebnosti in GDPR

Upravljanje razširitev brskalnikov pogosto odpove, ker je pregled zasebnosti ločen od orodij za končne točke. Vendar lahko številne razširitve vidijo osebne podatke, prikazane v aplikacijah SaaS, kadrovskih sistemih, zahtevkih podpore, evidencah CRM, e-pošti, analitičnih platformah in orodjih za sodelovanje.

Po GDPR Article 5(2) mora organizacija dokazati odgovornost. Po Article 25 mora uveljaviti vgrajeno in privzeto varstvo podatkov. Po Article 32 mora uporabiti ustrezne tehnične in organizacijske ukrepe za varnost obdelave. Če razširitev iznaša osebne podatke, lahko dogodek postane kršitev varnosti osebnih podatkov po Article 4(12), kar sproži presojo in morda obveznosti obveščanja po Article 33.

Pregled razširitev z vidika zasebnosti mora postaviti naslednja vprašanja:

Vsaka razširitev ne zahteva celovite DPIA. Vendar morajo razširitve s širokim dostopom do strani, obdelavo z umetno inteligenco, zajemom zaslona, dostopom do e-pošte, dostopom do CRM, dostopom do kadrovskih podatkov, podatkov podpore strankam ali reguliranih finančnih podatkov sprožiti strukturirano presojo zasebnosti.

Korak 6: beležite in spremljajte za presojo in odziv na incidente

Program upravljanja razširitev brez dnevnikov ni primeren za presojo. Prav tako oslabi odziv na incidente, ker organizacija ne more ugotoviti, kdaj je bila razširitev nameščena, kdo jo je uporabljal, katera različica je bila prisotna, kdaj so se spremenila dovoljenja ali ali je prišlo do blokiranega poskusa namestitve.

[P-LM] Logging and Monitoring Policy - SME opredeljuje dnevnike za “namestitve programske opreme” kot ključno zahtevo upravljanja. Namestitev razširitve brskalnika je dogodek namestitve programske opreme in jo je treba ustrezno zajeti.

Dnevniki morajo najmanj vključevati:

Ti dnevniki morajo napajati procese spremljanja po kontrolah 8.15 in 8.16. Odvisno od tveganja se lahko posredujejo tudi v SIEM, platformo končnih točk ali repozitorij dokazil o skladnosti. Opozorila je treba konfigurirati za blokirane visoko tvegane razširitve, nenadne poraste zahtev za razširitve, spremembe dovoljenj pri odobrenih razširitvah, poskuse namestitve iz neuradnih virov in poskuse namestitve s strani privilegiranih uporabnikov.

Spremljanje je tudi prednost za NIS2 in DORA. Poročanje o incidentih po NIS2 Article 23 je odvisno od zgodnjega zaznavanja in ocene vpliva. DORA zahteva robustno obravnavanje incidentov IKT in dokazila o odpornosti. Presoja kršitve po GDPR je odvisna od poznavanja, kaj se je zgodilo, kdaj in kateri podatki so lahko bili prizadeti.

Kaj želi videti presojevalec

Presojevalec se redko zadovolji z izjavo, kot je “blokiramo tvegane razširitve.” Želi dokazila o upravljanju. Dokazila morajo povezovati politiko, oceno tveganja, tehnično uveljavljanje, spremljanje in odgovornost vodstva.

Tu postane Zenith Controls: The Cross-Compliance Guide posebej dragocen. Organizacijam pomaga pokazati, kako ena kontrolna dejavnost podpira več zahtev skladnosti. En sam odobritveni delovni tok za razširitev brskalnika lahko podpira ISO/IEC 27001 kontrolo 8.19, kibernetsko higieno NIS2, upravljanje IKT-tveganj po DORA in odgovornost po GDPR, če so dokazila hranjena in jasno preslikana.

Preslikava ISO/IEC 27001:2022 na NIS2, DORA in GDPR

Praktična preslikava pomaga vodjem informacijske varnosti pojasniti, zakaj upravljanje razširitev brskalnikov ni nišna tehnična kontrola. Je kontrola skladnosti s široko regulativno vrednostjo.

Preslikava DORA zahteva posebno pozornost. Nekateri presojevalci in ocenjevalci bodo pri pregledu upravljanja sprememb IKT uporabljali izrazje v slogu COBIT. COBIT BAI06 se običajno razume kot Managed IT Changes. Če so razširitve brskalnikov programska oprema in njihova namestitev spreminja uporabniško računalniško okolje, potem namestitev razširitev spada v isto upravljano logiko sprememb. Zenith Controls: The Cross-Compliance Guide podpira ta revizijski pogled s prikazom, kako se lahko dokazila kontrol ISO/IEC 27001 ponovno uporabijo za različne zahteve skladnosti.

90-dnevni načrt uvedbe upravljanja razširitev brskalnikov

Organizacijam ni treba rešiti vsega v enem tednu. Praktičen program je mogoče zgraditi po fazah, zlasti kadar je treba skrbno obvladovati motnje poslovanja.

Za visoko tvegane organizacije, zlasti finančne subjekte po DORA ali bistvene in pomembne subjekte po NIS2, mora prva faza uveljavljanja dati prednost uporabnikom z dostopom do kritičnih sistemov, reguliranih podatkov, privilegiranih administratorskih konzol, finančnih platform, orodij za podporo strankam in razvojnih okolij.

Sporočilo za upravni odbor

Upravljanja razširitev brskalnikov izvršnemu vodstvu ne smemo predstaviti kot projekta utrjevanja brskalnikov. Predstaviti ga je treba kot kontrolo nad nepreverjeno kodo tretjih oseb v reguliranih delovnih tokovih.

Upravni odbor in organ upravljanja morata razumeti štiri točke:

1. Brskalnik je danes ključna poslovna platforma.
2. Razširitve lahko dostopajo do občutljivih podatkov SaaS in avtenticiranih sej.
3. Neupravljane razširitve ustvarjajo tveganja dobaviteljev, zasebnosti, incidentov in odpornosti.
4. ISO/IEC 27001:2022 zagotavlja zagovorljiv kontrolni model, ki podpira dokazila za NIS2, DORA in GDPR.

Tak okvir razpravo premakne od tehnične preference k operativni odpornosti. Podpira tudi financiranje upravljanja brskalnikov na ravni podjetja, integracije s končnimi točkami, spremljanja, pregledov zasebnosti, triaže dobaviteljev in avtomatizacije revizijskih dokazil.

Od slepe pege do strateške kontrole

Marijina revizijska težava ni nastala zato, ker je en analitik namestil eno orodje za produktivnost. Nastala je zaradi neupravljanega razreda tveganja. Organizacija je zgradila močan program skladnosti okoli vidnih sredstev, vidnih dobaviteljev, vidnih platform SaaS in vidnih končnih točk, vendar je plast razširitev brskalnika ostala nevidna.

Ta vrzel je zdaj preveč pomembna, da bi jo ignorirali.

Rešitev ni zapletena, vendar mora biti namerna. Brskalnik obravnavajte kot del končne točke. Razširitve obravnavajte kot programsko opremo. Razvijalce razširitev in zaledja obravnavajte kot dobavitelje, kjer je to relevantno. Dovoljenja obravnavajte kot dostop do podatkov. Namestitev obravnavajte kot spremembo. Dnevnike obravnavajte kot dokazila o skladnosti.

Zagovorljiv program se začne s štirimi ukrepi:

1. Odkrijte vsako razširitev v upravljanih brskalnikih in na končnih točkah.
2. Določite sprejemljivo uporabo in pravila privzetega zavračanja z uporabo Endpoint Protection - Malware Policy - SME, P03 Acceptable Use Policy in podjetniške Acceptable Use Policy.
3. Zahteve za razširitve ocenjujte z merili za dobavitelje, oblak, ranljivosti in zasebnost iz Third party and supplier security policy in Application Security Requirements Policy - SME.
4. Uveljavite in spremljajte namestitvene dejavnosti z upravljanjem brskalnikov, beleženjem in praksami dokazovanja, usklajenimi z Logging and Monitoring Policy - SME.

Za vodje informacijske varnosti, ki se pripravljajo na presoje NIS2, DORA, GDPR ali ISO/IEC 27001:2022, je upravljanje razširitev brskalnikov izboljšava kontrole z visoko vrednostjo, ker zapira dejansko pot napada in hkrati ustvarja ponovno uporabna dokazila za več okvirov.

Za pospešitev dela prenesite Zenith Blueprint: An Auditor’s 30-Step Roadmap in preslikajte svoja dokazila z Zenith Controls: The Cross-Compliance Guide. Če želite kaos razširitev brskalnikov pretvoriti v program upravljanja, pripravljen na presojo, naročite presojo ali predstavitev Clarysec ter začnite s praktičnim popisom, zemljevidom tveganj in 90-dnevnim načrtom kontrol.