Versleuteling van data-at-rest in Azure Database for PostgreSQL Flexible Server

Azure Database for PostgreSQL flexible server versleutelt altijd alle in rust opgeslagen gegevens. Deze gegevens omvatten alle systeem- en gebruikersdatabases, serverlogboeken, write-ahead-logboeksegmenten en back-ups. De onderliggende opslag verwerkt versleuteling via versleuteling aan de serverzijde van Azure Disk Storage.

Versleuteling van data in rust met door de service beheerde sleutels (SMK) of door de klant beheerde sleutels (CMK)

Azure Database for PostgreSQL ondersteunt twee modi voor gegevensversleuteling in ruste: door de service beheerde sleutels (SMK) en door de klant beheerde sleutels (CMK). Gegevensversleuteling met door de service beheerde sleutels is de standaardmodus voor flexibele Azure Database for PostgreSQL-server. In deze modus beheert de service automatisch de versleutelingssleutels die worden gebruikt om uw gegevens te versleutelen. U hoeft geen actie te ondernemen om versleuteling in te schakelen of te beheren in deze modus.

In de door de klant beheerde sleutelsmodus kunt u uw eigen versleutelingssleutel gebruiken om uw gegevens te versleutelen. In deze modus hebt u meer controle over het versleutelingsproces, maar u moet ook zelf de versleutelingssleutels beheren. U moet uw eigen Azure Key Vault of Azure Key Vault Managed Hardware Security Module (HSM) implementeren en configureren om de versleutelingssleutels op te slaan die worden gebruikt door uw flexibele Azure Database for PostgreSQL-server.

U kunt de modus alleen selecteren bij het aanmaken van de server. U kunt de modus niet wijzigen van het ene naar het andere voor de levensduur van de server.

Om uw gegevens te versleutelen, gebruikt Azure Database for PostgreSQL de Azure Storage-versleuteling voor gegevens in rust. Wanneer u CMK gebruikt, bent u verantwoordelijk voor het leveren van sleutels voor het versleutelen en ontsleutelen van gegevens in Blob Storage en Azure Files services. U moet deze sleutels opslaan in Azure Key Vault of Azure Key Vault Managed Hardware Security Module (HSM). Zie door de klant beheerde sleutels voor Azure Storage-versleuteling voor meer informatie.

Voordelen van elke modus (SMK of CMK)

Gegevensversleuteling met door de service beheerde sleutels voor Azure Database for PostgreSQL biedt de volgende voordelen:

• De service beheert automatisch en volledig de toegang tot gegevens.
• De service bepaalt automatisch en volledig de levenscyclus van uw sleutel, inclusief de rotatie van de sleutel.
• U hoeft zich geen zorgen te maken over het beheren van gegevensversleutelingssleutels.
• Gegevensversleuteling op basis van door de service beheerde sleutels heeft geen negatieve invloed op de prestaties van uw workloads.
• Het vereenvoudigt het beheer van versleutelingssleutels (inclusief hun reguliere rotatie) en het beheer van de identiteiten die worden gebruikt voor toegang tot deze sleutels.

Gegevensversleuteling met door de klant beheerde sleutels voor Azure Database for PostgreSQL biedt de volgende voordelen:

• U kunt de toegang tot gegevens volledig beheren. U kunt een sleutel verwijderen om een database ontoegankelijk te maken.
• U bepaalt de levenscyclus van een sleutel, inclusief het rouleren van de sleutel, volledig om af te stemmen op het bedrijfsbeleid.
• U kunt al uw versleutelingssleutels centraal beheren en organiseren in uw eigen exemplaren van Azure Key Vault.
• Gegevensversleuteling op basis van door de klant beheerde sleutels heeft geen negatieve invloed op de prestaties van uw workloads.
• U kunt scheiding van taken tussen beveiligingsmedewerkers, databasebeheerders en systeembeheerders implementeren.

CMK-vereisten

