Découvrez les détails techniques du SSM Agent

Utilisez les informations de cette rubrique pour vous aider à implémenter AWS Systems Manager Agent (SSM Agent) et à comprendre le fonctionnement de l'agent.

Rubriques

• Comportement des informations d'identification SSM Agent version 3.2.x.x
• SSM AgentPriorité des informations d'identification de l'
• À propos du compte local ssm-user
• SSM Agent et le Instance Metadata Service (IMDS)
• Garder SSM Agent up-to-date
• S’assurer que le répertoire d’installation SSM Agent ne soit pas modifié, déplacé ou supprimé
• SSM Agentmises à jour continues par Régions AWS
• Communications de l'SSM Agent avec des compartiments S3 gérés par AWS
• Rechercher AMIs avec le SSM Agent préinstallé
• Utilisation de SSM Agent sur des instances EC2 pour Linux
• Utilisation de SSM Agent sur des instances EC2 pour macOS
• Utilisation de SSM Agent sur des instances EC2 pour Windows Server
• Vérification du statut de l'SSM Agent et démarrage de l'agent
• Vérification du numéro de version de l'SSM Agent
• Affichage des journaux SSM Agent
• Limitation de l'accès aux commandes de niveau racine via l'SSM Agent
• Automatisation des mises à jour de l'SSM Agent
• Abonnement aux notifications SSM Agent

Comportement des informations d'identification SSM Agent version 3.2.x.x

SSM Agent stocke un ensemble d'informations d'identification temporaires dans /var/lib/amazon/ssm/credentials (pour Linux et macOS) ou %PROGRAMFILES%\Amazon\SSM\credentials (pour Windows Server) lorsqu'une instance est intégrée à l'aide de la configuration de gestion d'hôte par défaut dans Quick Setup. Les informations d'identification temporaires disposent des autorisations que vous avez spécifiées pour le rôle IAM que vous avez choisi pour la configuration de la gestion de l'hôte par défaut. Sous Linux, seul le compte root peut accéder à ces informations d'identification. Sous Windows Server, seuls le compte SYSTEM et les Administrateurs locaux peuvent accéder à ces informations d'identification.

SSM AgentPriorité des informations d'identification de l'

Cette rubrique décrit des informations importantes sur la façon dont l'SSM Agent est autorisé à exécuter des actions sur vos ressources.

Note

La prise en charge des appareils de périphérie est légèrement différente. Vous devez configurer vos appareils Edge pour utiliser le logiciel AWS IoT Greengrass Core, configurer un rôle de service AWS Identity and Access Management (IAM) et déployer sur vos appareils SSM Agent à l'aide AWS IoT Greengrass de. Pour plus d’informations, consultez Gestion des appareils de pointe avec Systems Manager.

Quand SSM Agent est installé sur une machine, il a besoin d'autorisations pour communiquer avec le service Systems Manager. Sur les instances Amazon Elastic Compute Cloud (Amazon EC2), ces autorisations sont fournies dans un profil d'instance attaché à l'instance. Sur une machine non EC2, SSM Agent obtient normalement les autorisations nécessaires à partir du fichier d'informations d'identification partagées qui se trouve dans /root/.aws/credentials (Linux et macOS) ou %USERPROFILE%\.aws\credentials (Windows Server). Les autorisations nécessaires sont ajoutées à ce fichier durant le processus d'activation hybride.

Dans de rares cas, cependant, des autorisations peuvent être ajoutées à une machine, à un plus grand nombre d'emplacements que ceux où SSM Agent vérifie les autorisations pour exécuter ses tâches.

Par exemple, imaginons que vous ayez configuré une instance EC2 de sorte qu'elle soit gérée par Systems Manager. Cette configuration inclut l'attachement d'un profil d'instance. Mais vous décidez ensuite d'utiliser cette instance pour les tâches de développeur ou d'utilisateur final, et d'installer l' AWS Command Line Interface (AWS CLI) par-dessus. Dans ce cas, des autorisations supplémentaires sont ajoutées à un fichier d'informations d'identification sur l'instance.

Lorsque vous exécutez une commande Systems Manager sur l'instance, l'SSM Agent peut tenter d'utiliser des informations d'identification différentes de celles que vous pensez qu'il va utiliser, par exemple à partir d'un fichier d'informations d'identification et non d'un profil d'instance. Cela est dû au fait que l'SSM Agent recherche les informations d'identification dans l'ordre prescrit pour la chaîne de fournisseur d'informations d'identification par défaut.

