Utilisation de compartiments IBM Cloud Object Storage comme casier de preuves

Vous pouvez configurer des compartiments COS ( IBM Cloud Object Storage ) pour stocker les preuves générées par les contrôles de conformité intégrés aux pipelines d’ DevSecOps. Les preuves de conformité créent la trace d'audit que les auditeurs recherchent lors d'un audit de conformité. L'un des objectifs de DevSecOps consiste à générer et stocker de manière automatisée des preuves dans des éléments de verrouillage des preuves vérifiables. Pour plus d'informations, voir Verrouillage des informations collectées.

Le pipeline d'automatisation de la conformité stocke les informations suivantes dans le compartiment COS :

Artefacts de tâche
Résultats de tests, résultats d'analyse ou toute autre sortie enregistrée par les tâches.
Journaux des tâches
Une fois le pipeline exécuté, les journaux relatifs à cette exécution sont envoyés vers le evidence locker.
Preuve
Informations sur les tâches et leurs résultats, qui peuvent être soit un échec, soit une réussite. Pour plus d'informations sur le format des preuves qui sont envoyées, voir Récapitulatif de preuves.

Configuration de votre compartiment

Une instance de cloud Object Storage dédiée doit être créée avant la configuration d'une chaîne d'outils d'intégration continue ou de déploiement continu. Ce compartiment COS est utilisé pour le stockage lié à la conformité car des casiers d'informations collectées doivent être créés en limite pour vos applications. Cela permet d'améliorer la résilience de votre pipeline. Pour plus d'informations, voir Résilience.

Pour configurer votre compartiment Cloud Object Storage afin qu’il serve de référentiel de preuves de conformité dans le cadre d’un pipeline d’intégration continue ou de déploiement continu, vous pouvez vous référer aux informations suivantes. Les scripts modèles de pipeline ou de chaîne d’outils ne configurent pas le locker dans Cloud Object Storage.

Consultez cette page pour plus d'informations sur les considérations (granularité, sécurité,...) relatives à l'utilisation de Cloud Object Storage comme preuve de conformité.

Stratégie de conservation

Vous pouvez configurer les compartiments de stockage Cloud Object Storage pour appliquer une politique ou une durée de conservation aux objets téléchargés, également appelés objets immuables(Object Storage). La fonction Immutable Object Storage conserve les enregistrements électroniques et assure l'intégrité des données. Les politiques de conservation garantissent que les données sont stockées selon le principe Write-One-Read-Many (WORM), de manière indélébile et non réinscriptible. Vous ne pouvez pas modifier ou supprimer les objets des compartiments protégés au cours de la durée de conservation ni supprimer les compartiments protégés proprement dits tant que la durée de conservation n'est pas terminée. La règle s'applique jusqu'à la fin de la durée de conservation et le retrait de toute détention légale.

Il est recommandé de demander aux équipes d'établir une règle de conservation pour les compartiments qu'ils utilisent comme casier de preuves et qui stockent chaque objet pendant au moins 365 jours.

Droits d'accès au compartiment

Lors de l'utilisation de pipelines cloud dans l'environnement d' DevSecOps, les objets tels que les preuves, les résumés de preuves et les artefacts sont soit acheminés vers, soit lus à partir de Buckets dans l'environnement de stockage de données ( IBM Cloud Object Storage, COS). Les outils ne créent, ne mettent à jour, ne suppriment ni ne modifient aucun objet ou compartiment.

Pour garantir un accès sécurisé à vos compartiments d' Object Storage s cloud tout en facilitant les opérations de pipeline nécessaires, suivez ces politiques d'accès :

  • Lecteur.

    1. Cette autorisation permet aux pipelines de données de configuration ( Continuous Delivery, CD) de vérifier les paramètres de conservation du compartiment sans modifier aucune donnée.
    2. Nécessaire pour lire les preuves générées par le pipeline CI

  • Rédacteur de contenu.

    1. Cette autorisation permet aux pipelines d'intégration continue (CI), de livraison continue (CD) et de contrôle de configuration (CC) de télécharger ou d'écrire de nouveaux objets dans les compartiments.

Étapes de création des identifiants de service

