Geavanceerde aanvraagbeperking met Azure API Management

VAN TOEPASSING OP: Alle API Management-lagen

Het beperken van binnenkomende aanvragen is een belangrijke rol van Azure API Management. Door de snelheid van aanvragen of het totale aantal overgedragen aanvragen/gegevens te beheren, kunnen API Management API-providers hun API's beschermen tegen misbruik en waarde creëren voor verschillende API-productlagen.

Frequentielimieten en quota

Frequentielimieten en quota worden voor verschillende doeleinden gebruikt.

Frequentielimieten

Frequentielimieten worden meestal gebruikt ter bescherming tegen korte en intense volume bursts. Als u bijvoorbeeld weet dat uw back-endservice een knelpunt heeft in de database met een hoog aanroepvolume, kunt u een rate-limit-by-key beleid instellen om een hoog oproepvolume niet toe te staan met behulp van deze instelling.

Let op

Vanwege de gedistribueerde aard van de beperkingsarchitectuur is snelheidsbeperking nooit volledig nauwkeurig. Het verschil tussen geconfigureerde aanvragen en het werkelijke aantal toegestane aanvragen varieert op basis van aanvraagvolume en -frequentie, back-endlatentie en andere factoren.

Targets

Quota's worden meestal gebruikt voor het beheren van oproepfrequenties over een langere periode. Ze kunnen bijvoorbeeld het totale aantal oproepen instellen dat een bepaalde abonnee binnen een bepaalde maand kan doen. Voor het genereren van inkomsten met uw API kunnen quota ook anders worden ingesteld voor abonnementen op basis van lagen. Een abonnement in de Basic-laag kan bijvoorbeeld niet meer dan 10.000 oproepen per maand doen, maar een Premium-laag kan oplopen tot 100.000.000 oproepen per maand.

In Azure API Management worden frequentielimieten doorgaans sneller doorgegeven op de knooppunten om te beschermen tegen pieken. Daarentegen wordt gebruiksquotumgegevens op langere termijn gebruikt en daarom is de implementatie anders.

Notitie

Wanneer onderliggende rekenresources opnieuw worden opgestart in het serviceplatform, kan API Management aanvragen gedurende een korte periode blijven verwerken nadat een quotum is bereikt.

Beperking op basis van producten

Snelheidsbeperkingsmogelijkheden die zijn afgestemd op een bepaald abonnement, zijn handig voor de API-provider om limieten toe te passen voor de ontwikkelaars die zich hebben geregistreerd om hun API te gebruiken. Het helpt echter niet, bijvoorbeeld bij het beperken van afzonderlijke eindgebruikers van de API. Het is mogelijk dat één gebruiker van de toepassing van de ontwikkelaar het volledige quotum verbruikt en vervolgens voorkomt dat andere klanten van de ontwikkelaar de toepassing kunnen gebruiken. Bovendien kunnen verschillende klanten die een groot aantal aanvragen genereren, de toegang tot incidentele gebruikers beperken.

Aangepaste beperking op basis van sleutels

Notitie

De rate-limit-by-key beleidsregels en quota-by-key beleidsregels zijn niet beschikbaar in de verbruikslaag van Azure API Management. Het quota-by-key beleid is momenteel ook niet beschikbaar in de v2-lagen.

Het beleid voor frequentielimiet per sleutel en quota per sleutel biedt een flexibelere oplossing voor verkeerscontrole. Met deze beleidsregels kunt u expressies definiëren om de sleutels te identificeren die worden gebruikt om het gebruik van verkeer bij te houden. De manier waarop dit werkt, is het eenvoudigst geïllustreerd met een voorbeeld.

Beperking van IP-adressen

Het volgende beleid beperkt één CLIENT-IP-adres tot slechts 10 aanroepen per minuut, met in totaal 1.000.000 aanroepen en 10.000 kilobytes aan bandbreedte per maand.