Note

Sous Linux et macOS, l'SSM Agent s'exécute en tant qu'utilisateur racine. Par conséquent, les variables d'environnement et le fichier d'informations d'identification que SSM Agent recherche dans ce processus sont ceux de l'utilisateur root uniquement (/root/.aws/credentials). SSM Agent n'examine pas les variables d'environnement ou le fichier d'informations d'identification d'autres utilisateurs sur l'instance lorsqu'il recherche des informations d'identification.

La chaîne de fournisseur par défaut recherche des informations d'identification dans cet ordre :

1. Variables d'environnement, si elles sont configurées (AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY).

2. Fichier d'informations d'identification partagées ($HOME/.aws/credentials pour Linux et macOS ou %USERPROFILE%\.aws\credentialspour Windows Server) avec les autorisations fournies, par exemple, par une activation hybride ou une installation de la AWS CLI .

3. Rôle AWS Identity and Access Management (IAM) pour les tâches en présence d'une application utilisant une définition RunTask de tâche ou une opération d'API Amazon Elastic Container Service (Amazon ECS).

4. Un profil d'instance IAM attaché à une instance Amazon EC2

5. Le rôle IAM choisi pour la configuration de la gestion de l'hôte par défaut.

Pour plus d'informations, consultez les rubriques connexes suivantes :

• Profils d'instance pour les instances EC2 : configurez les autorisations d'instance requises pour Systems Manager

• Activations hybrides — Créez une activation hybride pour enregistrer les nœuds auprès de Systems Manager

• AWS CLI informations d'identification — Configuration et paramètres des fichiers d'identification dans le guide de l'AWS Command Line Interface utilisateur

• Chaîne de fournisseur d'informations d'identification par défaut : Spécification d'informations d'identification dans le Manuel du développeur AWS SDK for Go

  Note

  Cette rubrique du Manuel du développeur AWS SDK for Go décrit la chaîne de fournisseur par défaut en termes de SDK for Go. Les mêmes principes s'appliquent toutefois à l'évaluation des informations d'identification pour SSM Agent.

À propos du compte local ssm-user

À partir de la version 2.3.50.0 de l'SSM Agent, l'agent crée un compte utilisateur local appelé ssm-user et l'ajoute au répertoire /etc/sudoers.d (Linux et macOS) ou au groupe Administrateurs (Windows Server). Sur les versions de l'agent antérieures à 2.3.612.0, le compte est créé la première fois que l'SSM Agent démarre ou redémarre après l'installation. Sur la version 2.3.612.0 et version ultérieure, le compte ssm-user est créé la première fois qu'une session est démarrée sur une instance. Il s'ssm-useragit de l'utilisateur du système d'exploitation par défaut lorsqu'une session démarreSession Manager, une fonctionnalité de AWS Systems Manager. Vous pouvez modifier les autorisations de l'utilisateur ssm-user en le déplaçant vers un groupe ayant moins de privilèges ou en modifiant le fichier sudoers. Le compte ssm-user n'est pas supprimé du système lorsque l'SSM Agent est désinstallé.

Sur Windows Server, l'SSM Agent gère la définition d'un nouveau mot de passe pour le compte ssm-user lorsque chaque session commence. Aucun mot de passe n'est défini pour ssm-user sur des instances gérées Linux.

À partir de la version SSM Agent 2.3.612.0, le compte ssm-user n'est pas créé automatiquement sur les ordinateurs Windows Server qui sont utilisés en tant que contrôleurs de domaine. Pour utiliser Session Manager sur un contrôleur de domaine Windows Server, créez le compte ssm-user manuellement, s'il n'existe pas déjà, et affectez les autorisations d'administrateur de domaine à l'utilisateur.

Important

Pour que le compte ssm-user soit créé, le profil d'instance attaché à l'instance doit fournir les autorisations requises. Pour plus d'informations, consultez Étape 2 : vérifier ou ajouter des autorisations d'instance pour Session Manager.

SSM Agent et le Instance Metadata Service (IMDS)

