Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Le migliori pratiche di sicurezza per Deadline Cloud
<a name="security-best-practices"></a>

AWS Deadline Cloud (Deadline Cloud) offre una serie di funzionalità di sicurezza da considerare durante lo sviluppo e l'implementazione delle proprie politiche di sicurezza. Le seguenti best practice sono linee guida generali e non rappresentano una soluzione di sicurezza completa. Poiché queste best practice potrebbero non essere appropriate o sufficienti per l’ambiente, sono da considerare come considerazioni utili anziché prescrizioni.

**Nota**  
Per ulteriori informazioni sull'importanza di molti argomenti relativi alla sicurezza, consulta il Modello di [responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/).

## Protezione dei dati
<a name="data_protection"></a>

Ai fini della protezione dei dati, ti consigliamo di proteggere Account AWS le credenziali e configurare account individuali con AWS Identity and Access Management (IAM). In tal modo, a ogni utente verranno assegnate solo le autorizzazioni necessarie per svolgere i suoi compiti. Suggeriamo, inoltre, di proteggere i dati nei seguenti modi:
+ Utilizza l’autenticazione a più fattori (MFA) con ogni account.
+  SSL/TLS Da utilizzare per comunicare con AWS le risorse. È richiesto TLS 1.2 ed è consigliato TLS 1.3.
+ Configura l'API e la registrazione delle attività degli utenti con AWS CloudTrail.
+ Utilizza soluzioni di AWS crittografia, insieme a tutti i controlli di sicurezza predefiniti all'interno Servizi AWS.
+ Utilizza servizi di sicurezza gestiti avanzati come Amazon Macie, che aiuta a scoprire e proteggere i dati personali archiviati in Amazon Simple Storage Service (Amazon S3).
+ Se necessiti di moduli crittografici convalidati FIPS 140-2 quando accedi ad AWS attraverso un'interfaccia a riga di comando o un'API, utilizza un endpoint FIPS. Per ulteriori informazioni sugli endpoint FIPS disponibili, consulta il [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/).

Consigliamo di non inserire mai informazioni identificative sensibili, ad esempio i numeri di account dei clienti, in campi a formato libero come un campo **Nome**. Questa raccomandazione include quando lavori con AWS Deadline Cloud o altro Servizi AWS utilizzando la console, l'API o. AWS CLI AWS SDKs Tutti i dati che inserisci in Deadline Cloud o in altri servizi potrebbero essere raccolti per essere inclusi nei registri di diagnostica. Quando fornisci un URL a un server esterno, non includere informazioni sulle credenziali nell'URL per convalidare la tua richiesta a tale server.

## AWS Identity and Access Management autorizzazioni
<a name="iam-permissions"></a>

Gestisci l'accesso alle AWS risorse utilizzando utenti, ruoli AWS Identity and Access Management (IAM) e concedendo il minimo privilegio agli utenti. Stabilisci politiche e procedure di gestione delle credenziali per creare, distribuire, ruotare e revocare le credenziali di accesso. AWS Per ulteriori informazioni, consulta [Best practice IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) nella *Guida per l'utente di IAM*.

## Esegui lavori come utenti e gruppi
<a name="job-run-as-user"></a>

Quando si utilizza la funzionalità di coda in Deadline Cloud, è consigliabile specificare un utente del sistema operativo (OS) e il relativo gruppo primario in modo che l'utente del sistema operativo disponga delle autorizzazioni con privilegi minimi per i lavori della coda.

Quando specifichi un «Esegui come utente» (e gruppo), tutti i processi per i lavori inviati alla coda verranno eseguiti utilizzando quell'utente del sistema operativo e erediteranno le autorizzazioni del sistema operativo associate a quell'utente.

Le configurazioni della flotta e della coda si combinano per stabilire un livello di sicurezza. Sul lato della coda, è possibile specificare il ruolo «Job run as user» e IAM per utilizzare il sistema operativo e AWS le autorizzazioni per i lavori della coda. La flotta definisce l'infrastruttura (worker host, reti, storage condiviso montato) che, se associata a una particolare coda, esegue i lavori all'interno della coda. I job di una o più code associate devono accedere ai dati disponibili sugli host dei worker. Specificare un utente o un gruppo aiuta a proteggere i dati nei lavori da altre code, da altri software installati o da altri utenti con accesso agli host di lavoro. Quando una coda è priva di un utente, viene eseguita come utente agente che può impersonare () `sudo` qualsiasi utente della coda. In questo modo, una coda senza utente può trasferire i privilegi a un'altra coda.

