Minimum TLS Versie 1.2 Voor Azure Opslagaccounts

TLS 1.0 en TLS 1.1 zijn verouderde protocollen met bekende beveiligingskwetsbaarheden die gegevens tijdens transport kunnen compromitteren. De BEAST-aanval (Browser Exploit Against SSL/TLS) exploiteert zwakheden in de CBC-ciphermodus voor sessiehijacking, waardoor aanvallers versleutelde gegevens kunnen onderscheppen en manipuleren. De POODLE-aanval (Padding Oracle op Downgraded Legacy versleuteling) maakt gebruik van SSL 3.0-downgrades en TLS 1.0-varianten om versleutelde verbindingen te compromitteren. De SWEET32-aanval richt zich op 64-bit blokcijfers zoals 3DES in TLS 1.0, die na voldoende gegevensverzameling kunnen worden gebroken. TLS 1.0 en 1.1 ondersteunen zwakke cijferpakketten zoals RC4, DES en andere cryptografisch gebroken cijfers die niet langer als veilig worden beschouwd. Bovendien ontbreken moderne algoritmen zoals AEAD-cijfers (AES-GCM), SHA-256+-hashing en Perfect Forward Secrecy, die essentieel zijn voor moderne beveiliging. Vanuit complianceperspectief verbiedt PCI-DSS sinds 2018 het gebruik van TLS 1.0/1.1 voor betalingskaartgegevens, NIST heeft deze protocollen afgekeurd, en BIO/ISO 27001 vereisen moderne cryptografie. Opslag met TLS 1.0/1.1 vormt een compliance-overtreding en verhoogt het risico op datalekken aanzienlijk. In de praktijk kunnen TLS-downgrade-aanvallen waarbij een man-in-the-middle-aanvaller een client dwingt TLS 1.0 te gebruiken, gevolgd door BEAST/SWEET32-exploits, leiden tot volledige compromittering van gegevens tijdens transport. Zwakke cijferexploitatie waarbij het RC4-streamcijfer (verboden maar nog ondersteund in TLS 1.0) wordt gebroken, stelt aanvallers in staat versleutelde gegevens te ontsleutelen. TLS 1.2 (2008) en TLS 1.3 (2018) elimineren deze kwetsbaarheden door alleen sterke cijferpakketten toe te staan (AES-128/256-GCM), SHA-256+-hashing te vereisen, Perfect Forward Secrecy verplicht te stellen en alle zwakke legacy-cijfers te verwijderen.

Implementatie

Deze controle configureert de minimumTlsVersion-eigenschap op Azure opslagaccounts en stelt deze in op TLS1_2. Het effect hiervan is dat alle clientverbindingen naar het opslagaccount TLS 1.2 of hoger moeten gebruiken. Verbindingspogingen met TLS 1.0 en TLS 1.1 worden geweigerd met een verbindingsfout. HTTP zonder TLS wordt al geblokkeerd door de 'veilige overdracht vereist'-controle, wat complementair is aan deze maatregel. Moderne clients (vanaf 2015) ondersteunen TLS 1.2 standaard, waardoor compatibiliteitsproblemen minimaal zijn. Configuratiemethoden omvatten de Azure Portal waarbij u navigeert naar het opslagaccount, vervolgens naar Configuratie gaat en de minimum TLS-versie instelt op Versie 1.2. Via PowerShell kan dit worden gedaan met de cmdlet Set-AzStorageAccount met de parameter -minimumTlsVersion TLS1_2. Azure CLI biedt de opdracht az storage account update met de parameter --min-tls-version TLS1_2. Voor geautomatiseerde implementaties kunnen ARM- of Bicep-sjablonen worden gebruikt waarbij de eigenschap properties.minimumTlsVersion wordt ingesteld op 'TLS1_2'. Best practice is om TLS 1.2 als minimum in te stellen bij het aanmaken van het opslagaccount, client TLS-versiegebruik te monitoren via opslaganalyselogboeken om legacy-clients te identificeren voordat de handhaving wordt toegepast, en de impact te testen door te verifiëren dat geen legacy-applicaties TLS 1.0/1.1 gebruiken. Overweeg ook dat Azure Storage TLS 1.3 ondersteunt, waarbij u het minimum instelt op TLS1_2 zodat clients kunnen onderhandelen tot versie 1.3 voor optimale beveiliging.

