Utilizzate gli script di sessione per gestire l'esperienza di streaming degli utenti della AppStream versione 2.0

AppStream 2.0 fornisce script di sessione su istanza. Puoi utilizzare questi script per eseguire script personalizzati quando si verificano determinati eventi in sessioni di streaming degli utenti. Ad esempio, è possibile utilizzare script personalizzati per preparare l'ambiente AppStream 2.0 prima dell'inizio delle sessioni di streaming degli utenti. Puoi anche utilizzare script personalizzati per eliminare le istanze di streaming dopo che gli utenti hanno completato le proprie sessioni di streaming.

Gli script di sessione sono specificati all'interno di un'immagine 2.0 AppStream . Questi script vengono sono eseguiti all'interno del contesto dell'utente o del contesto di sistema. Se la sessione usa gli script standard in uscita per scrivere informazioni, errori o messaggistica di debug, tali elementi possono essere facoltativamente salvati in un bucket Amazon S3 nell'account Amazon Web Services.

Esecuzione degli script prima dell'inizio delle sessioni di streaming

Puoi configurare gli script per l'esecuzione per un massimo di 60 secondi prima di avviare le applicazioni degli utenti e prima che le sessioni di streaming abbiano inizio. In questo modo è possibile personalizzare l'ambiente AppStream 2.0 prima che gli utenti inizino a trasmettere in streaming le proprie applicazioni. Quando gli script di sessione vengono eseguiti, viene mostrata un'icona di caricamento per i tuoi utenti. Quando gli script vengono completati con successo o quando trascorre l'intervallo di tempo massimo in attesa, inizierà la sessione di streaming dei tuoi utenti. Se gli non vengono completati correttamente, viene visualizzato un messaggio di errore per i tuoi utenti. Tuttavia, i tuoi utenti possono usare comunque le proprie sessioni di streaming.

Quando specifichi un nome di file su un'istanza Windows, devi utilizzare una doppia barra rovesciata. Per esempio:

C:\\Scripts\\Myscript.bat

Se non si utilizza una doppia barra rovesciata, viene visualizzato un errore per notificare che il file.json non è formattato correttamente.

Nota

Quando gli script vengono completati correttamente, devono restituire un valore 0. Se gli script restituiscono un valore diverso da 0, AppStream 2.0 visualizza il messaggio di errore all'utente.

Quando si eseguono gli script prima dell'inizio delle sessioni di streaming e il framework applicativo dinamico AppStream 2.0 non è abilitato, si verifica il seguente processo:

1. I tuoi utenti si connettono a un'istanza della flotta AppStream 2.0 che non fa parte di un dominio. Si collegano utilizzando uno dei seguenti metodi di accesso:

   • AppStream Pool di utenti 2.0

   • SAML 2.0

   • AppStream API 2.0

2. Il catalogo delle applicazioni viene visualizzato nel portale AppStream 2.0 e gli utenti scelgono un'applicazione da avviare.

3. Si verifica uno degli eventi seguenti:

   • Se le impostazioni di persistenza delle applicazioni sono abilitate per i tuoi utenti, vengono scaricati e installati il file delle impostazioni delle applicazioni VHD (Virtual Hard Disk) che memorizza le tue impostazioni di personalizzazioni degli utenti e le impostazioni di Windows. In questo caso, è necessario l'accesso dell'utente a Windows.

     Per ulteriori informazioni sulle impostazioni di persistenza delle applicazioni, consulta Abilitare la persistenza delle impostazioni dell'applicazione per gli utenti AppStream 2.0..

   • Se le impostazioni di persistenza delle applicazioni non sono abilitate, l'utente Windows sarà già connesso.

4. Gli script di sessione sono avviati. Se lo storage persistente è abilitato per i tuoi utenti, viene inoltre avviata l'installazione del connettore di storage. Per informazioni sulle storage persistente, consulta Abilita e amministra lo storage persistente per i tuoi utenti AppStream 2.0.

   Nota

   Affinché inizi la sessione di streaming non è necessario il completamento dell'installazione del connettore di storage. Se gli script di sessione vengono completati prima del completamento dell'installazione del connettore di storage, lo streaming di sessione ha inizio.

   Per ulteriori informazioni sul monitoraggio dello stato di installazione dei connettori di storage, consulta Utilizzo dei connettori di storage con script di sessione.

5. I tuoi script di sessione vengono completati o scadono.

6. La sessione di streaming degli utenti ha inizio.

7. L'applicazione selezionata dai tuoi utenti viene avviata.

