Per Keeper la sicurezza delle credenziali e la protezione dei dati sono fondamentali

Panoramica

Keeper Security, Inc. si impegna con passione a proteggere le informazioni dei propri clienti con il software di sicurezza per dispositivi mobili e desktop Keeper. Milioni di utenti privati e aziende si affidano a Keeper per proteggere e accedere alle loro password e informazioni private.

Il software di Keeper viene costantemente migliorato e aggiornato per fornire ai nostri clienti la tecnologia e la protezione più avanzate. Questa pagina fornisce una panoramica dell'architettura di sicurezza, delle metodologie di crittografia e dell'ambiente di hosting di Keeper nella versione attualmente pubblicata. In questo documento viene descritta una panoramica dei dettagli tecnici relativi ai nostri metodi di crittografia e sicurezza.

La nostra Informativa sulla privacy e le nostre Condizioni d'uso sono disponibili sul nostro sito web tramite i seguenti link:

Piattaforma zero-trust

Keeper utilizza un'architettura zero-trust, che garantisce che ogni utente debba essere verificato e autenticato prima di poter accedere a un sito web, a un'applicazione o a un sistema.

Keeper Enterprise Password Management (EPM) offre alle aziende una visibilità e un controllo totali sulle pratiche adottate dai dipendenti con le password, consentendo agli amministratori IT di monitorare l'uso delle password e di applicare le migliori pratiche di sicurezza.

Keeper Secrets Manager (KSM) offre ai team di ingegneri una piattaforma per la gestione di tutte le credenziali, comprese le chiavi segrete dell'infrastruttura, le chiavi SSH, le chiavi API e i certificati con SDK e integrazione CI/CD.

Keeper Connection Manager (KCM) è un gateway per il desktop remoto che offre ai team DevOps e IT un accesso di rete zero-trust (ZTNA) senza intoppi a RDP, SSH, database, applicazioni web interne ed endpoint Kubernetes attraverso un browser web, senza bisogno di agenti.

Scopri tutto sulle soluzioni di sicurezza offerte da Keeper

Crittografia dei dati della cassetta di sicurezza

Keeper offre un modello di crittografia a più livelli basato sui privilegi minimi. Le chiavi AES a 256 bit a livello di voce e le chiavi a livello di cartella vengono generate sul dispositivo client e crittografano ogni voce memorizzata nella cassetta di sicurezza. Le voci della cassetta di sicurezza e tutti i suoi contenuti sono completamente crittografati, compresi i login, gli allegati ai file, i codici TOTP, le informazioni di pagamento, gli URL e i campi personalizzati.

Le chiavi di crittografia sono generate localmente sul dispositivo per preservare la zero knowledge e supportare funzionalità avanzate come la condivisione di voci e cartelle. Zero knowledge significa che ogni utente ha il controllo completo sulla crittografia e sulla decrittografia di tutte le informazioni personali contenute nella propria cassetta di sicurezza di Keeper e che nessuna delle sue informazioni archiviate è accessibile a terzi, nemmeno ai dipendenti di Keeper.

Le chiavi delle voci e le chiavi delle cartelle sono crittografate da una chiave dati AES a 256 bit, unica per ogni utente e generata sul dispositivo dell'utente.

Sul dispositivo dell'utente viene generata un'altra chiave client AES a 256 bit per la crittografia di una cache offline locale (se l'amministratore aziendale consente l'accesso offline). Infine, la chiave dati AES a 256 bit viene crittografata con un'altra chiave, come descritto nella sezione successiva.

Metodi di crittografia della cassetta di sicurezza

Keeper crittografa i dati in modi diversi a seconda della modalità di accesso degli utenti. Per gli utenti privati e i membri del piano famiglia, vengono utilizzate una password principale e l'autenticazione biometrica. Per gli utenti business e aziendali che accedono con SSO, Keeper utilizza la crittografia a curva ellittica per un'esperienza sicura e senza password.

Per gli utenti che accedono con una password principale: la chiave per decrittografare e crittografare i dati deriva dalla password principale dell'utente utilizzando la funzione di variazione della chiave basata sulla password (PBKDF2), con 1.000.000 di iterazioni. Dopo che l'utente ha digitato la propria password principale, la chiave viene derivata a livello locale e poi rivelerà la chiave dati. La chiave dati viene decrittografata e utilizzata per rivelare le chiavi delle singole voci e delle singole cartelle. La decrittografia di ogni chiave memorizza il contenuto della voce a livello locale sul dispositivo dell'utente.

Per gli utenti che accedono con la tecnologia SSO o senza password: La crittografia a curva ellittica viene utilizzata per crittografare e decrittografare i dati a livello di dispositivo. Per decifrare la chiave dati viene utilizzata una chiave privata ECC-256 (secp256r1) locale. Dopo che è stata decrittografata, la chiave dati viene utilizzata per decrittografare le chiavi delle singole voci e delle singole cartelle. La chiave della voce decrittografa quindi il contenuto di ciascuna voce memorizzata. La chiave dati crittografata viene trasmessa tra i dispositivi dell'utente attraverso un sistema push o un servizio di scambio di chiavi, chiamato Approvazione dispositivi. Per preservare la zero-knowledge, Approvazione dispositivi viene gestita localmente dall'utente finale.

Modello di crittografia SSO

Flusso per il primo dispositivo (onboarding di nuovi utenti)

1. La chiave dati, la coppia di chiavi di condivisione e la coppia di chiavi private/pubbliche EC del dispositivo vengono generate
2. La chiave dati viene crittografata con la chiave pubblica EC del dispositivo e memorizzata nel cloud (DEDK)
3. L'utente effettua il login con il proprio provider d'identità (IdP)
4. Dopo l'accesso con l'IdP, l'asserzione SAML firmata viene verificata da Keeper
5. La cassetta di sicurezza viene creata e l'utente viene inserito

Flusso dispositivi esistenti

1. L'utente effettua il login con il proprio provider d'identità (IdP)
2. Dopo l'accesso con l'IdP, l'asserzione SAML firmata viene verificata da Keeper
3. Keeper consegna all'utente la chiave dati crittografata del dispositivo (DEDK)
4. La chiave dati viene decrittografata con la chiave privata EC del dispositivo
5. La chiave dati decrittografa le chiavi delle cartelle e le chiavi delle voci
6. Le chiavi della voce decrittografano il contenuto della voce

Flusso dispositivi nuovi o non riconosciuti

1. Su ogni nuovo dispositivo viene generata una coppia di chiavi private/pubbliche EC
2. L'utente effettua il login con il proprio provider d'identità (IdP)
3. Dopo l'accesso con l'IdP, l'asserzione SAML firmata viene verificata da Keeper
4. Il dispositivo è "approvato" tramite Keeper Push, approvazione dell'amministratore o il servizio Keeper Automator (*vedere Approvazione dispositivi di seguito)
5. Durante la procedura di approvazione, la chiave dati viene crittografata con la chiave pubblica del nuovo dispositivo
6. La chiave dati crittografata del dispositivo (DEDK) viene inviata all'utente

Approvazione dispositivo

• L'approvazione del dispositivo è un meccanismo per fornire in modo sicuro la chiave dati dell'utente al nuovo dispositivo, preservando la zero-knowledge
• L'utente può approvare il proprio dispositivo crittografando la chiave dati con la chiave pubblica del nuovo dispositivo
• L'amministratore può approvare il dispositivo dalla console di amministrazione, da Commander o dal servizio Keeper Automator
• L'amministratore decrittografa la chiave dati dell'utente e ricrittografa la chiave dati con la chiave pubblica del nuovo dispositivo
• Il servizio Keeper Automator può eseguire approvazioni automatiche dei dispositivi sull'infrastruttura del cliente
• Keeper Automator verifica la firma SAML, rivela la chiave dati e la crittografa con la chiave pubblica del nuovo dispositivo.

Per saperne di più sul servizio Keeper Automator.

Sicurezza a livello di dispositivo per SSO Connect Cloud

Per gli utenti di SSO Connect Cloud, una chiave privata a curva ellittica viene generata e memorizzata localmente su ogni dispositivo. Sui moderni browser web e nell'applicazione Keeper Desktop basata su Electron, la cassetta di sicurezza di Keeper memorizza la chiave privata EC del dispositivo locale ("DPRIV") come CryptoKey non esportabile. Sui dispositivi iOS e macOS, la chiave è memorizzata nel portachiavi del dispositivo. Sui dispositivi Android, la chiave è crittografata con Android Keystore, utilizzando le Encrypted Shared Preferences. Ove disponibile, Keeper utilizza meccanismi di archiviazione sicura su ogni sistema operativo.

La chiave privata del dispositivo non viene utilizzata direttamente per crittgrafare o decrittografare i dati della cassetta di sicurezza. Dopo l'autenticazione con il provider d'identità, viene utilizzata una chiave a parte (che non viene memorizzata) per decrittografare i dati della cassetta di sicurezza. Pertanto, l'estrazione offline della chiave privata locale del dispositivo non può decrittografare la cassetta di sicurezza dell'utente.

Crittografia dei dati a riposo

Keeper utilizza AWS per ospitare la piattaforma e l'architettura di Keeper. I nostri centri dati AWS sono situati in diverse località geografiche e i nostri clienti possono ospitare il loro tenant Keeper in qualsiasi regione primaria preferita. Questo garantisce che i dati del cliente e l'accesso alla piattaforma siano isolati in quella specifica regione.

I dati della cassetta di sicurezza a riposo vengono crittografati sul dispositivo dell'utente in locale utilizzando AES-256 GCM, mentre i dati crittografati in transito vengono crittografati con TLS 1.3 con un ulteriore livello di crittografia nel payload. I dati dei clienti sono isolati grazie all'uso della crittografia a livello di voce.

Il modello di crittografia di Keeper segue la seguente struttura:

• Tutte le cassette di sicurezza sono crittografate da una chiave AES a 256 bit univoca e generata dal client in modalità GCM.
• Tutte le chiavi a livello di voce nelle cartelle condivise sono crittografate con una chiave AES a 256 bit della cartella condivisa.
• Le chiavi delle voci e delle cartelle per gli utenti della cassetta di sicurezza sono crittografate con un'altra chiave AES a 256 bit, chiamata chiave dati.
• Per Keeper Secrets Manager (KSM), le chiavi delle voci e delle cartelle dell'utente sono crittografate con una chiave AES a 256 bit dell'applicazione.
• Per gli utenti che accedono con una password principale, le chiavi per decifrare e crittografare i dati sono derivate dalla password principale.
• L'accesso con la tecnologia SSO o senza password utilizza la crittografia a curva ellittica per crittografare e decrittografare i dati sul dispositivo.
• Ogni payload crittografato viene inviato ai server di Keeper e crittografato con una chiave AES a 256 bit di trasmissione con TLS, per proteggersi dagli attacchi Man-in-the-Middle (MITM). La chiave viene generata nel client e trasferita utilizzando la crittografia ECIES tramite la chiave pubblica a curva ellittica del server.
• La condivisione sicura delle chiavi segrete tra gli utenti utilizza la distribuzione delle chiavi della crittografia a curva ellittica.

