Arquitetura
Toda implantação define três perfis:quarantinerecebe uploads controlados pelo usuário;recordscontém dados duráveis aprovados pelo scanner e exportações geradas; eephemeralcontém canários e objetos de curta duração.
@cbr/storage implementa os adaptadores canônicos s3, gcs,
azure e local. As operações em tempo de execução incluem health, upload, download,
exists, list, metadata, copy, delete, retenção e legal hold. O runtime nunca
cria nem configura buckets/contêineres e nunca gera URLs assinadas.
Os uploads do usuário são gravados atrás de uma intenção de upload durável, relidos e
verificados por SHA-256, analisados pelo clamd externo e copiados para records somente
após um veredito limpo. Os workers de mutação durável, migração e reconciliação
repetem de forma idempotente e expõem telemetria de dead-letter/integridade.
Comece por aqui
Política de suporte
Status atual de suporte e qualificação, legível por máquina
Selecionar um provedor
Compare os requisitos de certificação live e os níveis de evidência
Linha de base de segurança
Quarentena, varredura, integridade, criptografia, WORM e controles de segredos
Backup e restauração
Proteja o PostgreSQL e as versões exatas dos objetos como um único conjunto
Runbook de migração
Transição copy-first, verificação do ledger, retenção da origem e rollback
Saúde e solução de problemas
Categorias de prontidão, canário, scanner, CA, permissões e dead letters
Orientação por provedor
OpenShift ODF/Ceph RGW
OBC externo ou RGW independente com CA privada e egresso restrito
AWS S3
Buckets existentes e identidade de carga de trabalho
Google Cloud Storage
Buckets existentes e Workload Identity
Azure Blob
Contêineres existentes e Managed Identity
Produtos compatíveis com S3
Política de certificação live por produto/versão exatos
Local e MinIO
Armazenamento local somente para desenvolvimento e migração de MinIO legado