Delen via


Azure Key Vault REST API-foutcodes

De volgende foutcodes kunnen worden geretourneerd door een bewerking in een Azure Key Vault-webservice.

HTTP 401: Niet-geverifieerde aanvraag

401 betekent dat de aanvraag niet is geverifieerd voor Key Vault.

Een aanvraag wordt geverifieerd als:

  • De sleutelkluis kent de identiteit van de beller; en
  • De beller mag toegang krijgen tot Key Vault-resources.

Er zijn verschillende redenen waarom een aanvraag 401 kan retourneren.

Er is geen verificatietoken gekoppeld aan de aanvraag

Hier volgt een voorbeeld van een PUT-aanvraag, waarbij de waarde van een geheim wordt ingesteld:

PUT https://putreqexample.vault.azure.net//secrets/DatabaseRotatingPassword?api-version=7.0 HTTP/1.1
x-ms-client-request-id: 03d275a2-52a4-4bed-82c8-6fe15165affb
accept-language: en-US
Authorization: Bearer     eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5iQ3dXMTF3M1hrQi14VWFYd0tSU0xqTUhHUSIsImtpZCI6Im5iQ3dXMTF3M1hrQi14VWFYd0tSU0xqTUhHUSJ9.eyJhdWQiOiJodHRwczovL3ZhdWx0LmF6dXJlLm5ldCIsImlzcyI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0LzcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0Ny8iLCJpYXQiOjE1NDg2OTc1MTMsIm5iZiI6MTU0ODY5NzUxMywiZXhwIjoxNTQ4NzAxNDEzLCJhaW8iOiI0MkpnWUhoODVqaVBnZHF5ZlRGZE5TdHY3bGUvQkFBPSIsImFwcGlkIjoiZmFkN2Q1YjMtNjlkNi00YjQ4LTkyNTktOGQxMjEyNGUxY2YxIiwiYXBwaWRhY3IiOiIxIiwiaWRwIjoiaHR0cHM6Ly9zdHMud2luZG93cy5uZXQvNzJmOTg4YmYtODZmMS00MWFmLTkxYWItMmQ3Y2QwMTFkYjQ3LyIsIm9pZCI6IjM5NzVhZWVkLTdkMDgtNDUzYi1iNmY0LTQ0NWYzMjY5ODA5MSIsInN1YiI6IjM5NzVhZWVkLTdkMDgtNDUzYi1iNmY0LTQ0NWYzMjY5ODA5MSIsInRpZCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsInV0aSI6IjItZ3JoUmtlSWs2QmVZLUxuNDJtQUEiLCJ2ZXIiOiIxLjAifQ.fgubiz1MKqTJTXI8dHIV7t9Fle6FdHrkaGYKcBeVRX1WtLVuk1QVxzIFDlZKLXJ7QPNs0KWpeiWQI9IWIRK-8wO38yCqKTfDlfHOiNWGOpkKddlG729KFqakVf2w0GPyGPFCONRDAR5wjQarN9Bt8I8YbHwZQz_M1hztlnv-Lmsk1jBmech9ujD9-lTMBmSfFFbHcqquev119V7sneI-zxBZLf8C0pIDkaXf1t8y6Xr8CUJDMdlWLslCf3pBCNIOy65_TyGvy4Z4AJryTPBarNBPwOkNAtjCfZ4BDc2KqUZM5QN_VK4foP64sVzUL6mSr0Gh7lQJIL5b1qIpJxjxyQ
User-Agent: FxVersion/4.7.3324.0 OSName/Windows OSVersion/6.2.9200.0 Microsoft.Azure.KeyVault.KeyVaultClient/3.0.3.0
Content-Type: application/json; charset=utf-8
Host: putreqexample.vault.azure.net
Content-Length: 31

{
   "value": "m*gBJ7$Zuoz)"
}

De header Autorisatie is het toegangstoken dat vereist is bij elke aanroep van de Key Vault voor bewerkingen in het gegevensvlak. Als de header ontbreekt, moet het antwoord 401 zijn.

Het token ontbreekt aan de juiste resource die eraan is gekoppeld

