Felsöka Azure Dedicated HSM-tjänsten

Azure Dedicated HSM-tjänsten har två distinkta aspekter. För det första registrering och distribution i Azure av HSM-enheter med deras underliggande nätverkskomponenter. För det andra konfigurationen av HSM-enheterna som förberedelse för användning/integrering med en viss arbetsbelastning eller ett visst program. Även om Thales Luna 7 HSM-enheter är desamma i Azure som du skulle köpa direkt från Thales, skapar det faktum att de är en resurs i Azure några unika överväganden. Dessa överväganden och eventuella resulterande felsökningsinsikter eller bästa praxis dokumenteras här för att säkerställa hög synlighet och åtkomst till viktig information. När tjänsten används är definitiv information tillgänglig via supportförfrågningar till antingen Microsoft eller Thales direkt.

Anteckning

Det bör noteras att innan du utför någon konfiguration på en nyligen distribuerad HSM-enhet bör den uppdateras med relevanta korrigeringar. En specifik nödvändig korrigering är KB0019789 i Thales supportportal som åtgärdar ett problem där systemet slutar svara under omstarten.

HSM-registrering

Dedikerad HSM är inte fritt tillgänglig för användning eftersom den levererar maskinvaruresurser i molnet och därför är en värdefull resurs som behöver skyddas. Vi använder därför en allowlisting-process via e-post med hjälp av HSMrequest@microsoft.com.

Få åtkomst till dedikerad HSM

Börja med att fråga dig själv vilka användningsfall du har som inte kan hanteras av Azure Key Vault eller Azure Managed HSM. Om du då tror att endast dedikerad HSM passar dina viktiga lagringskrav kan du skicka e-post HSMrequest@microsoft.com för att begära åtkomst. Beskriv dina program- och användningsfall, de regioner som du vill ha HSM:er och mängden HSM:er som du letar efter. Om du arbetar med en Microsoft-representant, till exempel en kontoansvarig eller molnlösningsarkitekt, ska du inkludera dem i alla förfrågningar.

HSM-etablering

Etablering av en HSM-enhet i Azure kan göras via CLI eller PowerShell. När du registrerar dig för tjänsten tillhandahålls en ARM-exempelmall och hjälp ges för den inledande anpassningen.

Information om HSM-distributionsfel

Dedikerad HSM stöder CLI och PowerShell för distribution, så portalbaserad felinformation är begränsad och inte utförlig. Du hittar bättre information med hjälp av Resource Explorer. Portalens startsida har en ikon för detta och mer detaljerad felinformation finns tillgänglig. Den här informationen hjälper mycket om den klistras in när du skapar en supportbegäran som rör distributionsproblem.

Delegering av HSM-undernät

Den främsta orsaken till distributionsfel är att du glömmer att ange lämplig delegering för det kunddefinierade undernät som HSM:erna ska etableras på. Att ange den delegeringen är en del av kraven för VNet och undernätet för distribution och mer information finns i självstudierna.

HSM-distributionsloppsvillkor

Standard-ARM-mallen som tillhandahålls för distributionen har HSM- och ExpressRoute-gatewayrelaterade resurser. Nätverksresurser är ett beroende för en lyckad HSM-distribution och tidsinställningen kan vara avgörande. Ibland har vi sett distributionsfel som rör beroendeproblem och omkörning av distributionen löser ofta problemet. Om inte lyckas ofta borttagning av resurser och omdistribution. När du har försökt med det här och fortfarande har hittat problemet skapar du en supportbegäran i Azure Portal väljer problemtypen "Problem med att konfigurera Azure-konfigurationen".

HSM-distribution med Terraform

Några kunder har använt Terraform som en automatiseringsmiljö i stället för ARM-mallar som tillhandahålls när de registrerar sig för den här tjänsten. HSM:erna kan inte distribueras på det här sättet, men de beroende nätverksresurserna kan det. Terraform har en modul för att anropa en minimal ARM-mall som bara har HSM-distributionen. I det här fallet bör du se till att nätverksresurser som den nödvändiga ExpressRoute-gatewayen distribueras fullständigt innan du distribuerar HSM:er. Följande CLI-kommando kan användas för att testa för slutförd distribution och integreras efter behov. Ersätt vinkelparentesens platshållare för din specifika namngivning. Du bör leta efter ett resultat av "provisioningState is Succeeded"

az resource show --ids /subscriptions/<subid>/resourceGroups/<myresourcegroup>/providers/Microsoft.Network/virtualNetworkGateways/<myergateway>

Distributionsfel baserat på kvot

Distributioner kan misslyckas om du överskrider 2 HSM:er per stämpel och 4 HSM:er per region. Undvik den här situationen genom att se till att du har tagit bort resurser från tidigare misslyckade distributioner innan du distribuerar igen. Se objektet "Hur gör jag för att se HSM:er" nedan för att kontrollera resurser. Om du tror att du behöver överskrida den här kvoten, som främst finns där som ett skydd, kan du skicka ett e-postmeddelande HSMrequest@microsoft.com med information.

Distributionsfel baserat på kapacitet

