> Question 1 : la machine de contrôle
Chez Userify (divulgation complète : nous offrons en fait un logiciel pour gérer les clés ssh), nous traitons ce problème en permanence, puisque nous gérons é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, car vous avez un meilleur contrôle, vous réduisez votre surface, vous pouvez vraiment le verrouiller aux seuls réseaux de confiance connus.
Ce qu'il faut retenir, c'est que dans un système correctement construit comme celui-ci, il ne devrait pas y avoir de secrets importants susceptibles d'être divulgués à un attaquant. Si quelqu'un pénètre dans votre centre de données avec un chariot élévateur et s'en va avec votre serveur, il n'obtiendra pas grand-chose, si ce n'est quelques mots de passe lourdement hachés, probablement quelques fichiers lourdement cryptés et quelques clés publiques sans les clés privées correspondantes. En d'autres termes, pas grand-chose.
Comme vous le soulignez, les véritables vecteurs de menace sont les suivants que se passe-t-il si un pirate prend le contrôle de cette machine ? et l'utilise pour déployer ses propres comptes d'utilisateur et clés (publiques). Il s'agit d'un risque pour pratiquement toutes les plates-formes en nuage (ex : Linode). Vous devriez vous concentrer sur la prévention de l'accès au plan de contrôle, ce qui signifie minimiser la surface d'attaque (n'exposer que quelques ports et verrouiller ces ports autant que possible) et de préférence utiliser un logiciel qui est renforcé contre l'escalade des privilèges et diverses attaques (injection SQL, XSS, CSRF, etc.) Activer l'accès 2FA/MFA au plan de contrôle et se concentrer sur le verrouillage de ce plan de contrôle autant que possible.
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) ?
C'est nettement meilleure d'avoir une machine de contrôle dédiée dans un centre de données sécurisé, parce que vous pouvez l'isoler et la verrouiller pour prévenir/minimiser le risque de vol ou d'accès non autorisé.
Si la meilleure pratique consiste à utiliser mon ordinateur portable (qui pourrait être volé, bien sûr, mais je pourrais avoir mes clés publiques sauvegardées en toute sécurité en ligne dans le nuage ou hors ligne sur un appareil portable crypté), Et si j'ai besoin d'utiliser des 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 un plan de contrôle secondaire pour gérer vos clés (même Userify) jusqu'à ce que vous deveniez suffisamment grand pour commencer à rencontrer des problèmes de gestion en raison d'un plus grand nombre d'utilisateurs et de différents niveaux d'autorisation sur les serveurs ou que vous ayez besoin d'un coup de main supplémentaire pour vos utilisateurs qui n'ont peut-être pas les connaissances ou l'accès à Ansible pour mettre à jour les clés. Userify au début n'était pas beaucoup plus qu'un tas de Shell Shell (aujourd'hui ils seraient Ansible, probablement !) et il n'y a rien de mal à cela, jusqu'à ce que vous commenciez à avoir besoin d'un contrôle de gestion supplémentaire et de moyens faciles pour les gens de gérer/rotation de leurs propres clés. (Bien sûr, jetez un coup d'œil à Userify si vous en arrivez là).
Comment le sécuriser et éviter qu'il ne devienne un "point d'attaque unique" ?
Bien sûr, consultez toutes les ressources disponibles sur le net pour verrouiller les choses, mais le plus important, c'est qu'il n'y a pas d'autre solution que d'aller voir sur place. commencer par une base solide :
1. Concevez votre solution en gardant la sécurité à l'esprit dès le départ. Choisissez une technologie (c'est-à-dire une base de données ou des langages) qui a traditionnellement connu moins de problèmes, puis codez en pensant d'abord à la sécurité. Assainir toutes les données entrantes, même celles provenant d'utilisateurs de confiance. La paranoïa est une vertu.
2. Tout finit par se briser. Minimisez les dommages lorsque cela se produit : comme vous l'avez déjà souligné, essayez de minimiser la manipulation de matériel secret.
3. Restez simple. N'adoptez pas les dernières nouveautés exotiques à moins d'être certain qu'elles augmenteront votre sécurité de manière mesurable et prouvable. Par exemple, nous avons choisi X25519/NaCl (libsodium) plutôt que AES pour notre couche de chiffrement (nous chiffrons tout, au repos et en mouvement), parce qu'il a été conçu et écrit à l'origine par quelqu'un en qui nous avons confiance (DJB et al) et qu'il a été examiné par des chercheurs de renommée mondiale tels que 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 bogues profonds.
4. Répondre aux normes de sécurité. Même si vous ne relevez pas d'un régime de sécurité tel que PCI ou la règle de sécurité HIPAA, lisez ces normes et trouvez le moyen de les respecter ou, au moins, de mettre en place des contrôles compensatoires très stricts. Cela vous permettra de vous assurer que vous respectez réellement les "meilleures pratiques".
5. Introduire des tests de pénétration externes/indépendants et mettre en place des primes aux bogues. pour vous assurer que vous suivez ces bonnes pratiques en permanence. Tout semble parfait jusqu'à ce que des personnes intelligentes et très motivées s'y attaquent... une fois que ce sera fait, vous aurez une grande confiance dans votre solution.
Question 2 : les clés SSH Quel est le meilleur choix : laisser Ansible utiliser l'utilisateur root (avec sa clé publique sauvegardée dans ~/.ssh/authorized_keys / permet à l'utilisateur Ansible d'exécuter toutes les commandes via sudo en spécifiant un mot de passe (qui est unique et doit être connu de tous les administrateurs système qui utilisent Ansible pour contrôler les serveurs).
Essayez de ne jamais utiliser de mots de passe sur les serveurs, même pour sudo. C'est une question de secrets et, en fin de compte, cela sapera votre sécurité (vous ne pouvez pas vraiment faire varier le mot de passe sudo entre les machines, vous devez le stocker quelque part, le mot de passe signifie que vous ne pouvez pas vraiment faire de l'automatisation de serveur à serveur, ce qui est exactement ce dont il s'agit). De plus, si vous laissez SSH à ses valeurs par défaut, ces mots de passe peuvent être forcés de manière brute, ce qui rend les clés quelque peu vides de sens. Par ailleurs, évitez d'utiliser l'utilisateur root pour quelque raison que ce soit, et en particulier pour la connexion à distance.
Créer un utilisateur non privilégié dédié à Ansible avec un accès sudo / permettre à l'utilisateur Ansible d'exécuter toutes les commandes via sudo sans spécifier de mot de passe.
Exactement. Un utilisateur non privilégié que vous pouvez auditer dans ansible, avec des rôles sudo. Idéalement, créez un utilisateur standard dédié aux communications serveur à serveur/ansible avec un accès sudo (sans mot de passe).
... N.B., si vous utilisiez Userify, je vous 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), de générer une clé SSH sur le serveur de contrôle, et de fournir sa clé publique dans sa page de profil Userify. (Cette zone de texte devient essentiellement /home/ansible/.ssh/authorized_keys ). Le compte système ansible doit être séparé des autres comptes système serveur à serveur, tels que le compte de sauvegarde à distance, la gestion des secrets, etc. Ensuite, invitez vos humains et ils peuvent créer et gérer leurs propres clés également et tout reste séparé. Mais, tout comme pour le verrouillage d'un serveur de contrôle Ansible, essayez de verrouiller votre serveur Userify (ou toute autre solution que vous déployez) de la même manière.
d'autres indices ?
Je pense que vous vous y prenez de la bonne manière et que vous posez les bonnes questions. Si vous souhaitez discuter de ce genre de choses, envoyez-moi un courriel (first dot last name at userify) et je serai ravi de discuter avec vous, quelle que soit la direction que vous prendrez en fin de compte. Je vous souhaite bonne chance !