Wanneer u een toegangstoken aanvraagt vanuit het Azure OAUTH-eindpunt, is een parameter met de naam 'resource' verplicht. De waarde is belangrijk voor de tokenprovider omdat deze het token bereikt voor het beoogde gebruik. De resource voor alle tokens voor toegang tot een Key Vault is https://vault.keyvault.net (zonder afsluitende slash).

Het token is verlopen

Tokens zijn base64 gecodeerd en de waarden kunnen worden gedecodeerd op websites zoals http://jwt.calebb.net. Dit is het bovenstaande token gedecodeerd:

    {
 typ: "JWT",
 alg: "RS256",
 x5t: "nbCwW11w3XkB-xUaXwKRSLjMHGQ",
 kid: "nbCwW11w3XkB-xUaXwKRSLjMHGQ"
}.
{
 aud: "https://vault.azure.net",
 iss: "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
 iat: 1548697513,
 nbf: 1548697513,
 exp: 1548701413,
 aio: "42JgYHh85jiPgdqyfTFdNStv7le/BAA=",
 appid: "fad7d5b3-69d6-4b48-9259-8d12124e1cf1",
 appidacr: "1",
 idp: "https://sts.windows.net/72f988bf-86f1-41af-91ab-2d7cd011db47/",
 oid: "3975aeed-7d08-453b-b6f4-445f32698091",
 sub: "3975aeed-7d08-453b-b6f4-445f32698091",
 tid: "72f988bf-86f1-41af-91ab-2d7cd011db47",
 uti: "2-grhRkeIk6BeY-Ln42mAA",
 ver: "1.0"
}.
[signature]

We kunnen veel belangrijke onderdelen in dit token zien:

  • aud (doelgroep): de resource van het token. U ziet dat dit is https://vault.azure.net. Dit token werkt niet voor resources die niet expliciet overeenkomen met deze waarde, zoals grafiek.
  • iat (uitgegeven op): Het aantal tikken sinds het begin van het tijdvak toen het token werd uitgegeven.
  • nbf (niet eerder): Het aantal tikken sinds het begin van het tijdvak wanneer dit token geldig wordt.
  • exp (vervaldatum): het aantal tikken sinds het begin van het tijdvak wanneer dit token verloopt.
  • appid (toepassings-id): de GUID voor de toepassings-id die deze aanvraag doet.
  • tid (tenant-id): de GUID voor de tenant-id van de principal die deze aanvraag indient

Het is belangrijk dat alle waarden correct worden geïdentificeerd in het token om de aanvraag te laten werken. Als alles klopt, resulteert de aanvraag niet in 401.

Problemen met 401 oplossen

401's moeten worden onderzocht vanaf het moment van het genereren van tokens, voordat de aanvraag wordt ingediend bij de sleutelkluis. Over het algemeen wordt code gebruikt om het token aan te vragen. Zodra het token is ontvangen, wordt het doorgegeven aan de Key Vault-aanvraag. Als de code lokaal wordt uitgevoerd, kunt u Fiddler gebruiken om de aanvraag/reactie op vast te https://login.microsoftonline.comleggen. Een aanvraag ziet er als volgt uit:


POST https://login.microsoftonline.com/<key vault tenant ID>/oauth2/token HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded; charset=utf-8
Host: login.microsoftonline.com
Content-Length: 192

resource=https%3A%2F%2Fvault.azure.net&client_id=<registered-app-ID>&client_secret=<registered-app-secret>&client_info=1&grant_type=client_credentials

De volgende door de gebruiker opgegeven informatie moet juist zijn:

  • De tenant-id van de sleutelkluis
  • Resourcewaarde ingesteld op https%3A%2F%2Fvault.azure.net (URL gecodeerd)
  • Client-id
  • Clientgeheim

Zorg ervoor dat de rest van de aanvraag bijna identiek is.

Als u alleen het toegangstoken voor antwoorden kunt ophalen, kunt u dit decoderen om ervoor te zorgen dat de tenant-id, de client-id (app-id) en de resource worden gebruikt.

HTTP 403: Onvoldoende machtigingen

