Keeper est fanatique de la sécurité des identifiants et de la protection des données

Présentation

Keeper Security, Inc. s'est donné pour mission de protéger les informations de ses clients à l'aide des logiciels de sécurité Keeper pour les appareils mobiles et les ordinateurs. Des millions de consommateurs et d'entreprises font confiance à Keeper pour sécuriser leurs mots de passe et leurs informations privées et y accéder.

Le logiciel Keeper est constamment amélioré et mis à jour afin d'offrir la technologie et la protection les plus récentes à nos clients. Cette page présente l'architecture de sécurité, les méthodes de chiffrement et l'environnement d'hébergement de Keeper dans sa version actuelle. Ce document détaille les aspects techniques de nos méthodes de chiffrement et de sécurité.

Notre politique de confidentialité et nos conditions d'utilisation sont disponibles sur notre site web en cliquant sur les liens suivants :

Plateforme zero-trust

Keeper repose sur une architecture zero trust, qui prévoit la vérification et l'authentification de chaque utilisateur avant qu'il ne puisse accéder à un site web, à une application ou à un système.

Enterprise Password Management (EPM) de Keeper dote les entreprises d'une visibilité et d'un contrôle total sur les pratiques de leurs collaborateurs en matière de mots de passe, ce qui permet aux administrateurs informatiques de surveiller l'utilisation des mots de passe et d'appliquer les bonnes pratiques en matière de sécurité.

Keeper Secrets Manager (KSM) propose une plateforme destinée aux ingénieurs pour gérer tous les identifiants, notamment les secrets d'infrastructure, les clés SSH, les clés d'API et les certificats, avec des SDK et une intégration CI/CD.

Keeper Connection Manager (KCM) est une passerelle de bureau à distance qui fournit aux équipes DevOps et informatiques un accès réseau zero trust (ZTNA) en toute simplicité à RDP, SSH, aux bases de données, aux applications web internes et aux points terminaison Kubernetes par le biais d'un navigateur web, sans aucun agent.

Zoom sur Keeper - N°1 sur la sécurité

Chiffrement du coffre-fort de données

Keeper propose un modèle de chiffrement multicouche basé sur le principe du moindre privilège. Des clés AES 256 bits au niveau de l'archive et du dossier sont générées sur l'appareil client pour chiffrer chaque archive stockée. Les archives et l'ensemble de leur contenu sont entièrement chiffrés, y compris les identifiants, les pièces jointes, les codes TOTP, les informations de paiement, les URL et les champs personnalisés.

Les clés de chiffrement sont générées localement sur l'appareil afin de préserver le principe de zero knowledge et de prendre en charge des fonctionnalités avancées telles que le partage d'archives et de dossiers. La notion de zero knowledge signifie que chaque utilisateur dispose d'un contrôle total sur le chiffrement et le déchiffrement de toutes les informations personnelles contenues dans son coffre-fort Keeper, et qu'aucune de ses informations déchiffrées n'est accessible par quiconque, pas même par le personnel de Keeper.

Les clés d'archives et les clés de dossiers sont chiffrées par une clé de données AES 256 bits propre à chaque utilisateur et générée sur son appareil.

Une autre clé client AES 256 bits est générée sur l'appareil de l'utilisateur pour chiffrer un cache local hors ligne (si l'administrateur de l'entreprise autorise l'accès hors ligne). Enfin, la clé de données AES 256 bits est chiffrée avec une autre clé, comme décrit dans la section suivante.

Méthodes de chiffrement du coffre-fort

Keeper chiffre les données de différentes manières en fonction de la méthode de connexion des utilisateurs. Les consommateurs et les membres d'une formule famille se connectent à l'aide d'un mot de passe principal et d'un système d'authentification biométrique. Les utilisateurs professionnels qui se connectent par authentification unique (SSO) bénéficient d'une expérience sécurisée et sans mot de passe grâce au chiffrement sur courbe elliptique de Keeper.

Dans le cas des utilisateurs qui se connectent avec un mot de passe principal, la clé permettant de déchiffrer et de chiffrer la clé de données est dérivée du mot de passe principal de l'utilisateur à l'aide de la fonction de variation de clé basée sur le mot de passe (PBKDF2), avec 1 000 000 d'itérations. Une fois que l'utilisateur a saisi son mot de passe principal, la clé est dérivée localement et dévoile ensuite la clé de données. La clé de données est déchiffrée et utilisée pour dévoiler les clés individuelles des archives et des dossiers. Le contenu des archives est stocké localement sur l'appareil de l'utilisateur après le déchiffrement de chaque clé.

Concernant les utilisateurs qui se connectent à l'aide d'une technologie SSO ou sans mot de passe, la cryptographie sur courbe elliptique permet de chiffrer et de déchiffrer les données au niveau de l'appareil. Une clé privée ECC-256 (secp256r1) locale permet de déchiffrer la clé de données. Une fois la clé de données déchiffrée, elle sert à décrypter les clés individuelles des archives et des dossiers. La clé de l'archive déchiffre alors tout le contenu de l'archive stockée. La clé de données chiffrée est transmise entre les appareils de l'utilisateur par l'intermédiaire d'un système « push » ou d'un service d'échange de clés, appelé « approbation d'appareil ». Pour préserver le principe de zero knowledge, l'approbation d'appareil est gérée localement par l'utilisateur final.

Modèle de chiffrement SSO

Premier flux de l'appareil (intégration d'un nouvel utilisateur)

1. Génération de la clé de données, de la paire de clés de partage et de la paire de clés privée/publique de la CE de l'appareil
2. Chiffrement de la clé de données à l'aide de la clé publique CE de l'appareil et stockage dans le cloud (DEDK)
3. Connexion de l'utilisateur avec son fournisseur d'identité (IdP)
4. Après connexion à l'IdP, vérification de l'assertion SAML signée par Keeper
5. Création du coffre-fort et intégration de l'utilisateur

Flux de dispositif existant

1. Connexion de l'utilisateur avec son fournisseur d'identité (IdP)
2. Après connexion à l'IdP, vérification de l'assertion SAML signée par Keeper
3. Délivrance de la clé de données chiffrée (DEDK) à l'utilisateur par Keeper
4. Déchiffrement de la clé de données à l'aide de la clé privée CE de l'appareil
5. Déchiffrement des clés de dossier et des clés d'archive par la clé de données
6. Déchiffrement du contenu de l'archive à l'aide des clés de l'archive

Flux de dispositif nouveau ou non reconnu

1. Génération d'une paire de clés privée/publique CE sur chaque nouvel appareil
2. Connexion de l'utilisateur avec son fournisseur d'identité (IdP)
3. Après connexion à l'IdP, vérification de l'assertion SAML signée par Keeper
4. L'appareil est « approuvé » par Keeper Push, l'approbation de l'administrateur ou le service Keeper Automator (*voir Approbation de l'appareil ci-dessous).
5. Au cours du processus d'approbation, la clé de données est chiffrée avec la clé publique du nouvel appareil
6. Envoi de la clé de données chiffrée de l'appareil (DEDK) à l'utilisateur

Approbation d'appareil

• L'approbation d'un appareil est un mécanisme qui permet de transmettre en toute sécurité la clé de données de l'utilisateur à son nouvel appareil tout en préservant le principe de zero knowledge
• Un utilisateur peut approuver son appareil en chiffrant la clé de données avec la clé publique du nouvel appareil
• Un administrateur peut approuver le dispositif à partir de la console d'administration, du service Commander ou du service Keeper Automator
• L'administrateur déchiffre la clé de données de l'utilisateur et la chiffre à nouveau avec la clé publique du nouvel appareil
• Le service Keeper Automator peut effectuer des approbations automatisées d'appareils sur l'infrastructure du client
• Keeper Automator vérifie la signature SAML, dévoile la clé de données et chiffre la clé de données avec la clé publique du nouvel appareil.

En savoir plus sur le service Automator de Keeper.

Sécurité au niveau de l'appareil pour SSO Connect Cloud

Pour les utilisateurs de SSO Connect Cloud, une clé privée sur courbe elliptique est générée et stockée localement sur chaque appareil. Sur les navigateurs web modernes et l'application de bureau Keeper basée sur Electron, le coffre-fort Keeper stocke la clé privée CE locale de l'appareil (« DPRIV ») en tant que CryptoKey non exportable. Sur les appareils iOS et macOS, la clé est stockée dans le trousseau de l'appareil. Sur les appareils Android, la clé est chiffrée avec le Keystore Android, en utilisant les préférences partagées chiffrées. Si possible, Keeper utilise des mécanismes de stockage sécurisés sur chaque système d'exploitation.

