Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Verwenden Sie Sitzungsskripten auf Flotten mit mehreren Sitzungen
Bei der Verwendung von Sitzungsskripten für Flotten mit mehreren Sitzungen gelten zusätzliche Anforderungen und Überlegungen, um optimale Leistung und Sicherheit zu gewährleisten.
Voraussetzungen
Bei einer Flotte mit nur einer Sitzung werden die SessionStartSessionTerminationAnd-Hooks für eine bestimmte Instanz garantiert nur einmal ausgeführt. Das liegt daran, dass es eine 1:1 -Zuordnung von Sitzungen zu Instanzen gibt. Bei der Verwendung von Multi-Session-Flotten gibt es eine N:M-Zuordnung von Sessions zu Instances, wobei jede Session ihren eigenen und einen eigenen Hook ausführt. SessionStartSessionTermination Das bedeutet, dass die SessionTerminationHooks SessionStartund die Hooks auf einer bestimmten Instanz viele Male und in vielen verschiedenen Reihenfolgen ausgeführt werden können. Für eine optimale Benutzererfahrung sollte Folgendes für Ihre Session-Skripte gelten, wenn Sie sie auf Multi-Session-Flotten verwenden:
-
Skripte sind idempotent.
Wenn eine Aktion bereits ausgeführt wurde, sollten Skripte mehr als eine Ausführung auf derselben Instanz problemlos verarbeiten.
-
Skripten sind unabhängig.
Da Skripten pro Sitzung ausgeführt werden, sollten sie, wenn eine Sitzung ausgeführt wird SessionStart, SessionTerminationwährend eine andere läuft, sich gegenseitig oder die Erfahrung anderer Sitzungen nicht beeinträchtigen.
-
Skripts sind performant.
Auf Instanzen mit mehreren Sitzungen können mehrere Sitzungen gleichzeitig bereitgestellt werden. Das bedeutet, dass die Sitzungsskripten mehrfach gleichzeitig ausgeführt werden können. Skripts sollten effizient sein, keine übermäßigen Ressourcen verbrauchen und die Erfahrung anderer Benutzer auf der Instanz oder die Stabilität der Sitzungen nicht beeinträchtigen.
Viele dieser Anforderungen können erfüllt werden, indem die Logik des Sitzungsskripts auf die spezifische Benutzersitzung ausgerichtet wird, für die das Skript ausgeführt wird.
Sicherheitsüberlegungen
AppStream 2.0-Images sollten nicht so konfiguriert werden, dass sie Benutzern Schreibberechtigungen für Sitzungsskriptdateien gewähren. Dadurch wird ein kritischer Angriffsvektor für böswillige Benutzer eingeführt, bei dem sie Skriptdateien ändern könnten. Diese Dateien könnten dann je nach Konfiguration als SYSTEM oder einem anderen Benutzer ausgeführt werden.
Wichtig
Es liegt in Ihrer Verantwortung, sicherzustellen, dass Ihre AppStream 2.0-Images sicher konfiguriert sind. Dies ist besonders wichtig für Instanzen mit mehreren Sitzungen, bei denen mehrere Benutzer dieselbe Instanz verwenden. Wenn Images nicht sicher konfiguriert sind, besteht ein Sicherheitsrisiko für alle Benutzer dieser Instanz.
Folgendes sollte für Ihre Bilder und Sitzungsskriptdateien gelten:
-
Benutzer sind nicht berechtigt, Sitzungsskriptdateien zu ändern.
-
Benutzer sind nicht berechtigt, das Sitzungsskript config.json zu ändern. Das Standardverhalten des Images schränkt den Zugriff auf Administratoren ein.
Die ausführbaren Dateien von Sitzungsskripten sollten an einem sicheren Ort gespeichert werden, an dem sie während der Laufzeit vor Änderungen geschützt sind.
Wenn der Service feststellt, dass eine ausführbare Datei eines Sitzungsskripts geändert wurde, schlägt er alle nachfolgenden Ausführungen dieses Hooks auf dieser Instance fehl, lädt Protokolldateien auf Amazon S3 hoch (falls die Amazon S3 S3-Protokollierung aktiviert ist), und Sie erhalten die folgende Meldung:
Das Sitzungsskript wurde nicht ausgeführt, da die ausführbare Datei nach der Instance-Bereitstellung geändert wurde. Die Ausführung wurde aus Sicherheitsgründen übersprungen.
Wenn Ihr Anwendungsfall eine Änderung der ausführbaren Datei des Sitzungsskripts zur Laufzeit erfordert (wenn Sie beispielsweise auf eine EXE Datei verweisen, die zur Laufzeit durch einen automatischen Aktualisierungsprozess geändert wurde), werden die obigen Prüfungen nicht bestanden. Verwenden Sie in diesem Fall ein Skript, um die Ausführung an Ihre geänderte ausführbare Datei weiterzuleiten. Lassen Sie das Skript zur Laufzeit unverändert, wenn der Dienst Sicherheitsüberprüfungen durchführt.
Wenn Ihre Sitzungsskriptdateien zu groß sind (mehr als 100 MB), kann dies zu Verzögerungen bei der Instanz- und Sitzungsbereitstellung führen, und die Sicherheitsprüfungen nehmen zusätzliche Zeit in Anspruch (abhängig vom Instanztyp und den verfügbaren Ressourcen). Wenn Ihr Anwendungsfall umfangreiche Sitzungsskripten erfordert, sollten Sie die Verwendung kleinerer Skripts in Betracht ziehen, um die Ausführung umzuleiten. Dies wird die Erfahrung bei der Bereitstellung von Instanzen und Sitzungen verbessern.
Beachten Sie, dass der Dienst nur die in den Sitzungsskripten config.json definierte ausführbare Datei überprüft, und dass dies nur ein Fallback-/Best-Effort-Mechanismus ist. Es liegt in Ihrer Verantwortung, sicherzustellen, dass alle Codepfade in den ausführbaren Dateien von Sitzungsskripten sicher sind und nicht von Endbenutzern geändert werden können.