## Rete
<a name="networking"></a>

Per evitare che il traffico venga intercettato o reindirizzato, è essenziale proteggere come e dove viene instradato il traffico di rete.

Ti consigliamo di proteggere il tuo ambiente di rete nei seguenti modi:
+ Proteggi le tabelle di routing delle sottoreti di Amazon Virtual Private Cloud (Amazon VPC) per controllare come viene instradato il traffico a livello IP.
+ Se utilizzi Amazon Route 53 (Route 53) come provider DNS nella configurazione della tua farm o workstation, accedi in modo sicuro all'API Route 53.
+ Se ti connetti a Deadline Cloud all'esterno, AWS ad esempio utilizzando workstation locali o altri data center, proteggi qualsiasi infrastruttura di rete locale. Ciò include server DNS e tabelle di routing su router, switch e altri dispositivi di rete.

## Lavori e dati sui lavori
<a name="secure-job-data"></a>

I job di Deadline Cloud vengono eseguiti all'interno delle sessioni sugli host dei lavoratori. Ogni sessione esegue uno o più processi sull'host di lavoro, che in genere richiedono l'immissione di dati per produrre l'output. 

Per proteggere questi dati, è possibile configurare gli utenti del sistema operativo con code. L'agente di lavoro utilizza l'utente del sistema operativo in coda per eseguire i sottoprocessi della sessione. Questi sottoprocessi ereditano le autorizzazioni dell'utente del sistema operativo di coda.

Ti consigliamo di seguire le migliori pratiche per proteggere l'accesso ai dati a cui accedono questi sottoprocessi. Per ulteriori informazioni, consulta [Modello di responsabilità condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/).

## Struttura dell'azienda
<a name="farm-structure"></a>

Puoi organizzare le flotte e le code di Deadline Cloud in molti modi. Tuttavia, alcune disposizioni hanno implicazioni in termini di sicurezza.

Una farm ha uno dei confini più sicuri perché non può condividere le risorse di Deadline Cloud con altre aziende agricole, tra cui flotte, code e profili di archiviazione. Tuttavia, puoi condividere AWS risorse esterne all'interno di una farm, il che compromette i limiti di sicurezza.

È inoltre possibile stabilire limiti di sicurezza tra le code all'interno della stessa farm utilizzando la configurazione appropriata.

Segui queste procedure consigliate per creare code sicure nella stessa farm:
+ Associa una flotta solo alle code all'interno dello stesso limite di sicurezza. Tenere presente quanto segue:
  + Dopo l'esecuzione del processo sull'host del lavoratore, i dati potrebbero rimanere indietro, ad esempio in una directory temporanea o nella home directory dell'utente in coda.
  + Lo stesso utente del sistema operativo esegue tutti i lavori su un host Fleet Worker di proprietà del servizio, indipendentemente dalla coda a cui viene inviato il lavoro.
  + Un job può lasciare i processi in esecuzione su un worker host, permettendo ai job di altre code di osservare altri processi in esecuzione.
+ Assicurati che solo le code all'interno dello stesso limite di sicurezza condividano un bucket Amazon S3 per gli allegati dei lavori.
+ Assicurati che solo le code all'interno dello stesso limite di sicurezza condividano un utente del sistema operativo.
+ Proteggi tutte AWS le altre risorse integrate nella farm fino al limite.

## Code di allegati Job
<a name="job-attachment-queues"></a>

Gli allegati Job sono associati a una coda, che utilizza il tuo bucket Amazon S3.
+ Gli allegati di lavoro scrivono e leggono da un prefisso root nel bucket Amazon S3. È necessario specificare questo prefisso root nella chiamata API. `CreateQueue`
+ Il bucket ha un corrispondente`Queue Role`, che specifica il ruolo che concede agli utenti della coda l'accesso al bucket e al prefisso root. Quando crei una coda, specifichi l'`Queue Role`Amazon Resource Name (ARN) insieme al bucket degli allegati del lavoro e al prefisso root.
+ Le chiamate autorizzate a `AssumeQueueRoleForRead``AssumeQueueRoleForUser`, e le operazioni `AssumeQueueRoleForWorker` API restituiscono una serie di credenziali di sicurezza temporanee per. `Queue Role` 