Pour accéder à votre bucket COS à l'aide de Cloud Pipelines :

  1. Accédez aux informations d'identification du service :
  2. Créer un nouveau justificatif d'identité :
    • Cliquez sur « Créer » et suivez les instructions pour créer un nouvel identifiant de service pour votre compartiment COS.

Étapes pour attribuer l'accès aux buckets COS

Pour attribuer les autorisations d'accès appropriées à vos buckets COS :

  1. Accédez aux autorisations de compartiment IAM :
  2. Attribuer des rôles et des politiques :
    • Attribuer le rôle de lecteur aux pipelines CD pour vérifier les politiques de rétention.
    • Attribuer le rôle Object Writer aux pipelines CI, CD et CC pour l'écriture des preuves dans les buckets.

Lorsque vous utilisez le compartiment Object Storage Cloud comme espace de stockage des preuves, les autorisations recommandées sont Lecteur et Éditeur d'objets. Les autorisations avec des privilèges plus élevés (par exemple, un accès de niveau administrateur) doivent être évitées pour empêcher toute modification accidentelle ou malveillante de vos objets.

Classes de stockage

Les coûts varient pour les équipes ayant des configurations différentes et une fréquence de déploiement différente. Il n'est pas recommandé d'utiliser l'offre gratuite comme compartiments de stockage Cloud Object Storage, car celle-ci ne peut pas être configurée pour être immuable.

Exemple d'estimation

Si vous travaillez avec un pipeline de référence d'intégration continue ou de déploiement continu comportant six éléments de preuve chacun, une seule paire d'exécutions d'intégration continue et de déploiement continu génère 37 requêtes de classe A et six requêtes de classe B.

  • L'intégration continue écrit six journaux, six artefacts et six preuves, ce qui équivaut à 18 demandes PUT de classe A.
  • Le déploiement continu lit six éléments de preuve (six GET - Classe B), écrit six éléments de preuve, six journaux, six artefacts et un résumé, ce qui équivaut à 19 PUT - Classe A.

Avec en moyenne cinq microservices (cinq × intégration continue) et quatre régions de déploiement (quatre × déploiement continu), un déploiement complet équivaut à 166 requêtes de classe A et 24 requêtes de classe B.

Avec un déploiement complet par semaine (quatre par mois), vous pouvez calculer 664 demandes de classe A et 96 demandes de classe B par mois.

La quantité de données collectées varie en fonction des cas d'utilisation. Avec des tailles moyennes pour les informations collectées (1 kB), les artefacts de test (100 kB) et les journaux (15 kB), vous pouvez calculer 0.01 Goctet de données créé et transféré par mois.

Résilience

Il est recommandé d'utiliser les options de résilience Cross-Region ou Regional pour maintenir une résilience interne. Pour plus d'informations sur ces régions, voir Noeuds finaux et emplacements de stockage.

Nom du compartiment

Les noms de compartiments d' Object Storage s dans le cloud doivent être uniques au niveau mondial et conformes aux normes DNS. Ils doivent comporter entre 3 et 63 caractères et contenir des minuscules, des chiffres et des tirets. Les noms de compartiment doivent commencer et se terminer par une lettre minuscule ou un chiffre. Les noms qui ressemblent à des adresses IP ne sont pas autorisés. Les noms de compartiment doivent être uniques à l'échelle du système IBM Cloud Object Storage et ne peuvent pas contenir d'informations personnelles, comme une partie d'un nom ou d'une adresse, ou des comptes financiers ou de sécurité, ou des numéros de sécurité sociale.

Les noms de compartiment doivent être uniques car tous les compartiments du cloud public partagent un espace de nom global. Cette exigence permet d'accéder à un compartiment sans avoir à fournir d'informations relatives à une instance de service ou à un compte. Il n’est pas non plus possible de créer un compartiment dont le nom commence par cosv1- ou account-, car ces préfixes sont réservés par le système.

Noeud final

Utilisez des noeuds finaux private pour la plupart des demandes provenant de IBM Cloud® et utilisez des noeuds finaux public pour la plupart des demandes provenant de l'extérieur de IBM Cloud®. Pour plus d'informations, voir Types de noeud final.

