Skip to main content
El soporte de almacenamiento se cualifica por versión de CaseBender, adaptador de proveedor y perfil de implementación. Un nombre de proveedor por sí solo no es evidencia suficiente.

​
Puerta de la versión

Antes de publicar una versión on-premises u OpenShift:
  1. Fije cada imagen por digest en el manifiesto de la versión.
  2. Genere un SBOM CycloneDX o SPDX para cada imagen y el paquete de código fuente.
  3. Firme las imágenes y ateste los SBOM con la identidad de la versión.
  4. Escanee los digests exactos publicados/reflejados, incluidos los paquetes de SO y de lenguaje.
  5. Revise los SDK de almacenamiento, las bibliotecas TLS, los paquetes de CA y las dependencias transitivas.
  6. Ejecute pruebas de contrato del proveedor, integridad, migración, copia de seguridad/restauración y reversión para cada proveedor listado como soportado por esa versión.
  7. Registre las excepciones con propietario, explotabilidad, control compensatorio, caducidad y aprobación. No suprima una familia entera de paquetes.
Los flujos de trabajo de versión del repositorio ya producen evidencia de SBOM y firmas, y deploy/verify-images.sh verifica las firmas de imagen, las atestaciones CycloneDX y la política de vulnerabilidades. Use esos controles contra cada digest después de reflejarlo, además de antes de la exportación.

​
Verificación del consumidor

Obtenga el manifiesto de la versión, los checksums, la política de identidad/emisor de Sigstore, los SBOM y las atestaciones a través de un canal de confianza separado. A continuación:
Use la identidad y el emisor exactos de las notas de versión firmadas, no estos marcadores. Un fallo de verificación es un bloqueador de la versión. Conserve la evidencia del registro de transparencia cuando esté conectado; para la verificación desconectada, transfiera el paquete firmado y el material de confianza pública mediante el proceso aprobado.

​
Revisión de SBOM específica del almacenamiento

Confirme que el SBOM contiene los adaptadores seleccionados en tiempo de ejecución y revise:
  • componentes históricos de MinIO solo en artefactos de origen/ recuperación heredados; el tiempo de ejecución de producción no debe contener el paquete nativo minio;
  • @aws-sdk/client-s3 para S3; una dependencia de presigner no debe implicar el comportamiento de URL firmadas habilitado;
  • @google-cloud/storage y las bibliotecas de autenticación para GCS;
  • @azure/storage-blob y @azure/identity para Azure;
  • Node.js/OpenSSL y el paquete de CA de la imagen;
  • imágenes de CLI/herramientas usadas para copia de seguridad, migración y validación.
Un adaptador instalado pero no seleccionado sigue aportando riesgo de paquete alcanzable y debe permanecer en la revisión de SBOM y vulnerabilidades. A la inversa, la presencia en el SBOM no demuestra que un producto/versión esté certificado. Azure está implementado bajo el identificador canónico de tiempo de ejecución azure, pero la matriz actual no declara azure-blob como soportado en la versión.

​
Registro de evidencia de la versión

Conserve:
  • la revisión del código fuente, los digests inmutables de imagen, los hashes de SBOM, las firmas y la salida de verificación;
  • las bases de datos/versiones de herramientas del escáner y las excepciones de vulnerabilidad aprobadas;
  • las versiones de proveedor/producto, el protocolo/cifrado/emisor TLS del endpoint y el hash de CA;
  • los resultados saneados del contrato del proveedor y de integridad SHA-256;
  • los registros de copia/comprobación de migración y el resultado de la reversión;
  • el punto de consistencia de la copia de seguridad, la prueba de restauración, el RPO/RTO medido;
  • la versión de OpenShift, la revisión de SCC, los manifiestos renderizados, las versiones de CNI/CSI y las pruebas de escritura de UID arbitrario en /tmp//data.
Nunca incluya claves de acceso, valores secretos, URL prefirmadas, claves privadas, URL de base de datos, nombres de objeto del cliente ni contenidos de objeto en la evidencia de la versión o en los paquetes de soporte.

​
Respuesta de seguridad

Cuando se divulgue una vulnerabilidad del SDK de almacenamiento o del proveedor, determine si el código y la configuración afectados están presentes y son alcanzables, publique un aviso acotado, actualice las imágenes/SBOM afectados y vuelva a ejecutar las pruebas de contrato y restauración. La retirada de un proveedor es una decisión de ciclo de vida del producto con aviso explícito, guía de migración y fechas de soporte. La guía actual de CaseBender trata una implementación MinIO heredada solo como origen externo de migración/reversión; esta política no inventa una fecha de fin de soporte del cliente más allá de un plan de cambio aprobado del cliente.