Établissez une connexion à distance avec vos instances AWS

Introduction

Dans mon article précédent, nous avons discuté de la connexion aux instances EC2 à l'aide des EC2 Instance Connect EndPoints, également appelés "EICE", et de leur simplicité et sécurité d'utilisation. Cependant, AWS propose un autre service qui facilite la connexion sécurisée aux instances EC2 privées. Ce service s'appelle AWS Systems Manager Session Manager et constitue une fonctionnalité du service AWS Systems Manager.

Dans cet article, nous allons explorer une architecture qui utilise AWS Systems Manager Session Manager, comment garantir sa sécurité et comment l'utiliser. Nous allons créer un exemple pour rendre l'ensemble du scénario plus compréhensible. À la fin de cet article, vous serez en mesure d'établir une connexion à une instance EC2 privée en utilisant le service AWS Systems Manager Session Manager.

Nous examinerons un environnement sans VPN ni appliance physique de sécurité, où ni adresse IP publique, passerelle NAT, ni sous-réseau public ne sont utilisés.

💡

Avertissement

Les approches suivantes pourraient ne pas être recommandées pour une utilisation au sein d'entreprises nécessitant des normes de sécurité élevées, où l'utilisation d'appliances physiques est la norme et obligatoire. Bien que la solution proposée soit très sécurisée, il est toujours préférable de discuter de tout projet avec votre responsable de la sécurité, de partager des informations avec vos collègues et de veiller à ce que tout le monde comprenne la mise en œuvre envisagée. Il est également important de garder à l'esprit que, comme le disent souvent beaucoup : ne vous y trompez pas, il n'existe pas de systèmes invulnérables - c'est une question de connaissances, de temps, d'argent et d'efforts.

Challenge existant

Risques, limites et désavantages...

La connexion à une instance EC2 peut parfois impliquer le choix de méthodes apparemment pratiques qui, en réalité, peuvent introduire des vulnérabilités de sécurité significatives. Ces méthodes peuvent inclure l'attribution d'une adresse IP publique à l'instance EC2 ou même la configuration d'un bastion host publique.

Risques des adresses IP publiques

Dans mon article précédent, nous avons discuté des risques liés à l'utilisation des adresses IP publiques et pourquoi elles devraient être évitées. L'utilisation d'adresses IP publiques pour la connexion aux instances EC2 dans le Cloud comporte des risques élevés de sécurité, exposant directement les instances à Internet et les rendant vulnérables à des attaques. Même l'authentification par paires de clés RSA ne suffit pas à garantir la sécurité.

De plus, il existe des limitations sur le nombre d'adresses IP publiques autorisées par AWS dans un compte et une région spécifiques. En outre, à partir du 1er février 2024, AWS commencera à facturer l'utilisation des adresses IPv4, ce qui entraînera des coûts, même pour les adresses inactives. Il est donc recommandé d'éviter cette pratique en faveur de méthodes plus sécurisées.

Risques liés à l'utilisation des bastions

Une alternative serait de configurer des bastions publics. Bien que certains les utilisent fréquemment comme passerelle d'accès aux instances EC2, les organisations les évitent généralement en raison de plusieurs facteurs clés, les considérant avec prudence.

Tout d'abord, ils introduisent de la complexité dans l'infrastructure, car leur maintenance et leur sécurisation peuvent poser des problèmes administratifs. De plus, les bastions présentent des risques de sécurité, car toute vulnérabilité ou mauvaise configuration peut les transformer en un point de défaillance unique que les pirates peuvent exploiter pour obtenir un accès non autorisé.

Enfin, leur surcharge opérationnelle, y compris la nécessité d'une surveillance continue et d'une maintenance, peut être chronophage et potentiellement perturber les procédures de réponse aux incidents, incitant les organisations à rechercher des méthodes alternatives plus sécurisées et efficaces pour l'accès aux ressources.

Approche recommandée

Meilleures pratiques pour assurer...

AWS Systems Manager Session Manager n'est pas un nouveau service; il est largement utilisé par les entreprises qui souhaitent garantir des connexions sécurisées. AWS Systems Manager Session Manager renforce la sécurité d'accès aux instances avec une web-interface et un interpréteur de commandes (CLI), éliminant ainsi le besoin de ports ouverts ou de serveurs d'accès. De plus, il simplifie la gestion des clés SSH en permettant aux administrateurs de gérer l'accès via des politiques IAM, autorisant ou révoquant les permissions de manière centralisée.