Wanneer u door de klant beheerde versleutelingssleutel gebruikt, neemt u de verantwoordelijkheid op zich. U moet uw eigen Azure Key Vault of Azure Key Vault HSM implementeren. U moet uw eigen sleutel genereren of importeren. U moet vereiste machtigingen verlenen voor de Sleutelkluis, zodat uw flexibele Azure Database for PostgreSQL-server de benodigde acties op de sleutel kan uitvoeren. U moet alle netwerkaspecten van de Azure Key Vault configureren waarin de sleutel wordt bewaard, zodat uw Azure Database for PostgreSQL flexibele server toegang heeft tot de sleutel. Het controleren van de toegang tot de sleutel is ook uw verantwoordelijkheid. Ten slotte bent u verantwoordelijk voor het roteren van de sleutel en, indien nodig, het bijwerken van de configuratie van uw flexibele Azure Database for PostgreSQL-server, zodat deze verwijst naar de gedraaide versie van de sleutel.

Wanneer u door de klant beheerde sleutels voor een opslagaccount configureert, verpakt Azure Storage de HOOFDgegevensversleutelingssleutel (DEK) voor het account met de door de klant beheerde sleutel in de bijbehorende sleutelkluis of beheerde HSM. De beveiliging van de hoofdversleutelingssleutel verandert, maar de gegevens in uw Azure Storage-account blijven altijd versleuteld. Er is geen extra actie vereist om ervoor te zorgen dat uw gegevens versleuteld blijven. Beveiliging door door de klant beheerde sleutels wordt onmiddellijk van kracht.

Azure Key Vault is een extern sleutelbeheersysteem in de cloud. Het is maximaal beschikbaar en biedt schaalbare, veilige opslag voor cryptografische RSA-sleutels, optioneel ondersteund door DOOR FIPS 140 gevalideerde HSM's (Hardware Security Modules). Het biedt geen directe toegang tot een opgeslagen sleutel, maar biedt versleutelings- en ontsleutelingsservices aan geautoriseerde entiteiten. Key Vault kan de sleutel genereren, importeren of ontvangen van een on-premises HSM-apparaat.

In de volgende lijst worden de vereisten beschreven voor het configureren van gegevensversleuteling voor Azure Database for PostgreSQL:

• Voor CMK-configuraties met één tenant moeten Key Vault en uw Azure Database for PostgreSQL flexibele server behoren tot dezelfde Microsoft Entra tenant. Zie voor scenario's voor meerdere tenants door de klant beheerde sleutels voor meerdere tenants. Als u de Key Vault-resource later verplaatst, moet u de gegevensversleuteling opnieuw configureren.
• Stel de configuratie Aantal dagen dat verwijderde kluizen worden bewaard voor Key Vault in op 90 dagen. Als u een bestaand Key Vault exemplaar met een lager getal hebt geconfigureerd, blijft deze geldig. Als u deze instelling echter wilt wijzigen en de waarde wilt verhogen, moet u een nieuw Key Vault exemplaar maken. Zodra een instantie is gemaakt, kunt u deze instelling niet wijzigen.
• Schakel in Key Vault de functie voor voorlopig verwijderen in om gegevensverlies te helpen voorkomen als een sleutel of een Key Vault-exemplaar per ongeluk wordt verwijderd. Key Vault bewaart resources die voorlopig zijn verwijderd 90 dagen, tenzij de gebruiker ze in de tussentijd herstelt of definitief verwijdert. De herstel- en opschoningsacties zijn gekoppeld aan hun eigen machtigingen, via een Key Vault-RBAC-rol of een machtiging in het toegangsbeleid. De zacht verwijderde functie staat standaard aan. Als u een Key Vault hebt die lang geleden is uitgerold, is soft delete mogelijk nog steeds uitgeschakeld. In dat geval kunt u deze inschakelen met behulp van Azure CLI.
• Beveiliging tegen opschonen inschakelen om een verplichte bewaarperiode af te dwingen voor verwijderde kluizen en kluisobjecten.
• Verleen de door de gebruiker toegewezen beheerde identiteit van Azure Database for PostgreSQL Flexible Server toegang tot de sleutel door:
• Voorkeur: configureer Azure Key Vault met RBAC-machtigingsmodel en wijs de beheerde identiteit toe aan de Key Vault cryptoserviceversleutelingsgebruikersrol.
• Verouderd: Als Azure Key Vault is geconfigureerd met het machtigingsmodel voor toegangsbeleid, verleent u de volgende machtigingen aan de beheerde identiteit:
• get: Om de eigenschappen en het openbare deel van de sleutel in Key Vault op te halen.
• list: De in Key Vault opgeslagen sleutels weergeven en doorlopen.
• wrapKey: Om de gegevensversleutelingssleutel te versleutelen.
• unwrapKey: De gegevensversleutelingssleutel ontsleutelen.
• De sleutel die wordt gebruikt voor het versleutelen van de gegevensversleutelingssleutel kan alleen asymmetrisch, RSA of RSA-HSM zijn. Sleutelgrootten van 2048, 3.072 en 4.096 worden ondersteund. Gebruik een 4096-bits sleutel voor betere beveiliging.
• De datum en tijd voor sleutelactivering (indien ingesteld) moeten zich in het verleden bevinden. De datum en tijd voor vervaldatum (indien ingesteld) moeten in de toekomst zijn.
• De sleutel moet de status Ingeschakeld hebben.
• Als u een bestaande sleutel in Key Vault importeert, geeft u deze op in de ondersteunde bestandsindelingen (.pfx, .byokof .backup).