Systems Manager s'appuie sur les métadonnées d'instance EC2 pour fonctionner correctement. Systems Manager peut accéder aux métadonnées d'instance en utilisant la version 1 ou la version 2 d'Instance Metadata Service (IMDSv1 et IMDSv2). Votre instance doit pouvoir accéder à l'adresse IPv4 du service des métadonnées d'instance : 169.254.169.254. Pour plus d'informations, consultez Métadonnées d'instance et données utilisateur dans le Guide de l'utilisateur Amazon EC2.

Garder SSM Agent up-to-date

Une nouvelle version de SSM Agent est lancée chaque fois que de nouvelles fonctionnalités sont ajoutées à Systems Manager ou que des mises à jour sont apportées aux fonctionnalités existantes. Le fait de ne pas utiliser la dernière version de l'agent peut empêcher votre nœud géré d'utiliser diverses capacités et fonctionnalités de Systems Manager. C'est pourquoi nous vous recommandons d'automatiser le processus permettant de maintenir SSM Agent à jour sur vos machines. Pour plus d'informations, consultez Automatisation des mises à jour de l'SSM Agent. Abonnez-vous à la page des notes de SSM Agent publication GitHub pour recevoir des notifications concernant les SSM Agent mises à jour.

Note

Une nouvelle version de SSM Agent est lancée chaque fois que de nouvelles fonctionnalités sont ajoutées à Systems Manager ou que des mises à jour sont apportées aux fonctionnalités existantes. Le fait de ne pas utiliser la dernière version de l'agent peut empêcher votre nœud géré d'utiliser diverses capacités et fonctionnalités de Systems Manager. C'est pourquoi nous vous recommandons d'automatiser le processus permettant de maintenir SSM Agent à jour sur vos machines. Pour plus d'informations, consultez Automatisation des mises à jour de l'SSM Agent. Abonnez-vous à la page des notes de SSM Agent publication GitHub pour recevoir des notifications concernant les SSM Agent mises à jour.

Les Amazon Machine Images (AMIs) qui comprennent l'SSM Agent par défaut peuvent prendre jusqu'à deux semaines pour publier l'AMI mis à jour avec la dernière version de l'SSM Agent. Nous vous recommandons de configurer encore plus fréquemment des mises à jour automatiques de l'SSM Agent.

S’assurer que le répertoire d’installation SSM Agent ne soit pas modifié, déplacé ou supprimé

SSM Agent est installé sur /var/lib/amazon/ssm/ (Linux et macOS) et %PROGRAMFILES%\Amazon\SSM\ (Windows Server). Ces répertoires d’installation contiennent des fichiers et des dossiers critiques utilisés par SSM Agent, tels qu’un fichier d’informations d’identification, des ressources pour la communication interprocessus (IPC) et des dossiers d’orchestration. Aucun élément du répertoire d’installation ne doit être modifié, déplacé ou supprimé. Dans le cas contraire, SSM Agent pourrait cesser de fonctionner correctement.

SSM Agentmises à jour continues par Régions AWS

Une fois qu'une SSM Agent mise à jour est disponible dans son GitHub référentiel, cela peut prendre jusqu'à deux semaines avant que la version mise à jour ne soit déployée auprès de tous Régions AWS à des moments différents. Pour cette raison, vous pouvez recevoir le message d'erreur « Non pris en charge sur la plate-forme actuelle » ou « Mise amazon-ssm-agent à jour vers une ancienne version, veuillez activer l'autorisation de rétrogradation » lorsque vous tentez de déployer une nouvelle version de SSM Agent dans une région.

Pour déterminer votre version disponible de SSM Agent, vous pouvez exécuter une commande curl.

Pour afficher la version de l'agent disponible dans le compartiment de téléchargement global, exécutez la commande suivante.

curl https://s3.amazonaws.com/ec2-downloads-windows/SSMAgent/latest/VERSION

Pour afficher la version de l'agent disponible dans une région particulière, exécutez la commande suivante, en remplaçant la région par celle où vous travaillez, par exemple, us-east-2 pour la région USA Est (Ohio).

curl https://s3.region.amazonaws.com/amazon-ssm-region/latest/VERSION

Vous pouvez aussi ouvrir le fichier VERSION directement dans votre navigateur sans exécuter de commande curl.

Communications de l'SSM Agent avec des compartiments S3 gérés par AWS

