Skip to main content
Le support du stockage est qualifié par version CaseBender, adaptateur fournisseur et profil de déploiement. Un nom de fournisseur seul n’est pas une preuve suffisante.

​
Porte de version

Avant de publier une version on-premises ou OpenShift :
  1. Épinglez chaque image par digest dans le manifeste de version.
  2. Générez un SBOM CycloneDX ou SPDX pour chaque image et le lot source.
  3. Signez les images et attestez les SBOM avec l’identité de version.
  4. Analysez les digests exacts publiés/miroités, y compris les paquets OS et de langage.
  5. Examinez les SDK de stockage, les bibliothèques TLS, les lots CA et les dépendances transitives.
  6. Exécutez les tests de contrat fournisseur, d’intégrité, de migration, de sauvegarde/restauration et de rollback pour chaque fournisseur listé comme supporté par cette version.
  7. Enregistrez les exceptions avec propriétaire, exploitabilité, contrôle compensatoire, expiration et approbation. Ne supprimez pas une famille de paquets entière.
Les workflows de version du dépôt produisent déjà des preuves SBOM et de signature, et deploy/verify-images.sh vérifie les signatures d’image, les attestations CycloneDX et la politique de vulnérabilités. Utilisez ces contrôles contre chaque digest après miroir ainsi qu’avant l’export.

​
Vérification consommateur

Obtenez le manifeste de version, les sommes de contrôle, la politique d’identité/émetteur Sigstore, les SBOM et les attestations via un canal de confiance séparé. Puis :
Utilisez l’identité et l’émetteur exacts des notes de version signées, pas ces espaces réservés. Un échec de vérification est un bloqueur de version. Préservez les preuves du journal de transparence lorsque vous êtes connecté ; pour une vérification déconnectée, transférez le lot signé et le matériel de confiance public via le processus approuvé.

​
Revue SBOM spécifique au stockage

Confirmez que le SBOM contient les adaptateurs sélectionnés à l’exécution et examinez :
  • les composants MinIO historiques uniquement dans les artefacts source/reprise héritage ; l’exécution de production ne doit pas contenir le paquet natif minio ;
  • @aws-sdk/client-s3 pour S3 ; une dépendance presigner ne doit pas impliquer un comportement d’URL signées activé ;
  • @google-cloud/storage et les bibliothèques d’authentification pour GCS ;
  • @azure/storage-blob et @azure/identity pour Azure ;
  • Node.js/OpenSSL et le lot CA de l’image ;
  • les images CLI/outils utilisées pour la sauvegarde, la migration et la validation.
Un adaptateur installé mais non sélectionné contribue toujours au risque de paquet atteignable et doit rester dans la revue SBOM et de vulnérabilités. Inversement, la présence dans le SBOM ne prouve pas qu’un produit/une version est certifié. Azure est implémenté sous l’ID d’exécution canonique azure, mais la matrice actuelle ne déclare pas azure-blob comme supporté par la version.

​
Enregistrement de preuves de version

Conservez :
  • la révision source, les digests d’image immuables, les hachages SBOM, les signatures et la sortie de vérification ;
  • les bases de données/versions d’outils du scanner et les exceptions de vulnérabilités approuvées ;
  • les versions fournisseur/produit, le protocole/chiffre/émetteur TLS du point de terminaison et le hachage CA ;
  • les résultats de contrat fournisseur assainis et d’intégrité SHA-256 ;
  • les journaux de copie/vérification de migration et le résultat de rollback ;
  • le point de cohérence de sauvegarde, le test de restauration, le RPO/RTO mesuré ;
  • la version OpenShift, la revue SCC, les manifestes rendus, les versions CNI/CSI et les tests d’écriture /tmp//data UID arbitraire.
N’incluez jamais de clés d’accès, de valeurs secrètes, d’URL pré-signées, de clés privées, d’URL de base de données, de noms d’objets client ou de contenus d’objets dans les preuves de version ou les lots de support.

​
Réponse de sécurité

Lorsqu’une vulnérabilité de SDK de stockage ou de fournisseur est divulguée, déterminez si le code et la configuration concernés sont présents et atteignables, publiez un avis ciblé, mettez à jour les images/SBOM affectés et relancez les tests de contrat et de restauration. Le retrait d’un fournisseur est une décision de cycle de vie produit avec un avis explicite, un guide de migration et des dates de support. Le guide CaseBender actuel traite un déploiement MinIO héritage uniquement comme source externe de migration/rollback ; cette politique n’invente pas de date de fin de support client au-delà d’un plan de changement client approuvé.