BIO 13.01 ISO A.13.1.1

Mail Flow & Gateway Design

📅 2025-10-30
•
⏱️ 12 minuten lezen
•
🟢 Should-Have

💼 Management Samenvatting

Het ontwerp van de mailflow en e-mailgateways bepaalt hoe berichten veilig, betrouwbaar en conform Nederlandse compliance-eisen door Exchange Online bewegen.

Aanbeveling
Kies voor directe mailflow naar Exchange Online, gebruik alleen een gateway bij aantoonbare compliance- of integratie-eisen.
Risico zonder
Medium
Risk Score
6/10
Implementatie
32u (tech: 24u)
Van toepassing op:
✓ Exchange Online
✓ Email Gateway
✓ SMTP

Directe levering naar Exchange Online verkleint de beheerlast en benut de volledige bescherming van Microsoft Defender, maar sommige organisaties hebben aanvullende inspectie, archivering of versleuteling nodig via een externe gateway. Zonder een doordacht ontwerp ontstaat een lappendeken van connectors, DNS-records en uitzonderingen die vertragingen veroorzaakt, berichten laat vastlopen of gevoelige informatie zonder toezicht laat vertrekken.

PowerShell Modules Vereist
Primary API: Exchange Online PowerShell
Connection: Connect-ExchangeOnline
Required Modules: ExchangeOnlineManagement

Implementatie

Dit document beschrijft praktijkrijpe architecturen voor direct verkeer, enkelvoudige gateways en dual-gatewayketens, inclusief besliskaders voor MX-records, SPF-aanpassingen, connectorconfiguraties en operationele afspraken zodat beheerteams consistent kunnen implementeren, monitoren en bijsturen.

Vereisten

Een solide mailflowontwerp begint bij een goed beheerde Exchange Online-tenant waarin licenties, mailboxprovisioning en beleid voor gegevensbescherming volwassen zijn. Iedere mailbox die als bron of bestemming voor hybride of federatieve stromen fungeert moet beschikken over voldoende opslag, herstelbare mailboxen en gedefinieerde bewaartermijnen zodat berichten niet voortijdig worden verwijderd. Daarnaast moet de organisatie beschikken over een actuele configuratie van Microsoft Defender voor Office 365 of een gelijkwaardige oplossing zodat native antispam- en anti-malwarelagen actief zijn voordat verkeer eventueel naar een gateway wordt geleid. Zonder deze fundamenten is elke gateway slechts een pleister op een structureel probleem. Bevestigde domeinen en zorgvuldig beheerde DNS-records vormen de tweede pijler. Alle primaire en secundaire SMTP-domeinen moeten in Exchange Online zijn gevalideerd, toegewezen aan de juiste e-mailadressen en consistent zijn met het organisatiebrede identiteitsmodel. MX-records, SPF-entries en eventuele CNAME- of TXT-records voor DKIM moeten geautomatiseerd worden uitgerold via het centrale DNS-beheer zodat wijzigingen traceerbaar zijn. Vooraf moet duidelijk zijn welke IP-adressen of hostnamen de gateway gebruikt, hoe failover-records worden gepubliceerd en welke TTL-waarden nodig zijn om snelle wijzigingen tijdens incidentrespons mogelijk te maken. Dit voorkomt dat berichten naar verouderde eindpunten blijven gaan nadat er architecturale aanpassingen zijn doorgevoerd. Authenticatie- en encryptiemechanismen vragen minstens zoveel aandacht als netwerkpaden. De organisatie moet beschikken over een actueel overzicht van certificaten voor TLS, inclusief uitgifteprocedures, rotatieschema’s en sleutelbeheer. Wanneer IP-verificatie wordt gebruikt, zijn firewallregels nodig die inkomende en uitgaande SMTP-stromen vanuit bekende adressen toelaten en verdachte bronnen blokkeren. Connectoren in Exchange Online dienen per usecase te worden beschreven, inclusief verplichte headers, limieten voor berichtgrootte en beperkingen voor specifieke verzenddomeinen. Door die configuraties vooraf te documenteren kunnen beheerders aantonen dat berichten alleen via gecontroleerde routes het platform verlaten of binnenkomen. Voor organisaties die een derde partij gebruiken, is inzicht in capaciteit, beschikbaarheid en beveiliging van de gateway cruciaal. Er moeten redundante nodes in gescheiden datacenters aanwezig zijn, ondersteund door duidelijke failoverprocedures en health-checks die elke minuut beschikbaarheid meten. Capaciteitsplanning houdt rekening met piekbelasting tijdens campagnes, automatische replies en incidentmeldingen zodat wachtrijen niet oplopen. Daarnaast zijn integraties nodig met DLP-, archiverings- of encryptieservices; de benodigde API-sleutels, service-accounts en logging-eisen moeten vooraf geautoriseerd worden en voldoen aan Nederlandse privacyregelgeving en de BIO. Tot slot vereist een volwassen mailflowarchitectuur duidelijke processen en vaardigheden. Rollen zoals mailflow-architect, gatewaybeheerder, SOC-analist en DNS-specialist moeten met bijbehorende verantwoordelijkheden zijn vastgelegd in het security- en operationshandboek. Veranderverzoeken verlopen via een change-proces waarin risico’s, testscenario’s en terugvalplannen worden beschreven voordat configuraties live gaan. Trainingen zorgen ervoor dat beheerders de betekenis van headers, transportregels en encryptiebeleid begrijpen. Documentatie moet in het Nederlands beschikbaar zijn en omvat runbooks voor onderhoud, escalaties en audits. Alleen met deze organisatorische randvoorwaarden kunnen technische vereisten daadwerkelijk leiden tot een voorspelbaar en veilig e-mailtransport. Daarnaast moet de organisatie aantonen dat integraties met identity- en securityprocessen geborgd zijn. Denk aan het synchroniseren van blokkeerlijsten tussen SIEM, e-mailgateway en endpointbeveiliging, het opnemen van mailflowstappen in business continuity-plannen en het beschikbaar hebben van testomgevingen waarin updates veilig kunnen worden gevalideerd. Door deze afhankelijkheden expliciet te benoemen ontstaat draagvlak bij management en architectuurfora, waardoor investeringen in licenties, netwerksegmentatie en opleiding tijdig worden goedgekeurd.