Au cours de l'exécution de diverses opérations de Systems Manager, AWS Systems Manager Agent (SSM Agent) accède à un certain nombre de compartiments Amazon Simple Storage Service (Amazon S3). Ces compartiments S3 sont accessibles au public et, par défaut, l'SSM Agent s'y connecte en utilisant des appels HTTP.

Toutefois, si vous utilisez un point de terminaison de cloud privé virtuel (VPC) dans le cadre de vos opérations Systems Manager, vous devez fournir une autorisation explicite dans un profil d'instance Amazon Elastic Compute Cloud (Amazon EC2) pour Systems Manager, ou dans un rôle de service pour les machines non EC2 dans un environnement hybride et multicloud. Sinon, vos ressources ne peuvent pas accéder à ces compartiments publics.

Pour accorder à vos nœuds gérés l'accès à ces compartiments lorsque vous utilisez un point de terminaison d'un VPC, vous créez une politique d'autorisations Amazon S3 personnalisée, puis l'attachez à votre profil d'instance (pour les instances EC2) ou à votre fonction du service (pour les nœuds gérés non EC2).

Pour plus d'informations sur l'utilisation d'un point de terminaison de cloud privé virtuel (VPC) dans vos opérations de Systems Manager, consultez Améliorer la sécurité des instances EC2 en utilisant des points de terminaison VPC pour Systems Manager.

Note

Ces autorisations fournissent uniquement l'accès aux compartiments AWS gérés requis parSSM Agent. Elles ne fournissent pas les autorisations qui sont nécessaires pour les autres opérations Amazon S3. Elles ne fournissent pas non plus l'autorisation sur vos propres compartiments S3.

Pour plus d’informations, consultez les rubriques suivantes :

• Configurer les autorisations d'instance requises pour Systems Manager

• Créez le rôle de service IAM requis pour Systems Manager dans les environnements hybrides et multicloud

Autorisations de compartiment nécessaires

Le tableau suivant décrit chacun des compartiments S3 auxquels l'SSM Agent peut avoir besoin d'accéder pour des opérations Systems Manager.

Note

région représente l'identifiant d'une région Région AWS prise en charge par AWS Systems Manager, par exemple us-east-2 pour la région USA Est (Ohio). Pour obtenir une liste des valeurs region prises en charge, consultez la colonne Région dans la rubrique Points de terminaison de service Systems Manager de la Référence générale d'Amazon Web Services.

Autorisations Amazon S3 requises par l'SSM Agent