Versioning delle voci

Keeper mantiene una cronologia completa e crittografata delle versioni di ogni voce memorizzata nella cassetta di sicurezza dell'utente, garantendo la sicurezza che nessun dato critico vada perso. Dall'applicazione client di Keeper, gli utenti possono esaminare la cronologia delle voci ed eseguire un ripristino di ogni singola voce della cassetta di sicurezza. Se una password o un file memorizzati in Keeper vengono modificati o eliminati, gli utenti hanno sempre la possibilità di eseguire un ripristino puntuale.

Keeper Business

I clienti che acquistano Keeper Business ottengono un ulteriore livello di controllo sui propri utenti e dispositivi. Gli amministratori di Keeper hanno accesso a una console di amministrazione basata su cloud che consente il controllo completo della creazione del profilo utente, dell'eliminazione del profilo utente, delle autorizzazioni in base al ruolo, dell'amministrazione delegata, dei team, dell'integrazione Active Directory/LDAP, dell'autenticazione a due fattori, del Single Sign-On e dell'applicazione della sicurezza. I criteri di applicazione in base al ruolo di Keeper sono completamente personalizzabili e scalabili per qualsiasi organizzazione.

Crittografia avanzata dei dati a riposo

Oltre a memorizzare nell'infrastruttura AWS solo il testo cifrato del dispositivo, Keeper esegue anche una super-crittografia con moduli di sicurezza hardware (HSM) multi-regione utilizzando chiavi non esportabili.

Crittografia e protezione dei backup

A livello di prodotto/utente, il software Keeper mantiene una cronologia completa delle revisioni di ogni voce. Pertanto, se un utente ha bisogno di recuperare qualcosa, può visualizzare e ripristinare le versioni precedenti delle sue voci di Keeper memorizzate in qualsiasi momento, senza limiti, attraverso l'interfaccia utente.

A livello di sistema, i database crittografati e gli oggetti dei file di Keeper sono replicati e sottoposti a backup in più regioni geografiche per consentire il recupero in caso di disastro. Tutti i backup sono crittografati con AES-256, oltre alla super-crittografia del testo cifrato generato dal dispositivo.

