Het begrijpen van gegevensversleuteling in Azure opslag

Azure Storage is de ruggengraat van talloze cloud-native toepassingen, data meren, back-up oplossingen en enterprise workloads. Met die centrale rol komt een onmiskenbare verantwoordelijkheid: het beschermen van gegevens waar het zich bevindt. Encryptie is de basis van die bescherming, ervoor te zorgen dat gevoelige informatie vertrouwelijk blijft, zelfs als aanvallers omzeilen netwerkcontroles of fysieke beveiliging. Microsoft Azure biedt een gelaagd encryptie kader dat gegevens zowel in rust als in transit, met opties variërend van volledig beheerde, platform-versleuteling tot klant gecontroleerde sleutel hiërarchieën.

Dit artikel breidt uit op de kern encryptie mogelijkheden binnen Azure Storage, waaronder Azure Blob Storage, Azure Files, Queue Storage, en Table Storage. We lopen door elke encryptie laag, hoe het te configureren, en de beslissingen die belangrijk zijn voor compliance, prestaties en operationele controle.

Versleuteling bij rust

Versleuteling bij rust beschermt gegevens wanneer het wordt geschreven naar fysieke media binnen Azure datacenters. Dit omvat alles van de ruwe schijfblokken die worden gebruikt door virtuele machines tot de opslag van objecten in Blob Storage. Azure implementeert encryptie in rust met behulp van een combinatie van transparante opslag-side encryptie, infrastructuur-level encryptie, en optionele client-side encryptie. De standaard laag .Azure Storage Service Encryptie (SSE) .. werkt automatisch, maar de flexibiliteit om uw eigen sleutels te brengen of host-level encryptie te implementeren geeft architecten de controle die ze nodig hebben voor regelgeving omgevingen.

Versleuteling van de Azure Storage Service (SSE)

