Skip to main content
Applica questa baseline a ogni profilo di storage di produzione e validala nell’ambiente del cliente.

​
Storage esterno e identità

  • Usa solo bucket o container esterni pre-creati di proprietà del cliente.
  • Nega l’accesso pubblico e l’amministrazione a livello di account.
  • Usa identità del workload/catene di credenziali predefinite con i permessi di bucket/container e prefisso più ristretti richiesti da web e worker.
  • Mantieni separate le responsabilità di amministrazione, attestazione preflight, operazioni oggetto runtime, migrazione e retention dove la piattaforma lo consente.
  • Conserva i secret nel secret manager della piattaforma. Non inserirli mai nel codice sorgente, nei ConfigMap, nelle immagini, negli argomenti/cronologia della shell, nei log, nella telemetria, nei bundle di supporto o nelle evidenze di certificazione.
  • Mantieni abilitata la verifica TLS. Monta i file CA privati in sola lettura e ruotali con una procedura di sovrapposizione.
Gli adapter runtime eseguono solo operazioni data-plane. Non devono creare, eliminare né configurare località di storage.

​
Tre profili di scopo

  • quarantine: tutti gli upload controllati dall’utente entrano qui.
  • records: solo gli upload utente approvati dallo scanner e gli export generati dal server, strettamente definiti e fidati, diventano disponibili qui.
  • ephemeral: deep canary e dati a vita breve con un ciclo di vita delimitato.
Usa bucket/container diversi quando è richiesta la separazione delle policy. Non concedere agli utenti finali l’accesso diretto all’object store.

​
La scansione malware fallisce in chiusura

La produzione richiede clamd esterno tramite CLAMD_SOCKET_PATH o CLAMD_HOST. Il TLS dello scanner remoto usa CLAMD_TLS=true e CLAMD_CA_FILE; un’eccezione plaintext su rete privata è un’eccezione di rischio esplicita, non il default. CaseBender calcola SHA-256, scrive un intent di upload, rilegge l’oggetto esatto e accoda la verifica. Se lo scanner non è disponibile, va in timeout, restituisce output malformato o non può scansionare la dimensione configurata, l’oggetto resta in quarantine. I retry sono persistenti; l’esaurimento diventa un dead letter. Solo un verdetto CLEAN terminale consente la copia in records. Un risultato INFECTED resta in quarantine e crea un evento di audit di sicurezza sensibile. Non scaricare mai un campione malware live per il troubleshooting.

​
Campioni malware intenzionali

I test autorizzati possono memorizzare un campione con content trust MALWARE_SAMPLE e quarantineOnly. Resta in quarantine, non viene mai promosso e ha stato di scan SKIPPED. Usa fixture inerti equivalenti a EICAR dove possibile. Richiedi autorizzazione scritta, gestione isolata, retention/distruzione approvate e nessun allegato a ticket di supporto. Non indebolire la policy di scansione per far passare un test.

​
Integrità e versioni esatte

  • Persisti SHA-256 applicativo, dimensione, checksum del provider e versione/generazione del provider quando disponibili.
  • Verifica i byte scaricati dopo upload, promotion, migrazione, backup e ripristino.
  • Tratta gli ETag come opachi; gli ETag multipart/crittografati potrebbero non essere MD5.
  • Usa create condizionale per impedire race di sovrascrittura.
  • Indirizza retention, legal hold, ripristino e migrazione per versione esatta dell’oggetto—non un oggetto latest fluttuante.
  • Genera alert su storage.checksum_mismatch, oggetti attesi mancanti e orphan confermati.

​
Crittografia, WORM e legal hold

Richiedi TLS e crittografia server-side gestita dal provider. Usa chiavi gestite dal cliente quando è obbligatorio e verifica separatamente la rotazione/recovery delle chiavi. Per i records regolamentati, imposta requireWorm: true e STORAGE_REQUIRE_WORM=true, quindi qualifica versioning del provider, object retention/immutabilità e legal hold. La readiness fallisce con categoria capability quando questi controlli sono assenti. CaseBender non aggira la retention di governance per default e la retention di compliance blocca intenzionalmente l’eliminazione anticipata. La capability WORM in un SDK non è prova che il bucket/container sia stato creato con le impostazioni di immutabilità richieste.

​
Nessun URL firmato

Gli adapter di storage CaseBender non generano URL S3 pre-firmati, URL firmati GCS o URL SAS Azure. I download devono passare attraverso autenticazione CaseBender, autorizzazione, controlli tenant, controlli di ciclo di vita, approvazione dello scanner e confini di audit.

​
Health

  • /api/health/live è solo di processo e non ha dipendenze esterne.
  • /api/health/ready verifica i provider configurati e richiede un deep canary fresco di write/read/copy/delete su ephemeral.
  • La risposta espone solo categorie sanitizzate: configuration, authentication, tls, storage, capability o canary_stale.
Non includere mai credenziali di endpoint, chiavi oggetto, nomi di bucket, nomi di clienti o messaggi di eccezione del provider in una risposta health pubblica.

​
Telemetria e privacy

Monitora metriche aggregate di provider, operazione, risultato, latenza, byte, scanner, quarantine, outbox, migrazione, riconciliazione e readiness. Applica controlli least-access e retention ai dati di osservabilità. I log e le label delle metriche possono includere un provider canonico e un’operazione. Non devono includere credenziali, token, URL firmati, connection string, chiavi private, contenuti dei file, nomi di oggetti del cliente o chiavi oggetto sensibili. Sanitizza gli errori prima della persistenza e dell’export di supporto. Vedi Stato di salute e risoluzione dei problemi dello storage e Backup e ripristino.