Vereisten

Voor het implementeren van minimum TLS 1.2 voor Azure opslagaccounts zijn verschillende technische en organisatorische vereisten van toepassing. Deze vereisten zijn essentieel om een succesvolle implementatie te waarborgen en om te voorkomen dat kritieke bedrijfsprocessen worden verstoord door onverwachte compatibiliteitsproblemen.

De primaire technische vereiste is de aanwezigheid van een Azure opslagaccount van elk type, inclusief blobopslag, bestandsopslag, queue-opslag en table-opslag. Alle typen opslagaccounts ondersteunen de configuratie van een minimum TLS-versie, waardoor deze maatregel universeel toepasbaar is binnen Azure Storage-omgevingen. Voor het configureren van de minimum TLS-versie is een Azure-rol met voldoende machtigingen vereist. De minimale vereiste rollen zijn Eigenaar, Inzender of Opslagaccount Inzender. Deze rollen bieden de benodigde machtigingen om opslagaccountconfiguraties te wijzigen, inclusief de minimum TLS-versie-instelling.

Voor geautomatiseerde implementatie en monitoring via PowerShell is PowerShell 5.1 of hoger vereist, samen met de Az.Storage-module. Deze module biedt de cmdlets die nodig zijn voor het configureren en monitoren van TLS-versie-instellingen. Organisaties moeten ervoor zorgen dat de nieuwste versie van de Az.Storage-module is geïnstalleerd om toegang te hebben tot alle beschikbare functionaliteit en om compatibiliteitsproblemen te voorkomen.

Een kritieke vereiste die vaak over het hoofd wordt gezien, is het uitvoeren van een uitgebreide clientcompatibiliteitsbeoordeling voordat de minimum TLS-versie wordt afgedwongen. Organisaties moeten verifiëren dat alle applicaties die toegang hebben tot het opslagaccount TLS 1.2 of hoger ondersteunen. Deze beoordeling moet worden uitgevoerd voor alle systemen die programmatisch of via gebruikersinterfaces toegang hebben tot opslagaccounts, inclusief webapplicaties, backend-services, data-integratietools en desktop-applicaties. Het identificeren van legacy-clients die alleen TLS 1.0 of 1.1 ondersteunen, is essentieel om onverwachte service-onderbrekingen te voorkomen.

Het opstellen van een inventarisatie van legacy-clients die TLS 1.0 of 1.1 gebruiken, vormt een belangrijke voorbereidende stap. Deze inventarisatie moet informatie bevatten over de applicatienaam, de eigenaar of verantwoordelijke, het upgrade-pad naar TLS 1.2-ondersteuning, en de geschatte tijd die nodig is voor de upgrade. Deze informatie is cruciaal voor het plannen van de implementatie en het bepalen van de juiste volgorde waarin opslagaccounts worden bijgewerkt. Voor organisaties met meerdere opslagaccounts kan het raadzaam zijn om te beginnen met accounts die alleen worden gebruikt door moderne applicaties, gevolgd door accounts met gemengde clienttypes.

Het opzetten van een testomgeving waarin de minimum TLS-versie kan worden gevalideerd, is essentieel voor het verifiëren van connectiviteit en het identificeren van potentiële problemen voordat de wijziging in productie wordt doorgevoerd. Deze testomgeving moet representatief zijn voor de productieomgeving en moet alle typen clients bevatten die in productie worden gebruikt. Door uitgebreide tests uit te voeren in een testomgeving kunnen organisaties problemen vroegtijdig identificeren en oplossen zonder impact op productiesystemen.