Principales caractéristiques et avantages

AWS Systems Manager Session Manager offre une approche sécurisée et rationalisée pour la gestion à distance des instances AWS. Voici les principales fonctionnalités qui en font un outil précieux pour un accès efficace et sécurisé aux instances :

Accès distant sécurisé : Accès direct et sécurisé aux instances AWS sans ports ouverts.
Journal d'audit : Enregistre toutes les activités de session pour la conformité et la surveillance.
Intégration IAM : Contrôle d'accès basé sur les rôles via IAM pour l'initiation de sessions.
Communication chiffrée : Assure la confidentialité et l'intégrité des données.
Enregistrement des sessions : Capture la sortie des sessions pour l'analyse.
Pas de bastion : Élimine le besoin d'un serveur intermédiaire.
Documents SSM personnalisés : Prise en charge de documents personnalisés pour un contrôle de session flexible.
Prise en charge de Windows et Linux : Fonctionne de manière transparente avec les deux types de systèmes d'exploitation.
Politiques de terminaison de session : Termine automatiquement les sessions inactives.
Journaux de conformité : Journaux détaillés pour la conformité réglementaire.

Architecture de base

La mise en œuvre d'un environnement en utilisant SSM n'est pas aussi simple que beaucoup peuvent le penser. Plusieurs ressources doivent être créées et correctement configurées pour le faire fonctionner de manière sécurisée. Nous utiliserons AWS System Manager Session Manager, plusieurs VPC endpoints, des instances EC2, des groupes de sécurité, des rôles IAM, des politiques IAM, des clés KMS, IAM Instance Profile, un groupe AWS CloudWatch, etc.

Outre les ressources mentionné précédemment, AWS Systems Manager Session Manager nécessite qu'une application soit installée sur le client, qui établira la connexion avec l'instance cible. Cette application s'appelle: session-manager-plugin

Connexion à une instance EC2 à l'aide du AWS SSM

Conditions préalables

Cependant, avant d'approfondir le cas d'utilisation, nous devons nous assurer d'installer le session-manager-plugin si vous ne l'avez jamais installé auparavant. Pour ce faire, exécutez les commandes suivantes :

curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/ubuntu_64bit/session-manager-plugin.deb" -o "session-manager-plugin.deb"
sudo dpkg -i session-manager-plugin.deb

Vérifiez l'installation et la version du plugin. Vous devriez avoir au moins la version : 1.2.536.0

session-manager-plugin --version

Étude de cas avec les bonnes pratiques

Mettons tout cela en pratique...

Pour illustrer, nous allons mettre en œuvre un exemple avec une instance EC2 dans un sous-réseau privé protégé par un groupe de sécurité.

Dans cette architecture, nous observons l'utilisation d'une instance EC2 comme cible, derrière un groupe de sécurité dans un sous-réseau privé. L'instance a un Instance Profile attaché avec un rôle contenant des politiques IAM autorisant l'utilisation de la connexion via SSM. Dans cette architecture, nous avons déployé 3 VPC endpoints pour permettre la connexion avec SSM - sans eux, vous ne pourrez pas vous connecter. Les VPC endpoints sont derrière un groupe de sécurité, qui est différent du groupe de sécurité de l'instance EC2.

Architecture détaillée pour la connexion aux instances EC2 à l'aide de AWS SSM

Il y a 2 groupes de sécurité et le flux permet uniquement le port 443 du groupe de sécurité du VPC endpoint vers le groupe de sécurité de l'instance EC2.

Aucune adresse IP publique n'est utilisée, et la plage d'adresses IP de destination pour demo-sg-A pourrait éventuellement être encore plus restreinte.

Une fois l'infrastructure déployée, il est nécessaire de déployer les paramètres par défaut du AWS Session Manager. Vous pouvez utiliser un fichier modèle JSON que vous nommerez "SessionManagerRunShell.json" :

{
    "schemaVersion": "1.0",
    "description": "Document to hold regional settings for Session Manager",
    "sessionType": "Standard_Stream",
    "inputs": {
        "s3BucketName": "",
        "s3KeyPrefix": "",
        "s3EncryptionEnabled": false,
        "cloudWatchLogGroupName": "",
        "cloudWatchEncryptionEnabled": false,
        "cloudWatchStreamingEnabled": false,
        "kmsKeyId": "",
        "runAsEnabled": false,
        "runAsDefaultUser": "",
        "idleSessionTimeout": "20",
        "maxSessionDuration": "",
        "shellProfile": {
            "windows": "",
            "linux": ""
        }        
    }
}

