Übersicht über die Buildphase

Artikel
04/19/2024

Das Erstellen von Containerimages ist die dritte Stufe des Containers Secure Supply Chain (CSSC)-Frameworks. Während einige Unternehmen die Basisbilder von externen Quellen direkt abrufen, können andere die Basisbilder aus dem internen Katalog abrufen, ohne die Bilder anhand ihrer Signaturen und Nachweise zu überprüfen. Es ist wichtig, sicherzustellen, dass Basisbilder immer aus dem internen Katalog abgerufen und vor der Verwendung überprüft werden. Nach dem Erstellen der Bilder veröffentlichen einige Unternehmen sie ohne Sicherheitsrisiko- und Schadsoftwareüberprüfung und generieren keine Nachweise wie SBOM, die in nachfolgenden Lieferkettenstufen nicht überprüft werden können. Es ist wichtig, sicherzustellen, dass die erstellten Containerimages vertrauenswürdig sind und den Unternehmensrichtlinien entsprechen.

Das CssC-Framework (Containers Secure Supply Chain) von Microsoft identifiziert die Notwendigkeit des Erstellens von Containerimages und stellt eine Reihe bewährter Methoden und Tools bereit, mit denen Sie vertrauenswürdige und kompatible Images sicher erstellen können. In diesem Artikel erfahren Sie mehr über die Ziele, bewährten Methoden und Tools, die Sie in der Buildphase des CSSC-Frameworks verwenden können.

Hintergrund

Derzeit verwenden Unternehmen verschiedene Ansätze, um kompatible Containerimages sicher zu erstellen. Vor dem Erstellen von Containerimages müssen interne Teams Basisimages aus internen goldenen Registern abrufen. Diese Bilder werden jedoch nicht vor der Verwendung überprüft, was nicht empfohlen wird, da goldene Register kompromittiert werden können und Bilder böswillig werden können. Unternehmen steuern auch die Quelle von Bibliotheken und Paketen, die in den Containerimages hinzugefügt werden, um die Qualität zu gewährleisten.

Nach dem Erstellen von Containerimages generieren Unternehmen zusätzliche Metadaten, um sicherzustellen, dass die Containerimages kompatibel sind. Einige Unternehmen nutzen ein DOKUMENT der SLSA-Provenienz , um zu wissen, welcher Git-Commit für die Erstellung des Containerimages und ob es reproduzierbar ist. Andere verwenden Docker-Bezeichnungen, um dem Besitzer des Containerimages eine Provenienz bereitzustellen und der für den Commit des Images verantwortlich ist. Einige Unternehmen scannen das Bild auf Sicherheitsrisiken und Schadsoftware und generieren entsprechend Berichte.

Die Buildphase des CSSC-Frameworks empfiehlt eine Reihe von Schritten und Sicherheitskontrollen, die implementiert werden sollten, um vertrauenswürdige und kompatible Containerimages zu erstellen, bevor sie veröffentlicht werden.

Empfohlene Praktiken

Microsoft empfiehlt die folgenden Methoden zum sicheren Erstellen kompatibler Containerimages.

Rufen Sie Basisbilder nur aus dem internen Katalog ab, um die Angriffsfläche zu reduzieren und die Sicherheit zu verbessern.
Überprüfen Sie nach Verfügbarkeit Signaturen und Nachweise von Basisimages, bevor Sie sie verwenden, um sicherzustellen, dass sie vertrauenswürdig und konform sind.
Distrolose Bilder enthalten nur die Anwendung und ihre Laufzeitabhängigkeiten, ohne zusätzliche Software- oder Betriebssystemkomponenten. Verwenden Sie distrolose Bilder als Basisbilder, um die Angriffsfläche zu reduzieren und die Sicherheit zu verbessern.
Wenden Sie den geringsten Zugriff auf die Buildplattform oder den Dienst an, um sicherzustellen, dass nur autorisierte Benutzer Änderungen oder Änderungen vornehmen können, wodurch das Risiko nicht autorisierter Zugriffe, Datenschutzverletzungen und anderer Sicherheitsvorfälle verringert wird.
Scannen Sie Containerimages auf Sicherheitsrisiken und Schadsoftware nach dem Build, um das Risiko der Einführung von Sicherheitsrisiken zu verringern.
Bereichern Sie Containerimages nach dem Build mit zusätzlichen Metadaten wie SBOM und Provenienzmetadaten.
Signieren Sie Containerimages und relevante Metadaten nach dem Build mit Enterprise-Schlüsseln, um Integrität sicherzustellen und vertrauenswürdigen Stempel der Genehmigung für die interne Verwendung bereitzustellen.
Patchen Sie Containerimages zeitnah, um bekannte Sicherheitsrisiken zu beheben.
Halten Sie Abhängigkeiten angemessen auf dem neuesten Stand, um mit den Sicherheitsrisiken und Sicherheitsupdates auf dem laufenden zu bleiben.