Het ontwikkelen van een rollback-plan is een belangrijke risicobeperkende maatregel. Hoewel het onwaarschijnlijk is dat een rollback nodig is na een zorgvuldige implementatie, moet er een procedure zijn om tijdelijk terug te keren naar de vorige configuratie indien er onverwachte kritieke bedrijfsimpact optreedt. Dit rollback-plan moet gedocumenteerde stappen bevatten voor het terugdraaien van de minimum TLS-versie-instelling en moet worden getest in de testomgeving om te verifiëren dat het correct werkt.

Veelvoorkomende clients die TLS 1.2 compatibel zijn, omvatten .NET Framework 4.6 en hoger, Java 8 en hoger, Python 2.7.9 en hoger, Windows 7 SP1 en hoger met de juiste updates, Windows Server 2008 R2 en hoger met updates, en moderne browsers vanaf 2015. Voor organisaties die nog steeds legacy-systemen gebruiken die deze versies niet ondersteunen, is het essentieel om upgrade-paden te identificeren en te plannen voordat de minimum TLS-versie wordt afgedwongen. In de meeste gevallen zijn moderne clients standaard compatibel met TLS 1.2, waardoor de impact op de meeste organisaties minimaal zal zijn.

Implementatie

Gebruik PowerShell-script minimum-tls-version-12.ps1 (functie Invoke-Remediation) – PowerShell script voor automatische implementatie van minimum TLS 1.2 voor Azure opslagaccounts.

De implementatie van minimum TLS 1.2 voor Azure opslagaccounts vereist een gestructureerde aanpak die begint met een grondige pre-implementatiebeoordeling. Deze beoordeling is kritiek om te voorkomen dat kritieke bedrijfsprocessen worden verstoord door onverwachte compatibiliteitsproblemen. De eerste stap in dit proces is het inschakelen van opslaganalyselogboekregistratie indien deze nog niet is ingeschakeld. Deze logboekregistratie is essentieel voor het monitoren van TLS-versiegebruik door clients en voor het identificeren van legacy-clients die mogelijk problemen zullen ondervinden wanneer de minimum TLS-versie wordt afgedwongen.

Gedurende een periode van één tot twee weken moeten organisaties het TLS-versiegebruik monitoren door te navigeren naar het opslagaccount in de Azure Portal, vervolgens naar Diagnostische instellingen te gaan en de logboeken in te schakelen. Deze monitoringperiode is essentieel om een accuraat beeld te krijgen van welke clients welke TLS-versies gebruiken. Door de logboeken te analyseren en te filteren op de TLS-versie die door clients wordt gebruikt, kunnen organisaties legacy-clients identificeren die nog steeds TLS 1.0 of 1.1 gebruiken. Voor elke geïdentificeerde legacy-client moet gedetailleerde documentatie worden opgesteld die de applicatienaam, de eigenaar of verantwoordelijke, en het upgrade-pad naar TLS 1.2-ondersteuning bevat. Deze informatie vormt de basis voor het migratieplan dat moet worden uitgevoerd voordat de minimum TLS-versie wordt afgedwongen.

Het migratieplan moet concrete stappen bevatten voor het upgraden van legacy-clients naar TLS 1.2-ondersteuning. Dit kan het upgraden van clientbibliotheken, het installeren van OS-patches, of het bijwerken van applicatiecode omvatten. Alleen nadat alle legacy-clients zijn geüpgraded en getest, moet de minimum TLS-versie worden afgedwongen. Deze gefaseerde aanpak minimaliseert het risico op onverwachte service-onderbrekingen en zorgt ervoor dat alle clients klaar zijn voor de wijziging.