ARN de compartiment S3	Description
arn:aws:s3:::aws-windows-downloads-region/*	Obligatoire pour certains documents SSM qui ne prennent en charge que les systèmes d'exploitation Windows Server, ainsi que pour d'autres pour la prise en charge multiplateforme, tels que AWSEC2-ConfigureSTIG.
arn:aws:s3:::amazon-ssm-region/*	Requise pour la mise à jour des installations de l'SSM Agent. Ces compartiments contiennent les packages d'installation de l'SSM Agent, et l'installation des manifestes qui sont référencés par le document et le plug-in AWS-UpdateSSMAgent. Si ces autorisations ne sont pas fournies, l'SSM Agent effectue un appel HTTP pour télécharger la mise à jour.
arn:aws:s3:::amazon-ssm-packages-region/*	Requise pour utiliser les versions de l'SSM Agent antérieures à la version 2.2.45.0 en vue d'exécuter le document SSM AWS-ConfigureAWSPackage.
arn:aws:s3:::region-birdwatcher-prod/*	Permet d'accéder au service de distribution utilisé par la version 2.2.45.0 et les versions ultérieures de l'SSM Agent. Ce service est utilisé pour exécuter le document AWS-ConfigureAWSPackage. Cette autorisation est nécessaire pour tous Régions AWS sauf pour la région Afrique (Le Cap) (af-south-1) et pour la région Europe (Milan) (eu-south-1).
arn:aws:s3:::aws-ssm-distributor-file-region/*	Permet d'accéder au service de distribution utilisé par la version 2.2.45.0 et les versions ultérieures de l'SSM Agent. Ce service est utilisé pour exécuter le document SSM AWS-ConfigureAWSPackage. Cette autorisation est nécessaire uniquement pour la région Afrique (Le Cap) (af-sud-1) et la région Europe (Milan) (eu-sud 1).
arn:aws:s3:::aws-ssm-document-attachments-region/*	Fournit un accès au compartiment S3 contenant les packages pourDistributor, une fonctionnalité de AWS Systems Manager, détenus par AWS.
arn:aws:s3:::patch-baseline-snapshot-region/*	Fournit l'accès au compartiment S3 contenant les instantanés de référentiel de correctifs. Ceci est obligatoire si vous utilisez l'un des documents SSM suivants : AWS-RunPatchBaseline AWS-RunPatchBaselineAssociation AWS-RunPatchBaselineWithHooks AWS-ApplyPatchBaseline (un document SSM hérité) Note Dans la région Moyen-Orient (Bahreïn) (me-south-1) uniquement, ce compartiment S3 utilise une convention de dénomination différente. Pour cette Région AWS uniquement, utilisez plutôt le compartiment suivant. patch-baseline-snapshot-me-south-1-uduvl7q8 Dans la région Afrique (Le Cap) (me-south-1) uniquement, ce compartiment S3 utilise une convention de dénomination différente. Pour cette Région AWS uniquement, utilisez plutôt le compartiment suivant. patch-baseline-snapshot-af-south-1-tbxdb5b9
Pour les nœuds gérés Linux et Windows Server : arn:aws:s3:::aws-ssm-region/* Pour les instances Amazon EC2macOS : arn:aws:s3:::aws-patchmanager-macos-region/*	Fournit l'accès au compartiment S3 contenant les modules requis à utiliser avec certains documents Systems Manager (documents SSM). Par exemple : arn:aws:s3:::aws-ssm-us-east-2/* aws-patchmanager-macos-us-east-2/* Exceptions Dans certains cas, les noms des compartiments S3 Régions AWS utilisent une convention de dénomination étendue, comme le montrent leurs ARN. Pour ces régions, utilisez plutôt les ARN suivants : Middle East (Bahrain) Region (me-south-1)) : aws-patch-manager-me-south-1-a53fc9dce Africa (Cape Town) Region (af-south-1) : aws-patch-manager-af-south-1-bdd5f65a9 Europe (Milan) Region (eu-south-1) : aws-patch-manager-eu-south-1-c52f3f594 Asia Pacific (Osaka) Region (ap-northeast-3) : aws-patch-manager-ap-northeast-3-67373598a Documents SSM Voici quelques documents SSM couramment utilisés, stockés dans ces compartiments. Dans arn:aws:s3:::aws-ssm-region/: AWS-RunPatchBaseline AWS-RunPatchBaselineAssociation AWS-RunPatchBaselineWithHooks AWS-InstanceRebootWithHooks AWS-ConfigureWindowsUpdate AWS-FindWindowsUpdates AWS-PatchAsgInstance AWS-PatchInstanceWithRollback AWS-UpdateSSMAgent AWS-UpdateEC2Config Dans arn:aws:s3:::aws-patchmanager-macos-region/: AWS-RunPatchBaseline AWS-RunPatchBaselineAssociation AWS-RunPatchBaselineWithHooks AWS-InstanceRebootWithHooks AWS-PatchAsgInstance AWS-PatchInstanceWithRollback

Exemple

L'exemple suivant illustre comment fournir l'accès aux compartiments S3 requis pour les opérations Systems Manager dans la région USA Est (Ohio) (us-east-2). Dans la plupart des cas, vous devez fournir ces autorisations explicitement dans un profil d'instance ou un rôle de service uniquement lors de l'utilisation d'un point de terminaison de VPC.

Important

Dans cette politique, nous vous recommandons d'éviter d'utiliser des caractères génériques (*) à la place des régions spécifiques. Par exemple, utilisez arn:aws:s3:::aws-ssm-us-east-2/* et n'utilisez pas arn:aws:s3:::aws-ssm-*/*. L'utilisation de caractères génériques pourrait fournir l'accès aux compartiments S3 vers lesquels vous ne prévoyez pas d'accorder l'accès. Si vous souhaitez utiliser le profil d'instance pour plusieurs régions, nous vous recommandons de répéter le premier bloc Statement pour chaque région.

