Renforcer la sécurité des connexions SSH aux hôtes gérés avec Red Hat Ansible Automation Platform

Red Hat Ansible Automation Platform est une plateforme qui permet de mettre en œuvre des automatisations à l'échelle de l'entreprise, ce qui en fait un outil idéal pour vos audits de sécurité. Tout système de sécurité comporte de nombreuses couches, mais cet article se concentre sur la réduction des risques associés aux attaques SSH sur les hôtes gérés. Bien que le risque zéro n'existe pas, vous pouvez sécuriser les hôtes gérés afin d'éviter autant que possible certains types d'attaques (en particulier les attaques par force brute) et d'atténuer les risques associés à d'autres (en n'autorisant les connexions par SSH qu'à partir des hôtes autorisés, en utilisant la commande sudo, etc.). Cet article porte sur Ansible Automation Platform, mais la majeure partie de la configuration sécurisée est appliquée aux hôtes gérés (en modifiant sshd_config, sssd.conf, access.conf) pour que vous puissiez appliquer ces concepts à d'autres outils centralisés tels que Red Hat Satellite.

Poursuivez votre lecture pour apprendre à sécuriser la configuration de votre hôte géré à l'aide de la méthode suivante.

• Plusieurs comptes de service pour la connexion SSH aux hôtes, créés dans AD/LDAP :
  • Clé publique stockée dans AD/LDAP pour la connexion SSH avec authentification par clé publique
  • Mot de passe stocké dans AD/LDAP pour la commande sudo uniquement (pas pour la connexion SSH)
• Sur tout type d'hôte géré :
  • Connexion d'un compte de service possible uniquement à partir des nœuds d'exécution d'Ansible Automation Platform (rejet de toute tentative de connexion à partir d'un autre emplacement)
  • Mot de passe obligatoire pour la réattribution des privilèges avec la commande sudo pour tout compte de service

Configuration

Commencez par un déploiement standard non sécurisé, qui inclut généralement les éléments suivants.

• Un compte de service Ansible Automation Platform :
  • utilisé pour la connexion SSH aux hôtes ;
  • créé dans AD/LDAP avec un mot de passe aléatoire.
• Sur tout type d'hôte :
  • le compte de service peut se connecter avec le mot de passe ;
  • le compte de service peut utiliser la commande sudo sans mot de passe.

Renforcement de la sécurité de la configuration

De nombreuses entreprises créent un seul compte de service pour chaque service. Dans ce scénario avec Ansible Automation Platform, un seul compte de service est créé. Il permet de se connecter à tous les hôtes gérés. Cependant, si pour une raison quelconque, ce compte est compromis, l'attaquant peut accéder à tous les hôtes gérés.

Il s'agit de la première modification que vous devez effectuer. Une bonne stratégie de sécurité se fait en plusieurs couches, et dans cette optique, il est essentiel de créer plusieurs comptes de service. Il n'existe pas d'approche universelle pour la mise en œuvre de cette approche. Examinez votre architecture pour déterminer ce qui convient le mieux. Voici quelques stratégies courantes pour créer différents comptes de service.

• Emplacement ou datacenter : créer un compte de service pour chaque datacenter
• Organisation ou domaine : créer un compte de service pour chaque organisation ou domaine
• SE : créer un compte de service pour chaque type d'hôte (Red Hat Enterprise Linux 7, 8, 9, etc.)
• Utilisation : créer un compte de service pour chaque utilisation de l'hôte de l'application principale (base de données, Apache, Kafka)
• Sécurité : créer un compte de service pour chaque zone de sécurité (DMZ, Zone interne 1, etc.)

Créez un groupe commun pour tous les comptes de service. Il vous sera ainsi plus facile d'autoriser un compte tout en interdisant l'accès à tous les autres.

Authentification par clé SSH publique à l'aide d'AD/LDAP

Basez l'authentification SSH pour les comptes de service sur des clés publiques. Bien que ce type de clé présente des inconvénients par rapport aux mots de passe, il permet de neutraliser les attaques par force brute pour la connexion SSH.

