Azure App Service: TLS 1.2 Als Minimum Versie Afdwingen

TLS 1.0 en 1.1 zijn officieel als verouderd gemarkeerd door alle grote browsers en beveiligingsorganisaties vanwege bekende cryptografische zwakheden. Deze verouderde protocollen zijn kwetsbaar voor verschillende aanvallen: POODLE (Padding Oracle On Downgraded Legacy Encryption) maakt het mogelijk om versleutelde gegevens te onderscheppen, BEAST (Browser Exploit Against SSL/TLS) kan sessie-cookies stelen, en CRIME (Compression Ratio Info-leak Made Easy) kan gevoelige gegevens lekken via compressie-analyse. Deze kwetsbaarheden zijn niet theoretisch - ze worden actief uitgebuit door aanvallers om versleutelde communicatie te compromitteren. PCI-DSS 4.0 heeft sinds juni 2018 TLS 1.2 of hoger verplicht gesteld voor alle systemen die betaalkaartgegevens verwerken, en organisaties die nog TLS 1.0/1.1 toestaan zijn niet-nalevend. Het afdwingen van TLS 1.2 als minimum blokkeert alle verbindingspogingen van verouderde clients die alleen oudere protocollen ondersteunen, voldoet aan alle moderne nalevingsvereisten waaronder ISO 27001 en NIS2, en voorkomt protocol downgrade-aanvallen waarbij aanvallers proberen de verbinding te dwingen naar een zwakkere versleuteling. Alle moderne browsers (sinds 2008) en besturingssystemen ondersteunen TLS 1.2, dus de impact op legitieme gebruikers is minimaal.

Implementatie

Deze maatregel configureert de minTlsVersion-eigenschap op 1.2 voor alle Azure App Services en Function Apps. Wanneer deze instelling is geconfigureerd, weigert de App Service automatisch alle inkomende HTTPS-verbindingen die TLS 1.0 of 1.1 proberen te gebruiken, waardoor alleen TLS 1.2 en TLS 1.3 (waar ondersteund) worden toegestaan. De implementatie is eenvoudig en kan worden uitgevoerd via Azure Portal onder TLS/SSL-instellingen door 'Minimum TLS Version' in te stellen op 1.2, of via PowerShell voor geautomatiseerde implementatie over meerdere App Services. Moderne browsers en clients (Chrome, Firefox, Edge, Safari sinds 2008, iOS 5+, Android 4.4+) ondersteunen allemaal TLS 1.2, dus de impact op eindgebruikers is verwaarloosbaar. Alleen zeer oude systemen zoals Internet Explorer 10 en ouder op Windows 7, en Android 4.3 en ouder worden geblokkeerd, wat in 2025 een acceptabele beveiligingsafweging is. Deze wijziging vereist geen code-aanpassingen in de applicatie, heeft geen prestatie-impact (TLS 1.2 is efficiënter dan oudere versies), en is kosteloos te implementeren. Voor organisaties die werken met zeer oude client-systemen moet een migratieplan worden opgesteld, maar de beveiligingsbest practice is om deze verouderde systemen te upgraden in plaats van zwakke versleuteling toe te staan. Optioneel kan worden overwogen om in de toekomst TLS 1.3 als minimum in te stellen zodra Azure-brede ondersteuning volwassen is, wat nog sterkere versleuteling biedt.

Implementatie

De implementatie van TLS 1.2 als minimum versie voor Azure App Services kan op verschillende manieren worden uitgevoerd, afhankelijk van de schaal van de organisatie en de mate van automatisering die gewenst is. Voor kleine organisaties met enkele App Services is handmatige configuratie via de Azure Portal de meest directe aanpak, terwijl grotere organisaties met tientallen of honderden App Services baat hebben bij geautomatiseerde PowerShell-scripts of Azure Policy-implementaties die proactieve nalevingshandhaving bieden. Elke methode heeft specifieke voordelen en is geschikt voor verschillende scenario's.

**Handmatige Configuratie via Azure Portal** Voor organisaties met een beperkt aantal App Services, of wanneer een eenmalige configuratie nodig is, biedt de Azure Portal een gebruiksvriendelijke interface voor het instellen van TLS 1.2 als minimum versie. Het proces begint met navigatie naar de Azure Portal, waar men in het linkermenu naar App Services gaat en de specifieke App Service selecteert die geconfigureerd moet worden. Vervolgens klikt men onder Instellingen op 'TLS/SSL-instellingen', hoewel de exacte locatie kan variëren afhankelijk van de Portal-versie - sommige versies hebben deze optie onder 'Configuratie' en dan 'Algemene instellingen'. Binnen deze sectie bevindt zich de instelling 'Minimum TLS-versie', die meestal te vinden is in de 'Protocol-instellingen' sectie. Voor oudere App Services die zijn aangemaakt vóór 2018 staat deze instelling vaak standaard op TLS 1.0 of 1.1, wat onveilig is volgens moderne beveiligingsstandaarden. Door de dropdown te openen en '1.2' te selecteren, wordt de minimum TLS-versie ingesteld op het veilige niveau. TLS 1.3 is op dit moment nog optioneel omdat Azure nog niet overal volledige ondersteuning biedt voor deze nieuwste versie, hoewel dit in de toekomst de aanbevolen instelling zal worden zodra de ondersteuning volwassen is. Na het selecteren van TLS 1.2 klikt men op 'Opslaan' om de wijziging toe te passen. Een belangrijk voordeel van deze configuratie is dat er geen App Service-herstart vereist is - de wijziging wordt direct actief zonder uitvaltijd. Om te valideren dat de configuratie correct is toegepast, opent men de browser Developer Tools door op F12 te drukken, navigeert naar het Beveiliging-tabblad, en bezoekt de app-URL. In het Beveiliging-tabblad kan men verifiëren dat de verbinding TLS 1.2 of hoger gebruikt. Als aanvullende validatie kan men proberen om via verouderde tools zoals OpenSSL met specifieke vlaggen TLS 1.0 te forceren - deze poging moet nu falen, wat bevestigt dat de configuratie correct werkt. Deze handmatige methode is ideaal voor kleine implementaties maar wordt tijdrovend wanneer meerdere App Services geconfigureerd moeten worden.