Per informazioni sul framework applicativo dinamico AppStream 2.0, vedereUtilizza il framework di applicazioni dinamiche di AppStream 2.0 per compilare un provider di app dinamiche.

Quando si eseguono gli script prima dell'inizio delle sessioni di streaming e il framework applicativo dinamico AppStream 2.0 è abilitato, si verifica il seguente processo:

1. I tuoi utenti visitano il portale applicativo SAML 2.0 per la tua organizzazione e scelgono lo stack AppStream 2.0.

2. Si connettono a un'istanza della flotta AppStream 2.0 aggiunta a un dominio.

3. Se le impostazioni di persistenza delle applicazioni sono abilitata per i tuoi utenti, vengono scaricati e installati il file VHD (Virtual Hard Disk) che memorizza le tue impostazioni di personalizzazione degli utenti e le impostazioni di Windows.

4. Si verifica l'accesso dell'utente a Windows.

5. Il catalogo delle applicazioni viene visualizzato nel portale AppStream 2.0 e gli utenti scelgono un'applicazione da avviare.

6. Gli script di sessione sono avviati. Se lo storage persistente è abilitato per i tuoi utenti, viene inoltre avviata l'installazione del connettore di storage.

   Nota

   Affinché inizi la sessione di streaming non è necessario il completamento dell'installazione del connettore di storage. Se gli script di sessione vengono completati prima del completamento dell'installazione del connettore di storage, lo streaming di sessione ha inizio.

   Per ulteriori informazioni sul monitoraggio dello stato di installazione dei connettori di storage, consulta Utilizzo dei connettori di storage con script di sessione.

7. I tuoi script di sessione vengono completati o scadono.

8. La sessione di streaming degli utenti ha inizio.

9. L'applicazione selezionata dai tuoi utenti viene avviata.

Esecuzione degli script dopo la fine delle sessioni di streaming.

Puoi anche configurare gli script per l'esecuzione dopo la fine delle sessioni di streaming degli utenti. Ad esempio, è possibile eseguire uno script quando gli utenti selezionano Termina sessione dalla barra degli strumenti AppStream 2.0 o quando raggiungono la durata massima consentita per la sessione. È inoltre possibile utilizzare questi script di sessione per ripulire l'ambiente AppStream 2.0 prima che un'istanza di streaming venga terminata. Ad esempio, puoi utilizzare gli script per rimuovere i blocchi dei file o caricare i file di log. Quando esegui gli script dopo la fine delle sessioni di streaming, si verifica il processo riportato di seguito.

1. La sessione di streaming AppStream 2.0 degli utenti termina.

2. Gli script di fine sessione sono avviati.

3. I tuoi script di fine sessione vengono completati o scadono.

4. Si verifica l'uscita dell'utente da Windows.

5. Uno o entrambi i seguenti eventi si verificano in parallelo, ove applicabile:

   • Se per gli utenti sono abilitate le impostazioni di persistenza delle applicazioni, il file VHD che archivia le impostazioni di personalizzazione degli utenti e le impostazioni di Windows viene smontato e caricato in un bucket Amazon S3 nell'account.

   • Se lo storage persistente è abilitato per gli utenti, il connettore di storage completa una sincronizzazione finale e viene disinstallato.

6. L'istanza del parco istanze viene terminata.

Creazione e specificazione di script di sessione

Puoi configurare e specificare script di sessione per parchi istanze sempre attivi, on demand ed elastici.

Per configurare e specificare script di sessione per parchi istanze sempre attivi, on demand ed elastiche

1. Apri la console AppStream 2.0 all'indirizzo https://console.aws.amazon.com/appstream2.

2. Nel riquadro di navigazione a sinistra, scegli Image (Immagini), Image Builder (Sviluppatore di immagini).

3. Seleziona uno sviluppatore di immagini che sia nello stato Running (In esecuzione) e scegli Connect (Connessione).

4. Quando viene richiesto, scegliere Administrator (Amministratore).

5. Accedi a C:\AppStream\SessionScripts e apri il file di configurazione config.json.

   Per ulteriori informazioni sui parametri degli script di sessione, vedi File di configurazione degli script di sessione.

6. Al termine delle modifiche, salva e chiudi il file config.json.

7. Sul desktop dell'Image Builder, apri Image Assistant.

8. (Facoltativo) specifica altre applicazioni da includere nell'immagine.

