Password Manager self-hosted o basati sul cloud?

Alcuni clienti ci hanno chiesto quali sono i pro e i contro di una soluzione di gestione delle password self-hosted, come Bitwarden. Dal momento che ho molta esperienza in materia, ho pensato di condividere alcuni dei motivi principali per utilizzare un Password Manager basato sul cloud come Keeper, invece di una cassaforte password self-hosted.

I vantaggi di una soluzione self-hosted

L’unico vantaggio di una piattaforma di gestione delle password self-hosted che mi viene in mente è quello di un ambiente in cui gli utenti utilizzano solo un computer desktop, in un ambiente di rete air-gapped. Questa situazione non si applica alla stragrande maggioranza degli individui o delle imprese.

I contro di una soluzione self-hosted

Gestione dell’infrastruttura

In una soluzione self-hosted, il cliente è responsabile della distribuzione del container, dell’hosting in un server, del bilanciamento del carico, dei certificati SSL, del routing e del firewall. Il cliente passerà dai compiti di gestione degli utenti finali a quelli di gestione di un’intera piattaforma software. Quando le cose vanno male, situazione molto probabile, l’amministratore ha la responsabilità esclusiva e totale.

Sarà necessaria una competenza nei seguenti ambiti:

• Container Docker
• Docker Swarm per l’alta disponibilità
• Hosting, manutenzione, aggiornamenti e backup dei server di database
• Bilanciamento del carico
• Firewall/applicazione web firewall (WAF)
• Amministrazione dei servizi Windows o Linux
• Patching, backup e ripristino delle istanze
• Amministrazione hardware: installazione e manutenzione continua di server, infrastruttura di rete (router, switch), firewall/appliance di sicurezza, array di storage e sistemi elettrici.
• Manutenzione degli impianti – backup di emergenza dell’alimentazione (generatori, batteria), sicurezza ambientale, fisica e controllo degli accessi.

Keeper è distribuito su un’ampia infrastruttura cloud in più data center geografici, con un team dedicato a tempo pieno di personale DevOps negli Stati Uniti che gestisce, protegge e monitora l’ambiente.

Distribuire impostazioni personalizzate

In una soluzione self-hosted, tutte le applicazioni distribuite devono essere modificate dall’amministratore e da ogni utente finale per includere le impostazioni personalizzate degli endpoint URL. Gli utenti saranno sfidati a farlo e dovranno disporre di una connettività di rete all’endpoint ospitato. Puoi anche imporre queste impostazioni attraverso i criteri di gruppo e la gestione dei dispositivi mobili (MDM), ma questo presuppone che tu abbia il controllo completo di tutti i dispositivi endpoint. Qualsiasi dispositivo al di fuori del tuo controllo deve essere configurato manualmente dall’amministratore o dall’utente.

Le applicazioni per l’utente finale di Keeper non richiedono alcuna configurazione: funzionano subito.

Mancanza di casi d’uso critici

Ci sono diversi casi d’uso che potrebbero non essere disponibili in un’installazione on-premise di un servizio di cassaforte password. Ad esempio:

• La sincronizzazione e i push in tempo reale richiedono la connettività dell’infrastruttura cloud. Per risolvere questo problema, il fornitore può fornire un cloud relay, ma in questo modo si vanifica l’obiettivo del self-hosting.
  
• L’integrazione del Single Sign-On (SSO) con i servizi di gestione delle chiavi on-premise è molto complessa
  .
• L’integrazione con le API richiederà il routing di rete dai server di sviluppo/produzione all’endpoint self-hosted di destinazione.

Keeper offre una sincronizzazione in tempo reale e non richiede alcun servizio on-premise per funzionare o integrarsi con l’SSO. Tutte le API comunicano direttamente con il cloud Keeper, utilizzando la crittografia zero-knowledge. Non sono necessarie modifiche al routing della rete interna.

Vulnerabilità di sicurezza

Per consentire agli utenti finali di accedere alla cassaforte sui loro sistemi remoti o sui loro dispositivi mobili, l’applicazione ospitata deve esporre l’accesso di rete in entrata all’obiettivo. Ciò significa che il servizio sarà pubblicamente accessibile, consentendo a bot e malintenzionati di attaccarlo. Di conseguenza, sarai costretto ad acquistare e implementare una soluzione WAF front-end di terze parti come Cloudflare, AWS Shield, ecc.

Keeper è una soluzione completamente gestita, zero-knowledge, ospitata su Amazon Web Services. Amazon Shield/WAF viene utilizzato per controllare gli attacchi DDoS (Distributed Denial of Service) e altri attacchi bot.

