SSL reciproco per i clienti del servizio cloud SaaS

0

La mia azienda sta lanciando un servizio SaaS basato su cloud. Ci saranno clienti di diversi inquilini che si connettono ai nostri servizi tramite SSL reciproco.

I client userebbero una libreria fornita da noi per connettersi al servizio. Questa libreria basata su Java eseguirà SSL reciproco utilizzando keystore e truststores. Quindi sia il server che i clienti sono sotto il nostro controllo. Per sottolineare, non ci sono browser coinvolti nell'intera comunicazione.

Per poter eseguire correttamente l'autenticazione SSL reciproca, è necessario affidarsi a un certificato fornito dal nostro servizio cloud. Questo certificato potrebbe essere:

  1. Un certificato CA pubblico (come Comodo, Verisign ecc.). Ma chiedere ai clienti di fidarsi di una CA pubblica consentirebbe la possibilità di un uomo in attacchi centrali dato che qualcun altro può utilizzare un certificato diverso firmato dalla stessa CA per ingannare i clienti.
  2. CA radice privata di nostra proprietà. Ciò implicherebbe la creazione del nostro servizio PKI e la sicurezza della chiave privata et al. La nostra situazione giustifica la scelta di questa via?
  3. Certificato autofirmato utilizzato da server e client. Un problema che vedo con questa soluzione è che quando il certificato scade, tutti i client attraverso i tenant dovranno riconfigurare il nuovo certificato allo stesso tempo . Sarebbe inaccettabile.

Un'altra opzione che ho trovato è quella di utilizzare una sorta di blocco SSL (certificato o chiave pubblica) che sostituirà la catena di fiducia. Questa non è una soluzione facile da implementare.

Qual è la soluzione consigliata?

    
posta xsreality 11.12.2018 - 11:39
fonte

1 risposta

0

Dato che sia il client che il server sono completamente sotto il tuo controllo, ritengo che sia la cosa migliore (e forse anche la più semplice) da fare affidamento solo sui certificati auto-emessi in modo che non sia necessario fidarsi di qualche CA esterna che è al di fuori di il tuo controllo.

Se hai solo pochi comunicatori, potrebbe essere facile andare con certificati autofirmati e scambiarli quando necessario. Tieni presente che in questo caso puoi semplicemente aggiungere il certificato o la chiave pubblica specifici e ignorare qualsiasi scadenza, revoca ecc. - poiché tutto è comunque sotto il tuo controllo diretto.

Con più coetanei di comunicazione è probabilmente meglio creare la propria struttura PKI, ovvero disporre della propria CA radice che emette i certificati per entrambi i client e i server e che può anche rinnovare e revocare i certificati. Una volta che questa PKI è stata configurata, la gestione dei peer di comunicazione è semplificata dal momento che è sufficiente affidarsi a questa CA specifica (e solo a questa CA). Una semplice struttura PKI potrebbe essere creata già con openssl ma ci sono anche prodotti commerciali che potrebbero fornire una migliore usabilità e anche scalare meglio.

Dato che hai il pieno controllo su client e server è possibile iniziare in modo semplice ed economico (certificati autofirmati), crescere lentamente ma rimanere a buon mercato (CA basato su openssl) e poi passare a un (non così economico) CA aziendale quando sono coinvolti molti clienti.

    
risposta data 11.12.2018 - 13:08
fonte