Limitation de l'accès aux commandes de niveau racine via l'SSM Agent

AWS Systems Manager L'agent (SSM Agent) s'exécute sur les instances Amazon Elastic Compute Cloud (AmazonEC2) et sur d'autres types de machines dans des environnements hybrides et multicloud à l'aide des autorisations root (Linux) ou SYSTEM des autorisations (Windows Server). Comme il s'agit du niveau le plus élevé d'autorisations d'accès au système, toute entité de confiance autorisée à qui l'on a accordé l'autorisation d'envoyer des commandes SSM Agent possède un accès root ou SYSTEM des autorisations. (Dans AWS, une entité de confiance qui peut effectuer des actions et accéder à des ressources AWS est appelée principale. Un principal peut être un Utilisateur racine d'un compte AWS, un utilisateur ou un rôle.)

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 peut être fait dans la IAM politique assignée au principal. Dans la IAM politique, vous pouvez inclure une condition qui limite l'utilisateur à exécuter des commandes uniquement sur les nœuds gérés marqués par des balises spécifiques ou une combinaison 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 IAM politique appliquée aux ingénieurs débutants, vous spécifiez qu'ils ne peuvent exécuter des commandes que sur des instances étiquetées avecssm: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.

En utilisant cette approche, si les ingénieurs débutants tentent d'exécuter une commande sur une instance de production, l'accès leur sera refusé car la IAM politique qui leur est attribuée ne fournit pas un accès explicite aux instances étiquetées avecssm:resourceTag/productionServer.

Pour de plus amples informations et d'exemples, consultez les rubriques suivantes :