Ansible meilleures pratiques de sécurité

Je vais introduire Ansible dans mon centre de données et je recherche des pratiques optimales en matière de sécurité pour localiser la machine de contrôle et gérer les clés SSH.

Question 1: la machine de contrôle

Nous avons bien sûr besoin d'une machine de contrôle. La machine de contrôle possède des clés SSH publiques enregistrées. Si un attaquant a accès à la machine de contrôle, il a potentiellement accès à l’ensemble du centre de données (ou aux serveurs gérés par Ansible). 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)?

Si la meilleure pratique consiste à utiliser mon ordinateur portable (qui pourrait être volé, bien sûr, mais mes clés publiques pourraient être sauvegardées de manière sécurisée en ligne dans le cloud ou hors ligne sur un périphérique crypté portable), 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? Comment le sécuriser et éviter qu’il ne devienne un "point d’attaque unique"?

Question 2: les clés SSH

Supposons que je doive utiliser Ansible pour effectuer certaines tâches qui doivent être exécutées par root (comme l’installation de progiciels ou quelque chose du genre). Je pense que la meilleure pratique consiste à ne pas utiliser l'utilisateur root sur des serveurs contrôlés, mais à ajouter un utilisateur normal pour Ansible avec les autorisations sudo. Toutefois, si Ansible doit exécuter presque toutes les tâches, il doit pouvoir accéder à toutes les commandes par le biais de sudo. Alors, quel est le meilleur choix:

• laisser Ansible utiliser l'utilisateur root (avec sa clé publique enregistrée dans ~/.ssh/authorized_keys
• créer un utilisateur non privilégié dédié à Ansible avec accès sudo
• permettre à l'utilisateur Ansible d'exécuter toutes les commandes via sudo en spécifiant un mot de passe (chaque administrateur système qui doit être unique doit en connaître l'existence)
• permettre à l'utilisateur Ansible d'exécuter toutes les commandes via sudo sans spécifier de mot de passe
• d'autres allusions?

Le bastion host (le centre de contrôle ansible) appartient à un sous-réseau distinct. Il ne devrait pas être directement accessible de l'extérieur, ni directement des serveurs gérés!

Votre ordinateur portable est le périphérique le moins sécurisé de tous. Un courrier stupide, une vulnérabilité flash stupide, un invité stupide Wifi et il se fait pwned.

Pour les serveurs, n'autorisez pas l'accès root via ssh. Beaucoup d'audits s'en moquent.

Pour ansible, laissez chaque administrateur utiliser son propre compte personnel sur chaque serveur cible, et laissez-les entrer avec des mots de passe. De cette façon, aucun mot de passe n'est partagé entre deux personnes. Vous pouvez vérifier qui a fait quoi sur chaque serveur. C’est à vous de voir si les comptes personnels permettent de se connecter avec un mot de passe, avec la clé ssh uniquement, ou bien nécessitent les deux.

Pour clarifier, ansible ne nécessite pas l’utilisation d’un seul nom de connexion cible . Chaque administrateur peut et devrait avoir un identifiant de cible personnel.

Remarque: essayez de ne jamais créer un compte appelé mot (comme "ansible", "admin", "cluster", "management" ou "opérateur") s'il possède un mot de passe. Le seul bon nom pour un compte qui a un mot de passe est le nom d'un être humain, comme "jkowalski". Seul un être humain peut être responsable des actions effectuées via le compte et responsable de la sécurisation incorrecte de son mot de passe, mais "impossible".

> 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!

Réponse 1: la machine de contrôle

Un peu des deux, vous pouvez utiliser votre ordinateur portable pour vous connecter à des serveurs via un hôte bastion. quelque chose comme:

Host private1
  IdentityFile ~/.ssh/rsa_private_key
  ProxyCommand ssh user@bastion -W %h:%p

Host bastion
  IdentityFile ~/.ssh/bastion_rsa_key

En savoir plus sur les hôtes du bastion

Où vous avez une clé pour le serveur bastion, puis une clé distincte pour l'hôte derrière elle. (personnellement, j'utiliserais gpg-agent / ssh-agent)

Réponse 2: authentification

Je ne suis pas sûr de savoir en quoi les meilleures pratiques "ansibles" spécifiques diffèrent de toutes les autres meilleures pratiques de connexion ssh.

Une combinaison des authentifications suivantes:

• Clés SSH par utilisateur (stockées de manière centralisée)
• Authentification Kerberos
• Authentification multi-facteurs ( Yubikeys , Duo, GoogleAuth, etc.)
• Fail2ban / lock-account
• enregistrement et alerte centralisés
• authentification centralisée (FreeIPA, LDAP, IdM, MS AD)
• signer des clés ssh avec un ca interne

D'autres pensées:

• Toujours stocker les secrets / informations privées dans ansible-vault.
• Ansible n’a pas besoin de SUDO / Root pour fonctionner, à moins que ce que vous faites n’exige sudo / root.
• Ansible peut élever les autorisations de différentes manières

Enfin, vous n'avez rien dit à propos de Windows. Donc, je ne peux que supposer que vous ne l'utilisez pas. Cependant, dans ce cas, j'utiliserais l'option délégué pour que votre ordinateur portable utilise l'hôte bastion (delegate_to bastion.hostname.fqdn:) et kerberos / winrm https avec des tickets Kerberos.

Au cas où vous l'auriez manqué, les meilleures pratiques informatiques, ne faites jamais rien en tant que root, utilisez toujours des comptes nommés.