Autenticazione reciproca [chiusa]

1. Quali sono i diversi tipi di autenticazione reciproca che possono verificarsi tra i componenti dell'infrastruttura? (Es .: tra Server e DB, solo tra i server).

L'autenticazione riguarda dimostrare chi sei (cioè la tua identità). Nell'infrastruttura di un'azienda, potrebbe essere necessario autenticarsi. Queste risorse potrebbero essere applicazioni, dipendenti, ecc. E il metodo di autenticazione potrebbe essere certificati, password, ecc.

L'autenticazione reciproca significa semplicemente che le due risorse devono / vogliono verificare l'identità dell'altro prima di compiere ulteriori passi.

2. Qual è il rischio di non avere alcun tipo di autenticazione reciproca?

Il rischio è lo stesso di non avere alcun tipo di autenticazione (a senso unico): una parte non è sicura con chi ha a che fare. L'impatto dipende dalle risorse interessate.

Facciamo due esempi:

• La maggior parte delle volte, durante la navigazione in HTTPS, solo il server web si autenticherà durante l'handshake TLS. Ad esempio, Google non ha bisogno di te per provare la tua identità prima di darti un'occhiata a che cos'è un Tarsius (Wikipedia). , il cliente (tu) vuole essere sicuro che stia navigando su Google e non su un sito web losco.

• Quando le applicazioni aziendali comunicano tra loro, ciascuna potrebbe dover verificare l'identità dell'altro. (Immagina due applicazioni che gestiscono i bonifici bancari.) In tal caso, supponendo che utilizzino TLS, entrambi controlleranno l'altro certificato. In caso contrario, un utente malintenzionato può impersonare una delle applicazioni e causare problemi alla società.

Non esiste una regola empirica per decidere se è necessaria un'autenticazione reciproca. Devi valutare il rischio per ogni risorsa e decidere se è necessario autenticarsi.