Documentazione dell'infrastruttura Oracle Cloud

Gestione dell'autorizzazione mediante l'API

L'API REST dei domini di Identity supporta sia l'autorizzazione basata su token che le firme delle richieste OCI. Per motivi di sicurezza, l'API REST dei domini di Identity non è accessibile utilizzando solo il nome utente e la password utilizzati per collegarsi al dominio di Identity. Per accedere all'API REST dei domini di Identity, è necessario un token di accesso OAuth2 o una chiave API da utilizzare per l'autorizzazione.

L'API REST dei domini di Identity utilizza il protocollo OAuth 2.0 per l'autenticazione e l'autorizzazione e supporta gli scenari di autorizzazione comuni riportati di seguito.

  • Web server

  • Cellulare

  • JavaScript applicazioni

La sezione Autorizzazione illustra gli scenari OAuth 2.0 supportati dai domini di Identity.

Questa sezione contiene gli argomenti riportati di seguito.

Registrazione di un'applicazione client

Un'applicazione deve essere registrata come client OAuth 2 utilizzando il dominio di Identity. I client OAuth sono client HTTP che possono ottenere e quindi utilizzare un token di accesso.

Completare i passi riportati di seguito per utilizzare un client OAuth per accedere all'API REST dei domini di Identity.

  1. Accedere al dominio di Identity utilizzando il nome utente e la password trovati nell'e-mail di benvenuto.

  2. Creare un'applicazione client OAuth e prendere nota dell'ID client e del segreto client.

    Nota

    Quando si configura l'applicazione client OAuth, selezionare i ruoli applicazione che si desidera assegnare all'applicazione. Ciò consente all'applicazione di accedere alle interfacce API REST a cui possono accedere ciascuno dei ruoli applicazione assegnati. A ogni ruolo applicazione sono assegnati ambiti che definiscono un livello di accesso ancora più esteso alle operazioni API. Ad esempio, selezionare Amministratore dominio di Identity dalla lista. Tutte le operazioni API REST disponibili per l'amministratore del dominio di Identity saranno accessibili all'applicazione.

  3. Utilizzare l'ID client e il segreto client per richiedere un token di accesso dal servizio OAuth IAM.

  4. Includere il token di accesso nell'intestazione HTTP appropriata quando si effettuano chiamate all'API REST.

Ulteriori informazioni

Suggerimenti di sicurezza

Per integrare in modo sicuro le applicazioni con i domini di Identity utilizzando OAuth, è necessario implementare i controlli di sicurezza consigliati dallo standard.

I controlli di sicurezza possono essere considerati obbligatori o facoltativi in base ai requisiti di riservatezza, integrità e disponibilità dell'applicazione in uso.

