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.
Utiliser des scripts de session sur des flottes multisessions
Lorsque vous utilisez des scripts de session sur des flottes multisessions, des exigences et des considérations supplémentaires doivent être prises en compte pour garantir des performances et une sécurité optimales.
Prérequis
Sur une flotte à session unique, pour une instance donnée, il est garanti que les SessionTerminationhooks SessionStartet ne fonctionneront qu'une seule fois. Cela est dû au fait qu'il existe un mappage 1:1 des sessions aux instances. Lorsque vous utilisez des flottes multisessions, il existe un mappage N:M des sessions vers les instances, où chaque session exécute sa propre session et se connecte. SessionStartSessionTermination Cela signifie que les SessionTerminationhooks SessionStartand peuvent être exécutés plusieurs fois sur une instance donnée, et dans de nombreux ordres différents. Pour une expérience optimale, les règles suivantes doivent s'appliquer à vos scripts de session lorsqu'ils sont utilisés sur des flottes multisessions :
-
Les scripts sont idempotents.
Lorsqu'une action a déjà été exécutée, les scripts doivent gérer plusieurs exécutions sur la même instance avec une gestion harmonieuse.
-
Les scripts sont indépendants.
Comme les scripts s'exécutent par session, si une session est SessionTerminationen cours d'exécution pendant qu'une autre est en cours d'exécution SessionStart, ils ne doivent pas interférer les uns avec les autres ni avec l'expérience des autres sessions.
-
Les scripts sont performants.
Sur les instances multisessions, plusieurs sessions peuvent être mises en service simultanément. Cela signifie qu'il peut y avoir plusieurs exécutions simultanées des scripts de session. Les scripts doivent être efficaces, ne pas consommer trop de ressources et ne pas affecter l'expérience des autres utilisateurs sur l'instance ni la stabilité des sessions.
Bon nombre de ces exigences peuvent être satisfaites en gardant la logique du script de session centrée sur la session utilisateur spécifique pour laquelle le script est exécuté.
Considérations de sécurité
AppStream Les images 2.0 ne doivent pas être configurées pour autoriser les utilisateurs à accéder en écriture aux fichiers de script de session. Cela introduit un vecteur d'attaque critique pour les utilisateurs malveillants, qui peuvent modifier les fichiers de script. Ces fichiers peuvent ensuite être exécutés en tant qu'utilisateur SYSTEM ou en tant qu'utilisateur tiers, en fonction de votre configuration.
Important
Il est de votre responsabilité de vous assurer que vos images AppStream 2.0 sont configurées de manière sécurisée. Cela est particulièrement important pour les instances multi-sessions, où plusieurs utilisateurs utilisent la même instance. Si les images ne sont pas configurées de manière sécurisée, il existe un risque de sécurité pour tous les utilisateurs de cette instance.
Ce qui suit doit être vrai pour vos images et vos fichiers de scripts de session :
-
Les utilisateurs ne sont pas autorisés à modifier les fichiers de script de session.
-
Les utilisateurs ne sont pas autorisés à modifier le script de session config.json. Le comportement par défaut de l'image restreint l'accès aux administrateurs.
Les exécutables des scripts de session doivent être stockés dans un emplacement sécurisé où ils ne peuvent pas être modifiés lors de l'exécution.
Si le service détecte qu'un exécutable de script de session a été modifié, il échouera à toute exécution ultérieure de ce hook sur cette instance, téléchargera les fichiers journaux sur Amazon S3 (si la journalisation Amazon S3 est activée) et le message suivant s'affichera :
Le script de session n'a pas été exécuté car l'exécutable a été modifié après le provisionnement de l'instance. L'exécution a été ignorée pour des raisons de sécurité.
Si votre cas d'utilisation nécessite de modifier le script de session exécutable au moment de l'exécution (par exemple, si vous pointez sur un EXE fichier modifié par un processus de mise à jour automatique au moment de l'exécution), les vérifications ci-dessus échoueront. Dans ce cas, utilisez un script pour rediriger l'exécution vers votre exécutable modifié. Ne modifiez pas le script au moment de l'exécution lorsque le service effectue des contrôles de sécurité.
Si les fichiers de script de session sont trop volumineux (plus de 100 Mo), cela peut entraîner des retards dans le provisionnement des instances et des sessions, et les contrôles de sécurité peuvent prendre plus de temps (en fonction du type d'instance et des ressources disponibles). Si votre cas d'utilisation nécessite des scripts de session volumineux, pensez à utiliser des scripts plus petits pour rediriger l'exécution. Cela améliorera les expériences de provisionnement des instances et des sessions.
Notez que le service ne vérifie que l'exécutable défini dans les scripts de session config.json, et qu'il ne s'agit que d'un mécanisme de repli ou de meilleur effort. Il est de votre responsabilité de vous assurer que tous les chemins de code des exécutables des scripts de session sont sécurisés et ne peuvent pas être modifiés par les utilisateurs finaux.