Voor organisaties die de voorkeur geven aan een handmatige implementatie via de Azure Portal, begint het proces met het navigeren naar Azure opslagaccounts in de Azure Portal. Voor elk opslagaccount dat moet worden bijgewerkt, selecteert u het account en navigeert u naar de sectie Configuratie. Onder de optie 'minimum TLS-versie' selecteert u 'Versie 1.2' en klikt u op 'Opslaan'. Het is belangrijk om te begrijpen dat oudere clients die alleen TLS 1.0 of 1.1 ondersteunen onmiddellijk hun connectiviteit zullen verliezen zodra deze wijziging wordt doorgevoerd. Daarom is het essentieel om alle clients te verifiëren door de connectiviteit van clientapplicaties te testen na de implementatie. Deze verificatie moet worden uitgevoerd voor alle applicaties die toegang hebben tot het opslagaccount om te zorgen dat alles correct functioneert.

Voor organisaties met meerdere opslagaccounts is een bulkupdate via PowerShell de aanbevolen aanpak. Deze methode is efficiënter, minder foutgevoelig en kan worden geautomatiseerd voor consistente implementatie. Het proces begint met het verbinden met Azure via Connect-AzAccount. Vervolgens worden alle Azure opslagaccounts opgehaald met de cmdlet Get-AzStorageAccount en opgeslagen in een variabele. Door deze variabele te filteren met Where-Object kunnen niet-conforme accounts worden geïdentificeerd waar de minimumTlsVersion niet is ingesteld op 'TLS1_2'. Deze accounts kunnen vervolgens in bulk worden bijgewerkt met een ForEach-Object-lus die Set-AzStorageAccount aanroept met de juiste parameters. Na de update moet de implementatie worden geverifieerd door opnieuw alle opslagaccounts op te halen en te controleren dat er geen accounts meer zijn met een minimumTlsVersion die niet gelijk is aan 'TLS1_2'.

Na de implementatie van de minimum TLS-versie is uitgebreide verificatie van clientcompatibiliteit essentieel. Alle applicaties die toegang hebben tot het opslagaccount moeten worden getest om te verifiëren dat ze correct functioneren met TLS 1.2. Veelvoorkomende problemen die kunnen optreden, omvatten legacy Windows-systemen met .NET Framework versies ouder dan 4.6, oude Java-versies ouder dan 8, Python-versies ouder dan 2.7.9, en aangepaste applicaties met hardcoded SSL/TLS-instellingen die niet automatisch upgraden naar nieuwere TLS-versies. De oplossing voor deze problemen omvat het upgraden van clientbibliotheken naar versies die TLS 1.2 ondersteunen, het inschakelen van TLS 1.2 in het besturingssysteem of runtime-omgeving, en het bijwerken van applicatiecode om expliciet TLS 1.2 te gebruiken. Voor Windows-systemen kan TLS 1.2 worden ingeschakeld via registerinstellingen, hoewel dit al standaard is ingeschakeld in Windows 10 en Windows Server 2016 en hoger.

Voor langetermijncompliance en het voorkomen van regressie is het sterk aanbevolen om Azure Policy te implementeren voor het afdwingen van de minimum TLS-versie. Het ingebouwde Azure Policy 'Azure opslagaccounts zouden de opgegeven minimum TLS-versie moeten hebben' kan worden gebruikt om ervoor te zorgen dat alle nieuwe opslagaccounts automatisch worden geconfigureerd met de juiste minimum TLS-versie. De beleidsparameters moeten worden ingesteld met minimumTLSVersion gelijk aan TLS1_2. Het beleidseffect kan worden ingesteld op Audit voor monitoringdoeleinden, of op Deny om te voorkomen dat niet-conforme accounts worden aangemaakt. Voor bestaande accounts kan een remediation-taak worden geconfigureerd die automatisch alle niet-conforme accounts bijwerkt naar TLS 1.2. Deze aanpak zorgt ervoor dat compliance wordt gehandhaafd, zelfs wanneer nieuwe opslagaccounts worden aangemaakt door verschillende teamleden of geautomatiseerde processen.

Monitoring

Gebruik PowerShell-script minimum-tls-version-12.ps1 (functie Invoke-Monitoring) – Continue monitoring van minimumTlsVersion compliance voor alle Azure opslagaccounts.