**Geautomatiseerde Implementatie via PowerShell** Voor organisaties met meerdere App Services of wanneer regelmatige nalevingscontroles nodig zijn, biedt PowerShell-automatisering een efficiënte oplossing die tijd bespaart en consistentie garandeert. Het proces begint met het verbinden met Azure via de Connect-AzAccount-cmdlet, waarna men de juiste abonnement selecteert met Select-AzSubscription -SubscriptionId gevolgd door de abonnement-ID tussen aanhalingstekens. Deze stap is cruciaal omdat Azure-accounts vaak toegang hebben tot meerdere abonnementen, en men moet zeker zijn dat men werkt in de juiste omgeving. Vervolgens identificeert men alle niet-nalevende App Services met de opdracht Get-AzWebApp gevolgd door een Where-Object-filter dat controleert of de MinTlsVersion-eigenschap niet gelijk is aan '1.2'. Deze query toont alle App Services die nog TLS-versies lager dan 1.2 toestaan, wat een duidelijk overzicht geeft van de omvang van de implementatie. Voor elke niet-nalevende app wordt vervolgens TLS 1.2 als minimum ingesteld met een foreach-lus die Set-AzWebApp aanroept met de ResourceGroupName en Name van de app, en MinTlsVersion ingesteld op '1.2'. Tijdens dit proces wordt voor elke succesvol geconfigureerde app een groene bevestigingsmelding getoond met Write-Host, wat visuele feedback geeft over de voortgang. Na de implementatie valideert men de naleving door opnieuw Get-AzWebApp uit te voeren met een Select-Object die de Name, ResourceGroup en een berekende MinTLS-eigenschap toont, gevolgd door een Where-Object-filter dat alle apps met MinTLS niet gelijk aan '1.2' selecteert. Als de configuratie succesvol is, moet deze query een lege lijst retourneren. Voor rapportagedoeleinden kan men een nalevingsrapport exporteren naar CSV met Export-Csv, wat nuttig is voor audittrails en managementrapportages. Het rapport bevat alle App Services met hun respectievelijke TLS-versies, wat helpt bij het aantonen van naleving aan auditors. Voor continue naleving kan men een terugkerende nalevingscontrole inplannen via Azure Automation die wekelijks automatisch nieuwe App Services detecteert en herstelt, wat ervoor zorgt dat toekomstige implementaties automatisch nalevend zijn zonder handmatige interventie.

**Preventieve Controle via Azure Policy** Azure Policy biedt de meest geavanceerde en proactieve aanpak voor TLS 1.2-handhaving, waarbij niet alleen bestaande resources worden gecontroleerd, maar ook nieuwe implementaties automatisch worden geblokkeerd als ze niet voldoen aan de beveiligingsvereisten. Deze methode is ideaal voor organisaties die Infrastructure as Code gebruiken en willen voorkomen dat ontwikkelaars per ongeluk onveilige configuraties implementeren. Het proces begint in de Azure Portal onder Beleid, waar men naar Definities navigeert en zoekt naar het ingebouwde beleid genaamd 'App Service-apps moeten de nieuwste TLS-versie gebruiken', of men kan een aangepast beleid maken voor specifieke TLS 1.2-handhaving als het ingebouwde beleid niet precies aan de vereisten voldoet. Aangepaste beleidsregels bieden meer flexibiliteit maar vereisen kennis van Azure Policy Definition Language. Vervolgens wijst men het beleid toe op abonnementsniveau door naar Beleidstoewijzingen te gaan en 'Beleid toewijzen' te selecteren. Tijdens de toewijzing selecteert men het TLS-versiebeleid, definieert men het Bereik als het volledige abonnement of specifieke resourcegroepen, en kiest men het Effect. Het Effect kan 'Audit' zijn voor alleen detectie zonder blokkering, of 'Weigeren' voor het daadwerkelijk blokkeren van nieuwe niet-nalevende implementaties. Voor productie-omgevingen wordt 'Weigeren' sterk aanbevolen omdat dit proactieve beveiligingshandhaving biedt en voorkomt dat onveilige configuraties überhaupt worden geïmplementeerd. In de Parameters stelt men de Minimum TLS-versie in op 1.2. Een belangrijke optie tijdens de beleidstoewijzing is het inschakelen van 'Maak een hersteltaak', wat automatische herstel mogelijk maakt voor bestaande niet-nalevende resources zonder handmatige interventie. Deze hersteltaken kunnen worden geconfigureerd om direct uit te voeren of op een gepland tijdstip, wat flexibiliteit biedt voor onderhoudsvensters. Na de toewijzing toont het Beleidsnalevingsdashboard realtime het nalevingspercentage van alle App Services binnen het bereik, wat een duidelijk overzicht geeft van de beveiligingsstatus. Het doel is 100 procent naleving, en het dashboard helpt bij het identificeren van resources die nog aandacht nodig hebben. Het belangrijkste voordeel van Azure Policy met Weigeren-effect is dat het implementeren van nieuwe App Services met TLS lager dan 1.2 volledig blokkeert, wat betekent dat ontwikkelaars en DevOps-teams niet per ongeluk onveilige configuraties kunnen implementeren, zelfs niet via geautomatiseerde pipelines. Dit biedt proactieve beveiligingshandhaving op organisatieniveau en voorkomt beveiligingsschuld voordat deze ontstaat.

