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. # Bewährte Sicherheitsmethoden für Deadline Cloud AWS Deadline Cloud (Deadline Cloud) bietet eine Reihe von Sicherheitsfunktionen, die Sie bei der Entwicklung und Implementierung Ihrer eigenen Sicherheitsrichtlinien berücksichtigen sollten. Die folgenden bewährten Methoden sind allgemeine Richtlinien und keine vollständige Sicherheitslösung. Da diese bewährten Methoden für Ihre Umgebung möglicherweise nicht angemessen oder ausreichend sind, sollten Sie sie als hilfreiche Überlegungen und nicht als bindend ansehen. **Anmerkung** Weitere Informationen zur Bedeutung vieler Sicherheitsthemen finden Sie im [Modell der gemeinsamen Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/). ## Datenschutz Aus Datenschutzgründen empfehlen wir, dass Sie Ihre AWS-Konto Anmeldeinformationen schützen und individuelle Konten mit AWS Identity and Access Management (IAM) einrichten. So erhält jeder Benutzer nur die Berechtigungen, die zum Durchführen seiner Aufgaben erforderlich sind. Außerdem empfehlen wir, die Daten mit folgenden Methoden schützen: + Verwenden Sie für jedes Konto die Multi-Faktor-Authentifizierung (MFA). + Wird verwendet SSL/TLS , um mit AWS Ressourcen zu kommunizieren. Wir benötigen TLS 1.2 und empfehlen TLS 1.3. + Richten Sie die API und die Protokollierung von Benutzeraktivitäten mit ein AWS CloudTrail. + Verwenden Sie AWS Verschlüsselungslösungen zusammen mit allen darin enthaltenen Standardsicherheitskontrollen AWS-Services. + Verwenden Sie fortschrittliche verwaltete Sicherheitsdienste wie Amazon Macie, die Sie bei der Erkennung und Sicherung personenbezogener Daten unterstützen, die in Amazon Simple Storage Service (Amazon S3) gespeichert sind. + Wenn Sie für den Zugriff auf AWS über eine Befehlszeilenschnittstelle oder über eine API FIPS 140-2-validierte kryptografische Module benötigen, verwenden Sie einen FIPS-Endpunkt. Weitere Informationen über verfügbare FIPS-Endpunkte finden Sie unter [Federal Information Processing Standard (FIPS) 140-2](https://aws.amazon.com/compliance/fips/). Wir empfehlen dringend, in Freitextfeldern wie z. B. im Feld **Name** keine sensiblen, identifizierenden Informationen wie Kontonummern von Kunden einzugeben. Diese Empfehlung gilt auch, wenn Sie mit AWS Deadline Cloud oder anderen AWS-Services über die Konsole AWS CLI, API oder AWS SDKs arbeiten. Alle Daten, die Sie in Deadline Cloud oder andere Dienste eingeben, werden möglicherweise zur Aufnahme in Diagnoseprotokolle aufgenommen. Wenn Sie eine URL für einen externen Server bereitstellen, schließen Sie keine Anmeldeinformationen zur Validierung Ihrer Anforderung an den betreffenden Server in die URL ein. ## AWS Identity and Access Management Berechtigungen Verwalten Sie den Zugriff auf AWS Ressourcen mithilfe von Benutzern und AWS Identity and Access Management (IAM-) Rollen und indem Sie Benutzern die geringsten Rechte gewähren. Richten Sie Richtlinien und Verfahren zur Verwaltung von Anmeldeinformationen für die Erstellung, Verteilung, Rotation und den Widerruf AWS von Zugangsdaten ein. Weitere Informationen finden Sie unter [Bewährte Methoden für IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html) im *IAM-Benutzerhandbuch*. ## Führen Sie Jobs als Benutzer und Gruppen aus Bei der Verwendung der Warteschlangenfunktion in Deadline Cloud hat es sich bewährt, einen Betriebssystembenutzer (OS) und seine primäre Gruppe anzugeben, sodass der Betriebssystembenutzer die geringsten Rechte für die Jobs der Warteschlange hat. Wenn Sie die Option „Als Benutzer ausführen“ (und Gruppe) angeben, werden alle Prozesse für Jobs, die an die Warteschlange gesendet werden, mit diesem Betriebssystembenutzer ausgeführt und erben die zugehörigen Betriebssystemberechtigungen dieses Benutzers. Die Kombination der Flotten- und Warteschlangenkonfigurationen sorgt für ein gewisses Maß an Sicherheit. Auf der Warteschlangenseite können die Rolle „Job wird als Benutzer ausgeführt“ und die IAM-Rolle angegeben werden, um das Betriebssystem und die AWS Berechtigungen für die Jobs der Warteschlange zu verwenden. Die Flotte definiert die Infrastruktur (Worker-Hosts, Netzwerke, bereitgestellter gemeinsam genutzter Speicher), über die Jobs innerhalb der Warteschlange ausgeführt werden, sofern sie einer bestimmten Warteschlange zugeordnet sind. Auf die auf den Worker-Hosts verfügbaren Daten müssen Jobs aus einer oder mehreren zugehörigen Warteschlangen zugreifen können. Die Angabe eines Benutzers oder einer Gruppe trägt dazu bei, die Daten in Jobs vor anderen Warteschlangen, anderer installierter Software oder anderen Benutzern mit Zugriff auf die Worker-Hosts zu schützen. Wenn es in einer Warteschlange keinen Benutzer gibt, wird sie als Agent-Benutzer ausgeführt, der sich als (`sudo`) beliebiger Warteschlangenbenutzer ausgeben kann. Auf diese Weise kann eine Warteschlange ohne Benutzer Rechte an eine andere Warteschlange weiterleiten. ## Netzwerk Um zu verhindern, dass der Datenverkehr abgefangen oder umgeleitet wird, müssen Sie unbedingt sicherstellen, wie und wohin Ihr Netzwerkverkehr geleitet wird. Wir empfehlen Ihnen, Ihre Netzwerkumgebung auf folgende Weise zu sichern: + Sichere Subnetz-Routing-Tabellen für Amazon Virtual Private Cloud (Amazon VPC), um zu kontrollieren, wie der Datenverkehr auf IP-Ebene weitergeleitet wird. + Wenn Sie Amazon Route 53 (Route 53) als DNS-Anbieter in Ihrem Farm- oder Workstation-Setup verwenden, sichern Sie den Zugriff auf die Route 53-API. + Wenn Sie eine Verbindung zu Deadline Cloud außerhalb herstellen, AWS z. B. über lokale Workstations oder andere Rechenzentren, sichern Sie jede lokale Netzwerkinfrastruktur. Dazu gehören DNS-Server und Routing-Tabellen auf Routern, Switches und anderen Netzwerkgeräten. ## Jobs und Jobdaten Deadline Cloud-Jobs werden innerhalb von Sitzungen auf Worker-Hosts ausgeführt. In jeder Sitzung werden ein oder mehrere Prozesse auf dem Worker-Host ausgeführt. Für die Ausgabe müssen Sie in der Regel Daten eingeben. Um diese Daten zu sichern, können Sie Betriebssystembenutzer mit Warteschlangen konfigurieren. Der Worker-Agent verwendet den Warteschlangen-OS-Benutzer, um Sitzungsunterprozesse auszuführen. Diese Unterprozesse erben die Berechtigungen des Queue-OS-Benutzers. Wir empfehlen, dass Sie sich an bewährte Methoden halten, um den Zugriff auf die Daten, auf die diese Unterprozesse zugreifen, zu sichern. Weitere Informationen finden Sie unter [Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/). ## Struktur der Farm Sie können Deadline Cloud-Flotten und Warteschlangen auf viele Arten anordnen. Bestimmte Vereinbarungen haben jedoch Auswirkungen auf die Sicherheit. Eine Farm hat eine der sichersten Grenzen, da sie Deadline Cloud-Ressourcen nicht mit anderen Farmen teilen kann, einschließlich Flotten, Warteschlangen und Speicherprofilen. Sie können jedoch externe AWS Ressourcen innerhalb einer Farm gemeinsam nutzen, wodurch die Sicherheitsgrenze gefährdet wird. Mit der entsprechenden Konfiguration können Sie auch Sicherheitsgrenzen zwischen Warteschlangen innerhalb derselben Farm einrichten. Folgen Sie diesen bewährten Methoden, um sichere Warteschlangen in derselben Farm zu erstellen: + Ordnen Sie eine Flotte nur Warteschlangen innerhalb derselben Sicherheitsgrenze zu. Beachten Sie Folgendes: + Nachdem der Job auf dem Worker-Host ausgeführt wurde, können Daten zurückbleiben, z. B. in einem temporären Verzeichnis oder im Home-Verzeichnis des Warteschlangenbenutzers. + Derselbe Betriebssystembenutzer führt alle Jobs auf einem firmeneigenen Fleet-Worker-Host aus, unabhängig davon, an welche Warteschlange Sie den Job senden. + Ein Job kann dazu führen, dass Prozesse auf einem Worker-Host ausgeführt werden, sodass Jobs aus anderen Warteschlangen andere laufende Prozesse beobachten können. + Stellen Sie sicher, dass sich nur Warteschlangen innerhalb derselben Sicherheitsgrenze einen Amazon S3 S3-Bucket für Jobanhänge teilen. + Stellen Sie sicher, dass nur Warteschlangen innerhalb derselben Sicherheitsgrenze denselben Betriebssystembenutzer verwenden. + Sichern Sie alle anderen AWS Ressourcen, die in die Farm integriert sind, bis zur Grenze. ## Warteschlangen für Arbeitsanhänge Jobanhänge sind mit einer Warteschlange verknüpft, die Ihren Amazon S3 S3-Bucket verwendet. + Auftragsanhänge schreiben in ein Root-Präfix im Amazon S3 S3-Bucket und lesen aus diesem. Sie geben dieses Root-Präfix im `CreateQueue` API-Aufruf an. + Der Bucket hat ein entsprechendes`Queue Role`, das die Rolle spezifiziert, die Warteschlangenbenutzern Zugriff auf den Bucket und das Root-Präfix gewährt. Beim Erstellen einer Warteschlange geben Sie den `Queue Role` Amazon-Ressourcennamen (ARN) zusammen mit dem Bucket und dem Root-Präfix für Jobanhänge an. + Autorisierte Aufrufe von `AssumeQueueRoleForRead``AssumeQueueRoleForUser`, und `AssumeQueueRoleForWorker` API-Operationen geben einen Satz temporärer Sicherheitsanmeldedaten für die zurück`Queue Role`. Wenn Sie eine Warteschlange erstellen und einen Amazon S3 S3-Bucket und ein Root-Präfix wiederverwenden, besteht die Gefahr, dass Informationen an Unbefugte weitergegeben werden. QueueA und QueueB verwenden beispielsweise denselben Bucket und dasselbe Root-Präfix. In einem sicheren Workflow hat ArtistA Zugriff auf QueueA, aber nicht auf QueueB. Wenn sich jedoch mehrere Warteschlangen einen Bucket teilen, kann ArtistA auf die Daten in QueueB-Daten zugreifen, da es denselben Bucket und dasselbe Root-Präfix wie QueueA verwendet. Die Konsole richtet Warteschlangen ein, die standardmäßig sicher sind. Stellen Sie sicher, dass die Warteschlangen eine eindeutige Kombination aus Amazon S3 S3-Bucket und Root-Präfix haben, sofern sie nicht Teil einer gemeinsamen Sicherheitsgrenze sind. Um Ihre Warteschlangen zu isolieren, müssen Sie das so konfigurieren, `Queue Role` dass nur der Warteschlangenzugriff auf den Bucket und das Root-Präfix zulässig ist. Ersetzen Sie im folgenden Beispiel jedes *placeholder* durch Ihre ressourcenspezifischen Informationen. ------ #### [ 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/*" } ] } ``` ------ Sie müssen außerdem eine Vertrauensrichtlinie für die Rolle festlegen. Ersetzen Sie im folgenden Beispiel den *placeholder* Text durch Ihre ressourcenspezifischen Informationen. ------ #### [ 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" } } } ] } ``` ------ ## Amazon S3 S3-Buckets mit benutzerdefinierter Software Sie können die folgende Anweisung zu Ihrem hinzufügen, `Queue Role` um auf benutzerdefinierte Software in Ihrem Amazon S3 S3-Bucket zuzugreifen. Im folgenden Beispiel *SOFTWARE\$1BUCKET\$1NAME* ersetzen Sie es durch den Namen Ihres S3-Buckets und *BUCKET\$1ACCOUNT\$1OWNER* durch die AWS-Konto ID, der der Bucket gehört. ``` "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" } } } ] ``` Weitere Informationen zu den bewährten Sicherheitsmethoden von Amazon S3 finden Sie unter [Bewährte Sicherheitsmethoden für Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) im *Amazon Simple Storage Service-Benutzerhandbuch*. ## Worker-Hosts Schützen Sie Worker-Hosts, um sicherzustellen, dass jeder Benutzer nur Operationen für die ihm zugewiesene Rolle ausführen kann. Wir empfehlen die folgenden bewährten Methoden zur Sicherung von Worker-Hosts: + Die Verwendung eines *Host-Konfigurationsskripts* kann die Sicherheit und den Betrieb eines Workers ändern. Eine falsche Konfiguration kann dazu führen, dass der Worker instabil ist oder nicht mehr funktioniert. Es liegt in Ihrer Verantwortung, solche Fehler zu debuggen. + Verwenden Sie nicht denselben `jobRunAsUser` Wert für mehrere Warteschlangen, es sei denn, an diese Warteschlangen übermittelte Jobs liegen innerhalb derselben Sicherheitsgrenze. + Stellen Sie die Warteschlange nicht `jobRunAsUser` auf den Namen des Betriebssystembenutzers ein, unter dem der Worker-Agent ausgeführt wird. + Gewähren Sie Warteschlangenbenutzern die Betriebssystemberechtigungen mit den geringsten Rechten, die für die vorgesehenen Warteschlangenworkloads erforderlich sind. Stellen Sie sicher, dass sie keine Dateisystem-Schreibberechtigungen für Work-Agent-Programmdateien oder andere gemeinsam genutzte Software haben. + Stellen Sie sicher, dass nur der Root-Benutzer Linux und das Konto `Administrator` Eigentümer der Worker-Agent-Programmdateien sind und diese ändern können. Windows + Auf Linux Worker-Hosts sollten Sie erwägen, einen `umask` Override-Vorgang zu konfigurieren`/etc/sudoers`, der es dem Worker-Agent-Benutzer ermöglicht, Prozesse als Warteschlangenbenutzer zu starten. Diese Konfiguration trägt dazu bei, dass andere Benutzer nicht auf Dateien zugreifen können, die in die Warteschlange geschrieben wurden. + Gewähren Sie vertrauenswürdigen Personen den Zugriff auf Worker-Hosts mit den geringsten Rechten. + Beschränken Sie die Berechtigungen auf lokale DNS-Override-Konfigurationsdateien (`/etc/hosts`aktiviert Linux und aktiviertWindows) sowie `C:\Windows\system32\etc\hosts` auf das Routing von Tabellen auf Workstations und Worker-Host-Betriebssystemen. + Beschränken Sie die Berechtigungen für die DNS-Konfiguration auf Workstations und Worker-Host-Betriebssystemen. + Patchen Sie regelmäßig das Betriebssystem und die gesamte installierte Software. Dieser Ansatz umfasst Software, die speziell mit Deadline Cloud verwendet wird, wie z. B. Einreicher, Adapter, Worker Agents, OpenJD Pakete und andere. + Verwenden Sie sichere Passwörter für die Warteschlange. Windows `jobRunAsUser` + Wechseln Sie regelmäßig die Passwörter für Ihre Warteschlange`jobRunAsUser`. + Sorgen Sie für den Zugriff auf die Windows Kennwortgeheimnisse mit den geringsten Rechten und löschen Sie ungenutzte Geheimnisse. + Erteilen Sie der Warteschlange nicht die `jobRunAsUser` Erlaubnis, die Befehle für den Zeitplan in der future auszuführen: + EinLinux, verweigern Sie diesen Konten den Zugriff auf `cron` und`at`. + Ist diese Windows Option aktiviert, wird diesen Konten der Zugriff auf den Windows Taskplaner verweigert. **Anmerkung** Weitere Informationen darüber, wie wichtig es ist, das Betriebssystem und die installierte Software regelmäßig zu patchen, finden Sie im Modell der [gemeinsamen Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/). ## Host-Konfigurationsskript + Die Verwendung eines Host-Konfigurationsskripts kann die Sicherheit und den Betrieb eines Workers ändern. Eine falsche Konfiguration kann dazu führen, dass der Worker instabil ist oder nicht mehr funktioniert. Es liegt in Ihrer Verantwortung, solche Fehler zu debuggen. ## Workstations Es ist wichtig, Workstations mit Zugriff auf Deadline Cloud zu sichern. Dieser Ansatz trägt dazu bei, dass mit Jobs, die Sie an Deadline Cloud einreichen, keine beliebigen Workloads ausgeführt werden können, die Ihnen in Rechnung gestellt werden. AWS-Konto Wir empfehlen die folgenden bewährten Methoden zur Sicherung von Künstler-Workstations. Weitere Informationen finden Sie unter [-Modell der geteilten Verantwortung](https://aws.amazon.com/compliance/shared-responsibility-model/). + Sichern Sie alle dauerhaften Anmeldeinformationen, die Zugriff auf, einschließlich Deadline AWS Cloud, ermöglichen. Weitere Informationen finden Sie unter [Verwalten der Zugriffsschlüssel für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#securing_access-keys) im *-IAM-Benutzerhandbuch*. + Installieren Sie nur vertrauenswürdige, sichere Software. + Erfordern Sie, dass Benutzer sich mit einem Identitätsanbieter zusammenschließen, um AWS mit temporären Anmeldeinformationen zugreifen zu können. + Verwenden Sie sichere Berechtigungen für die Programmdateien von Deadline Cloud-Absendern, um Manipulationen zu verhindern. + Gewähren Sie vertrauenswürdigen Personen den Zugriff auf die Workstations von Künstlern mit den geringsten Rechten. + Verwenden Sie nur Einreicher und Adapter, die Sie über den Deadline Cloud Monitor erhalten. + Beschränken Sie die Berechtigungen auf lokale DNS-Override-Konfigurationsdateien (`/etc/hosts`an Linux undmacOS, und `C:\Windows\system32\etc\hosts` anWindows) und auf das Routing von Tabellen auf Workstations und Worker-Host-Betriebssystemen. + Beschränken Sie die Berechtigungen `/etc/resolve.conf` auf Workstations und Worker-Host-Betriebssystemen. + Patchen Sie regelmäßig das Betriebssystem und die gesamte installierte Software. Dieser Ansatz umfasst Software, die speziell mit Deadline Cloud verwendet wird, wie z. B. Einreicher, Adapter, Worker Agents, OpenJD Pakete und andere. ## Überprüfen Sie die Echtheit der heruntergeladenen Software Überprüfen Sie nach dem Herunterladen des Installationsprogramms die Echtheit Ihrer Software, um sie vor Dateimanipulationen zu schützen. Dieses Verfahren funktioniert sowohl für als auch für SystemeWindows. Linux ------ #### [ Windows ] Gehen Sie wie folgt vor, um die Echtheit Ihrer heruntergeladenen Dateien zu überprüfen. 1. Ersetzen Sie den Befehl im folgenden Befehl `file` durch die Datei, die Sie überprüfen möchten. Beispiel, ** *C:\$1PATH\$1TO\$1MY\$1*DeadlineCloudSubmitter-windows-x64-installer.exe **. Ersetzen Sie es außerdem `signtool-sdk-version` durch die Version des installierten SignTool SDK. Beispiel, **10.0.22000.0**. `"C:\Program Files (x86)\Windows Kits\10\bin\signtool-sdk-version\x86\signtool.exe" verify /vfile` 1. Sie können beispielsweise die Installationsdatei für den Deadline Cloud-Absender überprüfen, indem Sie den folgenden Befehl ausführen: `"C:\Program Files (x86)\Windows Kits\10\bin\10.0.22000.0\x86\signtool.exe" verify /v DeadlineCloudSubmitter-windows-x64-installer.exe` ------ #### [ Linux ] Verwenden Sie das `gpg` Befehlszeilentool, um die Echtheit Ihrer heruntergeladenen Dateien zu überprüfen. 1. Importieren Sie den `OpenPGP` Schlüssel, indem Sie den folgenden Befehl ausführen: ``` gpg --import --armor < 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. **Überprüfen Sie das Installationsprogramm für Deadline Cloud Submitter** Gehen Sie wie folgt vor, um das Installationsprogramm für den Deadline Cloud-Absender zu verifizieren: 1. Laden Sie die Signaturdatei für das Deadline Cloud-Installationsprogramm für Submitter herunter. [Laden Sie die Signaturdatei (.sig) herunter](https://downloads.deadlinecloud.amazonaws.com/submitters/latest/linux/DeadlineCloudSubmitter-linux-x64-installer.run.sig) 1. Überprüfen Sie die Signatur des Deadline Cloud Submitter-Installationsprogramms, indem Sie Folgendes ausführen: ``` gpg --verify ./DeadlineCloudSubmitter-linux-x64-installer.run.sig ./DeadlineCloudSubmitter-linux-x64-installer.run ``` 1. **Überprüfen Sie den Deadline Cloud-Monitor** **Anmerkung** Sie können den Download des Deadline Cloud-Monitors mithilfe von Signaturdateien oder plattformspezifischen Methoden überprüfen. Plattformspezifische Methoden finden Sie Linux (Debian) auf der Registerkarte, auf der Registerkarte Linux (RPM) oder auf der Linux (AppImage) Registerkarte, die auf Ihrem heruntergeladenen Dateityp basiert. Gehen Sie wie folgt vor, um die Desktop-Anwendung Deadline Cloud Monitor anhand von Signaturdateien zu verifizieren: 1. Laden Sie die entsprechende Signaturdatei für Ihr Deadline Cloud Monitor-Installationsprogramm herunter: + [Laden Sie die .deb-Signaturdatei herunter](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor_amd64.deb.sig) + [Laden Sie die .rpm-Signaturdatei herunter](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor.x86_64.rpm.sig) + [Herunterladen. AppImage Signaturdatei](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor_amd64.AppImage.sig) 1. Überprüfen Sie die Signatur: **Für .deb:** ``` gpg --verify ./deadline-cloud-monitor_amd64.deb.sig ./deadline-cloud-monitor_amd64.deb ``` **Für .rpm:** ``` gpg --verify ./deadline-cloud-monitor.x86_64.rpm.sig ./deadline-cloud-monitor.x86_64.rpm ``` **Für. AppImage**: ``` gpg --verify ./deadline-cloud-monitor_amd64.AppImage.sig ./deadline-cloud-monitor_amd64.AppImage ``` 1. Vergewissern Sie sich, dass die Ausgabe wie folgt aussieht: `gpg: Signature made Mon Apr 1 21:10:14 2024 UTC` `gpg: using RSA key B840C08C29A90796A071FAA5F6CD3CE6B7` Wenn die Ausgabe den Ausdruck enthält, bedeutet dies`Good signature from "AWS Deadline Cloud"`, dass die Signatur erfolgreich verifiziert wurde und Sie das Installationsskript für den Deadline Cloud-Monitor ausführen können. **Historische Schlüssel** ``` -----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) ] Um Pakete zu überprüfen, die a verwendenLinux. AppImage Binär, führen Sie zuerst die Schritte 1 bis 3 Linux auf der Registerkarte aus und führen Sie dann die folgenden Schritte aus. 1. Laden Sie GitHub **validate-x86\$164 von der AppImageUpdate [Seite](https://github.com/AppImageCommunity/AppImageUpdate/releases/tag/continuous) in herunter. AppImage**Datei. 1. Führen Sie nach dem Herunterladen der Datei den folgenden Befehl aus, um Ausführungsberechtigungen hinzuzufügen. ``` chmod a+x ./validate-x86_64.AppImage ``` 1. Führen Sie den folgenden Befehl aus, um Ausführungsberechtigungen hinzuzufügen. ``` chmod a+x ./deadline-cloud-monitor__amd64.AppImage ``` 1. Führen Sie den folgenden Befehl aus, um die Signatur des Deadline Cloud-Monitors zu überprüfen. ``` ./validate-x86_64.AppImage ./deadline-cloud-monitor__amd64.AppImage ``` Wenn die Ausgabe den Ausdruck enthält`Validation successful`, bedeutet dies, dass die Signatur erfolgreich verifiziert wurde und Sie das Installationsskript für den Deadline Cloud-Monitor problemlos ausführen können. ------ #### [ Linux (Debian) ] Um Pakete zu verifizieren, die Linux eine.deb-Binärdatei verwenden, führen Sie zunächst die Schritte 1—3 Linux auf der Registerkarte aus. **dpkg** ist das zentrale Paketverwaltungswerkzeug in den meisten debian basierten Linux Distributionen. Sie können die .deb-Datei mit dem Tool überprüfen. 1. Laden Sie die .deb-Datei für den Deadline Cloud Monitor herunter: [Laden Sie den Deadline Cloud Monitor (.deb) herunter](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor_amd64.deb) 1. Überprüfen Sie die .deb-Datei: ``` dpkg-sig --verify deadline-cloud-monitor_amd64.deb ``` 1. Die Ausgabe wird wie folgt aussehen: ``` Processing deadline-cloud-monitor_amd64.deb... GOODSIG _gpgbuilder B840C08C29A90796A071FAA5F6CD3C 171200 ``` 1. Um die .deb-Datei zu überprüfen, vergewissern Sie sich, dass sie in der Ausgabe vorhanden `GOODSIG` ist. ------ #### [ Linux (RPM) ] Um Pakete zu verifizieren, die eine Linux .rpm-Binärdatei verwenden, führen Sie zunächst die Schritte 1 bis 3 auf der Linux Registerkarte aus. 1. Laden Sie die .rpm-Datei für den Deadline Cloud Monitor herunter: [Laden Sie den Deadline Cloud Monitor (.rpm) herunter](https://downloads.deadlinecloud.amazonaws.com/dcm/latest/deadline-cloud-monitor.x86_64.rpm) 1. Überprüfen Sie die .rpm-Datei: ``` gpg --export --armor "Deadline Cloud" > key.pub sudo rpm --import key.pub rpm -K deadline-cloud-monitor.x86_64.rpm ``` 1. Die Ausgabe wird wie folgt aussehen: ``` deadline-cloud-monitor.x86_64.rpm: digests signatures OK ``` 1. Um die .rpm-Datei zu überprüfen, vergewissern Sie sich, dass sie in der Ausgabe enthalten `digests signatures OK` ist. ------