9. Segui le fasi necessarie in Image Assistant per completare la creazione dell'immagine.

   Se la configurazione di script di sessione non può essere convalidata (ad esempio, se il file .json non è formattato in modo corretto), riceverai una notifica quando scegli Disconnect and create image (Disconnetti e crea immagine).

   Nota

   Per individuare il file di configurazione degli script di sessione per Image Builder basati su Linux, accedi a /opt/appstream/SessionScripts/config.json.

Per configurare e specificare gli script di sessione per i parchi istanze elastici

1. Crea un file zip che contenga gli script di sessione e il file config.json. I file degli script verranno copiati nelle seguenti posizioni. Devi utilizzare queste posizioni per config.json.

   • Per Windows utilizza C:\AppStream\SessionScripts\SessionScript.

   • Per Linux utilizza /opt/appstream/SessionScripts/SessionScript.

   Nota

   Per eseguire i file di script di sessione, assicurati che il file.zip contenga solo gli script di sessione e i file config.json e non la cartella che li contiene. Per ulteriori informazioni, consulta File di configurazione degli script di sessione.

2. Carica il file zip in un bucket Amazon S3 nell'account.

   Nota

   Il VPC deve fornire l'accesso al bucket Amazon S3. Per ulteriori informazioni, consulta Utilizzo degli endpoint VPC di Amazon S3 per le funzionalità 2.0 AppStream .

   È necessario che il bucket S3 e la flotta AppStream 2.0 si trovino nello stesso ambiente. Regione AWS

   Per eseguire l'operazione S3:GetObject sull'oggetto script di sessione nel bucket Amazon S3, devi disporre delle autorizzazioni IAM. Per ulteriori informazioni sull'archiviazione degli script di sessione in un bucket Amazon S3, consulta Archivia l'icona dell'applicazione, lo script di configurazione, lo script di sessione e il file VHD in un bucket S3.

3. Apri la console AppStream 2.0 all'indirizzo https://console.aws.amazon.com/appstream2.

4. Nel riquadro di navigazione, selezionare Fleets (Parchi istanze).

5. Scegli un parco istanze elastico che desideri aggiornare, quindi scegli Visualizza dettagli.

6. Nella scheda Impostazioni degli script di sessione, scegli Modifica.

7. Per Oggetto script di sessione in S3, inserisci l'URI S3 che rappresenta l'oggetto script sessione oppure scegli Sfoglia S3 per accedere ai bucket S3 e trovare l'oggetto script di sessione.

8. Una volta completate le modifiche, scegli Salva modifiche.

9. A questo punto, gli script di sessione sono disponibili per tutte le istanze del parco istanze avviate.

   Nota

   Puoi anche configurare gli script di sessione quando crei un nuovo parco istanze elastico.

File di configurazione degli script di sessione

Per individuare il file di configurazione degli script di sessione in un'istanza di Windows, accedi a C:\\ AppStreamSessionScripts\ config.json. Su un'istanza Linux, vai a /opt/appstream/ SessionScripts /config.json. La formattazione del file è la seguente.

Nota

Il file di configurazione è in formato .json. Verifica che qualsiasi testo digitato in questo file sia in formato .json valido.

{
  "SessionStart": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  },
  "SessionTermination": {
    "executables": [
      {
        "context": "system",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      },
      {
        "context": "user",
        "filename": "",
        "arguments": "",
        "s3LogEnabled": true
      }
    ],
    "waitingTime": 30
  }
}

Puoi utilizzare i seguenti parametri nel file di configurazione degli script di sessione.

SessionStart/SessionTermination

Gli script di sessione da eseguire nel pertinente evento della sessione in base al nome dell'oggetto.

Tipo: stringa

Required: No

Valori consentiti: SessionStart, SessionTermination

WaitingTime

La durata massima degli script di sessione, in secondi.

Tipo: integer

Required: No

Limiti: la durata massima è di 60 secondi. Se gli script di sessione non sono completati entro tale durata, vengono arrestati. Se per continuare l'esecuzione è necessario uno script, avviarlo come un processo separato.

Eseguibili

I dettagli per gli script di sessione da eseguire.

Tipo: stringa

Campo obbligatorio: sì