Se crei una coda e riutilizzi un bucket Amazon S3 e un prefisso root, c'è il rischio che le informazioni vengano divulgate a parti non autorizzate. Ad esempio, QueueA e QueueB condividono lo stesso bucket e lo stesso prefisso root. In un flusso di lavoro sicuro, Artista ha accesso a QueueA ma non a QueueB. Tuttavia, quando più code condividono un bucket, Artista può accedere ai dati nei dati di QueueB perché utilizza lo stesso bucket e lo stesso prefisso root di QueueA.

La console imposta code sicure per impostazione predefinita. Assicurati che le code abbiano una combinazione distinta di bucket Amazon S3 e prefisso root, a meno che non facciano parte di un limite di sicurezza comune. 

Per isolare le code, devi configurare per consentire l'accesso alla coda solo `Queue Role` al bucket e al prefisso root. Nell'esempio seguente, sostituisci ciascuno *placeholder* di essi con le informazioni specifiche della risorsa.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Action": [
                "s3:GetObject",
                "s3:PutObject",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Effect": "Allow",
            "Resource": [
                "arn:aws:s3:::JOB_ATTACHMENTS_BUCKET_NAME",
                "arn:aws:s3:::JOB_ATTACHMENTS_BUCKET_NAME/JOB_ATTACHMENTS_ROOT_PREFIX/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:ResourceAccount": "111122223333"
                }
            }
        },
        {
            "Action": [
                "logs:GetLogEvents"
            ],
            "Effect": "Allow",
            "Resource": "arn:aws:logs:us-east-1:111122223333:log-group:/aws/deadline/FARM_ID/*"
        }
    ]
}
```

------

È inoltre necessario impostare una politica di fiducia per il ruolo. Nell'esempio seguente, sostituisci il *placeholder* testo con le informazioni specifiche della risorsa.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Principal": {
                "Service": "deadline.amazonaws.com"
            },
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                },
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:deadline:us-east-1:111122223333:farm/FARM_ID"
                }
            }
        },
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Effect": "Allow",
            "Principal": {
                "Service": "credentials.deadline.amazonaws.com"
            },
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                },
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:deadline:us-east-1:111122223333:farm/FARM_ID"
                }
            }
        }
    ]
}
```

------

## Bucket Amazon S3 software personalizzati
<a name="software-buckets"></a>

Puoi aggiungere la seguente dichiarazione alla tua richiesta di accesso `Queue Role` al software personalizzato nel tuo bucket Amazon S3. Nell'esempio seguente, sostituiscilo *SOFTWARE\$1BUCKET\$1NAME* con il nome del bucket S3 e *BUCKET\$1ACCOUNT\$1OWNER* con l' Account AWS ID proprietario del bucket.

```
"Statement": [ 
    {
        "Action": [
            "s3:GetObject",
            "s3:ListBucket"
        ],
        "Effect": "Allow",
        "Resource": [
            "arn:aws:s3:::SOFTWARE_BUCKET_NAME",
            "arn:aws:s3:::SOFTWARE_BUCKET_NAME/*"
        ],
        "Condition": {
         "StringEquals": {
            "aws:ResourceAccount": "BUCKET_ACCOUNT_OWNER"
         }
      }
    }
]
```

Per ulteriori informazioni sulle best practice di sicurezza di Amazon S3, consulta le best practice [di sicurezza per Amazon S3 nella Amazon Simple](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) *Storage Service User* Guide.

## Operatori ospitanti
<a name="worker-hosts"></a>

Proteggi gli host per i lavoratori per garantire che ogni utente possa eseguire operazioni solo per il ruolo assegnato. 

