Pouvez-vous garder un secret? Qu’en est-il de l’environnement de données de votre organisation?
Dans un réseau informatique, un «secret» est une donnée compacte qui doit rester confidentielle. En règle générale, les secrets sont utilisés pour l’authentification ou comme entrée dans un algorithme cryptographique. Les secrets les plus courants comprennent:
- Identifiants de compte avec des privilèges
- Clés SSH
- Les identifiants d’API et d’autres application keys, y compris ceux utilisés dans les récipients, les systèmes CI / CD, les processus d’automatisation, le logiciel de protocole de bureau à distance (RDP) et même les logiciels de sécurité
- Base de données et autres mots de passe de système à système.
- TLS / SSL et autres certificats privés pour une communication sécurisée
- Clés de chiffrement privées
Étant donné que les secrets du réseau informatique déverrouillent l’accès aux systèmes et aux données hautement privilégiés, la sécurisation des secrets est tout aussi essentielle pour prévenir les cyberattaques que la sécurisation des mots de passe de l’utilisateur final. Environ 75% des attaques de ransomware impliquent des identifiants compromis – la plupart du temps, des identifiants RDP.
Comment les secrets sont compromis
L’un des plus grands défis de la gestion des secrets est l’étalement des secrets, qui se produit lorsque les organisations utilisent une approche ad hoc de la gestion des secrets. Différents services, équipes et même les membres de l’équipe gèrent tous indépendamment les secrets sous leur responsabilité.
Cette approche peut sembler raisonnable au début. Par exemple, un nouveau microsite doit accéder à une base de données. L’administrateur a déjà un fichier de paramétrage avec des données sensibles, alors pourquoi ne pas sécuriser la clé d’accès à la base de données dans le même fichier de paramétrage, puis vous assurer que le fichier est sécurisé? Cela fonctionne lorsqu’une organisation a un nombre relativement faible de secrets à protéger.
Cependant, à mesure que les organisations se développent, leurs environnements de données et les secrets qu’ils stockent évoluent également. Avant que l’équipe informatique ne s’en rende compte, les secrets se sont multipliés comme des Tribules – les clés SSH seules peuvent se chiffrer en milliers – et elles sont dispersées sur tout le réseau, sans ordre spécifique.
Les identifiants codés en dur ou intégrés sont un autre obstacle à la gestion des secrets. De nombreuses solutions logicielles, appareils IoT et autres matériels sont livrés avec des identifiants par défaut codés en dur. Si ces appareils et applications sont déployés sans modifier les identifiants par défaut, les cybercriminels peuvent facilement y accéder en utilisant les outils d’analyse en combinaison avec le dictionnaire par force brute ou d’autres attaques de mots de passe, ou ils peuvent simplement lire le manuel du propriétaire de l’appareil ou de l’application, qui comprend les identifiants par défaut.
Dans les environnements DevOps, les outils de pipeline CI / CD courants tels que Jenkins, Ansible, Github Actions et Azure DevOps utilisent des secrets pour accéder aux bases de données, aux serveurs SSH, aux services HTTP et à d’autres systèmes sensibles. Ces secrets sont stockés dans un fichier de paramétrage pour le système de déploiement ou dans l’un des douze coffres de stockage différents, qui fournissent tous des capacités très différentes en fonction du produit. Dans un scénario où les administrateurs ne stockent pas les identifiants dans les fichiers ou les systèmes de paramétrage, ils sont probablement stockés dans leurs environnements DevOps. Quel que soit le cas, les administrateurs peuvent ou ne peuvent pas avoir toutes les possibilités de vérifier ou obtenir d’alerte sur l’utilisation de ces secrets.
Bien que certains outils incluent des gestionnaires de secrets intégrés, qui permettent aux organisations de supprimer les identifiants codés en dur / intégrés, les gestionnaires de secrets fonctionnent uniquement avec ces outils, ce qui ne résout pas le problème d’étalement des secrets.
Keeper Secrets Manager: sécurité Zero-Trust, Zero-Knowledge pour les secrets de votre réseau
Keeper est heureux d’annoncer le lancement de Keeper Secrets Manager, la première et seule solution Zero-Trust et Zero-Knowledge cloud-based, pour sécuriser les secrets d’infrastructure. Keeper Secrets Manager est entièrement géré et utilise une nouvelle architecture de sécurité en attente de brevet. En outre, il tire parti du même modèle de sécurité Zero-Knowledge que la plateforme de enterprise password management (EPM) de Keeper.
Avec Keeper Secrets Manager, tous les serveurs, les pipelines CI / CD, les environnements de développement et le code source tirent des secrets d’un terminal API sécurisé. Chaque secret est chiffré avec une clé AES 256-bit, puis chiffré à nouveau par une autre clé d’application AES-256. L’appareil client récupère le texte chiffré du cloud Keeper, et les secrets sont déchiffrés et utilisés localement sur l’appareil (et non sur le serveur de Keeper).
Ready to see Keeper Secrets Manager for yourself?
Talk to an Expert
En outre, toutes les demandes de serveur sont chiffrées avec une clé de transmission AES-256 en plus de TLS pour prévenir les attaques MITM ou de replay. Si vous comptez, c’est beaucoup de clés de chiffrement! Cette cryptographie multicouche est gérée de manière transparente via nos SDKs côté client, qui sont faciles à intégrer dans n’importe quel environnement.
Bien que les solutions de gestion des secrets compétitives exigent que les clients achètent du matériel spécial, installent un service proxy ou utilisent un fournisseur de services cloud spécifique, Keeper Secrets Manager s’intègre de manière transparente à presque n’importe quel environnement de données, sans aucun matériel supplémentaire ou infrastructure hébergée dans le cloud requis. Il offre des intégrations prêtes à l’emploi avec une grande variété d’outils DevOps, y compris les Github Actions, Kubernetes, Ansible et plus encore.
Keeper Secrets Manager est une extension naturelle de Keeper enterprise password manager (EPM). Il est intégré au coffre Web Keeper, à l’application de bureau et à la console d’administration avec des intégrations au module de rapport et d’alertes avancés de Keeper, BreachWatch, Webhooks, l’intégration SIEM et les outils de conformité. Par exemple, tous les identifiants codés en dur ou intégrés qui sont stockés dans le Keeper Vault d’une organisation seront soumis aux analyses BreachWatch, et les administrateurs informatiques seront informés si l’un de ces identifiants est compromis.
En savoir plus sur Keeper Secrets Manager et planifier une demonstration!