Datakryptering med en kundhanterad nyckel i Azure Database for PostgreSQL – flexibel server

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Azure Database for PostgreSQL – flexibel server använder Azure Storage-kryptering för att kryptera vilande data som standard med hjälp av Microsoft-hanterade nycklar. För användare av en flexibel Azure Database for PostgreSQL-server liknar den transparent datakryptering i andra databaser, till exempel SQL Server.

Många organisationer behöver fullständig kontroll över åtkomsten till data med hjälp av en kundhanterad nyckel (CMK). Med datakryptering med CMK:er för Azure Database for PostgreSQL – flexibel server kan du ta med din nyckel (BYOK) för dataskydd i vila. Det gör det även möjligt för organisationer att implementera ansvarsfördelning vad gäller hanteringen av nycklar och data. Med CMK-kryptering ansvarar du för och har fullständig kontroll över en nyckels livscykel, behörigheter för nyckelanvändning och granskning av åtgärder på nycklar.

Datakryptering med CMK:er för Azure Database for PostgreSQL – flexibel server anges på servernivå. För en viss server används en typ av CMK som kallas nyckelkrypteringsnyckel (KEK) för att kryptera tjänstens datakrypteringsnyckel (DEK). KEK är en asymmetrisk nyckel som lagras i en kundägd och kundhanterad Azure Key Vault-instans . KEK och DEK beskrivs mer detaljerat senare i den här artikeln.

Key Vault är ett molnbaserat, externt nyckelhanteringssystem. Den har hög tillgänglighet och ger skalbar och säker lagring för RSA-kryptografiska nycklar, som eventuellt backas upp av FIPS 140-verifierade maskinvarusäkerhetsmoduler (HSM). Den tillåter inte direkt åtkomst till en lagrad nyckel, men tillhandahåller krypterings- och dekrypteringstjänster till auktoriserade entiteter. Key Vault kan generera nyckeln, importera den eller överföra den från en lokal HSM-enhet.

Förmåner

Datakryptering med CMK:er för flexibel Azure Database for PostgreSQL-server ger följande fördelar:

• Du har fullständig kontroll över dataåtkomsten. Du kan ta bort en nyckel för att göra en databas otillgänglig.

• Du styr helt en nyckels livscykel, inklusive rotation av nyckeln för att anpassa till företagets principer.

• Du kan hantera och organisera nycklar centralt i Key Vault.

• Att aktivera kryptering påverkar inte prestanda med eller utan CMK:er, eftersom PostgreSQL förlitar sig på Azure Storage-lagret för datakryptering i båda scenarierna. Den enda skillnaden är att när du använder en CMK krypteras Azure Storage-krypteringsnyckeln (som utför faktisk datakryptering).

• Du kan implementera en uppdelning av uppgifter mellan säkerhetsansvariga, databasadministratörer och systemadministratörer.

Terminologi

Datakrypteringsnyckel (DEK): En symmetrisk AES 256-nyckel som används för att kryptera en partition eller ett datablock. Kryptering av varje datablock med en annan nyckel gör kryptanalysattacker svårare. Resursprovidern eller programinstansen som krypterar och dekrypterar ett visst block behöver åtkomst till DEK:er. När du ersätter en DEK med en ny nyckel måste endast data i dess associerade block omkrypteras med den nya nyckeln.

Nyckelkrypteringsnyckel (KEK): En krypteringsnyckel som används för att kryptera DEK:erna. En KEK som aldrig lämnar Key Vault gör att DEK:erna själva kan krypteras och kontrolleras. Entiteten som har åtkomst till KEK kan skilja sig från den entitet som kräver DEK:erna. Eftersom KEK krävs för att dekryptera DEK:erna är KEK i själva verket en enda punkt där du kan ta bort DEK:er (genom att ta bort KEK).

DEK:erna, krypterade med en KEK, lagras separat. Endast en entitet som har åtkomst till KEK kan dekryptera dessa DEK:er. Mer information finns i Säkerhet i kryptering i vila.

Så här fungerar datakryptering med en CMK

En microsoft entra-användartilldelad hanterad identitet används för att ansluta och hämta en CMK. Följ den här självstudien om du vill skapa en identitet.

