Gestionnaire de mot de passe auto-hébergé vs. cloud-based

Parfois, des clients s’interrogent sur les avantages et les inconvénients d’une solution de gestion des mots de passe auto-hébergée telle que Bitwarden. Mon expérience en la matière me pousse à vous faire part des principales raisons d’utiliser un gestionnaire de mot de passe cloud-based tel que Keeper, plutôt qu’un coffre de mot de passe auto-hébergé.

Les avantages d’une solution auto-hébergée

À mon avis, l’unique avantage d’une plateforme de gestion des mots de passe auto-hébergée c’est lorsque les utilisateurs ne se servent que d’un ordinateur de bureau, dans un environnement de réseau isolé (air gap). Cette situation ne s’applique pas à la grande majorité des particuliers ou des entreprises.

Les inconvénients d’une solution auto-hébergée

Gestion de l’infrastructure

Dans une solution auto-hébergée, le client est responsable du déploiement du conteneur, de l’hébergement sur un serveur, de l’équilibrage de la charge, des certificats SSL, du routage et du pare-feu. Le client passe ainsi de la gestion des utilisateurs finaux à la gestion d’une plateforme logicielle entière. Lorsque les choses tournent mal (et c’est inéluctable), l’administrateur est le seul et unique responsable.

Une expertise sera donc nécessaire pour les éléments suivants :

• Les conteneurs Docker
• Docker Swarm pour une haute disponibilité
• Hébergement, maintenance, mises à niveau et sauvegarde de serveurs de base de données
• Équilibrage de charge
• Pare-feu/Pare-feu d’application Web (WAF)
• Administration des services Windows ou Linux
• Application de correctifs, sauvegarde et récupération d’instances
• Administration du matériel – installation et maintenance permanente des serveurs, de l’infrastructure réseau (routeurs, commutateurs), des pare-feu/appareils de sécurité, des baies de stockage et du dispositif électrique.
• Maintenance des installations – alimentation de secours (générateurs, batteries), environnement, sécurité physique et contrôle des accès.

Keeper est déployé sur une grande infrastructure cloud dans plusieurs centres de données géographiques, avec une équipe dévouée constituée d’un personnel DevOps qui travaille à plein temps aux États-Unis, et dont la mission est de gérer, sécuriser et surveiller l’environnement.

Déploiement de paramètres personnalisés

Dans une solution auto-hébergée, toutes les applications déployées doivent être modifiées par l’administrateur et chaque utilisateur final pour inclure des paramètres de point de terminaison d’URL personnalisés. Les utilisateurs seront mis au défi de le faire et devront disposer d’une connectivité réseau avec le point de terminaison hébergé. Vous pouvez également appliquer ces paramètres par le biais de la stratégie de groupe et de la gestion des appareils mobiles (MDM), mais cela suppose que vous disposiez d’un contrôle total et complet sur tous les appareils de point de terminaison. Tout appareil hors de votre contrôle doit être configuré manuellement par l’administrateur ou l’utilisateur.

Les applications Keeper destinées aux utilisateurs finaux n’ont pas besoin d’être configurées – elles sont prêtes à l’emploi.

Absence de cas d’usage critiques

Il existe de nombreux cas d’usage qui pourraient ne pas être disponibles dans une installation sur site d’un service de coffre de mot de passe. Par exemple :

• La synchronisation et la transmission en temps réel nécessitent une connectivité à l’infrastructure dans le cloud. Un relais dans le cloud peut être proposé par le fournisseur pour résoudre ce problème, mais cela élimine la notion d’auto-hébergement.
  
• Une Intégration de l’authentification unique (SSO) très complexe
  avec les services de gestion des clés sur site
• L’intégration aux API nécessitera un routage réseau depuis les serveurs de développement/production jusqu’au point de terminaison auto-hébergé cible.

Keeper fournit une synchronisation en temps réel et ne nécessite aucun service sur site pour fonctionner ou pour s’intégrer à la SSO. Toutes les API communiquent directement avec le cloud Keeper en utilisant le chiffrement Zero-Knowledge. Aucune modification du routage du réseau interne n’est nécessaire.

Vulnérabilités en matière de sécurité

Afin de permettre aux utilisateurs finaux d’accéder au coffre sur leurs systèmes à distance ou leurs appareils mobiles, l’application hébergée doit exposer l’accès au réseau entrant à la cible. Ceci signifie que le service sera accessible au public, ce qui donnera aux bots et aux acteurs malveillants la possibilité de l’attaquer. Par conséquent, vous serez obligé d’acheter et de déployer une solution WAF front-end tierce telle que Cloudflare, AWS Shield, etc.

Keeper est une solution Zero-Knowledge entièrement gérée, hébergée dans Amazon Web Services. Amazon Shield/WAF est déployé pour gérer le déni de service distribué (DDoS) et d’autres attaques de bot.

