Skip to main content
Sélectionnez le stockage d’abord selon les exigences opérationnelles, puis confirmez la déclaration de support lisible par machine de la version. CaseBender ne considère pas chaque backend implémenté par un SDK comme certifié pour la version.

Flux de sélection

  1. Choisissez un service externe, géré par le client, accessible à la fois par le web et le worker.
  2. Provisionnez des emplacements distincts quarantine, records et ephemeral.
  3. Confirmez les exigences d’identité, TLS/CA privée, chiffrement, versioning, rétention, conservation légale, journalisation d’audit, egress, sauvegarde et restauration.
  4. Comparez le profil produit exact avec scripts/storage/certification-matrix.json.
  5. Exécutez la qualification en direct contre le produit/la version exacts depuis le réseau des charges de travail.
  6. Signez et conservez des preuves assainies avec l’enregistrement de version.

Interprétation de la matrice actuelle

Les preuves en direct ODF/Ceph actuelles sont bloquées par les identifiants du client. Le profil est configuré et prêt pour la qualification, non certifié. Ne mettez à jour le statut client qu’après que le validateur de version a accepté des preuves signées de version exacte.

Niveaux de preuve

  • Unit prouve le comportement de l’adaptateur local dans des tests de code contrôlés.
  • Emulator prouve la compatibilité SDK et de contrat avec le sous-ensemble d’un émulateur.
  • Live prouve les opérations requises contre un produit nommé et une version exacte dans le contexte réseau, de confiance, d’identité et de politique prévu.
Les résultats d’émulateur ne peuvent jamais satisfaire une entrée de matrice dont requiredCertification est live. Les noms de famille de produits tels que « S3 compatible », « Ceph » ou « Azure Blob » sont insuffisants sans une version cible exacte et un condensé de preuves. La compatibilité d’émulateur n’est pas une certification en direct.

Valider la matrice

Partez de scripts/storage/certification-evidence.template.json. N’ajoutez jamais d’identifiants, de jetons, de chaînes de connexion, de clés privées, de contenus d’objets, de noms d’objets client ou d’URL signées aux preuves.

Exemples de configuration

Pour la production, préférez un STORAGE_CONFIG_FILE monté en mode 0400 ou 0600. Cette forme est illustrative :
Le schéma de profil strict complet est documenté dans les pages des fournisseurs. Ne placez pas de clés d’accès dans la documentation et ne commitez pas un fichier de configuration renseigné.

Déclencheurs de requalification

Relancez les preuves en direct après toute modification de :
  • la version CaseBender ou le SDK de stockage ;
  • le fournisseur, ODF, Ceph, le compte ou la version d’API ;
  • la sécurité, le versioning, la rétention ou l’immuabilité du bucket/conteneur ;
  • l’identité, le rôle, l’identifiant, le point de terminaison, la CA privée ou la politique d’egress ;
  • la frontière scanner/promotion ; ou
  • les outils de sauvegarde, de migration et de restauration.
Guides associés :