Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Limitation de l'accès aux commandes de niveau racine via l'SSM Agent
L'agent AWS Systems Manager (SSM Agent) s'exécute sur les instances Amazon Elastic Compute Cloud (Amazon EC2) et d'autres types d'ordinateurs dans des environnements hybrides et multicloud en utilisant les autorisations root (Linux) ou SYSTEM (Windows Server). Parce qu'elles représentent le plus haut niveau de privilèges d'accès au système, toute entité approuvée qui a reçu l'autorisation d'envoyer des commandes à l'SSM Agent possède des autorisations racine ou SYSTEM. (Dans AWS, les entités approuvées qui peuvent effectuer des actions et accéder aux ressources dans AWS s'appellent principaux. Un principal peut être un utilisateur, un rôle ou un Utilisateur racine d'un compte AWS.)
Ce niveau d'accès est nécessaire à un mandataire pour qu'il puisse envoyer des commandes Systems Manager autorisées pour l'SSM Agent, mais il permet également à un principal d'exécuter des codes malveillants en exploitant d'éventuelles vulnérabilités dans l'SSM Agent.
En particulier, les autorisations nécessaires pour exécuter les commandes SendCommand et StartSession doivent être soigneusement restreintes. Une première étape judicieuse consiste à accorder les autorisations à chaque commande uniquement pour sélectionner les principaux dans votre organisation. Toutefois, nous vous recommandons de renforcer votre posture de sécurité en limitant les nœuds gérés sur lesquels un principal peut exécuter ses commandes. Cela est possible dans la politique IAM affectée au principal. Dans la politique IAM, vous pouvez inclure une condition qui limite l'utilisateur à l'exécution de commandes uniquement sur les nœuds gérés balisés à l'aide de balises spécifiques ou de combinaisons de balises.
Par exemple, supposons que vous avez deux parcs de serveurs, l'un à des fins de test, l'autre à des fins de production. Dans la politique IAM appliquée aux jeunes ingénieurs, vous spécifiez qu'ils peuvent exécuter des commandes uniquement sur les instances balisées avec ssm:resourceTag/testServer. Mais, pour un plus petit groupe d'ingénieurs principaux, qui doivent avoir accès à toutes les instances, vous accordez l'accès aux instances balisées avec ssm:resourceTag/testServer ou ssm:resourceTag/productionServer.
Avec cette approche, si de jeunes ingénieurs essaient d'exécuter une commande sur une instance de production, l'accès leur est refusé car la politique IAM qui leur est affectée ne fournit pas un accès explicite aux instances balisées avec ssm:resourceTag/productionServer.
Pour de plus amples informations et d'exemples, consultez les rubriques suivantes :