För att en PostgreSQL-server ska använda CMK:er som lagras i Key Vault för kryptering av DEK ger en Key Vault-administratör följande åtkomsträttigheter till den hanterade identitet som du skapade:

• get: För att hämta den offentliga delen och egenskaperna för nyckeln i Key Vault.

• list: För att lista och iterera via nycklar i Key Vault.

• wrapKey: För kryptering av DEK. Den krypterade DEK:en lagras i Azure Database for PostgreSQL.

• unwrapKey: För dekryptering av DEK. Azure Database for PostgreSQL behöver den dekrypterade DEK:en för att kryptera och dekryptera data.

Key Vault-administratören kan också aktivera loggning av Key Vault-granskningshändelser, så att de kan granskas senare.

Alternativt till tilldelning av åtkomsträttigheter , som beskrivs ovan, kan du skapa en ny Azure RBAC-rolltilldelning med rollen Key Vault Crypto Service Encryption User.

Viktigt!

Om du inte anger de föregående åtkomsträttigheterna eller RBAC-tilldelningen till en hanterad identitet för åtkomst till Key Vault kan det leda till att det inte går att hämta en krypteringsnyckel och att det inte går att konfigurera CMK-funktionen.

När du konfigurerar servern för att använda CMK:t som lagras i Key Vault skickar servern DEK till Key Vault för kryptering. Key Vault returnerar den krypterade DEK som lagras i användardatabasen. Vid behov skickar servern den skyddade DEK:en till Key Vault för dekryptering. Granskare kan använda Azure Monitor för att granska Key Vault-granskningshändelseloggar om loggningen är aktiverad.

Krav för att konfigurera datakryptering för flexibel Azure Database for PostgreSQL-server

Här följer krav för att konfigurera Key Vault:

• Key Vault och Azure Database for PostgreSQL – flexibel server måste tillhöra samma Microsoft Entra-klientorganisation. Nyckelvalv och serverinteraktioner mellan klientorganisationer stöds inte. Om du flyttar Key Vault-resursen efteråt måste du konfigurera om datakryptering.

• Inställningen Dagar för att behålla borttagna valv för Key Vault måste vara 90. Om du har konfigurerat den befintliga Key Vault-instansen med ett lägre tal måste du skapa en ny Key Vault-instans eftersom du inte kan ändra en instans när du har skapat den.

• Vi rekommenderar att du anger Dagar för att behålla konfigurationen av borttagna valv för Key Vault till 90 dagar. Om du har konfigurerat en befintlig Key Vault-instans med ett lägre tal bör den fortfarande vara giltig. Men om du vill ändra den här inställningen och öka värdet är det nödvändigt att skapa en ny Key Vault-instans. När en instans har skapats går det inte att ändra dess konfiguration.

• Aktivera funktionen för mjuk borttagning i Key Vault för att skydda mot dataförlust om en nyckel eller en Key Vault-instans tas bort av misstag. Key Vault behåller mjukt borttagna resurser i 90 dagar om inte användaren återställer eller rensar dem under tiden. Åtgärderna för återställning och rensning har sina egna behörigheter som är associerade med en Key Vault-åtkomstprincip.

  Funktionen för mjuk borttagning är inaktiverad som standard, men du kan aktivera den via PowerShell eller Azure CLI. Du kan inte aktivera den via Azure-portalen.

• Aktivera rensningsskydd för att framtvinga en obligatorisk kvarhållningsperiod för borttagna valv och valvobjekt.

• Ge Azure Database for PostgreSQL flexibel serverinstans åtkomst till Key Vault med behörigheterna get, list, wrapKey och unwrapKey med hjälp av dess unika hanterade identitet. Du kan också skapa en ny Azure RBAC-rolltilldelning med rollen Key Vault Crypto Service Encryption User för den hanterade identiteten.

Här följer krav för att konfigurera CMK i Azure Database for PostgreSQL – flexibel server:

• DEN CMK som ska användas för kryptering av DEK kan endast vara asymmetrisk, RSA eller RSA-HSM. Nyckelstorlekar på 2 048, 3 072 och 4 096 stöds.

