Journalisation SSH et gestion des sessions à l'aide d'AWS SSM

Publié: 2022-03-11

La configuration d'outils ou de scripts personnalisés pour conserver un journal SSH sous Linux peut être fastidieuse et sujette aux erreurs.

Les ingénieurs peuvent utiliser rootsh , screen ou un autre utilitaire pour enregistrer l'activité de l'utilisateur, mais si les autorisations de l'utilisateur ne sont pas définies correctement, un utilisateur expérimenté peut effacer les journaux d'audit pour couvrir ses traces. Une autre option serait de configurer la journalisation au niveau du noyau, mais l'expertise nécessaire pour cela n'est pas si courante.

Heureusement, il existe un moyen de consigner l'activité des utilisateurs sans même écrire une seule commande Linux ! Nous aurons besoin de ces services :

  • EC2
  • IAM (gestion des identités et des accès)
  • KMS (Service de gestion des clés)
  • CloudWatch Logs (et/ou S3)
  • AWS Systems Manager (anciennement connu sous le nom de SSM)

Voyons comment configurer chacun d'eux.

EC2 et IAM

Le lancement d'une instance EC2 est normalement assez facile, mais il y a une tâche clé qui doit être effectuée lors du lancement : nous devons attacher un rôle IAM à notre instance, sinon nous ne pourrons pas obtenir les résultats attendus détaillés à la fin de ce document. article.

Le rôle IAM que nous associons à notre instance EC2 doit avoir la stratégie intégrée AmazonSSMManagedInstanceCore , plus cette stratégie (attachée en ligne ou gérée par le client) :

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

Outre le rôle IAM, nous utilisons généralement cette configuration d'instance EC2 :

  • Le système d'exploitation est Amazon Linux 2, car par défaut, il est fourni avec AWS Systems Manager Agent (SSM Agent) installé. (Il en va de même pour les distributions Ubuntu, qui sont également une option.)
  • Le type d'instance est t3.micro (mais n'importe quel type fera l'affaire).
  • Le groupe de sécurité par défaut qu'AWS attribue au VPC fonctionnera, car nous n'avons pas besoin d'un port SSH ouvert pour cet exercice.

Nous pouvons commencer à configurer KMS sans attendre le démarrage de l'instance EC2.

KMS

Nous avons besoin d'une clé KMS si nous voulons que tous les journaux de session livrés à CloudWatch soient stockés chiffrés. Passons au service KMS et créons une clé.

Une capture d'écran d'AWS avec le fil d'Ariane "KMS", "Clés gérées par le client" et "Créer une clé", actuellement à l'étape 1 : "Configurer la clé". Le "Type de clé" peut être défini sur "Symétrique" (sélectionné) ou "Asymétrique". Sous "Options avancées", le paramètre "Origine du matériel de clé" peut être "KMS" (sélectionné), "Externe" ou "Magasin de clés personnalisé (CloudHSM)".
Étape 1 : Choisir un type de clé symétrique.

Une capture d'écran d'AWS avec le même fil d'Ariane, maintenant à l'étape 2 : "Ajouter des étiquettes". Un champ Alias ​​est défini sur "cwlg", un champ Description facultatif est laissé vide et un champ Balises facultatif n'a pas de balises ajoutées.
Étape 2 : Nommer notre clé.

Une capture d'écran d'AWS avec le même fil d'Ariane, maintenant à l'étape 3 : "Définir les autorisations administratives clés". Le premier champ, "Administrateurs clés", a une zone de recherche vide avec 10 lignes de résultats (page 1 sur 3) avec des colonnes Nom, Chemin et Type. Seule la première ligne (avec les valeurs de colonne respectives "admin", "/" et "User") a sa case à cocher correspondante cochée. L'autre champ, "Suppression de clé", a une seule option, "Autoriser les administrateurs de clé à supprimer cette clé", dont la case est également cochée.
Étape 3 (facultative) : Affectation d'un administrateur.

Nous vous recommandons d'affecter un administrateur afin que la clé puisse être gérée par des utilisateurs autres que l'utilisateur racine du compte AWS, mais si d'autres n'ont pas besoin d'un accès, nous pouvons ignorer l'étape 3.

Ici, nous avons choisi l'utilisateur IAM "admin" comme administrateur clé, mais nous sommes libres de choisir n'importe quel utilisateur ou rôle. Nous pouvons également choisir de désactiver l'autorisation de suppression de clé pour l'administrateur.

Une capture d'écran d'AWS avec le même fil d'Ariane, maintenant à l'étape 4 : "Définir les autorisations d'utilisation des clés". Le premier champ, "Ce compte", contient les mêmes résultats de recherche qu'à l'étape 3, mais aucun d'entre eux n'est coché. L'autre champ, "Autres comptes AWS", n'a rien d'ajouté.
Étape 4 : Ignorer la page d'attribution d'utilisateur.

