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.com
leggen. 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