Updates van de CMK-sleutelversie

U kunt CMK configureren voor handmatige sleutelrotatie en updates, of voor automatische sleutelversie-updates na een handmatige of automatische sleutelrotatie in de Key Vault.

Zie Gegevensversleuteling configureren met door de klant beheerde sleutel tijdens het inrichten van de server voor meer informatie.

Belangrijk

Wanneer u de sleutel door een nieuwe versie vervangt, moet u de oude sleutel beschikbaar houden zodat de herversleuteling slaagt. Hoewel de meeste hersleutelingen binnen 30 minuten plaatsvinden, wacht u ten minste 2 uur voordat u de toegang tot de oude sleutelversie uitschakelt.

Handmatige sleutelrotatie en updates

Wanneer u CMK configureert met handmatige sleutelupdates, moet u de sleutelversie handmatig bijwerken in Azure Database for PostgreSQL flexibele server na een handmatige of automatische sleutelrotatie in de Key Vault. De server blijft de oude sleutelversie gebruiken totdat u deze bijwerkt. U richt deze modus in door een sleutel-URI op te geven die de versie GUID in de URI bevat. Bijvoorbeeld: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Tot voor kort was deze optie de enige optie die beschikbaar was.

Wanneer u de sleutel handmatig draait of AKV de sleutel automatisch roteert op basis van het rotatiebeleid, moest u de CMK-eigenschap op uw PostgreSQL-server bijwerken. Deze benadering bleek foutgevoelig te zijn voor de operators of vereist een aangepast script voor het afhandelen van de rotatie, met name bij het gebruik van de functie voor automatische rotatie van Key Vault.

Updates van automatische sleutelversies

Als u automatische updates voor sleutelversies wilt inschakelen, gebruikt u een versieloze sleutel-URI. Deze aanpak elimineert de noodzaak om de versie-eigenschap van de CMK bij te werken op uw PostgreSQL-server na een sleutelrotatie. PostgreSQL haalt automatisch de nieuwe sleutelversie op en versleutelt de gegevensversleutelingssleutel opnieuw. Deze aanpak vereenvoudigt het beheer van de levenscyclus van uw sleutels aanzienlijk, vooral in combinatie met automatische rotatie in Key Vault.

Als u deze methode wilt implementeren met behulp van Azure Resource Manager, Bicep, Terraform, Azure PowerShell of Azure CLI, laat u de versie GUID weg uit uw sleutel-URI.

Schakel in de portal het selectievakje in om de gebruikersinterface te begeleiden bij het onderdrukken van versie-GUID's tijdens interactieve selectie en bij het valideren van de URI.

Aanbevelingen

Wanneer u een door de klant beheerde sleutel gebruikt voor gegevensversleuteling, volgt u deze aanbevelingen om Key Vault te configureren:

• Stel een resourcevergrendeling in op Key Vault om onbedoelde of niet-geautoriseerde verwijdering van deze kritieke resource te voorkomen.
• Schakel controle en rapportage in voor alle versleutelingssleutels. Key Vault biedt logboeken die eenvoudig kunnen worden ingevoerd in andere SIEM-hulpprogramma's (Security Information and Event Management). Azure Monitor-logboeken is een voorbeeld van een service die al is geïntegreerd.
• Vergrendel Key Vault door openbare toegang uitschakelen te selecteren en vertrouwde Microsoft-services toestaan om deze firewall te omzeilen.
• Schakel automatische updates voor sleutelversies in.