Implementeeratie

Directe mailflow naar Exchange Online vormt de basis voor de meeste Nederlandse organisaties omdat het beheerkosten beperkt en de volledige securitystack van Microsoft benut. Het traject start met het plannen van DNS-aanpassingen, waarbij MX-records alvast naar de nieuwe clouddoelstelling wijzen in een gecontroleerd tijdslot. Vervolgens worden standaardthrottles, transportregels en spamfilters geëvalueerd zodat beleid rondom vertrouwelijke informatie, versleuteling en quarantaines consistent wordt toegepast. Tijdens pilots wordt gebruikgemaakt van testdomeinen en gefaseerde cut-overs om te controleren hoe legacy-applicaties, multifunctionele printers en externe partners reageren op de directe route. Door monitoring van message traces en SMTP-logs kunnen teams bewijzen dat berichten binnen de afgesproken tijd worden afgeleverd voordat de productievolumes worden omgezet.

Wanneer binnenkomende post eerst een derde partij moet passeren, wordt een inbound-gatewayarchitectuur ingericht. De eerste stap is het opstellen van een duidelijk doel: gaat het om verscherpte DLP, additionele sandboxing of verplicht verkeer via een sectorale voorziening zoals ZIVVER of een zorgnetwerk? Op basis daarvan worden capaciteitsberekeningen gemaakt, inclusief failover tussen meerdere gatewayclusters. De MX-records verwijzen naar de gateway, terwijl Exchange Online een inboundconnector krijgt die alleen verkeer van de bekende IP-adressen of TLS-certificaten accepteert. In de gateway worden policies voor authenticatie, virusscans, SPF-evaluatie en berichtmanipulatie ingericht zodat niets aan het berichtformaat verandert waardoor Exchange Online transportregels zouden kunnen falen. Tot slot wordt een expliciet pad voor interne e-mail naar Microsoft gedefinieerd zodat loopdetectie en berichtklassificatie intact blijven.

