Dela via

Översikt över säkerhetsdomän i Managed HSM

  • Artikel

En hanterad HSM är en FIPS( Federal Information Processing Standards) 140-2-verifierad, högtillgänglig maskinvarusäkerhetsmodul (HSM) som har en kundkontrollerad säkerhetsdomän.

För att fungera måste en hanterad HSM ha en säkerhetsdomän. Säkerhetsdomänen är en krypterad blobfil som innehåller artefakter som HSM-säkerhetskopiering, användarautentiseringsuppgifter, signeringsnyckeln och den datakrypteringsnyckel som är unik för den hanterade HSM.

En hanterad HSM-säkerhetsdomän har följande syften:

  • Etablerar "ägarskap" genom att kryptografiskt binda varje hanterad HSM till en rot av förtroendenycklar under din enda kontroll. Detta säkerställer att Microsoft inte har åtkomst till ditt kryptografiska nyckelmaterial på den hanterade HSM:en.

  • Anger den kryptografiska gränsen för nyckelmaterial i en hanterad HSM-instans.

  • Gör att du kan återställa en hanterad HSM-instans helt om det uppstår en katastrof. Följande katastrofscenarier beskrivs:

    • Ett oåterkalleligt fel där alla HSM-instanser av en hanterad HSM-instans förstörs.
    • Den hanterade HSM-instansen togs bort av en kund och resursen rensades efter att den obligatoriska kvarhållningsperioden löpte ut.
    • Kunden arkiverade ett projekt genom att utföra en säkerhetskopia som inkluderade den hanterade HSM-instansen och alla data och tog sedan bort alla Azure-resurser som var associerade med projektet.

Utan säkerhetsdomänen är haveriberedskap inte möjligt. Microsoft kan inte återställa säkerhetsdomänen och Microsoft kan inte komma åt dina nycklar utan säkerhetsdomänen. Att skydda säkerhetsdomänen är därför av yttersta vikt för din affärskontinuitet och för att säkerställa att du inte är kryptografiskt utelåst.

Metodtips för säkerhetsdomänskydd

Implementera följande metodtips för att säkerställa skyddet av din säkerhetsdomän.

Ladda ned den krypterade säkerhetsdomänen

Säkerhetsdomänen genereras i både den hanterade HSM-maskinvaran och tjänstprogramvarans enklaver under initieringen. När den hanterade HSM:en har etablerats måste du skapa minst tre RSA-nyckelpar och skicka de offentliga nycklarna till tjänsten när du begär nedladdningen av säkerhetsdomänen. Du måste också ange det minsta antal nycklar som krävs (kvorumet) för att dekryptera säkerhetsdomänen i framtiden.

Den hanterade HSM initierar säkerhetsdomänen och krypterar den med de offentliga nycklar som du anger med hjälp av Shamirs algoritm för hemlig delning. När säkerhetsdomänen har laddats ned flyttas den hanterade HSM:en till ett aktiverat tillstånd och är redo att användas.

Lagra säkerhetsdomännycklarna

Nycklarna till en säkerhetsdomän måste lagras i offlinelagring (till exempel på en krypterad USB-enhet) med varje delning av kvorumet på en separat lagringsenhet. Lagringsenheterna måste förvaras på separata geografiska platser och i ett fysiskt kassaskåp eller en låsruta. För ultrakänsliga och högsäkerhetsanvändande användningsfall kan du till och med välja att lagra dina privata säkerhetsdomännycklar i din lokala, offline-HSM.

Det är särskilt viktigt att regelbundet granska din säkerhetsprincip för det hanterade HSM-kvorumet. Din säkerhetsprincip måste vara korrekt, du måste ha uppdaterade poster om var säkerhetsdomänen och dess privata nycklar lagras och du måste veta vem som har kontroll över säkerhetsdomänen.

Här följer förbud mot nyckelhantering av säkerhetsdomäner:

  • En person får aldrig ha fysisk åtkomst till alla kvorumnycklar. Med andra ord m måste vara större än 1 (och bör helst vara >= 3).
  • Säkerhetsdomännycklarna får aldrig lagras på en dator som har en Internetanslutning. En dator som är ansluten till Internet utsätts för olika hot, till exempel virus och skadliga hackare. Du minskar risken avsevärt genom att lagra säkerhetsdomännycklarna offline.

Upprätta ett kvorum för säkerhetsdomän

