Betrouwbaarheid in beheerde HSM van Azure Key Vault

Azure Key Vault Managed HSM is een volledig beheerde, zeer beschikbare, single-tenant cloudservice die aan standaarden voldoet en waarmee u cryptografische sleutels voor uw cloudtoepassingen kunt beschermen met behulp van hardware security modules (HSM's) die zijn gevalideerd volgens FIPS 140-3 Level 3. Beheerde HSM biedt een reeks ingebouwde betrouwbaarheidsfuncties om ervoor te zorgen dat uw sleutels beschikbaar blijven.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe beheerde HSM bestand is tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, partitiefouten en regiostoringen. Ook wordt beschreven hoe u back-ups en het beveiligingsdomein gebruikt voor herstel na noodgevallen, hoe herstelfuncties beschermen tegen onbedoelde verwijdering en belangrijke informatie over de beheerde SLA (Service Level Agreement).

Aanbevelingen voor productie-implementatie

Voor productiewerkzaamheden raden we u aan het volgende te doen:

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u Managed HSM gebruikt, richt u een instantie in, die soms een pool wordt genoemd.

De architectuur van Beheerde HSM is ontworpen voor hoge beschikbaarheid en duurzaamheid.

• Isolatie van één tenant: Elk beheerd HSM-exemplaar is toegewezen aan één klant en bestaat uit een cluster met meerdere HSM-partities die cryptografisch zijn geïsoleerd.

• Driedubbele redundante partities: Een beheerde HSM-pool bestaat uit drie HSM-partities met gelijke taakverdeling, verdeeld over afzonderlijke rekken binnen een datacenter. Deze distributie biedt redundantie tegen hardwarefouten en zorgt ervoor dat het verlies van één onderdeel, zoals de voeding of netwerkswitch van een rek, niet van invloed is op alle partities.

• Confidential Computing: Elk service-exemplaar wordt uitgevoerd in een TEE (Trusted Execution Environment) die gebruikmaakt van Intel SGX-enclaves. Microsoft personeel, inclusief personen met fysieke toegang tot de servers, heeft geen toegang tot uw cryptografische sleutelmateriaal.

• Automatische genezing: Als een hardwarefout of ander probleem van invloed is op een van de drie partities, wordt de betreffende partitie automatisch opnieuw opgebouwd op gezonde hardware zonder tussenkomst van de klant en zonder geheimen weer te geven.

Zie Sleutelsoevereiniteit, beschikbaarheid, prestaties en schaalbaarheid in Beheerde HSM voor meer informatie over hoe beheerde HSM deze mogelijkheden implementeert.

Beveiligingsdomein

Het beveiligingsdomein is een essentieel onderdeel van beheerde HSM voor herstel na noodgevallen. Het is een versleutelde blob die alle referenties bevat die nodig zijn voor het opnieuw bouwen van een beheerd HSM-exemplaar, inclusief de sleutel van de partitie-eigenaar, de partitiereferenties, de gegevensterugloopsleutel en een eerste back-up van de HSM.

Beveiligingsdomeinen vormen een essentieel onderdeel van de beveiliging en betrouwbaarheid van uw beheerde HSM. We raden u aan deze aanbevolen procedures te volgen:

• Sleutels veilig genereren: Genereer voor productieomgevingen de RSA-sleutelparen die het beveiligingsdomein beschermen in een omgeving met air-gapped, zoals een on-premises HSM of een geïsoleerd werkstation.

• Offline opslaan: Sla beveiligingsdomeinsleutels op versleutelde USB-stations of andere offlineopslag op, met elke sleutelshare op een afzonderlijk apparaat in afzonderlijke geografische locaties.

• Een quorum voor meerdere gebruikers instellen: Gebruik ten minste drie sleutelhouders om te voorkomen dat één persoon toegang heeft tot alle quorumsleutels en om een afhankelijkheid van één persoon te voorkomen.

Zie Het beveiligingsdomein in het overzicht van beheerde HSM's voor meer informatie.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Wanneer u Azure-services gebruikt die zijn geïntegreerd met beheerde HSM, verwerken deze services automatisch tijdelijke fouten.

Als u aangepaste toepassingen bouwt die zijn geïntegreerd met Beheerde HSM, kunt u de volgende aanbevolen procedures overwegen om tijdelijke fouten te verwerken die kunnen optreden:

• Gebruik de door Microsoft geleverde SDK's voor Azure Key Vault, waaronder ingebouwde mechanismen voor opnieuw proberen. SDK's zijn beschikbaar voor .NET, Python en JavaScript.

• Implementeer logica voor opnieuw proberen, inclusief exponentieel uitstel, voor elke code die rechtstreeks met beheerde HSM communiceert.

• Verminder het aantal directe afhankelijkheden van beheerde HSM. Sla resultaten van cryptografische bewerkingen in de cache op, indien mogelijk, om directe aanvragen naar beheerde HSM te verminderen. Voer bewerkingen met openbare sleutels, zoals versleuteling, sleutelverpakking en verificatie, lokaal uit door het openbare-sleutelmateriaal in de cache op te slaan. Het lokaal uitvoeren van de bewerkingen vermindert de afhankelijkheid van uw beheerde HSM en vermindert de kans op tijdelijke fouten die deze bewerkingen onderbreken.

Als u Managed HSM gebruikt in scenario's met een hoge doorvoer, beperkt Managed HSM de snelheid van cryptografische bewerkingen niet. De HSM-hardware wordt gebruikt voor volledige capaciteit. Elk beheerd HSM-exemplaar heeft drie partities. Tijdens onderhouds- of herstelbewerkingen is één partitie mogelijk niet beschikbaar. Voor capaciteitsplanning wordt ervan uitgegaan dat er twee partities beschikbaar zijn. Als u gegarandeerde doorvoer nodig hebt, moet u plannen op basis van één partitie die beschikbaar is. Bewaak de metrische gegevens voor beheerde HSM-beschikbaarheid om inzicht te hebben in de status van de service.

Als u versleuteling voor grote gegevensvolumes wilt schalen, gebruikt u een sleutelhiërarchie. Sla alleen de sleutelcoderingssleutel (KEK) op in Managed HSM en gebruik deze om gegevensversleutelingssleutels op een lager niveau in te pakken die elders in beveiligde sleutelopslag zijn opgeslagen.

Zie Azure Richtlijnen voor het schalen van beheerde HSM's voor meer informatie over prestatiebenchmarks en capaciteitsplanning.

Tolerantie voor partitiefouten

Beheerde HSM bereikt hoge beschikbaarheid via de driedubbele redundante architectuur, waarbij elke HSM-pool bestaat uit drie HSM-partities die zijn verdeeld over afzonderlijke serverrekken binnen een datacenter. Deze distributie op rackniveau biedt redundantie tegen gelokaliseerde hardwarefouten.

Wanneer hardwarestoringen of gelokaliseerde storingen optreden, stuurt Managed HSM uw aanvragen automatisch om naar gezonde partities en herbouwt de betrokken partities via een proces dat confidential service healing wordt genoemd. Mislukte partities worden automatisch opnieuw opgebouwd op gezonde hardware door gebruik te maken van geteste TLS- en Intel SGX-enclaves om geheimen tijdens het herstel te beveiligen.

Cost

De ingebouwde hoge beschikbaarheid in Beheerde HSM voegt geen extra kosten toe. Prijzen zijn gebaseerd op het aantal HSM-pools en het aantal bewerkingen dat u uitvoert. Zie De prijzen van Azure Managed HSM voor meer informatie.

Gedrag wanneer alle partities in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer beheerde HSM-pools operationeel zijn en er geen partities beschikbaar zijn.

• Verkeersroutering: Beheerde HSM beheert automatisch verkeersroutering over de drie partities. Tijdens normale bewerkingen worden aanvragen transparant verdeeld over partities.

• Gegevensreplicatie: Beheerde HSM repliceert synchroon alle gegevens, inclusief sleutels, roltoewijzingen en toegangsbeheerbeleid voor alle drie de partities. Deze benadering zorgt voor consistentie en beschikbaarheid, zelfs als een partitie niet beschikbaar is.

Gedrag bij een partitiefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een of meer partities niet beschikbaar zijn.

• Detectie en reactie: De beheerde HSM-service detecteert partitiefouten en reageert er automatisch op. U hoeft geen actie te ondernemen tijdens een partitiefout.

• Actieve aanvragen: Tijdens een partitiefout kunnen aanvragen tijdens een vlucht naar de betrokken partitie mislukken en moeten clienttoepassingen deze opnieuw proberen. Om de gevolgen van partitiestoringen te minimaliseren, moeten clienttoepassingen de tijdelijke foutafhandelingsprocedures volgen.

• Verwachte gegevensverlies: Er wordt geen gegevensverlies verwacht tijdens een partitiefout vanwege synchrone replicatie tussen partities.

• Verwachte downtime: Voor leesbewerkingen en de meeste cryptografische bewerkingen moet er minimaal of geen downtime zijn tijdens een partitiefout. De resterende gezonde partities blijven aanvragen verwerken.

• Verkeer omleiden: Beheerde HSM routeert verkeer automatisch weg van de betrokken partitie naar gezonde partities zonder tussenkomst van de klant.

Partitieherstel

Wanneer de getroffen partitie herstelt, herstelt Managed HSM automatisch de bewerkingen via vertrouwelijke service-herstel. Dit proces:

1. Hiermee maakt u een nieuwe dienstinstance op gezonde hardware.
2. Hiermee wordt een geteste TLS-verbinding met de primaire partitie tot stand gebracht.
3. Wissel referenties en cryptografisch materiaal veilig uit.
4. De servicegegevens worden gekoppeld aan de nieuwe CPU.

Het Azure platform beheert dit proces volledig en vereist geen tussenkomst van de klant.

Tolerantie voor fouten in beschikbaarheidszones

Hoge beschikbaarheid in beheerde HSM is gebaseerd op distributie op rackniveau binnen een datacenter, niet expliciete implementatie van beschikbaarheidszones. Elke partitie wordt uitgevoerd op een afzonderlijke server in een ander rek, die beschermt tegen storingen op rackniveau, zoals problemen met de voeding of netwerkswitch.

Als u wilt beschermen tegen storingen in de hele datacenter- of beschikbaarheidszone, gebruikt u een van de methoden die worden beschreven in Tolerantie voor storingen in de hele regio.

Tolerantie voor storingen in de hele regio

Beheerde HSM-resources worden geïmplementeerd in één Azure-regio. Als de regio niet meer beschikbaar is, is uw beheerde HSM ook niet beschikbaar. Er zijn echter benaderingen die u kunt gebruiken om tolerantie voor storingen in regio's te garanderen.

Replicatie in meerdere regio's

Beheerde HSM ondersteunt optionele replicatie van meerdere regio's, die u kunt gebruiken om een beheerde HSM-pool uit te breiden van één Azure regio (de primaire regio) naar een tweede Azure regio (de uitgebreide regio). Wanneer u deze functie configureert:

• Beide regio's zijn actief en kunnen aanvragen verwerken.
• Sleutelmateriaal, rollen en machtigingen worden automatisch gerepliceerd tussen regio's.
• Azure Traffic Manager stuurt aanvragen naar de dichtstbijzijnde beschikbare regio.
• De gecombineerde SLA neemt toe.

Vereisten

• Regioondersteuning: Alle regio's die beheerde HSM ondersteunen, kunnen worden gebruikt als primaire regio's. Er is geen afhankelijkheid van Azure-regiokoppelingen.

  Beheerde HSM biedt geen ondersteuning voor alle regio's als uitgebreide regio's. Zie ondersteuning voor Azure-regio's voor meer informatie.

• Maximum aantal regio's: U kunt één uitgebreide regio toevoegen voor maximaal twee regio's in totaal.

Cost

Replicatie voor meerdere regio's veroorzaakt extra facturering omdat de uitgebreide regio een tweede HSM-pool verbruikt. Zie De prijzen van Azure Managed HSM voor meer informatie.

Replicatie voor meerdere regio's configureren

• Een uitgebreide regio toevoegen: Zie Een primaire HSM uitbreiden naar een uitgebreide regio voor meer informatie over het toevoegen van een uitgebreide regio aan een bestaande primaire regio.

  Het uitbreiden van een beheerde HSM naar een andere regio kan tot 30 minuten duren.

• Een uitgebreide regio verwijderen: Zie Een uitgebreide regio verwijderen uit de primaire HSM voor meer informatie over het verwijderen van een uitgebreide regio uit een bestaande primaire regio.

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u replicatie voor meerdere regio's configureert en beide regio's operationeel zijn.

• Verkeersroutering: Alle regio's kunnen aanvragen verwerken. Azure Traffic Manager routeert aanvragen naar de regio met de dichtstbijzijnde geografische nabijheid of laagste latentie.

  Als u Azure Private Link gebruikt voor toegang tot beheerde HSM, configureert u privé-eindpunten in beide regio's voor optimale routering tijdens failover. Zie Het gedrag van Private Link met replicatie in meerdere regio's voor meer informatie.

• Gegevensreplicatie: Alle wijzigingen in sleutels, roldefinities en roltoewijzingen worden asynchroon gerepliceerd naar de uitgebreide regio binnen zes minuten. Wacht zes minuten nadat u een sleutel hebt gemaakt of bijgewerkt voordat u deze in de uitgebreide regio gebruikt.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u replicatie voor meerdere regio's configureert en er een storing optreedt in een van de replicaregio's.

• Detectie en reactie: Azure Traffic Manager detecteert de beschadigde regio en stuurt toekomstige aanvragen door naar de gezonde regio. DNS-records hebben een time-to-live (TTL) van vijf seconden, hoewel clients die DNS-zoekacties in de cache opslaan, mogelijk iets langere failovertijden ervaren.

• Notification: Microsoft geeft u niet automatisch een melding wanneer een regio uitvalt. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele regiofouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Aanvragen tijdens de vlucht naar de getroffen regio kunnen mislukken en moeten opnieuw worden geprobeerd.

• Verwachte gegevensverlies: Wijzigingen die binnen zes minuten zijn aangebracht voordat de regiofout mogelijk niet naar de uitgebreide regio wordt gerepliceerd. Deze wijzigingen kunnen verloren gaan als de primaire regio onherstelbaar is.

• Verwachte downtime: Zowel lees- als schrijfbewerkingen blijven beschikbaar in de regio die in orde is tijdens de failover.

  Clienttoepassingen die zich dicht bij de beschadigde regio bevinden, worden mogelijk naar die regio doorgestuurd totdat de DNS-records worden bijgewerkt, maar deze update vindt binnen ongeveer vijf seconden plaats. Om de failovertijd te minimaliseren, moeten clients voorkomen dat DNS-zoekacties langer in de cache worden opgeslagen dan de TTL van de DNS-record.

• Omleiding: Azure Traffic Manager stuurt aanvragen automatisch om naar de goede regio.

Herstel van de regio

Wanneer de betrokken regio wordt hersteld, worden bewerkingen automatisch hervat door beheerde HSM. Azure Traffic Manager begint opnieuw met het routeren van aanvragen naar beide regio's op basis van nabijheid.

Test voor regiofouten

Beheerde HSM beheert de verkeersroutering, failover en failback volledig voor regiofouten, zodat u geen processen voor regiofouten hoeft te valideren of verdere invoer hoeft op te geven.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Als replicatie met meerdere regio's niet geschikt is voor uw behoeften, kunt u handmatig herstel na noodgevallen implementeren. Voor deze aanpak is het volgende vereist:

• Het beveiligingsdomein van de bron-HSM.
• De persoonlijke sleutels (ten minste het quorumnummer) die het beveiligingsdomein versleutelen.
• Een recente volledige HSM-back-up van de bron HSM.

Herstel na noodgevallen uitvoeren:

1. Maak een nieuw beheerd HSM-exemplaar in een andere regio.
2. Activeer de herstelmodus van het beveiligingsdomein en upload het beveiligingsdomein.
3. Maak een back-up van de nieuwe HSM (vereist voordat u deze herstelt).
4. Herstel de back-up vanaf de bron-HSM.

Zie Beheerde HSM-herstel na noodgevallen voor gedetailleerde procedures voor herstel na noodgevallen.

Backups en herstel

Beheerde HSM ondersteunt volledige back-up en herstel van alle sleutels, versies, kenmerken, tags en roltoewijzingen. Back-ups worden opgeslagen in een Azure Storage-account. Als uw regio dit ondersteunt, raden we u aan een back-up te maken van uw beheerde HSM naar een Azure Storage-account waarvoor GEOGRAFISCH redundante opslag (GRS) is ingeschakeld.

De HSM versleutelt back-ups met behulp van cryptografische sleutels die zijn gekoppeld aan het beveiligingsdomein van de HSM. U kunt alleen back-ups herstellen naar een HSM met hetzelfde beveiligingsdomein.

Beheerde HSM biedt geen ondersteuning voor het plannen van back-ups, maar u kunt uw eigen planner bouwen met behulp van een service zoals Azure Functions of Azure Automation.

Hoewel er een back-up wordt uitgevoerd, werkt de HSM mogelijk niet op volledige doorvoer omdat sommige partities bezig zijn met het uitvoeren van de back-upbewerking.

Zie Volledige back-up en herstel voor gedetailleerde procedures voor back-up en herstel.

Veerkracht tegen onbedoeld verwijderen

Beheerde HSM biedt twee belangrijke herstelfuncties om onbedoelde of schadelijke verwijdering te voorkomen.

• Zacht verwijderen: Verwijderde HSM's en sleutels worden niet direct definitief verwijderd. Ze blijven herstelbaar voor een configureerbare bewaarperiode van 7 tot 90 dagen (standaard: 90 dagen). Voorlopig verwijderen is altijd ingeschakeld en kan niet worden uitgeschakeld.

  Opmerking

  Voorlopig verwijderde beheerde HSM-resources blijven facturering in rekening gebracht totdat ze zijn opgeschoond.

• Beveiliging tegen opschoning: Wanneer deze optie is ingeschakeld, wordt voorkomen dat uw beheerde HSM en de bijbehorende sleutels definitief worden verwijderd totdat de bewaarperiode is verstreken. Beveiliging tegen opschonen kan niet door iedereen worden uitgeschakeld of overschreven, waaronder Microsoft.

We raden u ten zeerste aan om opschoningsbeveiliging in te schakelen voor productieomgevingen. Zie Beheerde HSM-beveiliging voor voorlopig verwijderen en opschonen voor meer informatie.

Tolerantie voor serviceonderhoud

Beheerde HSM verwerkt serviceonderhoud, waaronder firmware-updates, patching en hardwareherstel, zonder tussenkomst van de klant. Tijdens onderhoud:

• De service kan partities tijdelijk niet beschikbaar maken terwijl er updates worden toegepast.
• Ten minste twee van de drie partities blijven beschikbaar tijdens routineonderhoud.
• Uw clienttoepassingen moeten opnieuw geprobeerd logica implementeren om korte onderbrekingen op te vangen.

Het herstelproces van de vertrouwelijke service zorgt ervoor dat de service nooit geheimen blootstelt tijdens onderhoudsbewerkingen.

Diensteniveau-overeenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Beheerde HSM biedt een standaard-SLA voor beschikbaarheid voor implementaties met één regio. Het inschakelen van replicatie in meerdere regio's verhoogt de totale verwachte uptime, omdat aanvragen vanuit een van beide regio's kunnen worden verwerkt als er een niet meer beschikbaar is.

Verwante inhoud

• Wat is Azure Key Vault Beheerde HSM?
• Replicatie voor meerdere regio's inschakelen
• Herstel na noodgevallen voor Beheerde HSM
• Volledige back-up en herstel
• Overzicht van beveiligingsdomein in beheerde HSM
• Beschermingsmechanismen tegen zachte verwijdering en zuiveringsbeveiliging van beheerde HSM
• Richtlijnen voor azure Managed HSM-schaalaanpassing
• Wat is Azure documentatie over betrouwbaarheid?