Nous n'attribuerons aucun utilisateur à cette clé, car nous voulons que cette clé soit utilisée uniquement par le service CloudWatch Logs pour les opérations de chiffrement et de déchiffrement des journaux SSH.

Une capture d'écran d'AWS avec le même fil d'Ariane, maintenant à l'étape 5 : "Révision". Le premier champ, "Configuration de la clé", répertorie le "Type de clé" comme "Symétrique", la "Spécification de la clé" comme "SYMMETRIC_DEFAULT", l'"Utilisation de la clé" comme "Crypter et déchiffrer" et l'"Origine" comme "AWS_KMS ." Le champ suivant, « Alias ​​et description », répertorie un alias, « cwlg », sans description. Le champ suivant, "Tags", n'affiche aucune donnée. Le dernier champ, "Politique de clé", comprend une zone de texte préremplie avec une politique au format JSON.
Étape 5 : Passez en revue notre configuration et échangez la stratégie de clé par défaut.

Sur la page Review, nous devrons modifier la stratégie de clé générée par KMS, car elle n'inclut pas les autorisations permettant à CloudWatch Logs d'utiliser la clé. Nous allons la remplacer par cette règle :

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

Assurez-vous de remplacer tous les espaces réservés :

  • ACCOUNT_ID devient notre ID de compte AWS.
  • USERNAME devient le nom d'utilisateur de l'administrateur sélectionné à l'étape 3. Si nous avons choisi de ne pas participer à cette étape, nous supprimons ici le deuxième bloc de déclaration (celui avec "Sid": "Allow access for Key Administrators" ).
  • REGION devient le code d'identification régional vers lequel nous déployons des services (par exemple, us-west-1 ).

Avec cela, KMS est prêt à fonctionner.

Groupe de journaux CloudWatch

Ensuite, nous avons besoin d'un groupe CloudWatch Log (et/ou d'un compartiment S3, voir ci-dessous) où l'agent SSM peut envoyer des journaux de session SSH. Créons-le.

Une capture d'écran d'AWS avec le fil d'Ariane "CloudWatch", "CloudWatch Logs", "Groupes de journaux" et "Créer un groupe de journaux". Il n'y a pas de barre latérale à plusieurs étapes. Le premier champ, "Détails du groupe de journaux", comporte trois sous-champs : "Nom du groupe de journaux" (défini sur "ssm-session-demo"), "Paramètre de rétention" (défini sur "Never expire" dans une liste déroulante) et « ARN clé KMS - facultatif » (défini sur une valeur tronquée commençant par « arn:aws:kms »). Le deuxième champ, "Tags", n'a pas de balises.
Création d'un groupe de journaux "CloudWatch Logs".

Notez le champ ARN de la clé KMS : AWS nous fournit la valeur nécessaire ici après la création de la clé à l'étape 5 de la section KMS.

(Si nous n'avons pas associé la stratégie correcte à notre clé KMS plus tôt, permettant au service CloudWatch Logs d'utiliser la clé, nous recevrons une erreur liée à la clé KMS à ce stade.)

Stockage des journaux SSH dans un compartiment S3