Voor uitgaande stromen via een gateway wordt een outboundconnector aangemaakt waarin de gatewayhosts als smarthost zijn gedefinieerd en TLS verplicht is. Deze route is vooral relevant wanneer er aanvullende ontsleuteling, compliance-archivering of sectorale beveiligingsstandaarden moeten worden toegepast voordat e-mail het internet opgaat. De inrichting vereist afspraken over IP-reputatiebeheer, rate limiting en eventuele herschrijving van afzenderdomeinen. Daarnaast moet de gateway DMARC- en DKIM-handtekeningen intact laten of in overleg nieuwe handtekeningen plaatsen die overeenkomen met de geregistreerde records. Changeprocedures beschrijven hoe Exchange Online tijdelijk rechtstreeks naar internet kan verzenden wanneer de gateway problemen ondervindt, inclusief automatische rollback zodra de dienst weer gezond is.

In scenario’s met zowel inbound- als outboundgateways wordt het proces nog nauwkeuriger vastgelegd. Beide richtingen vereisen redundante koppelingen, gescheiden beheeraccounts en uniforme logging zodat SOC-teams correlaties kunnen maken over de gehele keten. Berichtklassificaties die in de inkomende stroom worden toegepast moeten downstream opnieuw beschikbaar zijn wanneer een bericht de organisatie verlaat; dat vraagt om consistente headerafspraken, namespacebeheer en validatie van transportregels. Tijdens ontwerpworkshops wordt bepaald hoe escalaties verlopen als een van de gateways degradeert en hoe het verkeer tijdelijk direct naar Exchange Online kan worden geleid zonder dat complianceverplichtingen worden geschonden. Door deze spelregels vooraf te oefenen, blijft de organisatie in controle tijdens echte verstoringen.

Connectoren vormen de toegangsdeuren tot Exchange Online en krijgen daarom een eigen lifecycle. Voor elke connector wordt vastgelegd wie eigenaar is, welk doel hij dient en welke beveiligingsinstellingen van toepassing zijn. Inboundconnectoren worden gekoppeld aan partneridentiteiten of specifieke IP-adressen, en accepteren uitsluitend geauthenticeerde TLS-verbindingen. Outboundconnectoren sturen naar partners, gateways of on-premises systemen en bevatten limieten voor berichtgrootte, authenticatie via certificaten en verplichte regeleinden. Auditlogging registreert alle wijzigingen, terwijl geautomatiseerde scripts de configuratie vergelijken met het referentieontwerp. Zo blijft de connectorlaag betrouwbaar, inzichtelijk en eenvoudig te herstellen mocht iemand per ongeluk instellingen wijzigen.

Gebruik PowerShell-script m365-mail-flow-gateway.ps1 (functie Invoke-Monitoring) – monitor mail flow connectors.

monitoring

