Betrouwbaarheid in beheerde HSM van Azure Key Vault

Azure Key Vault Managed HSM is een volledig beheerde, maximaal beschikbare, single-tenant cloudservice die voldoet aan standaarden. Hiermee kunt u cryptografische sleutels voor uw cloudtoepassingen beveiligen met behulp van hardwarebeveiligingsmodules (HSM's) die zijn gevalideerd volgens FIPS 140-3 niveau 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, hardwarestoringen en regio-storingen. Ook wordt beschreven hoe u back-ups en het beveiligingsdomein kunt gebruiken om te herstellen van andere soorten problemen, en herstelfuncties om onbedoeld verwijderen te voorkomen worden aangegeven, en wordt enkele belangrijke informatie over de beheerde HSM-service level agreement (SLA) gegeven.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productiewerkzaamheden raden we u aan het volgende te doen:

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u beheerde HSM gebruikt, implementeert u een exemplaar, dat ook wel een pool wordt genoemd.

Beheerde HSM is ontworpen voor hoge beschikbaarheid en duurzaamheid via de architectuur:

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

  • Drie redundante partities: een beheerde HSM-pool bestaat uit drie HSM-partities met gelijke taakverdeling, verdeeld over afzonderlijke racks 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-medewerkers, waaronder medewerkers met fysieke toegang tot de servers, hebben geen toegang tot uw cryptografische sleutelmateriaal.

  • Automatisch herstellen: als een hardwarefout of een 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 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.

Belangrijk

Zonder het beveiligingsdomein is herstel na noodgevallen niet mogelijk. Microsoft kan het beveiligingsdomein niet herstellen en heeft geen toegang tot uw sleutels zonder dit domein.

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 lucht-gapped (zoals een on-premises HSM of een geïsoleerd werkstation).
  • Offline opslaan: Bewaar beveiligingsdomeinsleutels op versleutelde USB-stations of andere offlineopslag, waarbij elke sleutelshare op een afzonderlijk apparaat op afzonderlijke geografische locaties staat.
  • Een quorum voor meerdere personen 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 wanneer ze rechtstreeks communiceren met beheerde HSM, inclusief exponentieel uitstelbeleid.

  • 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. Voor openbare-sleutelbewerkingen, zoals versleuteling, wrapping en verificatie, voert u deze bewerkingen lokaal uit door het materiaal van de openbare sleutel in de cache op te cachen. Het lokaal uitvoeren van de bewerkingen vermindert de afhankelijkheid van uw beheerde HSM en voorkomt tijdelijke fouten bij het onderbreken van deze bewerkingen.

Als u Beheerde HSM gebruikt in scenario's met hoge doorvoer, houd er dan rekening mee dat Beheerde HSM cryptografische bewerkingen niet beperkt. 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.

Voor het schalen van de versleuteling van grote hoeveelheden gegevens gebruikt u een sleutelhiërarchie waarbij alleen de sleutelversleutelingssleutel (KEK) wordt opgeslagen in beheerde HSM en wordt gebruikt voor het verpakken van sleutels op lager niveau die zijn opgeslagen op een andere opslaglocatie voor beveiligde sleutels.

Zie Richtlijnen voor het schalen van Azure Managed HSM voor gedetailleerde prestatiebenchmarks en richtlijnen voor 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.

Diagram met de drie partities van een beheerde HSM-pool, elk op een afzonderlijke fysieke server en in een ander serverrek.

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 met behulp van geteste TLS- en Intel SGX-enclaves om geheimen tijdens het herstel te beveiligen.

Cost

Er zijn geen extra kosten verbonden aan de ingebouwde hoge beschikbaarheid in Beheerde HSM. De prijzen zijn gebaseerd op het aantal HSM-pools en het aantal uitgevoerde bewerkingen. 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: alle gegevens, inclusief sleutels, roltoewijzingen en beleidsregels voor toegangsbeheer, worden synchroon gerepliceerd voor alle drie de partities. Dit zorgt voor consistentie en beschikbaarheid, zelfs als een partitie niet meer 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 is verantwoordelijk voor het detecteren van partitiefouten en het automatisch reageren hierop. U hoeft geen actie te ondernemen tijdens een partitiefout.

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

  • Verwacht 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 tot geen downtime zijn tijdens een partitiefout. De resterende gezonde partities blijven aanvragen verwerken.

  • Verkeer omleiden: Beheerde HSM routeert verkeer automatisch 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

De hoge beschikbaarheid van 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 bestand moet zijn tegen storingen in datacenters of beschikbaarheidszones, kunt u overwegen een van de benaderingen te gebruiken voor 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, waarmee u een beheerde HSM-pool kunt uitbreiden van één Azure-regio (de primaire regio) naar een tweede Azure-regio (de uitgebreide regio). Zodra deze is geconfigureerd:

  • Beide regio's zijn actief en kunnen aanvragen verwerken.
  • Belangrijk materiaal, rollen en machtigingen worden automatisch gerepliceerd tussen regio's.
  • Aanvragen worden doorgestuurd naar de dichtstbijzijnde beschikbare regio met behulp van Azure Traffic Manager.
  • De gecombineerde SLA neemt toe.

Vereisten

  • Regioondersteuning: Alle door Azure beheerde HSM-regio's worden ondersteund 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 in meerdere regio's veroorzaakt extra facturering omdat er een tweede HSM-pool wordt gebruikt in de uitgebreide regio. Zie De prijzen van Azure Managed HSM voor meer informatie.

Replicatie voor meerdere regio's configureren

Gedrag wanneer alle regio's in orde zijn

Wanneer replicatie voor meerdere regio's is ingeschakeld 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 Private Link gebruikt, configureert u privé-eindpunten in beide regio's voor optimale routering tijdens een 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

Wanneer replicatie voor meerdere regio's is ingeschakeld en één regio een storing ondervindt:

  • Detectie en reactie: Azure Traffic Manager detecteert de beschadigde regio en stuurt toekomstige aanvragen naar de gezonde regio. DNS-records hebben een TTL van vijf seconden, hoewel clients die DNS-zoekopdrachten opslaan in de cache mogelijk iets langer 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 betrokken regio kunnen mislukken en moeten opnieuw worden geprobeerd.

  • Verwacht gegevensverlies: er kunnen gegevensverlies zijn voor wijzigingen die binnen zes minuten vóór de regiofout zijn aangebracht als deze wijzigingen de replicatie niet hadden voltooid.

  • 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. Traffic Manager begint 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. Hiervoor 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.

Belangrijk

De nieuwe HSM heeft een andere naam en service-eindpunt-URI. U moet uw toepassingsconfiguratie bijwerken om de nieuwe locatie te kunnen gebruiken.

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.

Back-ups worden versleuteld met behulp van cryptografische sleutels die zijn gekoppeld aan het beveiligingsdomein van de HSM en kunnen alleen worden hersteld 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:

  • Voorlopig verwijderen: wanneer u een HSM of een sleutel verwijdert, blijft deze herstelbaar voor een configureerbare bewaarperiode (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.

  • Bescherming tegen permanent verwijderen: Wanneer ingeschakeld, wordt de permanente verwijdering van uw Managed HSM en de bijbehorende sleutels voorkomen 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:

  • Partities zijn mogelijk tijdelijk niet beschikbaar terwijl 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 geheimen nooit worden blootgesteld 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 implementaties met één regio. Wanneer u replicatie voor meerdere regio's inschakelt, neemt de gecombineerde SLA voor beide regio's toe.

Verwante inhoud

  • Last updated on