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 a seconda dei requisiti di riservatezza, integrità e disponibilità dell'applicazione.

Un'integrazione OAuth sicura richiede:

Controlli di sicurezza implementati in tutti i partecipanti OAuth, che includono il server di autorizzazione (IAM), il proprietario della risorsa (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 i partecipanti OAuth (per evitare attacchi di rappresentazione)
Convalida delle informazioni corretta per qualsiasi richiesta (in particolare per i token di accesso JWT (JSON Web Token))
Utilizzo di token con finalità e timeout minimi (per ridurre l'esposizione in caso di divulgazione e per supportare la revoca dei token)
Uso dei principi di sicurezza tipici delle informazioni, come ad esempio i privilegi minimi

Risorse

Per ulteriori informazioni sulla sicurezza di 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 dei suggerimenti di sicurezza

In questa pagina vengono elencati i suggerimenti di sicurezza più rilevanti sotto forma di 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 delle 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 server delle risorse. Ciò impedisce l'intercettazione durante la trasmissione del codice di autorizzazione, dei token di accesso, dei token di aggiornamento, delle credenziali client e delle credenziali utente e impedisce gli attacchi di ripetizione.
Stabilire l'autenticazione del server (HTTPS con convalida CA sicura)

L'autenticazione del server consente ai client, ai server delle risorse e ai proprietari delle risorse di stabilire una comunicazione tra di loro e con un dominio di Identity dopo aver verificato il certificato pubblico sulla CA sicura.

Se il server non fornisce un certificato attendibile (fornito da un'autorità di certificazione attendibile e con un nome host corrispondente), la comunicazione viene considerata un attacco MITM (man-in-the-middle).

L'autenticazione del server impedisce attacchi di spoofing, proxy, man-in-the-middle e phishing per acquisire codici di autorizzazione, token di accesso, credenziali client e credenziali utente.
Considera l'utilizzo di un'asserzione sicura con i domini di Identity

I client di sicurezza critici possono utilizzare un'asserzione client con crittografia delle chiavi (anziché un segreto client) per l'autenticazione.
Proteggere l'URI di reindirizzamento con HTTPS e convalida CA attendibile

Il protocollo HTTPS e l'uso della convalida CA sicura impediscono il phishing del "codice" di autorizzazione e la rappresentazione della sessione utente.

Amministrazione

Configurare le applicazioni in base al principio dei privilegi minimi

Le applicazioni devono essere configurate in un dominio di Identity con solo i diritti minimi necessari per l'operazione.

Ridurre l'ambito, i flussi, i tipi di sovvenzioni 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 dell'applicazione vengono visualizzate per gli utenti nelle pagine Applicazioni personali e del consenso.

L'uso di nomi e descrizioni di applicazioni significative può impedire agli utenti di commettere errori durante l'autorizzazione del consenso e contribuisce anche a migliorare la generazione di report di 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 affidarsi al proprietario della risorsa, fornire 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 e 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 di sicurezza, implementa una rotazione segreta del 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 fornisce trasparenza al proprietario della risorsa e impedisce alle applicazioni di richiedere ambiti non obbligatori.
Conoscenza degli utenti

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

Sviluppo applicazioni

Proteggere codici, token di accesso, token di aggiornamento e credenziali client

Le applicazioni devono preservare 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 cui altre misure di sicurezza dell'applicazione):
- Non memorizzare codici (utilizzare il codice solo durante il runtime per ottenere il token di accesso)
- Conservare i token di accesso nella memoria transitoria e limitarne i privilegi
- Memorizza i token di aggiornamento e le credenziali client in luoghi sicuri a cui l'applicazione può accedere solo
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.
Leggere i token dal file system delle applicazioni native

Gli autori di attacchi potrebbero tentare di ottenere l'accesso al file system sul dispositivo e leggere i token di aggiornamento utilizzando un'applicazione dannosa. Per ridurre questo rischio, memorizza i segreti in un archivio sicuro e usa il blocco del dispositivo per impedire l'accesso non autorizzato al dispositivo.
Implementa controlli per dispositivi clonati e rubati con app native

Per ridurre i rischi quando un dispositivo con app native viene clonato o rubato, utilizzare 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 dell'ambiente di hosting prima di pubblicare l'applicazione per ridurre le vulnerabilità. Le minacce correlate all'hosting e allo sviluppo delle applicazioni non vengono affrontate dai domini di Identity. 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 nell'applicazione.
Applica privilegio minimo durante richiesta scope

Le applicazioni client devono richiedere token che contengano 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 scope e di un token di accesso per concedere diversi livelli di accesso ai domini di Identity, vedere Scope.
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 il token JWT seguendo il profilo JWT per le autorizzazioni di autenticazione client e autorizzazioni client OAuth 2.0 e gli RFC JWT.

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

Nota

I server delle risorse devono elaborare le informazioni solo dopo aver eseguito l'intera convalida JWT.
Ricevi token JWT in modo appropriato

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 le applicazioni client e server delle risorse

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

Non scrivere applicazioni che raccolgono informazioni di autenticazione direttamente dagli utenti.
Impedisci selezione-jacking

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

Per i browser meno recenti, le tecniche di frame-busting JavaScript possono essere utilizzate, ma potrebbero non essere efficaci in tutti i browser.
Evitare l'uso delle credenziali password proprietario 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 del client. Questo tipo di sovvenzione presenta un rischio più elevato perché:
- È responsabile della raccolta delle credenziali utente sull'applicazione client (gestisce l'UID / password anti-pattern).
- Non presenta una schermata di consenso per le richieste di ambito.
Ad eccezione dei motivi di 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.
Evita richieste con informazioni riservate inviate mediante parametri URL

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

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