Upravljanje Microsoft Entra Conditional Access v letu 2026

V torek ob 09:12 Maria, direktorica informacijske varnosti (CISO) hitro rastočega evropskega fintech podjetja, odpre poročilo o pripravljenosti na DORA, ki bi moralo biti rutinsko. Njena nadzorna plošča Microsoft Entra Conditional Access je videti dobro. MFA je uveljavljen za skrbnike. Zastarela avtentikacija je blokirana. Visoko tvegane prijave se dodatno preverijo ali zavrnejo. Občutljive finančne aplikacije zahtevajo skladne naprave. Dostop iz brskalnikov na neupravljanih končnih točkah je omejen.
Nato prebere ugotovitev presojevalca.
»Vaša pravila Conditional Access so tehnično ustrezna, vendar delujejo v praznem prostoru. Pokažite nam politiko, odobreno na ravni upravnega odbora, ki zahteva te nastavitve. Pokažite nam zapis o spremembi za pravilo, spremenjeno prejšnji mesec. Pokažite nam, kako je bila politika za visoko tvegane prijave aktivna med domnevnim napadom credential stuffing. Pokažite nam, kako ta dokazila podpirajo ISO 27001, DORA, NIS2 in GDPR.«
Ekipa za identitete lahko izvozi konfiguracijo. SOC lahko prikaže dnevnike prijav. Vodja skladnosti lahko pokaže na mapo s politikami. Vendar nihče ne more pripraviti enotnega, upravljanega dokaznega sklopa, ki povezuje tveganje, politiko, odobritev, konfiguracijo, izjeme, spremljanje, odziv na incidente, obveznosti glede zasebnosti in pregled vodstva.
To je izziv upravljanja Conditional Access v letu 2026.
Microsoft Entra Conditional Access ni več zgolj nastavitev identitete. Je sistem kontrol na ravni upravnega odbora, ki določa, kdo lahko dostopa do storitev v oblaku, pod katerimi pogoji, iz katerih naprav, s katero avtentikacijsko močjo in s katerimi omejitvami sej. Za regulirane organizacije morajo biti te odločitve razložljive, zagovorljive in mapirane na obveznosti po ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST in COBIT 2019.
Conditional Access je zdaj preverljiv sistem kontrol
Conditional Access je na presečišču identitete, varnostnega stanja naprave, občutljivosti aplikacije, lokacije, tveganja prijave, uporabniškega tveganja, vedenja seje in beleženja. Posamezna politika lahko zahteva MFA, zahteva skladno napravo, blokira dostop s tvegane lokacije, omeji prenose iz neupravljanih brskalnikov ali zahteva ponovno avtentikacijo, ko se tveganje spremeni.
Zato je ena najmočnejših točk uveljavljanja ničelnega zaupanja v Microsoftovih okoljih v oblaku. Hkrati je tudi zelo primeren za revizijsko preverjanje.
Po ISO/IEC 27001:2022 kontrola ni zrela zgolj zato, ker obstaja v portalu. Organizacija mora razumeti svoj kontekst, oceniti tveganja informacijske varnosti, izbrati obravnave tveganj, dokumentirati izjavo o uporabnosti (SoA), izvajati kontrole, spremljati učinkovitost in jih sčasoma izboljševati. Relevantne klavzule vključujejo klavzulo 6.1.2 za oceno tveganj, klavzulo 6.1.3 za obravnavo tveganj, klavzulo 7.5 za dokumentirane informacije, klavzulo 8.1 za operativno načrtovanje in nadzor, klavzulo 9.1 za spremljanje ter klavzulo 9.3 za vodstveni pregled.
Priloga A, usklajena z ISO/IEC 27002:2022, vsebuje praktični jezik kontrol, ki ga bodo presojevalci prepoznali. Conditional Access običajno podpira:
- 5.15 nadzor dostopa
- 5.16 upravljanje identitet
- 5.17 avtentikacijske informacije
- 5.18 pravice dostopa
- 8.1 uporabniške končne točke
- 8.2 pravice privilegiranega dostopa
- 8.3 omejitev dostopa do informacij
- 8.5 varna avtentikacija
- 8.15 beleženje
- 8.16 dejavnosti spremljanja
Za organizacije, regulirane v EU, je upravljavsko breme še jasnejše. NIS2 Article 20 nalaga odgovornost organom upravljanja za odobritev in nadzor ukrepov za upravljanje tveganj kibernetske varnosti. NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z nadzorom dostopa, upravljanjem sredstev, kibernetsko higieno, obravnavanjem incidentov, varnostjo dobavne verige, oceno učinkovitosti ter večfaktorsko ali neprekinjeno avtentikacijo, kadar je to ustrezno. NIS2 Article 23 uvaja fazno poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom o incidentu v 72 urah in končnim poročilom v enem mesecu.
DORA za finančne subjekte določa podobna pričakovanja. Article 5 zahteva notranji okvir upravljanja in kontrol. Article 6 zahteva okvir upravljanja IKT-tveganj. Article 9 obravnava zaščito in preprečevanje, vključno z omejitvami dostopa in praksami upravljanja identitet. Articles 10, 11, 17, 18 in 19 povezujejo odkrivanje, odziv, obnovitev, upravljanje IKT-incidentov, razvrščanje in poročanje. Ker se DORA uporablja od 17. januarja 2025, morajo finančni subjekti Conditional Access obravnavati kot del dokazil o operativni odpornosti, ne le kot utrjevanje identitet.
GDPR dodaja vidik zasebnosti. Če Conditional Access ščiti sisteme, ki obdelujejo osebne podatke, podpira načela odgovornosti iz Article 5, odgovornost upravljavca iz Article 24, varstvo podatkov že pri načrtovanju iz Article 25 in varnost obdelave iz Article 32. Če obstaja sum nepooblaščenega dostopa, lahko dnevniki Conditional Access postanejo del ocene kršitve in dokazil za obveščanje.
Napaka je, če se ti elementi obravnavajo kot ločene revizijske zahteve. Zrel pristop je enoten model upravljanja Conditional Access, ki ga je mogoče predstaviti po okviru, regulatorju, stranki ali ciljni skupini upravnega odbora.
Konfiguracija ni upravljanje
Večina organizacij zna odgovoriti na vprašanje: »Kaj je konfigurirano?« Manj jih zna odgovoriti na težja vprašanja:
- Zakaj je ta politika Conditional Access konfigurirana na ta način?
- Kateri scenarij tveganja obravnava?
- Katera klavzula politike jo zahteva?
- Kdo je odobril spremembo?
- Kateri uporabniki, aplikacije in naprave so izvzeti?
- Kako se testira?
- Kateri dnevniki dokazujejo, da je delovala?
- Kako pogosto se pregleduje?
- Kaj se zgodi, ko odpove?
Tu se običajno pojavijo revizijske ugotovitve. Politike obstajajo, vendar niso povezane z nastavitvami Microsoft Entra. Skladnost naprav je v domeni IT-operacij, vendar ni mapirana na tveganje nadzora dostopa. Politike tveganja prijave so omogočene brez dokumentiranih pragov ali pravil eskalacije. Omejitve sej so konfigurirane, vendar se nikoli ne testirajo z neupravljanih naprav. Dnevniki se hranijo, vendar niso urejeni kot revizijska dokazila.
Clarysec to obravnava kot težavo sledljivosti. Vsaka odločitev Conditional Access mora povezati politiko, tveganje, kontrolo, konfiguracijo, dokazila in pregled.
Politika uporabe storitev v oblaku za MSP Politika uporabe storitev v oblaku za MSP določa:
Večfaktorska avtentikacija (MFA) za skrbniške in uporabniške račune
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.2.2.
Ta klavzula je zahteva. Pravilo Conditional Access je uveljavitev. Dnevnik prijav je dokazilo. Zapis o pregledu dokazuje nadzor.
Politika varnosti omrežja za MSP Politika varnosti omrežja za MSP dodaja zahtevo glede varnostnega stanja končne točke:
Sistemi brez posodobljene protivirusne programske opreme, popravkov ali sprejemljivega varnostnega stanja naprave morajo biti blokirani ali dani v karanteno
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.4.3.
V terminologiji Microsoft Entra se to lahko izrazi kot »zahtevaj skladno napravo«, »blokiraj nepodprte platforme«, »omeji neupravljane brskalniške seje« ali »zavrni dostop do visoko tveganih aplikacij z neznanih naprav«. Vendar kontrola ni popolna, dokler organizacija ne more dokazati obsega, odobritve, testiranja, izjem in spremljanja.
Najprej vzpostavite upravljavsko podlago, nato nabor pravil
Močan program Conditional Access se začne zunaj portala Entra. Začne se z ISMS, registrom tveganj, politiko nadzora dostopa, politiko uporabe storitev v oblaku, SoA in modelom dokazil.
Clarysecov Zenith Blueprint: 30-koračni časovni načrt presojevalca Zenith Blueprint podaja praktično zaporedje. V fazi upravljanja tveganj, korak 13, načrtovanje obravnave tveganj in izjava o uporabnosti, organizacijam naroča, naj kontrole povežejo s tveganji in regulativnimi gonili:
Navzkrižno sklicevanje na predpise: če so določene kontrole uvedene posebej zaradi skladnosti z GDPR, NIS2 ali DORA, lahko to navedete v registru tveganj kot del utemeljitve vpliva tveganja ali v opombah SoA.
Pri Conditional Access to spremeni dokazni sklop. Namesto izjave »Omogočili smo MFA« lahko organizacija pove:
- Scenarij tveganja: kompromitirane uporabniške poverilnice omogočajo nepooblaščen dostop do podatkov strank v Microsoft 365 in finančnem SaaS.
- Lastnik tveganja: vodja varnosti IT.
- Obravnava: Entra Conditional Access zahteva močan MFA za privilegirane vloge, MFA za uporabnike, blokiranje tveganja prijave, skladne naprave za občutljive aplikacije in omejitve sej za neupravljane končne točke.
- Mapiranje ISO/IEC 27002:2022: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 in 8.16.
- Regulativno mapiranje: NIS2 Articles 20, 21 in 23, DORA Articles 5, 6, 9, 10, 17 in 18, GDPR Articles 24, 25, 32 in 33.
- Dokazila: odobritev politike, izvoz Conditional Access, zahtevek za spremembo, rezultati testiranja, dnevniki prijav, poročila o skladnosti naprav, register izjem, zahtevki SOC in zapisniki vodstvenih pregledov.
Zenith Blueprint v fazi Kontrole v praksi, korak 19, pojasnjuje tudi, zakaj varnostno stanje končne točke spada v odločitev o dostopu:
Dostop do informacij prek končnih točk mora upoštevati kontekst. Ali naprava na primer izpolnjuje minimalne varnostne standarde pred dostopom do virov podjetja? Ali je pred kratkim uspešno prestala pregled zlonamerne programske opreme? Ali se povezuje z neobičajne lokacije ali omrežja? Z integracijo načel ničelnega zaupanja se lahko varnostno stanje končne točke vključi v pogojni dostop, ki zavrne vstop, dokler naprava ne dokaže, da je varna.
To je ključno načelo upravljanja. Conditional Access mora temeljiti na tveganjih, upoštevati kontekst in ustvarjati dokazila.
Mapirajte odločitve Conditional Access na cilje kontrol
Zrel program opredeli standardne odločitve o dostopu in nato vsako mapira na namen upravljanja in dokazila. To preprečuje razraščanje politik in poenostavi revizijske razprave.
| Odločitev Conditional Access | Namen upravljanja | Primarna dokazila | Vrednost za skladnost med okviri |
|---|---|---|---|
| Zahtevaj MFA za skrbnike | Preprečiti kompromitacijo privilegiranih računov | Izvoz politike CA, seznam vlog, dnevniki prijav, odobritve izjem | Podpira ISO/IEC 27002:2022 8.2 in 8.5, MFA po NIS2, omejitve dostopa po DORA in zaupnost po GDPR |
| Zahtevaj skladno napravo za občutljive aplikacije | Zmanjšati dostop z neupravljanih ali ranljivih končnih točk | Politika skladnosti Intune, politika CA Entra, poročila o skladnosti naprav | Podpira 8.1 uporabniške končne točke, kibernetsko higieno, zaščito pri IKT-tveganjih in varovala zasebnosti |
| Blokiraj visoko tveganje prijave | Preprečiti verjetno zlorabo poverilnic | Konfiguracija politike tveganja, dnevniki tveganih dogodkov, zahtevki triaže SOC | Podpira 8.16 dejavnosti spremljanja, odkrivanje incidentov, pripravljenost na poročanje po NIS2 in razvrščanje incidentov po DORA |
| Omeji neupravljane brskalniške seje | Omejiti uhajanje podatkov iz neskladnih naprav | Politika sej, dnevniki kontrol aplikacij, dokazila o testiranju | Podpira 8.3 omejitev dostopa do informacij, kontrole v oblaku, delo na daljavo in varstvo osebnih podatkov |
| Zahtevaj odobrene odjemalske aplikacije ali zaščito aplikacij | Zaščititi mobilni dostop in dostop BYOD | Politika zaščite mobilnih aplikacij, nastavitve odobritev CA, dnevniki mobilnega dostopa | Podpira upravljanje končnih točk, kontrole BYOD in omejitve dostopa do aplikacij |
| Blokiraj zastarelo avtentikacijo | Odstraniti šibke poti avtentikacije | Poročila o avtentikacijskih protokolih, politika CA, rezultati testiranja | Podpira 8.5 varno avtentikacijo in zmanjšanje napadalne površine |
| Zahtevaj ponovno avtentikacijo za tvegane seje | Zmanjšati vztrajnost dostopa po spremembah tveganja | Nastavitve nadzora sej, dokazila o pogostosti prijav, dnevniki tveganih dogodkov | Podpira upravljanje sej, zajezitev incidentov in odgovornost glede zasebnosti |
Politika uporabe storitev v oblaku za podjetja Politika uporabe storitev v oblaku podpira centralno integracijo identitet:
Integracija enotne prijave (SSO) z IdP organizacije je zahtevana za zagotovitev doslednosti avtentikacije.
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.2.4.
Politika upravljanja uporabniških računov in privilegijev za podjetja Politika upravljanja uporabniških računov in privilegijev izrecno zahteva spremljanje:
Uporaba sistemov enotne prijave (SSO) mora biti integrirana s centralnimi ponudniki identitet (npr. Active Directory (AD), Azure AD) in spremljana za anomalno vedenje pri prijavah.
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.4.
Skupaj ti klavzuli zahtevata več kot SSO. Zahtevata centralno arhitekturo identitet, dosledno avtentikacijo, spremljanje anomalnega vedenja pri prijavah in dokazila, da se odločitve o dostopu pregledujejo.
Skladnost naprav: kontrola, ki jo presojevalci lahko testirajo
Skladnost naprav je eno od področij, kjer je zrelost najlažje preceniti. Nadzorna plošča lahko prikazuje 92 odstotkov skladnih naprav, vendar bo presojevalec vprašal, ali pravilo velja za aplikacije, ki so pomembne, ali so osebne naprave dovoljene, ali so nepodprte platforme blokirane in ali so izjeme odobrene.
Politika dela na daljavo za podjetja Politika dela na daljavo določa osnovo za odobritev:
Naprave BYOD morajo biti izrecno odobrene in:
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.2.2.
Ta kratka poved je pomembna. BYOD ni samo tehnično stanje. Je upravljavska odločitev. V Conditional Access se mora prevesti v pravila lastništva naprav, minimalne izhodiščne zahteve skladnosti, zahteve za šifriranje, preverjanja popravkov in zaščite pred zlonamerno programsko opremo, zaščito mobilnih aplikacij, obravnavo pogodbenih izvajalcev in pregled izjem.
Clarysecov Zenith Controls: vodnik za skladnost med okviri Zenith Controls mapira kontrolo ISO/IEC 27002:2022 5.15 nadzor dostopa kot preventivno kontrolo, ki varuje zaupnost, celovitost in razpoložljivost v operativni zmogljivosti upravljanja identitet in dostopa. Nadzor dostopa povezuje tudi z uporabniškimi končnimi točkami, ker lahko neupravljani prenosniki, mobilne naprave in namizni računalniki oslabijo centralizirano uveljavljanje dostopa.
Praktični četrtletni paket dokazil o napravah za Conditional Access mora vključevati:
- Odobreno izhodiščno zahtevo za skladnost naprav.
- Politike Conditional Access, ki zahtevajo skladne naprave.
- Aplikacije, zaščitene s temi politikami.
- Izvoz izvzetih uporabnikov, skupin, aplikacij in platform.
- Poročilo o trendih neskladnih naprav.
- Vzorčne dnevnike blokiranih prijav za neskladne naprave.
- Register izjem z lastnikom, razlogom, datumom poteka in sprejemom tveganja.
- Zapis vodstvenega pregleda.
Ta paket dokazil podpira operativni nadzor po ISO/IEC 27001:2022, kibernetsko higieno po NIS2, zaščito in preprečevanje po DORA ter odgovornost po GDPR.
Tveganje prijave: odkrivanje mora postati dokazilo o odločitvi
Conditional Access na podlagi tveganja je točka, kjer odkrivanje na ravni identitete postane upravljanje dostopa. Microsoft Entra lahko ocenjuje signale, kot so neznane lastnosti prijave, anonimni naslovi IP, nemogoče potovanje in razkrite poverilnice. Vendar presojevalci odgovora »politika tveganja je omogočena« ne bodo sprejeli kot zadostnega. Vprašali bodo, zakaj so bili izbrani pragovi, kdo pregleduje tvegane dogodke in kdaj visoko tvegana prijava postane incident.
Politika beleženja in spremljanja za MSP Politika beleženja in spremljanja za MSP določa minimalno zahtevo glede beleženja:
Dnevniki avtentikacije: uspešni in neuspešni poskusi prijave, trajanje seje, uporaba MFA
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.4.2.
Politika beleženja in spremljanja za podjetja Politika beleženja in spremljanja razširja pričakovani nabor dogodkov:
Vrste dogodkov, ki jih je treba zajeti (npr. prijave, neuspešni dostopi, konfiguracijske spremembe, skrbniški ukazi, zaznava zlonamerne programske opreme)
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.1.1.
Za Conditional Access morajo uporabna dokazila vključevati uspešne prijave, neuspešne prijave, rezultat politike Conditional Access, metodo MFA, tveganje prijave, uporabniško tveganje, stanje skladnosti naprave, dostopano aplikacijo, lokacijo, odjemalsko aplikacijo, rezultat kontrole seje, zgodovino sprememb politik in skrbniška dejanja.
Zenith Controls mapira kontrolo ISO/IEC 27002:2022 8.16 dejavnosti spremljanja kot odkrivalno in korektivno kontrolo, povezano s konceptoma zaznavanja in odzivanja. Spremljanje povezuje z beleženjem, ocenjevanjem dogodkov, obveščevalnimi podatki o grožnjah, spremljanjem dobaviteljev in upravljanjem incidentov. Dejavnosti spremljanja mapira tudi na GDPR Articles 32 in 33, spremljanje in poročanje o incidentih po NIS2, sledenje IKT-incidentom po DORA, neprekinjeno spremljanje po NIST in varnostno spremljanje po COBIT.
Visoko tvegana prijava, ki jo blokira Conditional Access, zato ni le varnostni uspeh. Je dokazilo, da so preventivni, odkrivalni in odzivni procesi povezani.
Kontrole sej: povezava med dostopom in varstvom podatkov
Odločitve pred dostopom niso dovolj. Ko je uporabnik avtenticiran, kontrole sej določajo, koliko izpostavljenosti ostane. To je posebej pomembno za neupravljane naprave, pogodbene izvajalce, delo na daljavo, deljene terminale, tvegane lokacije in aplikacije, ki obdelujejo osebne podatke.
Politika zahtev za varnost aplikacij za MSP Politika zahtev za varnost aplikacij za MSP določa:
Upravljanje sej: podatki seje morajo poteči po 15 minutah nedejavnosti in vključevati opozorila o poteku, kadar je to primerno.
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.3.
V upravljanju Microsoft Entra se to lahko mapira na pogostost prijave, omejitve trajnih brskalniških sej, Conditional Access App Control, omejitve, ki jih uveljavlja aplikacija, blokiranje prenosov, ponovno avtentikacijo po spremembah tveganja in omejitve sej na podlagi občutljivosti.
Kontrole sej podpirajo kontrolo ISO/IEC 27002:2022 8.3 omejitev dostopa do informacij in 8.5 varna avtentikacija. Podpirajo tudi GDPR Article 32, ker zmanjšujejo nepooblaščen ogled, prenos ali vztrajnost dostopa do osebnih podatkov. Pri DORA omejitve sej pomagajo omejevati izpostavljenost v sistemih IKT ter podpirajo odkrivanje in odziv. Pri NIS2 so sorazmerni ukrepi nadzora dostopa in kibernetske higiene.
Dokazila morajo pojasniti, zakaj kontrola seje obstaja. Na primer, »blokiraj prenos iz neupravljanih naprav za kadrovske in finančne aplikacije« se mora mapirati na uhajanje osebnih podatkov, kompromitacijo končne točke in izgubo zaupnosti. Dokazila morajo vključevati konfiguracijo, obseg aplikacij, testne prijave z upravljanih in neupravljanih naprav, dnevnike, ki prikazujejo omejitve, ter zapise odobritev.
Ustvarite register kontrol Conditional Access
Register kontrol Conditional Access je operativni most med registrom tveganj, izjavo o uporabnosti in konfiguracijo Microsoft Entra. Teh dokumentov ne nadomešča. Omogoča njihovo praktično uporabo.
| Polje registra | Primer vnosa |
|---|---|
| Scenarij tveganja | Kompromitirane poverilnice, uporabljene za dostop do finančnega SaaS z neupravljane naprave |
| Politika Conditional Access | CA-High-Risk-Finance-Require-MFA-Compliant-Device |
| Namen kontrole | Zahtevati MFA, zahtevati skladno napravo, blokirati visoko tveganje prijave in omejiti neupravljane seje |
| Viri dokazil | Izvoz CA, dnevniki prijav, poročilo o skladnosti naprav, register izjem in zahtevek opozorila SOC |
| Mapiranje skladnosti | ISO/IEC 27002:2022 5.15, 8.1, 8.3, 8.5, 8.15 in 8.16, NIS2 Article 21, DORA Articles 6 in 9, GDPR Article 32 |
Uporabite petstopenjski cikel pregleda:
- Potrdite obseg: identificirajte aplikacije v oblaku, ki obdelujejo regulirane, finančne, operativne ali osebne podatke.
- Mapirajte politike na tveganja: vsako politiko Conditional Access povežite z vsaj enim scenarijem tveganja in enim lastnikom tveganja.
- Preverite izključitve: izvozite izvzete uporabnike, vloge, aplikacije, skupine, lokacije in naprave. Vsaka izključitev mora imeti lastnika, razlog, odobritev in datum poteka.
- Testirajte uveljavljanje: s testnimi računi preverite MFA, skladnost naprav, blokiranje tveganja, blokiranje zastarele avtentikacije in omejitve sej.
- Pripravite paket dokazil: shranite izvoze, posnetke zaslona, dnevnike in odobritve z metapodatki.
Politika spremljanja presoje in skladnosti za MSP Politika spremljanja presoje in skladnosti za MSP je ključna za celovitost dokazil:
Metapodatki (npr. kdo jih je zbral, kdaj in iz katerega sistema) morajo biti dokumentirani.
Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.2.3.
Posnetki zaslona brez vira, datuma, osebe, ki jih je zbrala, in sistemskega konteksta so šibka dokazila. Izvozi Conditional Access, dnevniki prijav in poročila o pregledih se morajo obravnavati kot nadzorovani revizijski zapisi.
Mapiranje dokazil Conditional Access za skladnost med okviri
Vrednost Conditional Access je v tem, da lahko en nabor kontrol ob ustreznem upravljanju zadosti več revizijskim pogledom.
| Funkcionalnost Conditional Access | Primarna kontrola ISO/IEC 27002:2022 | Povezava NIS2 | Povezava DORA | Povezava GDPR | Dokazila za predložitev |
|---|---|---|---|---|---|
| MFA za skrbnike | 8.2 pravice privilegiranega dostopa in 8.5 varna avtentikacija | Article 21 nadzor dostopa in MFA | Articles 5, 6 in 9 upravljanje in zaščita | Article 32 varnost obdelave | Politika dostopa, konfiguracija CA, seznam privilegiranih vlog, dnevniki prijav, ki prikazujejo MFA |
| Blokiranje neupravljanih naprav | 8.1 uporabniške končne točke in 5.15 nadzor dostopa | Article 21 kibernetska higiena in upravljanje sredstev | Article 9 zaščita in preprečevanje | Articles 25 in 32 varstvo zasebnosti že pri načrtovanju in varnost | Politika dela na daljavo, politika skladnosti naprav, konfiguracija CA, dnevniki blokiranih prijav |
| Blokiranje visoko tveganih prijav | 8.16 dejavnosti spremljanja in 8.5 varna avtentikacija | Articles 21 in 23 spremljanje in pripravljenost na incidente | Articles 10, 17 in 18 odkrivanje in razvrščanje incidentov | Articles 32 in 33 varnost in dokazila o kršitvi | Politika beleženja, konfiguracija tveganj, dnevniki Identity Protection, zahtevki SOC |
| Omejevanje neupravljanih sej | 8.3 omejitev dostopa do informacij | Article 21 nadzor dostopa in kibernetska higiena | Article 9 omejitve dostopa | Article 32 zaupnost in celovitost | Politika sej, dokazila CA App Control, rezultati testiranja upravljanih in neupravljanih naprav |
| Blokiranje zastarele avtentikacije | 8.5 varna avtentikacija | Article 21 nadzor dostopa | Article 9 zaščita in preprečevanje | Article 32 varnost obdelave | Poročilo o protokolih, politika CA, rezultati testiranja, zapis o spremembi |
| Četrtletni pregled izključitev | 5.18 pravice dostopa | Article 20 nadzor in Article 21 ocena učinkovitosti | Article 5 odgovornost vodstva | Article 24 odgovornost | Register izjem, odobritve, datumi poteka, zapisniki vodstvenih pregledov |
Zenith Controls mapira tudi 5.15 nadzor dostopa na GDPR Article 32, NIS2 Article 21(2)(i), koncepte upravljanja dostopa po DORA, družine nadzora dostopa NIST SP 800-53 in COBIT 2019 DSS06.04. Kontrolo 8.5 varna avtentikacija mapira na GDPR Articles 5, 24, 25 in 32, upravljanje tveganj kibernetske varnosti po NIS2, upravljanje IKT-tveganj po DORA, identifikacijo in avtentikacijo po NIST ter identiteto in logični dostop po COBIT.
Sporočilo je preprosto. Okviri uporabljajo različen jezik, vendar pričakujejo isti vzorec zagotovila: pravi uporabniki, iz sprejemljivih kontekstov, z uporabo močne avtentikacije, prek upravljanih sej, z dnevniki, ki dokazujejo, kaj se je zgodilo.
Kako bodo presojevalci pregledovali Conditional Access
Presojevalec ISO/IEC 27001:2022 bo začel pri ISMS. Vprašal bo, ali je Conditional Access v obsegu, katera tveganja obravnava, kako je prikazan v SoA, kako so politike odobrene, kako so spremembe nadzorovane in ali dokazila potrjujejo operativno učinkovitost. Pričakujte vzorčenje privilegiranih uporabnikov, občutljivih aplikacij, izključitev in nedavnih sprememb politik.
Presojevalec za DORA ali NIS2 se bo osredotočil na operativno odpornost, odgovornost vodstva in tveganje. Lahko vpraša, kako kontrole dostopa ščitijo kritične ali pomembne funkcije, kako upravni odbor nadzira tveganje identitet, kako se triažirajo visoko tvegane prijave in ali neuspešni dostopi vplivajo na razvrščanje incidentov ali odločitve o poročanju.
Presojevalca, osredotočenega na GDPR, bodo zanimali osebni podatki. Lahko vpraša, kako so kadrovski, finančni ali podatki strank zaščiteni pred neupravljanimi napravami, kako kontrole sej zmanjšujejo nepooblaščen ogled, kako je dostop omejen na pooblaščene uporabnike in kako dnevniki podpirajo oceno kršitve.
Pregledovalec COBIT 2019 bo iskal prakse upravljanja, lastništvo, kazalnike, ponovljivost, spremljanje uspešnosti in izboljšave. Ocenjevalec, usmerjen v NIST, bo primerjal rezultate na področju identitete, avtentikacije, avtorizacije, spremljanja in odziva s tehničnimi dokazili.
Politika nadzora dostopa za podjetja Politika nadzora dostopa določa ton za privilegirani dostop:
Skrbniški dostop mora biti strogo nadzorovan prek:
Iz razdelka »Zahteve upravljanja«, klavzula politike 5.4.1.
Vaša dokazila Microsoft Entra morajo operativno dokončati ta stavek. Katere vloge so privilegirane? Katere zahtevajo MFA, odporen proti lažnemu predstavljanju, ali močan MFA? Katere so upravičene prek upravljanja privilegiranih identitet? Kateri računi so »break-glass«? Kateri so izvzeti iz politik? Kdo jih pregleduje? Kam se pošiljajo opozorila?
Kazalniki za upravni odbor pri upravljanju Conditional Access
Ker NIS2 in DORA poudarjata odgovornost vodstva, mora biti poročanje o Conditional Access razumljivo upravnemu odboru. Ne poročajte samo imen politik. Poročajte o profilu tveganja in uspešnosti kontrol.
Uporabni kazalniki vključujejo:
- Delež privilegiranih računov, zaščitenih z močnim MFA.
- Število izključitev Conditional Access po ravni tveganja.
- Število blokiranih, dodatno preverjenih ali dovoljenih visoko tveganih prijav.
- Delež dostopov do občutljivih aplikacij, ki zahtevajo skladne naprave.
- Število sej z neupravljanih naprav do reguliranih aplikacij.
- Čas do triaže visoko tveganih dogodkov prijave.
- Število sprememb politik Conditional Access v četrtletju.
- Število poteklih, obnovljenih in zapadlih izjem.
- Pokritost beleženja avtentikacije, sej in sprememb politik.
- Neuspešni testni primeri iz četrtletne validacije Conditional Access.
Ti kazalniki pretvorijo konfiguracijo identitet v dokazila o nadzoru. Organom upravljanja pomagajo tudi dokazati odobritev, pregled, zagotavljanje virov in nenehno izboljševanje.
Pogoste ugotovitve, ki jih je treba odpraviti pred revizijo
Ugotovitve glede Conditional Access običajno izvirajo iz šibkega upravljanja, ne iz tehnološke odpovedi. Najpogostejše težave vključujejo:
- Računi »break-glass« so izvzeti, vendar se ne spremljajo.
- Politike so poimenovane nedosledno in nimajo lastnikov.
- Občutljive aplikacije manjkajo v pravilih skladnosti naprav.
- Gostujoči uporabniki in zunanji sodelavci obidejo standardne kontrole.
- Storitveni računi in identitete delovnih obremenitev niso upravljani ločeno.
- Zaznave tveganja prijave niso triažirane ali povezane z incidenti.
- Kontrole sej se nikoli ne testirajo z neupravljanih naprav.
- Spremembe politik se izvajajo neposredno v produkcijsko okolje brez zapisov o spremembah.
- Izključitve so trajne, nedokumentirane ali ustno odobrene.
- Dnevniki se hranijo, vendar se ne pregledujejo.
- Dokazila nimajo metapodatkov, konteksta vira ali verige skrbništva.
Ciljno stanje, pripravljeno za leto 2026, vključuje vodstveno odobreno upravljanje dostopa, zasnovo Conditional Access na podlagi tveganj, izrecno mapiranje na ISO/IEC 27001:2022 in ISO/IEC 27002:2022, dokumentirano podporo NIS2, DORA in GDPR, močan MFA po vlogi in tveganju, skladnost naprav za občutljiv dostop, omejitve sej za neupravljane kontekste, spremljane spremembe avtentikacije in politik, življenjski cikel izjem, četrtletno testiranje in poročanje vodstvu.
Pretvorite Microsoft Entra v dokazila, pripravljena na revizijo
Vaše politike Conditional Access že vsako minuto sprejemajo varnostne odločitve. Vprašanje je, ali so te odločitve upravljane, utemeljene na tveganjih, spremljane in mapirane na obveznosti, ki zanimajo vaše presojevalce in regulatorje.
Začnite z Zenith Blueprint Zenith Blueprint, zlasti s korakom 13, da povežete politike Conditional Access s tveganji, obravnavami, izjavo o uporabnosti in regulativnimi opombami. Uporabite Zenith Controls Zenith Controls za mapiranje nadzora dostopa, varne avtentikacije, varnostnega stanja končnih točk, beleženja in spremljanja prek ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST in COBIT 2019.
Nato uskladite svoje notranje zahteve s politikami Clarysec, vključno z Politiko uporabe storitev v oblaku za MSP, Politiko varnosti omrežja za MSP, Politiko beleženja in spremljanja za MSP, Politiko spremljanja presoje in skladnosti za MSP, Politiko zahtev za varnost aplikacij za MSP, Politiko uporabe storitev v oblaku, Politiko upravljanja uporabniških računov in privilegijev, Politiko dela na daljavo, Politiko nadzora dostopa in Politiko beleženja in spremljanja.
Clarysec vam pomaga pretvoriti Microsoft Entra Conditional Access iz zbirke nastavitev v uveljavljiv, merljiv in na revizijo pripravljen sistem kontrol. Prenesite ustrezne zbirke orodij Clarysec, zahtevajte pregled mapiranja politik ali rezervirajte oceno, da preverite, ali vaša dokazila Conditional Access zdržijo presojo po ISO 27001, NIS2, DORA in GDPR.
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