Per i clienti che necessitano di assistenza con il recupero (ad esempio, a causa dell'eliminazione accidentale di una cassetta di sicurezza o di una cartella condivisa), il team di supporto di Keeper può fornire assistenza per qualsiasi momento (fino al minuto) entro 30 giorni. L'assistenza di Keeper può aiutarvi per qualsiasi tipo di ripristino, come il recupero di un utente, di una cassetta di sicurezza o per il ripristino completo dell'azienda.

Recupero degli account

Una frase di recupero di 24 parole consente ai clienti di Keeper di accedere nuovamente alla propria cassetta di sicurezza in caso di perdita o dimenticanza della password principale.

Keeper ha implementato le frasi di recupero utilizzando lo stesso elenco di parole BIP39 usato per proteggere i wallet di criptovalute. L'elenco di parole utilizzato in BIP39 è un insieme di 2.048 parole utilizzate per generare una chiave di crittografia con 256 bit di entropia. Questo metodo di recupero è comunemente utilizzato nei wallet di bitcoin e criptovalute più diffusi. Ogni parola dell'elenco BIP39 è stata accuratamente selezionata per migliorare la visibilità e rendere il processo di recupero meno soggetto a errori. Gli utenti dovrebbero annotare la loro frase di recupero e conservarla in un luogo sicuro come una cassaforte.

La frase di recupero genera una chiave AES a 256 bit che crittografa una copia della chiave dati dell'utente. Per recuperare l'account e reimpostare la password principale, gli utenti devono disporre della frase di recupero insieme a un'e-mail di verifica e all'autenticazione a due fattori (2FA).

Gli amministratori aziendali possono disattivare il recupero dell'account a livello di regole di applicazione dei ruoli.

Chiavi di crittografia a livello aziendale

I clienti di Keeper Enterprise e Business possono gestire diverse funzionalità della piattaforma di Keeper, come le regole di accesso in base al ruolo, il provisioning, l'autenticazione e la gestione.

Le funzioni amministrative sono protette dalla piattaforma di Keeper sia con la crittografia che con l'autorizzazione. L'autorizzazione garantisce che solo gli utenti designati possano eseguire determinate funzioni. La crittografia garantisce che gli amministratori designati siano in grado di eseguire fisicamente e crittograficamente solo le funzionalità che riguardano i dati della cassetta di sicurezza o le chiavi controllate dall'azienda. Di seguito alcuni esempi:

• La piattaforma di Keeper è una piattaforma di gestione delle chiavi de facto, in cui gli utenti e gli amministratori hanno il pieno controllo delle loro chiavi private.
• Le coppie di chiavi di crittografia pubbliche e private vengono utilizzate per la creazione di dispositivi, utenti e team.
• Le regole di ruolo per il trasferimento delle cassette di sicurezza e l'approvazione dei dispositivi utilizzano chiavi di crittografia pubbliche e private.
• Le coppie di chiavi a curva ellittica (EC) sono utilizzate per la condivisione di dati tra utenti e, a livello aziendale, dal singolo utente all'amministratore.
• I dati d'utilizzo sensibili, come la forza delle password registrate, sono crittografati con chiavi pubbliche aziendali che solo l'amministratore può decifrare.
• I campi del titolo della voce, dell'URL e del tipo di voce della cassetta di sicurezza di ciascun utente aziendale sono crittografati con la chiave pubblica aziendale e possono essere decrittografati all'interno della console di amministrazione di Keeper, da un amministratore a cui sono stati assegnati i privilegi di segnalazione della conformità.

Verifica dei dispositivi

Prima che un utente possa anche solo tentare di accedere a un account, deve superare una fase di approvazione e verifica del dispositivo. La verifica del dispositivo impedisce l'enumerazione degli account e protegge dagli attacchi di forza bruta.

I clienti che accedono con una password principale possono effettuare la verifica del dispositivo utilizzando diversi metodi, tra cui:

• Codice di verifica tramite e-mail
• Inserimento codice 2FA da una TOTP o da un messaggio di testo
• Utilizzo di Keeper Push^™ per inviare un messaggio a un dispositivo riconosciuto

Per i clienti che si autenticano con SSO Connect Cloud di Keeper, l'approvazione del dispositivo avviene con un trasferimento di chiavi, dove la chiave dati crittografata dell'utente viene consegnata al dispositivo, che viene decrittografato localmente utilizzando la chiave privata a curva ellittica dell'utente. Tra i metodi di approvazione del dispositivo vi sono:

• Keeper Push (utilizzando le notifiche push) ai dispositivi dell'utente esistenti
• Approvazione dell'amministratore tramite la console di amministrazione di Keeper
• Approvazione automatica tramite il servizio Keeper Automator
• Approvazione automatica tramite Commander CLI

Maggiori informazioni sull'approvazione dei dispositivi.

Privacy dei dati

Keeper è conforme al RGPD e si impegna a garantire che i nostri processi e prodotti mantengano la conformità al RGPD per i nostri clienti nell'Unione Europea e in tutto il mondo. We comply with the EU-U.S. Data Privacy Framework ("EU-U.S. DPF"), the UK Extension to the EU-U.S. DPF, the German Federal Data Protection Act (BDSG) and the Swiss-U.S. Data Privacy Framework ("Swiss-U.S. DPF") as set forth by the U.S. Department of Commerce.

Leggete l'Informativa sulla privacy RGPD di Keeper.

Nessuna delle applicazioni di Keeper contiene tracker o librerie di terze parti che eseguono il tracciamento. A titolo di esempio, questo report fornisce informazioni sull'app di Keeper per Android, la quale mostra che non sono installati tracker.

Isolamento dei dati

Keeper è una piattaforma SaaS completamente gestita e ospita i propri dati in più data center AWS isolati a livello geografico. Le organizzazioni possono stabilire il proprio tenant Keeper nell'area geografica principale che preferiscono. I dati dei clienti e gli accessi alla piattaforma rimangono isolati in quella determinata area geografica.

Regioni disponibili:

• Stati Uniti (USA)
• United States Government Cloud (US_GOV)
• Europa (EU)
• Australia (AU)
• Giappone (JP)
• Canada (CA)

Crittografia in transito

La cassetta di sicurezza di Keeper è protetta da API che vengono convalidate tramite autorizzazione sul dispositivo dell'utente.

• L'utente recupera un token di sessione con il suo login e lo invia a ogni chiamata API.
• Il token di sessione è gestito e controllato dal server di backend.
• Il login viene effettuato con una password principale, con la biometria, con la ripresa della sessione o con l'autenticazione SAML 2.0 SSO.

Quando si utilizza una password principale, il dispositivo dell'utente ricava una chiave di autenticazione a 256 bit utilizzando PBKDF2-HMAC_SHA256 con 1.000.000 di iterazioni e un valore sale casuale. L'hash di autenticazione viene generato effettuando l'hash crittografico della chiave di autenticazione con SHA-256. Al momento dell'accesso, l'hash di autenticazione viene confrontato con quello conservato nella cassetta di sicurezza di Keeper. Dopo l'accesso, un token di sessione viene generato sul server e inviato all'utente per essere utilizzato dal dispositivo per le successive richieste API. Per consentire l'uso continuo delle comunicazioni client-server, la sessione deve essere attiva.

• Keeper utilizza TLS a 256 e 128 bit per crittografare il 100% dei dati memorizzati nell'app dell'utente e in Archiviazione dei file sicura di Keeper.
• Keeper utilizza certificati TLS firmati con l'algoritmo SHA2. SHA2 è l'algoritmo di firma più sicuro attualmente disponibile presso le autorità di certificazione commerciali. L'uso di SHA2 da parte di Keeper protegge dai certificati contraffatti che un malintenzionato potrebbe utilizzare per farsi passare per un sito web.

Autenticazione cloud

Keeper ha creato un modello avanzato di autenticazione nel cloud e di comunicazione in rete con i massimi livelli di privacy, sicurezza, fiducia e trasparenza. Alcune caratteristiche chiave di questo modello di autenticazione sono:

Integrazione con qualsiasi provider SAML 2.0

Keeper si integra con tutti i provider di identità compatibili con SAML 2.0, tra cui Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 e altri ancora.

I nostri prodotti offrono due diversi tipi di SSO: SSO Connect Cloud e SSO Connect On-Prem. Entrambe le implementazioni forniscono un'architettura zero-knowledge con autenticazione senza intoppi per gli utenti.

Le password principali degli utenti non vengono mai trasmesse sul layer di rete

A differenza della maggior parte dei servizi SaaS, le credenziali di accesso degli utenti di Keeper non lasciano mai il dispositivo. Quando gli utenti accedono a Keeper utilizzando una password principale, PBKDF2 viene utilizzato sul dispositivo locale per ricavare una chiave AES a 256 bit per la decodifica. Un'ulteriore chiave PBKDF2 viene generata a livello di dispositivo e poi sottoposta a hash con HMAC_SHA256 per creare un token di autenticazione. Keeper non è a conoscenza della chiave di decrittografia dell'utente.

Il traffico tra il dispositivo client e Keeper Cloud non può essere intercettato o decrittografato

Tutti i payload crittografati inviati ai server di Keeper sono crittografati da una chiave di trasmissione AES a 256 bit e da TLS per proteggersi dagli attacchi man-in-the-middle (MITM). La chiave di trasmissione viene generata sul dispositivo client e trasferita al server utilizzando la crittografia ECIES tramite la chiave pubblica EC del server.

I nuovi dispositivi non possono essere utilizzati per accedere a un account senza una procedura di verifica

Gli utenti non possono utilizzare nuovi dispositivi per accedere ai propri account di Keeper senza utilizzare un metodo di verifica. Keeper supporta diversi tipi di metodi di verifica, a seconda dello schema di autenticazione.

L'autenticazione multifattoriale (AMF) viene eseguita dopo la verifica, prima che l'utente inserisca la propria password principale.

Se l'utente ha configurato o applicato l'AMF, deve superare questo passaggio prima di inserire la propria password principale.

L'inserimento della password principale non può avvenire fino a quando la verifica del dispositivo e la fase AMF non sono state completate correttamente

Se non viene impostato alcun metodo di verifica, l'utente non può procedere all'inserimento della propria password principale. Questa autenticazione avanzata protegge da diversi metodi di attacco comuni, tra cui gli attacchi di forza bruta, il password spray, gli attacchi a enumerazione e quelli MitM.

Autenticazione multifattoriale (AMF)

Per proteggersi dall'accesso non autorizzato all'account di un cliente, Keeper offre l'autenticazione multifattoriale (AMF) – un approccio che richiede due o più fattori di autenticazione, ovvero un fattore di conoscenza, un fattore di possesso e/o un fattore intrinseco. Maggiori informazioni sulla configurazione dell'AMF in Keeper.

Keeper utilizza la vostra password principale e il dispositivo in vostro possesso per fornire un ulteriore livello di sicurezza se la password principale o il dispositivo vengono compromessi. Keeper supporta le chiavi hardware FIDO2 WebAuthn e le soluzioni basate su software come TOTP e SMS.

Quando si utilizza un metodo AMF/2FA con TOTP, Keeper genera una chiave segreta di 10 byte utilizzando un generatore di numeri casuali protetto da crittografia. Questo codice è valido per circa un minuto e non può essere riutilizzato una volta eseguita con successo l'autenticazione. Keeper supporta qualsiasi applicazione TOTP, compresi Google Authenticator e Microsoft Authenticator. Keeper si integra anche direttamente con i servizi AMF più diffusi, come Duo e RSA SecurID.

Quando si utilizzano autenticatori AMF, come Google Authenticator, Microsoft Authenticator o altre applicazioni TOTP sul dispositivo mobile, il server di Keeper genera internamente un codice QR contenente la chiave segreta. Ogni volta che un utente attiva l'AMF, viene generata una nuova chiave.

Per attivare l'AMF, aprite la schermata delle impostazioni della Web App, dell'app per desktop o dell'applicazione per iOS/Android di Keeper. Gli amministratori di Keeper Business possono anche imporre l'uso dell'AMF e dei metodi AMF supportati tramite la console di amministrazione di Keeper.

Il supporto per WebAuth compatibile con FIDO2 è fornito tramite Keeper, con dispositivi di sicurezza basati su hardware come YubiKey e Google Titan come fattore aggiuntivo. Anche le chiavi d'accesso sono supportate come metodo 2FA utilizzando dispositivi fisici o browser. Le chiavi di sicurezza rappresentano un modo sicuro per eseguire l'AMF senza richiedere all'utente di inserire manualmente i codici.

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID Messaggio di testo SMS Titan Security Key TOTP Yubico

Active Directory / LDAP Bridge di Keeper

Keeper Bridge si integra con i server di Active Directory e LDAP per il provisioning e l'onboarding degli utenti. La comunicazione con Keeper Bridge viene prima autorizzata da un amministratore dotato del privilegio di gestire il bridge. Viene generata una chiave di trasmissione che viene condivisa con Keeper per tutte le comunicazioni successive. L'uso della chiave di trasmissione costituisce l'autorizzazione per tutte le operazioni eseguite dal bridge, ad eccezione dell'inizializzazione del bridge. La chiave di trasmissione può essere rigenerata in qualsiasi momento e la sua rotazione avviene automaticamente ogni 30 giorni.

La chiave di trasmissione serve solo per la trasmissione, il che significa che una chiave compromessa può essere reinizializzata o revocata senza alcuna perdita di dati o di autorizzazioni.

Keeper Bridge non può concedere privilegi a un ruolo o a un utente. Può aggiungere un utente a un ruolo con privilegi, purché non siano necessarie chiavi di applicazione. Keeper Bridge non può elevare se stesso o un utente al di sopra della porzione di albero che sta gestendo. Non tutte le operazioni sono disponibili per Keeper Bridge, ad esempio può disabilitare un utente attivo, ma non può eliminarlo. Sarà l'amministratore a scegliere se l'utente andrà eliminato o trasferito.

Autenticazione SSO con AMF

Quando Keeper viene implementato con una soluzione SSO come Entra ID/Azure AD, Okta, Ping, Google Workspace o qualsiasi altro provider di identità SAML 2.0, l'AMF può essere gestita completamente durante la procedura di accesso IdP. Keeper supporta inoltre le policy di accesso condizionali Azure per tutti i tipi di applicazioni e dispositivi.

L'AMF può essere applicata sia dal lato del provider d'identità che da quello di Keeper. Ad esempio, una volta che l'utente ha superato la fase con AMF con il provider d'identità, può essere obbligato a superare una seconda fase con AMF nell'interfaccia di Keeper. Questa regola può essere applicata dall'amministratore di Keeper.

Amazon Web Services CAS Centrify DUO F5 Google Workplace IBM Security JumpCloud Microsoft ADFS Onelogin Okta Ping Identity

Autenticazione SAML 2.0 con SSO Connect Cloud

Keeper SSO Connect Cloud consente ai clienti aziendali di integrare completamente Keeper con qualsiasi provider d'identità conforme a SAML 2.0 e di distribuire ai propri utenti cassette di sicurezza crittografate.

SAML implementation with Keeper allows a user to authenticate through their SSO IdP and then decrypt their vault ciphertext on their device. Every user device has an individual Elliptic Curve (EC) key pair and encrypted data key. In addition, each user has their own 256-bit AES data key. When signing in to Keeper using a new device, the user must utilize existing devices to perform an approval or, alternatively, an admin with privileges can approve their device.

This capability is essential so a user can decrypt their vault locally, on their device, without the requirement of a master password or password key derivation. Zero knowledge is maintained because the cloud cannot decrypt the user's data key. Instead, the device-encrypted data key (DEDK) is provided to the user upon successful authentication of the IdP (e.g., Okta, Azure, Google Workspace, AD FS, Ping, Duo, Jumpcloud, etc.). The data key for the user is decrypted locally on the device with the elliptic curve device private key. Keeper holds US Utility Patents on this technology, which has been in production since 2015.

Keeper Automator è un servizio opzionale che esegue approvazioni istantanee dei team, approvazioni dei dispositivi e assegnazioni degli utenti dopo l'esecuzione dell'accesso dal provider di identità SSO.

Una volta che Automator è in esecuzione, gli utenti possono accedere senza problemi a Keeper sui nuovi dispositivi (non approvati in precedenza) dopo aver eseguito correttamente l'autenticazione con il proprio provider di identità, senza ulteriori procedure di approvazione.

Keeper SSO Connect On-Prem

Nonostante la maggior parte di clienti scelga di implementare la soluzione Keeper SSO Connect Cloud, chi richiede una soluzione on-premise può implementare SSO Connect On-Prem, una integrazione auto-ospitata che richiede un server applicativo su Windows o Linux. Per mantenere la sicurezza Zero Knowledge e garantire un'esperienza SSO senza interruzioni per gli utenti, Keeper SSO Connect deve essere installato sul server del cliente. Gli ambienti Windows, Mac e Linux sono completamente supportati e offrono modalità operative di bilanciamento del carico ad alta disponibilità (HA) e opzioni di super-crittografia con moduli di sicurezza hardware.

Keeper SSO Connect genera e mantiene automaticamente la password principale per ogni utente di cui è stato fatto il provisioning, che è una chiave a 256 bit generata in modo casuale. La password principale viene crittografata con la chiave SSO. La chiave SSO è crittografata con la chiave dell'albero. La chiave SSO viene recuperata dal server all'avvio del servizio Keeper SSO Connect e quindi decrittografata utilizzando la chiave dell'albero, che viene memorizzata localmente sul server per supportare l'avvio automatico del servizio. La comunicazione tra SSO Connect e il Cloud Security Vault di Keeper è protetta da una chiave di trasmissione. Le comunicazioni SAML sono firmate crittograficamente e sono protette dall'algoritmo di firma RSA-SHA256 o ECDSA-SHA256, a seconda del tipo di chiave di crittografia (RSA o ECC) fornita dal cliente.

Condivisione

Keeper supporta la possibilità di condividere in modo sicuro le voci tra gli utenti, con un team interno o anche all'esterno della propria organizzazione (se consentito dall'amministratore di Keeper).

Condivisione delle voci

Gli utenti di Keeper possono condividere direttamente le voci tra loro. A tal fine, Keeper richiede inizialmente la chiave pubblica a curva ellittica dell'utente dalla sua cassetta di sicurezza. Ogni voce ha una chiave di registrazione che viene crittografata con la chiave pubblica a curva ellittica del destinatario e sincronizzata con la cassetta di sicurezza di Keeper dell'utente.

Il proprietario della voce condivisa crittografata decrittografa la chiave della voce con la propria chiave privata a curva ellittica. Anche la chiave della voce viene crittografata di nuovo con la chiave dati dell'utente e il testo cifrato viene memorizzato nella cassetta di sicurezza del destinatario.

Condivisione singola

