Dela via

Datakryptering

  • Artikel

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

Alla data som hanteras av en instans av Azure Database for PostgreSQL är alltid krypterade i vila. Dessa data omfattar alla system- och användardatabaser, temporära filer, serverloggar, loggsegment för skrivning framåt och säkerhetskopior.

För att uppnå kryptering av dina data använder Azure Database for PostgreSQL – Flexibel server Azure Storage-kryptering för vilande data, vilket ger nycklar för kryptering och dekryptering av data i Blob Storage- och Azure Files-tjänster. Dessa nycklar måste lagras i Azure Key Vault eller Azure Key Vault Managed Hardware Security Module (HSM). Mer information finns i kundhanterade nycklar för Azure Storage-kryptering.

Azure Database for PostgreSQL – Flexibel server stöder konfiguration av datakryptering i två olika lägen: tjänsthanterad nyckel och kundhanterad nyckel. Konfigurationsläget kan bara väljas när servern skapas. Det går inte att ändra från ett läge till ett annat under serverns livslängd.

Med tjänsthanterad krypteringsnyckel tar Azure Database for PostgreSQL – Flexibel server hand om etableringen av Azure Key Vault där nycklarna behålls, och den tar på sig allt ansvar för att tillhandahålla nyckeln som data krypteras och dekrypteras med. Tjänsten tar också hand om lagring, skydd, granskning av åtkomst, konfiguration av nätverk och automatisk rotation av nyckeln.

Med kundhanterad krypteringsnyckel tar du på dig allt ansvar. Därför måste du distribuera ditt eget Azure Key Vault eller Azure Key Vault HSM. Du måste generera eller importera din egen nyckel. Du måste bevilja nödvändiga behörigheter för Key Vault så att din flexibla Azure Database for PostgreSQL-server kan utföra nödvändiga åtgärder på nyckeln. Du måste ta hand om att konfigurera alla nätverksaspekter i Azure Key Vault där nyckeln behålls, så att din flexibla Azure Database for PostgreSQL-server kan komma åt nyckeln. Det är också ditt ansvar att granska åtkomsten till nyckeln. Slutligen ansvarar du för att rotera nyckeln och vid behov uppdatera konfigurationen av din flexibla Azure Database for PostgreSQL-server så att den refererar till den roterade versionen av nyckeln.

När du konfigurerar kundhanterade nycklar för ett lagringskonto omsluter Azure Storage rotdatakrypteringsnyckeln (DEK) för kontot med den kundhanterade nyckeln i det associerade nyckelvalvet eller hanterade HSM. Skyddet av rotkrypteringsnyckeln ändras, men data i ditt Azure Storage-konto förblir alltid krypterade. Det krävs ingen extra åtgärd från din sida för att säkerställa att dina data förblir krypterade. Skydd med kundhanterade nycklar börjar gälla omedelbart.

Azure 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 ta emot den från en lokal HSM-enhet.

Fördelar som tillhandahålls av varje läge

Datakryptering med tjänsthanterade nycklar för flexibel Azure Database for PostgreSQL-server ger följande fördelar:

  • Tjänsten styr dataåtkomst automatiskt och fullständigt.
  • Tjänsten styr automatiskt och fullständigt nyckelns livscykel, inklusive rotation av nyckeln.
  • Du behöver inte bekymra dig om att hantera datakrypteringsnycklar.
  • Datakryptering baserat på tjänsthanterade nycklar påverkar inte prestandan för dina arbetsbelastningar negativt.
  • Det förenklar hanteringen av

Datakryptering med kundhanterade nycklar 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 kontrollerar helt och hållet en nyckels livscykel, inklusive rotation av nyckeln, så att den överensstämmer med företagets principer.
  • Du kan centralt hantera och organisera alla dina krypteringsnycklar i dina egna instanser av Azure Key Vault.
  • Datakryptering baserat på kundhanterade nycklar påverkar inte prestandan för dina arbetsbelastningar negativt.
  • Du kan implementera ansvarsfördelning mellan säkerhetsansvariga, databasadministratörer och systemadministratörer.

Krav

Följande är listan över krav för att konfigurera datakryptering för azure database for PostgreSQL – flexibel server:

  • 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.
  • 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 den här inställningen.
  • Aktivera funktionen för mjuk borttagning i Key Vault för att hjälpa dig 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 associerade med en Key Vault-roll eller en åtkomstprincipbehörighet. Funktionen för mjuk borttagning är aktiverad som standard. Om du har några Key Vault som distribuerades för länge sedan kan det fortfarande ha mjuk borttagning inaktiverats. I så fall kan du aktivera det med hjälp av Azure CLI.
  • Aktivera rensningsskydd för att framtvinga en obligatorisk kvarhållningsperiod för borttagna valv och valvobjekt.
  • Ge Azure Database for PostgreSQL flexibel server användartilldelad hanterad identitet åtkomst till nyckeln genom att:
  • Nyckeln som används för att kryptera datakrypteringsnyckeln kan endast vara asymmetrisk, RSA eller RSA-HSM. Nyckelstorlekar på 2 048, 3 072 och 4 096 stöds. Vi rekommenderar att du använder en 4 096-bitarsnyckel för bättre säkerhet.
  • 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 aktiverat tillstånd.
  • Om du importerar en befintlig nyckel till Key Vault anger du den i de filformat som stöds (.pfx, .byokeller .backup).

Rekommendationer