Continue monitoring van de minimum TLS-versieconfiguratie is essentieel om te waarborgen dat compliance wordt gehandhaafd en dat nieuwe opslagaccounts automatisch worden geconfigureerd met de juiste instellingen. Deze monitoring moet worden uitgevoerd op verschillende niveaus en met verschillende frequenties om een volledig beeld te krijgen van de compliance-status binnen de organisatie.

Wekelijks moeten organisaties een PowerShell-audit uitvoeren om de TLS-versiecompliance te verifiëren. Deze audit moet alle opslagaccounts in de organisatie controleren en rapporteren over accounts die niet voldoen aan de vereiste minimum TLS-versie van 1.2. Het PowerShell-script kan worden geautomatiseerd via Azure Automation of een vergelijkbare service om ervoor te zorgen dat de audit consistent wordt uitgevoerd zonder handmatige interventie. De resultaten van deze audit moeten worden gedocumenteerd en gedeeld met de relevante stakeholders om te zorgen dat eventuele afwijkingen snel worden geïdentificeerd en gecorrigeerd.

Het Azure Policy compliance-dashboard biedt een gecentraliseerde weergave van de compliance-status voor alle opslagaccounts binnen het bereik van het beleid. Dit dashboard moet regelmatig worden gemonitord om te verifiëren dat het TLS minimum-versiebeleid correct wordt toegepast en dat alle nieuwe accounts automatisch worden geconfigureerd met de juiste instellingen. Het dashboard toont ook eventuele niet-conforme accounts die handmatige interventie vereisen. Door dit dashboard regelmatig te controleren, kunnen organisaties proactief problemen identificeren voordat ze escaleren tot compliance-overtredingen.

Opslaganalyselogboeken moeten worden gemonitord voor verbindingsfouten die kunnen wijzen op TLS-versieverkeerde matches. Wanneer een client probeert verbinding te maken met een TLS-versie die lager is dan het minimum, zal de verbinding worden geweigerd en wordt dit geregistreerd in de logboeken. Door deze logboeken te analyseren, kunnen organisaties legacy-clients identificeren die nog steeds TLS 1.0 of 1.1 proberen te gebruiken. Deze informatie is waardevol voor het identificeren van systemen die mogelijk zijn gemist tijdens de initiële compatibiliteitsbeoordeling of voor het detecteren van nieuwe systemen die zijn toegevoegd aan de omgeving zonder de juiste TLS-configuratie.

Automatische waarschuwingen moeten worden geconfigureerd voor nieuwe Azure opslagaccounts om ervoor te zorgen dat de TLS-configuratie automatisch wordt gecontroleerd wanneer nieuwe accounts worden aangemaakt. Deze waarschuwingen kunnen worden geïmplementeerd via Azure Policy of via geautomatiseerde scripts die worden getriggerd wanneer nieuwe opslagaccounts worden gedetecteerd. Door deze automatische controle te implementeren, kunnen organisaties ervoor zorgen dat compliance wordt gehandhaafd, zelfs wanneer accounts worden aangemaakt door verschillende teamleden of geautomatiseerde processen die mogelijk niet op de hoogte zijn van de compliance-vereisten.

Continue tracking van client TLS-versiegebruik is essentieel voor het detecteren van onverwachte gebruikspatronen of nieuwe legacy-clients die mogelijk problemen veroorzaken. Deze monitoring moet worden uitgevoerd via opslaganalyselogboeken en moet regelmatig worden geanalyseerd om trends en afwijkingen te identificeren. Wanneer TLS 1.0 of 1.1-gebruik wordt gedetecteerd, moet dit onmiddellijk worden onderzocht om te bepalen of dit een legitieme legacy-client is die nog moet worden geüpgraded, of een indicatie van een beveiligingsprobleem zoals een TLS-downgrade-aanval.

