Delen via

Data-encryptie in rusttoestand in Azure Database voor PostgreSQL

Alle gegevens die worden beheerd door een flexibele Azure Database voor PostgreSQL-serverinstantie, worden altijd bij rust versleuteld. Deze gegevens omvatten alle systeem- en gebruikersdatabases, serverlogboeken, write-ahead logboeksegmenten en back-ups. Versleuteling wordt verwerkt door de onderliggende opslag via versleuteling aan de serverzijde van Azure Disk Storage.

Versleuteling at rest met Service (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 Server-exemplaar van Azure Database for PostgreSQL.

De modus kan alleen worden geselecteerd tijdens het maken van de server. Het kan niet worden gewijzigd van de ene modus naar de andere voor de levensduur van de server.

Azure Database for PostgreSQL maakt gebruik van Azure Storage-versleuteling voor data-at-rest om de versleuteling van uw gegevens te bereiken. Bij het gebruik van CMK is de klant verantwoordelijk voor het leveren van sleutels voor het versleutelen en ontsleutelen van gegevens in Blob Storage- en Azure Files-services. Deze sleutels moeten worden opgeslagen 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

Met de door de klant beheerde versleutelingssleutel neemt u alle verantwoordelijkheid. Daarom moet u uw eigen Azure Key Vault of Azure Key Vault HSM implementeren. U moet uw eigen sleutel genereren of importeren. U moet vereiste machtigingen verlenen in de Sleutelkluis, zodat uw Azure Database for PostgreSQL Flexible Server-instantie de benodigde acties met de sleutel kan uitvoeren. U moet alle netwerkaspecten van de Azure Key Vault configureren waarin de sleutel wordt bewaard, zodat uw flexibele serverexemplaren van Azure Database for PostgreSQL toegang hebben 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 Azure Database for PostgreSQL flexibele serverinstantie, zodat deze naar de gerouleerde versie van de sleutel verwijst.

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.

Hieronder vindt u de lijst met vereisten voor het configureren van gegevensversleuteling voor Azure Database for PostgreSQL:

  • Key Vault en uw exemplaar van flexibele Azure Database for PostgreSQL-server moeten deel uitmaken van dezelfde Microsoft Entra-tenant. Interactie tussen tenantsleutels en servers wordt niet ondersteund. Als u de Key Vault-resource later verplaatst, moet u de gegevensversleuteling opnieuw configureren.
  • We raden u aan de configuratie dagen in te stellen voor het behouden van de configuratie van verwijderde kluizen voor Key Vault op 90 dagen. Als u een bestaand Key Vault-exemplaar met een lager nummer hebt geconfigureerd, moet dit nog steeds geldig zijn. Als u deze instelling echter wilt wijzigen en de waarde wilt verhogen, moet u een nieuw Key Vault-exemplaar maken. Zodra een instantie is aangemaakt, kan deze instelling niet gewijzigd worden.
  • Schakel de functie voorlopig verwijderd in Key Vault in om u te helpen bij het beveiligen tegen gegevensverlies als een sleutel of een Key Vault-exemplaar per ongeluk wordt verwijderd. Key Vault bewaart voorlopig verwijderde resources gedurende 90 dagen, tenzij de gebruiker deze ondertussen herstelt of opschoont. De herstel- en opschoningsacties hebben hun eigen machtigingen gekoppeld aan een Key Vault- of toegangsbeleidsmachtiging. De zacht verwijderde functie staat standaard aan. Als u een sleutelkluis hebt die lang geleden is geïmplementeerd, is voorlopig verwijderen mogelijk nog steeds uitgeschakeld. In dat geval kunt u deze inschakelen met behulp van Azure CLI.
  • Schakel beveiliging tegen opschonen in om een verplichte bewaarperiode af te dwingen voor verwijderde kluizen en kluisobjecten.
  • Geef de door de gebruiker toegewezen beheerde identiteit van de Azure Database for PostgreSQL-serverinstantie toegang tot de sleutel door:
  • Voorkeur: Azure Key Vault moet worden geconfigureerd met het RBAC-machtigingsmodel en de beheerde identiteit moet de rol Crypto Vault-versleutelingsgebruiker voor cryptoserviceversleuteling krijgen toegewezen.
  • 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.
  • lijst: Om de sleutels weer te geven en te herhalen die zijn opgeslagen in Key Vault.
  • 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. We raden u aan een 4096-bits sleutel te gebruiken 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

CMK kan worden geconfigureerd met handmatige sleutelrotatie en updates of met automatische sleutelversie-updates na een handmatige of automatische sleutelrotatie in 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 naar een nieuwe versie draait, moet u de oude sleutel beschikbaar houden om de hercodering te voltooien. Hoewel de meeste hersleutelingen binnen 30 minuten moeten plaatsvinden, raden we u aan minstens 2 uur te wachten 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 het exemplaar van de flexibele Azure Database for PostgreSQL-server na een handmatige of automatische sleutelrotatie in de Sleutelkluis. De server blijft de oude sleutelversie gebruiken totdat u deze bijwerkt. U richt deze modus in door een sleutel-URI op te geven, inclusief de versie GUID in de URI. Bijvoorbeeld: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. Tot voor kort was dit de enige optie die beschikbaar was.

Wanneer u de sleutel handmatig draait of AKV de sleutel automatisch draait op basis van het rotatiebeleid, moest u de CMK-eigenschap bijwerken op uw PostgreSQL-exemplaar. 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 sleutel-URI met een versieloze versie. Dit elimineert de noodzaak om de versie-eigenschap van de CMK in uw PostgreSQL-exemplaar bij te werken na een sleutelrotatie. PostgreSQL haalt automatisch de nieuwe sleutelversie op en versleutelt de gegevensversleutelingssleutel opnieuw. Dit is een enorme vereenvoudiging in het levenscyclusbeheer van uw sleutel, vooral in combinatie met automatische rotatie van Key Vault.

Als u wilt implementeren met ARM, 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.

Recommendations

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

  • Als u onbedoeld of niet-geautoriseerd verwijderen van deze kritieke resource wilt voorkomen, stelt u een resourcevergrendeling in voor Key Vault.
  • 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 foutbericht dat lijkt op 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 herstellen 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 bewaken 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 uw exemplaar van flexibele Azure Database for PostgreSQL-servers is versleuteld met een door de klant beheerde sleutel die is opgeslagen in Key Vault, wordt elke zojuist gemaakte serverkopie ook versleuteld. U kunt deze nieuwe kopie maken via een herstelbewerking naar een bepaald tijdstip of 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:

  • Initieer het herstelproces of het proces voor het maken van een leesreplica van het primaire exemplaar van de flexibele Azure Database for PostgreSQL-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 sleutels niet ondersteund nadat u een server met door de klant beheerde sleutel naar een andere server hebt hersteld.

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.

Beheerde HSM van Azure Key Vault is een volledig beheerde, maximaal beschikbare cloudservice met één tenant, conforme standaarden. U kunt deze gebruiken om cryptografische sleutels voor uw cloudtoepassingen te beveiligen via met FIPS 140-3 gevalideerde HSM's.

Wanneer u nieuwe flexibele Azure Database for PostgreSQL-serverexemplaren maakt in Azure Portal met de door de klant beheerde sleutel, kunt u Azure Key Vault Managed HSM kiezen als sleutelarchief, 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, is continue toegang tot deze sleutel vereist om de server online te houden. Als dat niet het geval is, wordt de status van de server gewijzigd in Ontoegankelijk en wordt alle verbindingen geweigerd.

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

Oorzaak Resolutie / Besluit
Een van de versleutelingssleutels die door de server worden verwezen, had een vervaldatum en -tijd geconfigureerd en die datum en tijd zijn bereikt. U moet de vervaldatum van de sleutel verlengen. Vervolgens moet u wachten totdat de service de sleutel opnieuwvalideren en de serverstatus automatisch naar Gereed zet. Alleen wanneer de server weer de status Gereed heeft, kunt u de sleutel draaien naar een nieuwere versie 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. Hiervoor kunt u het az postgres flexible-server updatevoorbeeld gebruiken waarin 'Sleutel/identiteit wijzigen voor gegevensversleuteling' wordt beschreven. Gegevensversleuteling kan niet worden ingeschakeld na het maken van de server. Hierdoor wordt alleen de sleutel/identiteit bijgewerkt.' Als u deze liever bijwerkt met behulp van de API, kunt u het eindpunt van de service aanroepen - Update-eindpunt van de service.
U verwijdert het Key Vault-exemplaar. Het exemplaar van de flexibele Server van Azure Database for PostgreSQL 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 hebt te beperkte Key Vault-firewallregels ingesteld, zodat uw exemplaar van azure Database for PostgreSQL flexibele 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 serverexemplaren van Azure Database for PostgreSQL de firewall kunnen 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 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 de door de gebruiker toegewezen beheerde identiteit die wordt gebruikt voor toegang tot de versleutelingssleutel die is opgeslagen in Key Vault, wordt verwijderd in Microsoft Entra-id, moet u de volgende stappen uitvoeren 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 exact dezelfde naam heeft als voordat deze werd verwijderd, werkt u de eigenschappen van azure Database voor flexibele serverexemplaren 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.

Gegevensversleuteling gebruiken met door de klant beheerde sleutels en functies voor bedrijfscontinuïteit met geografisch redundante bedrijfscontinuïteit

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

  • De geografisch redundante back-upversleutelingssleutel moet worden gemaakt in een Key Vault-exemplaar dat moet bestaan in de regio waar de geografisch redundante back-up wordt opgeslagen.
  • De REST API-versie van Azure Resource Manager voor het ondersteunen van cmk-servers met geografisch redundante back-ups 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, raden we u aan om de door de gebruiker beheerde identiteit in dezelfde regio te maken 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. De door de gebruiker toegewezen identiteit voor verificatie bij dit Key Vault-exemplaar moet worden gemaakt in dezelfde regio.

Beperkingen

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

Verwante inhoud