Mises à jour logicielles

Avec une solution auto-hébergée, tous les logiciels sur site doivent être sauvegardés, corrigés, arrêtés et redémarrés en permanence. Une solution de coffre qui évolue rapidement nécessite de nombreux composants mobiles et des mises à jour constantes du produit sur les différentes plateformes : Web, bureau, mobile, extensions de navigateur, etc. Le taux élevé de mises à jour nécessitera des correctifs logiciels fréquents pour tout produit sur site. Et il existe toujours un risque qu’un mauvais correctif ou un correctif non appliqué puisse causer un problème grave.

Les logiciels Keeper, toutes plateformes confondues, sont toujours à jour et bénéficient des dernières mises à jour de sécurité. Aucune intervention du client n’est nécessaire.

Sauvegarde et récupération

Les bases de données, les serveurs, la configuration et les conteneurs doivent être sauvegardés. La récupération doit être testée et vérifiée en permanence. Si des sauvegardes quotidiennes sont effectuées à partir d’une instance sur site d’une base de données, il existe un risque de perte de mots de passe critiques et confidentiels au cours d’une période de 24 heures.

L’infrastructure de la base de données de Keeper est déployée dans plusieurs régions et dans plusieurs zones. Les sauvegardes de données peuvent être restaurées à n’importe quel moment – à la seconde près – dans un délai de 30 jours. De plus, la fonctionnalité Historique des archives de Keeper fournit un historique complet des modifications apportées à chaque mot de passe ou archive stockée dans la plateforme depuis le tout début.

Des initiés malveillants

Dans une solution auto-hébergée, l’administrateur a un contrôle total sur les logiciels et le stockage. Cela donne également à l’administrateur la possibilité de prendre le contrôle du coffre d’un utilisateur, du coffre de ses supérieurs hiérarchiques et des cadres supérieurs de niveau C.

Par ailleurs, si l’administrateur a créé le service à partir d’un code source, il a également la possibilité d’introduire des bugs, des vulnérabilités et des élévations de privilèges. Dans la plupart des environnements, les équipes de direction et les cadres ne doivent pas permettre à un administrateur d’élever ses privilèges et d’accéder aux coffres des utilisateurs.

Keeper est développé à l’aide d’une architecture de sécurité Zero-Knowledge et Zero-Trust. Keeper peut être facilement paramétré pour créer des rôles d’administrateur délégué avec des autorisations limitées. Les administrateurs Keeper n’ont pas la possibilité de déchiffrer les coffres d’utilisateurs qu’ils ne gèrent pas.

Risques Open Source

Il est intéressant de mettre à la disposition de la communauté open source l’intégralité du code source des applications front-end et back-end, ce qui présente des avantages sur le plan de la transparence. Cependant, les avantages en matière de sécurité sont limités pour la plupart des entreprises. Si un pull request émanant d’un acteur malveillant est accepté dans un projet open source sans examen adéquat par les experts, des vulnérabilités peuvent être introduites. Ce n’est pas parce que le code source est public que les chercheurs en sécurité analysent et testent le code pour détecter les vulnérabilités. On sait depuis des années que des vulnérabilités subsistent dans de nombreux projets de code source public.

Keeper fait appel à des chercheurs en cyber sécurité de renom pour effectuer des tests de pénétration trimestriels contre les cibles logicielles de Keeper, tant internes qu’externes, avec un accès complet au code source. Keeper s’est également associé à Bugcrowd pour gérer son programme de divulgation des vulnérabilités (VDP). Pour en savoir plus, rendez-vous sur https://bugcrowd.com/keepersecurity.

Les API de Keeper et les kits de développement logiciel (SDK) tels que Commander et Secrets Manager sont des sources publiques et sont disponibles sur notre référentiel Github.

Lacunes en matière d’audit dues à la mobilité du personnel

Inévitablement, un administrateur ayant le contrôle de cet environnement peut finir par quitter l’organisation. Ainsi, il pourrait laisser derrière lui un système non géré, non entretenu ou non sécurisé. De plus, si l’administrateur est licencié ou quitte son poste pour des raisons négatives, il n’y aura pas de trace d’audit d’un éventuel comportement malveillant (comme la copie des coffres des utilisateurs, l’introduction de vulnérabilités ou la destruction de données).

Keeper dispose d’un module dénommé Advanced Reporting & Alerts Module (ARAM) qui comprend une piste d’audit de toutes les activités des utilisateurs. Les administrateurs de Keeper n’ont jamais un accès direct aux données des coffres des utilisateurs finaux.

Si vous avez des questions, n’hésitez pas à nous envoyer un e-mail à security@keepersecurity.com.