<rate-limit-by-key  calls="10"
          renewal-period="60"
          counter-key="@(context.Request.IpAddress)" />

<quota-by-key calls="1000000"
          bandwidth="10000"
          renewal-period="2629800"
          counter-key="@(context.Request.IpAddress)" />

Als alle clients op internet een uniek IP-adres hebben gebruikt, kan dit een effectieve manier zijn om het gebruik door de gebruiker te beperken. Het is echter waarschijnlijk dat meerdere gebruikers één openbaar IP-adres delen omdat ze toegang hebben tot internet via een NAT-apparaat. Ondanks dit is de beste optie voor API's die niet-geverifieerde toegang IpAddress toestaan.

Beperking van gebruikersidentiteit

Als een eindgebruiker is geverifieerd, kan er een beperkingssleutel worden gegenereerd op basis van informatie die die gebruiker op unieke wijze identificeert.

<rate-limit-by-key calls="10"
    renewal-period="60"
    counter-key="@(context.Request.Headers.GetValueOrDefault("Authorization","").AsJwt()?.Subject)" />

In dit voorbeeld ziet u hoe u de autorisatieheader extraheert, converteert naar JWT object en het onderwerp van het token gebruikt om de gebruiker te identificeren en te gebruiken als de sleutel voor snelheidsbeperking. Als de gebruikersidentiteit wordt opgeslagen in de JWT als een van de andere claims, kan die waarde op zijn plaats worden gebruikt.

Gecombineerd beleid

Hoewel het beperkingsbeleid op basis van gebruikers meer controle biedt dan het beperkingsbeleid op basis van een abonnement, is er nog steeds waarde voor het combineren van beide mogelijkheden. Beperking op basis van productabonnementssleutel (limiet aantal aanroepen per abonnement en gebruiksquotum per abonnement instellen) is een uitstekende manier om geld te verdienen met een API door kosten in rekening te brengen op basis van gebruiksniveaus. De nauwkeurigere controle over het beperken door de gebruiker is complementair en voorkomt dat het gedrag van een gebruiker de ervaring van een andere gebruiker verslechtert.

Clientgestuurde beperking

Wanneer de beperkingssleutel wordt gedefinieerd met behulp van een beleidsexpressie, is dit de API-provider die kiest hoe de beperking wordt beperkt. Een ontwikkelaar kan echter bepalen hoe ze hun eigen klanten beperken. Dit kan worden ingeschakeld door de API-provider door een aangepaste header in te voeren zodat de clienttoepassing van de ontwikkelaar de sleutel kan doorgeven aan de API.

<rate-limit-by-key calls="100"
          renewal-period="60"
          counter-key="@(request.Headers.GetValueOrDefault("Rate-Key",""))"/>

Hierdoor kan de clienttoepassing van de ontwikkelaar kiezen hoe ze de snelheidsbeperkingssleutel willen maken. De clientontwikkelaars kunnen hun eigen tarieflagen maken door sets sleutels toe te wijzen aan gebruikers en het sleutelgebruik te roteren.

Samenvatting

Azure API Management biedt snelheids- en quotumbeperking om uw API-service te beveiligen en er waarde aan toe te voegen. Met het nieuwe beperkingsbeleid met aangepaste bereikregels hebt u meer controle over deze beleidsregels, zodat uw klanten nog betere toepassingen kunnen bouwen. In de voorbeelden in dit artikel wordt het gebruik van dit nieuwe beleid gedemonstreerd door de productiesnelheid te beperken tot sleutels met client-IP-adressen, gebruikersidentiteit en door de client gegenereerde waarden. Er zijn echter veel andere onderdelen van het bericht die kunnen worden gebruikt, zoals gebruikersagent, URL-padfragmenten, berichtgrootte.

Volgende stappen

Geef ons uw feedback als een GitHub-probleem voor dit onderwerp. Het zou geweldig zijn om te horen over andere mogelijke sleutelwaarden die een logische keuze zijn geweest in uw scenario's.