> ## 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.

# Selección y certificación de proveedores de almacenamiento

> Seleccione un proveedor sin confundir la compatibilidad del adaptador con la certificación en vivo

Seleccione el almacenamiento primero por requisitos operativos y, a continuación,
confirme la declaración de soporte legible por máquina de la versión. CaseBender no
trata cada backend implementado por un SDK como certificado en la versión.

## Flujo de selección

1. Elija un servicio externo, gestionado por el cliente, al que puedan acceder tanto
   web como worker.
2. Aprovisione ubicaciones separadas `quarantine`, `records` y `ephemeral`.
3. Confirme los requisitos de identidad, TLS/CA privada, cifrado, versionado,
   retención, retención legal, registro de auditoría, egreso, copia de seguridad y
   restauración.
4. Compare el perfil de producto exacto con
   `scripts/storage/certification-matrix.json`.
5. Ejecute la cualificación en vivo contra el producto/versión exactos desde la red
   de la carga de trabajo.
6. Firme y conserve la evidencia saneada junto con el registro de la versión.

## Interpretación de la matriz actual

| ID de matriz           | Adaptador en tiempo de ejecución | Declarado como soportado | Modo requerido | Significado para el operador                                                        |
| ---------------------- | -------------------------------- | ------------------------ | -------------- | ----------------------------------------------------------------------------------- |
| `openshift-odf-rgw`    | `s3`                             | Yes                      | `live`         | Destino de soporte solo después de que la evidencia en vivo exacta de ODF/Ceph pase |
| `aws-s3`               | `s3`                             | No                       | `live`         | Adaptador implementado; no reclame certificación de la versión                      |
| `google-cloud-storage` | `gcs`                            | No                       | `live`         | Adaptador implementado; no reclame certificación de la versión                      |
| `azure-blob`           | `azure`                          | No                       | `live`         | Adaptador implementado; no describa Azure como código no soportado                  |
| `local-development`    | `local`                          | No                       | `unit`         | Solo desarrollo/pruebas de un solo nodo                                             |

La evidencia en vivo actual de ODF/Ceph está bloqueada por las credenciales del
cliente. Está configurada y lista para cualificación, no certificada. Actualice el
estado orientado al cliente solo después de que el validador de la versión acepte
evidencia firmada de la versión exacta.

## Niveles de evidencia

* **Unit** demuestra el comportamiento del adaptador local en pruebas de código
  controladas.
* **Emulator** demuestra la compatibilidad del SDK y del contrato con el subconjunto
  de un emulador.
* **Live** demuestra las operaciones requeridas contra un producto nombrado y una
  versión exacta en el contexto de red, confianza, identidad y política previstos.

Los resultados del emulador nunca pueden satisfacer una entrada de la matriz cuyo
`requiredCertification` sea `live`. Los nombres de familia de producto como
«S3 compatible», «Ceph» o «Azure Blob» son insuficientes sin una versión de destino
exacta y un digest de evidencia.

La compatibilidad del emulador no es certificación en vivo.

## Validar la matriz

```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>'
```

Comience con `scripts/storage/certification-evidence.template.json`. Nunca añada
credenciales, tokens, cadenas de conexión, claves privadas, contenidos de objeto,
nombres de objeto del cliente ni URL firmadas a la evidencia.

## Ejemplos de configuración

Para producción, prefiera un `STORAGE_CONFIG_FILE` montado con modo `0400` o
`0600`. Esta forma es ilustrativa:

```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>" }
  }
}
```

El esquema estricto completo del perfil está documentado en las páginas de
proveedores. No ponga claves de acceso en la documentación ni confirme un archivo
de configuración poblado.

## Disparadores de recualificación

Vuelva a ejecutar la evidencia en vivo después de cambiar cualquiera de lo
siguiente:

* la versión de CaseBender o el SDK de almacenamiento;
* el proveedor, ODF, Ceph, la cuenta o la versión de API;
* la seguridad, el versionado, la retención o la inmutabilidad del
  bucket/contenedor;
* la identidad, el rol, la credencial, el endpoint, la CA privada o la política
  de egreso;
* el límite de escáner/promoción; o
* las herramientas de copia de seguridad, migración y restauración.

Guía relacionada:

* [Política de soporte del almacenamiento empresarial](/es/deployment/storage-support-policy)
* [Certificación compatible con S3](/es/deployment/storage-s3-compatible)
* [Seguridad de la versión de almacenamiento](/es/deployment/storage-release-security)