La condivisione singola di Keeper consente la condivisione sicura e limitata nel tempo di una voce, come una password, una credenziale, una chiave segreta, una connessione, un documento o altre informazioni riservate, con chiunque, anche se non dispone di un account di Keeper. Il modello di crittografia della condivisione singola di Keeper utilizza la stessa tecnologia di Keeper Secrets Manager (KSM), una piattaforma zero-knowledge e zero-trust per la protezione dell'infrastruttura cloud.

1. Nella cassetta di sicurezza di Keeper dell'utente, l'originatore genera un accesso singolo facendo clic su Condivisione singola. La chiave di registrazione AES a 256 bit viene crittografata con un token di accesso monouso e il valore crittografato viene memorizzato nella cassetta di sicurezza di Keeper.
2. L'utente che condivide il token di accesso singolo con un destinatario utilizza un semplice URL o un codice QR. La parte dell'URL che contiene il token di accesso è contenuta nella porzione "identificatore di frammento" dell'URL, che non viene mai inviata ai server di Keeper. Pertanto, Keeper non può accedere alle informazioni né decrittografarle, e la zero-knowledge è protetta.
3. L'URL si apre nel browser dell'utente e l'applicazione della cassetta di sicurezza viene caricata sul dispositivo. Il token viene consegnato direttamente all'applicazione locale della cassetta di sicurezza e non viene inviato al server.
4. Il destinatario utilizza quindi il proprio dispositivo per generare una coppia di chiavi EC lato utente finale e la chiave privata viene memorizzata localmente, sul dispositivo, nella memoria CryptoKey del browser.
5. Al primo utilizzo da parte del destinatario, la libreria SDK si autentica con l'hash del token di accesso singolo. Quindi, il server di Keeper risponde con il testo cifrato della voce e la chiave cifrata della voce.
6. Il dispositivo decrittografa la chiave della voce con il token di accesso singolo e il contenuto viene decrittografato. La chiave viene memorizzata sul dispositivo client nella memoria CryptoKey del browser o in un'altra posizione di memorizzazione.
7. La chiave della voce crittografata per quel determinato dispositivo viene eliminata in modo che il token non possa essere utilizzato di nuovo. Successivamente, la richiesta del client deve essere firmata con la chiave privata.
8. Più chiamate sullo stesso dispositivo vengono inviate con un identificatore che definisce il dispositivo e una richiesta firmata con la chiave privata del client. La richiesta per l'identificatore del dispositivo dato - attraverso la firma ECDSA - utilizza la chiave pubblica del client del dispositivo e viene verificata dal server. Keeper elabora la richiesta e il server restituisce al dispositivo dell'utente una voce crittografata in testo cifrato.
9. Oltre alla crittografia a livello di voce, il dispositivo client crea una chiave di trasmissione AES-256 bit generata in modo casuale, che viene crittografata con la chiave pubblica dell'API del cloud di Keeper. Il dispositivo client decrittografa la risposta del server con la chiave di trasmissione e quindi decrittografa il payload del testo cifrato della risposta con la chiave della voce, che decrittografa il contenuto della voce.

Condividi privilegi di amministratore

La funzione Amministratori di condivisione di Keeper è un'autorizzazione del controllo degli accessi in base al ruolo (RBAC) che offre agli amministratori privilegi elevati sulle cartelle e sulle voci condivise di un'organizzazione. Gli amministratori di condivisione dispongono di privilegi completi per gli utenti e le voci a cui hanno accesso.

Modello di crittografia di Secrets Manager

Keeper Secrets Manager è una piattaforma zero-knowledge per i professionisti IT e DevOps che consente ai team di gestire le chiavi segrete durante tutto il ciclo di vita dello sviluppo e della distribuzione del software.

Modello di crittografia utilizzato da Secrets Manager:

• La crittografia e la decrittografia avvengono localmente sul dispositivo (non sul server).
• Il testo in chiaro non viene mai memorizzato sul dispositivo.
• Il testo in chiaro non viene mai ricevuto dal server.
• Nessuno, compresi i dipendenti di Keeper, terze parti o intermediari, può decrittografare le chiavi segrete.
• Il dispositivo client gestisce le chiavi per crittografare e decrittografare le chiavi segrete, sotto il controllo dell'utente.
• Ogni chiave segreta è crittografata da una chiave di crittografia AES a 256 bit generata dal lato client in modalità GCM.
• Se la chiave segreta è contenuta all'interno di una cartella condivisa, la chiave della voce è nascosta da una chiave della cartella condivisa.
• Una chiave di applicazione AES a 256 bit viene generata sul lato client e utilizzata per decrittografare la cartella condivisa e le chiavi di registrazione. La chiave della voce decrittografa quindi la chiave segreta individuale.
• I server Keeper sono protetti da una chiave AES a 256 bit e da TLS per evitare attacchi MitM.
• La chiave di trasmissione viene generata sul dispositivo client e trasferita al server utilizzando la crittografia ECIES tramite la chiave pubblica EC del server.
• La crittografia a curva ellittica viene utilizzata per condividere le chiavi segrete tra gli utenti per una distribuzione sicura delle chiavi.
• La crittografia multilivello consente il controllo degli accessi a livello di utente, gruppo e amministratore.
• Le chiavi segrete gestite all'interno della cassetta di sicurezza sono segmentate e isolate dai dispositivi definiti di Keeper Secrets Manager a cui è concesso l'accesso alla voce e alla cartella.

Modello di Keeper Secrets Manager per la rotazione delle password

• Un client univoco di Keeper Secrets Manager (KSM), chiamato gateway, viene installato nell'ambiente del cliente.
• Il gateway stabilisce una connessione sicura in uscita verso il router di Keeper.
• Il router è un servizio cloud ospitato nell'ambiente AWS di Keeper, che facilita la comunicazione tra l'API di back-end di Keeper, le applicazioni dell'utente finale (Cassetta Web, app per desktop, ecc.) e i gateway installati nell'ambiente dell'utente.
• I WebSocket vengono stabiliti tra il dispositivo dell'utente finale (ad esempio, la Cassetta Web) e il router di Keeper utilizzando il token della sessione in corso.
• Il router di Keeper verifica il token della sessione e la autentica. Tutti i payload crittografati inviati al router di Keeper sono nascosti da una chiave AES a 256 bit, oltre a TLS, per proteggere dagli attacchi MitM.
• La chiave AES a 256 bit viene creata sul dispositivo dell'utente finale e trasferita al server utilizzando la crittografia ECIES tramite la chiave pubblica EC del router.
• Le richieste di rotazione e discovery vengono emesse tra il dispositivo dell'utente finale (o Keeper Scheduler) e il gateway attraverso il canale di comunicazione WebSocket stabilito.
• Durante la rotazione, quando il gateway richiede una chiave segreta dalla cassetta di sicurezza di Keeper, autentica e decrittografa la chiave segreta utilizzando le API di Keeper Secrets Manager per proteggere la zero-knowledge.
• Come per qualsiasi altro dispositivo di Keeper Secrets Manager, l'accesso può essere limitato anche in base all'indirizzo IP, oltre che al processo di crittografia e firma.

Connessione zero-trust e sicurezza del tunnel

Zero-Trust KeeperPAM offre la possibilità di stabilire sessioni privilegiate su cloud e on-premise, creare tunnel, stabilire accessi diretti all'infrastruttura e proteggere gli accessi ai database remoti senza dover utilizzare una VPN.

Una connessione è una sessione remota visiva che utilizza il browser web. L'interazione tra l'utente e il dispositivo target avviene in una finestra del browser web o all'interno dell'applicazione desktop di Keeper.

Un tunnel è una connessione TCP/IP che viene stabilita tra il client della cassetta di sicurezza locale attraverso il gateway Keeper e l'endpoint di destinazione. L'utente può utilizzare qualsiasi applicazione nativa per comunicare con l'endpoint di destinazione, come il terminale a riga di comando, l'applicazione GUI o l'applicazione di gestione dei database come MySQL Workbench.

Quando l'utente stabilisce una connessione o un tunnel:

1. L'applicazione Vault Client comunica con l'infrastruttura Keeper Router per avviare una connessione WebRTC protetta da una chiave simmetrica ECDH archiviata all'interno della voce Keeper pertinente.
2. Il gateway di Keeper comunica con il relativo router tramite il protocollo WebSockets solo in uscita. Scopri di più sulla procedura.
3. Il gateway di Keeper utilizza le API di Keeper Secrets Manager per ottenere le chiavi segrete necessarie dalla cassetta di sicurezza, inclusa la chiave simmetrica ECDH.
4. Per le connessioni, il client della cassetta di sicurezza, che utilizza il protocollo Apache Guacamole, passa i dati attraverso la connessione WebRTC al gateway di Keeper che utilizza Guacd per connettersi alla destinazione trovata nella voce di Keeper.
5. Per le funzionalità di tunneling (inoltro delle porte), viene aperta una porta locale sul dispositivo locale che esegue il software Keeper Desktop. I dati inviati alla porta locale vengono trasmessi tramite la connessione WebRTC al gateway Keeper e successivamente inoltrati all'endpoint target definito nella voce Keeper.
6. Le registrazioni delle sessioni di connessione sono protette tramite una chiave di crittografia AES-256 (“chiave di registrazione”) che viene generata sul gateway Keeper durante ogni sessione. La chiave di registrazione è inoltre protetta tramite una chiave di risorsa AES-256 con derivazione HKDF.

Sicurezza e isolamento del browser remoto (RBI)

La tecnologia Keeper di isolamento del browser remoto protegge gli accessi alle applicazioni web interne o a qualsiasi altra risorsa web tramite il container Keeper Connection Manager Docker o il gateway Keeper.

Utilizzo del metodo associato al container di Keeper Connection Manager Docker:

1. L'utente si autentica attraverso il servizio web Keeper Connection Manager che è ospitato dal client in un container Docker.
2. L'utente avvia una sessione di isolamento del browser remoto per l'applicazione web target. Tra il browser dell'utente e il servizio web Keeper Connection Manager ospitato, la comunicazione su HTTPS è protetta da Let's Encrypt o dal certificato di autenticazione del cliente.
3. Sul container di Keeper Connection Manager Docker, viene eseguita una versione integrata di Chromium all'interno di una sandbox, il rendering del sito web target viene ottenuto utilizzando un driver di visualizzazione in locale che trasmette il contenuto visibile della pagina in tempo reale al browser web dell'utente utilizzando il protocollo Apache Guacamole.

Utilizzo del gateway Keeper con l'app o la versione desktop di Keeper Web Vault:

1. L'applicazione Vault Client comunica con l'infrastruttura Keeper Router per avviare una connessione WebRTC protetta da una chiave simmetrica ECDH archiviata all'interno della voce Keeper pertinente.
2. Il gateway di Keeper comunica con il relativo router tramite il protocollo WebSockets solo in uscita. Scopri di più sulla procedura.
3. Il gateway di Keeper utilizza le API di Keeper Secrets Manager per ottenere le chiavi segrete necessarie dalla cassetta di sicurezza, inclusa la chiave simmetrica ECDH.
4. Il client della cassetta di sicurezza, che utilizza il protocollo Apache Guacamole, trasmette i dati attraverso la connessione WebRTC al gateway di Keeper che utilizza quindi il protocollo HTTP o HTTPS per connettersi alla destinazione trovata nella voce di Keeper.
5. Le registrazioni delle sessioni di connessione sono protette tramite una chiave di crittografia AES-256 (“chiave di registrazione”) che viene generata sul gateway Keeper durante ogni sessione. La chiave di registrazione è inoltre protetta tramite una chiave di risorsa AES-256 con derivazione HKDF.

Protezione e isolamento del browser

Diverse misure di sicurezza vengono attivate utilizzando il protocollo di isolamento del browser remoto:

1. L'endpoint dell'applicazione web protetta è protetto da un livello di crittografia TLS dal gateway Keeper Connection Manager al dispositivo locale dell'utente, indipendentemente dal fatto che il protocollo TLS venga utilizzato tra il gateway e l'endpoint, proteggendo così dagli attacchi MITM o dall'ispezione dei pacchetti sulla rete locale degli utenti.
2. La sessione di navigazione remota proietta visivamente l'interazione sul dispositivo locale dell'utente utilizzando una tela e il rendering grafico. Nessun codice JavaScript o HTML dal sito web target viene eseguito sul computer locale dell'utente.
3. Siccome nessun codice dal sito web target viene eseguito localmente e il browser locale non può accedere direttamente al codice dell'applicazione sottostante, l'applicazione web isolata è protetta da vettori di attacco come le vulnerabilità di scripting cross-site riflesse, le contraffazioni delle richieste cross-site e l'abuso API.
4. È possibile limitare l'esecuzione dell'esfiltrazione dei dati dall'endpoint target tramite il filtraggio delle richieste di URL e risorse per l'utente. L'upload e il download dei file presentano delle limitazioni, anche se l'applicazione web target consentirebbe altrimenti l'azione.
5. La sessione di navigazione e le sequenze di tasti possono essere registrate per l'auditing e la conformità e consentono inoltre di eseguire l'analisi forense delle sessioni basate sul web.
6. Le credenziali vengono compilate automaticamente dal gateway nell'applicazione web target e non vengono mai trasmesse al dispositivo dell'utente, inoltre, non sono accessibili sul dispositivo locale dell'utente, proteggendo così dagli eventuali leak di informazioni segrete.
7. Attraverso le policy del firewall, all'utente può essere richiesto di accedere all'applicazione web target solo attraverso la sessione di isolamento del browser remoto, riducendo le minacce legate alla compromissione dei browser o alla presenza di malware sui dispositivi locali.
8. L'applicazione web target viene protetta dall'autenticazione SSO e/o a più fattori, anche se l'applicazione non supporta nativamente queste tecnologie. Keeper protegge gli accessi alla cassetta di sicurezza e a tutte le sessioni di isolamento del browser remoto attraverso i metodi di autenticazione avanzati descritti in questo documento.

BreachWatch^®

Keeper gestisce un'architettura gestita e autonoma su AWS chiamata BreachWatch. BreachWatch è fisicamente separato dall'API di Keeper e dalle voci degli utenti.

Un modulo fisico di sicurezza hardware (HSM) sui server di BreachWatch viene utilizzato per elaborare, eseguire l'hashing e memorizzare miliardi di password uniche provenienti dalle violazioni dei dati del dark Web. Tutte le password vengono elaborate sui server di Keeper utilizzando il metodo di hashing HMAC_SHA512 e l'hash con l'HSM utilizzando una chiave non esportabile.

Quando BreachWatch viene attivato sul dispositivo client, viene generato un hash HMAC_SHA512 basato su ogni voce e inviato al server. Sul server, viene creato un secondo hash HMAC_SHA512 tramite l'HSM utilizzando una chiave non esportabile. Gli "hash degli hash" vengono confrontati per verificare se una credenziale è stata violata.

L'architettura di BreachWatch è costruita in modo da impedire la correlazione di una password violata con una password presente nella cassetta di sicurezza dell'utente, indipendentemente dalle dimensioni della violazione dei dati. Il rilevamento delle password violate utilizza un HSM fisico per assicurarsi che l'hashing possa essere eseguito solo online, per evitare qualsiasi attacco di forza bruta ai dati.

• Le password vengono sottoposte a hashing due volte con HMAC_512: una volta sul dispositivo client utilizzando un "pepe" e una volta nell'AWS CloudHSM utilizzando un modulo di sicurezza hardware con una chiave non esportabile.
• Viene utilizzato HMAC_512 perché sfrutta una funzione di hashing forte e una chiave segreta, che non è esportabile. Pertanto, un attacco offline contro gli hash non è fattibile.
• Il Message Authentication Code (MAC) con il risultato di una funzione hash crittografica amplia l'uso delle funzioni hash. I suoi risultati non dipendono solo dal messaggio ma anche da un secondo input che può essere una chiave segreta.

BreachWatch è costruito al 100% da Keeper con l'utilizzo dei feed di dati di SpyCloud, ma Keeper non invia mai dati a terzi.

Scansione dei domini

Gli utenti di BreachWatch scaricano una lista di domini che risultano essere stati violati ed eseguono la verifica a livello locale.

Scansione nomi utente e password

I dispositivi client si collegano a BreachWatch e caricano un elenco di nomi utente (o password) con hash, insieme a un identificatore casuale selezionato dal client (identificatori separati per i servizi di verifica dei nomi utente e delle password). Questi hash delle password vengono elaborati al momento del caricamento con HMAC utilizzando un modulo di sicurezza hardware (HSM) e una chiave segreta memorizzata nell'HSM contrassegnata come non esportabile (ciò significa che l'HSM elaborerà l'HMAC solo localmente e la chiave non potrà essere estratta). Questi input HMAC (nomi utente o password) vengono confrontati con i set di dati della violazione che sono stati elaborati con lo stesso HMAC e la stessa chiave. Ogni corrispondenza viene segnalata al dispositivo client. I valori che non corrispondono vengono memorizzati insieme all'ID anonimizzato del client.

Quando nuovi nomi utente e password violati vengono aggiunti al sistema, vengono elaborati con HMAC sull'HSM, aggiunti al set di dati di BreachWatch e confrontati con i valori del client memorizzati. Qualsiasi corrispondenza genera un avviso per quell'ID del client.

Periodicamente i client si confrontano con BreachWatch e presentano i loro identificativi di BreachWatch. Tutti i messaggi in coda vengono scaricati, mentre i client caricano tutti i nomi utente e le password nuovi o modificati, i quali vengono elaborati nello stesso modo.

La sicurezza dei servizi di BreachWatch si basa sul modello "trust-on-first-use" (TOFU): ciò significa che i client devono presupporre che il server di BreachWatch non sia dannoso o nocivo (ovvero, non sia attivamente compromesso dall'attacco di un hacker) al momento di caricare i propri valori crittografati. Non appena tali valori vengono elaborati con un HSM, vengono anche protetti da eventuali tentativi di violazione offline. In altre parole, se un hacker sottrae un dataset di valori del client archiviati, non potrà violarli offline senza la chiave HMAC conservata nel dispositivo HSM.

Se viene rilevata la violazione di una password, il dispositivo client invia l'hash della combinazione nome utente+password ai server di BreachWatch, che eseguono lo stesso confronto dell'hash HMAC per determinare se è stata violata una combinazione di nome utente+password; in tal caso, vengono restituiti i domini relativi a tali violazioni, in modo che il dispositivo client possa determinare se nome utente+password+dominio corrispondono. Se tutti e tre i parametri corrispondono sul dispositivo client, l'utente viene avvisato della gravità della violazione.

BreachWatch per i clienti aziendali

Quando BreachWatch viene attivato per i clienti business e enterprise, le cassette di sicurezza degli utenti finali vengono scansionate automaticamente, ogni volta che un utente accede a Keeper. I dati di riepilogo di BreachWatch scansionati sul dispositivo dell'utente vengono crittografati con la chiave pubblica dell'azienda e decrittografati dall'amministratore aziendale quando accede alla console di amministrazione di Keeper. Queste informazioni crittografate includono l'indirizzo e-mail, il numero di voci ad alto rischio, il numero di voci risolte e il numero di voci ignorate. L'amministratore di Keeper è in grado di visualizzare le statistiche di riepilogo a livello di utente all'interno dell'interfaccia utente della console di amministrazione.

Registrazione e segnalazione degli eventi

Se integrati con la Segnalazione e avvisi avanzati, i dispositivi degli utenti finali di Keeper possono anche essere configurati per trasmettere eventi dettagliati in tempo reale a soluzioni SIEM di terze parti e all'interfaccia di segnalazione della console di amministrazione di Keeper. I dati dell'evento contengono l'indirizzo e-mail, l'UID della voce, l'indirizzo IP e le informazioni sul dispositivo (gli eventi non includono alcun dato decrittografato della voce, poiché Keeper è una piattaforma zero-knowledge e non può decrittografare i dati dell'utente).

Per impostazione predefinita, i dati dettagliati degli eventi BreachWatch non vengono inviati al modulo Segnalazione e avvisi avanzati o a qualsiasi sistema di registrazione esterno collegato. Per attivare la segnalazione dei dati di BreachWatch a livello di evento al Modulo di segnalazione e avvisi avanzati, è necessario attivare la regola di applicazione del ruolo dell'evento nella schermata Ruolo specifico > Regole di applicazione > Caratteristiche della cassetta di sicurezza. Una volta attivata, i dispositivi client degli utenti finali inizieranno a inviare i dati degli eventi. Poiché l'integrazione con soluzioni SIEM di terze parti viene trasmessa dal back-end di Keeper alla SIEM di destinazione, queste informazioni sugli eventi sono quindi leggibili dalla SIEM di destinazione e possono essere utilizzate per identificare quali voci e quali utenti dell'organizzazione hanno password ad alto rischio. Se l'amministratore di Keeper non desidera trasmettere i dati degli eventi a livello di voce al modulo Segnalazione e avvisi avanzati di Keeper, questa impostazione può essere lasciata disattivata.

Splunk Sumo Logic LogRhythm Syslog Push IBM QRadar Azure Sentinel AWS S3 Bucket Devo Datadog Logz.io Elastic

Modalità offline