Consigliamo le seguenti best practice per proteggere gli host dei lavoratori: 
+ L'utilizzo di uno *script di configurazione dell'host* può modificare la sicurezza e le operazioni di un lavoratore. Una configurazione errata può causare l'instabilità o l'interruzione del lavoro del lavoratore. È responsabilità dell'utente eseguire il debug di tali errori.
+ Non utilizzare lo stesso `jobRunAsUser` valore con più code a meno che i lavori inviati a tali code non rientrino nello stesso limite di sicurezza.
+ Non impostate la coda `jobRunAsUser` sul nome dell'utente del sistema operativo con cui viene eseguito il worker agent.
+ Concedi agli utenti della coda le autorizzazioni del sistema operativo con i privilegi minimi necessarie per i carichi di lavoro in coda previsti. Assicurati che non dispongano delle autorizzazioni di scrittura del filesystem per i file di programma Work Agent o altro software condiviso. 
+ Assicurati che solo l'utente root Linux e il suo account siano `Administrator` proprietari e che possano modificare Windows i file di programma del worker agent.
+ Sugli host Linux worker, valuta la possibilità di configurare un `umask` override `/etc/sudoers` che consenta all'utente worker agent di avviare i processi come utenti in coda. Questa configurazione aiuta a garantire che altri utenti non possano accedere ai file scritti nella coda.
+ Concedi a persone fidate l'accesso con i privilegi minimi agli host dei lavoratori.
+ Limita le autorizzazioni al DNS locale, sostituisci i file di configurazione (`/etc/hosts`attivati e attivatiWindows) Linux e instrada le tabelle `C:\Windows\system32\etc\hosts` sulle workstation e sui sistemi operativi degli host di lavoro.
+ Limita le autorizzazioni alla configurazione DNS sulle workstation e sui sistemi operativi degli host di lavoro.
+ Applicate regolarmente patch al sistema operativo e a tutto il software installato. Questo approccio include software utilizzati specificamente con Deadline Cloud come mittenti, adattatori, agenti di lavoro, OpenJD pacchetti e altro. 
+ Usa password complesse per la coda. Windows `jobRunAsUser`
+ Ruota regolarmente le password per la coda. `jobRunAsUser`
+ Garantisci l'accesso con il minimo privilegio alle Windows password segrete ed elimina quelle inutilizzate.
+ Non `jobRunAsUser` autorizzate la coda a eseguire i comandi di pianificazione in futuro:
  + SìLinux, nega a questi account l'accesso a `cron` e. `at`
  + SìWindows, nega a questi account l'accesso al Windows task scheduler.

**Nota**  
Per ulteriori informazioni sull'importanza di applicare regolarmente patch al sistema operativo e al software installato, consulta il Modello di responsabilità [condivisa](https://aws.amazon.com/compliance/shared-responsibility-model/).

## Script di configurazione dell'host
<a name="worker-script"></a>
+ L'utilizzo di uno script di configurazione dell'host può modificare la sicurezza e le operazioni di un lavoratore. Una configurazione errata può causare l'instabilità o l'interruzione del lavoro del lavoratore. È responsabilità dell'utente eseguire il debug di tali errori.

## Workstation
<a name="workstations"></a>

È importante proteggere le workstation con accesso a Deadline Cloud. Questo approccio aiuta a garantire che tutti i lavori che invii a Deadline Cloud non possano eseguire carichi di lavoro arbitrari fatturati a te. Account AWS

Consigliamo le seguenti best practice per proteggere le postazioni di lavoro degli artisti. Per ulteriori informazioni, consultare il [ Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/) (Modello di responsabilità condivisa).
+ Proteggi tutte le credenziali permanenti che forniscono l'accesso a AWS, incluso Deadline Cloud. Per ulteriori informazioni, consulta [Gestione delle chiavi di accesso per gli utenti IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#securing_access-keys) nella *Guida per l’utente di IAM *.
+ Installa solo software affidabile e sicuro. 
+ Richiedi agli utenti di federarsi con un provider di identità per accedere AWS con credenziali temporanee.
+ Utilizza le autorizzazioni sicure sui file di programma del mittente di Deadline Cloud per evitare manomissioni.
+ Concedi alle persone fidate l'accesso meno privilegiato alle postazioni di lavoro degli artisti.
+ Utilizza solo i mittenti e gli adattatori che ottieni tramite Deadline Cloud Monitor.
+ Limita le autorizzazioni al DNS localemacOS, sostituisci i file di configurazione (attivati e `/etc/hosts` attivatiWindows) Linux e instrada le tabelle `C:\Windows\system32\etc\hosts` sulle workstation e sui sistemi operativi host dei lavoratori.
+ Limita le autorizzazioni alle workstation e ai `/etc/resolve.conf` sistemi operativi host dei lavoratori.
+ Applicate regolarmente patch al sistema operativo e a tutto il software installato. Questo approccio include software utilizzati specificamente con Deadline Cloud come mittenti, adattatori, agenti di lavoro, OpenJD pacchetti e altro. 