{
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "s3:GetObject",
                "Resource": [
                    "arn:aws:s3:::aws-windows-downloads-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-us-east-2/*",
                    "arn:aws:s3:::amazon-ssm-packages-us-east-2/*",
                    "arn:aws:s3:::us-east-2-birdwatcher-prod/*",
                    "arn:aws:s3:::aws-ssm-document-attachments-us-east-2/*",
                    "arn:aws:s3:::patch-baseline-snapshot-us-east-2/*",
                    "arn:aws:s3:::aws-ssm-us-east-2/*",
                    "arn:aws:s3:::aws-patchmanager-macos-us-east-2/*"
                ]
            }
        ]
    }

Validation des machines activées par un système hybride à l'aide d'une empreinte matérielle

Lorsque vous exécutez des machines non EC2 dans un environnement hybride et multicloud, SSM Agent rassemble des attributs système (autrement appelés hachage matériel), qu'il utilise pour calculer une empreinte digitale. L'empreinte digitale est une chaîne opaque que l'agent transmet à certaines API Systems Manager. Cette empreinte digitale unique associe l'appelant à un nœud géré et activé par un système hybride particulier. L'agent stocke l'empreinte digitale et le hachage matériel sur le disque local, à un emplacement désigné comme Coffre-fort.

L'agent calcule le hachage matériel et l'empreinte digitale lorsque la machine est enregistrée pour une utilisation avec Systems Manager. Ensuite, l'empreinte digitale est transmise au service Systems Manager lorsque l'agent envoie une commande RegisterManagedInstance.

Plus tard, lors de l'envoi d'une commande RequestManagedInstanceRoleToken, l'agent vérifie l'empreinte digitale et le hachage matériel dans le coffre-fort afin de s'assurer que les attributs de la machine actuelle correspondent au hachage matériel stocké. Si les attributs de la machine actuelle correspondent au hachage matériel stocké dans le coffre-fort, l'agent transmet l'empreinte digitale du coffre-fort à une RegisterManagedInstance, et l'appel est alors considéré comme réussi.

Si les attributs de la machine actuelle ne correspondent pas au hachage matériel stocké, l'SSM Agent calcule une nouvelle empreinte digitale, stocke le nouveau hachage matériel et l'empreinte digitale dans le coffre-fort et transmet la nouvelle empreinte digitale à un RequestManagedInstanceRoleToken. Cela provoque l'échec du RequestManagedInstanceRoleToken, et l'agent ne pourra pas obtenir un jeton de rôle pour se connecter au service Systems Manager.

Cet échec est intégré, et il sert d'étape de vérification pour empêcher que plusieurs nœuds gérés communiquent avec le service Systems Manager en tant que même nœud géré.

Lorsqu'il compare les attributs de la machine actuelle au hachage matériel stocké dans le coffre-fort, l'agent utilise la logique suivante pour déterminer si l'ancien et le nouveau hachages correspondent :

• Si le SID (ID système/machine) est différent, alors ils ne correspondent pas.

• Si l'adresse IP est la même, alors ils correspondent.

• Sinon, le pourcentage d'attributs de la machine qui correspondent est calculé et comparé au seuil de similarité configuré par l'utilisateur pour déterminer s'il y a correspondance.

Le seuil de similarité est stocké dans le coffre-fort, et fait partie du hachage matériel.

Le seuil de similarité peut être défini après qu'une instance a été enregistrée en utilisant une commande semblable à celle qui suit.

Sur les machines Linux :

sudo amazon-ssm-agent -fingerprint -similarityThreshold 1

Sur Windows Server les machines utilisant PowerShell :

cd "C:\Program Files\Amazon\SSM\" `
    .\amazon-ssm-agent.exe -fingerprint -similarityThreshold 1

Important

Si l'un des composants utilisés pour calculer l'empreinte digitale change, cela peut entraîner la mise en veille prolongée de l'agent. Pour éviter cette mise en veille prolongée, définissez le seuil de similitude à une valeur faible, 1 par exemple.

SSM Agent sur GitHub

Le code source de SSM Agent est disponible sur GitHubafin que vous puissiez adapter l'agent à vos besoins. Nous vous conseillons d'envoyer des requêtes d'extraction pour les modifications que vous souhaitez inclure. Toutefois, Amazon Web Services ne fournit pas de support pour l'exécution de copies modifiées de ce logiciel.