Det bästa sättet att skydda en säkerhetsdomän och förhindra kryptografisk utelåsning är att implementera flerpersonskontroll med hjälp av det hanterade HSM-konceptkvorumet. Ett kvorum är ett tröskelvärde för delad hemlighet för att dela upp nyckeln som krypterar säkerhetsdomänen mellan flera personer. Ett kvorum tillämpar kontroll för flera personer. På så sätt är säkerhetsdomänen inte beroende av en enskild person, som kan lämna organisationen eller ha skadliga avsikter.

Vi rekommenderar att du implementerar ett kvorum av m personer, där m är större än eller lika med 3. Den maximala kvorumstorleken för säkerhetsdomänen för en hanterad HSM är 10.

Även om en högre m storlek ger mer säkerhet medför det ytterligare administrativa omkostnader när det gäller hantering av säkerhetsdomänen. Det är därför absolut nödvändigt att säkerhetsdomänkvorumet väljs noggrant, med minst m>= 3.

Kvorumstorleken för säkerhetsdomäner bör också regelbundet granskas och uppdateras (till exempel vid personaländringar). Det är särskilt viktigt att ha register över säkerhetsdomäninnehavare. Dina poster bör dokumentera varje hand-off eller byte av innehav. Din princip bör tillämpa en strikt efterlevnad av kvorum- och dokumentationskrav.

Eftersom nycklarna tillåter åtkomst till den mest känsliga och kritiska informationen i din hanterade HSM måste privata nycklar för säkerhetsdomänen innehas av primära och betrodda anställda i organisationen. Innehavare av säkerhetsdomäner bör ha separata roller och vara geografiskt åtskilda i din organisation.

Ett kvorum för säkerhetsdomäner kan till exempel bestå av fyra nyckelpar, där varje privat nyckel ges till en annan person. Minst två personer måste samlas för att rekonstruera en säkerhetsdomän. Delarna kan ges till nyckelpersoner, till exempel:

  • Teknisk ansvarig för affärsenhet
  • Säkerhetsarkitekt
  • Säkerhetstekniker
  • Programutvecklare

Varje organisation är annorlunda och tillämpar en annan säkerhetsprincip baserat på dess behov. Vi rekommenderar att du regelbundet granskar din säkerhetsprincip för efterlevnad och fattar beslut om kvorum och dess storlek. Din organisation kan välja tidpunkt för granskningen, men vi rekommenderar att du genomför en säkerhetsdomängranskning minst en gång varje kvartal, och även vid dessa tillfällen:

  • När en medlem i kvorumet lämnar organisationen.
  • När ett nytt eller framväxande hot gör att du bestämmer dig för att öka kvorumets storlek.
  • När det sker en processändring i implementeringen av kvorumet.
  • När en USB-enhet eller HSM som tillhör en medlem i säkerhetsdomänkvorumet går förlorad eller komprometteras.

Kompromiss eller förlust av säkerhetsdomän

Om din säkerhetsdomän komprometteras kan en obehörig aktör använda den för att skapa en egen hanterad HSM-instans. Den skadliga aktören kan använda åtkomsten till nyckelsäkerhetskopior för att börja dekryptera data som skyddas med nycklarna på den hanterade HSM:en.

En förlorad säkerhetsdomän anses vara komprometterad.

När en säkerhetsdomän har komprometterats måste alla data som krypteras via den aktuella hanterade HSM dekrypteras med hjälp av aktuellt nyckelmaterial. En ny instans av Azure Key Vault Managed HSM måste etableras och en ny säkerhetsdomän som pekar på den nya URL:en måste implementeras.

Eftersom det inte finns något sätt att migrera nyckelmaterial från en instans av Managed HSM till en annan instans som har en annan säkerhetsdomän, måste implementeringen av säkerhetsdomänen vara väl genomtänkt, och den måste skyddas genom korrekt, regelbundet granskad arkivering.

Sammanfattning

Säkerhetsdomänen och dess motsvarande privata nycklar spelar en viktig roll i hanterade HSM-åtgärder. Dessa artefakter motsvarar kombinationen av ett säkert och dålig hantering kan lätt kompromettera starka algoritmer och system. Om en säker kombination är känd för en angripare ger det starkaste kassaskåpet ingen säkerhet. Korrekt hantering av säkerhetsdomänen och dess privata nycklar är avgörande för effektiv användning av den hanterade HSM:en.

Vi rekommenderar starkt att du läser NIST Special Publication 800-57 för bästa praxis för hantering innan du utvecklar och implementerar de principer, system och standarder som krävs för att uppfylla och förbättra organisationens säkerhetsmål.

Nästa steg