> ## 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. # Linha de base de segurança do armazenamento > Controles obrigatórios para uploads, integridade de objetos, acesso, retenção e telemetria Aplique esta linha de base a cada perfil de armazenamento de produção e valide-a no ambiente do cliente. ## Armazenamento externo e identidade * Use somente buckets ou contêineres externos pré-criados, de propriedade do cliente. * Negue acesso público e administração em toda a conta. * Use cadeias de identidade de carga de trabalho/credenciais padrão com as permissões mais restritas de bucket/contêiner e prefixo exigidas por web e worker. * Mantenha administração, atestação de preflight, operações de objeto em runtime, migração e responsabilidades de retenção separadas quando a plataforma permitir. * Armazene segredos no gerenciador de segredos da plataforma. Nunca os coloque em código-fonte, ConfigMaps, imagens, argumentos/histórico do shell, logs, telemetria, pacotes de suporte ou evidência de certificação. * Mantenha a verificação TLS habilitada. Monte arquivos de CA privada somente leitura e rotacione-os com um procedimento de sobreposição. Os adaptadores de runtime executam somente operações de data-plane. Eles não devem criar, excluir nem configurar locais de armazenamento. ## Três perfis de propósito * `quarantine`: todos os uploads controlados pelo usuário entram aqui. * `records`: somente uploads de usuário aprovados pelo scanner e exportações geradas pelo servidor, definidas de forma restrita, tornam-se disponíveis aqui. * `ephemeral`: canários profundos e dados de curta duração com ciclo de vida limitado. Use buckets/contêineres diferentes quando a separação de políticas for exigida. Não conceda aos usuários finais acesso direto ao object store. ## A varredura de malware falha em modo fechado A produção exige `clamd` externo por `CLAMD_SOCKET_PATH` ou `CLAMD_HOST`. O TLS do scanner remoto usa `CLAMD_TLS=true` e `CLAMD_CA_FILE`; uma exceção de rede privada em texto simples é uma exceção explícita de risco, não o padrão. O CaseBender calcula o SHA-256, grava uma intenção de upload, relê o objeto exato e enfileira a verificação. Se o scanner estiver indisponível, expirar, retornar saída malformada ou não puder analisar o tamanho configurado, o objeto permanece em quarentena. As retentativas são duráveis; o esgotamento torna-se um dead letter. Somente um veredito terminal `CLEAN` permite a cópia para `records`. Um resultado `INFECTED` permanece em quarentena e cria um evento de auditoria de segurança sensível. Nunca baixe uma amostra de malware viva para solução de problemas. ## Amostras intencionais de malware Testes autorizados podem armazenar uma amostra com confiança de conteúdo `MALWARE_SAMPLE` e `quarantineOnly`. Ela permanece em quarentena, nunca é promovida e tem estado de varredura `SKIPPED`. Use fixtures inertes equivalentes a EICAR sempre que possível. Exija autorização por escrito, tratamento isolado, retenção/destruição aprovadas e nenhum anexo em ticket de suporte. Não enfraqueça a política de varredura para fazer um teste passar. ## Integridade e versões exatas * Persista o SHA-256 da aplicação, o tamanho, o checksum do provedor e a versão/geração do provedor quando disponíveis. * Verifique os bytes baixados após upload, promoção, migração, backup e restauração. * Trate ETags como opacos; ETags multipart/criptografados podem não ser MD5. * Use create condicional para impedir corridas de sobrescrita. * Enderece retenção, legal hold, restauração e migração pela versão exata do objeto — não por um objeto latest flutuante. * Alerte em `storage.checksum_mismatch`, objetos esperados ausentes e órfãos confirmados. ## Criptografia, WORM e legal hold Exija TLS e criptografia no servidor gerenciada pelo provedor. Use chaves gerenciadas pelo cliente quando mandatório e verifique a rotação/recuperação de chaves separadamente. Para `records` regulamentados, defina `requireWorm: true` e `STORAGE_REQUIRE_WORM=true` e, em seguida, qualifique versionamento do provedor, retenção/ imutabilidade de objeto e legal hold. A prontidão falha com a categoria `capability` quando esses controles estão ausentes. O CaseBender não contorna a retenção de governança por padrão, e a retenção de conformidade bloqueia intencionalmente a exclusão antecipada. Capacidade WORM em um SDK não é prova de que o bucket/contêiner foi criado com as configurações imutáveis exigidas. ## Sem URLs assinadas Os adaptadores de armazenamento do CaseBender não geram URLs S3 pré-assinadas, URLs assinadas do GCS nem URLs SAS do Azure. Os downloads devem passar pela autenticação, autorização, verificações de tenant, verificações de ciclo de vida, aprovação do scanner e limites de auditoria do CaseBender. ## Saúde * `/api/health/live` é somente de processo e não tem dependência externa. * `/api/health/ready` verifica os provedores configurados e exige um canário profundo recente de write/read/copy/delete em `ephemeral`. * A resposta expõe somente categorias sanitizadas: `configuration`, `authentication`, `tls`, `storage`, `capability` ou `canary_stale`. Nunca inclua credenciais de endpoint, chaves de objeto, nomes de bucket, nomes de clientes ou mensagens de exceção do provedor em uma resposta pública de health. ## Telemetria e privacidade Monitore métricas agregadas de provedor, operação, resultado, latência, bytes, scanner, quarentena, outbox, migração, reconciliação e prontidão. Aplique controles de menor acesso e retenção aos dados de observabilidade. Logs e rótulos de métricas podem incluir um provedor canônico e uma operação. Eles não devem incluir credenciais, tokens, URLs assinadas, connection strings, chaves privadas, conteúdos de arquivos, nomes de objetos do cliente ou chaves de objeto sensíveis. Sanitize erros antes da persistência e da exportação de suporte. Consulte [Saúde e solução de problemas do armazenamento](/pt-BR/deployment/storage-health-troubleshooting) e [Backup e restauração](/pt-BR/deployment/storage-backup-restore).