Effectieve bewaking combineert zicht op Exchange Online met telemetrie uit gateways, DNS en beveiligingsplatforms zodat afwijkingen vroeg worden ontdekt. Operationele teams beginnen met het continu uitlezen van de mailflowdashboards in het Exchange Admin Center, aangevuld met near-realtime message traces die vertragingen of bounces inzichtelijk maken. Iedere wijziging in connectorstatus, TLS-handdrukken of authenticatiepogingen wordt naar een centraal SIEM gestuurd waar regels waarschuwen voor onverwachte bronnen of volumepieken. Op de gateways meten health-probes de wachtrijlengte, CPU-belasting en TLS-certificaatgeldigheid; zodra een drempel wordt overschreden, start een runbook dat berichten automatisch herrouteert of verkeer tijdelijk direct naar Exchange Online stuurt. Monitoring stopt niet bij netwerkpaden. DNS-records voor MX en SPF worden dagelijks gecontroleerd op ongeautoriseerde wijzigingen en worden vergeleken met de configuratiebron in het configuratiemanagementsysteem. DMARC-rapportages worden geanalyseerd op afwijkingen per domein zodat misbruik van afzenderidentiteiten snel wordt opgespoord. Daarnaast worden steekproeven gedaan op berichten die via de gateway lopen om te controleren of verplichte headers, versleuteling en classificaties intact blijven. Door deze controles systematisch te documenteren ontstaat bewijs richting auditors dat de mailflow permanent wordt bewaakt. Automatisering versnelt dit proces. PowerShell-scripts, waaronder de taak Invoke-Monitoring, verzamelen connectorconfiguraties, verifiëren TLS-instellingen en testen smarthostbereikbaarheid vanuit meerdere locaties. De resultaten worden vergeleken met een referentieprofiel zodat afwijkingen onmiddellijk zichtbaar worden. Eventuele fouten leiden tot tickets richting het SOC of de mailflowbeheerders, die vervolgens de details in het SIEM raadplegen en beslissen of mitigatie vereist is. Door automatisering te combineren met menselijke analyse blijft de controle schaalbaar, ook wanneer het e-mailvolume groeit of nieuwe gateways worden toegevoegd. Proactieve bewaking omvat eveneens synthetische transacties waarbij elke tien minuten testroutes worden verstuurd via alle relevante gateways en domeinen. Deze berichten bevatten controlehashes zodat direct zichtbaar is of berichtmanipulatie optreedt of dat vertragingen boven de afgesproken servicelevels uitkomen. De resultaten worden vergeleken met gebruikersklachten uit het servicedeskportaal; wanneer beide bronnen dezelfde trend laten zien, schakelt het team sneller op naar probleembeheer. In perioden met verhoogde dreigingen, zoals bij phishingcampagnes tegen de rijksoverheid, wordt de meetfrequentie opgevoerd en worden SOC-analisten via dashboards gewaarschuwd zodra verdachte patronen zich aandienen. Naast technische telemetrie wordt ook gekeken naar procesindicatoren. Maandelijkse rapportages tonen hoeveel changes aan connectors zijn uitgevoerd, hoeveel incidenten met gateways plaatsvonden en hoe lang het duurde om terug te keren naar de norm. Deze inzichten worden gedeeld met CISO’s en dienstverleners zodat zij investeren in extra capaciteit of opleidingen waar nodig. Door bewaking te positioneren als een integraal onderdeel van de Nederlandse Baseline voor Veilige Cloud ontstaat een cultuur waarin afwijkingen onmiddellijk worden besproken en opgelost. Tot slot wordt monitoring gekoppeld aan voorspellende analyses. Historische data over seizoenspieken, nieuwe phishinggolven en infrastructuurverstoringen wordt gevoed aan machinelearningmodellen die voorspellen wanneer latentiegrenzen in gevaar komen. Op basis daarvan worden drempels dynamisch bijgesteld, extra gatewaycapaciteit ingeschakeld of onderhoudsvensters verplaatst. Deze inzichten worden gedeeld met ketenpartners zodat gezamenlijke maatregelen, zoals het tijdelijk blokkeren van verdachte domeinen of het verplichten van TLS, in een gecoördineerd tijdsframe plaatsvinden. Door prioriteitswaarden, responstijden en lessons learned te koppelen aan concrete KPI’s ontstaat een dashboard waarmee bestuurders in één oogopslag zien hoe de mailflow presteert ten opzichte van de afgesproken normen.

Gebruik PowerShell-script m365-mail-flow-gateway.ps1 (functie Invoke-Monitoring) – Automated mail flow health check.

Remediatie

