Richtlijnen voor beperkingen in Azure Key Vault

  • Artikel
  • 4 minuten om te lezen

Beperking is een proces dat u start en dat het aantal gelijktijdige aanroepen naar de Azure-service beperkt om te voorkomen dat resources te veel worden gebruikt. Azure Key Vault (AKV) is ontworpen voor het verwerken van een groot aantal aanvragen. Als er een overweldigend aantal aanvragen optreedt, helpt het beperken van de aanvragen van uw client om optimale prestaties en betrouwbaarheid van de AKV-service te behouden.

Beperkingslimieten variëren afhankelijk van het scenario. Als u bijvoorbeeld een groot aantal schrijfvolumes gebruikt, is de kans op bandbreedtebeperking groter dan wanneer u alleen lees- en schrijfvolumes wilt uitvoeren.

Hoe worden Key Vault limieten verwerkt?

Servicelimieten in Key Vault misbruik van resources voorkomen en zorgen voor de kwaliteit van de service voor alle Key Vault van klanten. Wanneer een servicedrempelwaarde wordt overschreden, beperkt Key Vault verdere aanvragen van die client voor een bepaalde tijd, retourneert http-statuscode 429 (te veel aanvragen) en mislukt de aanvraag. Mislukte aanvragen die een 429 retourneren, tellen niet mee voor de vertragingslimieten die door de Key Vault.

Key Vault is oorspronkelijk ontworpen om te worden gebruikt voor het opslaan en ophalen van uw geheimen tijdens de implementatie. De wereld is veranderd en Key Vault wordt tijdens run-time gebruikt om geheimen op te slaan en op te halen, en vaak willen apps en services Key Vault gebruiken als een database. Huidige limieten bieden geen ondersteuning voor hoge doorvoersnelheden.

Key Vault oorspronkelijk gemaakt met de limieten die zijn opgegeven in Azure Key Vault servicelimieten. Hier volgen enkele Key Vault aanbevolen richtlijnen/aanbevolen procedures voor het maximaliseren van uw doorvoer:

  1. Zorg ervoor dat er een beperking is. De client moet zich houden aan exponentieel beleid voor 429-ers en ervoor zorgen dat u nieuwe keren een nieuwe doet volgens de onderstaande richtlijnen.
  2. Verdeel uw Key Vault verkeer over meerdere kluizen en verschillende regio's. Gebruik een afzonderlijke kluis voor elk beveiligings-/beschikbaarheidsdomein. Als u vijf apps hebt, elk in twee regio's, raden we 10 kluizen aan die elk de geheimen bevatten die uniek zijn voor de app en regio. Een abonnementsbrede limiet voor alle transactietypen is vijf keer de limiet voor afzonderlijke sleutelkluizen. Andere HSM-transacties per abonnement zijn bijvoorbeeld beperkt tot 5000 transacties binnen tien seconden per abonnement. Overweeg het geheim in uw service of app in de caching op te nemen om de RPS ook rechtstreeks naar de sleutelkluis te verminderen en/of burst-verkeer te verwerken. U kunt uw verkeer ook verdelen over verschillende regio's om de latentie te minimaliseren en een ander abonnement/andere kluis te gebruiken. Verzend niet meer dan de abonnementslimiet voor de Key Vault service in één Azure-regio.
  3. Cache de geheimen die u opgeeft Azure Key Vault in het geheugen, en gebruik deze waar mogelijk opnieuw uit het geheugen. Lees de gegevens alleen opnieuw Azure Key Vault wanneer de kopie in de cache niet meer werkt (bijvoorbeeld omdat deze is geroteerd op de bron).
  4. Key Vault is ontworpen voor uw eigen servicesgeheimen. Als u de geheimen van uw klanten opslaat (met name voor sleutelopslagscenario's met hoge doorvoer), kunt u overwegen om de sleutels in een database of opslagaccount met versleuteling op te slaan en alleen de hoofdsleutel op te slaan in Azure Key Vault.
  5. Het versleutelen, verpakken en verifiëren van openbare-sleutelbewerkingen kan worden uitgevoerd zonder toegang tot Key Vault, wat niet alleen het risico op beperking vermindert, maar ook de betrouwbaarheid verbetert (zolang u het openbare sleutelmateriaal op de juiste manier in de cache opgeslagen).
  6. Als u een Key Vault voor een service gebruikt, controleert u of die service ondersteuning biedt voor Azure AD-verificatie om rechtstreeks te verifiëren. Dit vermindert de belasting van Key Vault, verbetert de betrouwbaarheid en vereenvoudigt uw code omdat Key Vault nu het Azure AD-token kan gebruiken. Veel services zijn verplaatst naar het gebruik van Azure AD-auth. Zie de huidige lijst op Services die beheerde identiteiten voor Azure-resources ondersteunen.
  7. Overweeg uw belasting/implementatie over een langere periode te belasten om onder de huidige RPS-limieten te blijven.
  8. Als uw app uit meerdere knooppunten bestaat die dezelfde geheim(en) moeten lezen, kunt u overwegen een fan out-patroon te gebruiken, waarbij één entiteit het geheim uit Key Vault leest en alle knooppunten uitvent. Cache de opgehaalde geheimen alleen in het geheugen.

Uw app beperkt als reactie op servicelimieten

Hier volgen de best practices die u moet implementeren wanneer uw service wordt beperkt:

  • Verminder het aantal bewerkingen per aanvraag.
  • Verminder de frequentie van aanvragen.
  • Vermijd onmiddellijke nieuwe nieuwe proberen.
    • Alle aanvragen worden gemaakt op basis van uw gebruikslimieten.

Wanneer u de foutafhandeling van uw app implementeert, gebruikt u de HTTP-foutcode 429 om te detecteren of beperking aan de clientzijde nodig is. Als de aanvraag opnieuw mislukt met een HTTP 429-foutcode, wordt er nog steeds een Azure-servicelimiet aangetroffen. Ga door met het gebruik van de aanbevolen beperkingsmethode aan de clientzijde, waarbij u de aanvraag opnieuw wilt proberen totdat deze is gelukt.

Code die exponentieel afboeking implementeert, wordt hieronder weergegeven.

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

Het gebruik van deze code in een client-C#-toepassing is eenvoudig.

Begin bij HTTP-foutcode 429 uw client te beperken met behulp van een exponentiële back-offbenadering:

  1. Wacht 1 seconde, aanvraag opnieuw proberen
  2. Als de wachttijd nog steeds 2 seconden is beperkt, kunt u de aanvraag opnieuw proberen
  3. Als de wachttijd nog steeds 4 seconden is beperkt, kunt u de aanvraag opnieuw proberen
  4. Als de wachttijd nog steeds 8 seconden is beperkt, kunt u de aanvraag opnieuw proberen
  5. Als de wachttijd nog steeds 16 seconden is beperkt, kunt u de aanvraag opnieuw proberen

Op dit moment zou u geen HTTP 429-responscodes moeten krijgen.

Zie ook

Zie Beperkingspatroon voor een diepere oriëntatie van beperking in de Microsoft Cloud.