La clé privée du dispositif ne sert pas directement à chiffrer ou déchiffrer les données du coffre-fort. Une fois l'authentification du fournisseur d'identité réussie, une clé distincte (qui n'est pas déchiffrée) vient déchiffrer les données du coffre-fort. Par conséquent, il est impossible de déchiffrer le coffre-fort d'un utilisateur en extrayant hors ligne la clé privée locale de l'appareil.

Chiffrement des données au repos

Keeper fait appel à AWS pour héberger sa plateforme et son architecture. Nos centres de données AWS sont situés à plusieurs endroits, et nos clients peuvent héberger leur titulaire Keeper dans n'importe quelle région primaire préférée. Ainsi, les données du client et l'accès à la plateforme sont isolés dans cette région spécifique.

Les données du coffre-fort au repos sont chiffrées localement sur l'appareil de l'utilisateur en AES-256 GCM, et les données chiffrées en transit sont chiffrées à l'aide du protocole TLS 1.3, avec une couche supplémentaire de chiffrement dans la charge utile. Les données des clients sont isolées grâce à un chiffrement au niveau de l'archive.

Le modèle de chiffrement de Keeper s'appuie sur la structure suivante :

• Tous les coffres-forts sont chiffrés par une clé unique AES 256 bits générée côté client en mode GCM.
• Toutes les clés au niveau de l'archive dans les dossiers partagés sont protégées par une clé de dossier partagé AES 256 bits.
• Les clés des archives et des dossiers des utilisateurs du coffre-fort sont chiffrées à l'aide d'une autre clé AES 256 bits appelée clé de données.
• Dans le cas de Keeper Secrets Manager (KSM), les clés des archives et des dossiers de l'utilisateur sont chiffrées à l'aide d'une clé d'application AES de 256 bits.
• Lorsque les utilisateurs se connectent à l'aide d'un mot de passe principal, les clés qui permettent de déchiffrer et de chiffrer les données sont déchiffrées à partir du mot de passe principal.
• La connexion SSO ou la technologie sans mot de passe fait appel à la cryptographie sur courbe elliptique pour chiffrer et déchiffrer les données au niveau de l'appareil.
• Chaque charge utile chiffrée est envoyée aux serveurs Keeper et est protégée par une clé de transmission AES 256 bits avec TLS pour se prémunir contre les attaques de l'homme du milieu (MITM). La clé est générée sur le client et transférée avec un chiffrement ECIES via la clé publique sur courbe elliptique du serveur.
• Le partage sécurisé des secrets entre les utilisateurs repose sur la distribution de clés par cryptographie sur courbes elliptiques.

Versionnage d'entrée

Keeper conserve un historique chiffré de toutes les archives stockées dans le coffre-fort de l'utilisateur, assurant ainsi qu'aucune donnée critique n'est jamais perdue. Depuis l'application client de Keeper, les utilisateurs peuvent consulter l'historique des archives et restaurer n'importe quelle archive du coffre-fort. En cas de modification ou de suppression d'un mot de passe ou d'un fichier stocké dans Keeper, les utilisateurs ont toujours la possibilité d'effectuer une restauration à un moment donné.

Keeper Business

Les clients qui choisissent Keeper Business bénéficient d'un niveau de contrôle supplémentaire sur leurs utilisateurs et leurs appareils. Les administrateurs Keeper ont accès à une console d'administration dans le cloud qui permet un contrôle total sur l'intégration et le départ des utilisateurs, les autorisations basées sur les rôles, l'administration déléguée, les équipes, l'intégration Active Directory/LDAP, l'authentification à deux facteurs, l'authentification unique et les politiques de mise en œuvre de la sécurité. Les politiques d'application basées sur les rôles de Keeper sont entièrement personnalisables et évolutives pour les entreprises de toute taille.

Super chiffrement des données au repos

En plus de conserver uniquement le texte chiffré par l'appareil dans l'infrastructure AWS, Keeper effectue également un super chiffrement avec des modules de sécurité matériels (HSM) multirégionaux avec des clés non exportables.

Chiffrement et protection des sauvegardes

Au niveau du produit ou de l'utilisateur, le logiciel Keeper conserve un historique complet des révisions de chaque archive. Par conséquent, si un utilisateur a besoin d'une récupération, il peut consulter et revenir à des versions antérieures de ses archives Keeper stockées à tout moment, sans limite, par le biais de l'interface utilisateur.

Au niveau du système, les bases de données chiffrées et les objets fichiers de Keeper sont répliqués et sauvegardés dans plusieurs régions géographiques pour pouvoir être récupérés en cas de sinistre. Toutes les sauvegardes sont chiffrées en AES 256 en plus du super-chiffrement du texte chiffré généré par l'appareil.

Les clients qui ont besoin d'aide pour récupérer leurs données (par exemple, suite à la suppression accidentelle d'un coffre-fort ou d'un dossier partagé), peuvent contacter l'assistance Keeper qui les aidera à récupérer leurs données à n'importe quel moment (à la minute près) dans un délai de 30 jours. L'assistance Keeper peut intervenir sur la restauration d'un utilisateur, d'un coffre-fort ou de l'ensemble de l'entreprise.

Récupération de compte

Les clients de Keeper peuvent retrouver l'accès à leur coffre-fort en cas de perte ou d'oubli de leur mot de passe principal grâce à une phrase de récupération de 24 mots.

Keeper a intégré des phrases de récupération à partir de la même liste de mots BIP39 que celle utilisée pour protéger les portefeuilles crypto. La liste de mots BIP39 est un ensemble de 2 048 mots utilisés pour générer une clé de chiffrement avec 256 bits d'entropie. Cette méthode de récupération est couramment utilisée dans les portefeuilles de bitcoins et de cryptomonnaies les plus populaires. Chaque mot de la liste BIP39 est soigneusement sélectionné pour améliorer la visibilité et rendre le processus de récupération moins sujet aux erreurs. Les utilisateurs doivent noter leur phrase de récupération et la conserver dans un endroit sûr, tel qu'un coffre-fort.

La phrase de récupération génère une clé AES 256 bits qui chiffre une copie de la clé de données de l'utilisateur. Pour récupérer le compte et réinitialiser le mot de passe principal, les utilisateurs auront besoin de la phrase de récupération ainsi que d'un e-mail de vérification et d'une authentification à deux facteurs (2FA).

Les administrateurs de la formule Enterprise peuvent désactiver la récupération des comptes au niveau de la politique d'exécution des rôles.

Clés de chiffrement d'entreprise

Les clients de Keeper Enterprise et Business peuvent gérer de nombreuses fonctionnalités de la plateforme Keeper, telles que les politiques d'accès basées sur les rôles, l'approvisionnement, l'authentification et la gestion.

Les opérations d'administration sont protégées par la plateforme Keeper grâce au chiffrement et à l'autorisation. L'autorisation garantit que seuls les utilisateurs désignés peuvent exécuter certaines fonctions. Le chiffrement garantit que les administrateurs désignés sont uniquement en mesure d'exécuter physiquement et cryptographiquement des fonctionnalités qui impliquent des données du coffre-fort ou des clés contrôlées par l'entreprise. Voici quelques exemples :

• La plateforme de Keeper est une plateforme de gestion de clés de facto, où les utilisateurs et les administrateurs ont un contrôle total sur leurs clés privées.
• Des paires de clés de chiffrement publiques et privées servent à la création d'appareils, d'utilisateurs et d'équipes.
• Les politiques de rôle pour le transfert des coffres-forts et l'approbation des appareils reposent sur l'utilisation de clés de chiffrement publiques et privées.
• Les paires de clés sur courbe elliptique (CE) servent à partager des données entre utilisateurs, et de l'utilisateur individuel à l'administrateur au niveau de l'entreprise.
• Les données d'utilisation sensibles, telles que la force du mot de passe de l'archive, sont chiffrées à l'aide de clés publiques d'entreprise que seul l'administrateur peut déchiffrer.
• Les champs titre, URL et type d'archive de chaque utilisateur de l'entreprise sont chiffrés avec la clé publique de l'entreprise et peuvent être déchiffrés dans la console d'administration de Keeper, par un administrateur disposant des privilèges de rapport de conformité.

Vérification d'appareil

Avant de pouvoir tenter de se connecter à un compte, l'utilisateur doit d'abord passer par une étape d'approbation et de vérification de l'appareil. La vérification de l'appareil empêche l'énumération des comptes et protège contre les attaques par force brute.

Les clients qui se connectent à l'aide d'un mot de passe principal peuvent procéder à la vérification de l'appareil à l'aide de plusieurs méthodes, notamment :

• Code de vérification par e-mail
• Entrée du code d'authentification à deux facteurs à partir d'un TOTP ou d'un message texte
• Utilisation de Keeper Push^™ pour envoyer un message à un appareil reconnu

Pour les clients qui s'authentifient avec Keeper SSO Connect Cloud, l'approbation de l'appareil se fait avec un transfert de clé, dans lequel la clé de données chiffrée de l'utilisateur est transmise à l'appareil, avant d'être déchiffrée localement à l'aide de la clé privée sur courbe elliptique de l'utilisateur. Les méthodes d'approbation des appareils sont les suivantes :

• Keeper Push (avec des notifications push) vers les appareils des utilisateurs existants
• Approbation de l'administrateur via la console d'administration Keeper
• Approbation automatique via le service Keeper Automator
• Approbation automatique de l'administrateur via la CLI de Commander

En savoir plus sur l'approbation d'appareils.

Protection des données

Keeper se conforme au RGPD et s'engage à veiller à ce que ses processus et ses produits conservent cette conformité pour ses clients au sein de l'Union européenne et à travers le monde. 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.

Consulter la politique de confidentialité du RGPD de Keeper.

Aucune des applications de Keeper ne contient de traceurs ou de bibliothèques tierces effectuant du pistage. À titre d'exemple, ce rapport présente des informations sur l'application Android de Keeper, qui indique qu'aucun traceur n'est installé.

Isolement des données

Keeper est une plateforme SaaS entièrement gérée et qui héberge ses données dans plusieurs centres de données AWS géographiquement isolés. Les organisations peuvent héberger leur locataire Keeper dans leur région principale préférée. Les données client et l'accès à la plateforme sont limités à cette région spécifique.

Régions disponibles :

• États-Unis (US)
• Cloud du gouvernement des États-Unis (US_GOV)
• Europe (EU)
• Australie (AU)
• Japon (JP)
• Canada (CA)

Chiffrement en transit

Le coffre-fort Keeper est protégé par des API, qui sont validées par une autorisation sur l'appareil de l'utilisateur.

• L'utilisateur récupère un jeton de session avec son identifiant et l'envoie à chaque appel à l'API.
• Le jeton de session est géré et contrôlé par le serveur backend.
• La connexion s'effectue avec un mot de passe principal, la biométrie, la reprise de session ou l'authentification unique SAML 2.0.

Dans le cas du mot de passe principal, le dispositif de l'utilisateur obtient une clé d'authentification de 256 bits à l'aide de PBKDF2-HMAC_SHA256 avec 1 000 000 d'itérations et un salt aléatoire. Le hachage d'authentification résulte du hachage de la clé d'authentification avec SHA-256. Lors de la connexion, le hachage d'authentification est comparé à un hachage d'authentification stocké dans le coffre-fort Keeper. Une fois l'utilisateur connecté, un jeton de session est créé sur le serveur et envoyé à l'utilisateur pour que l'appareil l'utilise lors des demandes d'API ultérieures. La session doit être active pour permettre les communications client-serveur en continu.

• Keeper utilise le protocole TLS 256 bits et 128 bits pour chiffrer 100 % des données stockées dans l'application utilisateur et dans le stockage de fichiers sécurisé Keeper.
• Keeper déploie des certificats TLS signés à l'aide de l'algorithme SHA2. SHA2 est l'algorithme de signature le plus sécuritaire actuellement proposé par les autorités de certification commerciales. En utilisant l'algorithme SHA2, Keeper se protège contre les certificats contrefaits qu'un pirate pourrait utiliser pour usurper l'identité d'un site Web.

Authentification dans le cloud

Keeper a développé un modèle sophistiqué d'authentification dans le cloud et de communication en réseau qui respecte les plus hautes exigences en matière de confidentialité, de sécurité, de confiance et de transparence. Voici quelques caractéristiques clés de ce modèle d'authentification :

Intégration avec tous les fournisseurs SAML 2.0

Keeper s'intègre à tous les fournisseurs d'identité compatibles avec SAML 2.0, notamment Okta, Microsoft Entra ID (Azure), AD FS, Google Workspace, Centrify, OneLogin, Ping Identity, JumpCloud, Duo, Auth0 et bien d'autres encore.

Nos produits proposent deux solutions d'authentification unique : SSO Connect Cloud et SSO Connect On-Prem. Les deux implémentations présentent une architecture zero knowledge avec une authentification fluide pour les utilisateurs.

Les mots de passe principaux de l'utilisateur ne sont jamais transmis sur la couche réseau

Contrairement à la plupart des services SaaS, les identifiants de connexion des utilisateurs de Keeper ne quittent jamais leur appareil. Lorsque les utilisateurs se connectent à Keeper avec un mot de passe principal, l'algorithme PBKDF2 intervient sur l'appareil local pour dériver une clé AES de 256 bits afin de déchiffrer l'information. Une clé PBKDF2 supplémentaire est générée au niveau de l'appareil, puis hachée avec HMAC_SHA256 pour créer un jeton d'authentification. Keeper ne connaît pas la clé de déchiffrement de l'utilisateur.

Le trafic entre l'appareil client et le cloud Keeper ne peut pas être intercepté ou déchiffré

Toutes les charges utiles chiffrées envoyées aux serveurs de Keeper sont protégées par une clé de transmission AES 256 bits et TLS pour se prémunir contre les attaques de l'homme du milieu (MITM). La clé de transmission est générée sur le dispositif client et transférée au serveur en utilisant le chiffrement ECIES via la clé publique CE du serveur.

Les nouveaux appareils ne peuvent pas être utilisés pour s'identifier à un compte sans étape de vérification

Les utilisateurs ne peuvent pas utiliser de nouveaux appareils pour se connecter à leurs comptes Keeper sans utiliser une méthode de vérification. Keeper prend en charge plusieurs types de méthodes de vérification, en fonction du système d'authentification.

L'authentification multifacteur (MFA) intervient après la vérification, avant que l'utilisateur ne saisisse son mot de passe principal

En cas de configuration ou d'application de l'authentification multifacteur, l'utilisateur doit d'abord passer cette étape avant de saisir son mot de passe principal.

La saisie de mot de passe principal ne peut pas être effectuée tant que la vérification de l'appareil et les étapes de la MFA ne réussissent pas

Si aucune méthode de vérification n'est mise en place, l'utilisateur ne peut pas procéder à la saisie de son mot de passe principal. Cette authentification avancée offre une protection contre plusieurs méthodes d'attaque courantes, notamment les attaques par force brute, la pulvérisation de mot de passe, l'énumération et le MITM.

Authentification multifacteur (MFA)

Pour éviter tout accès non autorisé au compte d'un client, Keeper propose l'authentification multifacteur (MFA) : une approche qui nécessite au moins deux facteurs d'authentification, à savoir un facteur de connaissance, un facteur de possession et/ou un facteur d'inhérence. En savoir plus sur la mise en place de l'authentification multifacteur dans Keeper.

Keeper se base sur votre mot de passe principal et sur l'appareil en votre possession pour apporter une couche de sécurité supplémentaire en cas de compromission de votre mot de passe principal ou de votre appareil. Keeper prend en charge les clés matérielles FIDO2 WebAuthn et les solutions logicielles telles que TOTP et SMS.

En utilisant une méthode d'authentification multifacteur ou à deux facteurs TOTP, Keeper génère une clé secrète de 10 octets à l'aide d'un générateur de nombres aléatoires sécurisé sur le plan cryptographique. Ce code est valable pendant environ une minute et ne peut pas être réutilisé une fois l'authentification réussie. Keeper prend en charge n'importe quelle application TOTP, y compris Google Authenticator et Microsoft Authenticator. Keeper s'intègre également directement aux services d'authentification multifacteur les plus répandus, tels que Duo et RSA SecurID.

Si vous utilisez des authentificateurs multifacteurs, tels que Google Authenticator, Microsoft Authenticator ou d'autres applications TOTP sur votre appareil mobile, le serveur Keeper génère en interne un code QR contenant votre clé secrète. Chaque fois qu'un utilisateur active l'authentification multifacteur, une nouvelle clé est générée.

Pour activer l'authentification multifacteur, rendez-vous sur l'écran des paramètres de l'application Web, de l'application de bureau ou de l'application iOS/Android de Keeper. Les administrateurs de Keeper Business peuvent également imposer l'utilisation de l'authentification multifacteur et des méthodes prises en charge via la console d'administration de Keeper.

Keeper prend en charge WebAuth compatible avec FIDO2, avec des dispositifs de clés de sécurité matérielles tels que les clés YubiKey et Google Titan comme facteur supplémentaire. Les passkeys sont également pris en charge pour l'authentification à deux facteurs avec des appareils physiques ou des navigateurs web. Les clés de sécurité constituent un moyen sûr de procéder à l'authentification multifacteur sans que l'utilisateur n'ait à saisir les codes manuellement.

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID Message texte SMS Titan Security Key TOTP Yubico

Keeper Active Directory / Pont LDAP

Keeper Bridge s'intègre aux serveurs Active Directory et LDAP pour l'approvisionnement et l'intégration des utilisateurs. Un administrateur disposant des privilèges nécessaires pour gérer Keeper Bridge autorise d'abord la communication. Une clé de transmission est générée et partagée avec Keeper pour toute communication ultérieure. Cette clé de transmission autorise toutes les opérations effectuées par la passerelle, à l'exception de son initialisation. La clé de transmission peut être régénérée à tout moment et sera automatiquement renouvelée tous les 30 jours.

La clé de transmission sert uniquement à la transmission, ce qui signifie qu'une clé compromise peut être réinitialisée ou révoquée sans perte de données ou d'autorisation.

Keeper Bridge ne peut pas accorder de privilèges à un rôle ou à un utilisateur. Il peut ajouter un utilisateur à un rôle privilégié, à condition qu'aucune clé d'exécution ne soit nécessaire. Keeper Bridge ne peut pas s'élever lui-même ou élever un utilisateur au-dessus de la tranche de l'arbre qu'il gère. Il n'a pas accès à toutes les opérations, c'est-à-dire qu'il peut désactiver un utilisateur actif, mais ne peut pas le supprimer. L'administrateur devra choisir si l'utilisateur doit être supprimé ou transféré.

Authentification unique (SSO) avec authentification multifacteur

Lorsque Keeper est déployé avec une solution SSO telle que Entra ID / Azure AD, Okta, Ping, Google Workspace ou tout autre fournisseur d'identité SAML 2.0, la MFA peut être entièrement gérée pendant le processus d'identification IdP. Keeper prend également en charge les politiques d'accès implicite Azure sur tous les types d'appareils et toutes les applications.

L'authentification multifacteur peut être appliquée à la fois du côté du fournisseur d'identité et du côté du Keeper. Par exemple, une fois qu'un utilisateur a passé l'étape de l'authentification multifacteur avec le fournisseur d'identité, il peut être contraint de passer une seconde étape dl'authentification multifacteur au niveau de l'interface de Keeper. L'administrateur de Keeper peut appliquer cette politique.

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

Authentification SAML 2.0 avec SSO Connect Cloud

Keeper SSO Connect Cloud permet aux entreprises clientes d'intégrer complètement Keeper avec n'importe quel fournisseur d'identité compatible SAML 2.0 et de déployer des coffres-forts chiffrés pour ses utilisateurs.

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 est un service optionnel qui effectue des approbations d'équipe instantanées, des approbations d'appareil et des signatures d'utilisateur d'équipe lors d'une identification réussie du fournisseur d'identité SSO.

Une fois l'automatiseur en cours d'exécution, les utilisateurs peuvent accéder de manière transparente à Keeper sur les nouveaux appareils (non approuvés précédemment) après une authentification réussie avec votre fournisseur d'identité, sans aucune étape d'approbation supplémentaire.

Keeper SSO Connect On-Prem

Alors que la plupart des clients déploient le cloud Keeper SSO Connect, les clients qui ont besoin d'une solution sur site peuvent déployer le cloud SSO Connect, une intégration auto-hébergée qui nécessite un serveur d'application hébergé sous Windows ou Linux. Afin de maintenir la sécurité Zero Knowledge et d'assurer une expérience SSO transparente pour les utilisateurs, Keeper SSO Connect doit être installé sur le serveur du client. Les environnements Windows, Mac et Linux sont entièrement pris en charge avec les modes opérationnels d'équilibrage de charge haute disponibilité (HA) et le superchiffrement avec les modules de sécurité matériels.

Keeper SSO Connect génère et conserve automatiquement le mot de passe principal de chaque utilisateur approvisionné, constitué d'une clé de 256 bits générée de manière aléatoire. Ce mot de passe principal est chiffré avec la clé SSO. La clé SSO est chiffrée avec la clé d'arborescence. La clé SSO est récupérée sur le serveur au démarrage du service Keeper SSO Connect, puis déchiffrée à l'aide de la clé d'arborescence, stockée localement sur le serveur pour permettre le démarrage automatique du service. La communication entre SSO Connect et le Cloud Security Vault de Keeper est protégée par une clé de transmission. Les communications SAML sont signées cryptographiquement et sont protégées par l'algorithme de signature RSA-SHA256 ou ECDSA-SHA256 en fonction du type de clé de chiffrement (RSA ou ECC) fourni par le client.

Partage

Keeper permet de partager en toute sécurité des archives entre utilisateurs, avec une équipe interne ou même en dehors de l'entreprise (si l'administrateur de Keeper l'autorise).

=Partage d'entrées

Les utilisateurs de Keeper peuvent partager directement des archives entre eux. Pour ce faire, Keeper demande d'abord la clé publique sur courbe elliptique de l'utilisateur à partir de son coffre-fort. Chaque archive possède une clé d'archive chiffrée avec la clé publique sur courbe elliptique du destinataire et synchronisée avec le coffre-fort Keeper de l'utilisateur.

Le propriétaire de l'archive partagée chiffrée déchiffre la clé de l'archive avec sa clé privée à courbe elliptique. La clé de l'archive sera également chiffrée à nouveau avec la clé de données de l'utilisateur, et le texte chiffré est stocké dans le coffre-fort du destinataire.

Partage ponctuel

La fonction de partage ponctuel de Keeper permet le partage sécurisé et limité dans le temps d'une archive (mot de passe, identifiant, secret, connexion, document ou autre information confidentielle) avec n'importe qui, même s'il ne possède pas de compte Keeper. Le modèle de chiffrement du partage ponctuel de Keeper repose sur la même technologie que Keeper Secrets Manager (KSM) : une plateforme zero knowledge et zero trust qui sécurise l'infrastructure du cloud.

1. Le créateur génère un accès ponctuel en cliquant sur Partage ponctuel dans le coffre-fort Keeper de l'utilisateur. La clé d'archive AES 256 bits est chiffrée avec un jeton d'accès unique, et la valeur chiffrée est stockée dans le coffre-fort Keeper.
2. L'utilisateur partage le jeton d'accès ponctuel à un destinataire à l'aide d'une simple URL ou d'un code QR. La partie de l'URL qui contient le jeton d'accès est conservée dans la partie « identifiant de fragment » de l'URL, qui ne passe jamais par les serveurs de Keeper. Par conséquent, Keeper ne peut ni accéder à l'information ni la déchiffrer, et le principe de zero knowledge est préservé.
3. L'URL s'ouvre dans le navigateur de l'utilisateur et l'application du coffre-fort se charge sur l'appareil. Le jeton est directement transmis à l'application locale du coffre-fort, sans être envoyé au serveur.
4. Le destinataire utilise ensuite son appareil pour générer une paire de clés CE côté utilisateur final, et la clé privée est stockée localement, sur l'appareil, dans la mémoire CryptoKey du navigateur.
5. À la première utilisation du destinataire, la bibliothèque SDK procède à une authentification à l'aide du hachage du jeton d'accès à usage unique. Ensuite, le serveur de Keeper répond avec le texte chiffré de l'archive et la clé de l'archive chiffrée.
6. L'appareil déchiffre la clé d'archive avec le jeton d'accès à usage unique, et le contenu est déchiffré. La clé est stockée sur l'appareil client, dans la mémoire CryptoKey du navigateur ou à un autre point de stockage.
7. La clé d'archive chiffrée pour ce dispositif donné est supprimée, de sorte que le jeton ne peut plus être utilisé. Ensuite, la demande du client doit être signée avec la clé privée.
8. Les autres appels sur le même appareil sont envoyés avec un identifiant qui définit l'appareil et une demande qui est signée avec la clé privée du client. La demande pour l'identifiant de l'appareil donné (par le biais de la signature ECDSA) utilise la clé publique du client de l'appareil et est vérifiée par le serveur. Keeper traite la demande et le serveur renvoie une archive chiffrée en texte chiffré à l'appareil de l'utilisateur.
9. En plus du chiffrement au niveau de l'archive, l'appareil client crée une clé de transmission AES 256 bits générée de manière aléatoire, chiffrée avec la clé publique de l'API du cloud Keeper. L'appareil client déchiffre la réponse du serveur avec la clé de transmission, puis déchiffre la charge utile de la réponse en texte chiffré avec la clé d'enregistrement, ce qui déchiffre le contenu de l'archive.

Partage administrateur

La fonction de Partage administrateur de Keeper es une autorisation de contrôle d'accès basé sur les rôles (RBAC) qui confère aux administrateurs des privilèges élevés sur les dossiers et les archives partagés d'une entreprise. Les administrateurs de partage disposent de tous les privilèges d'utilisateur et d'archive pour tous les dossiers partagés auxquels ils ont accès.

Modèle de chiffrement Secrets Manager

Keeper Secrets Manager est une plateforme zero knowledge destinée aux professionnels de l'informatique et du DevOps. Ce qui permet aux équipes de gérer les secrets tout au long du cycle de développement et de déploiement des logiciels.

Secrets Manager recourt au modèle de chiffrement suivant

• Le chiffrement et le déchiffrement s'effectuent localement sur l'appareil (et non sur le serveur).
• Le texte en clair n'est jamais stocké sur l'appareil.
• Le serveur ne reçoit jamais de texte en clair.
• Personne, y compris le personnel de Keeper, les tiers ou les intermédiaires, ne peut déchiffrer les secrets.
• Le dispositif client gère les clés pour chiffrer et déchiffrer les secrets, sous le contrôle de l'utilisateur.
• Chaque secret est chiffré par une clé de chiffrement AES 256 bits générée côté client en mode GCM.
• Si le secret se trouve dans un dossier partagé, la clé de l'archive est protégée par une clé de dossier partagé.
• Une clé d'application AES 256 bits est générée côté client dans le but de déchiffrer les clés du dossier partagé et de l'archive. La clé d'archive déchiffre ensuite le secret individuel.
• Les serveurs Keeper sont protégés par une clé AES de 256 bits avec TLS pour éviter les attaques de l'homme du milieu (MITM).
• La clé de transmission est générée sur le dispositif client et transférée au serveur en utilisant le chiffrement ECIES via la clé publique CE du serveur.
• La cryptographie sur courbe elliptique permet de partager des secrets entre utilisateurs pour assurer la sécurité de la distribution des clés.
• Le chiffrement multicouche permet de contrôler l'accès au niveau de l'utilisateur, du groupe et de l'administrateur.
• Les secrets gérés dans le coffre-fort sont segmentés et isolés sur des dispositifs définis de gestion des secrets auxquels l'accès à l'archive et au dossier est autorisé.

Modèle de Keeper Secrets Manager pour la rotation des mots de passe

• Un client unique Keeper Secrets Manager (KSM), appelé passerelle, est installé dans l'environnement du client.
• La passerelle établit une connexion sortante sécurisée avec le routeur Keeper.
• Le routeur est un service cloud hébergé dans l'environnement AWS de Keeper, qui facilite la communication entre l'API backend de Keeper, les applications de l'utilisateur final (coffre-fort Internet, application de bureau, etc.) et les passerelles installées dans l'environnement de l'utilisateur.
• Des websockets sont établies entre le dispositif de l'utilisateur final (par exemple, le coffre-fort Internet) et le routeur Keeper avec le jeton de session actuel.
• Le routeur Keeper vérifie le jeton de session et authentifie la session. Toutes les données chiffrées envoyées au routeur Keeper sont protégées par une clé AES 256 bits, en plus de TLS, pour éviter les attaques de type MITM.
• La clé AES 256 bits est créée sur l'appareil de l'utilisateur final et transférée au serveur à l'aide du chiffrement ECIES via la clé publique CE du routeur.
• Les demandes de rotation et de découverte sont émises entre l'appareil de l'utilisateur final (ou le planificateur Keeper) et la passerelle par le canal de communication websocket établi.
• Pendant la rotation, lorsque la passerelle a besoin d'un secret du coffre-fort Keeper, elle authentifie le secret et le déchiffre à l'aide des API de Keeper Secrets Manager afin de préserver le principe de zero knowledge.
• Comme pour tout autre appareil doté de Secrets Manager, il est possible de restreindre l'accès en fonction de l'adresse IP, en plus du processus de chiffrement et de signature.

Connexion zero-trust et tunnels de sécurité

Zero-Trust KeeperPAM fournit la capacité d'établir des sessions privilégiées dans le cloud et sur site, de créer des tunnels, d'établir un accès direct à l'infrastructure et un accès sécurisé aux bases de données à distance sans VPN.

Une connexion est une session visuelle à distance utilisant le navigateur Web. L'interaction entre l'utilisateur et l'appareil cible se fait avec une fenêtre de navigateur Web ou dans l'application Keeper Desktop.

Un tunnel est une connexion TCP / IP qui est établie entre le vault client local via la passerelle Keeper vers le point de terminaison cible. L'utilisateur peut utiliser toute application native pour communiquer avec le point de terminaison cible, comme le terminal de ligne de commande, l'application GUI ou l'application de gestion de base de données telle que MySQL Workbench.

Lorsque l'utilisateur établit une connexion ou un tunnel :

1. L'application Vault Client communique à l'infrastructure Keeper Router pour initier une communication WebRTC protégée par une clé de symétrie ECDH qui est stockée dans l'entrée Keeper pertinente.
2. La passerelle Keeper communique avec le routeur Keeper via des WebSockets uniquement sortants. Ceci est décrit en détail sur ce lien.
3. La passerelle Keeper Gateway utilise les API Keeper Secrets Manager pour récupérer les secrets nécessaires du coffre-fort, y compris la clé de symétrie ECDH.
4. Pour les communications, le client Vault (à l'aide du protocole Apache Guacamole) passera les données via la liaison WebRTC vers la passerelle Keeper qui utilise ensuite Guacd pour se relier à la destination trouvée dans l'entrée Keeper.
5. Pour les fonctionnalités de tunneling (transfert de port), un port local est ouvert sur l'appareil local exécutant le logiciel Keeper Desktop. Les données envoyées au port local sont transmises via la liaison WebRTC à la passerelle Keeper et ensuite transmises au point de terminaison cible défini dans l'entrée Keeper.
6. Les enregistrements de session des liaisons sont protégés par une clé de chiffrement AES-256 (« clé d'enregistrement ») qui est générée sur la passerelle Keeper à chaque session. La clé d'enregistrement est également enveloppée par une clé de ressource AES-256 dérivée de HKDF.

Sécurité d'isolation du navigateur à distance

La technologie d'isolation du navigateur à distance Keeper protège l'accès aux applications Web internes ou à tout autre ensemble basé sur le Web via le Docker Keeper Connection Manager ou via la passerelle Keeper.

Utilisation de la méthode de conteneur de Connection Manager Docker :

1. L'utilisateur s'authentifie dans le service Web Keeper Connection Manager, hébergé par le client dans un récipient Docker.
2. L'utilisateur lance une session d'isolation du navigateur à distance vers l'application Web cible. Entre le navigateur de l'utilisateur et le service Web hébergé Keeper Connection Manager, la communication sur HTTPS est protégée par Let's Encrypt ou le certificat spécifié du client.
3. Sur le récipient Keeper Connection Manager Docker, une version intégrée de Chromium est exécutée dans un sandbox, le site Web cible est rendu à l'aide d'un pilote d'affichage local qui diffuse le texte visible de la page en temps réel vers le navigateur Web de l'utilisateur à l'aide du protocole Apache Guacamole.

Utilisation de la passerelle Keeper avec le coffre-fort Web ou l'application de bureau Keeper :

1. L'application Vault Client communique à l'infrastructure Keeper Router pour initier une communication WebRTC protégée par une clé de symétrie ECDH qui est stockée dans l'entrée Keeper pertinente.
2. La passerelle Keeper communique avec le routeur Keeper via des WebSockets uniquement sortants. Ceci est décrit en détail sur ce lien.
3. La passerelle Keeper Gateway utilise les API Keeper Secrets Manager pour récupérer les secrets nécessaires du coffre-fort, y compris la clé de symétrie ECDH.
4. Pour les communications, le client Vault (à l'aide du protocole Apache Guacamole) passera les données via la liaison WebRTC vers la passerelle Keeper qui utilise ensuite HTTP ou HTTPS pour se relier à la destination trouvée dans l'entrée Keeper.
5. Les enregistrements de session des liaisons sont protégés par une clé de chiffrement AES-256 (« clé d'enregistrement ») qui est générée sur la passerelle Keeper à chaque session. La clé d'enregistrement est également enveloppée par une clé de ressource AES-256 dérivée de HKDF.

Protection d'isolation du navigateur

Plusieurs mesures de sécurité sont activées à l'aide du protocole d'isolation du navigateur à distance :

1. Le point de terminaison de l'application Web étant protégé est enveloppé par une couche de chiffrement TLS de la passerelle Keeper Connection Manager vers l'appareil local de l'utilisateur, indépendamment du fait que TLS soit utilisé entre la passerelle et le point de terminaison, protégeant ainsi de l'attaque MITM ou de l'inspection des paquets sur le réseau local de l'utilisateur.
2. La session de navigation à distance projette visuellement l'interaction sur l'appareil local de l'utilisateur à l'aide d'un rendu canvas et graphique. Aucun code JavaScript ou HTML du site Web cible n'est exécuté sur la machine locale de l'utilisateur.
3. Étant donné qu'aucun code de site Web de la cible n'est exécuté localement et que le navigateur local ne peut pas accéder directement au code d'application sous-jacent, l'application Web isolée est protégée des vecteurs d'attaque tels que les vulnérabilités de script intersite reflétées, la falsification des demandes intersite et l'abus d'API.
4. L'utilisateur final peut être limité à effectuer l'exfiltration des données du point de terminaison cible grâce au filtrage des demandes d'URL et de ressources. Les téléchargements de fichiers et les téléchargements sont limités, même si l'application Web cible permettrait autrement l'action.
5. La session de navigation et les frappes peuvent être enregistrées à des fins d'audit et de réglementation, offrant la possibilité d'effectuer une analyse médico-légale des sessions basées sur le Web.
6. Les identifiants qui sont automatiquement remplis de la passerelle vers l'application Web cible ne sont jamais transmis à l'appareil de l'utilisateur et ne sont pas accessibles par l'utilisateur sur son appareil local, protégeant ainsi des fuites de secrets.
7. Grâce aux politiques de pare-feu, l'utilisateur peut être tenu d'accéder à l'application Web cible uniquement via la session d'isolation du navigateur à distance, réduisant la menace d'un navigateur compromis ou d'un logiciel malveillant d'appareil local.
8. L'application Web cible devient protégée par l'authentification unique ou l'authentification MFA, même si l'application ne la prend pas en charge de manière native. Keeper protège l'accès au coffre-fort et à toutes les sessions d'isolation du navigateur à distance grâce aux méthodes d'authentification avancées décrites dans ce document.

BreachWatch^®

Keeper dispose d'une architecture gérée et autonome sur AWS appelée BreachWatch. BreachWatch est physiquement séparé de l'API de Keeper et des archives des utilisateurs.

Un module de sécurité matériel physique (HSM) intégré aux serveurs de BreachWatch sert à traiter, hacher et stocker des milliards de mots de passe uniques provenant d'atteintes à la protection des données sur le dark web. Tous les mots de passe sont traités sur les serveurs de Keeper à l'aide de la méthode de hachage HMAC_SHA512 et hachés avec le HSM à l'aide d'une clé non exportable.

Lorsque BreachWatch est activé sur l'appareil client, un hachage HMAC_SHA512 est généré à partir de chaque archive et envoyé au serveur. Sur le serveur, un second hachage est créé à l'aide de HMAC_SHA512 via le HSM à l'aide d'une clé non exportable. Les « hachages de hachages » sont comparés pour déterminer si un identifiant a été compromis.

L'architecture de BreachWatch a été conçue pour empêcher toute corrélation entre un mot de passe compromis et un mot de passe présent dans le coffre-fort de l'utilisateur, quelle que soit l'ampleur de la violation de données. La détection des violations de mot de passe fait appel à un HSM physique pour s'assurer que le hachage peut uniquement être effectué en ligne, afin d'empêcher toute attaque par force brute sur les données.

• Les mots de passe sont hachés deux fois avec HMAC_512 : une fois sur l'appareil client à l'aide d'un « poivre », et une fois dans le CloudHSM AWS à l'aide d'un module de sécurité matériel avec une clé non exportable.
• Nous utilisons la méthode HMAC_512 parce qu'elle repose sur une fonction de hachage puissante et une clé secrète, qui n'est pas exportable.
• La fonction d'authentification des messages (MAC) avec le résultat d'une fonction de hachage cryptographique élargit l'utilisation des fonctions de hachage. Ses résultats dépendent non seulement du message, mais aussi d'une deuxième entrée qui peut être une clé secrète.

BreachWatch est conçu à 100 % par Keeper avec les flux de données de SpyCloud, mais Keeper n'envoie jamais aucune donnée à des tiers.

Vérification des domaines

Les clients BreachWatch téléchargent une liste de domaines violés et effectuent une vérification locale.

Vérification des noms d'utilisateur et mots de passe

Les appareils clients se connectent à BreachWatch et téléchargent une liste de noms d'utilisateur (ou de mots de passe) hachés ainsi qu'un identifiant aléatoire choisi par le client (identifiants distincts pour les services de vérification des noms d'utilisateur et des mots de passe). Lors du téléchargement, ces hachages de mots de passe sont traités par HMAC à l'aide d'un module de sécurité matériel (HSM) et d'une clé secrète stockée dans le HSM et déclarée non exportable (ce qui signifie que le HSM traitera uniquement le HMAC au niveau local et que la clé ne pourra pas être extraite). Ces données sorties du HMAC (noms d'utilisateur ou mots de passe) sont comparées aux ensembles de données de la violation qui ont été traités avec le même HMAC et la même clé. Toute correspondance est signalée au dispositif client. Les valeurs qui ne correspondent pas sont stockées avec l'identifiant anonyme du client.

Lorsque de nouveaux noms d'utilisateur et mots de passe piratés sont ajoutés au système, ils sont traités par HMAC sur le HSM, ajoutés à l'ensemble de données de BreachWatch et comparés aux valeurs client stockées. Toute correspondance déclenche une alerte pour l'identifiant du client concerné.

Les clients se connectent périodiquement à BreachWatch et présentent leur identifiant BreachWatch. Tout message en file d'attente est téléchargé et les clients chargent tout nom d'utilisateur ou mot de passe nouveau ou modifié et ceux-ci sont traités selon le même processus.

La sécurité des services BreachWatch est basée sur le modèle de sécurité TOFU (trust-on-first-use). C'est-à-dire que le client doit supposer que le serveur BreachWatch n'est pas malveillant (soit qu'il n'est pas compromis par une attaque à l'heure actuelle) lorsqu'il charge ses valeurs hachées. Une fois ces valeurs traitées avec un HSM, elles sont protégées contre des tentatives de piratage hors ligne. Autrement dit, si une personne malveillante vole le jeu de données de valeurs client stockées, elle ne peut pas pirater ces données hors ligne sans la clé HMAC stockée sur le HSM.

En cas de détection d'une violation d'un mot de passe, l'appareil client envoie une combinaison nom d'utilisateur + mot de passe aux serveurs BreachWatch, qui effectuent alors la même comparaison de hachage HMAC pour déterminer si une combinaison nom d'utilisateur + mot de passe a été piratée. Le cas échéant, le système renvoie les domaines liés à ces violations afin que l'appareil client puisse déterminer si la combinaison nom d'utilisateur + mot de passe + domaine correspond à cette combinaison. Si les trois paramètres correspondent sur l'appareil client, l'utilisateur est alerté de la gravité de la violation.

BreachWatch pour les clients professionnels et professionnels

Lorsque les clients Business et Enterprise ont activé BreachWatch, les coffres-forts des utilisateurs finaux sont analysés automatiquement, à chaque fois qu'un utilisateur se connecte à Keeper. Les données récapitulatives de BreachWatch analysées sur l'appareil de l'utilisateur sont chiffrées avec la clé publique de l'entreprise et déchiffrées par l'administrateur de l'entreprise lorsqu'il se connecte à la console d'administration de Keeper. Ces données chiffrées comprennent l'adresse e-mail, le nombre d'archives à haut risque, le nombre d'archives résolues et le nombre d'archives ignorées. L'administrateur Keeper peut consulter les statistiques récapitulatives de l'utilisateur dans l'interface utilisateur de la console d'administration.

Journalisation des événements et rapports

En étant intégrés avec le module Rapports avancés et alertes, les appareils des utilisateurs finaux de Keeper peuvent aussi être configurés pour transmettre des événements détaillés en temps réel vers des solutions SIEM tierces et vers l'interface de rapport de la console d'administration Keeper. Les données d'événement comprennent l'adresse e-mail, l'UID d'archive, l'adresse IP et les informations relatives à l'appareil. Les événements ne comprennent aucune donnée d'archive déchiffrée, étant donné que Keeper est une plateforme zero knowledge et ne peut pas déchiffrer les données utilisateur.

Par défaut, les données d'événement BreachWatch détaillées ne sont pas envoyées au module Rapports avancés et alertes ni à aucun système de journalisation externe connecté. Pour activer l'envoi de rapport d'événement de données BreachWatch au module Rapports avancés et alertes, vous devez activer l'événement de politique d'exécution des rôles pour le rôle concerné > Politiques d'exécution > Options du coffre-fort. Une fois activés, les appareils clients des utilisateurs finaux envoient les données de cet événement. Étant donné que l'intégration avec des solutions SIEM tierces est transmise du serveur backend Keeper aux SIEM cibles, les données de cet événement sont lisibles par le SIEM cible et peuvent être utilisées pour identifier les archives et les utilisateurs de l'entreprise associés à des mots de passe à haut risque. Si l'administrateur Keeper ne souhaite pas transmettre les données d'événement d'archive au module Rapports avancés et alertes de Keeper, ce paramètre peut être désactivé.

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

Mode hors-ligne

Le mode hors ligne permet aux utilisateurs d'accéder à leur coffre-fort quand ils ne sont pas en mesure de se connecter en ligne à Keeper ou à leur fournisseur d'identité SSO. Cette fonctionnalité est disponible sur l'application mobile, l'application de bureau et le coffre-fort Internet de Keeper, sur tous les navigateurs.

Cette fonctionnalité permet de copier le coffre-fort sur l'appareil local de l'utilisateur. Les données du coffre-fort stockées hors ligne sont chiffrées en AES-GCM avec une « clé client » de 256 bits générée de manière aléatoire et protégée par PBKDF2-HMAC-SHA512 avec jusqu'à 1 000 000 d'itérations et un salt aléatoire. Le salt et les itérations sont stockés localement. Lorsque l'utilisateur saisit son mot de passe principal ou utilise une technique biométrique, le système dérive une clé à l'aide du salt et des itérations et tente de déchiffrer la clé client. La clé client sert alors à déchiffrer l'archive stockée. Si la protection par autodestruction est activée sur le coffre-fort de l'utilisateur, les données du coffre-fort stockées localement seront automatiquement effacées après 5 tentatives infructueuses de connexion. Les clients professionnels peuvent restreindre l'accès hors ligne en fonction des politiques d'exécution des rôles mises en place par l'administrateur Keeper.

Accès en cas d'urgence (patrimoine numérique)

Les utilisateurs des formules individuelles et familiales de Keeper peuvent ajouter jusqu'à 5 personnes à contacter en cas d'urgence pour accéder au coffre-fort en cas de décès de l'utilisateur ou d'une autre situation d'urgence. L'utilisateur spécifie un délai d'attente et, une fois ce délai écoulé, la personne à contacter en cas d'urgence aura accès au coffre-fort de l'utilisateur. Le partage du coffre-fort avec un contact d'urgence repose sur le principe de zero knowledge, et le mot de passe principal de l'utilisateur n'est jamais partagé. Le chiffrement RSA 2048 bits se fait avec une clé AES 256 bits. La personne à contacter en cas d'urgence doit avoir un compte Keeper pour recevoir l'information.

Architecture réseau

Keeper utilise AWS en Amérique du Nord (Commercial ou GovCloud), en Europe, en Australie, au Japon et au Canada pour assurer la confidentialité des données localisées et l'isolement géographique afin d'héberger et d'exploiter la solution et l'architecture de Keeper. En utilisant AWS, Keeper peut faire évoluer ses ressources de façon fluide et à la demande et fournir un environnement de stockage dans le cloud le plus rapide et le plus sécurisé possible à ses clients. Keeper gère des environnements multi-zones et multi-régions afin de maximiser la disponibilité et de répondre le plus rapidement possible aux clients. Les entreprises clientes peuvent héberger leur titulaire Keeper dans n'importe quelle région primaire de leur choix. Les données des clients et l'accès à la plateforme sont isolés dans cette région spécifique.

Authentification dans le cloud

Keeper a développé un modèle sophistiqué d'authentification dans le cloud et de communication en réseau qui respecte les plus hautes exigences en matière de confidentialité, de sécurité, de confiance et de transparence. Voici quelques caractéristiques clés de ce modèle d'authentification :

• Le mot de passe principal ne passe jamais par la couche réseau. Contrairement à la plupart des services SaaS, les identifiants de connexion des utilisateurs de Keeper ne quittent jamais leur appareil. Lorsque les utilisateurs se connectent à Keeper avec un mot de passe principal, l'algorithme PBKDF2 intervient sur l'appareil local pour dériver une clé AES de 256 bits afin de déchiffrer l'information. Une clé PBKDF2 supplémentaire est générée au niveau de l'appareil, puis hachée avec HMAC_SHA256 pour créer un jeton d'authentification. Le Cloud Security Vault de Keeper ne connaît pas la clé de déchiffrement de l'utilisateur.
• Le trafic entre l'appareil client et le cloud Keeper ne peut pas être intercepté. ou déchiffré. Keeper utilise le Key Pinning et des couches supplémentaires de chiffrement de réseau (clés de transmission) entre l'appareil et les serveurs Keeper, pour éviter les attaques MITM.
• Les nouveaux appareils ne peuvent pas se connecter à un compte sans une étape de vérification de l'apparei.l Il est impossible de se connecter à un compte sans passer par cette étape. Keeper prend en charge plusieurs types de méthodes de vérification des appareils qui dépendent de la méthode d'authentification utilisée.
• L'authentification à deux facteurs s'effectue après la vérification de l'appareil et avant la saisie du mot de passe principal. Si un utilisateur a configuré ou appliqué l'authentification à deux facteurs, il doit effectuer cette étape avant de saisir son mot de passe principal.
• Il est impossible de saisir le mot passe principal avant d'avoir terminé l'étape de vérification de l'appareil et d'authentification à deux facteurs. L'utilisateur ne peut pas passer à l'étape de saisie du mot de passe principal sans procéder au préalable à une vérification de son appareil et à une authentification à deux facteurs. Ce flux d'authentification poussé protège contre plusieurs vecteurs d'attaque, notamment l'attaque par force brute, la pulvérisation de mot de passe, l'énumération et l'homme du milieu (MITM).

Chiffrement en transit

Le Cloud Security Vault de Keeper est protégé par des API qui sont validées par l'autorisation de l'appareil client. En se connectant, le client récupère un jeton de session qu'il envoie lors de chaque appel à l'API. Le jeton de session est conservé sur le serveur. La connexion s'effectue soit par un mot de passe principal, soit par une reprise de session, soit par une authentification unique SAML 2.0.

Lors de l'utilisation d'un mot de passe principal, le dispositif client obtient une « clé d'authentification » de 256 bits en utilisant la méthode PBKDF2-HMAC-SHA256 avec 1 000 000 d'itérations et un salt aléatoire de 128 bits. Un « hachage d'authentification » est généré en hachant la clé d'authentification en SHA-256. Pour se connecter, le hachage d'authentification est comparé à un hachage d'authentification stocké dans le Cloud Security Vault. Après la connexion, le serveur génère un jeton de session et l'envoie au client, qui l'utilisera pour les demandes d'API ultérieures. La session doit être active pour que la communication entre le client et le serveur puisse se poursuivre.

Keeper prend en charge le protocole TLS 256 bits et 128 bits pour chiffrer l'intégralité du transport des données entre l'application client et le stockage dans le cloud de Keeper.

Keeper déploie des certificats TLS signés par DigiCert à l'aide de l'algorithme SHA2, l'algorithme de signature le plus sûr du marché. L'algorithme SHA2 est nettement plus sûr que l'algorithme SHA1, plus courant, mais qui laisse une possibilité d'exploitation en raison d'une faiblesse mathématique décelée dans l'algorithme. SHA2 vous protège contre l'émission de certificats contrefaits dont pourrait se servir un pirate pour imiter un site Internet.

Keeper prend également en charge la transparence des certificats (CT, Certificate Transparency), une nouvelle initiative de Google permettant de créer une archive publique de certificats signés par les émetteurs des certificats. CT est déjà pris en charge par les dernières versions des navigateurs Chrome, Safari et Brave. Pour en savoir plus sur la transparence des certificats, consultez le site https://certificate.transparency.dev/.. Keeper prend en charge les suites de chiffrement TLS ci-dessous :

• 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

Les appareils clients Keeper sur iOS et Android appliquent également le Key Pinning, un mécanisme de sécurité qui empêche l'usurpation d'identité par des pirates qui utilisent des certificats numériques frauduleux.

Protection contre les attaques de type Cross-Site Scripting (XSS)

Le coffre-fort Internet Keeper applique une stratégie de sécurité de contenu stricte qui restreint l'origine des demandes sortantes et empêche l'exécution des scripts, à l'exception de ceux provenant explicitement de Keeper, y compris des scripts inline et attributs HTML de gestion des événements afin de réduire ou éliminer la plupart des vecteurs d'attaques de type cross-site scripting.

L'accès aux noms de domaine de Keeper Security est limité aux connexions HTTPS avec TLS 1.3 et est renforcé par HTTP Strict Transport Security. Un grand nombre d'attaques de type analyseur de paquets, modification de données et homme du milieu sont ainsi évitées.

Dans son extension de navigateur, Keeper ne demande jamais aux utilisateurs les identifiants de connexion au coffre-fort dans le cadre de la page. La connexion à l'extension s'effectue dans la zone de la barre d'outils de l'extension de navigateur. La connexion au coffre-fort sur le navigateur web s'effectue toujours sur les domaines keepersecurity.com, keepersecurity.eu, keepersecurity.com.au, keepersecurity.jp, keepersecurity.ca ou govcloud.keepersecurity.us, ou dans la barre d'outils de l'extension de navigateur Keeper qui existe en dehors de la page de contenu.

L'extension de navigateur Keeper place une iFrame dans les formulaires de connexion d'une page web pour s'assurer qu'aucun site web malveillant n'a accès au contenu injecté. Le contenu des archives injectées dans les iFrames est également limité aux archives stockées dans le coffre-fort de l'utilisateur qui correspondent au domaine du site web cible. Keeper ne proposera pas le remplissage automatique des identifiants ou des mots de passe à moins que le domaine du site web ne corresponde au champ de domaine du site web de l'archive du coffre-fort de Keeper. L'extension affichera les archives uniquement si celles-ci correspondent au domaine racine de l'adresse du site web.

Les extensions de navigateurs tierces peuvent disposer d'autorisations élevées dans les navigateurs web et accéder aux informations contenues dans la page. Par conséquent, nous recommandons aux administrateurs Keeper d'empêcher les utilisateurs d'installer des extensions de navigateur tierces à partir de la boutique d'applications du navigateur.

Données biométriques

Keeper prend nativement en charge Windows Hello, Touch ID, Face ID et la biométrie Android. Les clients qui se connectent normalement à leur coffre-fort Keeper à l'aide d'un mot de passe principal ou d'une authentification unique d'entreprise (SAML 2.0) peuvent également se connecter à leurs appareils avec la biométrie. L'administrateur Keeper doit activer la biométrie dans la politique des rôles. Les utilisateurs disposant d'un mot de passe principal ou d'une authentification unique peuvent également se connecter hors ligne à l'aide de la biométrie lorsque cette fonctionnalité est activée.

Lorsque la connexion biométrique est activée sur un appareil, une clé est générée localement de manière aléatoire et stockée dans l'enclave sécurisée (par exemple, le trousseau ou le Keystore) de l'appareil. La clé de données de l'utilisateur est chiffrée avec la clé biométrique. Une fois l'authentification biométrique réussie, la clé est récupérée et l'utilisateur peut déchiffrer son coffre-fort.

Trousseau iOS, Touch ID et Face ID

Sur les appareils iOS, Touch ID et Face ID permettent aux utilisateurs d'accéder à leur coffre-fort Keeper à l'aide de la biométrie. Cette fonctionnalité pratique consiste à stocker une « clé biométrique » de 256 bits générée de manière aléatoire dans le trousseau iOS. L'élément du trousseau iOS créé pour cette fonctionnalité n'est pas conçu pour se synchroniser avec le trousseau iCloud et ne quittera donc pas votre appareil mobile iOS.

Il est fortement recommandé d'utiliser un mot de passe principal complexe et d'activer l'authentification multifacteur afin de bénéficier d'une sécurité maximale sur votre coffre-fort chiffré Keeper. Touch ID et Face ID simplifient l'utilisation d'un mot de passe principal complexe sur votre appareil mobile iOS. Il est également recommandé de configurer un code d'accès plus long que le minimum de 4 chiffres pour sécuriser le trousseau iOS.

Le trousseau iOS est utilisé par iOS et les apps pour stocker des identifiants en toute sécurité. Les apps iOS utilisent le trousseau iOS pour stocker différentes données sensibles, notamment des mots de passe de sites web, des clés, des numéros de cartes bancaires et des données Apple Pay. Keeper n'utilise pas le trousseau iOS pour stocker les archives Keeper : toutes les archives Keeper sont protégées par un chiffrement AES 256 bits et sont stockées en toute sécurité dans le coffre-fort Keeper. Le trousseau iOS est également chiffré à l'aide du chiffrement AES 256 bits avec le code d'accès de l'appareil. Même si l'appareil est perdu ou volé, ou si une personne malintentionnée obtient un accès physique à l'appareil mobile, elle ne sera pas en mesure d'accéder aux données Keeper stockées. Le trousseau iOS ne peut pas être déchiffré sans le code d'accès et le coffre-fort Keeper ne peut pas être déchiffré sans le mot de passe principal Keeper de l'utilisateur.

Apple Watch^®

La fonctionnalité Favoris Apple Watch vous permet de voir les entrées sélectionnées sur une Apple Watch jumelée. Les entrées Keeper doivent être activées explicitement pour autoriser le visionnage sur l'Apple Watch. Une Apple Watch jumelée communique avec l'extension pour montres de Keeper qui fonctionne de façon transparente dans un espace de type "sandbox", indépendant de l'app iOS Keeper. L'extension pour montres de Keeper utilise également le Trousseau iOS pour stocker de façon sécurisée les clés, et y accéder, afin de communiquer en toute fluidité et sécurité avec l'app iOS Keeper.

Keeper DNA^®

Keeper DNA propose une méthode d'authentification multifacteur basée sur l'utilisation d'une montre connectée. Keeper DNA utilise des jetons sécurisés stockés dans le coffre-fort Keeper pour générer des codes temporels pour l'authentification multifacteur. Ces demandes d'authentification temporelle peuvent être approuvées et envoyées automatiquement depuis l'Apple Watch (ou l'appareil Android Wear) en touchant l'écran de la montre ou saisies manuellement par l'utilisateur.

Départs de collaborateurs (transfert de coffre-fort)

Lorsqu'une politique de transfert de compte est activée pour un nœud, la politique du nœud pour une paire de clés publique/privée se crée dans la console d'administration sur le dispositif de l'utilisateur. La clé de données de l'utilisateur final (pour lequel le rôle est soumis à l'exécution) est chiffrée avec la clé publique de la politique lorsque l'utilisateur se connecte au coffre-fort. La clé privée est chiffrée avec la clé publique de l'administrateur et ce dernier peut alors déchiffrer la clé d'exécution des rôles à l'aide d'un transfert de coffre-fort.

Lors d'un transfert de coffre-fort, l'administrateur Keeper doit d'abord verrouiller le compte de l'utilisateur. Le transfert du coffre-fort peut alors avoir lieu immédiatement, suivi de la suppression du compte de l'utilisateur. Ainsi, l'opération n'est pas effectuée en secret. Lors du transfert, la clé de données de l'utilisateur est récupérée en déballant d'abord la clé privée de l'exécution des rôles, puis la clé de données de l'utilisateur. La clé de données permet de déballer les clés d'archive, les clés d'équipe et les clés de dossier.

Tout le chiffrement est effectué côté client, dans la console d'administration. À aucun moment, Keeper n'a la possibilité de déchiffrer les informations partagées ou transférées. La clé de données d'un utilisateur n'est elle non plus jamais partagée. Tout utilisateur retiré d'une équipe, d'un dossier partagé ou d'un partage direct ne recevra pas de nouvelles données de l'équipe, du dossier partagé ou de l'archive. Bien que les clés d'archive, de dossier et d'équipe soient déchiffrées localement pour l'administrateur au cours de la transaction, les clés ne peuvent pas servir à accéder aux données sous-jacentes de l'archive ou du dossier.

Lors du transfert du coffre-fort, l'administrateur reçoit uniquement la clé de données chiffrée, les clés d'archives chiffrées et les clés de dossiers chiffrées. Il déchiffre ces clés, qui sont ensuite chiffrées à nouveau avec la clé publique du coffre-fort de destination. L'administrateur n'a jamais accès aux données de l'archive. Keeper ne chiffre pas directement les données stockées par le client avec la clé de données, cette opération s'effectue sur l'appareil.

Certifications et conformité

La sécurité est la priorité absolue de Keeper. Keeper est la solution de sécurité des mots de passe et la plateforme de gestion des accès privilégiés la plus sécurisée, certifiée, testée et contrôlée au monde. Keeper est titulaire des certifications SOC 2 et ISO les plus anciennes du secteur, notamment les normes ISO 27001, 27017 et 27018. Keeper respecte le RGPD, le CCPA, l'HIPAA, est homologué FedRAMP et StateRAMP, certifié PCI DSS et certifié par TrustArc pour la protection de la confidentialité.

• Les équipes de développement de logiciels de Keeper sont composées de collaborateurs à temps plein résidant aux États-Unis.
• Keeper ne stocke aucun mot de passe, identifiant ou secret tel qu'une clé d'accès dans son code source. Nous analysons régulièrement le code source à la recherche de telles données.
• Conservé à titre privé dans GitHub Enterprise, le code source de Keeper ne fournit aucune information nécessaire pour accéder au coffre-fort d'un utilisateur, car le chiffrement des données s'effectue au niveau de l'appareil. Une grande partie de ce code est publiée dans notre référentiel public GitHub dans le cadre des produits Commander et Secrets Manager de Keeper.
• Keeper n'intègre aucun code de fournisseur tiers d'authentification multifacteur dans ses applications. Les prestataires qui travaillent avec Keeper n'ont fait l'objet d'aucune violation impliquant Keeper.
• Keeper ne confie la gestion ou l'accès à ses centres de données AWS à aucun tiers. La gestion est entièrement assurée par des collaborateurs à temps plein de Keeper Security qui sont citoyens américains et qui se résident aux États-Unis.

Validé FIPS 140-3

Keeper utilise des modules de chiffrement validés FIPS 140-3 afin de respecter les exigences strictes de sécurité du gouvernement et du secteur public. Le chiffrement de Keeper a été certifié par le programme NIST CMVP et déclaré conforme à la norme FIPS 140 par des laboratoires tiers agréés.

Keeper uses FIPS 140-3 validated encryption that has been issued certificate #4743 under the NIST CMVP.

Conforme à la réglementation ITAR

Keeper Security Government Cloud (KSGC) est conforme aux réglementations américaines sur le trafic international d'armes (International Traffic in Arms Regulations ou ITAR). Les entreprises soumises aux réglementations d'exportation ITAR doivent contrôler les exportations non intentionnelles en limitant l'accès aux données protégées à des personnes américaines et en hébergeant physiquement les données protégées aux États-Unis exclusivement.

L'environnement Modéré FedRAMP de KSGC respecte les réglementations ITAR en appliquant les mesures suivantes :

• Le stockage de données entièrement conforme est hébergé sur AWS GovCloud et limité aux États-Unis.
• KSGC assure le chiffrement sécurisé des données en transit et au repos.
• Associée à des autorisations granulaires, la sécurité zero knowledge et zero trust assure aux entreprises que seul le personnel habilité peut accéder aux données sensibles.
• Fonctionnalités de rapport de conformité fournissant une piste d'audit électronique et traçable de toutes les opérations effectuées et données saisies
• L'équipe de réussite client isolée est composée de personnes américaines formées au traitement sécurisé de données soumises aux réglementations ITAR et dont l'exportation est contrôlée.

L'environnement FedRAMP de Keeper a été audité par un organisme d'évaluation tiers indépendant (3PAO) afin de valider les contrôles mis en place pour prendre en charge les programmes de conformité des exportations et continue d'être audité chaque année pour préserver cette conformité.

En savoir plus sur l'ITAR.

Homologué FedRAMP

KSGC est la plateforme de gestion des mots de passe et de cybersécurité de Keeper Security destinée aux entreprises du secteur public. KSGC a reçu l'homologation FedRAMP pour son niveau d'impact modéré et est hébergée sur AWS GovCloud (US). Retrouvez KSGC sur la place de marché FedRAMP.

Le programme FedRAMP (Federal Risk and Authorization Management Program, programme fédéral de gestion des risques et des autorisations) est un programme du gouvernement fédéral des États-Unis dont le but est de fournir une approche normalisée de l'évaluation de la sécurité, de l'autorisation et de la surveillance continue des produits et services cloud. FedRAMP permet aux agences gouvernementales d'utiliser des technologies cloud modernes plus rapidement en mettant l'accent sur la sécurité et la protection des données fédérales. En savoir plus sur FedRAMP.

Agréé par StateRAMP

StateRAMP a été développé une dizaine d'années après FedRAMP, dans le but d'encourager l'adoption de solutions sécurisées basées sur le cloud au niveau des États et des collectivités locales. Il faut généralement deux ans pour obtenir l'autorisation StateRAMP, mais ce processus a été simplifié dans le cadre d'un programme de réciprocité grâce à l'autorisation FedRAMP de Keeper.

Certification SOC 2

Les données du coffre-fort des clients sont protégées par des contrôles internes rigoureux et étroitement surveillés. Keeper répond à la norme SOC 2 de type 2 depuis plus de dix ans, encadrée par l'AICPA Service Organization Control. La conformité SOC 2 contribue à la sécurisation des coffres-forts des utilisateurs grâce à la mise en œuvre de contrôles normalisés tels que définis dans le cadre des conventions de l'AICPA Trust Service Principles.

Certifications ISO

Keeper est certifié ISO 27001, 27017 et 27018 certification qui englobe le système de gestion de l'information de Keeper Security, qui prend en charge la plateforme Keeper Enterprise. La certification ISO 27001 de Keeper inclut la gestion et l'opération du coffre-fort numérique et des services sur le cloud, les contrôles de sécurité cloud, les contrôles de confidentialité des données, le développement des applications et logiciels et la protection des biens numériques pour le coffre-fort numérique et des services sur le cloud.

Conformité au règlement 21 CFR Part 11 de la FDA

Keeper est conforme au règlement 21 CFR Part 11, qui s'applique aux scientifiques travaillant dans des environnements hautement réglementés, notamment aux chercheurs qui mènent des essais cliniques. Dans ce règlement, la FDA établit des critères selon lesquels les documents et les signatures électroniques sont considérés comme dignes de confiance, fiables et équivalents aux documents papier portant des signatures manuscrites. Plus précisément, les scientifiques doivent s'assurer que tout logiciel qu'ils utilisent est conforme au règlement 21 CFR Part 11 sur les points suivants :

Contrôles de sécurité pour l'identification des utilisateurs - Keeper est conforme aux exigences du règlement 21 CFR Part 11 concernant les fonctionnalités de sécurité qui limitent l'accès des utilisateurs et leurs privilèges. Le logiciel garantit l'utilisation par tous les utilisateurs de noms d'utilisateur et de mots de passe uniques, la capacité de détecter et d'empêcher les accès non autorisés au système et la capacité de verrouiller les comptes compromis.

Piste d'audit détaillée

Lors des inspections de la FDA, les régulateurs exigent que les chercheurs fournissent une piste d'audit détaillant toutes les opérations dans l'ordre chronologique. Les fonctionnalités de rapport de conformité de Keeper permettent aux chercheurs de produire facilement des pistes d'audit électroniques traçables.

Signatures électroniques

Lorsqu'un document nécessite une signature électronique juridiquement contraignante, le règlement 21 CFR Part 11 exige que celle-ci soit associée à un identifiant et un mot de passe uniques ou à une identification biométrique. Keeper répond à cette exigence en permettant aux chercheurs de s'assurer que tous les utilisateurs disposent de noms d'utilisateur et de mots de passe uniques, stockés en toute sécurité dans un coffre-fort numérique auquel seul l'utilisateur a accès.

Pour en savoir plus sur le règlement 21 CFR Part 11 cliquez ici.

Protection des données médicales des patients

Le logiciel Keeper est conforme aux normes internationales de protection des données médicales dont, sans restriction, la loi HIPAA (Health Insurance Portability and Accountability Act) et la loi DPA (Data Protection Act).

Respect de la législation HIPAA et Accords d'association (Business Associate Agreements)

Keeper est une plateforme de sécurité zero knowledge certifiée SOC2 et ISO 27001 conforme à la législation HIPAA. Keeper maintient une adhésion stricte et des contrôles couvrant la vie privée, la confidentialité, l'intégrité et la disponibilité. Avec cette architecture de sécurité, Keeper ne peut pas consulter, accéder ou déchiffrer les données, y compris les données ePHI, stockées dans le coffre-fort Keeper d'un utilisateur. Pour les raisons qui précèdent, Keeper n'est pas un associé commercial (Business Associate) tel que défini dans la législation HIPAA (Health Insurance Portability and Accountability Act) et ne fait pas l'objet d'un accord d'association (Business Associate Agreement).

Pour en savoir plus sur les avantages que la plateforme Keeper offre aux professionnels de santé et aux compagnies d'assurance maladie, consultez notre Déclaration de sécurité dans son intégralité et le Guide d'utilisateur d'Enterprise.

Certifié FSQS-NL

Keeper Security EMEA Limited est certifié par le Hellios Financial Services Qualification System-Netherlands (FSQS-NL) qui reconnaît les plus hauts standards de sécurité, de qualité et d'innovation aux Pays-Bas. Cette norme atteste de la conformité avec la Financial Conduct Authority et la Prudential Regulation Authority afin de garantir la fiabilité du logiciel Keeper Enterprise pour les grandes banques et les institutions financières.

Licence d'exportation du Département du Commerce des États-Unis conformément à la loi EAR

Keeper est certifié par le Bureau de l'industrie et de la sécurité du ministère américain du commerce sous le numéro de contrôle de classification des marchandises à l'exportation 5D992, conformément aux règlements de l'administration des exportations (EAR).
Pour en savoir plus sur l'EAR : https://www.bis.doc.gov

Surveillance à distance 24 h / 24, 7 j. / 7

Keeper est surveillé 24h/24, 7j/7, 365 jours par an par du personnel DevOps à temps plein et par un réseau de surveillance tiers mondial afin de garantir la disponibilité de notre site Web et de notre Cloud Security Vault dans le monde entier.

Si vous avez des questions concernant cette déclaration de sécurité, n'hésitez pas à nous contacter.

Phishing et e-mails frauduleux

Si vous recevez un e-mail apparemment expédié par Keeper Security et dont vous doutez de la légitimité, il peut s'agir d'un e-mail d'hameçonnage (phishing) caractérisé par une imitation de l'adresse e-mail de l'expéditeur. Ce type d'e-mail peut contenir des liens pointant vers un site qui ressemble à KeeperSecurity.com mais qui n'en est qu'une copie. Le site en question pourra vous demander votre mot de passe principal Keeper Security ou essayer d'installer un logiciel indésirable sur votre ordinateur afin de voler vos données personnelles ou d'accéder à votre ordinateur. D'autres e-mails contenant des liens sont susceptibles de vous rediriger vers d'autres sites potentiellement dangereux. Le message pourra aussi contenir des pièces jointes, contenant elles-mêmes souvent des logiciels indésirables appelés « malwares ». Si vous doutez d'un e-mail reçu, supprimez-le sans cliquer sur le moindre lien et sans ouvrir de pièce jointe

Pour signaler un e-mail censé provenir de Keeper que vous pensez être frauduleux ou pour toute autre question de sécurité, n'hésitez pas à nous contacter.

Infrastructure d'hébergement certifiée selon les normes les plus strictes du secteur

Le site web de Keeper et le stockage en nuage utilisent l'infrastructure sécurisée de cloud computing (informatique dans le nuage) d'Amazon Web Services (AWS). L'infrastructure en nuage d'AWS qui héberge l'architecture système de Keeper est certifiée pour répondre aux attestations, rapports et certifications de tierces parties suivantes :

Rapport de vulnérabilité et programme Bug Bounty

Keeper Security a pour objectif de développer la solution de gestion des mots de passe et des accès privilégiés la plus sécurisée du marché. Nous nous engageons à protéger la confidentialité et les données personnelles de nos clients. La mission de Keeper Security est de construire la plateforme de sécurité la plus sécurisée et la plus innovante au monde, et nous pensons que les rapports de bugs de la communauté mondiale des chercheurs en sécurité sont un élément précieux pour assurer la sécurité des produits et services de Keeper.

Keeper effectue des tests internes et externes approfondis, notamment des tests d'intrusion réalisés par NCC Group et CyberTest avec un accès complet au code source. Keeper gère son programme de divulgation des vulnérabilités en partenariat avec Bugcrowd. Globalement, cela profite à l'ensemble du secteur tout en favorisant l'intérêt général.

Lignes directrices

La Politique de divulgation des vulnérabilités de Keeper définit les attentes lors de la collaboration avec des hackers de bonne foi, et ce que vous pouvez attendre de nous.

Lorsque les tests et les rapports de sécurité sont effectués dans le respect des lignes directrices de la présente politique, nous :

• Considérons qu'ils sont autorisés conformément à la Loi sur la fraude et les infractions informatiques.
• Considérons qu'ils n'entrent pas dans le champ d'application de la DMCA, et nous ne porterons pas plainte contre vous pour avoir contourné les contrôles de sécurité ou de technologie.
• Les considérons légaux et nous n'intenterons ni ne soutiendrons aucune action en justice liée à ce programme contre vous.
• Coopérerons avec vous pour comprendre et résoudre le problème rapidement.
• Nous reconnaîtrons publiquement vos contributions si vous êtes le premier à signaler le problème et que nous modifions le code ou la configuration sur la base de ce problème.

Si, à quelque moment que ce soit, vous avez des inquiétudes ou des doutes quant à la conformité des tests avec les lignes directrices et la portée de la présente politique, contactez-nous à l'adresse security@keepersecurity.com avant de continuer.

Afin d'encourager les tests de sécurité de bonne foi et la divulgation des vulnérabilités découvertes, nous vous demandons :

• Évitez de porter atteinte à la confidentialité des utilisateurs, de nuire à l'expérience des utilisateurs, de perturber la production ou les systèmes de l'entreprise et/ou de détruire des données.
• Effectuez uniquement des recherches dans le cadre du programme de divulgation des vulnérabilités de Bugcrowd, dont le lien figure ci-dessous, et respectez les systèmes et les activités qui sont hors du champ d'application.
• Contactez-nous immédiatement à l'adresse security@keepersecurity.com vous découvrez des données d'utilisateur pendant les tests.
• Accordez-nous un délai raisonnable pour analyser le problème signalé, le confirmer et le résoudre avant de divulguer publiquement les failles découvertes.

Envoyez vos rapports à l'adresse suivante : https://bugcrowd.com/keepersecurity

Transparence

Keeper n'est pas seulement attaché à la sécurité, c'est une priorité absolue. C'est pourquoi nous rendons chaque élément de notre modèle de chiffrement accessible au public. Nous estimons que nos clients méritent de connaître toutes les mesures que nous prenons pour garantir la sécurité de leurs données dans un contexte de cybersécurité en constante évolution.

Votre coffre-fort Keeper est protégé même dans le pire des cas grâce au modèle de chiffrement zero trust et zero knowledge. Nous effectuons constamment des tests de sécurité pour nous assurer que nous restons la meilleure solution pour protéger vos données les plus précieuses.

Documentation de produit

Le portail de documentation de Keeper contient des manuels produit, des informations techniques, des notes de version et des guides de l'utilisateur. Il est accessible en cliquant sur ce lien.

Notes de publication du produit

Pour plus de transparence, Keeper publie des notes de version détaillées sur chaque plateforme.

État du système

Vous pouvez consulter l'état du système en temps réel ici.