> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Selezione e certificazione del provider di storage

> Seleziona un provider senza confondere la compatibilità dell'adapter con la certificazione live

Seleziona lo storage prima in base ai requisiti operativi, poi conferma la dichiarazione
di supporto machine-readable della release. CaseBender non tratta ogni backend
implementato da un SDK come certificato nella release.

## Flusso di selezione

1. Scegli un servizio esterno, gestito dal cliente, raggiungibile sia dal web sia
   dal worker.
2. Provisiona località separate `quarantine`, `records` ed `ephemeral`.
3. Conferma i requisiti di identità, TLS/CA privata, crittografia, versioning, retention, legal
   hold, audit logging, egress, backup e ripristino.
4. Confronta il profilo prodotto esatto con
   `scripts/storage/certification-matrix.json`.
5. Esegui la qualificazione live contro il prodotto/versione esatti dalla rete
   del workload.
6. Firma e conserva le evidenze sanitizzate insieme al record della release.

## Interpretazione della matrice attuale

| ID matrice             | Adapter runtime | Supporto dichiarato | Modalità richiesta | Significato per l'operatore                                                          |
| ---------------------- | --------------- | ------------------- | ------------------ | ------------------------------------------------------------------------------------ |
| `openshift-odf-rgw`    | `s3`            | Sì                  | `live`             | Target di supporto solo dopo che le evidenze live esatte di ODF/Ceph superano i test |
| `aws-s3`               | `s3`            | No                  | `live`             | Adapter implementato; non rivendicare la certificazione della release                |
| `google-cloud-storage` | `gcs`           | No                  | `live`             | Adapter implementato; non rivendicare la certificazione della release                |
| `azure-blob`           | `azure`         | No                  | `live`             | Adapter implementato; non descrivere Azure come codice non supportato                |
| `local-development`    | `local`         | No                  | `unit`             | Solo sviluppo/test su singolo nodo                                                   |

Le evidenze live attuali di ODF/Ceph sono bloccate dalle credenziali del cliente. È
configurato e pronto per la qualificazione, non certificato. Aggiorna lo stato rivolto
al cliente solo dopo che il validatore della release accetta evidenze firmate di versione esatta.

## Livelli di evidenza

* **Unit** dimostra il comportamento locale dell'adapter in test di codice controllati.
* **Emulator** dimostra la compatibilità SDK e di contratto con il sottoinsieme di un emulator.
* **Live** dimostra le operazioni richieste contro un prodotto nominato e una versione
  esatta nel contesto di rete, trust, identità e policy previsto.

I risultati di emulator non possono mai soddisfare una voce della matrice il cui
`requiredCertification` è `live`. I nomi di famiglia di prodotto come “S3
compatible,” “Ceph” o “Azure Blob” sono insufficienti senza una versione target
esatta e un digest delle evidenze.

La compatibilità con l'emulator non è certificazione live.

## Valida la matrice

```bash theme={null}
node scripts/storage/validate-certification-matrix.mjs
node --test scripts/storage/certification-matrix.test.mjs

# Release use requires a sanitized evidence JSON document.
node scripts/storage/validate-certification-matrix.mjs \
  --release \
  --evidence '<path-to-sanitized-evidence.json>'
```

Parti da `scripts/storage/certification-evidence.template.json`. Non aggiungere mai
credenziali, token, connection string, chiavi private, contenuti degli oggetti,
nomi di oggetti del cliente o URL firmati alle evidenze.

## Esempi di configurazione

Per la produzione, preferisci un `STORAGE_CONFIG_FILE` montato con modalità
`0400` o `0600`. Questa forma è illustrativa:

```json theme={null}
{
  "profiles": {
    "quarantine": { "provider": "s3", "bucket": "<quarantine-bucket>", "region": "<region>" },
    "records": { "provider": "s3", "bucket": "<records-bucket>", "region": "<region>", "requireWorm": true },
    "ephemeral": { "provider": "s3", "bucket": "<ephemeral-bucket>", "region": "<region>" }
  }
}
```

Lo schema completo e rigoroso del profilo è documentato nelle pagine dei provider. Non
inserire access key nella documentazione né committare un file di configurazione popolato.

## Trigger di riqualificazione

Riesegui le evidenze live dopo aver modificato uno qualsiasi di:

* release CaseBender o SDK di storage;
* provider, ODF, Ceph, account o versione API;
* sicurezza, versioning, retention o immutabilità di bucket/container;
* identità, ruolo, credenziale, endpoint, CA privata o policy di egress;
* confine scanner/promotion; oppure
* tooling di backup, migrazione e ripristino.

Guide correlate:

* [Policy di supporto dello storage enterprise](/it/deployment/storage-support-policy)
* [Certificazione S3-compatibile](/it/deployment/storage-s3-compatible)
* [Sicurezza della release dello storage](/it/deployment/storage-release-security)