**Impactbeoordeling en Mitigatie voor Verouderde Clients** Voordat TLS 1.2-handhaving wordt geïmplementeerd, is het belangrijk om te beoordelen welke impact dit heeft op bestaande clients, vooral in organisaties die mogelijk nog verouderde systemen gebruiken die geen TLS 1.2 ondersteunen. Deze beoordeling voorkomt onverwachte service-onderbrekingen en helpt bij het plannen van migratiestrategieën. Het identificeren van potentiële verouderde clients begint met het analyseren van App Service-toegangslogboeken, die beschikbaar zijn via Application Insights of Azure Log Analytics. Men zoekt naar User-Agent-strings die wijzen op verouderde browsers en besturingssystemen, zoals Internet Explorer 10 en ouder, Android 4.3 en ouder, iOS 4 en ouder, en Windows XP-systemen. Daarnaast moeten applicaties die gebruik maken van zeer oude Java, Python of Node.js-bibliotheken zonder TLS 1.2-ondersteuning worden geïdentificeerd, omdat deze ook problemen kunnen ondervinden. Deze analyse geeft inzicht in de omvang van het verouderde systeemprobleem en helpt bij het bepalen van de bedrijfsimpact. Voor consumentgerichte applicaties is het percentage verouderd verkeer typisch minder dan 0,1 procent in 2025, omdat de overgrote meerderheid van gebruikers moderne browsers en apparaten gebruikt. Voor interne bedrijfsapplicaties moet men echter coördineren met IT-teams om te bevestigen of verouderde systemen nog actief zijn, omdat deze mogelijk kritieke bedrijfsprocessen ondersteunen. Als verouderde clients worden gedetecteerd, moet een communicatiestrategie worden ontwikkeld die gebruikers tijdig informeert over de komende wijzigingen. Deze strategie omvat het versturen van waarschuwingen naar gebruikers via e-mail of in-app-meldingen minimaal 30 dagen vóór de TLS 1.2-handhaving, wat gebruikers de tijd geeft om hun systemen te upgraden. De communicatie moet duidelijke upgrade-instructies bevatten voor browsers en besturingssystemen, met specifieke stappen voor verschillende platforms. Voor interne applicaties moet men coördineren met IT-teams voor systeemupgrades, wat mogelijk planning en budgettering vereist. Voor ingebedde apparaten en IoT-apparaten moet men controleren of firmware-updates beschikbaar zijn of of hardwarevernieuwing nodig is, wat mogelijk langere doorlooptijden heeft. In uitzonderlijke gevallen waar bedrijfskritieke verouderde clients niet kunnen upgraden en TLS 1.2 een absolute blokkering is, kan men overwegen om een tijdelijke respijtperiode in te stellen, maar dit moet gepaard gaan met een harde deadline van maximaal zes maanden voor het buiten gebruik stellen van verouderde systemen. Deze uitzondering moet worden gedocumenteerd als een beveiligingsuitzondering met goedkeuring van het management, en moet worden beoordeeld door het beveiligingsteam om te bevestigen dat het risico acceptabel is. De best practice is echter om geen compromis te sluiten op TLS 1.2, omdat verouderde systemen inherent onveilig zijn en moeten worden uitgefaseerd in plaats van geaccommodeerd. Het toestaan van verouderde versleuteling om verouderde systemen te ondersteunen creëert een blijvend beveiligingsrisico dat niet opweegt tegen het tijdelijke gemak van het ondersteunen van verouderde technologie.

De totale implementatietijd varieert aanzienlijk afhankelijk van de gekozen methode en het aantal App Services. Handmatige configuratie via de Portal neemt ongeveer 5 minuten per App Service in beslag, wat geschikt is voor kleine implementaties maar tijdrovend wordt bij tientallen of honderden services. Geautomatiseerde PowerShell-scripts vereisen 30 tot 60 minuten voor de initiële setup en het testen, maar daarna kunnen alle App Services binnen enkele minuten worden geconfigureerd, ongeacht het aantal. Azure Policy-setup neemt ongeveer een uur in beslag voor de configuratie en het testen, maar biedt daarna volledig geautomatiseerde handhaving zonder verdere handmatige interventie. Beoordeling van verouderde clients voegt 1 tot 2 uur extra tijd toe indien nodig, afhankelijk van de complexiteit van de omgeving en het aantal te analyseren logboeken. Wat betreft kosten is TLS 1.2 minimum-handhaving volledig gratis - er zijn geen extra Azure-kosten verbonden aan deze configuratie, en er is geen prestatie-impact omdat TLS 1.2 zelfs efficiënter is dan oudere versies. De totale implementatiekosten bedragen nul euro, wat deze maatregel tot een van de meest kosteneffectieve beveiligingsverbeteringen maakt die beschikbaar zijn.

Compliance en Auditing

Het afdwingen van TLS 1.2 als minimum versie voor Azure App Services is niet alleen een technische beveiligingsmaatregel, maar ook een verplichte vereiste onder verschillende internationale en nationale nalevingsframeworks die van toepassing zijn op Nederlandse overheidsorganisaties en bedrijven die werken met gevoelige gegevens. Deze nalevingsvereisten zijn ontwikkeld door verschillende standaardisatie-organisaties en regelgevende instanties om een minimale beveiligingsstandaard te garanderen voor versleutelde communicatie, en het niet naleven van deze vereisten kan leiden tot mislukte audits, boetes, en mogelijk verlies van certificeringen die essentieel zijn voor het uitvoeren van bepaalde bedrijfsactiviteiten.

