Skip to main content
Aplique esta línea base a cada perfil de almacenamiento de producción y valídela en el entorno del cliente.

​
Almacenamiento externo e identidad

  • Use solo buckets o contenedores externos precreados propiedad del cliente.
  • Deniegue el acceso público y la administración de toda la cuenta.
  • Use cadenas de identidad de carga de trabajo/credenciales predeterminadas con los permisos más estrechos de bucket/contenedor y prefijo que requieran web y worker.
  • Separe las responsabilidades de administración, atestación de preflight, operaciones de objeto en tiempo de ejecución, migración y retención cuando la plataforma lo permita.
  • Almacene los secretos en el gestor de secretos de la plataforma. Nunca los ponga en el código fuente, ConfigMaps, imágenes, argumentos/historial de shell, registros, telemetría, paquetes de soporte ni evidencia de certificación.
  • Mantenga la verificación TLS habilitada. Monte los archivos de CA privada en solo lectura y rótelos con un procedimiento de solapamiento.
Los adaptadores en tiempo de ejecución realizan solo operaciones del plano de datos. No deben crear, eliminar ni configurar ubicaciones de almacenamiento.

​
Tres perfiles de propósito

  • quarantine: todas las cargas controladas por el usuario entran aquí.
  • records: solo las cargas de usuario aprobadas por el escáner y las exportaciones generadas por el servidor, definidas de forma estrecha y de confianza, quedan disponibles aquí.
  • ephemeral: canarios profundos y datos de vida corta con un ciclo de vida acotado.
Use buckets/contenedores distintos cuando se requiera separación de políticas. No conceda a los usuarios finales acceso directo al almacén de objetos.

​
El escaneo de malware falla en cerrado

La producción requiere clamd externo a través de CLAMD_SOCKET_PATH o CLAMD_HOST. El TLS del escáner remoto usa CLAMD_TLS=true y CLAMD_CA_FILE; una excepción de red privada en texto plano es una excepción de riesgo explícita, no el valor predeterminado. CaseBender calcula SHA-256, escribe una intención de carga, lee el objeto exacto de vuelta y pone en cola la verificación. Si el escáner no está disponible, agota el tiempo de espera, devuelve salida malformada o no puede escanear el tamaño configurado, el objeto permanece en cuarentena. Los reintentos son durables; el agotamiento se convierte en una dead letter. Solo un veredicto terminal CLEAN permite la copia a records. Un resultado INFECTED permanece en cuarentena y crea un evento de auditoría de seguridad sensible. Nunca descargue una muestra de malware en vivo para solucionar problemas.

​
Muestras de malware intencionales

Las pruebas autorizadas pueden almacenar una muestra con confianza de contenido MALWARE_SAMPLE y quarantineOnly. Permanece en cuarentena, nunca se promueve y tiene estado de escaneo SKIPPED. Use fixtures inertes equivalentes a EICAR cuando sea posible. Exija autorización por escrito, manejo aislado, retención/destrucción aprobadas y ningún adjunto en tickets de soporte. No debilite la política de escaneo para que una prueba pase.

​
Integridad y versiones exactas

  • Persista el SHA-256 de la aplicación, el tamaño, el checksum del proveedor y la versión/generación del proveedor cuando esté disponible.
  • Verifique los bytes descargados después de la carga, la promoción, la migración, la copia de seguridad y la restauración.
  • Trate los ETag como opacos; los ETag de multipart/cifrados pueden no ser MD5.
  • Use creación condicional para evitar condiciones de carrera de sobrescritura.
  • Dirija la retención, la retención legal, la restauración y la migración por la versión exacta del objeto, no por un objeto latest flotante.
  • Alerte sobre storage.checksum_mismatch, objetos esperados faltantes y huérfanos confirmados.

​
Cifrado, WORM y retención legal

Exija TLS y cifrado del lado del servidor gestionado por el proveedor. Use claves gestionadas por el cliente cuando se imponga y verifique la rotación/ recuperación de claves por separado. Para records regulados, establezca requireWorm: true y STORAGE_REQUIRE_WORM=true, y a continuación cualifique el versionado del proveedor, la retención/inmutabilidad de objetos y la retención legal. La preparación falla con la categoría capability cuando estos controles faltan. CaseBender no omite de forma predeterminada la retención de gobernanza, y la retención de cumplimiento bloquea intencionadamente la eliminación anticipada. La capacidad WORM en un SDK no demuestra que el bucket/contenedor se creó con los ajustes de inmutabilidad requeridos.

​
Sin URL firmadas

Los adaptadores de almacenamiento de CaseBender no generan URL prefirmadas de S3, URL firmadas de GCS ni URL SAS de Azure. Las descargas deben pasar por la autenticación, autorización, comprobaciones de tenant, comprobaciones de ciclo de vida, aprobación del escáner y límites de auditoría de CaseBender.

​
Salud

  • /api/health/live es solo del proceso y no tiene dependencia externa.
  • /api/health/ready comprueba los proveedores configurados y requiere un canario profundo reciente de write/read/copy/delete en ephemeral.
  • La respuesta expone solo categorías saneadas: configuration, authentication, tls, storage, capability o canary_stale.
Nunca incluya credenciales de endpoint, claves de objeto, nombres de bucket, nombres de cliente ni mensajes de excepción del proveedor en una respuesta de salud pública.

​
Telemetría y privacidad

Supervise métricas agregadas de proveedor, operación, resultado, latencia, bytes, escáner, cuarentena, outbox, migración, reconciliación y preparación. Aplique controles de mínimo acceso y retención a los datos de observabilidad. Los registros y las etiquetas de métricas pueden incluir un proveedor canónico y una operación. No deben incluir credenciales, tokens, URL firmadas, cadenas de conexión, claves privadas, contenidos de archivo, nombres de objeto del cliente ni claves de objeto sensibles. Sanee los errores antes de la persistencia y de la exportación de soporte. Consulte Salud y solución de problemas del almacenamiento y Copia de seguridad y restauración.