Opmerking

Nadat u Openbare toegang uitschakelen hebt geselecteerd en Vertrouwde Microsoft-services toestaan om deze firewall te omzeilen, krijgt u mogelijk een foutmelding die vergelijkbaar is met het volgende wanneer u openbare toegang probeert te gebruiken om Key Vault te beheren via de portal: 'U hebt het netwerktoegangsbeheer ingeschakeld. Alleen toegestane netwerken hebben toegang tot deze sleutelkluis.". Deze fout voorkomt niet dat tijdens het instellen van de door de klant beheerde sleutels sleutels kunnen worden opgegeven of sleutels kunnen worden opgehaald uit Key Vault tijdens serverbewerkingen.

• Bewaar een kopie van de door de klant beheerde sleutel op een veilige plaats of borg deze naar de borgservice.
• Als Key Vault de sleutel genereert, maakt u een sleutelback-up voordat u de sleutel voor de eerste keer gebruikt. U kunt de back-up alleen terugzetten naar Key Vault.

Speciale overwegingen

Onopzettelijke toegang tot sleutels intrekken vanuit Azure Key Vault

Iemand met voldoende toegangsrechten voor Key Vault kan per ongeluk servertoegang tot de sleutel uitschakelen door:

• De RBAC-rol Key Vault Crypto Service Encryption User intrekken of de machtigingen intrekken van de identiteit die wordt gebruikt om de sleutel in Key Vault op te halen.
• De sleutel verwijderen.
• Het Key Vault-exemplaar verwijderen.
• De Key Vault-firewallregels wijzigen.
• De beheerde identiteit van de server in Microsoft Entra-id verwijderen.

De sleutels controleren die in Azure Key Vault worden bewaard

Als u de databasestatus wilt bewaken en waarschuwingen wilt inschakelen voor het verlies van toegang tot de gegevensversleutelingsbeveiliging, configureert u de volgende Azure functies:

• Resourcestatus: Een database die geen toegang meer heeft tot de CMK, wordt weergegeven als Niet toegankelijk nadat de eerste verbinding met de database is geweigerd.
• Activiteitenlogboek: wanneer toegang tot de CMK in het door de klant beheerde Key Vault-exemplaar mislukt, worden vermeldingen toegevoegd aan het activiteitenlogboek. U kunt de toegang opnieuw instellen als u zo snel mogelijk waarschuwingen voor deze gebeurtenissen maakt.
• Actiegroepen: definieer deze groepen om meldingen en waarschuwingen te ontvangen op basis van uw voorkeuren.

Back-ups herstellen van een server die is geconfigureerd met een door de klant beheerde sleutel

Nadat u uw Azure Database for PostgreSQL flexibele server hebt versleuteld met een door de klant beheerde sleutel die is opgeslagen in Key Vault, wordt elke nieuw gemaakte serverkopie ook versleuteld. U kunt deze nieuwe kopie maken met behulp van een point-in-time-herstelbewerking of via leesreplica's.

Wanneer u gegevensversleuteling instelt met een door de klant beheerde sleutel, kunt u tijdens het herstellen van een back-up of het maken van een leesreplica problemen voorkomen door deze stappen uit te voeren op de primaire en herstelde of replicaservers:

• Start het proces voor het herstellen of voor het maken van een leesreplica vanaf de primaire Azure Database for PostgreSQL Flexible Server.
• Op de herstelde of replicaserver kunt u de door de klant beheerde sleutel en de door de gebruiker toegewezen beheerde identiteit wijzigen die wordt gebruikt voor toegang tot Key Vault. Zorg ervoor dat de identiteit die is toegewezen op de zojuist gemaakte server de vereiste machtigingen heeft voor de Sleutelkluis.
• Trek de oorspronkelijke sleutel niet in nadat u deze hebt hersteld. Op dit moment wordt het intrekken van een sleutel niet ondersteund nadat u een server met een door de klant beheerde sleutel hebt teruggezet op een andere server.

Beheerde HSM's