La modalità offline consente agli utenti di accedere ala propria cassetta di sicurezza quando non sono in grado di connettersi online a Keeper o al proprio provider d'identità SSO. Questa funzionalità è disponibile sull'applicazione mobile, sull'applicazione per desktop e nella Cassetta Web di Keeper, su tutti i browser.

La funzionalità esegue una copia della cassetta di sicurezza sul dispositivo locale dell'utente. I dati della cassetta di sicurezza memorizzati offline sono crittografati con AES-GCM e una "chiave del client" a 256 bit generata in modo casuale e protetta da PBKDF2-HMAC-SHA512 con 1.000.000 di iterazioni e un sale casuale. Il sale e le iterazioni sono memorizzati localmente. Quando l'utente inserisce la propria password principale o utilizza un metodo biometrico, viene ricavata una chiave utilizzando il sale e le iterazioni e si tenta di decifrare la chiave del client. La chiave del client viene quindi utilizzata per decrittografare la cache delle voci memorizzate. Se la protezione di autodistruzione è abilitata sulla cassetta di sicurezza dell'utente, 5 tentativi di accesso falliti cancelleranno automaticamente tutti i dati della cassetta di sicurezza memorizzati localmente. Per i clienti aziendali, l'accesso offline può essere limitato dall'amministratore di Keeper in base a regole di applicazione dei ruoli.

Accesso di emergenza (eredità digitale)

I piani personali e familiari di Keeper consentono agli utenti di aggiungere fino a cinque contatti di emergenza per garantire l'accesso alla cassetta di sicurezza in caso di morte dell'utente o di altra emergenza. L'utente specifica un tempo di attesa e, una volta trascorso, il contatto di emergenza avrà accesso alla cassetta di sicurezza dell'utente. La condivisione della cassetta di sicurezza con un contatto di emergenza è zero-knowledge e la password principale dell'utente non viene mai condivisa. Inoltre, viene utilizzata la crittografia RSA a 2048 bit con una chiave AES a 256 bit. Il contatto di emergenza deve avere un account di Keeper per accettare le informazioni.

Architettura di rete

Keeper utilizza AWS in America del nord (Commercial o GovCloud), Europa, Australia, Giappone e Canada per la privacy dei dati e l'isolamento geografico per ospitare e gestire la soluzione e l'architettura di Keeper. L'utilizzo di AWS consente a Keeper di scalare senza problemi le risorse su richiesta e di fornire ai clienti l'ambiente di cloud storage più veloce e sicuro. Keeper gestisce ambienti multi-zona e multi-regione per massimizzare i tempi di attività e fornire ai clienti tempi di risposta più rapidi. I clienti aziendali possono ospitare il proprio tenant di Keeper in qualsiasi regione primaria preferita. I dati dei clienti e l'accesso alla piattaforma sono isolati a quella specifica regione.

Autenticazione cloud

Keeper ha creato un modello avanzato di autenticazione nel cloud e di comunicazione in rete, costruito per garantire i massimi livelli di privacy, sicurezza e fiducia. Alcune caratteristiche importanti del modello di autenticazione sono:

• La password principale non viene mai trasmessa sul Livello Rete. A differenza della maggior parte dei servizi SaaS, le credenziali di accesso non lasciano mai il dispositivo. Il PBKDF2 viene utilizzato sul dispositivo locale per ricavare una chiave AES a 256 bit utilizzata per la decrittografia. Una seconda chiave PBKDF2 viene generata localmente e poi sottoposta a hash con HMAC_SHA256 per ottenere un token di autenticazione. Il Keeper Cloud Security Vault non è a conoscenza della chiave di decrittografia dell'utente.
• Il traffico tra il dispositivo client e Keeper Cloud non può essere intercettato o decrittografato. Keeper utilizza il key pinning e ulteriori livelli di crittografia a livello di rete (chiavi di trasmissione) tra il dispositivo e i server di Keeper, per garantire la prevenzione degli attacchi MitM.
• I nuovi dispositivi non possono accedere a un account senza una fase di verifica del dispositivo. Non è possibile effettuare tentativi di accesso a un account senza aver superato questa fase. Keeper supporta diversi tipi di metodi di verifica del dispositivo, che dipendono dallo schema di autenticazione utilizzato.
• La 2FA viene eseguita dopo la verifica del dispositivo, prima dell'inserimento della password principale. Se un utente ha configurato o applicato l'2FA, questo passaggio deve essere superato prima dell'inserimento della password principale.
• L'inserimento della password principale non può essere eseguito fino a quando la fase di verifica del dispositivo e l'2FA non sono andate a buon fine. L'utente non può procedere alla fase di inserimento della password principale senza aver prima eseguito la verifica del dispositivo e l'autenticazione con 2FA. Questo flusso di autenticazione avanzato offre una protezione contro diversi vettori di attacco, tra cui gli attacchi di forza bruta, il password spray, gli attacchi di enumerazione e MitM.

Crittografia in transito

Il Keeper Cloud Security Vault è protetto da API che vengono convalidate tramite autorizzazione dal dispositivo client. Il client recupera un token della sessione al momento dell'accesso e lo invia a ogni chiamata API. Il token della sessione viene conservato sul server. L'accesso viene effettuato tramite una password principale, la ripresa della sessione o l'autenticazione SAML 2.0 SSO.

Quando si utilizza una password principale, il dispositivo client ricava una "chiave di autenticazione" a 256 bit utilizzando PBKDF2-HMAC-SHA256 con 1.000.000 di iterazioni e un sale casuale a 128 bit. Un "hash di autenticazione" è generato dall'hashing della chiave di autenticazione utilizzando SHA-256. Per effettuare il login, l'hash di autenticazione viene confrontato con un hash di autenticazione memorizzato nel Cloud Security Vault. Dopo l'accesso, viene generato un token di sessione sul server e inviato al client per essere utilizzato dal dispositivo client per le successive richieste API. La sessione deve essere attiva per consentire l'uso continuo delle comunicazioni tra client e server.

Keeper supporta TLS a 256 e 128 bit per crittografare tutti i dati trasportati tra l'applicazione client e lo spazio basato su cloud di Keeper.

Keeper utilizza certificati TLS firmati da DigiCert utilizzando l'algoritmo SHA2, l'algoritmo di firma più sicuro attualmente offerto dalle autorità di certificazione commerciali. SHA2 è significativamente più sicuro del più diffuso SHA1, che potrebbe essere sfruttato a causa di un punto debole matematico identificato nell'algoritmo. SHA2 contribuisce a proteggere dall'emissione di certificati contraffatti che potrebbero essere utilizzati da un malintenzionato per farsi passare per un sito web.

Keeper supporta anche Certificate Transparency (CT), un'iniziativa di Google per creare un registro pubblicamente verificabile dei certificati firmati dalle autorità di certificazione. CT aiuta a prevenire l'emissione di certificati da parte di entità non autorizzate. CT è attualmente supportata nelle ultime versioni dei browser Chrome, Safari e Brave. Ulteriori informazioni sulla Certificate Transparency sono disponibili all'indirizzo: https://certificate.transparency.dev/. Keeper supporta le seguenti suite di cifratura TLS:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384

I dispositivi client di Keeper su iOS e Android implementano anche il key pinning, un meccanismo di sicurezza che impedisce l'impersonificazione da parte di malintenzionati che utilizzano certificati digitali fraudolenti.

Protezione dagli attacchi cross-site scripting (XSS)

La cassetta Web di Keeper implementa una severa politica di sicurezza dei contenuti che limita l'arrivo di richieste dall'esterno e impedisce l'esecuzione di qualsiasi script, ad eccezione di quelli esplicitamente originati da Keeper, inclusi gli script inline e gli attributi HTML di gestione degli eventi, riducendo o eliminando la maggior parte dei vettori degli attacchi alla cross-site scripting (XSS).

L'accesso ai nomi di dominio di Keeper è limitato al protocollo HTTPS con TLS v1.3 e viene imposto dalla procedura di sicurezza rigida per il trasporto di HTTP (HTST). In questo modo si impedisce una vasta serie di attacchi tra cui l'intercettazione di pacchetti (sniffing), la modifica dei dati e gli attacchi MitM.

All'interno dell'estensione per browser di Keeper, Keeper non richiede agli utenti le credenziali della cassetta di sicurezza all'interno dell'area del frame della pagina. L'accesso all'estensione avviene nell'area della barra degli strumenti dell'estensione per browser. L'accesso alla cassetta di sicurezza nel browser avverrà sempre nei dominii keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca o govcloud.keepersecurity.us oppure dalla barra degli strumenti dell'estensione di Keeper, che esiste al di fuori della pagina dei contenuti.

L'estensione per browser di Keeper inserisce un iFrame nei moduli di accesso di una pagina web per garantire che nessun sito web dannoso abbia accesso ai contenuti iniettati. Il contenuto delle voci iniettate negli iFrame è inoltre limitato alle voci memorizzate nella cassetta di sicurezza dell'utente che corrispondono al dominio del sito web di destinazione. Keeper non offre la compilazione automatica di credenziali e password a meno che il dominio del sito web non corrisponda al campo del dominio del sito web della voce della cassetta di sicurezza di Keeper. L'estensione non mostrerà le voci se non corrispondono al dominio principale dell'indirizzo del sito web.

Le estensioni per browser di terze parti possono avere autorizzazioni elevate nei browser e quindi accedere alle informazioni all'interno della pagina. Pertanto, si raccomanda agli amministratori di Keeper di impedire agli utenti di installare estensioni per browser di terze parti dal rispettivo app store.

Sistemi biometrici

Keeper supporta nativamente Windows Hello, Touch ID, Face ID e i metodi biometrici di Android. I clienti che normalmente accedono alla propria cassetta di sicurezza di Keeper utilizzando una password principale o un login SSO aziendale (SAML 2.0) possono anche accedere ai propri dispositivi utilizzando un metodo biometrico. La biometria deve essere abilitata dall'amministratore di Keeper nelle regole stabilite per i ruoli. L'accesso offline può essere ottenuto anche con un metodo biometrico sia per la password principale che per gli utenti abilitati al SSO quando questa funzione è attivata.

Quando il login biometrico è abilitato su un dispositivo, una chiave viene generata in modo casuale localmente e memorizzata nell'enclave protetta (ad esempio, nel portachiavi o nel keystore) del dispositivo. La chiave dati dell'utente viene crittografata con la chiave biometrica. Se l'autenticazione biometrica ha esito positivo, la chiave viene recuperata e l'utente è in grado di decrittografare la propria cassetta di sicurezza.

Portachiavi di iOS, Touch ID e Face ID

Touch ID e Face ID sui dispositivi iOS consentono agli utenti di accedere alla propria cassetta di sicurezza di Keeper utilizzando la biometria. Per fornire questa comoda funzione, una "chiave biometrica" a 256 bit generata in modo casuale viene memorizzata nel portachiavi di iOS. L'elemento del portachiavi di iOS creato per questa funzionalità non è destinato alla sincronizzazione con il portachiavi iCloud e quindi non lascerà il dispositivo mobile iOS.