Microsoft Defender voor Cloud-aanbevelingen moeten regelmatig worden gereviewd voor TLS-gerelateerde bevindingen. Defender voor Cloud detecteert automatisch wanneer opslagaccounts niet zijn geconfigureerd met de juiste minimum TLS-versie en genereert aanbevelingen voor het corrigeren van deze problemen. Deze aanbevelingen moeten worden behandeld als hoge prioriteit omdat ze direct verband houden met beveiligings- en compliance-vereisten. Door deze aanbevelingen regelmatig te reviewen en te implementeren, kunnen organisaties ervoor zorgen dat hun opslagaccounts blijven voldoen aan de hoogste beveiligingsstandaarden.

Kwartaalreviews moeten worden uitgevoerd om de clientcompatibiliteit opnieuw te beoordelen en om te overwegen te migreren naar TLS 1.3. Hoewel TLS 1.2 nog steeds als veilig wordt beschouwd, biedt TLS 1.3 verbeterde beveiliging en prestaties. Tijdens deze reviews moeten organisaties evalueren of hun clients klaar zijn voor TLS 1.3 en of er voordelen zijn aan het upgraden van het minimum naar TLS 1.3. Deze reviews moeten ook worden gebruikt om te verifiëren dat alle legacy-clients zijn geüpgraded en dat er geen nieuwe legacy-clients zijn toegevoegd aan de omgeving die mogelijk problemen veroorzaken.

Remediatie

Gebruik PowerShell-script minimum-tls-version-12.ps1 (functie Invoke-Remediation) – Automatische remediatie van niet-conforme Azure opslagaccounts naar minimum TLS 1.2.

Remediatie van Azure opslagaccounts die niet zijn geconfigureerd met minimum TLS 1.2 vereist een gestructureerde aanpak die begint met het identificeren van niet-conforme accounts via monitoring-scripts. Deze scripts moeten regelmatig worden uitgevoerd om alle opslagaccounts in de organisatie te controleren en te rapporteren over accounts die niet voldoen aan de vereiste minimum TLS-versie. Zodra niet-conforme accounts zijn geïdentificeerd, moet de impact worden beoordeeld door de opslaganalyselogboeken te controleren op TLS 1.0 of 1.1-gebruik door clients.

Als er geen TLS 1.0 of 1.1-clients worden gedetecteerd in de logboeken, kan onmiddellijke remediatie worden uitgevoerd door de minimum TLS-versie in te stellen op TLS 1.2. In dit scenario is het risico op service-onderbrekingen minimaal omdat alle clients al TLS 1.2 of hoger ondersteunen. De remediatie kan worden uitgevoerd via PowerShell met de cmdlet Set-AzStorageAccount met de parameter -minimumTlsVersion TLS1_2, of via de Azure Portal door naar de configuratiesectie van het opslagaccount te navigeren en de minimum TLS-versie in te stellen op Versie 1.2.

Als er wel TLS 1.0 of 1.1-clients worden gedetecteerd, moet een meer voorzichtige aanpak worden gevolgd. Eerst moeten de applicaties en eigenaren worden geïdentificeerd die deze legacy-clients gebruiken. Vervolgens moet een upgrade-plan worden ontwikkeld dat concrete stappen bevat voor het upgraden van clientbibliotheken, het installeren van OS-patches, of het bijwerken van applicatiecode om TLS 1.2-ondersteuning te bieden. Dit upgrade-plan moet worden getest in een ontwikkel- of testomgeving om te verifiëren dat de upgrades correct werken en geen onverwachte problemen veroorzaken.

Nadat de upgrades zijn getest, moet een onderhoudsvenster worden gepland voor de implementatie in productie. Tijdens dit onderhoudsvenster moeten de clients worden geüpgraded, de TLS 1.2-connectiviteit worden geverifieerd, en vervolgens moet de minimum TLS-versie worden afgedwongen. Deze gefaseerde aanpak minimaliseert het risico op onverwachte service-onderbrekingen en zorgt ervoor dat alle clients klaar zijn voordat de wijziging wordt doorgevoerd. Na de implementatie moet de omgeving 24 tot 48 uur worden gemonitord voor verbindingsfouten om te verifiëren dat alles correct functioneert.