Hardwarebeveiligingsmodules (HSM's) zijn manipulatiebestendige hardwareapparaten die cryptografische processen helpen beveiligen door sleutels te genereren, beveiligen en beheren die worden gebruikt voor het versleutelen van gegevens, het ontsleutelen van gegevens, het maken van digitale handtekeningen en het maken van digitale certificaten. HSM's worden getest, gevalideerd en gecertificeerd volgens de hoogste beveiligingsstandaarden, waaronder FIPS 140 en Algemene criteria.

Azure Key Vault Managed HSM is een volledig beheerde cloudservice met hoge beschikbaarheid, voor één tenant, die voldoet aan standaarden. U kunt deze gebruiken om cryptografische sleutels voor uw cloudtoepassingen te beveiligen via met FIPS 140-3 gevalideerde HSM's.

Wanneer u in de Azure-portal een nieuwe Flexibele server van Azure Database for PostgreSQL maakt met een door de klant beheerde sleutel, kunt u Azure Key Vault Managed HSM kiezen als sleutelopslag, als alternatief voor Azure Key Vault. De vereisten, wat betreft door de gebruiker gedefinieerde identiteit en machtigingen, zijn hetzelfde als met Azure Key Vault (zoals eerder in dit artikel is vermeld). Voor meer informatie over het maken van een beheerd HSM-exemplaar, de voordelen en verschillen van een gedeeld certificaatarchief op basis van Key Vault en het importeren van sleutels in beheerde HSM, raadpleegt u Wat is Beheerde HSM van Azure Key Vault?

Niet-toegankelijke door de klant beheerde sleutelvoorwaarde

Wanneer u gegevensversleuteling configureert met een door de klant beheerde sleutel die is opgeslagen in Key Vault, vereist de server continue toegang tot deze sleutel om online te blijven. Als de server geen toegang meer heeft, wordt de status gewijzigd in Niet-toegankelijk en wordt alle verbindingen geweigerd.

Enkele mogelijke redenen waarom de serverstatus niet toegankelijk is, zijn onder andere:

Oorzaak	Resolutie / Besluit
Een van de versleutelingssleutels waarnaar de server verwijst, heeft een vervaldatum en -tijd geconfigureerd en die datum en tijd worden bereikt.	De vervaldatum van de sleutel verlengen. Wacht vervolgens totdat de sleutel opnieuw wordt gevalideerd en de serverstatus automatisch wordt overgestapt op Gereed. Alleen wanneer de server weer de status Gereed heeft, kunt u de sleutel naar een nieuwere versie draaien of een nieuwe sleutel maken en de server bijwerken zodat deze verwijst naar die nieuwe versie van dezelfde sleutel of naar de nieuwe sleutel.
U draait de sleutel en vergeet het exemplaar van de flexibele Azure Database for PostgreSQL-server bij te werken, zodat deze verwijst naar de nieuwe versie van de sleutel. De oude sleutel, waarnaar de server verwijst, verloopt en verandert de serverstatus in Ontoegankelijk.	Om deze situatie te voorkomen, moet u telkens wanneer u de sleutel draait, ook het exemplaar van uw server bijwerken om naar de nieuwe versie te verwijzen. Gebruik hiervoor az postgres flexible-server updatehet voorbeeld waarin 'Sleutel/identiteit voor gegevensversleuteling wijzigen' wordt beschreven. Gegevensversleuteling kan niet worden ingeschakeld na het maken van de server, waardoor alleen de sleutel/identiteit wordt bijgewerkt.' Als u dit liever bijwerkt met behulp van de API, kunt u het Servers - Update-eindpunt van de service aanroepen.
U verwijdert het Key Vault exemplaar, de Azure Database for PostgreSQL flexibele server heeft geen toegang tot de sleutel en wordt verplaatst naar een niet-toegankelijke status.	Herstel het Key Vault-exemplaar en wacht totdat de service de periodieke hervalidatie van de sleutel uitvoert en de serverstatus automatisch naar Gereed gaat.
U verwijdert, van Microsoft Entra ID, een beheerde identiteit die wordt gebruikt om een van de versleutelingssleutels op te halen die zijn opgeslagen in Key Vault.	Herstel de identiteit en wacht totdat de service de periodieke hervalidatie van de sleutel uitvoert en de status van de server automatisch overschakelen naar Gereed.
Uw Key Vault-machtigingsmodel is geconfigureerd voor het gebruik van op rollen gebaseerd toegangsbeheer. U verwijdert de RBAC-roltoewijzing key vault cryptoserviceversleutelingsgebruiker uit de beheerde identiteiten die zijn geconfigureerd om een van de sleutels op te halen.	Verdeel de RBAC-rol opnieuw aan de beheerde identiteit en wacht totdat de service de periodieke hervalidatie van de sleutel uitvoert en de serverstatus automatisch naar Gereed gaat. Een alternatieve benadering bestaat uit het verlenen van de rol in de Sleutelkluis aan een andere beheerde identiteit en het bijwerken van de server zodat deze andere beheerde identiteit wordt gebruikt voor toegang tot de sleutel.
Uw Key Vault-machtigingsmodel is geconfigureerd voor het gebruik van toegangsbeleid. U trekt het lijst-, krijg-, wikkelSleutel- of ontwikkelSleutel-toegangsbeleid in van de beheerde identiteiten die zijn geconfigureerd om een van de sleutels op te halen.	Verdeel de RBAC-rol opnieuw aan de beheerde identiteit en wacht totdat de service de periodieke hervalidatie van de sleutel uitvoert en de serverstatus automatisch naar Gereed gaat. Een alternatieve benadering bestaat uit het verlenen van het vereiste toegangsbeleid voor de Key Vault aan een andere beheerde identiteit en het bijwerken van de server, zodat deze deze andere beheerde identiteit gebruikt voor toegang tot de sleutel.
U stelt te beperkte Key Vault-firewallregels in, zodat uw flexibele Azure Database for PostgreSQL-server niet kan communiceren met de Key Vault om uw sleutels op te halen.	Wanneer u een Key Vault-firewall configureert, moet u ervoor zorgen dat u de optie selecteert om vertrouwde Microsoft-services toe te staan, zodat uw flexibele Azure Database for PostgreSQL-server de firewall kan omzeilen.

Opmerking

Wanneer een sleutel is uitgeschakeld, verwijderd, verlopen of niet bereikbaar is, wordt een server met gegevens die zijn versleuteld met die sleutel ontoegankelijk, zoals eerder is aangegeven. De serverstatus wordt pas opnieuw gewijzigd in Gereed totdat de versleutelingssleutels opnieuw kunnen worden gevalideerd.

Over het algemeen wordt een server binnen 60 minuten ontoegankelijk nadat een sleutel is uitgeschakeld, verwijderd, verlopen of niet bereikbaar is. Nadat de sleutel beschikbaar is, kan het tot 60 minuten duren voordat de server weer gereed is.

Herstellen na verwijdering van beheerde identiteit

Als u de door de gebruiker toegewezen beheerde identiteit verwijdert die toegang heeft tot de versleutelingssleutel die is opgeslagen in Key Vault in Microsoft Entra ID, voert u de volgende stappen uit om te herstellen:

1. Herstel de identiteit of maak een nieuwe beheerde Entra ID-identiteit.
2. Als u een nieuwe identiteit hebt gemaakt, zelfs als deze dezelfde naam heeft als de verwijderde identiteit, werkt u de Azure Database voor flexibele servereigenschappen bij zodat deze deze nieuwe identiteit moet gebruiken voor toegang tot de versleutelingssleutel.
3. Zorg ervoor dat deze identiteit over de juiste machtigingen beschikt voor bewerkingen op de sleutel in Azure Key Vault (AKV).
4. Wacht ongeveer een uur totdat de server de sleutel opnieuwvalideert.

Belangrijk

Het maken van een nieuwe Entra ID-identiteit met dezelfde naam als de verwijderde identiteit herstelt niet na verwijdering van beheerde identiteiten.

Gebruik gegevensversleuteling met door de klant beheerde sleutels en geo-redundante voorzieningen voor bedrijfscontinuïteit

Azure Database for PostgreSQL ondersteunt geavanceerde functies voor gegevensherstel , zoals replica's en geografisch redundante back-ups. De volgende vereisten zijn van toepassing op het instellen van gegevensversleuteling met CMK's en deze functies, naast de basisvereisten voor gegevensversleuteling met CMK's:

• U moet de geografisch redundante back-upversleutelingssleutel maken in een Key Vault exemplaar dat moet bestaan in de regio waar de geografisch redundante back-up wordt opgeslagen.
• De versie van de Azure Resource Manager REST API voor de ondersteuning van CMK-servers met geo-redundante back-upondersteuning is 2022-11-01-preview. Als u Azure Resource Manager-sjablonen wilt gebruiken om het maken van servers die gebruikmaken van zowel versleuteling met CMK's als geografisch redundante back-upfuncties te automatiseren, gebruikt u deze API-versie.
• U kunt niet dezelfde door de gebruiker beheerde identiteit gebruiken om te verifiëren voor het Key Vault-exemplaar van de primaire database en het Key Vault-exemplaar met de versleutelingssleutel voor geografisch redundante back-up. Als u regionale tolerantie wilt behouden, maakt u de door de gebruiker beheerde identiteit in dezelfde regio als de geografisch redundante back-ups.
• Als u tijdens het maken een leesreplicadatabase instelt die moet worden versleuteld met CMK's, moet de versleutelingssleutel zich in een Key Vault-exemplaar bevinden in de regio waar de leesreplicadatabase zich bevindt. U moet de door de gebruiker toegewezen beheerde identiteit aanmaken om verificatie uit te voeren bij dit Key Vault-exemplaar in dezelfde regio.

Door de klant beheerde sleutels (CMK) voor meerdere tenants (preview)

Met beheerde sleutels voor meerdere tenants kunt u versleutelingssleutels gebruiken die zijn opgeslagen in een Key Vault of beheerde HSM-instantie die deel uitmaakt van een andere Microsoft Entra ID dan uw Azure Database for PostgreSQL flexibele server. Cmk-installatie tussen tenants vereist aanvullende configuratie en coördinatie tussen tenants. In het scenario voor meerdere tenants bevindt de Azure Database for PostgreSQL resource zich in een tenant die wordt beheerd door een onafhankelijke softwareleverancier (ISV) die de serviceprovider wordt genoemd. De sleutel die wordt gebruikt voor versleuteling van de Azure Database for PostgreSQL-resource bevindt zich in een sleutelkluis in een andere tenant die de klant beheert.

Overzicht van de installatie

op de ISV-tenant

• Een multitenant-toepassing maken

  • De door de gebruiker toegewezen beheerde identiteit configureren als een federatieve referentie op de toepassing

op de klant-tenant

1. De multitenant-toepassing installeren

2. Bestaande sleutelkluis of beheerde HSM maken of gebruiken en sleutelmachtigingen verlenen aan de toepassing met meerdere tenants

   1. Een nieuwe maken of een bestaande sleutel gebruiken

   2. Haal de sleutel op uit Azure Key Vault of Azure Managed HSM en noteer de sleutel-id

op de ISV-tenant

Tot nu toe hebt u de multitenant-toepassing geconfigureerd op de tenant van de serviceprovider. U hebt de toepassing ook geïnstalleerd op de tenant van de klant en de sleutelkluis en sleutel op de tenant van de klant geconfigureerd. Vervolgens kunt u een Azure Database for PostgreSQL server maken op de tenant van de serviceprovider en door de klant beheerde sleutels configureren met de sleutel van de tenant van de klant.

Wanneer u een Azure Database for PostgreSQL-server met door de klant beheerde sleutels maakt, moet u ervoor zorgen dat deze toegang heeft tot de sleutels die de klant heeft gebruikt. In scenario's met één tenant geeft u directe sleutelkluis toegang tot de door de gebruiker beheerde identiteit van de Azure Database for PostgreSQL-server. In een scenario voor meerdere tenants kunt u niet langer afhankelijk zijn van directe toegang tot de sleutelkluis, omdat deze zich in een andere tenant bevindt die wordt beheerd door de klant. Deze beperking is waarom u een toepassing voor meerdere tenants hebt gemaakt en een beheerde identiteit in de toepassing hebt geregistreerd om deze toegang te geven tot de sleutelkluis van de klant in de vorige secties. Deze beheerde identiteit, gekoppeld aan de toepassings-id voor meerdere tenants, is wat u gebruikt bij het maken van de CMK tussen tenants voor de Azure Database for PostgreSQL-server.

Wanneer er een nieuwe versie van de sleutel beschikbaar is in de sleutelkluis, wordt de nieuwe versie automatisch opgehaald door de Azure Database for PostgreSQL-server.

Azure-portal gebruiken

Als u door de klant beheerde sleutels voor meerdere tenants wilt configureren voor een nieuwe Azure Database for PostgreSQL-server in de Azure-portal, voert u de volgende stappen uit:

1. Selecteer bij het maken van de Azure Database for PostgreSQL-resource het tabblad Security in het Azure-portal en selecteer vervolgens Customer-managed key.

2. Wijs de door de gebruiker toegewezen beheerde identiteit toe die is gemaakt als Door de gebruiker toegewezen beheerde identiteit.

3. Wijs de toepassing met meerdere tenants toe met behulp van de naam van de toepassing.

4. Voer een sleutel-id in de sleutelselectiemethode in met behulp van de sleutel-id van de klant die is verkregen uit de clienttenant.

JSON-sjablonen en REST API Azure Resource Manager gebruiken

Implementeer een ARM-sjabloon met de volgende specifieke parameters:

Opmerking

Als u dit voorbeeld opnieuw maakt in een van uw Azure Resource Manager-sjablonen, gebruikt u een apiVersion van 2025-03-15-privatepreview of de nieuwere versies.

Parameter	Description	Voorbeeldwaarde
primaryKeyUri	Id van de sleutel, beheerd door de klant, die zich in de sleutelkluis van de serviceprovider bevindt.	https://my-vault.vault.azure.com/keys/my-key
primaryUserAssignedIdentity	Object dat aangeeft dat de beheerde identiteit moet worden toegewezen aan de Azure Database for PostgreSQL flexibele server.	"identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}
primaryFederatedIdentityClientId	Client-id van de Microsoft Entra-toepassing voor meerdere tenants.	application-client-id

Hier volgt een voorbeeld van een REST API met de drie geconfigureerde parameters:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Voorbeeld van aanvraagtekst:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Hier volgt een voorbeeld van een REST API voor sleutelrotatie. In het PATCH-voorbeeld wordt alleen de CMK-sleutel-URI bijgewerkt om de versleutelingssleutel te roteren zonder de server opnieuw te maken.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Hoofdtekst van de aanvraag (voorbeeld van sleutelrotatie):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Belangrijk

Zelfs als u de primaryKeyUri alleen bijwerkt, moet u alle eigenschappen voor gegevensversleuteling opgeven in de aanvraagbody. Als u de primaryFederatedIdentityClientId niet opgeeft in de hoofdtekst van het verzoek, wordt het verzoek behandeld als een niet-tenantoverschrijdende CMK-configuratie.

Beperkingen van de door de klant beheerde sleutels (CMK) voor meerdere tenants

• Azure PowerShell en Azure CLI deze functie nog niet ondersteunen.
• Het maken van een server met geografisch redundante back-ups en het inschakelen van back-upbewerkingen voor langetermijnretentie worden momenteel niet ondersteund.
• De preview wordt momenteel alleen ondersteund in deze regio's:
  • Oostelijke Verenigde Staten 2
  • Westelijke Verenigde Staten 2
  • US Centraal
  • Australia Southeast
  • Australia East
  • North Europe

Beperkingen van door de klant beheerde sleutels (CMK)

Dit zijn de huidige beperkingen voor het configureren van de door de klant beheerde sleutel in een flexibele Azure Database for PostgreSQL-server:

• U kunt door de klant beheerde sleutelversleuteling alleen configureren tijdens het maken van een nieuwe server, niet als een update naar een bestaande Azure Database for PostgreSQL flexibele server. In plaats daarvan kunt u een PITR-back-up herstellen naar een nieuwe server met CMK-versleuteling.
• Nadat u door de klant beheerde sleutelversleuteling hebt geconfigureerd, kunt u niet teruggaan naar de door het systeem beheerde sleutel. Als u wilt terugkeren, moet u de server herstellen naar een nieuwe server met gegevensversleuteling die is geconfigureerd met door het systeem beheerde sleutel.
• Het exemplaar van Azure Key Vault Beheerde HSM of het exemplaar van Azure Key Vault waarop u de versleutelingssleutel wilt opslaan, moet aanwezig zijn in dezelfde regio waarin u de Azure Database voor flexibele server maakt.

Verwante inhoud

• Gegevensversleuteling configureren in Azure Database for PostgreSQL