Utilisez la commande pour déployer le document sur AWS, qui contient les préférences par défaut du AWS Session Manager. Vous n'avez à le faire qu'une seule fois, à moins que vous modifiiez les paramètres par défaut. Dans ce cas, vous devrez redéployer le document:

Notez que si vous déployez un document défaut de paramètres de session pour la première fois dans le compte, utilisez la commande create-document. Si un document défaut de paramètres de session a déjà été déployé ou si vous avez déjà configuré quelque chose dans la console AWS dans les paramètres du Session Manager, utilisez la commande update-document.

aws ssm create-document \
    --name SSM-SessionManagerRunShell \
    --content "file://./SessionManagerRunShell.json" \
    --document-type "Session" \
    --document-format JSON

Utilisez cette commande pour un premier déploiement du document

aws ssm update-document \
    --name "SSM-SessionManagerRunShell" \
    --content "file://./SessionManagerRunShell.json" \
    --document-version "\$LATEST"

Utilisez cette commande si un document a déjà été déployé une fois

Utilisez la commande suivante pour démarrer une nouvelle session ciblant l'instance EC2 en utilisant les paramètres par défaut de SSM :

aws ssm start-session --target $EC2ID

Amélioration de l’approche

Comment pourrions-nous rendre cette architecture plus sécurisée ?

Conditions préalables

Cependant, avant d'approfondir ce cas d'utilisation, nous devons vérifier si l'agent CloudWatch est correctement installé sur l'instance EC2 cible. Cela peut être réalisé en utilisant la commande suivante. Vous devriez avoir au moins la version 3.2.1705.0. Effectuez la commande suivante pour le vérifier:

aws ssm describe-instance-information \
  --instance-information-filter-list '[{"key":"InstanceIds","valueSet":["'$EC2IDA'"]}]' \
  --query 'InstanceInformationList[0].AgentVersion'

Architecture plus sécurisée