Pour les pipelines qui s'exécutent dans la région de Londres, utilisez les noeuds finaux direct en raison de l'infrastructure d'agent gérée par pipeline qui s'y trouve.

Configuration des chaînes d'outils avec le bucket COS

Pour stocker les preuves, les actifs et les pièces jointes, configurez le compartiment COS dans vos pipelines. Puisque ce bucket est utilisé pour récupérer les informations existantes, il doit disposer d'un accès à l' Reader et à l' Object Writer. Pour confgurer ce seau dans le pipeline.

Environnement Propriétés pour la configuration du seau COS | Nom | Type | Description | Obligatoire ou facultatif | Verrouillé ou déverrouillé | |:----------|:------------------------------|:------------------|:----------|:----------| | cos-api-key | SECRET | La clé API d' Cloud Object Storage. | Obligatoire | Verrouillé | | cos-access-key-id | SECRET | L' Cloud Object Storage ID de clé d'accès à partir des identifiants HMAC. (Fourni avec cos-secret-access-key au lieu de cos-api-key)| Obligatoire | Déverrouillé | | cos-secret-access-key | SECRET | La clé d'accès secrète de l' Cloud Object Storage, à partir des identifiants HMAC. (Fourni avec cos-access-key-id au lieu de cos-api-key) | Obligatoire | Déverrouillé | | cos-bucket-name | texte | Nom du compartiment de votre instance d' Cloud Object Storage utilisé comme coffre-fort de preuves. | Obligatoire | Déverrouillé | | cos-endpoint | text | Le point de terminaison qui lit les preuves de l'instance d' Cloud Object Storage, utilisée comme coffre-fort de preuves. Pour plus d'informations, voir Types de points de terminaison. | Obligatoire | Déverrouillé |

Configurez le même compartiment dans tous vos pipelines CI/CD/CC.

Migration depuis Git Evidence Locker vers COS Evidence Locker

Afin d'améliorer les performances, la fiabilité et l'évolutivité de la compilation, la prise en charge des Evidence Git Lockers basés sur a été abandonnée. Le passage à des Evidence Cloud Object Storage Lockers basés sur COS permet de réduire la dépendance vis-à-vis Git des opérations et d'éviter les problèmes de limitation de débit imposés par Git hosting les fournisseurs.

Tous les utilisateurs doivent mettre à jour leurs chaînes d'outils et leurs pipelines afin d'utiliser un COS Evidence Locker.

Lorsque votre chaîne d'outils utilise uniquement un Git Evidence Locker

Suivez ces étapes pour effectuer la migration :

Lorsque votre chaîne d'outils utilise à la fois Git et COS Evidence Lockers

Si vous avez déjà configuré les deux :

  • Supprimez la evidence-repo propriété environment de tous les pipelines.
  • Supprimez GitHub/GitLab l'intégration associée au référentiel de preuves dans votre chaîne d'outils.

Préparation des pipelines CD pour la migration de Git vers COS Evidence Locker

Si vos pipelines CI et CD s'appuient sur un Git Evidence Locker, les pipelines CD doivent être amorcés pour utiliser le COS Evidence Locker. Vous pouvez choisir l'une des approches suivantes.

Approche 1 : Bootstrap utilisant les deux coffres-forts de preuves

Dans cette approche, COS Evidence Locker est activé tandis Git que Evidence Locker reste configuré. Le fait de les exécuter en parallèle permet au COS Evidence Locker d'être automatiquement amorcé à l'aide du Git Evidence Locker.

  • Conservez la Git configuration du casier à preuves.
  • Activez le COS Evidence Locker.
  • Exécutez le pipeline CD à l'aide d'une version de définition de pipeline antérieure à v10.46.1 (recommandé : v10.45.0 ).
  • Une fois l'exécution terminée, supprimez la configuration Git Evidence Locker comme décrit précédemment.

Approche 2 : Bootstrap sans Git Evidence Locker

Utilisez cette approche si vous préférez une migration propre sans dépendre de Git.

  • Supprimez la configuration Git Evidence Locker.
  • Effectuez une exécution unique du pipeline CD avec le force-redeploy paramètre défini sur true.
  • Une fois l'exécution terminée, réinitialisez force-redeploy à false ou supprimez complètement le paramètre.