Si consiglia vivamente di utilizzare una password principale complessa e di attivare l'autenticazione multifattoriale per garantire la massima sicurezza della propria cassetta di sicurezza di Keeper crittografata. L'utilizzo di Touch ID e Face ID rende più comodo l'uso di una password principale complessa sul proprio dispositivo mobile iOS. Si consiglia inoltre di impostare un codice d'accesso più lungo delle 4 cifre minime per proteggere il portachiavi di iOS.

Il portachiavi di iOS viene utilizzato da iOS e dalle app per memorizzare le credenziali in modo sicuro. Le app per iOS utilizzano il portachiavi di iOS per conservare tante informazioni sensibili, incluse le password ai siti web, le chiavi, i numeri delle carte di credito e le informazioni di Apple Pay. Keeper non utilizza il portachiavi di iOS per archiviare le voci di Keeper: tutte le voci di Keeper sono protette da una crittografia AES a 256 bit e sono archiviate in modo sicuro nella cassetta di sicurezza di Keeper. Anche il portachiavi di iOS è protetto da una crittografia AES a 256 bit utilizzando il codice d'accesso del dispositivo. Anche se il dispositivo viene smarrito o rubato o se un malintenzionato ottiene l'accesso fisico al dispositivo mobile, non potrà accedere alle informazioni memorizzate di Keeper. Il portachiavi di iOS non può essere decrittografato senza il codice d'accesso e la cassetta di sicurezza non può essere decrittografata senza la password principale di Keeper dell'utente.

Apple Watch ^®

La funzione Preferiti di Apple Watch consente di visualizzare le voci selezionate sull'Apple Watch associato. È necessario che la visualizzazione delle voci di Keeper sia stata esplicitamente abilitata su Apple Watch. Il dispositivo associato comunica con l'apposita estensione per orologio di Keeper che chiaramente viene eseguita in modo indipendente dall'app Keeper per iOS. L'estensione per orologio di Keeper utilizza inoltre il portachiavi di iOS per archiviare e accedere ai codici in modo protetto e consentire una comunicazione sicura e senza intoppi con l'app Keeper per iOS.

KeeperDNA^®

KeeperDNA offre un metodo di autenticazione multifattoriale utilizzando uno smart watch. KeeperDNA utilizza token sicuri memorizzati nella cassetta di sicurezza di Keeper per generare codici a tempo per l'autenticazione multifattoriale. Tali richieste di autenticazione a tempo possono essere approvate e inviate automaticamente dall'Apple Watch (o dal dispositivo Android Wear) con un tocco sullo schermo dell'orologio o inserite manualmente dall'utente.

Offboarding dei dipendenti (trasferimento della cassetta di sicurezza)

Quando si attiva la regola di trasferimento dell'account per un nodo, nella console di amministrazione sul dispositivo dell'utente viene creata la regola del nodo per una coppia di chiavi pubbliche/private. La chiave dati dell'utente finale, per gli utenti con un ruolo a cui viene applicata l'imposizione, viene crittografata con la chiave pubblica della regola quando l'utente accede alla cassetta di sicurezza. La chiave privata viene crittografata con la chiave pubblica dell'amministratore, che può quindi decrittografare la chiave di imposizione del ruolo con un trasferimento della cassetta di sicurezza.

Quando si esegue un trasferimento della cassetta di sicurezza, l'amministratore di Keeper deve prima bloccare l'account dell'utente. Il trasferimento della cassetta di sicurezza può quindi avvenire immediatamente, seguito dall'eliminazione dell'account dell'utente. In questo modo si garantisce che l'operazione non venga eseguita in segreto. Quando si esegue il trasferimento, la chiave dati dell'utente viene recuperata rivelando dapprima la chiave privata di imposizione del ruolo e poi la chiave dati dell'utente. La chiave dati viene utilizzata per aprire le chiavi delle voci, le chiavi dei team e le chiavi delle cartelle.

Tutta la crittografia viene eseguita dal lato client all'interno della console di amministrazione e Keeper non ha mai la possibilità di decrittografare le informazioni condivise o trasferite. Inoltre, la chiave dati del client di un utente non viene mai condivisa. Un utente rimosso da un team, da una cartella condivisa o da una condivisione diretta non riceverà nuovi dati dal team, dalla cartella condivisa o dalla voce. Sebbene le chiavi delle voci, delle cartelle e dei team vengano decrittografate localmente per l'amministratore durante la transazione, le chiavi non possono essere utilizzate per accedere ai dati delle voci o delle cartelle sottostanti.

Durante il trasferimento della cassetta di sicurezza, l'amministratore riceve solo la chiave dati crittografata, le chiavi delle voci crittografate e le chiavi delle cartelle crittografate. Decrittografa queste chiavi, che vengono poi crittografate di nuovo con la chiave pubblica della cassetta di sicurezza di destinazione. Non ha mai accesso ai dati effettivi delle voci. Keeper non crittografa direttamente i dati memorizzati dal client con la chiave dati, ma lo fa sul dispositivo.

Certificazioni e conformità

Noi di Keeper ci teniamo moltissimo alla sicurezza. Keeper è la soluzione di sicurezza delle password nonché la piattaforma di gestione degli accessi con privilegi più sicura, certificata, testata e verificata al mondo. Keeper possiede le certificazioni SOC 2 e ISO più longeve del settore. Keeper è certificata ISO 27001, 27017 e 27018. Keeper è conforme al GDPR, alla CCPA, all'HIPAA, è autorizzata FedRAMP e GovRAMP, è conforme alla PCI DSS e alla certificazione TrustArc per la privacy.

• I team di sviluppo software di Keeper sono composti da dipendenti a tempo pieno situati negli Stati Uniti.
• Keeper non memorizza password, credenziali o chiavi segrete come le chiavi d'accesso nel suo codice sorgente. Esaminiamo regolarmente il codice sorgente alla ricerca di tali informazioni.
• Il codice sorgente di Keeper, pur essendo privato in GitHub Enterprise, non fornisce le informazioni necessarie per accedere alla cassetta di sicurezza di un utente, poiché la crittografia dei dati avviene a livello di dispositivo. Gran parte di questo codice è pubblicato nel nostro repository pubblico su GitHub come parte dei prodotti Commander e Secrets Manager di Keeper.
• Keeper non incorpora nelle proprie applicazioni il codice di fornitori di AMF terze parti. I fornitori di Keeper non sono stati oggetto di violazioni che hanno coinvolto Keeper.
• Keeper non fornisce a terzi la gestione o l'accesso ai propri centri dati di AWS. Tutta la gestione è affidata a dipendenti a tempo pieno di Keeper Security, cittadini statunitensi e residenti negli Stati Uniti.

FIPS 140-3 convalidato

Keeper utilizza moduli di crittografia convalidati FIPS 140-3 per soddisfare i rigorosi requisiti di sicurezza del governo e del settore pubblico. La crittografia di Keeper è stata certificata dal NIST Cryptographic Module Validation Program (CMVP) e convalidata secondo lo standard FIPS 140 da laboratori terzi accreditati.

Keeper utilizza la crittografia convalidata FIPS 140-3 che ha ottenuto il certificato 4743 secondo lo standard NIST CMVP.

Conformità ITAR

Keeper Security Government Cloud (KSGC) supporta la conformità alle normative statunitensi sul traffico internazionale di armi (International Traffic in Arms Regulations, ITAR). Le aziende soggette alle normative sulle esportazioni ITAR devono controllare le esportazioni indesiderate limitando l'accesso ai dati protetti ai cittadini statunitensi e limitando l'ubicazione fisica dei dati protetti agli Stati Uniti.

L'ambiente FedRAMP Moderate di KSGC supporta i requisiti ITAR attraverso quanto segue:

• L'archiviazione dei dati completamente conforme è ospitata su AWS GovCloud e limitata agli Stati Uniti.
• KSGC offre una crittografia sicura dei dati in transito e a riposo.
• La sicurezza zero-knowledge e zero-trust, insieme alle autorizzazioni granulari, consente alle organizzazioni di garantire che solo il personale approvato possa accedere ai dati sensibili.
• solide funzionalità di segnalazione della conformità offrono una audit trail elettronica tracciabile di tutte le azioni eseguite e dei dati inseriti;
• Il team dedicato che si occupa di rapporti e soddisfazione dei clienti è composto da cittadini residenti negli Stati Uniti e formati appositamente nella gestione sicura dei dati controllati per l'esportazione sottostanti le norme ITAR, senza alcun supporto non statunitense.

L'ambiente FedRAMP di Keeper è stato sottoposto a un audit da parte di un'organizzazione indipendente di valutazione di terze parti (3PAO) per convalidare l'esistenza di controlli adeguati a supporto dei programmi di conformità alle esportazioni dei clienti e continua a essere sottoposto a audit annuali come richiesto per mantenere la conformità.

Ulteriori informazioni su ITAR.

Autorizzato da FedRAMP

KSGC è la piattaforma di sicurezza digitale e gestione password di Keeper Security per gli enti della Pubblica Amministrazione. KSGC è un provider autorizzato di FedRAMP a "Moderate Impact Level", ospitato in AWS GovCloud (USA). KSGC è disponibile in FedRAMP Marketplace.

Il Federal Risk and Authorization Management Program (FedRAMP) è un programma governativo federale degli Stati Uniti che fornisce un approccio standardizzato nella verifica, nell'autorizzazione e nel monitoraggio continuo della sicurezza dei prodotti e dei servizi legati al cloud. FedRAMP cerca di accelerare l'adozione di moderne soluzioni basate sul cloud da parte delle agenzie governative, con particolare attenzione alla sicurezza e alla protezione delle informazioni federali. Maggiori informazioni sul FedRAMP.

Autorizzazione GovRAMP

GovRAMP è stato sviluppato circa un decennio dopo FedRAMP con l'obiettivo di incoraggiare l'adozione di soluzioni sicure basate sul cloud nelle amministrazioni statali e locali. L'ottenimento dell'autorizzazione GovRAMP richiede normalmente un processo di due anni, che è stato semplificato attraverso un programma di reciprocità grazie all'autorizzazione FedRAMP di Keeper.

Conformità a SOC 2

I dati della cassetta di sicurezza dei clienti sono protetti da pratiche di controllo interne rigorose e altamente monitorate. Da oltre dieci anni Keeper possiede la certificazione SOC 2 di tipo 2, in conformità con il framework del Service Organization Control di AICPA. La conformità a SOC 2 contribuisce a garantire la sicurezza delle cassette di sicurezza degli utenti attraverso l'implementazione di controlli standardizzati, come definito nel framework dei Trust Service Principles di AICPA.