• Datum och tid för nyckelaktivering (om det anges) måste vara tidigare. Datum och tid för förfallodatum (om det anges) måste vara i framtiden.

• Nyckeln måste vara i tillståndet *Enabled- .

• Om du importerar en befintlig nyckel till Key Vault anger du den i de filformat som stöds (.pfx, .byokeller .backup).

Rekommendationer

Här är rekommendationer för att konfigurera Key Vault när du använder en CMK för datakryptering:

• Ange ett resurslås på Key Vault för att styra vem som kan ta bort den här kritiska resursen och förhindra oavsiktlig eller obehörig borttagning.

• Aktivera granskning och rapportering av alla krypteringsnycklar. Key Vault innehåller loggar som är enkla att mata in i andra SIEM-verktyg (säkerhetsinformation och händelsehantering). Azure Monitor-loggar är ett exempel på en tjänst som redan är integrerad.

• Lås Key Vault genom att välja Inaktivera offentlig åtkomst och Tillåt betrodda Microsoft usluge att kringgå brandväggen.

  

Kommentar

När du har valt Inaktivera offentlig åtkomst och Tillåt betrodda Microsoft usluge kringgå den här brandväggen kan du få ett fel som liknar följande när du försöker använda offentlig åtkomst för att administrera Key Vault via portalen: "Du har aktiverat nätverksåtkomstkontrollen. Endast tillåtna nätverk har åtkomst till det här nyckelvalvet." Det här felet utesluter inte möjligheten att ange nycklar under CMK-installationen eller hämta nycklar från Key Vault under serveråtgärder.

Här följer rekommendationer för att konfigurera en CMK:

• Behåll en kopia av CMK på en säker plats eller desläpa den till depositionstjänsten.

• Om Key Vault genererar nyckeln skapar du en nyckelsäkerhetskopia innan du använder nyckeln för första gången. Du kan bara återställa säkerhetskopian till Key Vault.

Återkallande av oavsiktlig nyckelåtkomst från Key Vault

Någon med tillräcklig åtkomstbehörighet till Key Vault kan av misstag inaktivera serveråtkomst till nyckeln genom att:

• Återkalla listan, hämta, wrapKey- och unwrapKey-behörigheter från den identitet som används för att hämta nyckeln i Key Vault.

• Tar bort nyckeln.

• Tar bort Key Vault-instansen.

• Ändra Key Vault-brandväggsreglerna.

• Ta bort serverns hanterade identitet i Microsoft Entra-ID.

Övervaka CMK:en i Key Vault

Om du vill övervaka databastillståndet och aktivera aviseringar för förlust av åtkomst till det transparenta datakrypteringsskyddet konfigurerar du följande Azure-funktioner:

• Resurshälsa: En databas som förlorade åtkomsten till CMK visas som otillgänglig efter att den första anslutningen till databasen har nekats.
• Aktivitetslogg: När åtkomsten till CMK i den kundhanterade Key Vault-instansen misslyckas läggs poster till i aktivitetsloggen. Du kan återställa åtkomsten om du skapar aviseringar för dessa händelser så snart som möjligt.
• Åtgärdsgrupper: Definiera dessa grupper för att ta emot meddelanden och aviseringar baserat på dina inställningar.

Återställa med en kunds hanterade nyckel i Key Vault

När Azure Database for PostgreSQL– flexibel server har krypterats med en kunds hanterade nyckel lagrad i Key Vault krypteras även alla nyligen skapade serverkopior. Du kan göra den här nya kopian via en återställning till tidpunkt (PITR) eller läsa repliker.

När du konfigurerar kundhanterad datakryptering vid återställning eller skapande av en läsreplik kan du undvika problem genom att följa dessa steg på de primära och återställde servrarna/replikservrarna:

• Initiera återställningsprocessen eller processen för att skapa en läsreplik från den primära azure database for PostgreSQL-instansen för flexibel server.

• På den återställda servern eller replikservern kan du ändra CMK och/eller Den Microsoft Entra-identitet som används för att komma åt Key Vault i inställningarna för datakryptering. Kontrollera att den nyligen skapade servern har list-, wrap- och unwrap-behörigheter till nyckeln som lagras i Key Vault.