SSE is het standaard encryptiemechanisme voor alle nieuwe en bestaande Azure Storage-accounts. Het versleutelt gegevens op de opslagservicelaag voordat het naar de schijf wordt geschreven en decodeert het wanneer het wordt gelezen. Dit proces is volledig transparant voor toepassingen; geen codewijzigingen, geen configuratievlaggen en geen prestatie-tuning zijn vereist. SSE gebruikt [256-bit Advanced Encryption Standard (AES-256)[], een van de sterkste symmetrische encryptie-algoritmen die beschikbaar zijn. De encryptiesleutels worden beheerd door Microsoft en intern op regelmatige basis gedraaid. Omdat SSE standaard is ingeschakeld, is elke opslagaccount inclusief die wordt gemaakt via het Azure portal, CR, of ARM templates, beschermt already gegevens bij rust, tenzij uitdrukkelijk uitgeschakeld, wat niet mogelijk is voor nieuwe accounts.

SSE bestrijkt alle Azure Storage-diensten: Blob Storage (blokblobs, voeg blobs toe, en pagina blobs), Azure Files (inclusief bestandsaandelen), Queue Storage, en Table Storage. Voor Azure Managed Disks, die terug virtuele machine opslag, encryptie wordt afzonderlijk behandeld door Azure Disk Encryption of server-side encryptie (SSE + platform-beheerde sleutels). De kritische takeaway: SSE is een no-configuration veiligheidsnet dat zorgt voor basis encryptie bij rust in de hele Storage service familie.

Versleuteling van infrastructuur

Naast SSE biedt Azure Storage infrastructuurversleuteling, die een tweede laag encryptie op het niveau van de opslaginfrastructuur toevoegt. Terwijl SSE gegevens op de fysieke schijven beschermt, versleutelt infrastructuurversleuteling gegevens opnieuw voordat het wordt geschreven naar de opslagcluster. Dit is met name relevant voor klanten die onderworpen zijn aan strikte nalevingsregelingen die dubbele encryptie op alle opslagmedia vereisen.

Infrastructuur-encryptie is ingeschakeld op het niveau van de opslag account en maakt gebruik van platform-beheerde sleutels. Het vereist geen wijzigingen in toepassingen of client code. De trade-off is een kleine schrijf-doorvoer overhead (typisch verwaarloosbaar voor de meeste workloads) en dat het niet kan worden uitgeschakeld zodra ingeschakeld. Uw organisatie moet beoordelen of een tweede encryptie laag is nodig op basis van interne beleid, regelgeving begeleiding, of contractuele vereisten.

Klantbeheersleutels (CMK)

Voor organisaties die hun eigen encryptiesleutels moeten controleren, of ze moeten voldoen aan de eisen, belangrijke rotatieschema's implementeren of integreren met bestaande sleutelbeheersystemen.Azure Storage ondersteunt Klantenbeheerde sleutels (CMK)[ opgeslagen in Azure Key Vault. Wanneer CMK is ingeschakeld, wordt de root-toets gebruikt om de sleutels van de gegevenscodering in te pakken opgeslagen in uw eigen Key Vault-instance. Dit betekent dat Microsoft de gegevens niet kan decoderen zonder toegang tot uw sleutel, en u kunt de toegang op elk moment intrekken door de sleutel uit te schakelen of te verwijderen.

CMK werkt bovenop SSE. De opslagservice versleutelt nog steeds gegevens met behulp van AES-256, maar de sleutelcoderingssleutel (KEK) die de gegevenscoderingssleutels (DEKs) beschermt wordt door u beheerd. U kunt kiezen tussen een Key Vault-beheerde sleutel[ (software-beschermd of HSM-backed) of een [Key Vault Managed HSM-sleutel[] voor FIPS 140-2 Niveau 3-naleving. Sleutelroulatie kan handmatig of geautomatiseerd worden met behulp van Key Vault.

Belangrijke overwegingen voor CMK:

  • Als u de sleutel in Key Vault uitschakelt of verwijdert, zal Azure Storage geen toegang hebben tot de gegevens. Dit maakt het opslagaccount effectief ontoegankelijk en kan leiden tot permanent verlies van gegevens als niet zorgvuldig beheerd.
  • CMK is beschikbaar voor Blob Storage, Azure Files, Queue Storage, Table Storage, en Azure Data Lake Storage Gen2.
  • CMK ondersteunt Azure Managed Disks niet direct; dat scenario gebruikt server-side encryptie met door de klant beheerde sleutels (SSE + CMK).
  • Het monitoren van belangrijke operaties via Key Vault audit logs en Azure Monitor is essentieel om onbevoegde toegang pogingen of sleutel verlopen te detecteren.

Toetsen met klanten (CPK)

Voor Blob Storage is er een derde sleutel optie genaamd Klant-Gedeelde sleutels (CPK)[. CPK staat een client toe om een encryptiesleutel te leveren op het moment van elk verzoek, in plaats van de sleutel in Key Vault op te slaan. De sleutel wordt gebruikt voor die enkele lees- of schrijfbewerking en wordt niet door Azure bewaard. Dit is handig voor scenario's waar u sleutelbeheer volledig wilt vermijden op het platformniveau.Bij voorbeeld, bij het verwerken van zeer gevoelige gegevens die niet een sleutelkluis kunnen delen met andere workloads. CPK wordt ondersteund voor zowel blokblobs als pagina blobs en werkt met Azure PowerShell, .NET SDK, Java SDK, en REST API-oproepen.

Versleuteling in doorvoer

Encryptie in transit beveiligt gegevens als het beweegt over netwerken, het beschermen van het tegen interceptie, man-in-het-midden aanvallen, en afluisteren. Azure Storage biedt meerdere mechanismen . Van verplichte HTTPS handhaving naar SMB-encryptie voor bestandsaandelen ..om ervoor te zorgen dat gegevens nooit worden verzonden in platte tekst.

HTTPS-handhaving

Alle Azure Storage eindpunten ondersteunen HTTPS (HTTP over TLS 1.2 of hoger). Standaard worden zowel HTTP als HTTPS geaccepteerd, maar beste praktijk is om beveiligde overdracht te versterken op opslagniveau. Deze instelling wijst elk verzoek dat via HTTP wordt gedaan af, waardoor verbindingen worden geblokkeerd van fout geconfigureerde clients of legacy-applicaties die TLS niet ondersteunen. Het inschakelen van veilige overdracht is een één-klik wijziging in het Azure-portaal of kan worden ingesteld via Azure Policy om alle abonnementen af te dwingen.

Bij het bouwen van toepassingen die Azure Storage gebruiken, gebruik altijd het URI-schema in verbindingsstrings. Voor ontwikkeling en testen, zorg ervoor dat er geen HTTP-eindpunten worden gebruikt in productiepijpleidingen. De Azure SDK's dwingen HTTPS standaard af bij het gebruik van verbindingsstrings die het standaard eindpunt achtervoegsel bevatten.

TLS-versievereisten

Azure Storage ondersteunt TLS 1.0, 1.1 en 1.2 van de client kant. Microsoft adviseert echter ten zeerste TLS 1.0 en 1.1 uit te schakelen om aan de moderne beveiligingsstandaarden te voldoen. Te beginnen met de Azure Storage REST API versie 2021-06-08, kunt u een minimum TLS versie[] vereiste instellen op het opslagaccount niveau. Dit is afgedwongen server-kant: elke client die probeert verbinding te maken met een oudere TLS versie ontvangt een 403 Verboden respons.

Om de minimale TLS-versie te configureren:

  • Ga naar de opslagrekening in het Azure portaal.
  • Selecteer Configuratie onder de sectie Beveiliging + netwerk.
  • Stel de Minimum TLS versie in op 1.2.

Deze instelling is van toepassing op alle eindpunten, waaronder Blob, File, Queue en Table storage. Audit voor alle legacy-toepassingen die kunnen vertrouwen op TLS 1.0 of 1.1 voordat de upgrade wordt uitgevoerd.

SMB-versleuteling voor Azure bestanden

Azure Files gebruikt het Server Message Block (SMB) protocol voor bestandsdelen. SMB 3.0 en later omvatten ingebouwde encryptie die gegevens beschermt in doorvoer tussen de client en het bestandsdeel. Wanneer u toegang krijgt tot een Azure bestandsdeel van een ondersteunde client (Windows 8/Server 2012 of later, Linux met CIFS kernel client 4.0+), wordt de verbinding automatisch versleuteld via het netwerk. Azure Files vereist SMB 3.0 of hoger met encryptie voor alle externe verbindingen; eerdere SMB versies worden geblokkeerd.

Voor klanten die online via VPN of ExpressRoute verbinding maken, zorgt SMB-encryptie ervoor dat gegevens die het publieke internet doorkruisen (indien van toepassing) vertrouwelijk blijven. Op interne netwerken van Azure wordt encryptie nog steeds aanbevolen om te beschermen tegen mogelijke laterale bewegingsaanvallen binnen het datacenter.

Privé-eindpunten en service-eindpunten

Terwijl encryptie gegevens beschermt bij doorvoer, zorgt netwerkniveau ervoor dat de blootstelling verder wordt verminderd. [Azure Private Endpoints kent een privé IP-adres toe aan de opslagaccount van uw virtuele netwerk, waardoor de opslagservice effectief in uw VNet komt. Het verkeer tussen uw virtuele netwerk en de opslagaccount reist via het Microsoft backbone netwerk, niet het publieke internet. Zelfs met private eindpunten blijft HTTPS-encryptie actief, waardoor de verdediging diep wordt.

Service-eindpunten bieden een vergelijkbaar voordeel op subnet niveau maar zonder een privé IP. Beide opties integreren naadloos met SSE en encryptie-in-transit instellingen.

Sleutelbeheer en -rotatie

Effectieve encryptie is afhankelijk van sterke sleutelbeheerpraktijken. Zelfs met SSE die gebruik maakt van door platformbeheer beheerde sleutels, behoudt uw organisatie de eigendom van de gegevens en de wettelijke verantwoordelijkheid voor de bescherming ervan. Sleutels moeten periodiek worden gedraaid om de impact van een mogelijk sleutelcompromis te beperken of om te voldoen aan de nalevingsvereisten zoals PCI DSS, HIPAA of SOC 2.

Voor opslagaccounts met CMK wordt rotatie beheerd door middel van Azure Key Vault. U kunt automatische rotatie instellen door een rotatiebeleid in te stellen op de sleutel, bijvoorbeeld elke 90 dagen. Azure Storage pikt de nieuwe sleutelversie op en versleutelt de gegevensversleutelingssleutels opnieuw met de nieuwste sleutel. Er is geen downtime of handmatige interventie nodig. Voor platformbeheerde sleutels (standaard SSE) draait Microsoft de sleutels intern zonder klantzicht.

Auditing sleutelgebruik is eenvoudig met de kenmerkende logs van Key Vault. Exporteer logs naar een log Analytics werkruimte of Azure opslag en stel waarschuwingen in voor operaties zoals , , of . Elk onverwacht sleutel toegangspatroon kan wijzen op een poging tot ongeoorloofde decryptie.

Breng uw eigen sleutel (BYOK) met HSM

Voor organisaties in sterk gereguleerde industrieën biedt Azure Key Vault Managed HSM een FIPS 140-2 Level 3 gevalideerde hardware security module (HSM) om encryptiesleutels op te slaan. U kunt de sleutel on-premises genereren en veilig overbrengen naar de HSM met behulp van een proces genaamd Bring Your Own Key (BYOK). Dit zorgt ervoor dat Microsoft nooit toegang heeft tot het ruwe sleutelmateriaal. BYOK wordt ondersteund voor zowel CMK als CPK scenario's.

Naleving en aanpassing van de regelgeving

Encryptie in Azure Storage kaarten direct aan nalevingseisen over belangrijke kaders. SSE voldoet aan de encryptie-at-rest mandaten in ISO 27001, SOC 2, en FedRAMP Matig. Infrastructuur encryptie sluit aan op de vereisten voor dual-layer encryptie gezien in specifieke federale normen. CMK biedt de sleutel scheiding nodig voor CJIS (Criminal Justice Information Services) en IRS 1075 gegevens, waar de CSP niet onafhankelijke toegang tot decryptie sleutels.

Het is uw verantwoordelijkheid om te controleren of uw gekozen encryptieconfiguratie voldoet aan de specifieke controles binnen uw compliance-scope. Azure verstrekt nalevingsdocumentatie en auditrapporten via de Microsoft Compliance Aanbiedingen pagina. Gebruik Azure Policy om encryptie-instellingen in uw organisatie af te dwingen, zoals het eisen van CMK voor alle opslagaccounts die productiegegevens bevatten of het mandateren van een minimale TLS-versie van 1.2.

Prestatieoverwegingen

Encryptie in Azure Storage introduceert minimale overhead. SSE werkt op het opslagknooppunt niveau en is geoptimaliseerd voor doorvoer. In de meeste benchmarks, de CPU-kosten van AES-256 encryptie is veel lager dan de latentie van het netwerk I/O. Infrastructuur encryptie voegt een kleine schrijf versterkingskosten, maar voor typische workloads (GPv2 opslagaccounts, algemeen-doel blok blobs), de impact is ruim onder 5% voor opeenvolgende workloads. Voor willekeurige I/O of workloads met zeer kleine objecten (onder 4 KB), de overhead kan iets hoger zijn maar nog steeds aanvaardbaar voor productie gebruik.

CMK voegt netwerk latency voor sleutel uitwrapping operaties toe omdat de opslagservice Key Vault moet bellen om de DEK op elke mount of fetch te decoderen. Deze latency is meestal onder 10 ms per call, en het resultaat wordt gecached, zodat volgende verzoeken binnen dezelfde sessie niet de overhead oplopen. Voor de meeste toepassingen, is dit onwaarneembaar.

Samenvatting van beste praktijken

De implementatie van encryptie in Azure Storage vereist planning, maar niet complexiteit. De volgende praktijken zullen u helpen een robuuste encryptie houding te bouwen:

  • Verify SSE is ingeschakeld. Het is standaard ingeschakeld, maar audit bestaande accounts die zijn gemaakt met oudere Azure Storage API versies of beheertools om te garanderen dat geen account is uitgeschakeld encryptie.
  • Schakel veilige handhaving van de overdracht in op elke opslagrekening om alleen HTTPS-communicatie te garanderen.
  • Stel minimaal TLS-versie in op 1.2 over alle productieopslagrekeningen. Test de compatibiliteit van de oude client vóór handhaving.
  • Gebruik door de klant beheerde sleutels voor werklast waarvoor nalevingsvereisten gelden die de essentiële controle of scheiding van taken vereisen.
  • Invoeren van infrastructuurversleuteling als uw compliance-kader expliciet dubbele laag-encryptie vereist.
  • Stemmen regelmatig roterenAutomate rotatie met behulp van het beleid van het sleutel Vault om handmatige fouten te voorkomen.
  • Monitor encryptie-operaties door Azure Monitor en Key Vault-diagnostiek. Stel waarschuwingen in voor belangrijke verwijderingen, uitschakelen of poging tot toegang tot storingen.
  • Gebruik Azure Policy om encryptievereisten af te dwingen, zoals het verplicht stellen van CMK voor bepaalde resource groepen of het blokkeren van HTTP-toegang.
  • Bekijk client-side encryptie voor ultragevoelige gegevens die moeten worden gecodeerd voordat ze Azure Storage bereiken. De Azure Storage client bibliotheken ondersteunen dit, maar het voegt complexiteit toe en moet worden gereserveerd voor uitzonderlijke scenario's.
  • Proef uw noodherstelplan met CMK-sleutels. Als uw Key Vault zich in een andere regio bevindt en niet werkt, kan dan uw opslagaccount nog steeds worden geopend? Gebruik een multiregio-sleutelreplicatie of een back-up Key Vault.

Door het gelaagd maken van encryptie in rust, encryptie in transit, en een sterk sleutelbeheer, kunt u een beveiligingshouding bereiken die voldoet aan de eisen van de moderne naleving van de onderneming zonder dat de prestaties of operationele eenvoud worden opgeofferd. Voor meer details, verwijzen naar de Azure Storage Service Encryptie documentatie en de Beveiligde Transfer gids over Microsoft Learn.