Herstelacties beginnen met het analyseren van de symptomen: vertraagde levering, bounceberichten, stijgende wachtrijen of beveiligingsalerts. Beheerders vergelijken de actuele configuratie met het referentieontwerp, controleren of de juiste certificaten zijn geladen en evalueren firewall- of netwerkwijzigingen die recent zijn doorgevoerd. Pas wanneer de oorzaak is vastgesteld, wordt een gecontroleerde wijziging uitgevoerd, bijvoorbeeld het heractiveren van TLS, het bijwerken van IP-allowlists of het vernieuwen van een connector. Elke stap wordt gedocumenteerd zodat later kan worden aangetoond welke maatregelen effect hadden. Indien wachtrijen op de gateway oplopen, wordt eerst vastgesteld of het probleem aan de bron (Exchange Online), onderweg (netwerk) of op de gateway zelf ligt. Vervolgens worden berichten selectief doorgestuurd naar alternatieve paden of tijdelijk teruggeleid naar directe cloudlevering om de dienstverlening in stand te houden. Dit gebeurt volgens een vooraf goedgekeurd terugvalplan waarin staat hoe DNS-records of smarthostconfiguraties worden aangepast en hoe gebruikers worden geïnformeerd over eventuele vertragingen. Na de primaire herstelactie volgt verificatie. Message traces, testberichten en synthetische transacties controleren of versleuteling, antispamregels en transport policies opnieuw correct functioneren. PowerShell-scripts zoals Invoke-Remediation voeren deze checks geautomatiseerd uit en rapporteren naar het changebeheerteam. Pas wanneer de resultaten stabiel zijn, worden tijdelijke bypasses teruggedraaid, worden DNS-records hersteld en wordt de gateway opnieuw in productie gezet. Het laatste onderdeel van remediatie is leren van incidenten. Elk probleem leidt tot een post-incidentreview waarin rootcause, detectietijd, hersteltijd en voorgestelde verbeteringen staan. Deze inzichten worden vertaald naar aanvullende monitoringregels, aangepaste runbooks of nieuwe trainingssessies voor beheerders. Zo bouwt de organisatie stap voor stap een robuust proces op waarmee toekomstige verstoringen sneller en met minder impact kunnen worden opgelost. Tijdens omvangrijke incidenten wordt een crisisteam ingericht waarin mailflow-experts samenwerken met netwerk-, SOC- en communicatieprofessionals. Zij hanteren vooraf geoefende scenariokaarten waarin duidelijk staat wie beslissingen neemt, hoe escalaties naar leveranciers verlopen en welke berichten richting directie of ketenpartners worden verstuurd. Door deze multidisciplinaire aanpak blijven de technische acties synchroon lopen met bestuurlijke verwachtingen en wordt voorkomen dat parallelle wijzigingen elkaar tegenwerken of dat onduidelijke communicatie extra druk oplevert. Automatisering speelt ook tijdens remediatie een sleutelrol. Scripts kunnen bijvoorbeeld automatisch connectorconfiguraties terugzetten naar de laatst bekende goede staat, gateways herstarten binnen afgesproken vensters of DNS-records aanpassen op basis van vooraf gedefinieerde failoverprofielen. Deze automatisering wordt echter altijd gecombineerd met controles door mensen zodat er geen ongewenste kettingreacties ontstaan. Door elke automatiseringsstap te documenteren en periodiek te testen in een gesimuleerde omgeving blijft de betrouwbaarheid hoog en zijn beheerders vertrouwd met de tooling op het moment dat elke seconde telt. Alle herstelacties monden uit in bijgewerkte kennisartikelen en trainingsmateriaal. Technische stappen, getroffen noodmaatregelen en beslissingen van het crisisteam worden samengebracht in een Nederlandstalig runbook dat als referentie dient bij volgende incidenten. Dit levend document wordt gedeeld met leveranciers en ketenpartners zodat zij hun eigen procedures hierop kunnen afstemmen en gezamenlijke oefeningen realistischer worden. Na afronding worden alle bevindingen gekoppeld aan prestatie-indicatoren, zodat managementrapportages laten zien hoe vaak herstelacties binnen het servicelevel zijn afgerond en welke structurele knelpunten extra investeringen vereisen. Deze rapportages sturen vervolgacties en prioriteren structurele verbetermaatregelen.

Gebruik PowerShell-script m365-mail-flow-gateway.ps1 (functie Invoke-Remediation) – Remediate connector issues.

Compliance en Auditing