## Verifica l'autenticità del software scaricato
<a name="verify-installer"></a>

Verifica l'autenticità del software dopo aver scaricato il programma di installazione per proteggerlo dalla manomissione dei file. Questa procedura funziona per entrambi i sistemi. Windows Linux

------
#### [ Windows ]

Per verificare l'autenticità dei file scaricati, completa i seguenti passaggi.

1. Nel comando seguente, `file` sostituiscilo con il file che desideri verificare. Ad esempio, ** *C:\$1PATH\$1TO\$1MY\$1*DeadlineCloudSubmitter-windows-x64-installer.exe **. Inoltre, `signtool-sdk-version` sostituiscilo con la versione dell'SignToolSDK installata. Ad esempio, **10.0.22000.0**.

   `"C:\Program Files (x86)\Windows Kits\10\bin\signtool-sdk-version\x86\signtool.exe" verify /vfile`

1. Ad esempio, puoi verificare il file di installazione del submitter di Deadline Cloud eseguendo il seguente comando:

   `"C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\signtool.exe" verify /v DeadlineCloudSubmitter-windows-x64-installer.exe`

------
#### [ Linux ]

Per verificare l'autenticità dei file scaricati, utilizza lo strumento da riga di comando. `gpg`

1. Importa la `OpenPGP` chiave eseguendo il seguente comando:

   ```
    gpg --import --armor <<EOF
   -----BEGIN PGP PUBLIC KEY BLOCK-----
   
   mQINBGlANDUBEACg6zffjN43gqe5ryPhk+wQM10rEdvmItw4WPWaVsN+/at/OIJw
   MGCagSYXcgR+jKbsHQOQoEQdo5SrxxHjpKTEs3KQhGvf+ehrU1Ac7koXKIBWtes+
   BI9F0slRECz0nXTOy/cd/90RXjpF07mreTLIKNIbybULfad82nYykpITjFr5XRGj
   /shYkucxRQZdwkgkIYyV25pPICPd2RsX+Zua85jV8mCqVffDfRXvgcPe3+ofClj/
   2CE8UfUIqO8Csua4YEkSqr3aeoTOEFT4kuQR5nFXVzorOEkQtO3gB35KNWKMlIOU
   2vA+wyoL7nWSii4yfYtW3EZ+3gq6HxvnT9Zs8MC53uTOiOdamASXecYREwGmY/io
   6n5XTEA/35LNbl4A756vSTZ7h4VFJAN5BpuqxstI1D7ou94skoSmcPoC/iniTvY9
   kZylU5OCH/nifMAHM2a5jrQel80cW4oko9eyc8ENQpSy15JElFOKFf7D/4tcZJLF
   F0VBTXbhfvq3dPfoq94IWt7p54Ovwj0S//CEu3jZYbNl2QC/3YiHE2H2XyGCQbq6
   2MjcuxLnEapoRIqfbi8GPtCWVPzm28WGyKIDofWICczzeJFFJnvzrY3wRG64ibKJ
   bR/uedwua1UuiC482V1FD5ffmzSSs8ktTp9hgj7RGDXlc9NTcF1jHxG9hwARAQAB
   tCxBV1MgRGVhZGxpbmUgQ2xvdWQgPGF3cy1kZWFkbGluZUBhbWF6b24uY29tPokC
   VwQTAQgAQRYhBJmXd7So2csyehiIYsg71N18bhtjBQJpQDQ1AhsvBQkDwmcABQsJ
   CAcCAiICBhUKCQgLAgQWAgMBAh4HAheAAAoJEMg71N18bhtjk2UP/3h4KlEzZO/7
   BxRmkbixuo1QuqOGvA6tXbSWaM8QH5jglcvL12PZLALklLT4v82uCsLR1lF8/Tch
   cCl0SZEOFIS+XxAaw1Xfai6jlyLhabOwKF2ylq5eJlLcw1lh2nAArDRb4fLD0m1g
   Dfqetq/XEpyXpOSkWxGRV4RlUdjQfytxrmcUnsT5/fk5f9VDdblu6K/lEmwfyYjB
   lXv0uUCkqPot0SmbvOh3PY3Hi3n54ncy8NfTeV+TUvSe3C1s1zNl8aqHoTxJB/eU
   kp+LFZ9m+igpSYnKeglKnytylH3KGCjTHglT/QXnI1wNTqmj1kFBVwtt/y1mtnA+
   CPIUHP1CtbKsHaLtpp4llBm5TVtPN/Wqqicn5QLl4khg7R4K+V2aaA4ubY6p1tG9
   0fFhN5tTnHDSKWMfmb83wfh5Zkcg85c3egjoit+wgGQRAQVqbznx7NqAHs9VoDIu
   SPcAr+C329AOBzod4gyNGH7Ah5DkMITo4O4+axnAU9yhFOHcMJmTIask/fNg1Aum
   OqYPMUwcgv1GZjLaTJyfGGC1xALsYR0KHnwIehD06MHR/Z98bGkcV8+Y0q8UPsd1
   VN1fc1rjCJh/AT3w6owvG4DaEwspseSjzHv16mW4e2N6Uu23SPzgQsJ5qYN2g8D+
   P7N9LGDfP8DaYc5JM9mlyFmYI2Q94ufL
   =rY5l
   -----END PGP PUBLIC KEY BLOCK-----
   EOF
   ```