Certificazioni ISO

Keeper ha ottenuto le certificazioni ISO 27001, 27017 e 27018, che riguardano il sistema di gestione delle informazioni di sicurezza di Keeper e l'infrastruttura cloud, che supporta la piattaforma aziendale di Keeper. Le certificazioni ISO di Keeper comprendono la gestione e il funzionamento della cassetta di sicurezza digitale e dei servizi cloud, i controlli di sicurezza del cloud, i controlli sulla privacy dei dati, lo sviluppo di software e applicazioni e la protezione degli asset digitali sia per la cassetta di sicurezza digitale che per i servizi cloud.

Conformità al CFR Titolo 21 Parte 11 della FDA

Keeper è conforme al Codice delle normative federali (CFR) Titolo 21 Parte 11 della Food and Drug Administration statunitense, che si applica agli scienziati che operano in ambienti altamente regolamentati, tra cui i ricercatori che conducono trial clinici. Tale norma specifica i criteri della FDA secondo cui i record elettronici e le firme elettroniche sono considerati degni di fiducia, affidabili ed equivalenti ai record cartacei con firma scritta a mano. Nello specifico, gli scienziati devono accertarsi che tutto il software da loro utilizzato sia conforme alle regole del CFR Titolo 21 Parte 11 riguardo a:

I controlli di sicurezza per l'identificazione dell'utente - Keeper si conforma ai requisiti del CFR Titolo 21 Parte 11 per quanto riguarda le funzionalità di sicurezza che limitano l'accesso degli utenti e ai loro privilegi, tra cui garantire che tutti gli utenti abbiano nomi utente e password univoci, la possibilità di rilevare e impedire accessi non autorizzati al sistema e la possibilità di bloccare gli account compromessi.

Audit trail dettagliato

Durante le ispezioni della FDA, le autorità di regolamentazione richiedono ai ricercatori di fornire un audit trail che descriva nel dettaglio la cronologia di tutte le operazioni. Le funzioni di segnalazione di Keeper consentono ai ricercatori di produrre facilmente audit trail elettronici tracciabili.

Firme elettroniche

Quando un documento richiede una firma elettronica legalmente vincolante, il CFR Titolo 21 Parte 11 della FDA stabilisce che la firma venga associata a un login e una password univoci o all'identificazione con metodo biometrico. Keeper supporta tale requisito abilitando degli strumenti di ricerca che si assicurano che tutti gli utenti abbiano nomi utente e password univoche, conservate al sicuro in una cassetta digitale a cui soltanto l'utente può accedere.

Ulteriori informazioni sulla Parte 11 del CFR 21 si trovano qui.

Protezione dei dati sanitari dei pazienti

Il software di Keeper è conforme agli standard globali sulla protezione delle informazioni medico-sanitarie, che comprendono, senza limitazioni, la normativa statunitense HIPAA (Health Insurance Portability and Accountability Act) e la legge sulla protezione dei dati (Data Protection Act o DPA).

Conformità HIPAA e contratti Business Associate Agreement (BAA)

Keeper è una piattaforma di sicurezza zero-knowledge certificata SOC2 e ISO 27001, conforme alla normativa HIPAA. Vengono mantenuti una rigorosa aderenza e controlli su privacy, riservatezza, integrità e disponibilità. Grazie a questa architettura di sicurezza, Keeper non può decrittografare, visualizzare o accedere a nessuna informazione, comprese le ePHI, archiviate nella cassetta di sicurezza di Keeper dell'utente. Per le ragioni di cui sopra, Keeper non è una Business Associate secondo la definizione dell'Health Insurance Portability and Accountability Act (HIPAA) e, pertanto, non è soggetta a un contratto di Business Associate.

Per saperne di più sui vantaggi aggiuntivi per gli operatori sanitari e le compagnie di assicurazione sanitaria, leggete l'intera Informativa sulla sicurezza e consultate la nostra Guida alle imprese.

Certificazione FSQS-NL

Keeper Security EMEA Limited è certificata secondo il sistema Hellios Financial Services Qualification System-Netherlands (FSQS-NL), il quale riconosce i più alti standard di sicurezza, qualità e innovazione nei Paesi Bassi. Questo standard dimostra la conformità con il Financial Conduct Authority e il Prudential Regulation Authority per garantire l'affidabilità del software Keeper Enterprise per grandi banche e istituti finanziari.

Licenza ai sensi dell'EAR concessa dall'U.S. Department of Commerce Export

Keeper è certificata dal Bureau of Industry and Security del Dipartimento del Commercio degli Stati Uniti d'America con il numero di controllo della classificazione delle merci esportate 5D992, in conformità con i regolamenti sull'amministrazione delle esportazioni (EAR).
Per ulteriori informazioni su EAR: https://www.bis.doc.gov

Monitoraggio remoto 24 ore su 24, 7 giorni su 7

Keeper è monitorata 24 ore su 24, 7 giorni su 7, 365 all'anno da personale DevOps a tempo pieno e da una rete di monitoraggio globale di terze parti per garantire che il nostro sito web e il Cloud Security Vault siano disponibili in tutto il mondo.

In caso di domande relative alla presente informativa sulla sicurezza, contattateci.

Email di phishing o falsificate

Se ricevete un'e-mail che sembra inviata da Keeper Security e non siete sicuri che sia legittima, potrebbe trattarsi di una "e-mail di phishing" in cui l'indirizzo e-mail del mittente è falsificato. In questo caso, l'e-mail può contenere link a un sito web che assomiglia a KeeperSecurity.com ma non è il nostro sito. Il sito web potrebbe chiedervi la vostra password principale di Keeper Security o tentare di installare un software indesiderato sul vostro computer con l'intenzione di rubare le vostre informazioni personali o accedere al vostro computer. Altre e-mail contengono link che possono reindirizzare l'utente ad altri siti web potenzialmente pericolosi. Il messaggio può anche includere allegati, che di solito contengono software indesiderato chiamato "malware". Se non siete sicuri di un'e-mail ricevuta nella vostra casella di posta, dovreste eliminarla senza fare clic su alcun link o aprire alcun allegato.

Se desiderate segnalare un'e-mail che sembra provenire da Keeper e che ritenete sia falsa o se avete altri problemi di sicurezza che riguardano altre questioni, non esitate a contattarci.

Infrastruttura di hosting certificata secondo gli standard più rigidi del settore

Il sito Web di Keeper e il cloud storage sono compatibili con l'infrastruttura di cloud computing Amazon Web Services (AWS). L'infrastruttura cloud AWS che ospita l'architettura del sistema di Keeper ha ottenuto la certificazione di conformità con i seguenti attestati, rapporti e certificazioni di terze parti:

Programma di segnalazione delle vulnerabilità e di bug bounty

Keeper Security si dedica allo sviluppo della soluzione di gestione delle password e degli accessi con privilegi più sicura del mercato. Ci impegniamo a proteggere la privacy e i dati personali dei nostri clienti. La missione di Keeper è costruire la piattaforma di sicurezza più sicura e innovativa del mondo e riteniamo che la segnalazione di bug da parte della comunità mondiale di ricercatori della sicurezza sia fondamentale per garantire la sicurezza dei prodotti e dei servizi di Keeper.

Keeper conduce numerosi test interni ed esterni, tra cui pen-test eseguiti da NCC Group e CyberTest con accesso completo al codice sorgente. Keeper gestisce il proprio programma di divulgazione delle vulnerabilità in collaborazione con Bugcrowd. Nel complesso, ciò va a vantaggio dell'intero settore e, inoltre, sostiene il bene comune.

Linee guida

La Politica di divulgazione delle vulnerabilità di Keeper stabilisce cosa aspettarsi quando si lavora con hacker etici nonché cosa aspettarsi da noi di Keeper Security.

Se i test di sicurezza e i rapporti vengono eseguiti secondo le linee guida di questa informativa, noi:

• la considereremo autorizzata in conformità con il Computer Fraud and Abuse Act.
• la considereremo esente dal DMCA e non presenteremo alcuna richiesta di risarcimento nei vostri confronti per aver aggirato i controlli di sicurezza o tecnologici.
• la considereremo legale e non perseguiremo né sosterremo alcuna azione legale nei vostri confronti in relazione a questo programma.
• collaboreremo con voi per capire e risolvere rapidamente il problema.
• riconosceremo pubblicamente il vostro contributo se sarete i primi a segnalare il problema e ad apportare una modifica al codice o alla configurazione in base al problema.

Se in qualsiasi momento avete dubbi o incertezze su come effettuare i test in modo coerente con le linee guida e l'ambito di applicazione di questa informativa, contattateci all'indirizzo security@keepersecurity.com prima di procedere oltre.

Per incoraggiare il testing etico sulla sicurezza e la divulgazione delle vulnerabilità scoperte, vi chiediamo di:

• Evitate di violare la privacy degli utenti, di danneggiarne l'esperienza, di interrompere la produzione o i sistemi aziendali e/o di distruggere i dati.
• Eseguite le ricerche solo nell'ambito del programma di divulgazione delle vulnerabilità di Bugcrowd, indicato di seguito, e rispettate i sistemi e le attività che non rientrano nell'ambito di applicazione.
• Contattateci immediatamente all'indirizzo security@keepersecurity.com qualora riscontraste dati utente durante il test.
• Concedeteci un tempo ragionevole per analizzare, confermare e risolvere il problema segnalato prima di divulgare pubblicamente qualsiasi scoperta di vulnerabilità.

Inviate i rapporti tramite: https://bugcrowd.com/keepersecurity

Trasparenza

Keeper non si limita a impegnarsi per la sicurezza, ma lo fa con grande zelo. È per questo che ogni dettaglio del nostro modello di crittografia è disponibile al pubblico. Riteniamo che i nostri clienti meritino di conoscere ogni passo che compiamo per garantire la sicurezza dei loro dati in un panorama di cybersecurity in continua evoluzione.

Il modello di crittografia zero-trust e zero-knowledge di Keeper assicura che anche nel peggiore dei casi la vostra cassetta di sicurezza di Keeper sia protetta; dal canto nostro, conduciamo continuamente test di sicurezza per assicurarci di rimanere la soluzione migliore per proteggere i vostri dati più preziosi.

Dichiarazione sulla schiavitù moderna

Documentazione di prodotto

Il portale della documentazione di Keeper, contenente manuali di prodotto, informazioni tecniche, note di rilascio e guide per l'utente finale, è disponibile a questo link..

Note di rilascio dei prodotti

Per maggiore trasparenza, Keeper pubblica note di rilascio dettagliate su tutte le piattaforme.

Stato del sistema

Lo stato del sistema in tempo reale è disponibile qui.