Mailflowontwerpen staan direct in verbinding met wettelijke vereisten zoals de BIO, NIS2 en sectorspecifieke richtlijnen voor zorg, onderwijs of rijksoverheden. Daarom wordt de architectuur tot in detail gedocumenteerd, inclusief rationale waarom bepaalde gateways, encryptieopties of loggingniveaus zijn gekozen. Deze documentatie bevat stroomschema’s, configuraties van connectors, gebruikte certificaten, bewaartermijnen en verantwoordelijkheden. Door alle keuzes in het Nederlands vast te leggen kunnen auditors en toezichthouders zonder vertaalslag beoordelen of de inrichting voldoet aan nationale normen. Gedetailleerde exporten van connectorconfiguraties, transportregels en DNS-records worden periodiek opgeslagen in een auditkluis met versiebeheer. Iedere wijziging loopt via changebeheer waarbij testresultaten, risicoanalyses en goedkeuringen worden vastgelegd. Door per kwartaal end-to-end mailflowtests uit te voeren, inclusief scenario’s met gateway-failover, toont de organisatie aan dat de maatregelen niet alleen op papier bestaan maar ook in praktijk functioneren. De testresultaten worden gekoppeld aan incident- en problemmanagement zodat structurele verbeteringen aantoonbaar zijn. Compliance overstijgt techniek; het raakt ook privacy en gegevensbescherming. Voor elke gateway wordt vastgesteld welke persoonsgegevens worden verwerkt, hoe lang logging bewaard blijft en hoe toegang tot deze logs is afgeschermd. Encryptiestromen worden gekoppeld aan AVG-procedures voor inzage- of verwijderverzoeken, zodat een burger of medewerker precies kan worden verteld welke route zijn bericht heeft afgelegd. Indien archivering of journaling wordt toegepast, is er een expliciete koppeling met bewaartermijnen en vernietigingsprocedures om overstemming met wet- en regelgeving te borgen. Audits worden voorbereid met een set standaardbewijzen: actuele architectuurdiagrammen, change-logs, resultaten uit het SIEM, rapportages van DMARC/DKIM-SPF en de meest recente uitkomsten van failovertests. Door dit pakket actueel te houden kan de organisatie bij elke externe beoordeling binnen enkele uren de gevraagde stukken overhandigen. Het reduceert auditstress, verkleint de kans op sancties en bewijst dat mailflowbeveiliging een integraal onderdeel vormt van de Nederlandse Baseline voor Veilige Cloud. Een volwassen compliance-aanpak koppelt mailflowmaatregelen bovendien aan bredere controleraamwerken zoals ISO 27001, ENSIA of sectorale normenkaders. Elke maatregel in dit document wordt gelinkt aan een controleregel, met verwijzing naar het verantwoordelijke team en de gebruikte tooling. Hierdoor kunnen auditors snel herleiden welke logbestanden of dashboards aantonen dat een control actief is. Deze mapping wordt onderhouden in het configuratiemanagementsysteem zodat wijzigingen in architectuur automatisch leiden tot een update van de compliance-documentatie. Transparantie richting bestuurders en ketenpartners is minstens zo belangrijk. Periodieke compliance-rapportages beschrijven hoe vaak mailflowcontroles zijn getest, welke afwijkingen zijn aangetroffen en welke verbeteringen zijn ingevoerd. Door successen en leermomenten te delen groeit het vertrouwen dat e-mail een betrouwbaar communicatiekanaal blijft, zelfs wanneer dreigingen toenemen of wanneer wetgeving verandert. Daarmee sluit de organisatie aan bij het principe van continue verbetering dat centraal staat binnen de Nederlandse Baseline voor Veilige Cloud. Verder onderhouden organisaties structurele relaties met leveranciers van gateways, encryptiediensten en sectorale berichtenplatformen. Contractuele afspraken bevatten clausules over auditrechten, dataminimalisatie en responstijden tijdens incidenten. Gezamenlijke evaluaties zorgen ervoor dat externe partijen dezelfde normen hanteren voor logging, privacy en beschikbaarheid, zodat de gehele keten aantoonbaar voldoet aan Nederlandse wet- en regelgeving. Deze ketenbrede samenwerking resulteert in een gedeeld compliance-dashboard waarin elke partner realtime kan aantonen dat controles actief zijn en dat maatregelen daadwerkelijk bijdragen aan betrouwbare en veilige e-mailcommunicatie.