Pour l'architecture suivante, nous avons ajouté quelques fonctionnalités : toutes les sessions sont enregistrées dans les journaux CloudWatch, et elles sont chiffrées avec KMS. Le volume EBS de l'instance EC2 est également chiffré avec KMS. Nous avons renforcé la sécurité en ajoutant 2 VPC endpoints (un pour les journaux CloudWatch et l'autre pour KMS), qui passent désormais en interne dans notre réseau. Enfin, la session créée avec AWS SSM est également chiffrée à l'aide de notre propre clé KMS.

Architecture détaillée pour la connexion aux instances EC2 à l'aide d'AWS SSM, avec volume, journaux et session chiffrés.

Pas de modifications pour les groupes de sécurité. Tout a été pris en considération.

Aucune adresse IP publique n'est utilisée et la plage d'adresses de destination du demo-sg-A pourrait éventuellement être encore plus restreinte

Pour la nouvelle architecture, nous devrons apporter quelques modifications au fichier SessionManagerRunShell.json. Nous devrons activer le chiffrement CloudWatch et le chiffrement SSM. Consultez le fichier avec les modifications ci-dessous :

{
    "schemaVersion": "1.0",
    "description": "Document to hold regional settings for Session Manager",
    "sessionType": "Standard_Stream",
    "inputs": {
        "s3BucketName": "",
        "s3KeyPrefix": "",
        "s3EncryptionEnabled": false,
        "cloudWatchLogGroupName": "/SSMLogs",
        "cloudWatchEncryptionEnabled": true,
        "cloudWatchStreamingEnabled": false,
        "kmsKeyId": "alias/mykey-logs",
        "runAsEnabled": false,
        "runAsDefaultUser": "",
        "idleSessionTimeout": "20",
        "maxSessionDuration": "",
        "shellProfile": {
            "windows": "",
            "linux": ""
        }        
    }
}

Notez que nous avons modifié 3 paramètres :

"cloudWatchEncryptionEnabled": true
"cloudWatchLogGroupName": "/SSMLogs"
"kmsKeyId": "alias/mykey-logs"

Le paramètre cloudWatchEncryptionEnabled forcera le chiffrement lors de l'enregistrement des journaux dans le groupe cloudWatchLogGroupName. Enfin, le paramètre kmsKeyId garantira que SSM utilise le chiffrement KMS pour la connexion en utilisant l'ID de clé sélectionné dans ce paramètre.

Pour vous assurer que les paramètres sont pris en compte, il est nécessaire de mettre à jour le document SSM-SessionManagerRunShell.json en utilisant la commande suivante:

Notez que si vous déployez un document défaut de paramètres de session pour la première fois dans le compte, utilisez la commande create-document. Si un document défaut de paramètres de session a déjà été déployé ou si vous avez déjà configuré quelque chose dans la console AWS dans les paramètres du Session Manager, utilisez la commande update-document.

aws ssm create-document \
    --name SSM-SessionManagerRunShell \
    --content "file://./SessionManagerRunShell.json" \
    --document-type "Session" \
    --document-format JSON

Utilisez cette commande pour un premier déploiement du document

aws ssm update-document \
    --name "SSM-SessionManagerRunShell" \
    --content "file://./SessionManagerRunShell.json" \
    --document-version "\$LATEST"

Utilisez cette commande si un document a déjà été déployé une fois

Démarrer une nouvelle session pour vérifier si la session SSM est chiffrée :

aws ssm start-session --target $EC2ID

La session indiquera qu'elle sera chiffrée avec AWS KMS:

connexion à EC2 avec SSM via terminal et AWS CLI

Si la session est créée via la console AWS, la notification sera également affichée:

connexion à EC2 avec SSM via AWS Console

Une fois la session créée, elle peut être visualisée dans la section "Session Manager" de la console AWS.

AWS Session Manager affiche les instances connectées dans la console AWS

Ainsi, vous pouvez facilement trouver le lien correspondant vers CloudWatch pour les journaux de session.

AWS Session Manager affiche la session terminée avec un lien vers CloudWatch pour les journaux

Dans CloudWatch Logs, il serait possible de voir les actions de l'utilisateur dans la session respective.

CloudWatch "SSMLogs" affichant les commandes de journal d'une session spécifique

Traitement des incidents

Il existe une erreur identifiée dans l'AWS CLI selon le dépôt officiel AWS Git pour AWS CLI (https://github.com/aws/aws-cli/issues/6218). La session SSM peut être créée via le navigateur, mais elle génère une erreur dans AWS CLI :

❗

----------ERROR------- Encountered error while initiating handshake. KMSEncryption failed on client with status 2 error: Failed to process action KMSEncryption: error while creating new KMS service, Error creating new aws sdk session CredentialRequiresARNError: credential type source_profile requires role_arn, profile xxx

Cette erreur peut être résolue via l'application awsume. Il s'agit d'une solution palliative en attendant qu'une solution officielle soit déployée et partagée. Il vous suffit de l'installer et d'exécuter la commande comme décrit ci-dessous :

pip install awsume
alias awsume=". awsume"
awsume <<YOUR PROFILE NAME>>

Dans l'image ci-dessous, la séquence de l'erreur et la solution palliative via la commande awsume. Dans ce cas, mon profil s'appelle "cloudguru", mais vous devez entrer le nom de votre profil utilisé pour votre compte/rôle cible

Conclusion

En résumé, AWS SSM offre une méthode efficace et sécurisée pour gérer les connexions aux instances EC2, que ce soit via AWS CLI ou la console AWS. L'accent mis sur la sécurité est évident : seuls le port TCP 443 est autorisé et aucune adresse IP publique n'est utilisée, avec une majorité des communications transitant via des connexions privées et des VPC endpoints. Bien que les VPC endpoints impliquent certains coûts, ils jouent un rôle crucial dans le renforcement de la sécurité.

Il est important de noter un léger problème avec le handshake des connexions SSM utilisant KMS via AWS CLI, mais la solution temporaire avec la bibliothèque awsume est simple et efficace. Aucun problème similaire n'a été observé lors de l'utilisation de la console AWS.

Cette approche démontre que, même avec des niveaux de sécurité élevés, une mise en œuvre efficace et sécurisée est possible. Cependant, il est toujours conseillé de collaborer étroitement avec les équipes de sécurité pour s'assurer que l'approche choisie est adaptée aux besoins spécifiques de votre projet.

Pour plus de détails et des conseils adaptés à vos besoins spécifiques, je vous encourage à consulter les références fournies.