• Återkalla inte den ursprungliga nyckeln efter återställningen. För närvarande stöder vi inte återkallning av nycklar när du har återställt en CMK-aktiverad server till en annan server.

Hanterade HSM:er

Maskinvarusäkerhetsmoduler (HSM: er) är manipulationsresistenta maskinvaruenheter som hjälper till att skydda kryptografiska processer genom att generera, skydda och hantera nycklar som används för att kryptera data, dekryptera data, skapa digitala signaturer och skapa digitala certifikat. HSM:er testas, verifieras och certifieras enligt de högsta säkerhetsstandarderna, inklusive FIPS 140 och Vanliga kriterier.

Azure Key Vault Managed HSM är en fullständigt hanterad, högtillgänglig molntjänst med enkel klientorganisation som är standardkompatibel. Du kan använda den för att skydda kryptografiska nycklar för dina molnprogram via FIPS 140-3-verifierade HSM:er.

När du skapar nya flexibla Azure Database for PostgreSQL-serverinstanser i Azure-portalen med CMK-funktionen kan du välja Azure Key Vault Managed HSM som ett nyckelarkiv som ett alternativ till Azure Key Vault. Förutsättningarna för användardefinierad identitet och behörighet är desamma som med Azure Key Vault (som vi nämnde tidigare i den här artikeln). Mer information om hur du skapar en hanterad HSM-instans, dess fördelar och skillnader från ett delat Key Vault-baserat certifikatarkiv och hur du importerar nycklar till Managed HSM finns i Vad är Azure Key Vault Managed HSM?.

Otillgängligt CMK-villkor

När du konfigurerar datakryptering med en CMK i Key Vault krävs kontinuerlig åtkomst till den här nyckeln för att servern ska vara online. Om servern förlorar åtkomsten till CMK i Key Vault börjar servern neka alla anslutningar inom 10 minuter. Servern utfärdar ett motsvarande felmeddelande och ändrar servertillståndet till Otillgängligt.

Några av orsakerna till att servertillståndet blir otillgängligt är:

• Om du tar bort Key Vault-instansen kan azure Database for PostgreSQL flexibel serverinstans inte komma åt nyckeln och flyttas till ett otillgängligt tillstånd. Om du vill göra servern tillgänglig återställer du Key Vault-instansen och återanvänder datakryptering.
• Om du tar bort nyckeln från Key Vault kan azure Database for PostgreSQL flexibel serverinstans inte komma åt nyckeln och flyttas till ett otillgängligt tillstånd. Om du vill göra servern tillgänglig återställer du nyckeln och återanvänder datakryptering.
• Om du tar bort, från Microsoft Entra-ID, en hanterad identitet som används för att hämta en nyckel från Key Vault eller genom att ta bort rolltilldelningen för Azure RBAC med rollen Key Vault Crypto Service Encryption User. Azure Database for PostgreSQL– flexibel serverinstans kan inte komma åt nyckeln och flyttas till ett otillgängligt tillstånd. Om du vill göra servern tillgänglig återställer du identiteten och återanvänder datakryptering.
• Om du återkallar Key Vault-listan, hämtar, wrapKey och tar bort åtkomstprinciper förwrapKey från den hanterade identitet som används för att hämta en nyckel från Key Vault, kan azure Database for PostgreSQL flexibel serverinstans inte komma åt nyckeln och flyttas till ett otillgängligt tillstånd. Lägg till nödvändiga åtkomstprinciper till identiteten i Key Vault.
• Om du konfigurerar alltför restriktiva Key Vault-brandväggsregler kan azure Database for PostgreSQL– flexibel server inte kommunicera med Key Vault för att hämta nycklar. När du konfigurerar en Key Vault-brandvägg måste du välja alternativet för att tillåta att betrodda Microsoft usluge kringgår brandväggen.

Kommentar

När en nyckel har inaktiverats, tagits bort, upphört att gälla eller inte kan nås blir en server som har data krypterade via den nyckeln otillgänglig, enligt vad som angavs tidigare. Servern blir inte tillgänglig förrän du återaktiverar nyckeln eller tilldelar en ny nyckel.

