IBM Cloud Object Storage-Buckets als Schließfach für Nachweise verwenden

Sie können IBM Cloud Object Storage (COS)-Buckets konfigurieren, um die Nachweise zu speichern, die durch die in die DevSecOps-Pipelines integrierten Konformitätsprüfungen generiert werden. Der Compliance-Nachweis erstellt den Prüfpfad, der von Prüfern während eines Compliance-Audits untersucht wird. Eines der Ziele von DevSecOps ist die automatisierte Nachweisgenerierung und -speicherung in überprüfbaren Nachweissegmenten. Weitere Informationen finden Sie unter evidence locker.

Die Pipeline zur Automatisierung der Compliance-Prüfung speichert die folgenden Informationen im COS-Bucket:

Taskartefakte
Testergebnisse, Scan-Ergebnisse oder sonstige von Aufgaben gespeicherte Ausgaben.
Taskprotokolle
Nachdem die Pipeline ausgeführt wurde, werden die Protokolle dieses Durchlaufs an den Evidence Locker gesendet.
Nachweis
Informationen zu Aufgaben und deren Ergebnissen, die entweder einen Fehler oder einen Erfolg darstellen können. Weitere Informationen zum Format der Nachweise, die gesendet werden, finden Sie unter Nachweiszusammenfassung.

Bucket konfigurieren

Eine dedizierte Cloud-Instanz Object Storage muss erstellt werden, bevor eine kontinuierliche Integration oder Toolchain für kontinuierliche Bereitstellung eingerichtet wird. Dieses COS-Bucket wird für den konformitätsbezogenen Speicher verwendet, da Angabensperren innerhalb der Grenzen Ihrer Anwendungen erstellt werden müssen. Dies trägt zur Verbesserung der Ausfallsicherheit Ihrer Pipeline bei. Weitere Informationen finden Sie unter Ausfallsicherheit.

Um Ihren Cloud- Object Storage-Bucket so zu konfigurieren, dass er als Speicherort für Compliance-Nachweise im Rahmen einer Continuous-Integration- oder Continuous-Deployment-Pipeline dient, können Sie die folgenden Informationen als Leitfaden verwenden. Die Skripte der Pipeline- oder Toolchain-Vorlagen richten den Locker in der Cloud- Object Storage nicht ein.

Auf dieser Seite finden Sie weitere Informationen zu Überlegungen (Granularität, Sicherheit,...) für die Verwendung von Cloud Object Storage für Compliance-Nachweise.

Aufbewahrungsrichtlinie

Sie können Cloud- Object Storage-Buckets so konfigurieren, dass eine Aufbewahrungsrichtlinie oder -frist für hochgeladene Objekte durchgesetzt wird; dies wird auch als Immutable Object Storage bezeichnet. Immutable Object Storage (IOS) dient der Aufbewahrung elektronischer Aufzeichnungen und stellt die Aufrechterhaltung der Datenintegrität sicher. Aufbewahrungsrichtlinien stellen sicher, dass Daten im WORM-Verfahren (Write-One-Read-Many) gespeichert werden, sodass sie nicht gelöscht oder überschrieben werden können. Objekte in geschützten Buckets können innerhalb des Aufbewahrungszeitraums nicht geändert oder gelöscht werden. Ebensowenig können geschützte Buckets selbst mit ihren Objekten gelöscht werden, bis der Aufbewahrungszeitraum verstrichen ist. Die Richtlinie wird bis zum Ende eines Aufbewahrungszeitraums und der Beseitigung aller gesetzlichen Bestimmungen durchgesetzt.

Es wird empfohlen, dass Teams eine Aufbewahrungsrichtlinie für die Buckets festlegen, die als Nachweisschließfach verwendet werden, in dem jedes Objekt über einen Zeitraum von mindestens 365 Tagen gespeichert wird.

Bucketzugriffsberechtigungen