Compliance & Frameworks

Automation

Gebruik het onderstaande PowerShell script om deze security control te monitoren en te implementeren. Het script bevat functies voor zowel monitoring (-Monitoring) als remediation (-Remediation).

PowerShell
<# .SYNOPSIS Mail Flow & Gateway Design .DESCRIPTION Implementation for Mail Flow & Gateway Design .NOTES Filename: m365-mail-flow-gateway.ps1 Author: Nederlandse Baseline voor Veilige Cloud Version: 1.0 Related JSON: content/design/platform/m365-mail-flow-gateway.json #> #Requires -Version 5.1 #Requires -Modules Microsoft.Graph [CmdletBinding()] param( [Parameter()][switch]$WhatIf, [Parameter()][switch]$Monitoring, [Parameter()][switch]$Remediation, [Parameter()][switch]$Revert ) $ErrorActionPreference = 'Stop' $VerbosePreference = 'Continue' $PolicyName = "Mail Flow & Gateway Design" $BIOControl = "13.01" function Connect-RequiredServices { # Connection logic based on API } function Test-Compliance { Write-Verbose "Testing compliance for: $PolicyName..." $result = [PSCustomObject]@{ ScriptName = "m365-mail-flow-gateway" PolicyName = $PolicyName IsCompliant = $false TotalResources = 0 CompliantCount = 0 NonCompliantCount = 0 Details = @() Recommendations = @() } # Compliance check implementation # Based on: Design Document $result.Details += "Compliance check - implementation required based on control" $result.NonCompliantCount = 1 return $result } function Invoke-Remediation { Write-Host "`nApplying remediation for: $PolicyName..." -ForegroundColor Cyan # Remediation implementation Write-Host " Configuration applied" -ForegroundColor Green Write-Host "`n[OK] Remediation completed" -ForegroundColor Green } function Invoke-Monitoring { $result = Test-Compliance Write-Host "`n========================================" -ForegroundColor Cyan Write-Host "$PolicyName" -ForegroundColor Cyan Write-Host "========================================" -ForegroundColor Cyan Write-Host "Total: $($result.TotalResources)" -ForegroundColor White Write-Host "Compliant: $($result.CompliantCount)" -ForegroundColor Green $color = if ($result.NonCompliantCount -gt 0) { "Red" } else { "Green" } Write-Host "Non-compliant: $($result.NonCompliantCount)" -ForegroundColor $color return $result } function Invoke-Revert { Write-Host "Revert: Configuration revert not yet implemented" -ForegroundColor Yellow } try { Connect-RequiredServices if ($Monitoring) { Invoke-Monitoring } elseif ($Remediation) { if ($WhatIf) { Write-Host "WhatIf: Would apply remediation" -ForegroundColor Yellow } else { Invoke-Remediation } } elseif ($Revert) { Invoke-Revert } else { $result = Test-Compliance if ($result.IsCompliant) { Write-Host "`n[OK] COMPLIANT" -ForegroundColor Green } else { Write-Host "`n[FAIL] NON-COMPLIANT" -ForegroundColor Red } } } catch { Write-Error $_ }

Risico zonder implementatie

Risico zonder implementatie
Medium: Onjuist ingerichte routes leiden tot vertraagde of geweigerde berichten, compliancegaten en extra kwetsbaarheid door single points of failure in gateways. Het risico vertaalt zich in onderbroken dienstverlening en gebrek aan aantoonbaarheid richting toezichthouders.

Management Samenvatting

Direct verkeer naar Exchange Online houdt het ontwerp overzichtelijk, benut Microsoft Defender volledig en vergt weinig beheer. Alleen wanneer wetgeving, sectorale encryptie-eisen of legacy-integraties het verplichten, wordt een betrouwbare in- en/of outboundgateway toegevoegd. Voor elke variant gelden: actuele MX- en SPF-records, streng geconfigureerde connectors, continue monitoring en gedocumenteerde terugvalscenario’s. Directe route blijft de norm omdat deze goedkoper, eenvoudiger en beter te auditen is.