1. Determina se fidarti della `OpenPGP` chiave. Alcuni fattori da considerare quando si decide se considerare attendibile la chiave di cui sopra sono i seguenti:
   + La connessione Internet che hai utilizzato per ottenere la chiave GPG da questo sito Web è sicura.
   + Il dispositivo da cui accedi a questo sito Web è sicuro.
   + AWS ha adottato misure per proteggere l'hosting della chiave `OpenPGP` pubblica su questo sito web.

1. Se decidi di considerare attendibile la OpenPGP chiave, modifica la chiave in modo affidabile con `gpg` un metodo simile al seguente esempio:

   ```
   $ gpg --edit-key 0xB840C08C29A90796A071FAA5F6CD3CE6B76F3CEF
   
       gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
       This is free software: you are free to change and redistribute it.
       There is NO WARRANTY, to the extent permitted by law.
   
   
       pub  4096R/4BF0B8D2  created: 2023-06-23  expires: 2025-06-22  usage: SCEA
                            trust: unknown       validity: unknown
       [ unknown] (1). AWS Deadline Cloud example@example.com
   
       gpg> trust
       pub  4096R/4BF0B8D2  created: 2023-06-23  expires: 2025-06-22  usage: SCEA
                            trust: unknown       validity: unknown
       [ unknown] (1). AWS Deadline Cloud aws-deadline@amazon.com
   
       Please decide how far you trust this user to correctly verify other users' keys
       (by looking at passports, checking fingerprints from different sources, etc.)
   
         1 = I don't know or won't say
         2 = I do NOT trust
         3 = I trust marginally
         4 = I trust fully
         5 = I trust ultimately
         m = back to the main menu
   
       Your decision? 5
       Do you really want to set this key to ultimate trust? (y/N) y
   
       pub  4096R/4BF0B8D2  created: 2023-06-23  expires: 2025-06-22  usage: SCEA
                            trust: ultimate      validity: unknown
       [ unknown] (1). AWS Deadline Cloud aws-deadline@amazon.com
       Please note that the shown key validity is not necessarily correct
       unless you restart the program.
   
       gpg> quit
   ```

1. 