Bei der Verwendung von Cloud-Pipelines innerhalb der DevSecOps-Umgebung werden Objekte wie Beweismittel, Beweiszusammenfassungen und Artefakte entweder in Buckets in IBM Cloud Object Storage (COS) geleitet oder daraus gelesen. Die Tools erstellen, aktualisieren, löschen oder ändern keine Objekte oder Buckets.

Um einen sicheren Zugriff auf Ihre Cloud-Buckets von Object Storage zu gewährleisten und gleichzeitig die erforderlichen Pipeline-Vorgänge zu ermöglichen, befolgen Sie diese Zugriffsrichtlinien:

  • Zielgruppe.

    1. Diese Berechtigung stellt sicher, dass Continuous Delivery (CD)-Pipelines die Aufbewahrungseinstellungen des Eimers überprüfen können, ohne Daten zu ändern.
    2. Erforderlich, um die von der CI-Pipeline generierten Beweise zu lesen

  • Objekt-Schreiber.

    1. Diese Berechtigung ermöglicht es, dass Pipelines für kontinuierliche Integration (CI), CD und Konfigurationskontrolle (CC) neue Objekte in die Buckets hochladen oder schreiben können.

Schritte zum Erstellen von Dienstanmeldeinformationen

So erhalten Sie über Cloud Pipelines Zugriff auf Ihren COS-Bucket:

  1. Navigieren Sie zu den Service-Zugangsdaten:
  2. Neuen Berechtigungsnachweis erstellen:
    • Klicken Sie auf "Erstellen" und befolgen Sie die Anweisungen, um einen neuen Berechtigungsnachweis für Ihren COS-Bucket zu erstellen.

Schritte zur Zuweisung von Zugriff auf COS-Buckets

So weisen Sie Ihren COS-Buckets die entsprechenden Zugriffsberechtigungen zu:

  1. Navigieren Sie zu IAM-Bucket-Berechtigungen:
  2. Zuweisen von Rollen und Richtlinien:
    • Weisen Sie CD-Pipelines die Rolle "Leser" zu, um die Aufbewahrungsrichtlinien zu überprüfen.
    • Weisen Sie die Rolle des Objektschreibers CI-, CD- und CC-Pipelines zu, um Beweise in Buckets zu schreiben.

Wenn Sie den Object Storage Cloud-Bucket als Speicherort für Beweismaterial verwenden, werden die Berechtigungen „Leser” und „Objekt-Schreiber” empfohlen. Berechtigungen mit höheren Privilegien (z. B. Zugriff auf Administratorebene) sollten vermieden werden, um versehentliche oder böswillige Änderungen an Ihren Objekten zu verhindern.

Speicherklassen

Die Kosten variieren für Teams mit unterschiedlichen Konfigurationen und unterschiedlicher Bereitstellungshäufigkeit. Es wird nicht empfohlen, die kostenlose Stufe als Cloud- Object Storage-Buckets zu nutzen, da die kostenlose Stufe nicht so konfiguriert werden kann, dass sie unveränderlich ist.

Beispielschätzung

Wenn Sie mit einer Referenz-Pipeline für kontinuierliche Integration bzw. kontinuierliche Bereitstellung arbeiten, die jeweils sechs Schritte umfasst, erzeugt ein einzelner Durchlaufpaar aus kontinuierlicher Integration und kontinuierlicher Bereitstellung 37 Anfragen der Klasse A und sechs Anfragen der Klasse B.

  • Bei der kontinuierlichen Integration werden sechs Protokolle, sechs Artefakte und sechs Nachweise geschrieben, was 18 PUT-Anforderungen der Klasse A entspricht.
  • Bei der kontinuierlichen Bereitstellung werden sechs Nachweise (sechs GET – Klasse B) gelesen, sechs Nachweise, sechs Protokolle, sechs Artefakte und eine Zusammenfassung geschrieben, was insgesamt 19 PUT – Klasse A entspricht.

Bei durchschnittlich fünf Microservices (fünf × kontinuierliche Integration) und vier Bereitstellungsregionen (vier × kontinuierliche Bereitstellung) entspricht eine vollständige Bereitstellung 166 Anfragen der Klasse A und 24 Anfragen der Klasse B.