Pour stocker les journaux d'activité avec S3 au lieu ou en plus de CloudWatch Logs, nous devons ajouter ces autorisations à notre profil d'instance EC2 en tant que stratégie distincte (ou les combiner manuellement avec d'autres autorisations dont nous pourrions avoir besoin :

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

Dans l'extrait ci-dessus, veillez à remplacer l'espace réservé BUCKET_NAME .

Maintenant que nous avons configuré un endroit pour stocker les journaux (CloudWatch Logs, un compartiment S3 ou les deux), nous sommes prêts à exploiter les sessions SSH.

Gestionnaire de sessions AWS Systems Manager

Il s'agit de la dernière étape clé, où nous configurons un accès sécurisé à notre machine Linux pour la surveillance et la journalisation des sessions SSH. Nous allons commencer par le tableau de bord Session Manager.

Une capture d'écran du tableau de bord AWS Session Manager avec les sections "Comment ça marche", "Pourquoi utiliser Session Manager ?", "Mise en route", "Plus de ressources" et dans le coin supérieur droit, "Démarrer une session". Cette dernière section comporte un bouton orange "Démarrer la session" et un bouton blanc "Configurer les préférences".
Étape 1 : Premiers pas avec le tableau de bord.

Sur le tableau de bord, cliquez sur le bouton blanc "Configurer les préférences" dans la case "Démarrer une session" en haut à droite pour activer la journalisation de session.

Sur la page Préférences, nous trouverons plusieurs sections que nous pourrions explorer, mais notre objectif sera de diffuser les journaux de session SSH vers CloudWatch ou S3 pour nous permettre de voir rapidement ce qui se passe dans notre machine Linux.

Une capture d'écran d'une section AWS intitulée "CloudWatch logging". Son premier paramètre, également appelé "journalisation CloudWatch", comporte une case à cocher intitulée Activer qui est cochée. Le paramètre suivant, "Choisissez votre option de journalisation préférée", a "Streamer les journaux de session (recommandé)" sélectionné au lieu de "Télécharger les journaux de session". Le paramètre suivant, « Appliquer le chiffrement », comporte une case à cocher intitulée « Autoriser uniquement les groupes de journaux CloudWatch chiffrés » qui est cochée. Le paramètre final, "Groupe de journaux CloudWatch", a "Choisissez un nom de groupe de journaux dans la liste" sélectionné au lieu de "Entrez un groupe de journaux dans la zone de texte". En dessous se trouve une liste, "Groupes de journaux CloudWatch", avec "ssm-session-demo" sélectionné. Il a les colonnes correspondantes "Cryptage" (défini sur "Chiffré"), "Expirer les événements après" (défini sur "N'expire jamais"), "Filtres de métrique" (défini sur 0), "Octets stockés" (défini sur 0) et un horodatage "Heure de création".
Étape 2a : Activation de la journalisation CloudWatch.

Juste après la section "CloudWatch logging", il y a une section "S3 logging" où nous pouvons sélectionner le bucket.

Une capture d'écran d'une section AWS intitulée « Journalisation S3 ». Son premier paramètre, "Envoyer les journaux de session à S3", comporte une case à cocher intitulée "Activer" qui est cochée. Son paramètre suivant, "Appliquer le chiffrement", comporte une case à cocher intitulée "Autoriser uniquement les compartiments S3 chiffrés" qui est cochée. Son paramètre suivant, "Choisir un compartiment S3", a "Choisir un nom de compartiment dans la liste" sélectionné au lieu de "Entrez un nom de compartiment dans la zone de texte". En dessous, "ssm-session-demo" est sélectionné dans une liste déroulante. Le dernier champ, "Préfixe de clé S3 - facultatif", est vide.
Étape 2b : Activation de la journalisation S3.

Une fois la journalisation SSH configurée, nous pouvons nous connecter en SSH à notre machine Linux et exécuter certaines commandes pour voir si l'activité est capturée ou non.

Alors, commençons une session. Sur la même page, nous trouverons un onglet "Sessions" où nous pourrons démarrer une session. Cliquer sur le bouton "Démarrer la session" nous donnera une liste des machines EC2 sur lesquelles nous pouvons initier une session :

Une capture d'écran d'AWS avec des fils d'Ariane AWS Systems Manager, Session Manager et Démarrer une session. Une zone de recherche "Instances cibles" n'a pas de requête remplie et un seul résultat, avec "Nom de l'instance" défini sur "Démo SSM".
Étape 3 : Sélection de notre instance EC2 avec laquelle démarrer une session SSH.

Si nous ne voyons pas notre instance EC2 Linux dans la liste, nous devons vérifier si elle est en cours d'exécution et si elle est associée aux autorisations IAM que nous avons décrites précédemment.

Gestion d'une erreur de l'agent SSM "Ne prend pas en charge les journaux de diffusion"

Si nous recevons une erreur indiquant que la version de l'agent SSM installée sur notre machine EC2 ne prend pas en charge la diffusion des journaux CloudWatch, ne vous inquiétez pas. Il existe un moyen indolore de résoudre ce problème.

Une capture d'écran d'un message d'erreur AWS avec du texte blanc sur fond rouge. Un X encerclé se trouve à côté du message : "La version de l'Agent SSM installée sur cette instance ne prend pas en charge la diffusion des journaux vers CloudWatch. Mettez à jour l'Agent SSM vers la dernière version ou désactivez l'option de diffusion des journaux dans vos préférences."
Une erreur potentielle "version obsolète de l'agent SSM".

Pour mettre à jour l'agent SSM, nous devons accéder à Exécuter la commande dans le panneau de gauche du service AWS Systems Manager .

Une capture d'écran du tableau de bord AWS Systems Manager Run Command avec les sections « Comment ça marche », « Fonctionnalités et avantages », « Cas d'utilisation et articles de blog », « Documentation » et dans le coin supérieur droit, « Gérer vos instances ». Cette section ne contient qu'un bouton orange "Exécuter une commande".
Étape 1 : Commencer par le tableau de bord « Exécuter la commande ».

Une fois que nous y sommes, nous pouvons cliquer sur le bouton orange "Exécuter une commande", menant à une nouvelle page où nous pouvons remplir certains paramètres.

Une capture d'écran d'AWS avec le fil d'Ariane AWS Systems Manager, Exécuter la commande et Exécuter une commande. Une zone de recherche intitulée « Document de commande » répertorie 10 lignes (page 4 sur plus de 5), avec une nommée « AWS-UpdateSSMAgent » sélectionnée. Il a "Amazon" dans sa colonne "Propriétaire" et "Windows, Linux" dans sa colonne "Types de plate-forme". Un champ en bas, "Version du document", a "1 (par défaut)" sélectionné dans une liste déroulante.
Etape 2 : Sélection d'un document de commande.

Nous commencerons par sélectionner AWS-UpdateSSMAgent dans la liste.

Une capture d'écran d'une section AWS intitulée "Cibles". Le premier champ, également appelé "Cibles", contient les options "Spécifier les balises d'instance", "Choisir les instances manuellement" (sélectionnées) et "Choisir un groupe de ressources". En bas se trouve une zone de recherche "Instances" sans requête, avec son seul résultat, "SSM Demo", coché. L'ID d'instance correspondant dans la ligne est copié dans une zone juste au-dessus de "Instances" avec un X.
Étape 3 : Sélection de l'instance EC2 qui a un agent SSM nécessitant une mise à jour.

Une fois que cela est sélectionné, nous allons faire défiler jusqu'à ce que nous voyions la section "Cibles". Là, nous devons sélectionner l'instance EC2 sur laquelle nous voulons mettre à jour l'agent SSM, puis appuyer sur le bouton "Exécuter" à la fin. Cela nous enverra vers une page où nous pourrons suivre la progression de la mise à jour.

Une capture d'écran d'AWS avec le fil d'Ariane "AWS Systems Manager", "Exécuter la commande" et "ID de commande" (suivi d'un GUID). La première section, "État de la commande", affiche les indicateurs de réussite, tout comme la seule ligne de la section suivante, "Cibles et résultats", qui répertorie l'instance unique de la précédente. Il existe également deux sections non développées en bas, "Description de la commande" et "Paramètres de la commande".
Étape 4 : Suivi de la progression de nos mises à jour.

