Delen via

Multitenancy en Azure Key Vault

  • Artikel

Azure Key Vault wordt gebruikt voor het beheren van beveiligde gegevens voor uw oplossing, waaronder geheimen, versleutelingssleutels en certificaten. In dit artikel beschrijven we enkele van de functies van Azure Key Vault die nuttig zijn voor multitenant-oplossingen. Vervolgens bieden we koppelingen naar de richtlijnen die u kunnen helpen, wanneer u van plan bent hoe u Key Vault gaat gebruiken.

Isolatiemodellen

Wanneer u met een systeem met meerdere tenants werkt met Key Vault, moet u een beslissing nemen over het isolatieniveau dat u wilt gebruiken. De keuze van isolatiemodellen die u gebruikt, is afhankelijk van de volgende factoren:

  • Hoeveel tenants wilt u hebben?
  • Deelt u uw toepassingslaag tussen meerdere tenants, implementeert u exemplaren van toepassingsexemplaren met één tenant of implementeert u afzonderlijke implementatiestempels voor elke tenant?
  • Moeten uw tenants hun eigen versleutelingssleutels beheren?
  • Hebben uw tenants nalevingsvereisten waarvoor hun geheimen afzonderlijk van de geheimen van andere tenants moeten worden opgeslagen?

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenancymodellen voor Key Vault:

Overweging Kluis per tenant, in het abonnement van de provider Kluis per tenant, in het abonnement van de tenant Gedeelde kluis
Gegevensisolatie Hoog Zeer hoog Beperkt
Isolatie van prestaties Gemiddeld. Hoge doorvoer kan beperkt zijn, zelfs met veel kluizen Hoog Beperkt
Implementatiecomplexiteit Laag/gemiddeld, afhankelijk van het aantal tenants Hoog. De tenant moet de provider op de juiste manier toegang verlenen Beperkt
Operationele complexiteit Hoog Laag voor de provider, hoger voor de tenant Laagste
Voorbeeldscenario Afzonderlijke toepassingsexemplaren per tenant Door de klant beheerde versleutelingssleutels Grote multitenant-oplossing met een gedeelde toepassingslaag

Kluis per tenant, in het abonnement van de provider

U kunt overwegen om een kluis te implementeren voor elk van uw tenants binnen uw Azure-abonnement (de serviceprovider). Deze benadering biedt een sterke gegevensisolatie tussen de gegevens van elke tenant, maar vereist dat u een toenemend aantal kluizen implementeert en beheert, terwijl u het aantal tenants verhoogt.

Er is geen limiet voor het aantal kluizen dat u in een Azure-abonnement kunt implementeren. Houd echter rekening met de volgende limieten:

Kluis per tenant, in het abonnement van de tenant