När en viss stämpel eller region blir full, dvs. nästan alla kostnadsfria HSM:er etableras, kan detta leda till distributionsfel. Varje stämpel har 12 HSM:er tillgängliga för kunder, vilket innebär 24 per region. Det finns också 2 reservdelar och 1 testenhet i varje stämpel. Om du tror att du har nått en gräns kan du skicka e-post HSMrequest@microsoft.com för information om fyllningsnivå för specifika stämplar.

Hur gör jag för att se HSM:er när de etableras?

På grund av att dedikerad HSM är en tillåten tjänst anses den vara en "dold typ" i Azure Portal. Om du vill se HSM-resurserna måste du markera kryssrutan "Visa dolda typer" enligt nedan. NIC-resursen följer alltid HSM och är ett bra ställe att ta reda på IP-adressen för HSM innan du använder SSH för att ansluta.

Nätverksresurser

Distributionen av dedikerad HSM har ett beroende av nätverksresurser och vissa följdbegränsningar att känna till.

Etablera ExpressRoute

Dedikerad HSM använder ExpressRoute-gateway som en "tunnel" för kommunikation mellan kundens privata IP-adressutrymme och den fysiska HSM:en i ett Azure-datacenter. Med tanke på att det finns en begränsning för en gateway per Vnet måste kunder som kräver anslutning till sina lokala resurser via ExpressRoute använda ett annat virtuellt nätverk för den anslutningen.

Privat HSM-IP-adress

Exempelmallarna som tillhandahålls för Dedikerad HSM förutsätter att HSM IP automatiskt tas från ett visst undernätsintervall. Du kan ange en explicit IP-adress för HSM via attributet "NetworkInterfaces" i ARM-mallen.

HSM-initiering

Initieringen förbereder en ny HSM för användning eller en befintlig HSM för återanvändning. Initieringen av HSM måste vara klar innan du kan generera eller lagra objekt, tillåta klienter att ansluta eller utföra kryptografiska åtgärder.

Förlorade autentiseringsuppgifter

Förlust av Shell-administratörslösenordet leder till förlust av HSM-nyckelmaterial. En supportbegäran bör göras för att återställa HSM. När du initierar HSM lagrar du autentiseringsuppgifterna på ett säkert sätt. Shell- och HSM-autentiseringsuppgifter bör behållas i enlighet med företagets principer.

Misslyckade inloggningar

Att ange felaktiga autentiseringsuppgifter för HSM:er kan få destruktiva konsekvenser. Följande är standardbeteenden för HSM-roller.

Roll	Tröskelvärde (antal försök)	Resultatet av för många felaktiga inloggningsförsök	Återställning
HSM SO	3	HSM är nollställd (alla HSM-objektidentiteter och alla partitioner är borta)	HSM måste initieras om. Innehållet kan återställas från säkerhetskopior.
Partition SO	10	Partitionen nollställs.	Partitionen måste initieras om. Innehållet kan återställas från säkerhetskopian.
Granska	10	Lockout	Upplåst automatiskt efter 10 minuter.
Kryptografi	10 (kan minskas)	Om HSM-princip 15: Aktivera SO-återställning av partitions-PIN är inställt på 1 (aktiverad) är CO- och CU-rollerna utelåst. Om HSM-princip 15: Aktivera SÅ är återställning av partitions-PIN inställd på 0 (inaktiverad), co- och CU-rollerna är permanent utelåst och partitionsinnehållet är inte längre tillgängligt. Det här är standardinställningen.	CO-rollen måste låsas upp och autentiseringsuppgifterna återställas av partitions-SO, med hjälp av role resetpw -name co. Partitionen måste initieras om och nyckelmaterial återställas från en säkerhetskopieringsenhet.

HSM-konfiguration

Följande är en situation där konfigurationsfel antingen är vanliga eller har en effekt som är värd att framhäva:

HSM-dokumentation och programvara

Programvara och dokumentation för Thales Luna 7 HSM-enheter är inte tillgänglig från Microsoft och måste laddas ned från Thales direkt. Registrering krävs med hjälp av thales kund-ID som togs emot under registreringsprocessen. Enheterna, som tillhandahålls av Microsoft, har programvaruversion 7.2 och version 7.0.3 av inbyggd programvara. I början av 2020 offentliggjorde Thales dokumentation och den finns här.

HSM-nätverkskonfiguration

Var försiktig när du konfigurerar nätverket i HSM. HSM har en anslutning via ExpressRoute-gatewayen från ett privat IP-adressutrymme för kunden direkt till HSM. Den här kommunikationskanalen är endast avsedd för kundkommunikation och Microsoft har ingen åtkomst. Om HSM har konfigurerats på ett sådant sätt att nätverkssökvägen påverkas innebär det att all kommunikation med HSM tas bort. I den här situationen är det enda alternativet att skapa en Microsoft-supportbegäran via Azure Portal för att återställa enheten. Den här återställningsproceduren återställer HSM till sitt ursprungliga tillstånd och allt konfigurations- och nyckelmaterial går förlorat. Konfigurationen måste återskapas och när enheten ansluter till HA-gruppen replikeras nyckelmaterial.