La mise à jour de l'agent ne devrait pas prendre plus de cinq minutes. Une fois cela fait, nous devrions pouvoir recréer une session dans le gestionnaire de session.

À ce stade, nous devrions avoir démarré une session SSH.

Une capture d'écran d'AWS avec un ID de session et un ID d'instance au-dessus d'un terminal. L'invite est "sh-4.2$" et les commandes "whoami" et "pwd" ont été entrées, avec les sorties "ssm-user" et "/usr/bin" respectivement.
Une session SSH utilisant l'agent SSM via AWS Systems Manager Session Manager.

Après avoir exécuté quelques commandes, naviguons vers le groupe de journaux CloudWatch Logs (ou notre compartiment S3, non affiché) et confirmons que l'activité est en cours d'enregistrement.

Une capture d'écran d'AWS avec le fil d'Ariane "CloudWatch", "CloudWatch Logs", "Groupes de journaux", "ssm-session-demo" et l'ID de session de l'étape précédente. La seule section est une zone de recherche, "Événements du journal", avec des lignes qui ont chacune un horodatage et un message au format JSON. L'un d'eux est agrandi pour révéler son JSON joliment imprimé et avec un bouton blanc à droite intitulé "Copier".
Événements de journal SSH enregistrés dans CloudWatch Logs.

Nous avons maintenant une configuration, avec le chiffrement au repos activé, enregistrant chaque commande lancée dans notre machine Linux.

En fait, chaque commande peut être plus que ce que nous voulons : tous les secrets fournis ou générés pendant la session seront enregistrés dans CloudWatch ou S3 et peuvent être vus par toute personne disposant des autorisations requises. Pour éviter cela, nous pouvons utiliser stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; pour chaque secret que nous devons fournir pendant la session.

Une excellente solution de journalisation AWS SSM/SSH avec des mises en garde mineures

Session Manager est un outil utile pour accéder à distance à nos machines virtuelles dans AWS sans avoir à ouvrir le port 22. En fait, nous ne pouvons pas générer de journaux SSH de cette façon si nous utilisons la redirection de port ou une connexion SSH directe, comme le Session Manager notices documentaires.

Néanmoins, la combinaison de Session Manager avec la journalisation de session est une solution robuste pour contrôler et surveiller l'activité au sein des machines virtuelles. De plus, nous ne sommes pas facturés pour l'utilisation du service Session Manager. Nous ne payons que pour notre instance EC2 et CloudWatch Logs ou un compartiment S3 pour le stockage des journaux.

Pour les lecteurs qui préfèrent les didacticiels vidéo, j'ai couvert un peu plus en détail une procédure très similaire sur YouTube.

Lectures complémentaires sur le blog Toptal Engineering :

  • Étude de cas : Pourquoi j'utilise AWS Cloud Infrastructure pour mes produits