Voor legacy-clients die TLS 1.2 niet ondersteunen, wat zeer zeldzaam is in 2025, moet een uitgebreide beoordeling worden uitgevoerd. Eerst moet de kritiekheid van de applicatie worden beoordeeld: is de applicatie bedrijfskritiek en kan deze worden vervangen of geüpgraded? Upgrade-opties omvatten het updaten van het besturingssysteem (bijvoorbeeld Windows 7 naar Windows 10, of Windows Server 2008 naar 2019 of hoger), het updaten van de runtime-omgeving (zoals .NET Framework, Java of Python), of het patchen van legacy-systemen om TLS 1.2-ondersteuning in te schakelen.

Als een tijdelijke workaround absoluut noodzakelijk is, kan een dedicated opslagaccount met TLS 1.0 worden geconfigureerd, hoewel dit sterk wordt afgeraden vanwege het beveiligingsrisico. Deze workaround moet worden gedocumenteerd als een uitzondering en moet worden beveiligd met compenserende controles zoals netwerkisolatie, verbeterde monitoring en geplande afschaffing. Risicoacceptatie moet worden goedgekeurd door het beveiligingsteam, moet een vervaldatum hebben, en moet kwartaal worden gereviewd. Op de lange termijn moet applicatiemodernisering worden uitgevoerd om legacy-afhankelijkheden te elimineren en volledige compliance te bereiken.

Compliance en Auditing

Minimum TLS 1.2 is verplicht voor meerdere compliance-frameworks die van toepassing zijn op Nederlandse organisaties, met name in de publieke sector en gereguleerde industrieën. Deze vereiste is essentieel voor het voldoen aan beveiligingsstandaarden en regelgevingsvereisten die zijn opgesteld om gegevens tijdens transport te beschermen tegen onderschepping en manipulatie.

De CIS Azure Foundations Benchmark v3.0.0 controle 3.1 vereist expliciet dat de 'minimum TLS-versie' is ingesteld op 'Versie 1.2' voor Azure opslagaccounts. Deze controle is geclassificeerd als Level 1, wat betekent dat deze wordt aanbevolen voor alle organisaties en als basisvereiste wordt beschouwd. Het niet implementeren van deze controle resulteert in een failed audit finding voor deze controle, wat kan leiden tot compliance-problemen bij klanten of partners die CIS Azure-compliance vereisen.

PCI-DSS v4.0 vereist in Requirement 4.2.1 dat sterke cryptografie wordt gebruikt, met TLS 1.2 als minimum sinds juni 2018. Voor organisaties die betalingskaartgegevens verwerken, is dit een absolute vereiste en het gebruik van TLS 1.0 of 1.1 vormt een directe compliance-overtreding. Sinds de deprecation-deadline van juni 2018 is het gebruik van TLS 1.0 of 1.1 voor betalingskaartgegevens een overtreding die kan leiden tot boetes, opschorting van betalingsverwerking en andere handhavingsmaatregelen.

De Baseline Informatiebeveiliging Overheid (BIO) specificeert in Thema 10.01.01 dat organisaties beleid moeten hebben voor cryptografische maatregelen en het gebruik van moderne, veilige protocollen. Voor Nederlandse overheidsorganisaties is de BIO-baseline verplicht, en het gebruik van verouderde TLS-versies vormt een directe overtreding van deze vereisten. Organisaties moeten kunnen aantonen dat ze moderne cryptografische protocollen gebruiken en dat verouderde protocollen zijn uitgeschakeld.

ISO 27001:2022 controle A.8.24 richt zich op het gebruik van cryptografie en vereist dat alleen sterke versleutelingsprotocollen worden gebruikt. TLS 1.0 en 1.1 worden niet langer als sterk beschouwd en voldoen niet aan deze vereiste. Organisaties die ISO 27001-certificering nastreven of behouden, moeten kunnen aantonen dat ze alleen moderne TLS-versies gebruiken die voldoen aan de vereisten voor sterke cryptografie.