När du använder en kundhanterad nyckel för datakryptering följer du dessa rekommendationer för att konfigurera Key Vault:

  • Ange ett resurslås på Key Vault för att förhindra oavsiktlig eller obehörig borttagning av den här kritiska resursen.
  • 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-tjänster att kringgå den här brandväggen.

Kommentar

När du har valt Inaktivera offentlig åtkomst och Tillåt betrodda Microsoft-tjänster 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 konfigurationen av kundhanterade nycklar eller hämta nycklar från Key Vault under serveråtgärder.

  • Behåll en kopia av den kundhanterade nyckeln 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.

Särskilda beaktanden

Å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:

  • Avtilldela RBAC-rollen Key Vault Crypto Service Encryption User eller återkalla behörigheterna 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 nycklarna som lagras i Azure Key Vault

Om du vill övervaka databastillståndet och aktivera aviseringar för förlust av åtkomst till 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 säkerhetskopior av en server som konfigurerats med en kundhanterad nyckel

När Azure Database for PostgreSQL – flexibel server har krypterats med en kundhanterad nyckel som lagras 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 datakryptering med kundhanterad nyckel kan du under drift som återställning av en säkerhetskopia eller skapande av en läsreplik undvika problem genom att följa dessa steg på de primära och återställde servrarna eller 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 den kundhanterade nyckeln och den användartilldelade hanterade identiteten som används för att få åtkomst till Key Vault. Kontrollera att den identitet som tilldelats på den nyligen skapade servern har de behörigheter som krävs för 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 server med kundhanterad nyckel 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 Portal med den kundhanterade nyckeln 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 kundhanterat nyckelvillkor

När du konfigurerar datakryptering med en kundhanterad nyckel som lagras 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 nyckeln 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 de möjliga orsakerna till att servertillståndet kan bli otillgängligt är:

  • Om du roterar nyckeln och glömmer att uppdatera instansen av Azure Database for PostgreSQL – flexibel server, så att den pekar på den nya versionen av nyckeln. Den gamla nyckeln, som instansen pekade på, upphör så småningom att gälla och omvandlar servertillståndet till Otillgängligt. Undvik detta genom att varje gång du roterar nyckeln se till att du även uppdaterar instansen av servern så att den pekar på den nya versionen. För att göra det kan du använda az postgres flexible-server update, i följande exempel som beskriver "Ändra nyckel/identitet för datakryptering. Datakryptering kan inte aktiveras när servern har skapats. Detta uppdaterar bara nyckeln/identiteten." Som ett alternativ kan du anropa tjänstens SERVRAR – Uppdatera REST-API:et.
  • 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-tjänster 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

Om den användartilldelade hanterade identiteten som används för att komma åt krypteringsnyckeln som lagras i Key Vault tas bort i Microsoft Entra-ID bör du följa dessa steg för att återställa:

  1. Antingen återställer du identiteten eller skapar en ny hanterad Entra-ID-identitet.
  2. Om du har skapat en ny identitet, även om den har exakt samma namn som den hade innan den togs bort, uppdaterar du Azure Database för flexibla serveregenskaper så att den vet att den måste använda den nya identiteten för att få åtkomst till krypteringsnyckeln.
  3. Kontrollera att den här identiteten har rätt behörigheter för åtgärder på nyckeln i Azure Key Vault (AKV).
  4. Vänta i ungefär en timme tills servern återupptar nyckeln.

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 kundhanterade nycklar 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 som måste finnas 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.

Kundhanterad nyckelrotation och versionslösa nycklar (förhandsversion)

Som en försiktighetsåtgärd rekommenderar vi att du roterar nyckeln regelbundet eller när nyckeln komprometteras.

Kommentar

De flesta företag har externa eller interna krav på att rotera sina nycklar regelbundet, till exempel var 90:e dag. För nycklar som genereras av Key Vault kan du konfigurera autorotation av kryptografiska nycklar i Azure Key Vault. Om du aktiverar autorotation måste du använda en versionslös CMK (förhandsversion) för datakryptering i Azure Database for PostgreSQL – flexibel server för att dra nytta av den här funktionen.

Genom att rotera nyckeln manuellt kan du skydda dina data om nyckeln skulle komprometteras. Om du vill rotera nyckeln skapar eller importerar du en ny nyckelgenerering för den komprometterade nyckeln.

  • Om du använder versionslösa kundhanterade nycklar (förhandsversion) hämtar servern den nya nyckeln automatiskt.
  • Om du använder versionsnycklar måste du uppdatera den flexibla serverinstansen Azure Database for PostgreSQL för att använda den nya versionen av nyckeln. Först då börjar servern använda den nya nyckeln för att kryptera och dekryptera data.

Versionslösa kundhanterade nycklar (förhandsversion)

Versionslösa nycklar rekommenderas för datakryptering i Azure Database for PostgreSQL – flexibel server. Den täcker korrekt något av de nyckelrotationsscenarier som beskrevs tidigare. När en ny nyckelversion är tillgänglig använder servern automatiskt den nya versionen av nyckelversionen för kryptering och dekryptering av data.

API:et ändras inte för versionslösa nycklar. I stället för att ange hela nyckelidentifierarens URI utelämnar du versionsdelen av nyckelidentifieraren. Detta gäller api:et, Azure CLI, ARM-mallar och Bicep-mallar. Azure Portal har en kryssruta för att aktivera versionslös, som du kan använda för att bara välja den versionslösa nyckelidentifieraren.

Begränsningar

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

Relaterat innehåll