Richtlijnen voor beperkingen in Azure Key Vault

  • Artikel

Beperking is een proces dat u initieert waarmee het aantal gelijktijdige aanroepen naar de Azure-service wordt 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, kunt u de aanvragen van uw client beperken om optimale prestaties en betrouwbaarheid van de AKV-service te behouden.

Beperkingslimieten variëren op basis van het scenario. Als u bijvoorbeeld een groot aantal schrijfbewerkingen uitvoert, is de mogelijkheid tot beperking groter dan wanneer u alleen leesbewerkingen uitvoert.

Hoe verwerkt Key Vault de limieten?

Servicelimieten in Key Vault voorkomen misbruik van resources en zorgen voor de kwaliteit van de service voor alle clients van Key Vault. Wanneer een servicedrempel wordt overschreden, beperkt Key Vault eventuele verdere aanvragen van die client, retourneert HTTP-statuscode 429 (Te veel aanvragen) en mislukt de aanvraag. Mislukte aanvragen die een 429 retourneren, tellen niet mee voor de beperkingslimieten die door Key Vault worden bijgehouden.

Key Vault is oorspronkelijk ontworpen om uw geheimen op te slaan en op te halen tijdens de implementatie. De wereld is ontwikkeld en Key Vault wordt tijdens runtime 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 is oorspronkelijk gemaakt met de limieten die zijn opgegeven in azure Key Vault-servicelimieten. Als u de doorvoersnelheden van Key Vault wilt maximaliseren, volgen hier enkele aanbevolen richtlijnen/aanbevolen procedures voor het maximaliseren van uw doorvoer:

  1. Zorg ervoor dat u een beperking hebt. De client moet exponentieel back-off-beleid voor 429's respecteren en ervoor zorgen dat u nieuwe pogingen doet volgens de onderstaande richtlijnen.
  2. Verdeel uw Key Vault-verkeer tussen 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 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. U kunt het geheim in de cache opslaan in uw service of app om de RPS ook rechtstreeks naar de sleutelkluis te verminderen en/of burst-verkeer af te handelen. U kunt uw verkeer ook verdelen over verschillende regio's om latentie te minimaliseren en een ander abonnement/kluis te gebruiken. Verzend niet meer dan de abonnementslimiet naar de Key Vault-service in één Azure-regio.
  3. Cache de geheimen die u uit Azure Key Vault in het geheugen ophaalt en gebruik indien mogelijk opnieuw uit het geheugen. Lees opnieuw vanuit Azure Key Vault wanneer de kopie in de cache niet meer werkt (bijvoorbeeld omdat deze bij de bron is gedraaid).
  4. Key Vault is ontworpen voor uw eigen servicesgeheimen. Als u de geheimen van uw klanten opslaat (met name voor opslagscenario's met hoge doorvoersleutels), kunt u de sleutels in een database of opslagaccount met versleuteling plaatsen en alleen de primaire sleutel opslaan in Azure Key Vault.
  5. Versleutelen, verpakken en verifiëren van openbare-sleutelbewerkingen kunnen 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 goed in de cache opgeslagen).
  6. Als u Key Vault gebruikt om referenties voor een service op te slaan, controleert u of die service ondersteuning biedt voor Microsoft Entra-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 Microsoft Entra-token kan gebruiken. Veel services zijn verplaatst naar het gebruik van Microsoft Entra-verificatie. Bekijk de huidige lijst in Services die beheerde identiteiten voor Azure-resources ondersteunen.
  7. Overweeg om uw belasting/implementatie gedurende een langere periode te spokken om onder de huidige RPS-limieten te blijven.
  8. Als uw app bestaat uit meerdere knooppunten die dezelfde geheimen moeten lezen, kunt u overwegen om een fan-outpatroon te gebruiken, waarbij één entiteit het geheim uit Key Vault leest en uitwaaieert naar alle knooppunten. Cache de opgehaalde geheimen alleen in het geheugen.

Uw app beperken als reactie op servicelimieten

Hier volgen de aanbevolen procedures die u moet implementeren wanneer uw service wordt beperkt:

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

Wanneer u de foutafhandeling van uw app implementeert, gebruikt u de HTTP-foutcode 429 om de noodzaak van beperking aan de clientzijde te detecteren. Als de aanvraag opnieuw mislukt met een HTTP 429-foutcode, ondervindt u nog steeds een Azure-servicelimiet. Blijf de aanbevolen beperkingsmethode aan de clientzijde gebruiken en voer de aanvraag opnieuw uit totdat deze is geslaagd.

Hier volgt code waarmee exponentieel uitstel wordt geïmplementeerd:

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.

Bij HTTP-foutcode 429 kunt u beginnen met het beperken van uw client met behulp van een exponentiële back-offbenadering:

  1. 1 seconde wachten, aanvraag opnieuw proberen
  2. Als de beperking nog steeds wordt toegepast, wacht u 2 seconden en probeert u de aanvraag opnieuw
  3. Als de beperking nog steeds wordt toegepast, wacht u 4 seconden en probeert u de aanvraag opnieuw
  4. Als de beperking nog steeds wordt toegepast, wacht u 8 seconden en probeert u de aanvraag opnieuw
  5. Als de beperking nog steeds wordt toegepast, wacht u 16 seconden en probeert u de aanvraag opnieuw

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

Zie ook

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