Waarom ‘Microsoft regelt de security’ een gevaarlijke misvatting is

🤖 In het kort

Microsoft 365 is veilig gebouwd, maar niet automatisch veilig ingericht. In het shared responsibility-model beveiligt Microsoft vooral het platform; jij blijft verantwoordelijk voor identiteit & toegang (Entra ID), apparaatbeheer (Intune), dreigingsdetectie en opvolging (Defender) en datacontrole & compliance (Purview). 

De grootste risico’s ontstaan meestal door misconfiguraties, te ruime rechten, onbeheerde devices, te brede sharing en alerts zonder opvolging. 

Met een heldere security baseline, eigenaarschap en een periodieke checkcyclus maak je security praktisch én bestuurbaar.

Je betaalt voor Microsoft 365, je ziet “beveiligingsfeatures” in het admin center en je gaat ervan uit dat Microsoft het grootste deel van de risico’s afdekt. Dat is begrijpelijk. Maar het is ook precies de misvatting die in mkb-omgevingen leidt tot de meest voorkomende incidenten: accounts die worden overgenomen, mailfraude die toch doorkomt, data die per ongeluk te breed gedeeld wordt en back-ups die pas ontbreken op het moment dat je ze nodig hebt.

Niet omdat Microsoft 365 onveilig is, integendeel zelfs. Maar omdat security in Microsoft 365 in belangrijke mate een inrichtings- en beheerkeuze is. Wie denkt dat “de leverancier het regelt”, mist vaak de basis: eigenaarschap, beleid en controle.

In deze blog leggen we het Microsoft 365 Shared Responsibility-principe uit zonder technisch moeras. Je ziet wat Microsoft wel doet, wat jij moet doen, en welke concrete stappen je morgen kunt nemen om risico’s te verlagen.

Inhoudsopgave

De misvatting: “Microsoft regelt de security”

Wat mensen bedoelen (en waarom dat logisch voelt)

In veel SaaS-diensten is de belofte impliciet: “wij hosten het, dus wij beveiligen het”. Dat klopt deels. Microsoft zorgt voor het wereldwijde cloudplatform, de datacenters, redundantie en een groot deel van de basisbeveiliging van de onderliggende infrastructuur.

Maar security is meer dan “de server staat achter slot en grendel”. In de praktijk ontstaan incidenten door vragen als:

  • Wie mag waarop inloggen en vanaf waar?

  • Welke mail wordt vertrouwd?

  • Welke apparaten zijn toegestaan?

  • Welke data mag gedeeld worden en met wie?

  • Hoe snel reageer je op verdachte signalen?

Die vragen liggen niet bij Microsoft. Die liggen bij jou of bij degene die jouw Microsoft 365-omgeving beheert.

Waar het misgaat in de praktijk

De pijn zit zelden in één groot gat. Het zit in een reeks “kleine” keuzes die nooit expliciet gemaakt zijn: geen uniforme multi-factor authentication (MFA), geen Conditional Access-beleid, te ruime adminrechten, geen device compliance, geen dataclassificatie, geen DLP, geen duidelijke back-upstrategie.

En het lastige: zolang er niets gebeurt, voelt dat als “het zal wel goed zijn”.

Microsoft 365 Shared Responsibility in normale mensentaal

Het Shared Responsibility model kun je zien als een scheidslijn:

Microsoft is verantwoordelijk voor:

  • De beveiliging van het cloudplatform en de infrastructuur (datacenters, netwerk, hypervisors).

  • Beschikbaarheid en basisbescherming van de dienst.

  • Standaard beveiligingsmogelijkheden en patches op platformniveau.

Jij (de klant) bent verantwoordelijk voor:

  • Identiteit & toegang: wie mag inloggen, hoe, vanaf waar.

  • Configuratie: policies, instellingen, logging, alerts.

  • Data: classificeren, delen, bewaren, versleutelen, voorkomen van datalekken.

  • Apparaten: beheer, compliance, updates, verlies/diefstal.

  • Operationele opvolging: signalen beoordelen, incidenten afhandelen, verbeteren.

Microsoft levert de gereedschapskist. Jij bepaalt of je het gereedschap gebruikt — en hoe consistent.

Vier plekken waar die misvatting pijn doet

1. Identity: Entra ID - accounts zijn je nieuwe perimeter

Microsoft Entra ID (voorheen Azure AD) is de identiteitslaag van Microsoft 365. Als iemand toegang krijgt tot een account, heeft die persoon vaak direct toegang tot mail, Teams, SharePoint en soms ook bedrijfsapplicaties.

Wat hier vaak misgaat in mkb:

  • MFA staat niet overal aan, of alleen voor “belangrijke accounts”.

  • MFA is te zwak (alleen sms), of wordt omzeild via social engineering.

  • Geen Conditional Access (beleid dat o.a. locatie, device compliance en risico meeweegt).

  • Te veel mensen met adminrechten “voor het gemak”.

Praktisch voorbeeld
Een medewerker logt in op een onbeheerde laptop. De sessie blijft actief. Later wordt dat device gestolen of besmet. Zonder device policies en Conditional Access kan die sessie lang bruikbaar blijven, zonder dat iemand direct “een wachtwoord kraakt”.

Nuchtere take-away: identity-security is geen feature die je “aan” zet. Het is beleid dat je afdwingt.

2. Endpoint: Intune - apparaten bepalen je risico-oppervlak

Microsoft Intune is de beheerlaag voor apparaten (laptops, telefoons) en bepaalt of een device compliant is: versleuteling aan, updates op orde, schermvergrendeling, geen jailbroken phone, etc.