**CIS Azure Benchmark - App Service Controls** De Center for Internet Security (CIS) Azure Benchmark is een van de meest erkende beveiligingsframeworks voor cloud-omgevingen en bevat specifieke controls voor Azure App Services die TLS-versie-handhaving vereisen. CIS-controls zijn gebaseerd op consensus van beveiligingsexperts wereldwijd en worden gebruikt door duizenden organisaties als basis voor hun cloudbeveiligingspositie. Voor App Services specificeert de CIS Azure Benchmark dat alleen moderne TLS-versies moeten worden toegestaan, waarbij TLS 1.2 als minimum wordt aanbevolen en TLS 1.0 en 1.1 expliciet moeten worden uitgeschakeld. Deze controls zijn onderdeel van de CIS Level 1 en Level 2 benchmarks, waarbij Level 1 de basisvereisten bevat die door alle organisaties moeten worden geïmplementeerd, en Level 2 aanvullende geavanceerde maatregelen bevat. Nederlandse organisaties die werken met overheidscontracten of die willen aantonen dat zij voldoen aan industriebest practices, gebruiken vaak de CIS-benchmarks als basis voor hun beveiligingsbeoordelingen. Het niet naleven van CIS-controls kan leiden tot lagere beveiligingsscores in beoordelingen, wat kan resulteren in het verlies van contracten of het niet kunnen aantonen van due diligence bij beveiligingsincidenten. Voor Azure App Services specifiek controleert CIS regelmatig of de minTlsVersion-eigenschap correct is ingesteld, en organisaties die deze control niet implementeren krijgen automatisch een mislukte status voor deze specifieke control, wat de algehele nalevingsscore negatief beïnvloedt.

