Implementeer compliance-aware cloud governance door de Microsoft 365-tenantbaseline te handhaven en elke noodzakelijke uitzondering centraal te beheren: begrens de scope tot het concrete compatibiliteitsprobleem, voeg een gerichte technische compensatie toe, leg herstel en restrisico vast en laat de uitzondering technisch vervallen na beoordeling. Verlaag beveiliging niet tenant-breed om lokale workflowproblemen op te lossen.
Kernpunten van dit artikel
Tijdelijke uitzonderingen zijn alleen beheersbaar wanneer de organisatie zelf eigenaar blijft van de tenantconfiguratie, de aanleiding en het herstelwerk.
- Beoordeel uitzonderingen op hun duur én reikwijdte: zonder technische afloop of met een globale uitsluiting verandert tijdelijke compatibiliteit in een blijvend beveiligingsgat.
- Houd compatibiliteitsgevallen, break-glass accounts en niet-persoonsgebonden accounts afzonderlijk, omdat hun toegangsmodel, risico en benodigde beheersing verschillen.
- Beperk een afwijking tot de specifieke toegangssituatie en compenseer precies de controle die daardoor wegvalt; behoud de algemene tenantbaseline.
- Weeg kortetermijncontinuïteit af tegen oplopend risico: statische legacy-uitzonderingen kunnen goedkoper lijken dan structurele modernisering, maar houden het risico in stand.
- Maak afwijkingen centraal aantoonbaar met de geldende baseline, actieve compensaties, risicobeoordeling en hersteltermijnen, zodat lokale flexibiliteit geen onzichtbare tenant-brede praktijk wordt.
Een tijdelijke uitzondering blijft bij de organisatie, niet bij de SaaS-leverancier
Microsoft 365-governance zonder permanente bypasses begint bij een heldere verantwoordelijkheidsgrens: standaard cloudfunctionaliteit neemt de verantwoordelijkheid voor de tenant niet over. De organisatie die de dienst afneemt, houdt zelf de regie over tenant-configuratie, het beheer van uitzonderingen en de onderbouwing daarvan. Dat geldt ook wanneer een beschikbare beveiligingsfunctie in de cloud aansluit op een bekend normenkader. De aanwezigheid van zo'n functie bewijst niet dat de gekozen configuratie, de reikwijdte van een uitsluiting of de vastlegging van een afwijking passend is. De feitelijke toestand van de tenant blijft daarom het bestuurlijke object.
Een tijdelijke uitzondering hoort niet alleen een administratieve einddatum te hebben. Wanneer een uitsluitingsgroep technisch statisch blijft bestaan, is de kans groot dat de afwijking na het beoogde herstelmoment nog steeds actief is. Periodieke Entra ID Access Reviews en geautomatiseerde vervaldata geven de uitzondering een levenscyclus die de configuratie zelf kan afdwingen. Zodra een herstelmijlpaal verloopt, kan de statische uitsluitingsgroep worden opgeschoond. Daarmee verschuift de vraag van: “herinnert iemand zich deze uitzondering nog?” naar: “is de herstelmijlpaal bereikt en vervalt de uitsluiting daardoor?” Die verschuiving maakt het onderscheid zichtbaar tussen een tijdelijke maatregel en een blijvende permissie.
De review heeft daarbij een andere functie dan alleen het nalopen van ledenlijsten. Zij brengt opnieuw aan het licht waarom een account buiten een interactieve controle valt en of die reden nog bestaat. Een geautomatiseerde vervaldatum voorkomt vervolgens dat het ontbreken van een handmatige opvolging de afwijking stilzwijgend verlengt. Juist de combinatie van beoordeling en technisch verval beperkt de ruimte waarin uitsluitingen kunnen verouderen terwijl de oorspronkelijke aanleiding allang verdwenen is.
Niet-persoonsgebonden accounts vragen om een afzonderlijke beoordeling. Een account dat van interactieve controles is uitgesloten zonder overgang naar service principals of certificaat-authenticatie, en zonder continue log-monitoring in SIEM/MDR, is geen gewone gebruikersuitzondering. De oorzaak, het toegangsmodel en de benodigde beheersing verschillen. Door zulke accounts in dezelfde uitzonderingsgroep te plaatsen als tijdelijke compatibiliteitsgevallen ontstaat een onduidelijke verzameling met uiteenlopende risico's en herstelpaden. De organisatie houdt die afwijking dus expliciet in eigen beheer, met een eigen grond voor de uitsluiting en zicht op de resterende controle.
Bronnen bij deze sectie: nist.gov, cisa.gov, cisecurity.org, cloudsecurityalliance.org
Wanneer een snelle bypass de tenant-baseline gaat vervangen
Een tijdelijke bypass wordt meestal niet permanent doordat iemand dat doelbewust besluit. Het patroon begint vaker met een operationeel incident waarin de druk om werk snel te herstellen zwaarder weegt dan de tijd om een begrensde afwijking formeel te behandelen. Een ongeplande, globale uitrol van Conditional Access met MFA kan legacy LOB-applicaties en scanservers direct raken. Als die uitval leidt tot een stroom P1-incidenten, raakt de helpdesk overbelast en ontstaat er druk op beheerders om de toegang onmiddellijk weer mogelijk te maken. Een statische CA-Bypass-Group zonder vervaldatum is dan een snelle uitweg, maar geen tijdelijke regeling met een aantoonbaar einde.
Vanaf dat moment verandert het risico van technisch naar organisatorisch. De groep blijft bestaan omdat de oorspronkelijke herstelactie niet is gekoppeld aan een technische afloop. Daardoor kan een uitzondering die onder incidentdruk is ontstaan jarenlang actief blijven zonder dat nog duidelijk is welke applicatie of welk werkproces de uitsluiting rechtvaardigt. De tenant-baseline is formeel wellicht niet gewijzigd, maar de effectieve bescherming wordt wel uitgehold voor ieder account dat in de groep blijft staan.
Een tweede escalatiepad ontstaat wanneer een ad-hoc bypass voor één gebruiker wordt toegestaan zonder risico-registratie. Collega's of andere afdelingen kunnen vervolgens informeel aan dezelfde groep worden toegevoegd, omdat de groep zichtbaar is als bestaande oplossing voor een vergelijkbaar probleem. Zo wordt een individuele uitzondering geleidelijk een gedeelde werkwijze. Wanneer de groep uitgroeit tot tientallen accounts, waaronder bevoorrechte rollen, is er geen sprake meer van een afgebakende compatibiliteitsmaatregel. Een gecompromitteerd legacy account kan dan tot tenant-brede overname leiden.
Naast deze groei binnen een uitsluitingsgroep bestaat een directer patroon: tenant-brede versoepeling onder druk van senior management. IT kan beveiligingsinstellingen verlagen om escalaties te vermijden, zonder formeel besluitvormings- en risico-acceptatietraject. Dat lijkt een oplossing voor de onmiddellijke verstoring, maar verplaatst een lokale compatibiliteitsvraag naar de hele tenant. De kern van governance ligt daarom niet in het ontkennen van uitval of werkdruk, maar in het voorkomen dat die druk een informele route opent die de formele besluitvorming passeert.
Bronnen bij deze sectie: nist.gov
Een uitzondering wordt gevaarlijk door onbeperkte duur of te brede scope
Een tijdelijke Microsoft 365-uitzondering wordt structureel risicovol door twee afzonderlijke eigenschappen: een onbeperkte duur en een te brede scope. De eerste eigenschap is zichtbaar bij een configuratieafwijking die voor een tijdelijke upgradeperiode wordt goedgekeurd, maar geen technische TTL heeft. De toestemming mag dan op papier tijdelijk zijn, terwijl het account in de feitelijke configuratie permanent buiten security controls blijft. De oorspronkelijke herstelperiode verstrijkt, maar niets in de technische inrichting dwingt het herstel af. Daardoor verandert een tijdelijke uitzondering in een permanente uitsluiting zonder dat daarvoor opnieuw een besluit is genomen.
De tweede eigenschap betreft de omvang van wat wordt uitgezonderd. Een beheerder kan een compatibiliteitsprobleem begrenzen op basis van IP-bereiken of client apps. Dat is iets anders dan gebruikers globaal uitsluiten van alle MFA- en device-compliance-regels. Bij zo'n Global Scope Bypass wordt niet alleen de specifieke oorzaak van het probleem geraakt; de uitsluiting strekt zich uit tot alle betrokken controles. De uitzondering is dan niet langer proportioneel aan de applicatie of het toegangspad dat aanleiding gaf tot het verzoek.
Beide patronen versterken elkaar. Een globaal ingestelde uitsluiting zonder technische TTL blijft niet alleen bestaan, maar blijft ook breed werken. Daardoor vervaagt het verschil tussen de normale tenant-baseline en de afwijkende toegangssituatie. Een beperkte uitzondering kan nog worden beoordeeld als een concrete configuratiekeuze voor een specifiek bereik of specifieke client app. Een permanente, globale uitsluiting maakt die beoordeling veel lastiger, omdat de effecten niet zijn teruggebracht tot de oorspronkelijke compatibiliteitsbehoefte.
Onbeheerde uitzonderingen in MFA en Conditional Access vergroten het aanvalsoppervlak voor toegang tot Exchange Online en SharePoint aanzienlijk. Via credential stuffing of token-replay kunnen aanvallers dan ongehinderd toegang krijgen. Dit gevolg hangt niet uitsluitend samen met het feit dat er een uitzondering is; het hangt samen met een uitzondering die niet meer bestuurbaar is in tijd en reikwijdte. Een geldige definitie van tijdelijk omvat daarom meer dan een tijdelijke bedoeling. Zij omvat een technische afloop, een duidelijk begrensde toepassingssituatie en een configuratie die niet verder reikt dan nodig is voor het betreffende compatibiliteitsconflict.
Bronnen bij deze sectie: cisa.gov, cisa.gov, cisecurity.org, cloudsecurityalliance.org
Toets afwijkingen aan de baseline, herstelkeuze en aantoonbaarheid
Een uitzondering kan langs drie verschillende beoordelingspunten worden geplaatst. De eerste bepaalt wat de geldende beveiligingsgrens is, de tweede maakt de kosten- en risicokeuze rond herstel zichtbaar, en de derde legt vast hoe de feitelijke tenantconfiguratie aantoonbaar blijft. Deze punten voorkomen dat een tijdelijke legacy-oplossing alleen wordt beoordeeld op de directe uitvoerbaarheid.
| Beoordelingspunt | Wat wordt beoordeeld | Betekenis voor de uitzondering |
|---|---|---|
| Baseline voor identiteit | De CIS Microsoft 365 Foundations Benchmark stelt dat legacy-authenticatie volledig wordt uitgeschakeld en MFA voor alle accounts geldt. De beperkte uitzondering betreft maximaal twee break-glass accounts onder continue SIEM-monitoring. | Break-glass accounts zijn een specifiek, begrensd geval binnen de baseline en mogen niet worden gelijkgesteld aan compatibiliteitsbypasses. Een legacy-uitzondering krijgt daardoor geen legitimiteit enkel omdat er ook een beperkte break-glass-uitzondering bestaat. |
| Herstelkeuze | Het behouden van legacy protocollen via statische uitzonderingen is op korte termijn goedkoper dan Graph API-migraties. Daartegenover staat een cumulatief veiligheidsrisico dat hoger is dan bij structurele modernisering. | De directe kostenbesparing is geen volledige afweging. De uitzondering vertegenwoordigt ook oplopend veiligheidsrisico zolang legacy protocollen via een statische uitsluiting in stand blijven. De keuze maakt dus zichtbaar of geld wordt besteed aan tijdelijke voortzetting of aan structureel herstel. |
| Aantoonbaarheid | Audit-ready tenantrapportages kunnen configuraties en afwijkingen koppelen aan CIS Benchmarks, NIST SP 800-53 en NIS2, met continue monitoring. | De rapportage verbindt de technische configuratie aan de gekozen normenkaders. Zij maakt afwijkingen zichtbaar naast de baseline, zonder te suggereren dat deze koppeling op zichzelf certificering of een geslaagde audit oplevert. |
Bronnen bij deze sectie: cisecurity.org
Beperk het beveiligingsgat binnen de uitzondering, niet in de hele tenant
Bij een compatibiliteitsconflict ligt de operationele volgorde in het begrenzen van de afwijking zelf. De uitgangspositie blijft de tenant-baseline; de uitzondering krijgt een technische compensatie die aansluit op het concrete beveiligingsgat. Daarmee wordt een lokaal probleem niet vertaald naar een algemene versoepeling voor alle gebruikers.
- Benoem het ontstane beveiligingsgat. Een uitzondering haalt een bestaande controle voor een bepaalde toegangssituatie weg. De eerste stap is daarom niet het aanpassen van de hele tenant, maar het expliciet maken welke bescherming door de uitzondering niet meer werkt. Alleen dan kan worden vastgesteld welke compensatie de afwijking rechtstreeks moet opvangen. Deze begrenzing houdt de aanleiding van de uitzondering verbonden met de feitelijke beveiligingsconsequentie.
- Koppel een gerichte technische compensatie aan die afwijking. Trusted IP-binding en web-only restricties zijn voorbeelden van technische compensatie. Zij zijn bedoeld om het gecreëerde beveiligingsgat direct te mitigeren en laterale dreigingen in te dammen. De compensatie staat dus niet los van de uitzondering: zij vormt de technische tegenhanger ervan. Dit maakt de tijdelijke toegang niet gelijk aan normale toegang, maar een afzonderlijke, beperkter beheerde situatie.
- Handhaaf de algemene tenant-baseline. Authenticatiepop-ups kunnen druk veroorzaken om algemene beveiligingsinstellingen te verlagen. Wanneer IT die druk volgt in plaats van een formele risico-acceptatie toe te passen, ontstaat een ander probleem dan een afzonderlijke compatibiliteitsuitzondering. De volledige tenant wordt dan aangepast aan de frictie die een specifieke gebruiker of situatie ervaart. Dat vergroot de afwijking van de oorspronkelijke beveiligingslijn.
- Voorkom ophoping tussen papier en configuratie. Een verlaging van de tenant-baseline kan afwijkingen laten opstapelen tussen formele compliance-documentatie en de feitelijke Entra-configuratie. In het beschreven escalatiepad kan dit uitmonden in het falen van een externe ISO 27001- of NIS2-audit met zware non-conformities. De directe verlichting van authenticatiefrictie krijgt dan een bestuurlijke nasleep, omdat de gedocumenteerde situatie niet meer overeenkomt met de werkelijke inrichting.
- Behandel compensatie als begrenzing, niet als vervanging van herstel. Een technische compensatie dempt het beveiligingsgat dat een tijdelijke uitzondering creëert. Zij verandert de uitzondering niet in een structurele oplossing voor het onderliggende compatibiliteitsprobleem. De tenant-baseline blijft daarom het referentiepunt, terwijl de compensatie uitsluitend de afwijkende toegangssituatie beheerst.
Bronnen bij deze sectie: nist.gov, cisa.gov
Wanneer productiviteit of lokale samenwerking om een uitzondering vraagt
Verzoeken om tijdelijke minder strikte toegang komen vaak voort uit een reëel werkpatroon. De beoordeling draait dan om de verhouding tussen de directe werkbelemmering, de beschikbare proportionele compensatie en de mogelijkheid om de afwijking centraal zichtbaar te houden.
- “Blokkeert harde verificatie medewerkers in het veld of in de zorg niet?”
Harde verificaties kunnen accountovernames helpen voorkomen, maar kunnen veld- en zorgmedewerkers blokkeren wanneer geen proportionele compensatie beschikbaar is. Web-only toegang is een genoemd voorbeeld van zo'n compensatie. De vraag is dus niet of productiviteit tegenover beveiliging staat als een absolute keuze. De relevante afweging is of de tijdelijke toegang een begrensde vorm krijgt die het werkproces mogelijk maakt zonder de normale beveiligingslijn voor de tenant blijvend te verlagen. Een tijdelijke afwijking blijft in deze situatie gekoppeld aan de directe aanleiding en aan de compensatie die de minder strikte toegang begrenst. Permanente verlaging van de baseline is daarmee geen standaardreactie op problemen met verificatie. - “Kunnen lokale managers niet zelf flexibel beslissen over externe samenwerking?”
Lokale flexibiliteit kan projecten versnellen wanneer externe samenwerking daarom vraagt. Die versnelling heeft echter een tenant-brede tegenwaarde: de afwijking moet binnen gecentraliseerde governance zichtbaar blijven om compliance voor de gehele tenant te kunnen waarborgen. Zonder die centrale zichtbaarheid wordt een lokale beslissing moeilijk te onderscheiden van andere uitzonderingen die elders zijn toegekend. De organisatie verliest dan het overzicht over welke afwijkingen bestaan, waarom zij bestaan en hoe zij zich verhouden tot de tenant als geheel. Lokale ruimte kan dus naast centrale governance bestaan, maar niet los daarvan. De centrale laag houdt de aantoonbaarheid vast, terwijl de tijdelijke afwijking beperkt blijft tot het samenwerkingsverzoek waarvoor zij is gemaakt.
Bronnen bij deze sectie: nist.gov, cisa.gov, cloudsecurityalliance.org
Maak afwijkingen zichtbaar als herstelwerk, niet als stilzwijgende standaard
Duurzaam uitzonderingsbeheer verbindt twee soorten informatie die vaak los van elkaar blijven bestaan. Aan de technische kant kunnen configuraties aantoonbaar worden gebaseerd op officiële baselines en het Well-Architected Framework. Daarmee ontstaat een onderbouwde referentie voor de inrichting van de tenant: zichtbaar is welke configuratiekeuze op welke basis rust. Die referentie maakt een afwijking herkenbaar als afwijking, in plaats van als een instelling die door herhaling vanzelf als normaal is gaan gelden.
Aan de bestuurlijke kant geeft een actueel Security Exception Register het periodieke kwartaaloverleg een concreet object. Het register bevat risicoscores, compenserende maatregelen en hersteltermijnen. Daardoor gaat het gesprek niet alleen over de vraag of een uitzondering nog bestaat, maar ook over de resterende risico-inschatting, de actieve begrenzing en het geplande herstel. Een hersteltermijn is hierbij meer dan een notitie over een gewenste datum: hij plaatst de afwijking in een bestuurbare tijdlijn waarin duidelijk wordt of herstelwerk vordert, stagneert of opnieuw beoordeeld moet worden.
De combinatie van aantoonbare configuratiekeuzes en een actueel register voorkomt dat governance uitsluitend reageert op incidenten of escalaties. De technische basis maakt zichtbaar waarvan wordt afgeweken; het register maakt zichtbaar welke compensatie en welke hersteltermijn bij die afwijking horen. Dat is ook financieel en operationeel relevant: zonder actuele risicoscores, compensaties en hersteltermijnen verandert kwartaaloverleg in handmatig uitzoekwerk naar afwijkingen, terwijl herstelwerk en de bijbehorende beheerskosten buiten beeld blijven.
Bronnen bij deze sectie: nist.gov
Dit artikel biedt geen juridisch advies. De toepasselijke verplichtingen hangen af van het doel, de functionaliteit, de gebruikerscontext en de risicoclassificatie van het systeem. Laat de concrete toepassing juridisch beoordelen vóór productiegebruik.