NIST SP 800-52 Rev.2 biedt richtlijnen voor TLS-implementaties en specificeert TLS 1.2 als minimum, met TLS 1.3 als voorkeur. Deze richtlijnen worden algemeen beschouwd als best practices voor cryptografische beveiliging en worden vaak gebruikt als referentie voor compliance-audits. Organisaties die voldoen aan NIST-richtlijnen moeten kunnen aantonen dat ze TLS 1.2 of hoger gebruiken voor alle versleutelde verbindingen.

De NIS2-richtlijn, geïmplementeerd in Nederland via de Wet beveiliging netwerk- en informatiesystemen, vereist in Artikel 21 dat organisaties veilige cryptografische protocollen implementeren voor cybersecurity-risicobeheer. Deze vereiste is met name relevant voor organisaties in kritieke sectoren zoals energie, transport, gezondheidszorg en financiële dienstverlening. Het gebruik van verouderde TLS-versies vormt een directe overtreding van deze vereisten en kan leiden tot handhavingsmaatregelen door de Autoriteit Consument en Markt (ACM).

De Algemene Verordening Gegevensbescherming (AVG), ook wel bekend als GDPR, vereist in Artikel 32 dat organisaties passende technische en organisatorische maatregelen implementeren voor de beveiliging van verwerking, inclusief moderne versleuteling. Voor organisaties die persoonsgegevens verwerken in Azure Storage, betekent dit dat ze moeten kunnen aantonen dat ze moderne versleutelingsprotocollen gebruiken die voldoen aan de vereisten voor gegevensbescherming. Het gebruik van verouderde TLS-versies kan worden beschouwd als een overtreding van deze vereisten en kan leiden tot boetes tot 4 procent van de wereldwijde jaaromzet of 20 miljoen euro.

De HIPAA Security Rule vereist in de Technical Safeguards-sectie dat organisaties versleuteling en ontsleuteling implementeren voor elektronische beschermde gezondheidsinformatie (ePHI). TLS 1.2 of hoger wordt beschouwd als de minimale vereiste voor het voldoen aan deze vereisten. Organisaties in de gezondheidszorg die HIPAA-compliance moeten handhaven, moeten kunnen aantonen dat ze moderne TLS-versies gebruiken voor alle versleutelde verbindingen die ePHI bevatten.

Regelgevingsdeadlines zijn van cruciaal belang voor compliance. De PCI-DSS TLS 1.0/1.1-deprecation was juni 2018, wat betekent dat het gebruik van deze versies nu een directe overtreding is. Organisaties die nog steeds TLS 1.0 of 1.1 gebruiken, lopen het risico op boetes, opschorting van services en andere handhavingsmaatregelen. Het is essentieel dat organisaties proactief zijn in het identificeren en remediëren van niet-conforme configuraties om deze risico's te vermijden.

Compliance & Frameworks

• CIS M365: Control 3.1 (L1) - Zorg ervoor dat 'minimum TLS version' is set to 'Version 1.2'
• BIO: 10.01.01 - Cryptografische maatregelen - Moderne veilige protocols
• ISO 27001:2022: A.8.24 - Use of cryptography - Strong protocol versions
• NIS2: Artikel - veilige cryptographic protocols en versleuteling in transit

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

Stel minimum TLS-versie in op 1.2 voor alle Azure opslagaccounts. Blokkeert kwetsbare TLS 1.0/1.1-protocollen. Vereist voor PCI-DSS, BIO, ISO 27001 en NIST. Voldoet aan CIS 3.1 (L1). Implementatie: 30-60 minuten inclusief clientcompatibiliteitsverificatie. Verplicht voor compliance - geen geldige reden voor TLS 1.0/1.1 in 2025.

• Implementatietijd: 2 uur
• FTE required: 0.02 FTE