**Verifica il programma di installazione del mittente di Deadline Cloud**

   Per verificare il programma di installazione di Deadline Cloud Submitter, completa i seguenti passaggi:

   1. Scarica il file di firma per il programma di installazione del mittente di Deadline Cloud.

      [Scarica il file della firma (.sig)](https://downloads.deadlinecloud.amazonaws.com/submitters/latest/linux/DeadlineCloudSubmitter-linux-x64-installer.run.sig)

   1. Verifica la firma del programma di installazione del mittente di Deadline Cloud eseguendo:

      ```
      gpg --verify ./DeadlineCloudSubmitter-linux-x64-installer.run.sig ./DeadlineCloudSubmitter-linux-x64-installer.run
      ```

1. 

**Verifica il monitor Deadline Cloud**
**Nota**  
Puoi verificare il download del monitor Deadline Cloud utilizzando file di firma o metodi specifici della piattaforma. Per i metodi specifici della piattaforma, consulta la Linux (Debian) scheda, la scheda Linux (RPM) o la Linux (AppImage) scheda in base al tipo di file scaricato. 

   Per verificare l'applicazione desktop Deadline Cloud Monitor con i file di firma, completa i seguenti passaggi:

   1. Scarica il file di firma corrispondente per il tuo programma di installazione del monitor Deadline Cloud:
      + [Scarica il file di firma.deb](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor_amd64.deb.sig)
      + [Scarica il file di firma.rpm](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor.x86_64.rpm.sig)
      + [Scarica. AppImage file di firma](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor_amd64.AppImage.sig)

   1. Verifica la firma:

      **Per .deb:**

      ```
      gpg --verify ./deadline-cloud-monitor_amd64.deb.sig ./deadline-cloud-monitor_amd64.deb
      ```

      **Per .rpm:**

      ```
      gpg --verify ./deadline-cloud-monitor.x86_64.rpm.sig ./deadline-cloud-monitor.x86_64.rpm
      ```

      **Per. AppImage**:

      ```
      gpg --verify ./deadline-cloud-monitor_amd64.AppImage.sig ./deadline-cloud-monitor_amd64.AppImage
      ```

   1. Verificate che l'output sia simile al seguente:

      `gpg: Signature made Mon Apr 1 21:10:14 2024 UTC`

      `gpg: using RSA key B840C08C29A90796A071FAA5F6CD3CE6B7`

      Se l'output contiene la frase`Good signature from "AWS Deadline Cloud"`, significa che la firma è stata verificata con successo e puoi eseguire lo script di installazione del monitor Deadline Cloud.

**Chiavi storiche**

```
-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBGX6GQsBEADduUtJgqSXI+q76O6fsFwEYKmbnlyL0xKvlq32EZuyv0otZo5L
le4m5Gg52AzrvPvDiUTLooAlvYeozaYyirIGsK08Ydz0Ftdjroiuh/mw9JSJDJRI
rnRn5yKet1JFezkjopA3pjsTBP6lW/mb1bDBDEwwwtH0x9lV7A03FJ9T7Uzu/qSh
qO/UYdkafro3cPASvkqgDt2tCvURfBcUCAjZVFcLZcVD5iwXacxvKsxxS/e7kuVV
I1+VGT8Hj8XzWYhjCZxOLZk/fvpYPMyEEujN0fYUp6RtMIXve0C9awwMCy5nBG2J
eE2Ol5DsCpTaBd4Fdr3LWcSs8JFA/YfP9auL3NczOozPoVJt+fw8CBlVIXO0J7l5
hvHDjcC+5v0wxqAlMG6+f/SX7CT8FXK+L3iOJ5gBYUNXqHSxUdv8kt76/KVmQa1B
Akl+MPKpMq+lhw++S3G/lXqwWaDNQbRRw7dSZHymQVXvPp1nsqc3hV7KlOM+6s6g
1g4mvFY4lf6DhptwZLWyQXU8rBQpojvQfiSmDFrFPWFi5BexesuVnkGIolQoklKx
AVUSdJPVEJCteyy7td4FPhBaSqT5vW3+ANbr9b/uoRYWJvn17dN0cc9HuRh/Ai+I
nkfECo2WUDLZ0fEKGjGyFX+todWvJXjvc5kmE9Ty5vJp+M9Vvb8jd6t+mwARAQAB
tCxBV1MgRGVhZGxpbmUgQ2xvdWQgPGF3cy1kZWFkbGluZUBhbWF6b24uY29tPokC
VwQTAQgAQRYhBLhAwIwpqQeWoHH6pfbNPOa3bzzvBQJl+hkLAxsvBAUJA8JnAAUL
CQgHAgIiAgYVCgkICwIDFgIBAh4HAheAAAoJEPbNPOa3bzzvKswQAJXzKSAY8sY8
F6Eas2oYwIDDdDurs8FiEnFghjUEO6MTt9AykF/jw+CQg2UzFtEyObHBymhgmhXE
3buVeom96tgM3ZDfZu+sxi5pGX6oAQnZ6riztN+VpkpQmLgwtMGpSMLl3KLwnv2k
WK8mrR/fPMkfdaewB7A6RIUYiW33GAL4KfMIs8/vIwIJw99NxHpZQVoU6dFpuDtE
1OuxGcCqGJ7mAmo6H/YawSNp2Ns80gyqIKYo7o3LJ+WRroIRlQyctq8gnR9JvYXX
42ASqLq5+OXKo4qh81blXKYqtc176BbbSNFjWnzIQgKDgNiHFZCdcOVgqDhwO15r
NICbqqwwNLj/Fr2kecYx180Ktpl0jOOw5IOyh3bf3MVGWnYRdjvA1v+/CO+55N4g
z0kf50Lcdu5RtqV10XBCifn28pecqPaSdYcssYSRl5DLiFktGbNzTGcZZwITTKQc
af8PPdTGtnnb6P+cdbW3bt9MVtN5/dgSHLThnS8MPEuNCtkTnpXshuVuBGgwBMdb
qUC+HjqvhZzbwns8dr5WI+6HWNBFgGANn6ageYl58vVp0UkuNP8wcWjRARciHXZx
ku6W2jPTHDWGNrBQO2Fx7fd2QYJheIPPAShHcfJO+xgWCof45D0vAxAJ8gGg9Eq+
gFWhsx4NSHn2gh1gDZ41Ou/4exJ1lwPM
=uVaX
-----END PGP PUBLIC KEY BLOCK-----
EOF
```

------
#### [ Linux (AppImage) ]

Per verificare i pacchetti che utilizzano unLinux. AppImage binario, completa prima i passaggi 1-3 nella Linux scheda, quindi completa i passaggi seguenti.

1. Dalla AppImageUpdate [pagina](https://github.com/AppImageCommunity/AppImageUpdate/releases/tag/continuous) in poi GitHub, scarica il **validate-x86\$164. AppImage**file.

1. Dopo aver scaricato il file, per aggiungere i permessi di esecuzione, esegui il seguente comando.

   ```
   chmod a+x ./validate-x86_64.AppImage
   ```

1. Per aggiungere i permessi di esecuzione, esegui il comando seguente.

   ```
   chmod a+x ./deadline-cloud-monitor_<APP_VERSION>_amd64.AppImage
   ```

1. Per verificare la firma del monitor di Deadline Cloud, esegui il seguente comando.

   ```
   ./validate-x86_64.AppImage ./deadline-cloud-monitor_<APP_VERSION>_amd64.AppImage
   ```

   Se l'output contiene la frase`Validation successful`, significa che la firma è stata verificata con successo e puoi eseguire in sicurezza lo script di installazione del monitor di Deadline Cloud.

------
#### [ Linux (Debian) ]

Per verificare i pacchetti che utilizzano un Linux file binario.deb, completate prima i passaggi 1-3 nella scheda. Linux

**dpkg** è lo strumento principale per la gestione dei pacchetti nella maggior parte delle distribuzioni basate. debian Linux È possibile verificare il file.deb con lo strumento.

1. Scarica il file.deb del monitor Deadline Cloud:

   [Scarica Deadline Cloud monitor (.deb)](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor_amd64.deb)

1. Verifica il file.deb:

   ```
   dpkg-sig --verify deadline-cloud-monitor_amd64.deb
   ```

1. L'output sarà simile a:

   ```
   Processing deadline-cloud-monitor_amd64.deb...
   GOODSIG _gpgbuilder B840C08C29A90796A071FAA5F6CD3C 171200
   ```

1. Per verificare il file.deb, verificate che `GOODSIG` sia presente nell'output.

------
#### [ Linux (RPM) ]

Per verificare i pacchetti che utilizzano un Linux file binario .rpm, completate prima i passaggi 1-3 nella scheda. Linux

1. Scarica il file.rpm di Deadline Cloud monitor:

   [Scarica Deadline Cloud monitor (.rpm)](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor.x86_64.rpm)

1. Verifica il file.rpm:

   ```
   gpg --export --armor "Deadline Cloud" > key.pub
   sudo rpm --import key.pub
   rpm -K deadline-cloud-monitor.x86_64.rpm
   ```

1. L'output sarà simile a:

   ```
   deadline-cloud-monitor.x86_64.rpm: digests signatures OK
   ```

1. Per verificare il file.rpm, verificate che `digests signatures OK` sia presente nell'output.

------