Workflow zum Erstellen kompatibler Containerimages

Die Buildphase verfügt über einen Workflow, um ein Containerimage zu erstellen, das mit Organisationen und Sicherheitsrichtlinien kompatibel ist. Es ist wichtig, die Zugriffssteuerung auf Berechtigungsstufe nur für autorisierte Benutzer auf die Buildplattform oder den Dienst anzuwenden. Wenn Basisimages im Katalog verfügbar sind, führt der Buildworkflow folgende Aktionen aus:

Rufen Sie nur Basisbilder aus dem internen Katalog ab.
Überprüfen Sie die Basisbilder, bevor Sie sie verwenden, um sicherzustellen, dass sie vertrauenswürdig und kompatibel ist.
Fügen Sie zusätzliche Frameworks, Anwendungscode und/oder Konfigurationen aus vertrauensbasierten Quellen auf Basisimages für den Build hinzu.
Generieren Sie SBOM während des Buildprozesses.
Scannen Sie das resultierende Containerimage nach dem Build auf bekannte Sicherheitsrisiken und Schadsoftware, um die Einführung von Sicherheitsfehlern zu verhindern.
Patchen des resultierenden Containerimages, um bekannte Sicherheitsrisiken und Schadsoftware zu beheben
Fügen Sie die Sicherheitsrisiko- und Schadsoftwareberichte als Bildnachweise an, die in nachfolgenden Phasen der Lieferkette verwendet werden sollen.
Fügen Sie SBOM als Bildnachweise an, die in nachfolgenden Phasen der Lieferkette verwendet werden sollen.
Erweitern Sie das resultierende Bild mit zusätzlichen Metadaten wie Provenienzmetadaten, die in nachfolgenden Phasen der Lieferkette verwendet werden sollen.
Signieren Sie das resultierende Image und relevante Metadaten mit Enterprise-Schlüsseln, um Integrität sicherzustellen und einen vertrauenswürdigen Stempel der Genehmigung für die Bereitstellungsphase bereitzustellen.

Sicherheitsziele in der Buildphase

Wenn Sie einen gut definierten Workflow zum Erstellen vertrauenswürdiger und konformer Containerimages haben, können Unternehmen ihre Sicherheit erhöhen und die Angriffsfläche auf ihrer Lieferkette für Container reduzieren. Die Buildphase des CSSC-Frameworks soll die folgenden Sicherheitsziele erfüllen.

Reduzieren der Angriffsfläche aufgrund einer unsachgemäßen Zugriffssteuerung

Interne Benutzer können unerwartete Änderungen oder falsche Konfigurationen für die Buildinfrastruktur vornehmen. Die Buildphase im CSSC-Framework behebt dieses Risiko, indem standardmäßig die geringste Berechtigungszugriffskontrolle erzwungen wird, sodass Ressourcenbesitzer sicherstellen können, dass die richtige Person über die richtigen Berechtigungen zum Vornehmen von Änderungen und Konfigurationen verfügt, wodurch die Angriffsfläche reduziert wird.

Reduzieren der Angriffsfläche von böswilligen internen Benutzern

Der Identitätsdiebstahl kann verwendet werden, um auf die Buildplattform zuzugreifen, Binärdateien zu ändern und illegale Änderungen einzugeben, die für den ursprünglichen Entwickler und die Benutzer unsichtbar sind. Es besteht auch das Risiko, anfälligen Code einzugeben oder von internen Benutzern falsch konfiguriert zu werden. Die Buildphase im CSSC-Framework behebt dieses Risiko, indem azure role-based access control (Azure RBAC) angewendet und Codeüberprüfungen aus verschiedenen Codebesitzer erzwungen werden.

Reduzieren der Angriffsfläche aufgrund externer Abhängigkeiten

Basisbilder aus externen Quellen können böswillig sein. Externe Register können kompromittiert werden. Die Buildphase im CSSC-Framework behebt dieses Risiko, indem Basisbilder nur aus dem Katalog verwendet und vor derEn Verwendung anhand ihrer Signaturen, Sicherheitsrisiken und Schadsoftwareberichte sowie anderer Bildmetadaten überprüft werden.