Bei einer vollständigen Bereitstellung pro Woche (vier pro Monat) können Sie pro Monat mit 664 Anforderungen der Klasse A und 96 Anforderungen der Klasse B rechnen.

Das erfasste Datenvolumen variiert je nach Anwendungsfall. Mit durchschnittlichen Größen für Angaben (1 kB), Testartefakte (100 kB) und Protokolle (15 kB) können Sie 0.01 GByte an Daten berechnen, die pro Monat erstellt und übertragen werden.

Ausfallsicherheit

Es wird empfohlen, die Cross-Region oder die Regional Ausfallsicherheit zu verwenden, wenn diese innerhalb der Grenzen sichergestellt werden soll. Weitere Informationen zu diesen Regionen finden Sie unter Endpunkte und Speicherpositionen.

Bucketname

Die Namen von Cloud- Object Storage-Buckets müssen global eindeutig und DNS-konform sein. Die Namen müssen eine Länge von 3-63 Zeichen aufweisen und Buchstaben in Kleinschreibung, Ziffern und Gedankenstriche enthalten. Bucketnamen müssen mit einem Kleinbuchstaben oder einer Ziffer anfangen und enden. Namen, die IP-Adressen ähneln, sind nicht zulässig. Bucketnamen müssen im gesamten IBM Cloud Object Storage-System eindeutig sein und dürfen keine personenbezogenen Daten wie z. B. einen Teil eines Namens oder einer Adresse, Finanzdaten, Sicherheitskonten oder SSN enthalten.

Bucketnamen müssen eindeutig sein, weil alle Buckets in der öffentlichen Cloud einen gemeinsamen Namensbereich verwenden. Diese Anforderung ermöglicht den Zugriff auf einen Bucket, ohne dass Angaben zu einer Service-Instanz oder zu einem Konto gemacht werden müssen. Es ist außerdem nicht möglich, einen Bucket mit einem Namen zu erstellen, der mit cosv1- oder account- beginnt, da diese Präfixe vom System reserviert sind.

Endpunkt

Verwenden Sie private-Endpunkte für die meisten Anforderungen, die aus IBM Cloud® stammen, und public-Endpunkte für die meisten Anforderungen, die aus IBM Cloud®stammen. Weitere Informationen finden Sie unter Endpunkttypen.

Verwenden Sie für Pipelines, die in der Region 'London' ausgeführt werden, direct-Endpunkte aufgrund der Pipeline-verwalteten Worker-Infrastruktur dort.

Konfigurieren von Toolchains mit dem COS-Bucket

Um Beweismittel, Vermögenswerte und Pfändungen zu speichern, konfigurieren Sie den COS-Bucket in Ihren Pipelines. Da dieser Eimer zur Wiederherstellung der vorhandenen Informationen verwendet wird, sollte er über Zugriff auf Reader und Object Writer verfügen. Um diesen Eimer in der Pipeline zu konfigurieren.

Umgebungseigenschaften für die COS-Eimer-Konfiguration |Name |Typ |Beschreibung |Erforderlich oder optional | Gesperrt oder entsperrt | |:----------|:------------------------------|:------------------|:----------|:----------| | cos-api-key | GEHEIM | Der API-Schlüssel Cloud Object Storage | Erforderlich | Gesperrt | | cos-access-key-id | SECRET | Die Cloud Object Storage Access Key ID aus HMAC-Anmeldeinformationen. (Wird zusammen mit cos-secret-access-key anstelle von cos-api-key bereitgestellt) | Erforderlich | Freigeschaltet | | cos-secret-access-key | SECRET | Der geheime Zugangsschlüssel Cloud Object Storage von HMAC-Anmeldeinformationen. (Wird zusammen mit cos-access-key-id anstelle von cos-api-key bereitgestellt) | Erforderlich | Freigeschaltet | | cos-bucket-name | Text | Der Name des Buckets in Ihrer Cloud Object Storage-Instanz, der als Beweismittel-Speicher verwendet wird. | Erforderlich | Entsperrt | | cos-endpoint | text | Der Endpunkt, der die Beweise aus der Cloud Object Storage-Instanz liest, die als Beweismittelschrank verwendet wird. Weitere Informationen finden Sie unter Endpunkttypen. | Erforderlich | Entsperrt |

