L'autenticazione reciproca TLS è la tua opzione più sicura ed è quella che generalmente raccomando per l'autenticazione da server a server, fatta eccezione per una situazione molto specifica e meno comune che spiegherò più avanti. L'autenticazione del certificato reciproco TLS è più sicura dell'autenticazione della password perché con l'autenticazione del certificato TLS, le chiavi private non vengono mai inviate nella comunicazione. Con un'autenticazione con chiave pre-condivisa (nota anche come password), il token segreto può essere compromesso solo da un'intercettazione andata a buon fine e poiché entrambi i lati del server gestiscono necessariamente il token segreto in un punto o in un altro, quindi è possibile compromettere entrambi gli autenticatori semplicemente compromettendo un lato della connessione. L'autenticazione del certificato limita l'impatto in quanto solo un lato della credenziale è compromesso.
Con l'autenticazione reciproca TLS da server a server, hai la possibilità di utilizzare una CA pubblica, che costa una piccola somma di denaro ma ti consente di esternalizzare la complessità dell'esecuzione di un'autorità di certificazione di root a qualcuno con un'esperienza adeguata per farlo oppure puoi eseguire una radice privata, quindi non devi fidarti di una terza parte con la sicurezza della tua rete di sistemi. Ci sono pro e contro di ciascuno, e dovresti considerarli attentamente.
However, my understanding is client certificate can also get stolen.
Qualsiasi credenziale può essere rubata, ecco perché è necessario proteggere i server e creare piani di emergenza per queste situazioni. Se hai una situazione in cui sei preoccupato per il furto della chiave privata, hai due opzioni:
- Nella maggior parte dei casi, è possibile progettare processi e procedure in modo da poter revocare e sostituire rapidamente il certificato rubato. Ciò potrebbe significare che dovresti utilizzare un certificato di origine che genera i certificati peer e / o hai bisogno di un modo per revocare e distribuire rapidamente nuove root a tutti i server che devono autenticarsi a vicenda.
- Se si dispone di una situazione in cui è estremamente difficile sostituire la radice della fiducia, ad esempio se si dispone di milioni di macchine gestite da centinaia o migliaia di aziende / singoli individui, si vuole davvero proteggere la radice della fiducia. In questo caso, dovresti fare il n. 1 e utilizzare anche un modulo di sicurezza hardware. Un HSM è un token hardware che memorizza la chiave privata e esegue operazioni di crittografia in modo che la chiave non lasci mai l'HSM. HSM consente di convertire il rischio di proteggere il server dalla sicurezza fisica del furto fisico dell'HSM stesso.
La mia altra raccomandazione potrebbe essere necessaria se hai una situazione in cui hai bisogno dell'autenticazione end-to-end, in cui il tuo modello di sicurezza è tale che i server non sono considerati parte fidata nella comunicazione tra gli utenti di entrambi i server. L'esempio più comune di questo è l'e-mail e la chat crittografate end-to-end. In questo caso, si desidera aggiungere un'autenticazione e una crittografia a livello di applicazione, in modo tale che i server non abbiano mai la chiave privata dell'utente e non possano quindi impersonare i propri utenti. In questo modello di sicurezza, gli utenti si fidano direttamente degli altri utenti, ma non si fidano necessariamente del server se non come semplice agente di consegna. La mia raccomandazione è di utilizzare GPG o qualsiasi altra cosa che implementa il Double Ratchet come il protocollo Signal.
In alternativa, OAuth / OAuth2 potrebbe essere necessario quando è necessaria un'autenticazione a tre gambe: utente / applicazione, server di identità e server di risorse. A meno che tu non abbia una situazione a tre gambe, probabilmente non hai davvero bisogno della complessità di OAuth / OAuth2.
In addition, if we do IP restriction, will it make the integration much safer?
Se hai già un'autenticazione corretta, renderà l'integrazione leggermente più sicura, ma non molto. La restrizione IP è davvero utile solo contro gli attacchi DoS perché il firewall IP è relativamente economico da applicare con un firewall di livello 3, ma di per sé non è sufficiente per alcun tipo di autenticazione e non ha la restrizione IP di solito non è la fine del mondo.