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.
# Implementieren Sie zentralisiertes benutzerdefiniertes Checkov-Scanning, um Richtlinien vor der Bereitstellung AWS der Infrastruktur durchzusetzen
*Benjamin Morris, Amazon Web Services*
## Zusammenfassung
Dieses Muster bietet ein GitHub Actions-Framework für das Schreiben benutzerdefinierter Checkov-Richtlinien in einem Repository, die unternehmensweit wiederverwendet werden können. GitHub Wenn dieses Muster befolgt wird, kann ein Informationssicherheitsteam benutzerdefinierte Richtlinien auf der Grundlage der Unternehmensanforderungen schreiben, hinzufügen und verwalten. Die benutzerdefinierten Richtlinien können automatisch in alle Pipelines der GitHub Organisation übernommen werden. Dieser Ansatz kann verwendet werden, um Unternehmensstandards für Ressourcen durchzusetzen, bevor die Ressourcen eingesetzt werden.
## Voraussetzungen und Einschränkungen
**Voraussetzungen**
+ Ein aktiver AWS-Konto
+ Eine GitHub Organisation, die GitHub Aktionen verwendet
+ AWS Infrastruktur, die entweder mit HashiCorp Terraform oder bereitgestellt wurde AWS CloudFormation
**Einschränkungen**
+ Dieses Muster wurde für GitHub Aktionen geschrieben. Es kann jedoch an ähnliche Frameworks für kontinuierliche Integration und kontinuierliche Lieferung (CI/CD) angepasst werden, wie z. GitLab Es ist keine spezielle kostenpflichtige Version von GitHub erforderlich.
+ Einige AWS-Services sind nicht in allen verfügbar AWS-Regionen. Informationen zur regionalen Verfügbarkeit finden Sie in der AWS Dokumentation unter [Dienstendpunkte und Kontingente](https://docs.aws.amazon.com/general/latest/gr/aws-service-information.html) und wählen Sie den Link für den Dienst.
## Architektur
Dieses Muster ist für die Bereitstellung als GitHub Repository konzipiert, das einen GitHub wiederverwendbaren Workflow und benutzerdefinierte Checkov-Richtlinien enthält. Der wiederverwendbare Workflow kann sowohl Terraform- als auch CloudFormation Infrastructure-as-Code-Repositorys (IaC) scannen.
Das folgende Diagramm zeigt das Repository für **wiederverwendbare GitHub Workflows und das Repository** für **benutzerdefinierte Checkov-Richtlinien als separate Symbole**. Sie können diese Repositorys jedoch entweder als separate Repositorys oder als einzelnes Repository implementieren. Der Beispielcode verwendet ein einzelnes Repository mit Dateien für Workflows (`.github/workflows`) und Dateien für benutzerdefinierte Richtlinien (`custom_policies`Ordner und `.checkov.yml` Konfigurationsdatei) im selben Repository.
Das Diagramm zeigt den folgenden Workflow:
1. Ein Benutzer erstellt eine Pull-Anfrage in einem GitHub Repository.
1. Pipeline-Workflows beginnen in GitHub Aktionen, einschließlich eines Verweises auf einen wiederverwendbaren Checkov-Workflow.
1. Der Pipeline-Workflow lädt den referenzierten wiederverwendbaren Checkov-Workflow aus einem externen Repository herunter und führt diesen Checkov-Workflow mithilfe von Aktionen aus. GitHub
1. Der wiederverwendbare Checkov-Workflow lädt die benutzerdefinierten Richtlinien aus einem externen Repository herunter.
1. Der wiederverwendbare Checkov-Workflow bewertet die IaC im GitHub Repository anhand integrierter und benutzerdefinierter Checkov-Richtlinien. Der wiederverwendbare Checkov-Workflow ist erfolgreich oder schlägt fehl, je nachdem, ob Sicherheitsprobleme gefunden wurden.
**Automatisierung und Skalierung**
Dieses Muster ermöglicht die zentrale Verwaltung der Checkov-Konfiguration, sodass Richtlinienaktualisierungen an einem Ort angewendet werden können. Dieses Muster erfordert jedoch, dass jedes Repository einen Workflow verwendet, der einen Verweis auf den zentralen wiederverwendbaren Workflow enthält. Sie können diesen Verweis manuell hinzufügen oder Skripts verwenden, um die Datei in den `.github/workflows` Ordner für jedes Repository zu verschieben.
## Tools
**AWS-Services**
+ [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)hilft Ihnen dabei, AWS Ressourcen einzurichten, sie schnell und konsistent bereitzustellen und sie während ihres gesamten Lebenszyklus regionsübergreifend AWS-Konten zu verwalten. Checkov kann scannen CloudFormation.
**Andere Tools**
+ [Checkov](https://www.checkov.io/) ist ein statisches Codeanalyse-Tool, das IaC auf Sicherheits- und Compliance-Fehlkonfigurationen überprüft.
+ [GitHub Actions](https://github.com/features/actions) ist in die GitHub Plattform integriert, um Sie bei der Erstellung, gemeinsamen Nutzung und Ausführung von Workflows in Ihren Repositorys zu unterstützen. GitHub Mithilfe von GitHub Aktionen können Sie Aufgaben wie das Erstellen, Testen und Bereitstellen Ihres Codes automatisieren.
+ [Terraform](https://www.terraform.io/) ist ein IaC-Tool von HashiCorp , mit dem Sie Cloud- und lokale Ressourcen erstellen und verwalten können. Checkov kann Terraform scannen.
**Code-Repository**
Der Code für dieses Muster ist im GitHub [centralized-custom-checkov-sast](https://github.com/aws-samples/centralized-custom-checkov-sast)Repository verfügbar.
## Best Practices
+ Um einen konsistenten Sicherheitsstatus aufrechtzuerhalten, sollten Sie die Sicherheitsrichtlinien Ihres Unternehmens an die Checkov-Richtlinien anpassen.
+ In den frühen Phasen der Implementierung der benutzerdefinierten Richtlinien von Checkov können Sie die Soft-Fail-Option in Ihrem Checkov-Scan verwenden, damit IaC und Sicherheitsprobleme zusammengeführt werden können. Wenn der Prozess ausgereift ist, wechseln Sie von der Soft-Fail-Option zur Hard-Fail-Option.
## Epen
### Erstellen Sie ein zentrales Checkov-Repository für benutzerdefinierte Richtlinien
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Erstellen Sie ein zentrales Checkov-Repository. | Erstellen Sie ein Repository, um benutzerdefinierte Checkov-Richtlinien zu speichern, die innerhalb der Organisation verwendet werden.
Für einen schnellen Start können Sie den Inhalt des Repositorys dieses Patterns in Ihr zentrales GitHub [centralized-custom-checkov-sast ](https://github.com/aws-samples/centralized-custom-checkov-sast)Checkov-Repository kopieren. | DevOps Ingenieur |
| Erstellen Sie ein Repository für wiederverwendbare Workflows. | Wenn bereits ein Repository für wiederverwendbare Workflows existiert oder Sie planen, wiederverwendbare Workflow-Dateien in dasselbe Repository aufzunehmen wie die benutzerdefinierten Checkov-Richtlinien, können Sie diesen Schritt überspringen.
Erstellen Sie ein GitHub Repository für wiederverwendbare Workflows. Die Pipelines anderer Repositorien werden auf dieses Repository verweisen. | DevOps Ingenieur |
### Erstellen Sie wiederverwendbare Checkov-Workflows und Beispielworkflows
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Fügen Sie einen wiederverwendbaren Checkov-Workflow hinzu. | Erstellen Sie einen wiederverwendbaren GitHub Checkov-Aktions-Workflow (YAML-Datei) im Repository für wiederverwendbare Workflows. Sie können diesen wiederverwendbaren Workflow anhand der in diesem Muster bereitgestellten Workflow-Datei anpassen.
Ein Beispiel für eine Änderung, die Sie möglicherweise vornehmen möchten, besteht darin, den wiederverwendbaren Workflow so zu ändern, dass er die Soft-Fail-Option verwendet. `true`Durch die Einstellung `soft-fail` auf kann der Job auch dann erfolgreich abgeschlossen werden, wenn ein Checkov-Scan fehlschlägt. Anweisungen finden Sie unter [Hard and Soft Fail](https://www.checkov.io/2.Basics/Hard%20and%20soft%20fail.html) in der Checkov-Dokumentation. | DevOps Ingenieur |
| Fügen Sie einen Beispiel-Workflow hinzu. | Fügen Sie einen Checkov-Beispiel-Workflow hinzu, der auf den `reusable` Workflow verweist. Dadurch wird eine Vorlage für die Wiederverwendung des `reusable` Workflows bereitgestellt. Im Beispiel-Repository `checkov-source.yaml` befindet sich der wiederverwendbare Workflow und `checkov-scan.yaml` ist das Beispiel, das verbraucht. `checkov-source`
Weitere Informationen zum Schreiben eines Checkov-Beispiel-Workflows finden Sie unter [Zusätzliche](#centralized-custom-checkov-scanning-additional) Informationen. | DevOps Ingenieur |
### Ordnen Sie Unternehmensrichtlinien den benutzerdefinierten Richtlinien von Checkov zu
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Ermitteln Sie Richtlinien, die mit Checkov durchgesetzt werden können. | [See the AWS documentation website for more details](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/patterns/centralized-custom-checkov-scanning.html)Weitere Informationen zur Erstellung von benutzerdefinierten Checkov-Richtlinien finden Sie unter [Übersicht über benutzerdefinierte Richtlinien](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html) in der Checkov-Dokumentation. | Sicherheit und Compliance |
| Fügen Sie benutzerdefinierte Checkov-Richtlinien hinzu. | Konvertieren Sie die identifizierten Unternehmensrichtlinien in benutzerdefinierte Checkov-Richtlinien im zentralen Repository. Sie können einfache Checkov-Richtlinien entweder in Python oder YAML schreiben. | Sicherheit |
### Implementieren Sie zentralisierte benutzerdefinierte Checkov-Richtlinien
| Aufgabe | Description | Erforderliche Fähigkeiten |
| --- | --- | --- |
| Fügen Sie den wiederverwendbaren Checkov-Workflow zu allen Repositorys hinzu. | Zu diesem Zeitpunkt sollten Sie über ein Beispiel für einen Checkov-Workflow verfügen, der auf den wiederverwendbaren Workflow verweist. Kopieren Sie den Checkov-Beispiel-Workflow, der auf den wiederverwendbaren Workflow verweist, in jedes Repository, das ihn benötigt. | DevOps Ingenieur |
| Erstellen Sie einen Mechanismus, um sicherzustellen, dass Checkov vor Zusammenführungen ausgeführt wird. | Um sicherzustellen, dass der Checkov-Workflow für jede Pull-Anfrage ausgeführt wird, erstellen Sie eine [Statusprüfung](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks), die einen erfolgreichen Checkov-Workflow voraussetzt, bevor Pull-Requests zusammengeführt werden können. GitHub ermöglicht es Ihnen, zu verlangen, dass bestimmte Workflows ausgeführt werden, bevor Pull-Requests zusammengeführt werden können. | DevOps Ingenieur |
| Erstellen Sie eine unternehmensweite PAT und geben Sie sie als geheim weiter. | Wenn Ihre GitHub Organisation öffentlich sichtbar ist, können Sie diesen Schritt überspringen.
Dieses Muster erfordert, dass der Checkov-Workflow in der Lage ist, benutzerdefinierte Richtlinien aus dem Repository für benutzerdefinierte Richtlinien in Ihrer GitHub Organisation herunterzuladen. Sie müssen Berechtigungen bereitstellen, damit der Checkov-Workflow auf diese Repositorys zugreifen kann.
[Erstellen Sie dazu ein Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-fine-grained-personal-access-token) (PAT) mit Berechtigungen zum Lesen von Organisations-Repositorys. Teilen Sie dieses PAT mit Repositorys, entweder als unternehmensweites Geheimnis (bei einem kostenpflichtigen Tarif) oder als Geheimnis in jedem Repository (kostenlose Version). Im Beispielcode lautet der Standardname für das Geheimnis. `ORG_PAT` | DevOps Ingenieur |
| (Optional) Schützen Sie die Checkov-Workflow-Dateien vor Änderungen. | Um die Checkov-Workflow-Dateien vor unerwünschten Änderungen zu schützen, können Sie eine `CODEOWNERS` Datei verwenden. Die `CODEOWNERS` Datei wird normalerweise im Stammverzeichnis bereitgestellt.
Um beispielsweise Genehmigungen von der `secEng` Gruppe Ihrer GitHub Organisation einzuholen, wenn die `checkov-scan.yaml` Datei geändert wird, fügen Sie Folgendes an die Datei eines Repositorys `CODEOWNERS` an:[Checkov]
.github/workflows/checkov-scan.yaml @myOrg/secEng
Eine `CODEOWNERS` Datei ist spezifisch für das Repository, in dem sie sich befindet. Um den vom Repository verwendeten Checkov-Workflow zu schützen, müssen Sie in jedem Repository eine `CODEOWNERS` Datei hinzufügen (oder aktualisieren).
Weitere Informationen zum Schutz von Checkov-Workflow-Dateien finden Sie unter [Zusätzliche](#centralized-custom-checkov-scanning-additional) Informationen. Weitere Informationen zu `CODEOWNERS` Dateien finden Sie in der offiziellen Dokumentation Ihres CI/CD Anbieters (z. B. [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners)). | DevOps Ingenieur |
## Zugehörige Ressourcen
+ [Überblick über die benutzerdefinierten Richtlinien von Checkov](https://www.checkov.io/3.Custom%20Policies/Custom%20Policies%20Overview.html)
+ [CloudFormation Scannen von Konfigurationen](https://www.checkov.io/7.Scan%20Examples/Cloudformation.html)
+ [GitHub Aktionen Wiederverwendbare Workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
## Zusätzliche Informationen
**Checkov-Workflow-Dateien schreiben**
Überlegen Sie sich beim Schreiben`checkov-scan.yaml`, wann es ausgeführt werden soll. Der `on` Schlüssel der obersten Ebene bestimmt, wann der Workflow ausgeführt wird. Im Beispiel-Repository wird der Workflow ausgeführt, wenn eine Pull-Anfrage auf den `main` Branch abzielt (und jedes Mal, wenn der Quell-Branch dieser Pull-Anfrage geändert wird). Aufgrund des `workflow_dispatch` Schlüssels kann der Workflow auch nach Bedarf ausgeführt werden.
Sie können die Workflow-Auslösebedingungen ändern, je nachdem, wie oft der Workflow ausgeführt werden soll. Sie könnten beispielsweise den Workflow so ändern, dass er jedes Mal ausgeführt wird, wenn Code an einen Zweig übertragen wird, indem Sie den Schlüssel durch den `branches` Schlüssel `pull_request` ersetzen `push` und ihn entfernen.
Sie können die Workflow-Beispieldatei ändern, die Sie in einem einzelnen Repository erstellt haben. Sie könnten beispielsweise den Namen des Ziel-Branches von bis ändern`main`, `production` wenn ein Repository um einen `production` Branch herum strukturiert ist.
**Schutz der Checkov-Workflow-Dateien**
Der Checkov-Scan liefert nützliche Informationen über mögliche Sicherheitsfehler. Einige Entwickler könnten dies jedoch als Hindernis für ihre Produktivität empfinden und versuchen, den Scan-Workflow zu entfernen oder zu deaktivieren.
Es gibt mehrere Möglichkeiten, dieses Problem zu lösen, darunter bessere Informationen über den langfristigen Wert von Sicherheitsscans und eine klarere Dokumentation zur Bereitstellung einer sicheren Infrastruktur. Dies sind wichtige „sanfte“ Ansätze für die DevSecOps Zusammenarbeit, die als Lösung für die eigentliche Ursache dieses Problems angesehen werden können. Sie können jedoch auch technische Kontrollen wie eine `CODEOWNERS` Datei als Leitplanken verwenden, um Entwickler auf dem richtigen Weg zu halten.
**Testmuster in einer Sandbox**
Gehen Sie folgendermaßen vor, um dieses Muster in einer Sandbox-Umgebung zu testen:
1. Erstellen Sie eine neue GitHub Organisation. Erstellen Sie ein Token mit schreibgeschütztem Zugriff auf alle Repositorys in der Organisation. Da dieses Token für eine Sandbox-Umgebung und nicht für eine kostenpflichtige Umgebung bestimmt ist, können Sie dieses Token nicht in einem unternehmensweiten Geheimnis speichern.
1. Erstellen Sie ein `checkov` Repository für die Checkov-Konfiguration und ein `github-workflows` Repository für die wiederverwendbare Workflow-Konfiguration. Füllen Sie die Repositorys mit dem Inhalt des Beispiel-Repositorys.
1. Erstellen Sie ein Anwendungs-Repository, kopieren Sie den `checkov-scan.yaml` Workflow und fügen Sie ihn in den entsprechenden Ordner ein. `.github/workflows` Fügen Sie dem Repository einen geheimen Schlüssel hinzu, der die PAT enthält, die Sie für den schreibgeschützten Organisationszugriff erstellt haben. Das Standardgeheimnis ist. `ORG_PAT`
1. Erstellen Sie eine Pull-Anfrage, die dem Anwendungs-Repository etwas Terraform oder CloudFormation Code hinzufügt. Checkov sollte scannen und ein Ergebnis zurückgeben.