Konfigurieren Sie denselben Bucket in allen Ihren Pipelines CI/CD/CC.

Migration von Git Evidence Locker zu COS Evidence Locker

Um die Build-Leistung, Zuverlässigkeit und Skalierbarkeit zu verbessern, wurde die Unterstützung für Git-basierte Evidence Lockers eingestellt. Der Umstieg auf Cloud Object Storage (COS)-basierte Evidence Lockers trägt dazu bei, die Abhängigkeit von Git Operationen zu verringern und Probleme mit Rate Limits von Git hosting Anbietern zu vermeiden.

Alle Benutzer sollten ihre Toolchains und Pipelines aktualisieren, um einen COS Evidence Locker zu verwenden.

Wenn Ihre Toolchain nur einen Git Evidence Locker verwendet

Befolgen Sie diese Schritte, um die Migration abzuschließen:

Wenn Ihre Toolchain sowohl Git als auch COS Evidence Lockers verwendet

Wenn Sie bereits beides konfiguriert haben:

  • Entfernen Sie die Eigenschaft evidence-repo „Umgebung“ aus allen Pipelines.
  • Entfernen Sie die GitHub/GitLab Integration, die mit dem Evidenz-Repository in Ihrer Toolchain verbunden ist.

Vorbereitung von CD-Pipelines für die Migration von Git zu COS Evidence Locker

Wenn Ihre CI- und CD-Pipelines auf einem Git Evidence Locker basieren, müssen die CD-Pipelines so konfiguriert werden, dass sie den COS Evidence Locker verwenden. Sie können einen der folgenden Ansätze wählen.

Ansatz 1: Bootstrap unter Verwendung beider Evidenzspeicher

Bei diesem Ansatz wird COS Evidence Locker aktiviert, während der Git Evidence Locker konfiguriert bleibt. Durch die parallele Ausführung beider Programme kann der COS Evidence Locker automatisch mithilfe des Git Evidence Locker gestartet werden.

  • Behalten Sie die Konfiguration Git des Evidence Locker bei.
  • Aktivieren Sie den COS Evidence Locker.
  • Führen Sie die CD-Pipeline mit einer Pipeline-Definitionsversion aus , die älter ist als v10.46.1 (empfohlen: v10.45.0 ).
  • Entfernen Sie nach Abschluss des Vorgangs die Git Evidence Locker-Konfiguration wie zuvor beschrieben.

Ansatz 2: Bootstrap ohne Git Evidence Locker

Verwenden Sie diesen Ansatz, wenn Sie eine saubere Migration bevorzugen, ohne sich auf Git.

  • Entfernen Sie die Konfiguration Git des Evidenzschranks.
  • Führen Sie einen einmaligen CD-Pipeline-Lauf mit dem force-redeploy Parameter auf durch true.
  • Nach Abschluss des Laufs setzen Sie den Parameter zurück force-redeploy auf false oder entfernen Sie ihn vollständig.

Diese einmalige CD-Pipeline-Ausführung stellt sicher, dass der COS Evidence Locker mit allen vorhandenen Inventar-Assets gefüllt wird. Es ist nur eine einzige anfängliche Ausführung erforderlich, und Sie können. Wenn Sie keine tatsächliche Bereitstellung auslösen möchten, können Sie die Phasen „Bereitstellung“ und „Abnahmetest“ überspringen, um die CD-Pipeline ohne Bereitstellungsaktionen auszuführen.

Sie können sich dafür entscheiden, den Git Beweisspeicher nach der Entfernung zu archivieren, da dies für Prüfungszwecke erforderlich wäre.

Migration von einem COS-Bucket zu einem anderen COS-Bucket