Wat vaak misgaat:

  • BYOD groeit vanzelf, maar regels groeien niet mee.

  • Geen uniforme compliance-eisen (“zolang Teams het doet…”).

  • Verlies of diefstal zonder mogelijkheid tot remote wipe.

  • Geen scheiding tussen privé en zakelijk op mobiele apparaten.

Waarom dit telt
Microsoft kan een datacenter beveiligen, maar niet jouw laptoppark. En een onveilig device is vaak de makkelijkste route naar je data.

3. Threat protection: Defender - signalen zonder opvolging zijn nutteloos

Microsoft Defender (o.a. Defender for Office 365, Defender for Endpoint) kan phishing detecteren, verdachte links blokkeren en afwijkend gedrag signaleren. Maar: signalen zijn alleen waardevol als iemand ze beoordeelt en opvolgt.

Wat vaak misgaat:

  • Alerts staan aan, maar niemand kijkt structureel.

  • Meldingen komen binnen bij een mailbox die niemand beheert.

  • Te veel “noise” → alert fatigue → alles wordt genegeerd.

  • Geen afspraken: wat is een incident, wie beslist, hoe snel reageren we?

Praktische nuance
Defender is geen “auto-pilot” die altijd incidenten oplost. Het is een sensor + gereedschap. Je hebt proces nodig om er winst uit te halen.

4. Data & compliance: Purview - delen en bewaren is ook een securitykeuze

Microsoft Purview helpt bij data governance en compliance: classificatie, retentie, eDiscovery en (afhankelijk van licenties) data loss prevention (DLP). Dit klinkt als “compliance”, maar het is óók security: je voorkomt dat gevoelige data ongecontroleerd rondzwerft.

Wat vaak misgaat:

  • SharePoint/OneDrive delen “werkt”, maar niemand weet wat er publiek staat.

  • Geen dataclassificatie → geen onderscheid tussen “onbelangrijk” en “gevoelig”.

  • Retentie is per toeval, niet per beleid (risico voor audits én voor herstel).

  • Geen DLP-regels voor bv. BSN, financiële data, klantcontracten.

Kort gezegd: security gaat niet alleen over buiten houden, maar ook over controle op wat naar buiten kan.

5 vragen om te toetsen of je shared responsibility écht regelt

Gebruik deze vijf vragen als snelle reality check. Als je op 2+ vragen “niet zeker” antwoordt, is het tijd om je basis te herzien.

  1. Is identiteit centraal en streng geregeld?
    MFA overal, Conditional Access actief, adminrechten minimaal.

  2. Kun je apparaten afdwingen of blokkeren?
    Alleen compliant devices bij gevoelige toegang, remote wipe mogelijk.

  3. Heb je zicht op verdachte signalen en een opvolgproces?
    Alerts komen bij een eigenaar, met afspraken over responstijd en escalatie.

  4. Weet je waar je gevoelige data staat en hoe die gedeeld wordt?
    Classificatie/labels, duidelijke deelregels, periodieke review.

  5. Kun je herstellen als het misgaat?
    Back-up- en recoveryaanpak die getest is, niet alleen “we vertrouwen op Microsoft”.

Wat je morgen al kunt doen (zonder grote projecten)

1. Leg een security baseline vast (en maak één eigenaar)

Een baseline is geen dik document. Het is een set minimum-afspraken die je consequent toepast: MFA-standaard, adminrollen, device compliance, logging, delen van data, back-up en incidentafhandeling.

Tip: maak het concreet in “wel/niet” regels. Bijvoorbeeld:

  • “Geen adminrechten zonder zakelijke reden en periodieke review.”

  • “Toegang tot SharePoint vanaf unmanaged devices: beperkt of read-only.”

  • “Extern delen: standaard uit, alleen per site/team aan na goedkeuring.”

2. Doe 3 snelle checks met hoge impact

  • Identity check: staan MFA en Conditional Access echt goed voor iedereen, inclusief admins en externe accounts?

  • Sharing check: welke SharePoint-sites/OneDrive-mappen staan open voor ‘Iedereen met de link’?

  • Alert check: waar komen Defender-alerts binnen en wie handelt ze af?

3. Zet een ritme neer: maandelijks klein, per kwartaal groter

Security verslapt vanzelf. Niet door onwil, maar door drukte. Maak het bestuurbaar:

  • Maandelijks: review van admins, alerts, uitzonderingen.

  • Per kwartaal: baseline-check + verbeterlijst.

  • Jaarlijks: scenario-oefening (phishing/CEO-fraude of datalek) en recovery-test.

Shared responsibility is geen probleem, maar een keuze

“Microsoft regelt de security” is gevaarlijk omdat het eigenaarschap wegneemt. Microsoft levert een sterk platform. Maar jouw risico wordt vooral bepaald door keuzes in identiteit, devices, data en opvolging.

Wil je dit nuchter en praktisch aanpakken? Begin niet met tooling, maar met afspraken en controle. Zet een baseline neer, wijs eigenaarschap toe en toets periodiek.

Zero Trust een nieuw beveiligings tijdperk 2

Meer informatie over het Zero Trust model?

Download dan gratis ons eBook met meer informatie

Download >

Shared responsibility scherp krijgen en uw Microsoft 365 écht veilig inrichten?

Avista-Shegani

Avista denkt graag
met u mee.

ADRES

Blauwhekken 5b
4751 XD Oud Gastel

CONTACT

CUSTOMER CARE

LINKS

Building Our Future - Your.Cloud - White
ISO-27001