Limiti: il numero massimo di script che può essere eseguito per ogni evento della sessione è 2 (uno per il contesto dell'utente, uno per il contesto di sistema).

Contesto

Il contesto in cui eseguire lo script di sessione.

Tipo: stringa

Campo obbligatorio: sì

Valori consentiti: user, system

Nome di file

Il percorso completo dello script di sessione da eseguire. Se il parametro non è specificato, lo script di sessione non viene eseguito.

Tipo: stringa

Required: No

Limiti: la lunghezza massima per il nome del file e il percorso completo è pari a 1.000 caratteri.

Valori .exe consentiti:,, .bat .sh

Nota

È inoltre possibile utilizzare PowerShell file di Windows. Per ulteriori informazioni, consulta Utilizzo dei file di Windows PowerShell .

Arguments (Argomenti)

Gli argomenti per lo script di sessione o per il file eseguibile.

Tipo: stringa

Required: No

Limiti di lunghezza: la lunghezza massima è pari a 1.000 caratteri.

S3 LogEnabled

Quando il valore di questo parametro è impostato su True, viene creato un bucket S3 nell'account Amazon Web Services per archiviare i log creati dallo script di sessione. Per impostazione predefinita, questo valore è impostato su True. Per ulteriori informazioni, consulta la sezione Registrazione dell'output degli script di sessione riportata di seguito in questo argomento.

Tipo: Booleano

Required: No

Valori consentiti: True, False

Utilizzo dei file di Windows PowerShell

Per utilizzare PowerShell i file Windows, specifica il percorso completo del PowerShell file nel filename parametro:

"filename": 
"C:\\Windows\\System32\\WindowsPowerShell\\v1.0\\powershell.exe",

Quindi specifica lo script di sessione nel parametro arguments:

"arguments": "-File \"C:\\path\\to\\session\\script.ps1\"",

Infine, verificate che la politica di PowerShell esecuzione consenta l'esecuzione PowerShell del file.

Registrazione dell'output degli script di sessione

Quando questa opzione è abilitata nel file di configurazione, AppStream 2.0 acquisisce automaticamente l'output dallo script di sessione che viene scritto nello standard out. Questo output viene caricato in un bucket Amazon S3 nell'account. Puoi esaminare i file di log per la risoluzione dei problemi o per finalità di debugging.

Nota

I file di log vengono caricati quando lo script di sessione restituisce un valore o quando il valore impostato in WaitingTime è scaduto.

Utilizzo dei connettori di storage con script di sessione

Quando i connettori di archiviazione AppStream 2.0 sono abilitati, iniziano a montarsi quando vengono eseguiti gli script di avvio della sessione. Se lo script si basa sul montaggio dei connettori di archiviazione, è possibile attendere che i connettori siano disponibili. AppStream 2.0 mantiene lo stato di montaggio dei connettori di archiviazione nel registro di Windows sulle istanze Windows, con la seguente chiave:

<provided user name>HKEY_LOCAL_MACHINE\ SOFTWARE\ Amazon\\ Storage\\ AppStream <Storage connector>

I valori della chiave di registro sono definiti come segue:

• Nome utente fornito: l'ID utente fornito mediante la modalità di accesso. Le modalità di accesso e il valore per ciascuna modalità sono definiti come segue:

  • Pool di utenti: l'indirizzo e-mail dell'utente

  • URL di streaming: lo UserID

  • SAML: il NameID. Se il nome utente include una barra (ad esempio, SAM di un utente di dominioAccountName), la barra viene sostituita da un carattere «-».

• Connettore di archiviazione: il connettore per l'opzione di archiviazione persistente abilitata per l'utente. I valori del connettore di storage sono indicati di seguito:

  • HomeFolder

  • GoogleDrive

  • OneDrive

Ogni chiave di registro del connettore di archiviazione contiene un valore MountStatusDWORD. La tabella seguente elenca i valori possibili per MountStatus.

Nota

Per visualizzare queste chiavi di registro, è necessario disporre di Microsoft.NET Framework versione 4.7.2 o successiva installato sull'immagine.

Valore	Descrizione
0	Connettore di storage non abilitato per questo utente
1	Installazione del connettore di storage in corso
2	Connettore di storage installato correttamente
3	Installazione del connettore di storage non riuscita
4	Il montaggio del connettore di storage è abilitato, ma non ancora montato

Nelle istanze Linux, puoi controllare lo stato di montaggio della cartella home osservando il valore di appstream_home_folder_mount_status nel file ~/.config/ -status. appstream-home-folder appstream-home-folder-mount

Valore	Descrizione
True	La home directory è stata montata correttamente
False	La home directory non è ancora montata

Abilitazione dell'archiviazione nel bucket Amazon S3 per i log di script delle sessioni

Quando abiliti la registrazione di Amazon S3 nella configurazione dello script di sessione, AppStream 2.0 acquisisce l'output standard dallo script di sessione. L'output viene periodicamente caricato in un bucket S3 nell'account Amazon Web Services. Per ogni AWS regione, la AppStream versione 2.0 crea un bucket nel tuo account che è unico per il tuo account e per la regione.

Non devi eseguire alcuna attività di configurazione per gestire questi bucket S3. Sono completamente gestiti dal servizio AppStream 2.0. I file di log che sono archiviati in ogni bucket sono crittografati tramite endpoint SSL di Amazon S3 quando in transito; vengono invece crittografati mediante chiavi di crittografia gestite da Amazon S3 se inattivi. I bucket vengono denominati in un formato specifico come segue:

appstream-logs-region-code-account-id-without-hyphens-random-identifier

region-code

Questo è il codice AWS regionale in cui viene creato lo stack con lo storage di bucket Amazon S3 abilitato per i log degli script di sessione.

account-id-without-hyphens

L'identificatore dell'account Amazon Web Services. L'ID casuale garantisce che non vi sia alcun conflitto con altri bucket in quella regione. La prima parte del nome del bucket, appstream-logs, resta uguale in tutti gli account o le regioni.

Ad esempio, se specifichi script di sessione in un'immagine nella regione Stati Uniti occidentali (Oregon) (us-west-2) con il numero di account 123456789012, 2.0 AppStream crea un bucket Amazon S3 all'interno del tuo account in quella regione con il nome mostrato. Solo un amministratore con autorizzazioni sufficienti può eliminare il bucket.

appstream-logs-us-west-2-1234567890123-abcdefg

La disabilitazione degli script di sessione non elimina nessun file di log memorizzato nel bucket S3. Per eliminare definitivamente i file di registro, tu o un altro amministratore con autorizzazioni adeguate dovete farlo utilizzando la console o l'API di Amazon S3. AppStream 2.0 aggiunge una policy sui bucket che impedisce l'eliminazione accidentale del bucket. Per ulteriori informazioni, consulta la sezione relativa a policy IAM e bucket S3 per la persistenza delle impostazioni dell'applicazione in Identity and Access Management per Amazon AppStream 2.0.

Quando gli script di sessione sono abilitati, viene creata una cartella univoca per ogni sessione di streaming avviata.

Il percorso per la cartella in cui i file di log vengono memorizzati nel bucket S3 nel tuo account utilizza la seguente struttura:

bucket-name/stack-name/fleet-name/access-mode/user-id-SHA-256-hash/session-id/SessionScriptsLogs/session-event

bucket-name

Il nome del bucket S3 in cui sono archiviati gli script di sessione. Il formato del nome è descritto precedentemente in questa sezione.

stack-name

Il nome dello stack da cui proviene la sessione.

fleet-name

Il nome del parco istanze sul quale lo script di sessione è in esecuzione.

access-mode

Il metodo di identità dell'utente: custom per l'API o la CLI AppStream 2.0, federated per SAML e userpool per gli utenti del pool di utenti.

user-id-SHA-256-hash

Il nome di cartella specifico dell'utente. Questo nome viene creato utilizzando una stringa esadecimale hash SHA-256 minuscola generata dall'identificatore utente.

session-id

L'identificatore di sessione della sessione di streaming dell'utente. Ogni sessione di streaming dell'utente genera un ID univoco.

session-event

L'evento che ha generato il log dello script di sessione. I valori dell'evento sono: SessionStart e SessionTermination.

L'esempio seguente di struttura della cartella si applica a una sessione di streaming avviata da test-stack e test-fleet. La sessione utilizza l'API dell'ID [e-mail], proveniente da un Account AWS ID di123456789012, e il gruppo di impostazioni test-stack nella regione Stati Uniti occidentali (Oregon) (us-west-2):

appstream-logs-us-west-2-1234567890123-abcdefg/test-stack/test-fleet/custom/a0bcb1da11f480d9b5b3e90f91243143eac04cfccfbdc777e740fab628a1cd13/05yd1391-4805-3da6-f498-76f5x6746016/SessionScriptsLogs/SessionStart/

In questo esempio la struttura della cartella contiene un file di log per uno script di avvio sessione del contesto dell'utente e un file di log per uno script di avvio sessione del contesto di sistema, se applicabile.

Usa gli script di sessione su flotte multisessione

Quando si utilizzano script di sessione su flotte multisessione, esistono requisiti e considerazioni aggiuntivi per garantire prestazioni e sicurezza ottimali.

Requisiti

In una flotta a sessione singola, per un determinato esempio, è garantito che gli SessionStarte SessionTerminationhook vengano eseguiti una sola volta. Questo perché esiste una mappatura 1:1 delle sessioni alle istanze. Quando si utilizzano flotte multisessione, esiste una mappatura N:M delle sessioni alle istanze, in cui ogni sessione viene eseguita autonomamente e si aggancia. SessionStartSessionTermination Ciò significa che gli SessionStartand SessionTerminationhook possono essere eseguiti più volte su una determinata istanza e in molti ordini diversi. Per un'esperienza ottimale, per gli script di sessione utilizzati su flotte multisessione dovrebbe valere quanto segue:

• Gli script sono idempotenti.

  Quando un'azione è già stata eseguita, gli script devono gestire più di un'esecuzione sulla stessa istanza con una gestione corretta.

• Gli script sono indipendenti.

  Poiché gli script vengono eseguiti per sessione, se una sessione è in esecuzione SessionTerminationmentre un'altra è in esecuzione SessionStart, non devono interferire tra loro o con l'esperienza di altre sessioni.

• Gli script sono performanti.

  Nelle istanze multisessione, è possibile effettuare il provisioning di più sessioni contemporaneamente. Ciò significa che possono esserci più esecuzioni simultanee degli script di sessione. Gli script devono essere efficienti, non consumare risorse eccessive e non influire sull'esperienza degli altri utenti sull'istanza o sulla stabilità delle sessioni.

Molti di questi requisiti possono essere soddisfatti mantenendo la logica degli script di sessione incentrata sulla sessione utente specifica per la quale lo script è in esecuzione.

Considerazioni sulla sicurezza

AppStream Le immagini 2.0 non devono essere configurate per consentire l'autorizzazione di scrittura ai file di script di sessione da parte di alcun utente. Ciò introduce un vettore di attacco fondamentale per gli utenti malintenzionati, che possono modificare i file di script. Questi file potrebbero quindi essere eseguiti come SYSTEM o come un altro utente, a seconda della configurazione.

Importante

È responsabilità dell'utente assicurarsi che le immagini AppStream 2.0 siano configurate in modo sicuro. Ciò è particolarmente importante per le istanze multisessione, in cui più utenti utilizzano la stessa istanza. Se le immagini non sono configurate in modo sicuro, esiste un rischio di sicurezza per tutti gli utenti di quell'istanza.

Per le immagini e i file degli script di sessione dovrebbe valere quanto segue:

• Gli utenti non sono autorizzati a modificare i file degli script di sessione.

• Gli utenti non sono autorizzati a modificare lo script di sessione config.json. Il comportamento predefinito dell'immagine limita l'accesso agli amministratori.

Gli eseguibili degli script di sessione devono essere archiviati in un luogo sicuro, al riparo da modifiche in fase di esecuzione.

Se il servizio rileva che l'eseguibile di uno script di sessione è stato modificato, fallirà tutte le successive esecuzioni di quell'hook su quell'istanza, caricherà i file di registro su Amazon S3 (se la registrazione Amazon S3 è abilitata) e verrà visualizzato il seguente messaggio:

Lo script di sessione non è stato eseguito perché l'eseguibile è stato modificato dopo il provisioning dell'istanza. L'esecuzione è stata ignorata per motivi di sicurezza.

Se il caso d'uso richiede la modifica dell'eseguibile dello script di sessione in fase di esecuzione (ad esempio, se si punta a un file EXE modificato da un processo di aggiornamento automatico in fase di esecuzione), i controlli precedenti non supereranno. In questo caso, utilizzate uno script per reindirizzare l'esecuzione all'eseguibile modificato. Lasciate lo script invariato in fase di esecuzione quando il servizio esegue i controlli di sicurezza.

Se i file degli script di sessione sono eccessivamente grandi (più di 100 MB), ciò può causare ritardi nel provisioning dell'istanza e della sessione e i controlli di sicurezza richiederanno più tempo (a seconda del tipo di istanza e delle risorse disponibili). Se il tuo caso d'uso richiede script di sessione di grandi dimensioni, prendi in considerazione l'utilizzo di script più piccoli per reindirizzare l'esecuzione. Ciò migliorerà le esperienze di provisioning di istanze e sessioni.

Nota che il servizio controlla solo l'eseguibile definito negli script di sessione config.json e questo è solo un meccanismo di fallback/best effort. È responsabilità dell'utente garantire che tutti i percorsi di codice negli eseguibili degli script di sessione siano sicuri e non possano essere modificati dagli utenti finali.