Böswillige Open Source Software (OSS)-Pakete mit ausgeblendeten Hintertüren können dazu führen, dass die Binärdateien des Pakets nicht mit dem Quellcode übereinstimmen. Die Gültigkeit von Abhängigkeiten oder Open Source-Komponenten kann ablaufen und die neuesten Sicherheitsupdates von upstream blockieren. Die Buildphase im CSSC-Framework behebt dieses Risiko, indem genehmigte Bibliotheken verwendet, regelmäßig auf Sicherheitsrisiken und Schadsoftware überprüft und Bibliotheken auf dem neuesten Stand gehalten werden.

Reduzieren der Angriffsfläche aufgrund kompromittierter Builds

Anfällige Build-Agents können Nebenbinärdateien oder bösartigen Code einfügen, die Angriffe wie den SolarWinds-Angriff verursachen können. Die Buildphase im CSSC-Framework behebt dieses Risiko, indem die Build-Agents regelmäßig gepatcht werden.

Sicherstellen einer minimalen Bildqualität

In der Buildphase des CSSC-Frameworks können Unternehmen die erforderlichen Schritte für die Überprüfung von Sicherheitsrisiken und Schadsoftwareüberprüfungen der Bilder nach dem Build konfigurieren und Berichte generieren. Unternehmen können die Bilder auch nach dem Build mit zusätzlichen Metadaten wie SBOMs, Provenienzmetadaten und anderen internen Metadaten erweitern, die ihren Richtlinien entsprechen. Sie können die Artefakte auch mit Unternehmensschlüsseln signieren, um Integrität sicherzustellen und einen vertrauenswürdigen Stempel der Genehmigung für die Bereitstellungsphase bereitzustellen.

Empfohlene Tools

Microsoft bietet eine Reihe von Tools und Diensten, die Unternehmen dabei helfen können, die empfohlenen Schritte im Workflow der Buildphase zu implementieren und die oben aufgeführten Sicherheitsziele zu erfüllen.

Tools zum Aufstehen auf dem neuesten Stand nach dem Build

Dependabot ist ein Tool zum Automatisieren von Abhängigkeitsupdates über Pullanforderungen. Ausführliche Informationen und nächste Schritte finden Sie in diesem Leitfaden.

Copa ist ein von Microsoft unterstütztes Open-Source-Projekt, behebt Sicherheitsrisiken des Linux-Betriebssystempakets in Containerimages basierend auf Den Ergebnissen der Sicherheitsrisikoüberprüfung. Ausführliche Informationen und nächste Schritte finden Sie in diesem Leitfaden.

Tools und Dienst für kontinuierliche Überprüfung und Patching von Images für Sicherheitsrisiken

Microsoft Defender für Cloud ist die cloudeigene Lösung, um die Sicherheit Ihrer containerisierten Workloads zu verbessern, zu überwachen und zu Standard zu gewährleisten. Microsoft Defender für Cloud bietet Tools zur Sicherheitsrisikobewertung und -verwaltung für Bilder, die in der Azure-Containerregistrierung gespeichert sind.

Tools und Dienste zum Anreichern externer Bilder mit Unternehmensmetadaten

ORAS ist ein CNCF-Projekt, das von Microsoft unterstützt wird und eine Open-Source-CLI und Bibliotheken für die Interaktion mit OCI-Registrierungen bietet. ORAS kann verwendet werden, um Anmerkungen hinzuzufügen und Metadaten an ein Containerimage anzufügen. ORAS kann verwendet werden, um SBOMs, Provenienzmetadaten und andere Metadaten hinzuzufügen, um die Bilder für nachfolgende Phasen in der Lieferkette zu bereichern.

Das SBOM-Tool von Microsoft ist ein Open Source-, hoch skalierbares und unternehmensfähiges Tool zum Erstellen von SPDX 2.2-kompatiblen SBOMs für jede Vielzahl von Artefakten. SBOM Tool kann verwendet werden, um detaillierte SBOMs für Containerimages zu generieren.

Notar Project ist ein von Microsoft gesichertes CNCF-Projekt, das Spezifikationen und Tools zum Signieren und Überprüfen von Softwareartefakten entwickelt. Das Tool des Notarprojekts notation kann zum Signieren von Containerimages und anderen cloudeigenen Artefakten mit Enterprise-Schlüsseln verwendet werden.

Azure Key Vault ist ein cloudbasierter Dienst, der einen sicheren und zentralen Speicherort zum Speichern und Verwalten kryptografischer Schlüssel, geheimer Schlüssel und Zertifikate bereitstellt. AKV kann zum sicheren und zuverlässigen Speichern und Verwalten Von Unternehmensschlüsseln verwendet werden.

Nächste Schritte

Siehe Übersicht über die Bereitstellungsphase zum sicheren Bereitstellen von Containerimages.

Freigeben über