In sommige situaties kunnen uw tenants kluizen maken in hun eigen Azure-abonnementen en ze willen uw toepassing mogelijk toegang verlenen om te werken met geheimen, certificaten of sleutels. Deze methode is geschikt wanneer u door de klant beheerde sleutels (CMK's) toestaat voor versleuteling binnen uw oplossing.

Om toegang te krijgen tot de gegevens in de kluis van uw tenant, moet de tenant uw toepassing toegang geven tot hun kluis. Voor dit proces moet uw toepassing worden geverifieerd via hun Microsoft Entra-exemplaar. Eén benadering is het publiceren van een Multitenant Microsoft Entra-toepassing. Uw tenants moeten een eenmalig toestemmingsproces uitvoeren. Ze registreren eerst de multitenant Microsoft Entra-toepassing in hun eigen Microsoft Entra-tenant. Vervolgens verlenen ze uw multitenant Microsoft Entra-toepassing het juiste toegangsniveau tot hun kluis. Ze moeten u ook de volledige resource-id opgeven van de kluis die ze hebben gemaakt. Vervolgens kan uw toepassingscode een service-principal gebruiken die is gekoppeld aan de multitenant Microsoft Entra-toepassing in uw eigen Microsoft Entra-id, voor toegang tot de kluis van elke tenant.

U kunt ook elke tenant vragen om een service-principal te maken voor uw service die moet worden gebruikt en om u de referenties ervan te geven. Deze aanpak vereist echter dat u referenties veilig opslaat en beheert voor elke tenant, wat een mogelijke beveiligingsaansprakelijkheid is.

Als uw tenants netwerktoegangsbeheer voor hun kluizen configureren, moet u ervoor zorgen dat u toegang hebt tot de kluizen.

Gedeelde kluizen

U kunt ervoor kiezen om de geheimen van tenants binnen één kluis te delen. De kluis wordt geïmplementeerd in uw Azure-abonnement (de oplossingsprovider) en u bent verantwoordelijk voor het beheren ervan. Deze benadering is eenvoudigst, maar biedt de minste gegevensisolatie en prestatie-isolatie.

U kunt er ook voor kiezen om meerdere gedeelde kluizen te implementeren. Als u bijvoorbeeld het patroon Implementatiestempels volgt, implementeert u waarschijnlijk een gedeelde kluis binnen elke zegel. Als u een oplossing voor meerdere regio's implementeert, moet u om de volgende redenen kluizen in elke regio implementeren:

  • Om latentie tussen regio's te voorkomen bij het werken met de gegevens in uw kluis.
  • Ter ondersteuning van vereisten voor gegevenslocatie.
  • Als u het gebruik van regionale kluizen binnen andere services wilt inschakelen waarvoor implementaties in dezelfde regio zijn vereist.

Wanneer u met een gedeelde kluis werkt, is het belangrijk om rekening te houden met het aantal bewerkingen dat u uitvoert voor de kluis. Bewerkingen omvatten het lezen van geheimen en het uitvoeren van versleutelings- of ontsleutelingsbewerkingen. Key Vault legt limieten op voor het aantal aanvragen dat kan worden gedaan voor één kluis en voor alle kluizen binnen een Azure-abonnement. Zorg ervoor dat u de richtlijnen voor beperking volgt. Het is belangrijk om de aanbevolen procedures te volgen, waaronder het veilig opslaan van de geheimen die u ophaalt en envelopversleuteling gebruikt om te voorkomen dat elke versleutelingsbewerking naar Key Vault wordt verzonden. Wanneer u deze aanbevolen procedures volgt, kunt u grootschalige oplossingen uitvoeren voor één kluis.

Als u tenantspecifieke geheimen, sleutels of certificaten wilt opslaan, kunt u overwegen een naamconventie te gebruiken, zoals een naamgevingsvoorvoegsel. U kunt bijvoorbeeld de tenant-id vooraf laten gaan aan de naam van elk geheim. Vervolgens kan uw toepassingscode eenvoudig de waarde van een specifiek geheim voor een specifieke tenant laden.

Functies van Azure Key Vault die ondersteuning bieden voor multitenancy

Tags

Key Vault biedt ondersteuning voor het taggen van geheimen, certificaten en sleutels met aangepaste metagegevens, zodat u een tag kunt gebruiken om de tenant-id voor elk tenantspecifiek geheim bij te houden. Key Vault biedt echter geen ondersteuning voor het uitvoeren van query's op tags, dus deze functie is het meest geschikt voor beheerdoeleinden, in plaats van voor gebruik in uw toepassingslogica.

Meer informatie:

Ondersteuning voor Azure Policy

Als u besluit een groot aantal kluizen te implementeren, is het belangrijk om ervoor te zorgen dat ze voldoen aan een consistente standaard voor netwerktoegangsconfiguratie, logboekregistratie en toegangsbeheer. Overweeg het gebruik van Azure Policy om te controleren of de kluizen zijn geconfigureerd volgens uw vereisten.

Meer informatie:

Beheerde HSM en toegewezen HSM

Als u een groot aantal bewerkingen per seconde moet uitvoeren en de limieten voor de Key Vault-bewerking onvoldoende zijn, kunt u overwegen beheerde HSM of Toegewezen HSM te gebruiken. Beide producten bieden u een gereserveerde hoeveelheid capaciteit, maar ze zijn meestal duurder dan Key Vault. Houd bovendien rekening met de limieten voor het aantal exemplaren van deze services dat u in elke regio kunt implementeren.

Meer informatie:

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

  • John Downs | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

Bekijk de implementatie- en configuratiemethoden voor multitenancy.