Migration von einem COS-Bucket zu einem anderen COS-Bucket Wenn Sie bereits Benutzer des COS-Beweismittelschranks sind und von einem COS-Bucket zu einem anderen migrieren müssen, ist es wichtig, einen reibungslosen Übergang zu gewährleisten, ohne Ihre Arbeitsabläufe zu unterbrechen. Nachfolgend finden Sie die Schritte und Überlegungen für die Migration zwischen COS-Buckets.

Gründe für Migration:

  • Organisatorische Umstrukturierung: Sie möchten vielleicht einen bestimmten COS-Bereich nicht mehr verwenden und stattdessen einen anderen nutzen.
  • Umzug des Eimers: Der Eimer muss von einem Konto auf ein anderes verschoben werden, möglicherweise aufgrund von organisatorischen Änderungen oder Compliance-Anforderungen.

Schritte zur Migration:

Konfigurieren Sie den Backup-COS-Bucket: Wenn Sie von einem alten COS-Bucket zu einem neuen migrieren, stellen Sie sicher, dass Ihre Pipeline so konfiguriert ist, dass sie sowohl den alten als auch den neuen Bucket verwendet. Dies ermöglicht eine reibungslose Migration, ohne Ihre bestehenden Arbeitsabläufe zu unterbrechen.

  • Erstellen Sie den neuen COS-Bucket wie oben beschrieben.
  • IAM-Richtlinien konfigurieren: Stellen Sie sicher, dass der neue COS-Bucket über die erforderlichen IAM-Richtlinien für den Reader- und Object-Writer-Zugriff verfügt, wie von Ihren Pipelines gefordert.
  • Umgebungsvariablen aktualisieren

Aktualisieren Sie in IBM Toolchains die Umgebungsvariablen, um sowohl die alten als auch die neuen COS-Buckets einzuschließen. Um den alten Bucket zu konfigurieren, verwenden Sie das Präfix "backup" in allen COS-Umgebungseigenschaften und verwenden Sie die normalen Eigenschaften, um den neuen COS-Bucket zu konfigurieren.

Name Typ Beschreibung Erforderlich oder optional Gesperrt oder entsperrt
backup-cos-api-key secret Der API-Schlüssel für die Backup Cloud Object Storage-API. Erforderlich Gesperrt
backup-cos-access-key-id secret Die Backup-Zugriffsschlüssel-ID Cloud Object Storage von HMAC-Anmeldeinformationen. (Wird zusammen mit backup-cos-secret-access-key anstelle von backup-cos-api-key bereitgestellt) Erforderlich Entsperrt
backup-cos-secret-access-key secret Der Backup-Zugangsschlüssel Cloud Object Storage Secret Access Key von HMAC-Zugangsdaten. (Wird zusammen mit backup-cos-access-key-id anstelle von backup-cos-api-key bereitgestellt) Erforderlich Entsperrt
backup-cos-bucket-name Text Der Name des Backup-Buckets in Ihrer Cloud Object Storage-Instanz, der als Evidence Locker verwendet wird. Erforderlich Entsperrt
backup-cos-endpoint Text Der Endpunkt, der die Beweise aus der Sicherungsinstanz Cloud Object Storage liest, die als Beweismittelschrank verwendet wird. Weitere Informationen finden Sie unter Endpunkttypen. Erforderlich Entsperrt

Löschen Sie den alten Bucket nicht vor Ablauf von 365 Tagen, da er für Prüfungszwecke benötigt wird.

Fehlerbehebungsanleitung für langsam laufende Pipelines

  1. force-redeploy sollte nicht auf true gesetzt werden, es sei denn, es handelt sich um eine Neuverteilung aller Einträge.
  2. Die Promotionspipeline sollte verwendet werden, um den richtigen Satz von Deltas zu promoten, damit die Deltarechnung korrekt ist.
  3. Wenn Sie solche Zeilen sehen, bedeutet dies, dass die CI-Pipeline nicht die richtigen Zusammenfassungen erzeugt. Kehren Sie zur CI-Pipeline zurück und überprüfen Sie, ob bei der Erstellung der Mini-Zusammenfassungen im Finish-Schritt ein Fehler aufgetreten ist.