> ## 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. # Baseline di sicurezza dello storage > Controlli obbligatori per upload, integrità degli oggetti, accesso, retention e telemetria 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](/it/deployment/storage-health-troubleshooting) e [Backup e ripristino](/it/deployment/storage-backup-restore).