Versleuteling aan de clientzijde voor wachtrijen
De Azure Queue Storage-clientbibliotheken voor .NET en Python ondersteunen het versleutelen van gegevens in clienttoepassingen voordat ze naar Azure Storage worden geüpload en gegevens ontsleutelen tijdens het downloaden naar de client. De clientbibliotheken ondersteunen ook integratie met Azure Key Vault voor sleutelbeheer van opslagaccounts.
Belangrijk
Azure Storage ondersteunt zowel versleuteling aan de servicezijde als aan de clientzijde. Voor de meeste scenario's raadt Microsoft aan om versleutelingsfuncties aan de servicezijde te gebruiken voor gebruiksgemak bij het beveiligen van uw gegevens. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie over versleuteling aan de servicezijde.
Over versleuteling aan de clientzijde
De Azure Queue Storage-clientbibliotheek maakt gebruik van AES om gebruikersgegevens te versleutelen. Er zijn twee versies van versleuteling aan de clientzijde beschikbaar in de clientbibliotheek:
- Versie 2 maakt gebruik van de GCM-modus (Galois/Counter Mode) met AES.
- Versie 1 maakt gebruik van de CBC-modus (Cipher Block Chaining) met AES.
Waarschuwing
Het gebruik van versie 1 van versleuteling aan de clientzijde wordt niet meer aanbevolen vanwege een beveiligingsprobleem in de implementatie van de CBC-modus van de clientbibliotheek. Zie Azure Storage voor meer informatie over dit beveiligingsprobleem versleuteling aan de clientzijde bijwerken in SDK om beveiligingsproblemen op te lossen. Als u momenteel versie 1 gebruikt, raden we u aan uw toepassing bij te werken om versie 2 te gebruiken en uw gegevens te migreren. Zie de volgende sectie: Beperk het beveiligingsprobleem in uw toepassingen voor meer informatie.
Het beveiligingsprobleem in uw toepassingen beperken
Vanwege een beveiligingsprobleem dat is gedetecteerd in de implementatie van de CBC-modus van de Queue Storage-clientbibliotheek, raadt Microsoft u aan een of meer van de volgende acties onmiddellijk uit te voeren:
Overweeg het gebruik van versleutelingsfuncties aan de servicezijde in plaats van versleuteling aan de clientzijde. Zie Azure Storage-versleuteling voor data-at-rest voor meer informatie over versleutelingsfuncties aan de servicezijde.
Als u versleuteling aan de clientzijde wilt gebruiken, migreert u uw toepassingen van versleuteling aan de clientzijde v1 naar versleuteling aan de clientzijde v2.
De volgende tabel bevat een overzicht van de stappen die u moet uitvoeren als u ervoor kiest om uw toepassingen te migreren naar versleuteling aan de clientzijde v2:
| Versleutelingsstatus aan clientzijde | Aanbevolen acties |
|---|---|
| De toepassing maakt gebruik van versleuteling aan de clientzijde van een versie van de clientbibliotheek die alleen versleuteling aan clientzijde v1 ondersteunt. | Werk uw toepassing bij om een versie van de clientbibliotheek te gebruiken die ondersteuning biedt voor versleuteling aan de clientzijde v2. Zie sdk-ondersteuningsmatrix voor versleuteling aan de clientzijde voor een lijst met ondersteunde versies. Werk uw code bij voor het gebruik van versleuteling aan de clientzijde v2. |
| De toepassing maakt gebruik van versleuteling aan de clientzijde met een versie van de clientbibliotheek die ondersteuning biedt voor versleuteling aan de clientzijde v2. | Werk uw code bij voor het gebruik van versleuteling aan de clientzijde v2. |
Daarnaast raadt Microsoft u aan de volgende stappen uit te voeren om uw gegevens te beveiligen:
- Configureer uw opslagaccounts voor het gebruik van privé-eindpunten om al het verkeer tussen uw virtuele netwerk (VNet) en uw opslagaccount te beveiligen via een privékoppeling. Zie Privé-eindpunten gebruiken voor Azure Storage voor meer informatie.
- Beperk de netwerktoegang tot alleen specifieke netwerken.
SDK-ondersteuningsmatrix voor versleuteling aan clientzijde
In de volgende tabel ziet u welke versies van de clientbibliotheken voor .NET en Python ondersteuning bieden voor welke versies van versleuteling aan de clientzijde:
| .NET | Python | |
|---|---|---|
| Versleuteling aan clientzijde v2 en v1 | Versies 12.11.0 en hoger | Versies 12.4.0 en hoger |
| Alleen versleuteling aan clientzijde v1 | Versies 12.10.0 en eerder | Versies 12.3.0 en eerder |
Als uw toepassing versleuteling aan de clientzijde gebruikt met een eerdere versie van de .NET- of Python-clientbibliotheek, moet u eerst uw code upgraden naar een versie die versleuteling aan de clientzijde ondersteunt v2. Vervolgens moet u uw gegevens ontsleutelen en opnieuw versleutelen met versleuteling aan de clientzijde v2. Indien nodig kunt u een versie van de clientbibliotheek gebruiken die ondersteuning biedt voor versleuteling aan de clientzijde v2 naast een eerdere versie van de clientbibliotheek terwijl u uw code migreert.
Hoe versleuteling aan de clientzijde werkt
De Azure Queue Storage-clientbibliotheken gebruiken envelopversleuteling om uw gegevens aan de clientzijde te versleutelen en ontsleutelen. Envelopversleuteling versleutelt een sleutel met een of meer extra sleutels.
De Queue Storage-clientbibliotheken zijn afhankelijk van Azure Key Vault om de sleutels te beveiligen die worden gebruikt voor versleuteling aan de clientzijde. Zie Wat is Azure Key Vault? voor meer informatie over Azure Key Vault.
Versleuteling en ontsleuteling via de enveloptechniek
Versleuteling via de enveloptechniek werkt als volgt:
De Azure Storage-clientbibliotheek genereert een CEK (Content Encryption Key), een eenmalige symmetrische sleutel.
Gebruikersgegevens worden versleuteld met behulp van de CEK.
De CEK wordt vervolgens verpakt (versleuteld) met behulp van de versleutelingssleutel voor sleutel (KEK). De KEK wordt geïdentificeerd met een sleutel-id en kan een asymmetrisch sleutelpaar of een symmetrische sleutel zijn. U kunt de KEK lokaal beheren of opslaan in een Azure Key Vault.
De Azure Storage-clientbibliotheek zelf heeft nooit toegang tot KEK. De bibliotheek roept het sleutelterugloop-algoritme aan dat wordt geleverd door Key Vault. Gebruikers kunnen ervoor kiezen om aangepaste providers te gebruiken voor sleutelterugloop/uitpakken, indien gewenst.
De versleutelde gegevens worden vervolgens geüpload naar Azure Queue Storage. De verpakte sleutel samen met enkele extra versleutelingsmetagegevens wordt geïnterpoleerd met de versleutelde gegevens.
Ontsleuteling via de enveloptechniek werkt als volgt:
- In de Azure Storage-clientbibliotheek wordt ervan uitgegaan dat de gebruiker de KEK lokaal of in een Azure Key Vault beheert. De gebruiker hoeft niet te weten welke specifieke sleutel is gebruikt voor versleuteling. In plaats daarvan kan een sleutel-resolver die verschillende sleutel-id's voor sleutels oplost, worden ingesteld en gebruikt.
- De clientbibliotheek downloadt de versleutelde gegevens samen met alle versleutelingsmateriaal dat is opgeslagen in Azure Storage.
- De verpakte CEK) wordt vervolgens uitgepakt (ontsleuteld) met behulp van de KEK. De clientbibliotheek heeft tijdens dit proces geen toegang tot de KEK, maar roept alleen het uitpakkende algoritme van de Azure Key Vault of een ander sleutelarchief aan.
- De clientbibliotheek gebruikt de CEK om de versleutelde gebruikersgegevens te ontsleutelen.
Berichtversleuteling/ontsleuteling
Omdat wachtrijberichten van elke indeling kunnen zijn, definieert de clientbibliotheek een aangepaste indeling met de Initialization Vector (IV) en de versleutelde inhoudsversleutelingssleutel (CEK) in de berichttekst.
Tijdens de versleuteling genereert de clientbibliotheek een willekeurige IV van 16 bytes, samen met een willekeurige CEK van 32 bytes en voert de envelopversleuteling van de tekst van het wachtrijbericht uit met behulp van deze informatie. De verpakte CEK en enkele extra versleutelingsmetagegevens worden vervolgens toegevoegd aan het versleutelde wachtrijbericht. Dit gewijzigde bericht (hieronder weergegeven) wordt opgeslagen in de service.
<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>
Tijdens de ontsleuteling wordt de verpakte sleutel uit het wachtrijbericht geëxtraheerd en uitgepakt. De IV wordt ook uit het wachtrijbericht geëxtraheerd en samen met de uitgepakte sleutel gebruikt om de gegevens van het wachtrijbericht te ontsleutelen. Versleutelingsmetagegevens zijn klein (minder dan 500 bytes), dus hoewel deze telt voor de limiet van 64 kB voor een wachtrijbericht, moet de impact beheerbaar zijn. Het versleutelde bericht is Base64-gecodeerd, zoals wordt weergegeven in het bovenstaande fragment, waarmee ook de grootte van het bericht wordt uitgebreid.
Vanwege de korte levensduur van berichten in de wachtrij, hoeft het ontsleutelen en opnieuw versleutelen van wachtrijberichten na het bijwerken naar versleuteling aan de clientzijde v2 niet nodig te zijn. Eventuele minder veilige berichten worden geroteerd in de loop van het normale gebruik van de wachtrij.
Versleuteling en prestaties aan de clientzijde
Houd er rekening mee dat het versleutelen van uw opslaggegevens leidt tot extra overhead op het gebied van prestaties. Wanneer u versleuteling aan de clientzijde in uw toepassing gebruikt, moet de clientbibliotheek de CEK en IV veilig genereren, de inhoud zelf versleutelen, communiceren met uw gekozen sleutelarchief voor sleutel-enveloppen en extra metagegevens opmaken en uploaden. Deze overhead is afhankelijk van de hoeveelheid gegevens die wordt versleuteld. We raden klanten aan hun toepassingen altijd te testen op prestaties tijdens de ontwikkeling.