HTTP 403 betekent dat de aanvraag is geverifieerd (deze kent de aangevraagde identiteit), maar de identiteit heeft geen toegang tot de aangevraagde resource. Er zijn twee oorzaken:

  • Er is geen toegangsbeleid voor de identiteit.
  • Het IP-adres van de aanvraagresource wordt niet goedgekeurd in de firewallinstellingen van de sleutelkluis.

HTTP 403 treedt vaak op wanneer de toepassing van de klant niet de client-id gebruikt die de klant denkt te hebben. Dit betekent meestal dat het toegangsbeleid niet juist is ingesteld voor de werkelijke aanroepende identiteit.

Als u direct na het toevoegen van een identiteit aan het toegangsbeleid een 403-fout krijgt, kunt u deze afhandelen door periodiek opnieuw te proberen.

Problemen met 403 oplossen

Schakel eerst logboekregistratie in. Zie Logboekregistratie van Azure Key Vault voor instructies over hoe u dit doet.

Nadat logboekregistratie is ingeschakeld, kunt u bepalen of de 403 wordt veroorzaakt door toegangsbeleid of firewallbeleid.

Fout vanwege firewallbeleid

"Clientadres (00.00.00.00) is niet geautoriseerd en beller is geen vertrouwde service"

Er is een beperkte lijst met vertrouwde Azure-services. Azure-websites behoren niet tot de vertrouwde Azure-services. Zie het blogbericht Vertrouwde services voor meer informatie.

U moet het IP-adres van de Azure-website toevoegen aan de sleutelkluis om dit te laten werken.

Als gevolg van toegangsbeleid: zoek de object-id voor de aanvraag en zorg ervoor dat de object-id overeenkomt met het object waaraan de gebruiker het toegangsbeleid probeert toe te wijzen. Er zijn vaak meerdere objecten in Microsoft Entra ID, die dezelfde naam hebben, dus het kiezen van de juiste is belangrijk. Door het toegangsbeleid te verwijderen en te lezen, is het mogelijk om te zien of er meerdere objecten bestaan met dezelfde naam.

Bovendien is voor het meeste toegangsbeleid het gebruik van de geautoriseerde toepassing niet vereist, zoals wordt weergegeven in de portal. Geautoriseerde toepassingen worden gebruikt voor 'on-behalf-of'-verificatiescenario's, die zelden voorkomen.

HTTP 429: Te veel aanvragen

Beperking treedt op wanneer het aantal aanvragen het opgegeven maximum voor het tijdsbestek overschrijdt. Als er beperking optreedt, is de reactie van Key Vault HTTP 429. Er zijn maximumaantallen voor typen aanvragen. Bijvoorbeeld: het maken van een HSM 2048-bits sleutel is 10 aanvragen per 10 seconden, maar alle andere HSM-transacties hebben een limiet van 2000 aanvragen/10 seconden. Daarom is het belangrijk om te begrijpen welke typen aanroepen worden gedaan bij het bepalen van de oorzaak van beperking. Over het algemeen zijn aanvragen voor de Key Vault beperkt tot 4.000 aanvragen/10 seconden. Uitzonderingen zijn sleutelbewerkingen, zoals beschreven in de servicelimieten van Key Vault

429-problemen oplossen

Het probleem met beperking kan met de volgende technieken worden omzeild:

  • Verminder het aantal aanvragen voor Key Vault door vast te stellen of er patronen zijn voor een aangevraagde resource en door te proberen deze in de cache van de aanroepende toepassing op te slaan.

  • Wanneer Key Vault-beperking optreedt, past u de aanvraagcode aan om een exponentieel uitstel te gebruiken voor het opnieuw proberen. Het algoritme wordt hier uitgelegd: Uw app beperken

  • Als het aantal aanvragen niet kan worden verminderd door opslag in de cache en een getimed uitstel niet werkt, kunt u overwegen de sleutels op te splitsen in meerdere sleutelkluizen. De servicelimiet voor één abonnement is vijf maal de afzonderlijke Key Vault-limiet. Als u meer dan vijf Key Vaults gebruikt, moet u rekening houden met het gebruik van meerdere abonnementen.

Gedetailleerde richtlijnen, waaronder aanvragen om limieten te verhogen, vindt u hier: Richtlijnen voor beperking van Key Vault