Riktlinjer för begränsning i Azure Key Vault
Begränsning är en process som du initierar som begränsar antalet samtidiga anrop till Azure-tjänsten för att förhindra överanvändning av resurser. Azure Key Vault (AKV) har utformats för att hantera ett stort antal begäranden. Om ett överväldigande antal begäranden inträffar hjälper begränsning av klientens begäranden till att bibehålla optimal prestanda och tillförlitlighet för AKV-tjänsten.
Begränsningsgränserna varierar beroende på scenariot. Om du till exempel utför en stor mängd skrivningar är risken för begränsning högre än om du bara utför läsningar.
Hur hanterar Key Vault dess gränser?
Tjänstbegränsningar i Key Vault förhindrar missbruk av resurser och säkerställer tjänstkvaliteten för alla Key Vault klienterna. När ett tröskelvärde för tjänsten överskrids begränsar Key Vault ytterligare begäranden från klienten under en viss tidsperiod, returnerar HTTP-statuskod 429 (för många begäranden) och begäran misslyckas. Misslyckade begäranden som returnerar 429 räknas inte mot begränsningsgränserna som spåras av Key Vault.
Key Vault utformades ursprungligen för att användas för att lagra och hämta dina hemligheter vid distributionen. Världen har utvecklats och Key Vault används vid körning för att lagra och hämta hemligheter, och ofta vill appar och tjänster använda Key Vault som en databas. Aktuella gränser stöder inte höga dataflödeshastigheter.
Key Vault skapades ursprungligen med de gränser som anges i Azure Key Vault tjänstbegränsningar. Här är några Key Vault rekommenderade riktlinjer/metodtips för att maximera dataflödet för att maximera dataflödet för att maximera dina dataflöden:
- Kontrollera att det finns begränsningar. Klienten måste respektera exponentiella backend-principer för 429-talet och se till att du gör återförsök enligt riktlinjerna nedan.
- Dela upp Key Vault trafik mellan flera valv och olika regioner. Använd ett separat valv för varje säkerhets-/tillgänglighetsdomän. Om du har fem appar, var och en i två regioner, rekommenderar vi 10 valv som innehåller hemligheterna som är unika för appen och regionen. En prenumerationsomfattande gräns för alla transaktionstyper är fem gånger den enskilda gränsen för nyckelvalv. Till exempel är HSM-andra transaktioner per prenumeration begränsade till 5 000 transaktioner på 10 sekunder per prenumeration. Överväg att cachelagra hemligheten i din tjänst eller app för att även minska RPS direkt till nyckelvalvet och/eller hantera burst-baserad trafik. Du kan också dela upp trafiken mellan olika regioner för att minimera svarstiden och använda en annan prenumeration/ett annat valv. Skicka inte mer än prenumerationsgränsen till Key Vault i en enda Azure-region.
- Cachelagra hemligheterna som du hämtar Azure Key Vault i minnet och återanvänd från minnet när det är möjligt. Läs om från Azure Key Vault när den cachelagrade kopian slutar fungera (t.ex. eftersom den roterades vid källan).
- Key Vault är utformad för dina egna tjänsthemligheter. Om du lagrar dina kunders hemligheter (särskilt i scenarier med nyckellagring med högt dataflöde) bör du överväga att placera nycklarna i en databas eller ett lagringskonto med kryptering och bara lagra huvudnyckeln i Azure Key Vault.
- Kryptera, omsluta och verifiera åtgärder med offentlig nyckel kan utföras utan åtkomst till Key Vault, vilket inte bara minskar risken för begränsning, utan även förbättrar tillförlitligheten (så länge du cachelagrar det offentliga nyckelmaterialet korrekt).
- Om du använder Key Vault för att lagra autentiseringsuppgifter för en tjänst kontrollerar du om tjänsten stöder Azure AD-autentisering för direktautentisering. Detta minskar belastningen på Key Vault, förbättrar tillförlitligheten och förenklar koden eftersom Key Vault nu kan använda Azure AD-token. Många tjänster har flyttats till att använda Azure AD-autentisering. Se den aktuella listan under Tjänster som stöder hanterade identiteter för Azure-resurser.
- Överväg att sprida belastningen/distributionen under en längre tidsperiod för att hålla dig under de aktuella RPS-gränserna.
- Om din app består av flera noder som behöver läsa samma hemligheter bör du överväga att använda ett förfjärrmönster, där en entitet läser hemligheten från Key Vault och fläktar ut till alla noder. Cachelagra endast hämtade hemligheter i minnet.
Så här begränsar du din app som svar på tjänstbegränsningar
Följande är metodtips som du bör implementera när tjänsten begränsas:
- Minska antalet åtgärder per begäran.
- Minska frekvensen för begäranden.
- Undvik omedelbara återförsök.
- Alla begäranden ackumuleras mot dina användningsgränser.
När du implementerar appens felhantering använder du HTTP-felkoden 429 för att identifiera behovet av begränsning på klientsidan. Om begäran misslyckas igen med en HTTP 429-felkod uppstår fortfarande en gräns för Azure-tjänsten. Fortsätt att använda den rekommenderade begränsningsmetoden på klientsidan och försök igen tills den lyckas.
Kod som implementerar exponentiell backoff visas nedan.
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);
Det är enkelt att använda den här koden i ett C#-klientprogram.
Rekommenderad begränsningsmetod på klientsidan
På HTTP-felkod 429 börjar du att minska klienten med en exponentiell backoff-metod:
- Vänta 1 sekund, försök igen
- Om väntetiden är begränsad i 2 sekunder försöker du igen
- Om väntetiden är begränsad i 4 sekunder försöker du igen
- Om väntetiden är begränsad i 8 sekunder försöker du igen
- Om väntetiden fortfarande är begränsad 16 sekunder försöker du igen
I det här läget bör du inte få HTTP 429-svarskoder.
Se även
En djupare orientering för begränsning i Microsoft Cloud finns i Begränsningsmönster.