# Steuern der Ausführung von GitHub Actions-Workflows Steuern Sie, wer GitHub ActionsWorkflows auslösen kann und welche Ereignisse diese unternehmensweit sowie in einer Organisation und einem Repository ausführen dürfen. Mit Schutzmechanismen für die Workflowausführung können Sie eine Allowlist definieren, mit der Sie festlegen können, wer GitHub ActionsWorkflows auslösen kann und durch welche Ereignisse sie ausgeführt werden dürfen. Weitere Informationen finden Sie unter [Informationen zu den Actions-Richtlinien](/de/actions/concepts/about-actions-policies). > \[!NOTE] GitHub hat eine Standardrichtlinie hinzugefügt, die das `pull_request_target` Ereignis in öffentlichen Repositorys blockiert. Diese Richtlinie tritt am 2. November 2026 in Kraft. Siehe [Sichere Verwendung von pull\_request\_target](/de/actions/reference/security/securely-using-pull_request_target#default-policy-for-pull_request_target). ## Vorbereiten des Hinzufügens von Schutzmaßnahmen Ähnlich wie Regelsätze greifen Schutzmechanismen für Workflow-Ausführungen zusammen mit anderen Schutzmechanismen im selben Repository, in derselben Organisation oder im selben Unternehmen. Anstatt eine große Richtlinie pro Konto zu erstellen, empfiehlt es sich, mehrere klar definierte Richtlinien und Layering-Schutzmaßnahmen auf Kontoebenen zu erstellen. Unternehmensbesitzer können Schutzmaßnahmen auf Unternehmensebene für umfassende, nicht verhandelbare Richtlinien erstellen. Organisationsbesitzer und Repositoryadministratoren können diese Einschränkungen dann hinzufügen. Denken Sie bei jeder Richtlinie, die Sie definieren, an Folgendes: 1. **Auf welche Organisationen oder Repositorys** Ihr Schutz ausgerichtet ist. Beispielsweise benötigen Open Source Repositorys möglicherweise strengere Einschränkungen für die Auslösung von Workflows. Sie können Repositorys nach Faktoren wie Sichtbarkeit, Bereitstellungsstatus oder benutzerdefinierte Eigenschaft ausrichten. * Der Bereitstellungsstatus linked artifacts pagestammt aus der Organisation. Wenn dies ein wichtiger Faktor ist, stellen Sie sicher, dass Sie Bereitstellungsdatensätze hochladen, wenn ein Artefakt bereitgestellt wird. Siehe [Informationen zu verknüpften Artefakten](/de/code-security/concepts/supply-chain-security/linked-artifacts). * Informationen zum Erstellen und Zuweisen von benutzerdefinierten Eigenschaften finden Sie unter [Verwalten von benutzerdefinierten Eigenschaften für Repositorys in Ihrer Organisation](/de/organizations/managing-organization-settings/managing-custom-properties-for-repositories-in-your-organization). 2. **Welche Workflows** geschützt werden. Beispielsweise benötigen Workflows, die Produktionscode bereitstellen, möglicherweise ein bestimmtes Schutzniveau, aber weniger sensible Automatisierungen benötigen möglicherweise nicht das gleiche Schutzniveau. Sie können Richtlinien auf bestimmte Workflowpfade oder erforderliche Workflows festlegen. 3. **Wer sollte diese Workflows** in den Repositorys ausführen können, auf die Sie abzielen. Dies kann Benutzer mit einer bestimmten Rolle, ausgewählten Bot-Konten oder einem bestimmten Team sein. Erwägen Sie, diese Benutzer in einer Organisation oder einem Unternehmensteam zu gruppieren, damit sie problemlos kontaktiert und über mehrere Regelgruppen verwiesen werden können. Weitere Informationen findest du unter [Erstellen eines Organisationsteams](/de/organizations/organizing-members-into-teams/creating-a-team) oder [Erstellen von Unternehmensteams](/de/enterprise-cloud@latest/admin/managing-accounts-and-repositories/managing-users-in-your-enterprise/create-enterprise-teams). ## Erstellen einer Workflowausführungsrichtlinie Erstellen Sie zunächst eine neue Aktionsrichtlinie für die Kontoebene, an der Sie arbeiten. In einem Repository oder einer Organisation: 1. Klicken Sie auf die Registerkarte **Einstellungen**. 2. Klicken Sie in der linken Randleiste unter **"Aktionen**" auf **"Richtlinien"**. In einem Unternehmen: 1. Klicken Sie auf die ** Registerkarte "Richtlinien** ". 2. Klicken Sie in der linken Randleiste auf **"Aktionen**" und dann auf **"Richtlinien"**. > \[!TIP] Informationen zum programmgesteuerten Verwalten von Richtlinien finden Sie unter [REST-API-Endpunkte für GitHub Actions-Richtlinien](/de/rest/actions/policies). ### Konfigurieren der Richtlinie Erstellen Sie als Nächstes eine neue Richtlinie. 1. Wählen Sie einen Namen für die Richtlinie aus. 2. Wählen Sie einen Erzwingungsstatus aus. Wenn Sie **Auswerten** (nur GitHub Enterprise Cloud) auswählen, können Sie in den Richtlinieneinblicken nachverfolgen, wann Benutzer von der Einschränkung betroffen wären. 3. Richten Sie Ihre gewünschten Workflows, Organisationen oder Repositorys an. 4. Konfigurieren Sie die folgenden Workflowausführungsschutze. ### Einschränken von Akteuren Standardmäßig kann jeder Benutzer mit Schreibzugriff auf ein Repository Workflows auslösen. Mit Akteurregeln können Sie trennen, wer Code beiträgt und wer Ihre CI ausführt, sodass Sie einem Mitwirkenden Schreibzugriff gewähren können, ohne ihm die Berechtigung zu erteilen, Workflows auszuführen. Nur die zulässigen Akteure können die angegebenen Workflows im zielbezogenen Repository ausführen. Wenn Sie Ereignisse auch einschränken, können diese Benutzer nur Workflows mit den zulässigen Ereignissen auslösen. Nicht zulässige Akteure können die angegebenen Workflows überhaupt nicht ausführen. GitHub Features sind für die integrierten Prozesse, auf GitHub Actions denen sie ausgeführt werden, von diesen Einschränkungen ausgenommen. Wenn Sie jedoch Workflows erstellt haben, die unter der Identität ausgeführt werden müssen, die einer mit GitHub verknüpften Funktion zugeordnet ist, wie `dependabot[bot]`, dann muss diese Identität als berechtigter Akteur hinzugefügt werden. ### Einschränken von Ereignissen Ereignisregeln steuern, welche Ereignisse zulässig sind, wie `push`, `pull_request`, `pull_request_target` und `workflow_dispatch`. ### Sperrdatei erfordern Der Schutz **Lockfile erforderlich** blockiert die Ausführung von Workflows mit `uses:` Abhängigkeiten von anderen Actions, es sei denn, die Abhängigkeiten sind in einer Abhängigkeits-Sperrdatei fixiert. Dadurch wird sichergestellt, dass die bestimmten Workflows vorhersehbaren, überprüften Code ausführen, anstelle dessen, worauf ein Tag oder Branch zur Laufzeit verweist. Siehe [Sperrdateien für Workflow-Abhängigkeiten](/de/actions/concepts/security/workflow-dependency-lockfiles). Generieren und überprüfen Sie Sperrdateien in den Repositorys, auf die Sie abzielen, bevor Sie diesen Schutz auf **"Aktiv"** festlegen. Andernfalls werden Sie Workflowausführungen in Repositorys blockieren, die nicht bereit sind. Eine gestaffelte Einführung finden Sie unter [Erzwingen von Lockfiles für Abhängigkeiten von Aktionen](/de/actions/how-tos/administer/enforce-workflow-lockfiles). Sie können **„Aktionen müssen an eine Commit-SHA in voller Länge angeheftet sein“** bei der Übernahme von Lockfiles aktiviert lassen. Bei Abhängigkeiten, die von einer Sperrdatei abgedeckt werden, wertet GitHub diese Anforderung mithilfe des gesperrten Commit-SHA aus. Wenn die Richtlinie während eines mehrstufigen Rollouts aktiviert bleibt, bleibt die SHA-Pinning-Erzwingung für Workflows erhalten, die noch keine Lockfiles übernommen haben. ## Richtlinien auswerten Sie können Richtlinieneinblicke anzeigen, um Workflow-Ausführungen zu sehen, die blockiert wurden (bei aktiven Richtlinien) oder blockiert worden wären (bei „Auswerten“-Richtlinien). Dies ist eine gute Möglichkeit, zu überprüfen, ob Richtlinien wie beabsichtigt funktionieren und keine unnötigen Reibungsverluste verursachen. Um Einblicke anzuzeigen, klicken Sie auf die Seite " **Richtlinieneinblicke** ". Sie finden dies direkt unter der Seite „GitHub Actions-Richtlinien“ in der Seitenleiste Ihres Repositorys, Ihrer Organisation oder Ihres Unternehmens.