**PCI-DSS 4.0 Requirement 4.2** De Payment Card Industry Data Security Standard (PCI-DSS) is een verplicht framework voor alle organisaties die betaalkaartgegevens verwerken, opslaan of verzenden, en versie 4.0 heeft sinds juni 2018 TLS 1.2 of hoger verplicht gesteld voor alle versleutelde communicatie die betrekking heeft op betaalkaartgegevens. Requirement 4.2 specificeert expliciet dat verouderde en onveilige versleutelingsprotocollen zoals TLS 1.0 en TLS 1.1 niet mogen worden gebruikt, en dat organisaties moeten aantonen dat zij alleen moderne versleutelingsstandaarden gebruiken. Voor Nederlandse organisaties die e-commerceplatforms beheren, betaalgateways opereren, of op enige wijze betrokken zijn bij de verwerking van creditcard- of debetkaarttransacties, is PCI-DSS-naleving niet optioneel maar verplicht. Het niet naleven van PCI-DSS-vereisten kan leiden tot mislukte audits door Qualified Security Assessors (QSA's), wat betekent dat de organisatie niet langer betaalkaartgegevens mag verwerken totdat de niet-naleving is opgelost. In ernstige gevallen kan de Payment Card Industry Security Standards Council boetes opleggen, en kunnen creditcardmaatschappijen de verwerkingsrechten van de organisatie intrekken, wat directe bedrijfsimpact heeft omdat de organisatie dan geen betalingen meer kan accepteren. Voor Azure App Services die worden gebruikt voor e-commerce of betalingsverwerking is het daarom absoluut kritiek dat TLS 1.2 als minimum wordt afgedwongen, en organisaties moeten tijdens PCI-DSS-audits kunnen aantonen dat deze configuratie actief is en wordt gemonitord. Dit vereist niet alleen de technische implementatie, maar ook documentatie van de configuratie, monitoringlogboeken die aantonen dat de handhaving actief is, en regelmatige nalevingscontroles die bevestigen dat nieuwe implementaties automatisch nalevend zijn.

**ISO 27001 - A.10.1.1 Cryptographic Controls** ISO 27001 is de internationale standaard voor Information Security Management Systems (ISMS) en wordt wereldwijd gebruikt door organisaties die willen aantonen dat zij een systematische aanpak hebben voor informatiebeveiliging. Control A.10.1.1 specificeert dat organisaties cryptografische controls moeten implementeren die gebaseerd zijn op 'state-of-the-art' technische maatregelen, wat betekent dat verouderde en bekende kwetsbare versleutelingsmethoden niet voldoen aan de vereisten. TLS 1.0 en 1.1 zijn officieel als verouderd en onveilig geclassificeerd door alle grote beveiligingsorganisaties, waaronder NIST, en voldoen daarom niet aan de 'state-of-the-art' vereiste van ISO 27001. Nederlandse organisaties die ISO 27001 gecertificeerd zijn of certificering nastreven, moeten kunnen aantonen dat zij moderne versleutelingsstandaarden gebruiken voor alle versleutelde communicatie, inclusief webapplicaties die worden gehost op Azure App Services. Tijdens ISO 27001-audits zullen auditors controleren of cryptografische controls correct zijn geïmplementeerd en of verouderde protocollen zijn uitgeschakeld. Het niet naleven van A.10.1.1 kan leiden tot non-conformiteiten tijdens audits, wat betekent dat de organisatie moet aantonen hoe zij deze non-conformiteit gaan oplossen binnen een bepaalde tijdsperiode. In ernstige gevallen kan dit leiden tot het verlies van de ISO 27001-certificering, wat kan resulteren in het verlies van contracten met klanten die ISO 27001-certificering als vereiste hebben, en kan de reputatie van de organisatie schaden. Daarnaast vereist ISO 27001 dat organisaties regelmatig hun cryptografische controls beoordelen en bijwerken om ervoor te zorgen dat zij blijven voldoen aan de 'state-of-the-art' vereiste, wat betekent dat organisaties proactief moeten monitoren op nieuwe beveiligingsstandaarden en hun configuraties moeten bijwerken wanneer nieuwe versies beschikbaar komen, zoals de toekomstige migratie naar TLS 1.3 als minimum zodra deze volledig wordt ondersteund.

**NIS2 - Artikel 21 Versleutelingsvereisten** De Network and Information Systems Directive 2 (NIS2) is Europese wetgeving die van toepassing is op Nederlandse organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg, financiële dienstverlening, en digitale infrastructuur. Artikel 21 van NIS2 specificeert dat organisaties passende technische en organisatorische maatregelen moeten nemen om de beveiliging van netwerk- en informatiesystemen te waarborgen, inclusief het gebruik van moderne versleutelingsstandaarden voor gegevens tijdens transport. Hoewel NIS2 niet expliciet TLS 1.2 als minimum vereist, interpreteert de Nederlandse toezichthouder (het Agentschap Telecom) en de Europese cybersecurity-autoriteit (ENISA) 'passende maatregelen' als het gebruik van state-of-the-art versleuteling, wat betekent dat verouderde en bekende kwetsbare protocollen zoals TLS 1.0 en 1.1 niet voldoen aan de vereisten. Nederlandse organisaties die onder NIS2 vallen moeten kunnen aantonen dat zij moderne beveiligingsmaatregelen implementeren, en het gebruik van verouderde TLS-versies kan worden geïnterpreteerd als niet voldoen aan de 'passende maatregelen' vereiste. Het niet naleven van NIS2-vereisten kan leiden tot boetes van maximaal 10 miljoen euro of 2 procent van de wereldwijde jaaromzet, afhankelijk van welke het hoger is, wat significante financiële impact kan hebben. Daarnaast kunnen toezichthouders organisaties verplichten om binnen een bepaalde tijdsperiode naleving te bereiken, en kunnen zij aanvullende maatregelen opleggen zoals verplichte beveiligingsaudits of het aanstellen van een Chief Information Security Officer (CISO). Voor Azure App Services die worden gebruikt door NIS2-plichtige organisaties is het daarom essentieel dat TLS 1.2-handhaving wordt geïmplementeerd en gemonitord, en dat organisaties kunnen aantonen tijdens toezichtsbezoeken dat zij proactief moderne beveiligingsstandaarden gebruiken.

Naast deze primaire nalevingsframeworks zijn er aanvullende overwegingen voor Nederlandse organisaties. De Algemene Verordening Gegevensbescherming (AVG) vereist onder Artikel 32 dat organisaties passende technische maatregelen nemen om persoonsgegevens te beveiligen, en het gebruik van verouderde versleuteling kan worden geïnterpreteerd als niet voldoen aan deze vereiste. De Baseline Informatiebeveiliging Overheid (BIO) bevat specifieke controls voor versleuteling tijdens transport (control 13.01.02) die moderne TLS-versies vereisen. Voor organisaties die werken met geclassificeerde informatie kunnen aanvullende vereisten van toepassing zijn via de Aanwijzingen voor de Versleuteling van Gegevens (AVG) van de Nationaal Coördinator Terrorismebestrijding en Veiligheid (NCTV). Het is daarom essentieel dat organisaties niet alleen de technische implementatie van TLS 1.2-handhaving uitvoeren, maar ook zorgen voor adequate documentatie, monitoring, en audittrails die aantonen dat de maatregel actief is en wordt gehandhaafd. Dit omvat het bijhouden van nalevingsrapporten die de TLS-versies van alle App Services documenteren, het implementeren van geautomatiseerde monitoring die niet-naleving detecteert, en het regelmatig beoordelen van de configuraties om ervoor te zorgen dat nieuwe implementaties automatisch nalevend zijn. Tijdens externe audits moeten organisaties deze documentatie kunnen presenteren om aan te tonen dat zij voldoen aan alle relevante nalevingsvereisten.

Monitoring

Het monitoren van TLS-versieconfiguraties voor Azure App Services is essentieel om te waarborgen dat alle services continu voldoen aan de beveiligingsvereisten en dat nieuwe implementaties automatisch worden gecontroleerd op naleving. Zonder continue monitoring kunnen organisaties onbewust nieuwe App Services implementeren met onveilige TLS-configuraties, of kunnen bestaande configuraties per ongeluk worden gewijzigd door andere teamleden of geautomatiseerde processen. Effectieve monitoring omvat niet alleen het detecteren van niet-nalevende configuraties, maar ook het genereren van rapporten voor management en auditors, het instellen van waarschuwingen voor directe notificatie bij niet-naleving, en het bijhouden van historische nalevingsgegevens om trends te identificeren en compliance-verbeteringen te meten. Voor Nederlandse organisaties die onder nalevingsframeworks vallen zoals ISO 27001, PCI-DSS, NIS2 of BIO, is het kunnen aantonen van continue monitoring en handhaving een verplicht onderdeel van audits, en het ontbreken van adequate monitoring kan leiden tot non-conformiteiten tijdens externe beoordelingen.

**Automatische Nalevingscontroles via PowerShell** De meest efficiënte manier om TLS-versieconfiguraties te monitoren is door gebruik te maken van geautomatiseerde PowerShell-scripts die regelmatig alle App Services in een abonnement of resourcegroep scannen en controleren of de MinTlsVersion-eigenschap correct is ingesteld op 1.2. Deze scripts kunnen worden uitgevoerd als onderdeel van een terugkerende taak via Azure Automation, waardoor continue monitoring wordt gegarandeerd zonder handmatige interventie. Het monitoringproces begint met het verbinden met Azure via Connect-AzAccount, gevolgd door het selecteren van het juiste abonnement. Vervolgens haalt het script alle App Services op met Get-AzWebApp en filtert deze op basis van de MinTlsVersion-eigenschap om niet-nalevende services te identificeren. Voor elke App Service wordt de huidige TLS-configuratie gecontroleerd en vergeleken met de vereiste waarde van 1.2. Services die TLS 1.0 of 1.1 toestaan worden geïdentificeerd als niet-nalevend en worden geregistreerd in een rapport. Het script genereert een gedetailleerd overzicht dat de naam van elke App Service, de resourcegroep, de huidige MinTlsVersion-waarde, en de nalevingsstatus bevat. Dit rapport kan worden geëxporteerd naar verschillende formaten zoals CSV voor verdere analyse, JSON voor geautomatiseerde verwerking, of HTML voor presentatie aan management. Voor organisaties met honderden App Services biedt dit een schaalbare oplossing die binnen enkele minuten een volledig overzicht geeft van de nalevingsstatus van alle services.

**Azure Policy Nalevingsdashboard** Voor organisaties die Azure Policy gebruiken voor TLS-versiehandhaving biedt het ingebouwde Beleidsnalevingsdashboard een realtime overzicht van de nalevingsstatus van alle App Services binnen het beleidsbereik. Dit dashboard toont automatisch het percentage App Services dat voldoet aan de TLS 1.2-vereiste, en identificeert specifieke resources die niet-nalevend zijn. Het dashboard wordt automatisch bijgewerkt wanneer nieuwe App Services worden geïmplementeerd of wanneer bestaande services worden gewijzigd, wat betekent dat organisaties altijd een actueel beeld hebben van hun nalevingsstatus zonder handmatige controles uit te voeren. Het dashboard biedt verschillende weergaven, waaronder een overzicht op abonnementsniveau dat het totale nalevingspercentage toont, en gedetailleerde weergaven per resourcegroep of per individuele App Service. Voor elke niet-nalevende resource toont het dashboard de reden voor niet-naleving, wat helpt bij het identificeren van de oorzaak en het plannen van herstelacties. Het dashboard ondersteunt ook het exporteren van nalevingsrapporten voor auditdoeleinden, en kan worden geïntegreerd met Azure Monitor voor het instellen van waarschuwingen die automatisch worden geactiveerd wanneer het nalevingspercentage onder een bepaalde drempelwaarde daalt. Voor managementrapportages kan het dashboard worden gebruikt om maandelijkse of wekelijkse nalevingsrapporten te genereren die aantonen dat de organisatie proactief beveiligingsvereisten handhaaft.

**Waarschuwingen en Notificaties** Het instellen van geautomatiseerde waarschuwingen is cruciaal om direct op de hoogte te worden gesteld wanneer nieuwe niet-nalevende App Services worden gedetecteerd, zodat herstelacties snel kunnen worden ondernomen voordat beveiligingsrisico's ontstaan. Azure Monitor biedt verschillende mechanismen voor het instellen van waarschuwingen, waaronder e-mailnotificaties, SMS-berichten, webhooks voor integratie met andere systemen zoals Slack of Microsoft Teams, en Azure Logic Apps voor geavanceerde workflow-automatisering. Waarschuwingen kunnen worden geconfigureerd om te worden geactiveerd wanneer Azure Policy niet-naleving detecteert, wanneer PowerShell-monitoringscripts niet-nalevende services identificeren, of wanneer Log Analytics-queries specifieke patronen detecteren die wijzen op configuratiewijzigingen. Voor kritieke omgevingen zoals productie-abonnementen wordt aanbevolen om waarschuwingen in te stellen met een hoge prioriteit die directe notificatie naar het beveiligingsteam verzendt, zodat binnen enkele minuten actie kan worden ondernomen. Voor ontwikkel- of testomgevingen kunnen waarschuwingen worden geconfigureerd met een lagere prioriteit die dagelijkse samenvattingen verzendt in plaats van realtime notificaties. Het is belangrijk om waarschuwingsregels regelmatig te testen om te verifiëren dat notificaties correct worden verzonden en ontvangen, en om ervoor te zorgen dat waarschuwingsvermoeidheid wordt voorkomen door alleen relevante en actievereiste waarschuwingen te verzenden.

**Log Analytics en Historische Analyse** Voor organisaties die gedetailleerde historische analyse en trendmonitoring nodig hebben, biedt Azure Log Analytics uitgebreide mogelijkheden voor het verzamelen, opslaan en analyseren van TLS-configuratiegegevens over langere perioden. Door regelmatig TLS-configuratiegegevens te verzamelen en op te slaan in Log Analytics-workspaces kunnen organisaties trends identificeren, zoals het aantal niet-nalevende services over tijd, de impact van nieuwe implementaties op nalevingspercentages, en de effectiviteit van herstelacties. Log Analytics-queries kunnen worden gebruikt om complexe analyses uit te voeren, zoals het identificeren van resourcegroepen met consistente nalevingsproblemen, het detecteren van patronen in configuratiewijzigingen die leiden tot niet-naleving, of het meten van de tijd tussen detectie en herstel van niet-nalevende configuraties. Deze analyses helpen organisaties om proactief problemen te identificeren voordat ze kritiek worden, en om de effectiviteit van hun beveiligingsprocessen te verbeteren. Voor auditdoeleinden kunnen Log Analytics-rapporten worden gebruikt om aan te tonen dat continue monitoring actief is en dat organisaties proactief reageren op nalevingsproblemen. De retentieperiode voor loggegevens kan worden geconfigureerd volgens organisatievereisten, waarbij veel organisaties kiezen voor minimaal één jaar retentie om te voldoen aan auditvereisten, en sommige organisaties kiezen voor langere retentieperioden voor compliance met specifieke regelgeving.

Gebruik PowerShell-script app-service-tls-12-minimum.ps1 (functie Invoke-Monitoring) – Controleren.

Remediatie

Wanneer monitoring detecteert dat App Services niet voldoen aan de TLS 1.2-minimumvereiste, moeten herstelacties snel worden ondernomen om beveiligingsrisico's te elimineren en naleving te herstellen. Remediatie omvat niet alleen het technisch corrigeren van de TLS-configuratie, maar ook het valideren dat de wijziging correct is toegepast, het documenteren van de herstelactie voor auditdoeleinden, en het analyseren van de oorzaak van de niet-naleving om toekomstige incidenten te voorkomen. Voor organisaties die onder nalevingsframeworks vallen is het belangrijk om te kunnen aantonen dat niet-nalevende configuraties snel worden gedetecteerd en hersteld, en dat er processen zijn om te voorkomen dat vergelijkbare problemen opnieuw optreden. Effectieve remediatie vereist een gestructureerde aanpak die rekening houdt met de omvang van het probleem, de kritiekheid van de betrokken App Services, en de impact op bedrijfsprocessen tijdens het herstelproces.

**Geautomatiseerde Herstel via PowerShell** Voor organisaties met meerdere niet-nalevende App Services biedt geautomatiseerde PowerShell-remediatie de meest efficiënte oplossing die tijd bespaart en consistentie garandeert. Het herstelproces begint met het identificeren van alle niet-nalevende App Services door gebruik te maken van Get-AzWebApp met een Where-Object-filter dat services selecteert waarvan de MinTlsVersion-eigenschap niet gelijk is aan '1.2'. Deze query geeft een volledig overzicht van alle services die aandacht nodig hebben, wat helpt bij het plannen van de herstelactie. Vervolgens kan een foreach-lus worden gebruikt om automatisch alle niet-nalevende services te herstellen door Set-AzWebApp aan te roepen met MinTlsVersion ingesteld op '1.2'. Tijdens het herstelproces wordt voor elke service een bevestigingsmelding gegenereerd die de naam van de service, de resourcegroep, en de oude en nieuwe TLS-versie toont, wat helpt bij het bijhouden van de voortgang. Na het herstel wordt de configuratie gevalideerd door opnieuw Get-AzWebApp uit te voeren en te verifiëren dat alle services nu TLS 1.2 als minimum hebben. Voor grote omgevingen met honderden App Services kan dit proces volledig geautomatiseerd worden via Azure Automation-runbooks die regelmatig worden uitgevoerd om niet-naleving automatisch te detecteren en te herstellen zonder handmatige interventie. Deze geautomatiseerde aanpak zorgt ervoor dat nieuwe implementaties of configuratiewijzigingen die leiden tot niet-naleving snel worden gecorrigeerd, wat de beveiligingspostuur van de organisatie verbetert en nalevingsrisico's minimaliseert.

**Azure Policy Hersteltaken** Voor organisaties die Azure Policy gebruiken voor TLS-versiehandhaving biedt de ingebouwde hersteltaakfunctionaliteit een geautomatiseerde oplossing die niet-nalevende resources automatisch corrigeert zonder handmatige interventie. Hersteltaken kunnen worden geconfigureerd tijdens de beleidstoewijzing door de optie 'Maak een hersteltaak' in te schakelen, wat ervoor zorgt dat wanneer het beleid niet-naleving detecteert, automatisch een hersteltaak wordt gemaakt die de configuratie corrigeert. Deze hersteltaken kunnen worden geconfigureerd om direct uit te voeren wanneer niet-naleving wordt gedetecteerd, of om op een gepland tijdstip te worden uitgevoerd, wat flexibiliteit biedt voor organisaties die herstelacties willen plannen tijdens onderhoudsvensters. Het belangrijkste voordeel van Azure Policy-hersteltaken is dat zij proactief werken - zodra een nieuwe App Service wordt geïmplementeerd met een onveilige TLS-configuratie, detecteert het beleid dit onmiddellijk en wordt automatisch een hersteltaak geactiveerd die de configuratie corrigeert voordat de service in productie wordt gebruikt. Dit voorkomt dat niet-nalevende configuraties überhaupt operationeel worden, wat de beveiligingspostuur aanzienlijk verbetert. Hersteltaken worden ook geregistreerd in het Azure Policy-dashboard, wat een volledige audittrail biedt van alle herstelacties die zijn uitgevoerd, inclusief wanneer de hersteltaak is gemaakt, wanneer deze is uitgevoerd, en of deze succesvol was. Voor auditdoeleinden kunnen deze herstellogboeken worden geëxporteerd en gepresenteerd aan auditors om aan te tonen dat de organisatie proactief niet-naleving detecteert en herstelt.

**Handmatige Herstel voor Kritieke Services** Voor kritieke productieservices waar geautomatiseerd herstel mogelijk risico's met zich meebrengt, of voor services waar aanvullende validatie vereist is voordat configuratiewijzigingen worden toegepast, kan handmatige herstel de voorkeur hebben. Handmatige herstel begint met het identificeren van de specifieke App Service die herstel vereist, gevolgd door het analyseren van de huidige configuratie en het bevestigen van de vereiste wijziging. Vervolgens wordt de wijziging toegepast via de Azure Portal door naar de App Service te navigeren, onder Instellingen naar TLS/SSL-instellingen te gaan, en de Minimum TLS-versie in te stellen op 1.2. Na het toepassen van de wijziging wordt de configuratie gevalideerd door de App Service-URL te bezoeken en te verifiëren dat de verbinding TLS 1.2 of hoger gebruikt via browser Developer Tools. Voor kritieke services wordt aanbevolen om de wijziging eerst te testen in een niet-productieomgeving om te verifiëren dat er geen onverwachte impact is op applicatiefunctionaliteit, hoewel TLS-versiewijzigingen typisch geen impact hebben op applicatiecode. Handmatige herstel biedt meer controle over het proces en maakt het mogelijk om aanvullende validaties uit te voeren, maar is tijdrovender dan geautomatiseerde oplossingen en is daarom alleen geschikt voor specifieke scenario's waar extra voorzichtigheid vereist is.

**Validatie en Verificatie na Herstel** Na het uitvoeren van herstelacties is het essentieel om te valideren dat de wijzigingen correct zijn toegepast en dat alle App Services nu voldoen aan de TLS 1.2-vereiste. Validatie begint met het opnieuw uitvoeren van de monitoringcontrole om te bevestigen dat alle voorheen niet-nalevende services nu correct zijn geconfigureerd. Dit kan worden gedaan door dezelfde PowerShell-scripts of Azure Policy-dashboards te gebruiken die werden gebruikt voor de initiële detectie, wat een directe vergelijking mogelijk maakt tussen de situatie voor en na het herstel. Voor individuele services kan validatie worden uitgevoerd door de App Service-URL te bezoeken en browser Developer Tools te gebruiken om te verifiëren dat de verbinding TLS 1.2 of hoger gebruikt. In het Beveiliging-tabblad van de Developer Tools kan men de TLS-versie van de verbinding zien, wat bevestigt dat de configuratie correct werkt. Als aanvullende validatie kunnen tools zoals OpenSSL worden gebruikt om te proberen verbinding te maken met TLS 1.0 of 1.1 - deze pogingen moeten falen, wat bevestigt dat de configuratie correct is toegepast en dat verouderde protocollen daadwerkelijk worden geblokkeerd. Na succesvolle validatie moeten herstelacties worden gedocumenteerd voor auditdoeleinden, inclusief welke services zijn hersteld, wanneer het herstel is uitgevoerd, en wie verantwoordelijk was voor de herstelactie. Deze documentatie helpt bij het aantonen van proactieve beveiligingshandhaving tijdens externe audits.

**Oorzaakanalyse en Preventie** Na het herstellen van niet-nalevende configuraties is het belangrijk om te analyseren waarom de niet-naleving is opgetreden en maatregelen te nemen om te voorkomen dat vergelijkbare problemen opnieuw optreden. Oorzaakanalyse begint met het identificeren van de bron van de niet-nalevende configuratie - was het een nieuwe implementatie die per ongeluk met onveilige instellingen werd geconfigureerd, een bestaande service waarvan de configuratie werd gewijzigd door een teamlid, of een geautomatiseerd proces zoals Infrastructure as Code-templates die onveilige standaardwaarden gebruiken? Door de oorzaak te identificeren kunnen organisaties gerichte maatregelen nemen om toekomstige incidenten te voorkomen. Als de oorzaak bijvoorbeeld Infrastructure as Code-templates zijn met onveilige standaardwaarden, moeten deze templates worden bijgewerkt om TLS 1.2 als standaardwaarde te gebruiken, en moeten bestaande templates worden gereviewd om te verifiëren dat zij correcte beveiligingsinstellingen bevatten. Als de oorzaak handmatige configuratiewijzigingen zijn door teamleden, moeten processen worden geïmplementeerd zoals verplichte code reviews voor configuratiewijzigingen, of training voor teamleden over beveiligingsvereisten. Als de oorzaak geautomatiseerde implementatieprocessen zijn, moeten deze processen worden bijgewerkt om automatisch TLS 1.2 te configureren voor alle nieuwe App Services. Door proactief oorzaken te analyseren en preventieve maatregelen te implementeren, kunnen organisaties de kans op toekomstige niet-naleving aanzienlijk verminderen en hun algehele beveiligingspostuur verbeteren.

Gebruik PowerShell-script app-service-tls-12-minimum.ps1 (functie Invoke-Remediation) – Herstellen.

Compliance & Frameworks

• CIS M365: Control App Service (L1) - TLS 1.2 minimum
• BIO: 13.01.02 - versleuteling in transit
• ISO 27001:2022: A.10.1.1, A.13.1.1 - Cryptographic controls

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).

