Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure Key Vault offre due tipi di contenitori per archiviare e gestire i segreti per le applicazioni cloud:
| Tipo di contenitore | Tipi di oggetto supportati | Endpoint del piano dati |
|---|---|---|
| Insiemi di credenziali |
|
https://<vault-name>.vault.azure.net |
| HSM gestito |
|
https://<hsm-name>.managedhsm.azure.net |
Ecco i suffissi degli URL usati per accedere a ogni tipo di oggetto
| Tipo di oggetto | Suffisso URL |
|---|---|
| Chiavi con protezione software | /chiavi |
| Chiavi con protezione HSM | /chiavi |
| Segreti | /secrets |
| Certificati | /certificati |
Azure Key Vault supporta richieste e risposte in formato JSON. Le richieste ai Azure Key Vault vengono indirizzate a un URL di Azure Key Vault valido usando HTTPS con alcuni parametri URL e corpi di richiesta e risposta con codifica JSON.
Questo articolo illustra le specifiche per il servizio Azure Key Vault. Per informazioni generali sull'uso di interfacce REST Azure, tra cui autenticazione/autorizzazione e su come acquisire un token di accesso, vedere Azure Informazioni di riferimento sulle API REST.
Struttura URL richiesta
Le operazioni di gestione delle chiavi usano verbi HTTP, tra cui DELETE, GET, PATCH e PUT. Le operazioni di crittografia sugli oggetti chiave esistenti usano HTTP POST.
Per i client che non supportano verbi HTTP specifici, Azure Key Vault consente di usare HTTP POST con l'intestazione />
Per usare gli oggetti nella Azure Key Vault, di seguito sono riportati gli URL di esempio:
Per CREARE una chiave denominata TESTKEY in un Key Vault usare -
PUT /keys/TESTKEY?api-version=<api-version> HTTP/1.1Per IMPORTAre una chiave denominata IMPORTKEY in un Key Vault usare -
POST /keys/IMPORTEDKEY/import?api-version=<api-version> HTTP/1.1Per ottenere un segreto chiamato MYSECRET in un Key Vault, usare -
GET /secrets/MYSECRET?api-version=<api-version> HTTP/1.1Per firmare un digest usando una chiave denominata TESTKEY in un Key Vault, usa -
POST /keys/TESTKEY/sign?api-version=<api-version> HTTP/1.1L'autorizzazione per una richiesta a un Key Vault è sempre la seguente:
- Per gli insiemi di credenziali:
https://<vault-name>.vault.azure.net/ - Per i moduli di protezione hardware gestiti:
https://{HSM-name}.managedhsm.azure.net/le chiavi vengono sempre archiviate nel percorso /keys, mentre i segreti vengono sempre archiviati nel percorso /secrets.
- Per gli insiemi di credenziali:
Versioni dell'API supportate
Il servizio Azure Key Vault supporta il controllo delle versioni del protocollo per garantire la compatibilità con i client di livello inferiore, anche se non tutte le funzionalità sono disponibili per tali client. I client devono usare il api-version parametro della stringa di query per specificare la versione del protocollo supportato perché non esiste un valore predefinito.
Le versioni dei protocolli di Azure Key Vault seguono uno schema di numerazione delle date utilizzando il formato {AAAA}.{MM}.{DD}.
Requisiti corpo della richiesta
In base alla specifica HTTP, le operazioni GET non devono avere un corpo della richiesta e le operazioni POST e PUT devono avere un corpo della richiesta. Il corpo delle operazioni DELETE è opzionale in HTTP.
Se non diversamente indicato nella descrizione dell'operazione, il tipo di contenuto del corpo della richiesta deve essere application/json e deve contenere un oggetto JSON serializzato conforme al tipo di contenuto.
Se non diversamente indicato nella descrizione dell'operazione, l'intestazione Accept request deve contenere il tipo di supporto application/json.
Formato del corpo della risposta
Se non diversamente indicato nella descrizione dell'operazione, il tipo di contenuto del corpo della risposta delle operazioni riuscite e non riuscite è application/json e contiene informazioni dettagliate sull'errore.
Uso di HTTP POST come alternativa
Alcuni client potrebbero non essere in grado di usare determinati verbi HTTP, ad esempio PATCH o DELETE. Azure Key Vault supporta HTTP POST come alternativa per questi client se il client include anche l'intestazione "X-HTTP-METHOD" per specificare il verbo HTTP originale. Il supporto per HTTP POST è indicato per ogni API definita in questo documento.
Gestione delle risposte agli errori
La gestione degli errori usa codici di stato HTTP. I risultati tipici sono:
2xx - Successo: Usato per operazioni normali. Il corpo della risposta contiene il risultato previsto
3xx - Reindirizzamento: il 304 "Non modificato" può essere restituito per soddisfare un GET condizionale. Altri codici 3xx possono essere usati in futuro per indicare le modifiche al DNS e al percorso.
4xx - Errore client: usato per richieste non valide, chiavi mancanti, errori di sintassi, parametri non validi, errori di autenticazione e così via. Il corpo della risposta contiene una spiegazione dettagliata dell'errore.
5xx - Errore del server: usato per gli errori interni del server. Il corpo della risposta contiene informazioni di errore riepilogate.
Il sistema è progettato per funzionare dietro un proxy o un firewall. Pertanto, un client potrebbe ricevere altri codici di errore.
Azure Key Vault restituisce anche informazioni sull'errore nel corpo della risposta quando si verifica un problema. Il corpo della risposta è in formato JSON e assume il formato seguente:
{
"error":
{
"code": "BadArgument",
"message":
"’Foo’ is not a valid argument for ‘type’."
}
}
}
Requisiti di autenticazione
Tutte le richieste di Azure Key Vault DEVONO essere autenticate. Azure Key Vault supporta Microsoft Entra token di accesso che possono essere ottenuti usando OAuth2 [RFC6749].
Per altre informazioni sulla registrazione dell'applicazione e sull'autenticazione da usare Azure Key Vault, vedere Registrare l'applicazione client con Microsoft Entra ID.
I token di accesso devono essere inviati al servizio usando l'intestazione di autorizzazione HTTP:
PUT /keys/MYKEY?api-version=<api-version> HTTP/1.1
Authorization: Bearer <access-token>
Quando non viene fornito un token di accesso o quando il servizio non accetta un token, viene restituito un errore HTTP 401 al client e include l'intestazione WWW-Authenticate, ad esempio:
401 Not Authorized
WWW-Authenticate: Bearer authorization="…", resource="…"
I parametri nell'intestazione WWW-Authenticate sono:
authorization: indirizzo del servizio di autorizzazione OAuth2 che può essere usato per ottenere un token di accesso per la richiesta.
resource: nome della risorsa (
https://vault.azure.net) da usare nella richiesta di autorizzazione.
Annotazioni
Key Vault client SDK per segreti, certificati e chiavi nella prima chiamata a Key Vault non forniscono un token di accesso per recuperare le informazioni del tenant. Si prevede di ricevere un HTTP 401 utilizzando il client SDK di Key Vault, in cui il Key Vault mostra all'applicazione l'intestazione WWW-Authenticate che contiene la risorsa e il tenant a cui deve andare per richiedere il token. Se tutto è configurato correttamente, la seconda chiamata dall'applicazione a Key Vault conterrà un token valido e avrà esito positivo.