Omstart av HSM-enhet

Vissa konfigurationsändringar kräver att HSM startas om eller startas om. Microsofts testning av HSM i Azure fastställde att omstarten vid vissa tillfällen kunde sluta svara. Konsekvensen är att en supportbegäran måste skapas i Azure Portal begära hård omstart och det kan ta upp till 48 timmar att slutföra med tanke på att det är en manuell process i ett Azure-datacenter. Undvik den här situationen genom att se till att du har distribuerat omstartskorrigeringen som är tillgänglig direkt från Thales. Se KB0019789 i Thales Luna 7 HSM 7.2-nedladdningar för en rekommenderad korrigering för ett problem där systemet slutar svara under omstarten (Obs! Du måste ha registrerat dig i Thales kundsupportportal för att kunna ladda ned).

NTLS-certifikat är inte synkroniserade

En klient kan förlora anslutningen till en HSM när ett certifikat upphör att gälla eller har skrivits över via konfigurationsuppdateringar. Klientkonfigurationen för certifikatutbyte ska tillämpas på nytt med varje HSM. Exempel på NTLS-loggning med ogiltigt certifikat:

NTLS[8508]: info : 0 : Inkommande anslutningsbegäran... : 192.168.50.2/59415 NTLS[8508]: Felmeddelandet från SSLAccept är : error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca NTLS[8508]: Fel under SSL accepterar ( RC_SSL_ERROR ) NTLS[8508]: info : 0xc0000711 : Misslyckas med att upprätta en säker kanal med klienten : 192.168.50.2/59415 : RC_SSL_FAILED_HANDSHAKE NTLS[8508]: info : 0 : NTLS-klienten "Okänt värdnamn" Anslutningsinstansen har tagits bort: 192.168.50.2/59415

TCP-kommunikation misslyckades

Kommunikation från Luna-klientinstallationen till HSM kräver minst TCP-port 1792. Tänk på detta eftersom alla nätverkskonfigurationer ändras i miljön.

Den misslyckade HA-gruppmedlemmen återställs inte

Om en misslyckad HA-gruppmedlem inte återställs måste den återställas manuellt från Luna-klienten med kommandot hagroup recover. Det är nödvändigt att konfigurera ett antal återförsök för en HA-grupp för att aktivera automatisk återställning. Som standard försöker en HA-grupp inte återställa en HA-medlem till gruppen när den återställs.

HA-gruppen synkroniseras inte

Om medlemspartitioner inte har samma kloningsdomän visas kommandot ha synchronize följande: Varning: Synkronisera kan misslyckas. Medlemmarna i plats 0 och plats 1 har motstridiga inställningar för kloning av privata nycklar. En ny partition med rätt kloningsdomän ska läggas till i HA-gruppen, följt av att den felaktigt konfigurerade partitionen tas bort.

HSM-avetablering

Endast när den är helt klar med en HSM kan den avetableras och sedan återställer Microsoft den och returnerar den till en kostnadsfri pool.

Så här tar du bort en HSM-resurs

TA INTE BORT resursgruppen för din dedikerade HSM direkt. HSM-resursen tas inte bort. Du fortsätter att debiteras eftersom den försätter HSM i ett överblivet tillstånd. Om inte följer korrekta procedurer och hamnar i den här situationen kontaktar du Microsoft Support.

Steg 1: Nollställ HSM. Azure-resursen för en HSM kan inte tas bort om inte HSM är i ett "nolliserat" tillstånd. Därför måste allt nyckelmaterial ha tagits bort innan du försöker ta bort det som en resurs. Det snabbaste sättet att nollställa är att få HSM-administratörslösenordet fel 3 gånger (obs! Detta refererar till HSM-administratören och inte administratören på installationsnivå). Använd kommandot "hsm login" och ange fel lösenord tre gånger. Luna-gränssnittet har ett hsm -factoryreset-kommando som nolliserar HSM, men det kan bara köras via -konsolen på serieporten och kunderna har inte åtkomst till detta.

Steg 2: När HSM har nollställts kan du använda något av följande kommandon för att initiera resursen Ta bort dedikerad HSM

Azure CLI: az dedicated-hsm delete --resource-group <RG name> –-name <HSM name>
Azure PowerShell: Remove-AzDedicatedHsm -Name <HSM-namn> – ResourceGroupName <RG-namn>

Steg 3: När steg 2 har slutförts kan du ta bort resursgruppen för att ta bort de andra resurserna som är associerade med den dedikerade HSM:en med hjälp av antingen Azure CLI eller Azure PowerShell.

Azure CLI: az group delete --name <RG name>
Azure PowerShell: Remove-AzResourceGroup -Name <RG-namn>

Nästa steg

Den här artikeln har gett insikter om områden i HSM-distributionens livscykel som kan ha problem eller kräver felsökning eller noggranna överväganden. Förhoppningsvis hjälper den här artikeln dig att undvika onödiga förseningar och frustration, och om du har relevanta tillägg eller ändringar kan du skicka en supportbegäran till Microsoft och meddela oss.