> Question 1: la machine de contrôle
Chez Userify (divulgation complète: nous proposons un logiciel permettant de gérer les clés SSH), nous traitons ce problème en permanence, car nous exploitons également le plus grand entrepôt de clés SSH. Nous recommandons généralement l’installation locale plutôt que l’utilisation du cloud, puisque vous avez un contrôle accru, réduisez votre surface, vous pouvez vraiment le verrouiller aux réseaux de confiance connus.
La chose importante à retenir est que, dans un système correctement construit comme celui-ci, il ne devrait y avoir aucun secret important pouvant être divulgué à un attaquant. Si quelqu'un conduit un chariot élévateur dans votre centre de données et s'en va avec votre serveur, il n'en obtiendra pas beaucoup, à l'exception de mots de passe fortement hachés, probablement de fichiers fortement cryptés et de clés publiques sans les clés privées correspondantes. En d'autres termes, pas tant que ça.
Comme vous l'avez fait remarquer, les véritables vecteurs de menace ici sont ce qui se passe si un attaquant acquiert le contrôle de cette machine et l'utilise pour déployer ses propres comptes d'utilisateurs et clés (publiques). C'est un risque pour pratiquement toutes les plateformes de cloud (ex: Linode). Vous devez surtout vous concentrer sur la prévention de l’accès au plan de contrôle, ce qui signifie minimiser la surface d’attaque (exposer seulement quelques ports, et verrouiller autant que possible ces ports) et utiliser de préférence un logiciel renforcé contre les hausses de privilèges et diverses attaques ( Injection SQL, XSS, CSRF, etc.) Activez l’accès 2FA / MFA au plan de contrôle et concentrez-vous sur le verrouillage de ce plan de contrôle autant que possible.
Alors, est-il préférable d'avoir une machine de contrôle dédiée dans le centre de données ou une machine de contrôle à distance (comme mon ordinateur portable connecté à distance au centre de données)?
Il est certainement préférable d'avoir une machine de contrôle dédiée dans un centre de données sécurisé, car vous pouvez l'isoler et la verrouiller pour éviter / minimiser les risques de vol ou d'accès non autorisé.
Si la meilleure pratique consiste à utiliser mon ordinateur portable (qui peut être volé, bien sûr, mais mes clés publiques peuvent être sauvegardées de manière sécurisée en ligne dans le cloud ou hors ligne sur un périphérique crypté portable), que se passe-t-il si je dois utiliser certaines interfaces Web avec Ansible, comme Ansible Tower, Semaphore, Rundeck ou Foreman, qui doit être installé sur une machine centralisée dans le centre de données?
Vous n’avez besoin d’exécuter AUCUNE interface Web ou plan de contrôle secondaire pour gérer vos clés (même Userify) tant que vous n’avez pas atteint un niveau suffisant pour vous attaquer aux problèmes de gestion dus à un nombre plus important d’utilisateurs et à différents niveaux d’autorisation sur les serveurs ou si vous avez besoin de ressources supplémentaires. Tenir la main pour vos utilisateurs qui n'ont peut-être pas la connaissance ou l'accès à Ansible pour mettre à jour les clés. Initialement, Userify n’était rien d’autre qu’un tas de scripts shell (aujourd’hui, ils seraient Ansible, probablement!) Et il n’ya rien de mal à cela, jusqu’à ce que vous ayez besoin d’un contrôle de gestion supplémentaire et de moyens faciles pour les utilisateurs de gérer / faire pivoter leurs fichiers. propres clés. (Bien sûr, jetez un coup d'œil à Userify si vous arrivez à ce point!)
Comment le sécuriser et éviter qu’il ne devienne un "point d’attaque unique"?
Bien sûr, vérifiez toutes les ressources sur le net pour verrouiller les choses, mais le plus important est de commencer par une base sécurisée:
1. Concevez votre solution en veillant à la sécurité dès le début. Choisissez une technologie (c.-à-d. Une base de données ou des langues) qui ont généralement rencontré moins de problèmes, puis codez avec la sécurité au premier plan. Désinfectez toutes les données entrantes, même des utilisateurs de confiance. La paranoïa est une vertu.
2. Finalement, tout est cassé. Minimisez les dégâts lorsque cela se produit: comme vous l'avez déjà souligné, essayez de minimiser le traitement des documents secrets.
3. Restez simple. Ne faites pas les dernières choses exotiques, sauf si vous êtes certain que cela augmentera votre sécurité de manière mesurable et prouvable. Par exemple, nous avons sélectionné X25519 / NaCl (libsodium) sur AES pour notre couche de chiffrement (nous chiffrons tout, au repos et en mouvement), car il a été initialement conçu et écrit par une personne de confiance (DJB et al) et révisé par le monde. Des chercheurs renommés comme Schneier et l'équipe de sécurité de Google. Utilisez des choses qui tendent vers la simplicité si elles sont plus récentes, car la simplicité rend plus difficile la dissimulation de bugs profonds.
4. Répondre aux normes de sécurité. Même si vous ne tombez pas dans un régime de sécurité tel que PCI ou la règle de sécurité HIPAA, lisez ces normes et déterminez comment les respecter ou au moins des contrôles compensatoires très stricts. Cela contribuera à garantir que vous rencontrez réellement les «meilleures pratiques».
5. Faites appel à des tests d'intrusion externes / indépendants et utilisez des primes de bugs pour vous assurer que vous suivez ces meilleures pratiques de manière continue. Tout va bien jusqu'à ce que des gens intelligents et très motivés s'en mêlent ... une fois que tout est terminé, vous aurez beaucoup de confiance en votre solution.
Question 2: les clés SSH Quel est le meilleur choix: laisser Ansible utiliser l'utilisateur root (avec sa clé publique enregistrée dans ~/.ssh/authorized_keys/ laisser l'utilisateur Ansible exécuter toutes les commandes via sudo en spécifiant un mot de passe (ce qui est unique et doit être connu de chaque administrateur système) qui utilise Ansible pour contrôler ces serveurs)
Essayez d'éviter de jamais utiliser des mots de passe sur les serveurs, même pour sudo. Cela concerne des secrets et finit par porter atteinte à votre sécurité (vous ne pouvez pas vraiment varier ce mot de passe sudo entre ordinateurs, vous devez le stocker quelque part, le mot de passe signifie que vous ne pouvez pas vraiment automatiser serveur à serveur, ce qui est impossible. En outre, si vous laissez SSH à ses valeurs par défaut, ces mots de passe peuvent être forcés brutalement, ce qui rend les clés un peu vides de sens, ainsi que d'éviter l'utilisation de l'utilisateur root à quelque fin que ce soit, et en particulier la connexion à distance.
Créer un utilisateur non privilégié dédié à Ansible avec un accès sudo / laisser l'utilisateur Ansible exécuter toutes les commandes via sudo sans spécifier de mot de passe
Exactement. Un utilisateur non privilégié que vous pouvez vérifier en arrière, avec des rôles sudo. Idéalement, créez un utilisateur standard dédié aux communications serveur à serveur / ansible avec accès sudo (sans mot de passe).
... NB, si vous utilisiez Userify, je suggèrerais de créer un utilisateur Userify pour ansible (vous pouvez également le diviser par projet ou même par groupe de serveurs si vous avez plusieurs machines de contrôle ansible), générez une clé SSH sur le serveur de contrôle et fournissez sa clé publique dans sa page de profil Userify. (Cette zone de texte devient essentiellement /home/ansible/.ssh/authorized_keys). Vous devez séparer le compte système ansible des autres comptes système serveur à serveur, tels qu'un compte de sauvegarde distant, la gestion des secrets, etc. Invitez ensuite vos utilisateurs. Ils peuvent également créer et gérer leurs propres clés et tout reste séparé. Toutefois, comme pour le verrouillage d’un serveur de contrôle Ansible, essayez de verrouiller votre serveur Userify (ou la solution que vous déployez) de la même manière.
d'autres allusions?
Je pense que vous vous y prenez certainement de la bonne façon et que vous posez les bonnes questions. Si vous souhaitez discuter de ce genre de chose, écrivez-moi (prénom du point à userify) et je serais heureux de pouvoir discuter, quelle que soit la direction que vous poursuivez. Bonne chance!