Commencez par ajouter les clés SSH publiques de chaque compte de service à l'attribut altSecurityIdentities dans AD/LDAP.

Sur chaque hôte géré, ajoutez « ssh » à la liste de services dans /etc/sssd/sssd.conf :

services = nss, pam, ssh

Ajoutez les paramètres ldap_user_extra_attrs et ldap_user_ssh_public_key à la section [domain] de /etc/sssd/sssd.conf :

[domain/example.com]
ldap_user_extra_attrs = altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities

L'option AuthorizedKeysCommandUser spécifie le compte utilisateur utilisé pour exécuter AuthorizedKeysCommand. Il est recommandé d'avoir recours à un utilisateur dédié pour cette opération. Ajoutez ces paramètres SSH à /etc/ssh/sshd_config :

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

Pour plus d'informations, consultez Stocker les clés SSH utilisateur dans Active Directory pour l'authentification SSH sur le portail client Red Hat.

Interdiction de l'authentification par mot de passe

Ajoutez ces paramètres SSH à /etc/ssh/sshd_config sur tous les hôtes gérés pour interdire l'utilisation d'un mot de passe pour l'authentification SSH (remplacez <Service Account> par le nom du compte de service) :

Match User <Service Account>
PasswordAuthentication no
Match all

Utilisation obligatoire du mot de passe pour la commande sudo

Pour la commande sudo, forcez l'utilisation du mot de passe pour le compte de service. Pour ce faire, créez un fichier nommé pour le groupe de comptes de service dans /etc/sudoers.d et ajoutez cette ligne :

%<Service Account Group>   ALL=(ALL:ALL) ALL

Par exemple, si le nom du groupe est aapsas :

$ cat /etc/sudoers.d/aapsas
%appsas   ALL=(ALL:ALL) ALL

Bien que les meilleures pratiques en matière de sécurité recommandent d'ajouter uniquement une commande autorisée spécifique pour lancer une exécution sudo, cette méthode n'est pas possible avec Ansible Automation Platform. Pour les hôtes gérés, Ansible Automation Platform communique avec les machines cibles (le plus souvent à l'aide de SSH), puis copie et exécute un script Python.

Autorisation des connexions provenant des nœuds d'exécution autorisés d'Ansible Automation Platform

La dernière étape du renforcement de la sécurité consiste à autoriser les connexions SSH pour un compte de service provenant uniquement des nœuds d'exécution d'Ansible Automation Platform ou de LOCAL (pour les commandes sudo). Pour ce faire, vous devez ajouter une ligne dans /etc/security/access.conf. La première ligne autorise les connexions à partir d'Ansible Automation Platform et de LOCAL, tandis que la seconde interdit tout autre compte de service.

+: <Service Account> : <AAP Execution Nodes IPS> LOCAL
-: <Service Account Group> : ALL

Automatisation de toute la configuration

Si cet article décrit la marche à suivre pour renforcer la sécurité de vos hôtes gérés pour la connexion SSH, puisqu'il s'agit d'Ansible Automation Platform, vous n'avez pas besoin de tout faire manuellement. Toutes les étapes de configuration décrites ci-dessus peuvent être facilement automatisées à l'aide du module de modèle. Créez des modèles pour les fichiers de configuration /etc/security/access.conf, /etc/sssd/sssd.conf et /etc/ssh/sshd_config.

Faites preuve de prudence, car vous modifiez les paramètres de sécurité de connexion de votre hôte cible. Toute erreur peut entraîner l'échec du service sshd, accorder l'accès à des utilisateurs qui n'en ont pas besoin, etc. Vérifiez votre travail avant de propager les modifications.

Bien sûr, une bonne stratégie de sécurité ne peut pas reposer sur une configuration à réaliser une seule fois. La sécurisation de la configuration SSH de vos hôtes gérés est une étape importante d'un processus sans fin, et par ailleurs, Ansible Automation Platform le simplifie grandement.