I allmänhet blir en server otillgänglig inom 60 minuter efter att en nyckel har inaktiverats, tagits bort, upphört att gälla eller inte kan nås. När nyckeln blir tillgänglig kan det ta upp till 60 minuter innan servern blir tillgänglig igen.

Återställa från borttagning av hanterad identitet

I sällsynta fall när entra-ID-hanterad identitet, som används av CMK för att hämta en nyckel från Azure Key Vault (AKV), tas bort i Microsoft Entra-ID: följande är rekommenderade steg för att återställa:

1. Antingen återställa identiteten eller skapa en ny hanterad Entra-ID-identitet
2. Kontrollera att den här identiteten har rätt behörigheter för åtgärder på nyckeln i Azure Key Vault (AKV). Beroende på behörighetsmodellen för nyckelvalvet (åtkomstprincip eller Azure RBAC) kan åtkomst till nyckelvalvet beviljas antingen genom att skapa en åtkomstprincip i nyckelvalvet (lista, hämta, wrapKey och unwrapKey-åtkomstprinciper ) eller genom att skapa en ny Azure RBAC-rolltilldelning med rollen Key Vault Crypto Service Encryption User.
3. Omvalidera CMK-datakryptering med en ny eller återställd identitet i Azure Database for PostgreSQL – Azure-portalen för flexibel serverkryptering.

Viktigt!

Att bara skapa en ny Entra-ID-identitet med samma namn som den borttagna identiteten återställs inte från borttagning av hanterad identitet.

Använda datakryptering med CMK:er och geo-redundanta funktioner för affärskontinuitet

Azure Database for PostgreSQL – flexibel server stöder avancerade funktioner för dataåterställning , till exempel repliker och geo-redundant säkerhetskopiering. Följande är krav för att konfigurera datakryptering med CMK:er och dessa funktioner, utöver grundläggande krav för datakryptering med CMK:er:

• Krypteringsnyckeln för geo-redundant säkerhetskopiering måste skapas i en Key Vault-instans i den region där den geo-redundanta säkerhetskopieringen lagras.
• Azure Resource Manager REST API-versionen för stöd för geo-redundanta säkerhetskopieringsaktiverade CMK-servrar är 2022-11-01-preview. Om du vill använda Azure Resource Manager-mallar för att automatisera skapandet av servrar som använder både kryptering med CMK:er och geo-redundanta säkerhetskopieringsfunktioner använder du den här API-versionen.
• Du kan inte använda samma användarhanterade identitet för att autentisera för den primära databasens Key Vault-instans och Key Vault-instansen som innehåller krypteringsnyckeln för geo-redundant säkerhetskopiering. För att upprätthålla regional återhämtning rekommenderar vi att du skapar den användarhanterade identiteten i samma region som de geo-redundanta säkerhetskopiorna.
• Om du konfigurerar en skrivskyddad replikdatabas som ska krypteras med CMK:er när den skapas måste dess krypteringsnyckel finnas i en Key Vault-instans i den region där skrivskyddad replikdatabas finns. Den användartilldelade identiteten för att autentisera mot den här Key Vault-instansen måste skapas i samma region.

Begränsningar

Här är de aktuella begränsningarna för att konfigurera CMK i Azure Database for PostgreSQL – flexibel server:

• Du kan bara konfigurera CMK-kryptering när du skapar en ny server, inte som en uppdatering av en befintlig flexibel Azure Database for PostgreSQL-serverinstans. Du kan återställa en PITR-säkerhetskopia till en ny server med CMK-kryptering i stället.

• När du har konfigurerat CMK-kryptering kan du inte ta bort den. Om du vill ta bort den här funktionen är det enda sättet att återställa servern till en icke-CMK-server.

• Instansen av Azure Key Vault Managed HSM eller instansen av Azure Key Vault där du planerar att lagra krypteringsnyckeln måste finnas i samma region där instansen av Azure Database för flexibel server skapas.

Nästa steg

• Läs mer om Microsoft Entra Domain Services.