Risico zonder implementatie

Management Samenvatting

TLS 1.2 minimum-handhaving blokkeert verouderde en kwetsbare TLS 1.0 en TLS 1.1 protocollen door de minTlsVersion-eigenschap op 1.2 te configureren voor alle Azure App Services. Deze instelling weigert automatisch alle inkomende HTTPS-verbindingen die TLS 1.0 of 1.1 proberen te gebruiken en staat alleen TLS 1.2 en TLS 1.3 toe, wat bescherming biedt tegen POODLE, BEAST, CRIME en protocol downgrade-aanvallen. Alle moderne browsers en clients ondersteunen TLS 1.2: Chrome/Edge/Firefox vanaf 2012, Safari vanaf 2013, iOS 5 en hoger, Android 4.4 en hoger, Windows 7 met updates - alleen zeer oude verouderde systemen zoals Internet Explorer 10 en ouder, Windows XP, Android 4.3 en ouder worden geblokkeerd, wat in 2025 een acceptabele beveiligingsafweging is omdat deze systemen end-of-life zijn en inherent onveilig. Implementatie: configureer via Azure Portal onder TLS/SSL-instellingen → Minimum TLS-versie → 1.2, of gebruik geautomatiseerd PowerShell-script voor bulk-implementatie: Set-AzWebApp -MinTlsVersion '1.2' over alle App Services in abonnement. Deze maatregel is absoluut verplicht voor ALLE productie App Services zonder uitzonderingen, verplicht voor PCI-DSS 4.0-naleving (vereist sinds juni 2018), vereist voor ISO 27001 A.10.1.1, NIS2 Artikel 21, CIS Azure Benchmark, en beschouwd als fundamentele beveiligingsbasislijn door NIST, SANS en alle cloudbeveiligingsframeworks. Implementatie-inspanning: 30 minuten voor handmatige configuratie per app, 1 uur voor geautomatiseerde implementatie over alle App Services met nalevingsmonitoring, geen extra Azure-kosten, geen code-wijzigingen vereist, geen prestatie-impact (TLS 1.2 is efficiënter dan oudere versies). Doorlopende inspanning: nul - eenmaal ingeschakeld blijft TLS 1.2 minimum actief. Return on investment komt van: geëlimineerde cryptografische aanvalsrisico's (POODLE/BEAST/CRIME), PCI-DSS-nalevingsbereiking (verplicht voor betalingsverwerking), geslaagde beveiligingsaudits voor ISO 27001/NIS2, en nul implementatiekosten bij kritieke beveiligingswaarde. Toekomstige upgrade: overweeg TLS 1.3 als minimum zodra Azure-brede ondersteuning volwassen is (momenteel beperkt beschikbaar) voor nog sterkere versleuteling.

• Implementatietijd: 1 uur
• FTE required: 0.01 FTE