Aggiornamenti software

Con una soluzione self-hosted, tutto il software on-premise deve essere sottoposto a backup, patch, smontaggio e riavvio continuo. Una soluzione di cassaforte in rapida evoluzione richiede molti componenti in movimento e aggiornamenti costanti del prodotto sulle varie piattaforme: web, desktop, mobile, estensioni del browser, ecc. Il rapido ritmo degli aggiornamenti richiederà frequenti patch software per qualsiasi prodotto on-premise. E c’è sempre il rischio che una patch sbagliata o mancata possa causare un problema serio.

Il software di Keeper, su tutte le piattaforme, è sempre aggiornato e patchato con gli ultimi aggiornamenti di sicurezza. Non è richiesto alcun intervento del cliente.

Backup e ripristino

È necessario eseguire il backup di database, server, configurazione e container. Il ripristino deve essere testato e verificato su base continua. Se i backup giornalieri vengono eseguiti da un’istanza on-premise di un database, si corre il rischio di perdere password critiche e riservate nell’arco delle 24 ore.

L’infrastruttura di database di Keeper è multi-regione e multi-zona. I backup dei dati possono essere ripristinati in qualsiasi momento, fino al secondo, entro 30 giorni. Inoltre, la funzione Record History di Keeper fornisce uno storico completo delle modifiche apportate a ogni password o record memorizzato nella piattaforma dall’inizio del tempo.

Insider malintenzionati

In una soluzione self-hosted, l’amministratore ha il pieno controllo del software e dello storage. In questo modo, l’amministratore ha anche la possibilità di prendere il controllo della cassaforte di un utente, persino di quello dei suoi manager e dirigenti di livello superiore.

Se l’amministratore ha costruito il servizio a partire dal codice sorgente, ha anche la possibilità di introdurre bug, vulnerabilità ed escalation di privilegi. Nella maggior parte degli ambienti, i team di gestione e i dirigenti non devono permettere a un amministratore di elevare i propri privilegi e accedere ai contenuti dei caveau degli utenti.

Keeper è costruito utilizzando un’architettura di sicurezza zero-knowledge e zero-trust. Keeper può essere facilmente configurato per creare ruoli di amministratore delegati con autorizzazioni limitate. Gli amministratori di Keeper non hanno mai la possibilità di decifrare le casseforti degli utenti che non gestiscono.

Rischi dell’open source

Mettere a disposizione di una comunità open source l’intero repository del codice sorgente del front-end e del back-end è degno di nota e presenta dei vantaggi in termini di trasparenza. Tuttavia, i vantaggi di sicurezza per la maggior parte delle aziende sono limitati. Se una richiesta di pull da parte di un malintenzionato viene accettata in un progetto open source senza un’adeguata peer review, possono essere introdotte delle vulnerabilità. Il fatto che il codice sorgente sia pubblico non significa che i ricercatori di sicurezza stiano analizzando e testando il codice alla ricerca di vulnerabilità. Le vulnerabilità sono note da anni in molti progetti di codice sorgente pubblico.

Keeper stipula contratti con ricercatori di sicurezza informatica leader del settore per eseguire test di penetrazione trimestrali contro gli obiettivi del software Keeper, sia interni che esterni, con accesso completo al codice sorgente. Keeper ha collaborato inoltre con Bugcrowd per gestire il programma di divulgazione delle vulnerabilità (VDP). Per saperne di più consulta https://bugcrowd.com/keepersecurity.

Le API e i kit di sviluppo software (SDK) di Keeper, come Commander e Secrets Manager, sono di origine pubblica e disponibili sul nostro repository Github.

Lacune nell’audit dovute al ricambio dei dipendenti

Inevitabilmente, un amministratore che ha il controllo di questo ambiente potrebbe finire per lasciare l’organizzazione. In questo modo si rischia di lasciare un sistema non gestito, non manutenuto o insicuro. Inoltre, se l’amministratore viene licenziato o se se ne va in malo modo, non ci sarà alcuna traccia di audit di eventuali comportamenti dannosi (come ad esempio l’acquisizione di copie dei vault degli utenti, l’introduzione di vulnerabilità o la distruzione di dati).

Keeper dispone di un modulo di reportistica avanzata e avvisi (ARAM) che contiene una traccia di audit di tutte le attività degli utenti. Gli amministratori di Keeper non hanno mai accesso diretto ai dati della cassaforte degli utenti finali.

Se hai domande, contattaci via e-mail all’indirizzo: security@keepersecurity.com.