Cette exécution unique du pipeline CD garantit que le COS Evidence Locker est alimenté avec tous les actifs d'inventaire existants. Une seule exécution initiale est nécessaire et vous pouvez. Si vous préférez ne pas déclencher de déploiement réel, vous pouvez ignorer les étapes de déploiement et de test d'acceptation pour exécuter le pipeline CD sans effectuer aucune action de déploiement.

Vous pouvez choisir d'archiver le Git coffre-fort de preuves après la suppression, car cela pourrait être nécessaire à des fins d'audit.

Migration d'un compartiment COS vers un autre compartiment COS

Migration d'un compartiment COS vers un autre Si vous êtes déjà utilisateur du système de stockage des preuves COS et que vous devez migrer d'un compartiment COS vers un autre, il est important de veiller à ce que la transition se fasse en douceur, sans perturber vos flux de travail. Vous trouverez ci-dessous les étapes et les considérations relatives à la migration entre les buckets COS.

Raisons de la migration :

  • Restructuration organisationnelle: Vous pouvez décider de ne plus utiliser un compartiment de la structure de classification des articles (COS) et d'en utiliser un autre.
  • Déplacement du compartiment: Le compartiment doit être déplacé d'un compte à un autre, éventuellement en raison de changements organisationnels ou d'exigences de conformité.

Étapes de la migration :

Configurer le compartiment Backup-COS: si vous migrez d'un ancien compartiment COS vers un nouveau, assurez-vous que votre pipeline est configuré pour utiliser à la fois l'ancien et le nouveau compartiment. Cela permet une migration en douceur sans perturber vos flux de travail existants.

  • Créez le nouveau compartiment COS comme défini dans les étapes ci-dessus.
  • Configurer les politiques IAM : Assurez-vous que le nouveau compartiment COS dispose des politiques IAM nécessaires pour l'accès aux lecteurs et aux graveurs d'objets, comme l'exigent vos pipelines.
  • Mise à jour des variables d'environnement

Dans les chaînes d'outils d' IBM, mettez à jour les variables d'environnement pour inclure les anciens et les nouveaux buckets COS. Pour configurer l'ancien bucket, utilisez le préfixe backup- dans toutes les propriétés COS env et utilisez les propriétés normales pour configurer le nouveau bucket COS.

Nom Type Description Requise ou facultative Verrouillé ou déverrouillé
backup-cos-api-key SECRET La clé API de l' Cloud Object Storage de sauvegarde. Obligatoire Verrouillé
backup-cos-access-key-id SECRET L' Cloud Object Storage de sauvegarde ID de clé d'accès à partir des identifiants HMAC. (Fourni avec backup-cos-secret-access-key au lieu de backup-cos-api-key) Obligatoire Déverrouillé
backup-cos-secret-access-key SECRET La clé d'accès secrète de sauvegarde de l' Cloud Object Storage, à partir des identifiants HMAC. (Fourni avec backup-cos-access-key-id au lieu de backup-cos-api-key) Obligatoire Déverrouillé
backup-cos-bucket-name texte Nom du compartiment de sauvegarde de votre instance d' Cloud Object Storage, utilisé comme espace de stockage des preuves. Obligatoire Déverrouillé
backup-cos-endpoint texte Le point final qui lit les preuves de l'instance d' Cloud Object Storage s de sauvegarde utilisée comme coffre-fort de preuves. Pour plus d'informations, voir Types de points de terminaison. Obligatoire Déverrouillé

Ne supprimez pas l'ancien seau pendant 365 jours, car il serait nécessaire à des fins d'audit.

Guide de dépannage pour les pipelines lents

  1. force-redeploy ne doit pas être fixé à true, à moins qu'il ne s'agisse d'un redéploiement de toutes les entrées.
  2. Le pipeline de promotion doit être utilisé pour promouvoir l'ensemble correct de delta, afin que le calcul du delta soit correct.
  3. Si vous voyez de telles lignes, cela signifie que le pipeline CI ne génère pas les bons résumés. Retourner au pipeline CI et vérifier s'il y a une erreur lors de la création des mini-sommaires dans l'étape de finition.