Un'integrazione sicura OAuth richiede:

  • Controlli di sicurezza implementati in tutti i partecipanti OAuth, che includono il server di autorizzazione (IAM), il proprietario delle risorse (utente), il client e le applicazioni del server delle risorse

  • Riservatezza delle informazioni chiave: codice, access_token, refresh_token, credenziali client e credenziali utente

  • Autenticazione del server stabilita tra OAuth partecipanti (per evitare attacchi di impersonazione)

  • Convalida delle informazioni corretta per qualsiasi richiesta (in particolare per i token di accesso JWT (JSON Web Token))

  • Uso di token con ambiti e timeout minimi (per ridurre l'esposizione in caso di divulgazione e supportare la revoca del token)

  • Uso di principi di sicurezza delle informazioni standard, ad esempio il privilegio minimo

Risorse

Per ulteriori informazioni sulla sicurezza OAuth, accedere ai collegamenti riportati di seguito.

Nota

Si consiglia di monitorare la sicurezza in modo proattivo in modo da poter identificare rapidamente nuove minacce alla sicurezza.

Elenco di controllo suggerimenti per la sicurezza

In questa pagina sono elencati i suggerimenti di sicurezza più pertinenti come elenco di controllo, in modo da poter convalidare la sicurezza dell'applicazione e risolvere gli elementi di sicurezza in base alle proprie aspettative.

Cifratura

  • Uso di TLS nelle applicazioni client e server risorse

    L'uso di TLS con tutte le applicazioni garantisce la riservatezza nelle comunicazioni tra il dominio di Identity, i proprietari delle risorse, le applicazioni client e le applicazioni del server delle risorse. Ciò impedisce l'interscambio durante la trasmissione del codice di autorizzazione, dei token di accesso, dei token di aggiornamento, delle credenziali client e delle credenziali utente e previene gli attacchi di ripetizione.

  • Stabilisci autenticazione server (HTTPS con convalida CA sicura)

    L'autenticazione del server consente ai client, ai server delle risorse e ai proprietari delle risorse di stabilire la comunicazione tra se stessi e con un dominio di Identity dopo aver verificato il certificato pubblico rispetto alla CA sicura.

    Se il server non fornisce un certificato attendibile (fornito da una CA attendibile e con un nome host corrispondente), la comunicazione viene considerata un attacco MIT (man-in-the-middle).

    L'autenticazione del server impedisce gli attacchi di spoofing, proxy, man-in-the-middle e phishing per acquisire i codici di autorizzazione, i token di accesso, le credenziali client e le credenziali utente.

  • Considera l'uso di un'asserzione attendibile con i domini di Identity

    I client di sicurezza critici possono utilizzare un'asserzione client con crittografia chiave (anziché un segreto client) per l'autenticazione.

  • Proteggi URI di reindirizzamento con HTTPS e convalida CA sicura

    HTTPS e l'utilizzo della convalida CA sicura impedisce il phishing del "codice" di autorizzazione e la rappresentazione della sessione utente.

Amministrazione

  • Configurare le applicazioni in base al principio di privilegio minimo

    Le applicazioni devono essere configurate in un dominio di Identity con solo i diritti minimi necessari per il funzionamento.

    Limitare l'ambito, i flussi, i tipi di sovvenzione e le operazioni migliora la postura della sicurezza e riduce l'impatto di un'applicazione compromessa.

  • Fornire un nome e una descrizione significativi per le applicazioni

    Le informazioni sull'applicazione vengono visualizzate per gli utenti nelle pagine Applicazioni personali e di consenso.

    L'uso di nomi e descrizioni significative delle applicazioni può impedire agli utenti di commettere errori durante l'autorizzazione del consenso e contribuisce anche a migliorare la segnalazione degli audit.

  • Fornire una descrizione significativa per gli ambiti

    La descrizione dell'ambito viene visualizzata nella pagina del consenso. Spiegare l'ambito, che l'utente sta per concedere, in modo comprensibile impedisce all'utente di commettere errori durante l'autorizzazione e contribuisce a migliorare la generazione di report di audit.

  • Evita ambiti forniti senza consenso

    Per sfruttare la trasparenza e fare affidamento sul proprietario della risorsa, fornire gli ambiti senza autorizzazione solo quando un ambito è obbligatorio e l'utente non deve essere in grado di negarlo.

  • Ridurre il timeout del token di accesso e utilizzare i token di aggiornamento

    I domini di Identity supportano JWT, un token di accesso che può essere convalidato nei server delle risorse senza controllare il token nel dominio di Identity. Per questo motivo, i token di accesso con lunga durata non possono essere facilmente revocati.

    Per implementare la revoca tempestiva, è possibile configurare il token di accesso con una breve durata, quindi utilizzare il token di aggiornamento per richiedere nuovi token di accesso. Per eseguire una revoca tempestiva, è necessario revocare il token di aggiornamento.

  • Ruota i segreti client dell'applicazione

    Per le implementazioni critiche per la sicurezza, implementare una rotazione dei segreti client. Ciò riduce il rischio di ottenere un segreto client compromesso esplorato.

Proprietario risorsa (utente)

  • Mantieni informato il proprietario della risorsa

    L'uso dell'ambito con il consenso garantisce trasparenza al proprietario della risorsa e impedisce alle applicazioni di richiedere ambiti non obbligatori.

  • Consapevolezza utente

    Insegna agli utenti come proteggere le proprie credenziali e identificare client, applicazione server delle risorse e legittimità del dominio di Identity (in particolare quando vengono visualizzate le pagine di autenticazione e consenso). Ciò riduce il rischio di attacchi di phishing e la compromissione delle credenziali utente.

Sviluppo delle applicazioni

  • Proteggi codici, token di accesso, aggiorna token e credenziali client

    Le applicazioni devono mantenere la riservatezza dei codici, dei token di accesso, dei token di aggiornamento e delle credenziali client. Quando si sviluppa l'applicazione, prendere in considerazione le seguenti misure (tra le altre misure di sicurezza dell'applicazione):

    • Non memorizzare i codici (utilizzare il codice solo durante il runtime per ottenere il token di accesso)

    • Mantieni i token di accesso nella memoria transitoria e limitane le autorizzazioni

    • Memorizza i token di aggiornamento e le credenziali client in posizioni sicure a cui è possibile accedere solo dall'applicazione

  • Proteggi URL di reindirizzamento

    L'URL di reindirizzamento (da cui il dominio di Identity recupera il codice di autorizzazione) è considerato un componente chiave per la sicurezza OAuth. Prestare attenzione quando si definisce questo URL per evitare minacce quali la falsificazione di richieste tra siti e la negazione del servizio.

  • Lettura dei token dal file system delle applicazioni native

    Gli autori di attacchi possono cercare di ottenere l'accesso al file system sul dispositivo e leggere i token di aggiornamento utilizzando un'applicazione dannosa. Per ridurre questo rischio, archivia i segreti nell'archiviazione sicura e utilizza il blocco del dispositivo per impedire l'accesso non autorizzato al dispositivo.

  • Implementa controlli per dispositivi clonati e rubati con applicazioni native

    Per ridurre i rischi quando un dispositivo con app native viene clonato o rubato, utilizza il blocco del dispositivo per impedire l'accesso non autorizzato e revocare i token di aggiornamento.

  • Convalida sicurezza applicazione prima della pubblicazione

    Eseguire il test della sicurezza dell'applicazione e del relativo ambiente di hosting prima di pubblicare l'applicazione per ridurre le vulnerabilità. Le minacce relative all'hosting e allo sviluppo delle applicazioni non vengono affrontate dai domini di identità. Queste minacce includono, a titolo esemplificativo, l'accesso indiretto ai database e allo storage delle applicazioni, il select-jacking, lo scripting cross-site, l'inserimento di script/SQL e i flussi di riservatezza delle informazioni sull'applicazione.

  • Applica privilegio minimo durante richiesta ambito

    Le applicazioni client devono richiedere token contenenti solo ambiti che verranno eventualmente o effettivamente utilizzati.

    L'uso di urn:opc:idm:__myscopes__ scope, anche se conveniente, può recuperare più token di quanto necessario dall'applicazione client.

    Un token con ambiti estesi può aumentare l'impatto sulla sicurezza quando un token viene compromesso.

    Per informazioni sull'uso del parametro di ambito e di un token di accesso per concedere livelli diversi di accesso ai domini di Identity, vedere Scopes.

  • Convalida token JWT

    Quando si riceve un token di accesso (JWT) da qualsiasi parte (ad eccezione del server del dominio di Identity in una richiesta diretta dall'applicazione), convalidare JWT seguendo il profilo JWT per le autorizzazioni di autenticazione e autorizzazione client OAuth 2.0 e le RFC JWT.

    Per ulteriori informazioni su come convalidare il token, vedere Convalida token.

    Nota

    I server risorse devono elaborare le informazioni solo dopo l'esecuzione dell'intera convalida JWT.

  • Ricezione corretta dei token JWT

    Le applicazioni server risorse devono ricevere il token di accesso utilizzando solo l'intestazione Authorization: bearer <token> per evitare minacce correlate all'inserimento dei parametri nella cache.

  • Implementare TLS a 2 vie tra applicazioni client e server risorse

    Per le applicazioni di importanza critica per la sicurezza, è possibile implementare un TLS a 2 vie tra le applicazioni client e server delle risorse per ridurre il rischio di attacchi di negazione del servizio (DoS) e di attacchi di rappresentazione.

    Non scrivere applicazioni che raccolgono informazioni di autenticazione direttamente dagli utenti.

  • Impedisci selezione-rivestimento

    Per i browser più recenti, evitare iFrames durante l'autorizzazione applicando l'uso dell'intestazione X-FRAME-OPTIONS.

    Per i browser più vecchi, le tecniche di frame-busting JavaScript possono essere utilizzate ma potrebbero non essere efficaci in tutti i browser.

  • Evitare l'uso delle credenziali password del proprietario della risorsa

    Il flusso del proprietario della risorsa consente a un client di richiedere un token di accesso utilizzando l'ID, la password e le credenziali dell'utente finale. Questo tipo di sovvenzione presenta un rischio maggiore perché:

    • È responsabile della raccolta delle credenziali utente sull'applicazione client (mantiene l'anti-pattern UID/password).

    • Non presenta una schermata di consenso per le richieste di ambito.

    Ad eccezione dei motivi della migrazione, evitare l'uso di questo tipo di privilegio.

  • Utilizzare l'intestazione Cache-Control="no-store"

    Questa intestazione riduce al minimo il rischio di non proteggere il contenuto autenticato e la perdita di dati riservati nei proxy HTTP.

  • Evitare le richieste con informazioni riservate inviate utilizzando i parametri URL

    I parametri URL (utilizzati nelle richieste GET) possono essere registrati in qualsiasi componente tra applicazioni quali log dell'applicazione, server proxy, firewall e componenti perimetrali di rete.

    I domini di Identity implementano endpoint REST di ricerca alternativa utilizzando POST che risolve questo rischio. Per ulteriori informazioni, vedere la pagina Parametri query.