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 Azure Database for PostgreSQL – flexibel 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 arbetsbelastningarnas prestanda negativt.
  • Det förenklar hanteringen av krypteringsnycklar (inklusive deras vanliga rotation) och hanteringen av de identiteter som används för att komma åt dessa nycklar.

Datakryptering med kundhanterade nycklar för Azure Database for PostgreSQL – flexibel 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:

  • Om du vill förhindra oavsiktlig eller obehörig borttagning av den här kritiska resursen anger du ett resurslås på Key Vault.
  • 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 så inte är fallet ändrar servern sitt tillstånd till Otillgängligt och börjar neka alla anslutningar.

Några av de möjliga orsakerna till att servertillståndet kan bli otillgängligt är:

Orsak Åtgärd
Någon av de krypteringsnycklar som servern pekar på hade ett förfallodatum och en konfigurerad tid och datum och tid har uppnåtts. Du måste förlänga förfallodatumet för nyckeln. Sedan måste du vänta tills tjänsten har förnyat nyckeln och automatiskt överföra servertillståndet till Klar. Endast när servern är i tillståndet Klar kan du rotera nyckeln till en nyare version eller skapa en ny nyckel och uppdatera servern så att den refererar till den nya versionen av samma nyckel eller till den nya nyckeln.
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 servern pekar på, upphör att gälla och omvandlar servertillståndet till Otillgängligt. Undvik den här situationen 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 efter att servern har skapats, detta uppdaterar bara nyckeln/identiteten." Om du föredrar att uppdatera den med hjälp av API:et kan du anropa tjänstens server– uppdateringsslutpunkt .
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. Återställ Key Vault-instansen och vänta tills tjänsten kör den regelbundna förlängningen av nyckeln och överför automatiskt servertillståndet till Klar.
Du tar bort en hanterad identitet från Microsoft Entra-ID som används för att hämta någon av krypteringsnycklarna som lagras i Key Vault. Återställ identiteten och vänta tills tjänsten kör den regelbundna förlängningen av nyckeln och överför automatiskt servertillståndet till Klar.
Key Vault-behörighetsmodellen är konfigurerad för att använda rollbaserad åtkomstkontroll. Du tar bort rolltilldelningen Key Vault Crypto Service Encryption User RBAC från de hanterade identiteter som har konfigurerats för att hämta någon av nycklarna. Bevilja RBAC-rollen igen till den hanterade identiteten och vänta tills tjänsten kör den regelbundna förlängningen av nyckeln och överför automatiskt servertillståndet till Klar. En alternativ metod är att bevilja rollen i Key Vault till en annan hanterad identitet och uppdatera servern så att den använder den andra hanterade identiteten för att få åtkomst till nyckeln.
Key Vault-behörighetsmodellen är konfigurerad för att använda åtkomstprinciper. Du återkallar åtkomstprinciperna list, get, wrapKey eller unwrapKey från den hanterade RBAC-rolltilldelningen key vault crypto service encryption user från de hanterade identiteter som har konfigurerats för att hämta någon av nycklarna. Bevilja RBAC-rollen igen till den hanterade identiteten och vänta tills tjänsten kör den regelbundna förlängningen av nyckeln och överför automatiskt servertillståndet till Klar. En alternativ metod är att bevilja nödvändiga åtkomstprinciper i Key Vault till en annan hanterad identitet och uppdatera servern så att den använder den andra hanterade identiteten för att få åtkomst till nyckeln.
Du konfigurerar alltför restriktiva Key Vault-brandväggsregler så att din flexibla Azure Database for PostgreSQL-server inte kan kommunicera med Key Vault för att hämta dina nycklar. När du konfigurerar en Key Vault-brandvägg kontrollerar du att du väljer alternativet för att tillåta betrodda Microsoft-tjänster så att din flexibla Azure Database for PostgreSQL-server kan kringgå 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 med den nyckeln otillgänglig, enligt vad som angavs tidigare. Servertillståndet ändras inte till Klar igen förrän krypteringsnycklarna kan återanvändas.

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 redo 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.

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