Skip to main content
O suporte de armazenamento é qualificado por release do CaseBender, adaptador do provedor e perfil de implantação. Um nome de provedor isoladamente não é evidência suficiente.

​
Gate da release

Antes de publicar uma release on-premises ou OpenShift:
  1. Fixe cada imagem por digest no manifesto da release.
  2. Gere um SBOM CycloneDX ou SPDX para cada imagem e o pacote de código-fonte.
  3. Assine as imagens e ateste os SBOMs com a identidade da release.
  4. Analise os digests exatos publicados/espelhados, incluindo pacotes de SO e de linguagem.
  5. Revise SDKs de armazenamento, bibliotecas TLS, bundles de CA e dependências transitivas.
  6. Execute testes de contrato do provedor, integridade, migração, backup/restauração e rollback para cada provedor listado como suportado por essa release.
  7. Registre exceções com proprietário, explorabilidade, controle compensatório, validade e aprovação. Não suprima uma família inteira de pacotes.
Os workflows de release do repositório já produzem evidência de SBOM e assinatura, e deploy/verify-images.sh verifica assinaturas de imagem, atestações CycloneDX e política de vulnerabilidades. Use esses controles contra cada digest após o espelhamento e também antes da exportação.

​
Verificação do consumidor

Obtenha o manifesto da release, checksums, política de identidade/emissor Sigstore, SBOMs e atestações por um canal confiável separado. Em seguida:
Use a identidade e o emissor exatos das notas de release assinadas, não estes placeholders. A falha de verificação é um bloqueador da release. Preserve a evidência do transparency log quando conectado; para verificação desconectada, transfira o pacote assinado e o material público de confiança pelo processo aprovado.

​
Revisão de SBOM específica de armazenamento

Confirme que o SBOM contém os adaptadores selecionados em runtime e revise:
  • componentes históricos do MinIO somente em artefatos de origem/recuperação legados; o runtime de produção não deve conter o pacote nativo minio;
  • @aws-sdk/client-s3 para S3; uma dependência de presigner não deve implicar comportamento habilitado de URL assinada;
  • @google-cloud/storage e bibliotecas de autenticação para GCS;
  • @azure/storage-blob e @azure/identity para Azure;
  • Node.js/OpenSSL e o bundle de CA da imagem;
  • imagens de CLI/ferramentas usadas para backup, migração e validação.
Um adaptador instalado, mas não selecionado, ainda contribui com risco de pacote alcançável e deve permanecer na revisão de SBOM e de vulnerabilidades. Por outro lado, a presença no SBOM não prova que um produto/versão está certificado. O Azure está implementado sob o ID canônico de runtime azure, mas a matriz atual não declara azure-blob como suportado na release.

​
Registro de evidência da release

Retenha:
  • revisão de origem, digests imutáveis de imagem, hashes de SBOM, assinaturas e saída de verificação;
  • bancos de dados/versões de ferramentas do scanner e exceções aprovadas de vulnerabilidade;
  • versões de provedor/produto, protocolo/cipher/emissor TLS do endpoint e hash da CA;
  • resultados sanitizados de contrato do provedor e de integridade SHA-256;
  • logs de cópia/verificação de migração e resultado de rollback;
  • ponto de consistência de backup, teste de restauração, RPO/RTO medidos;
  • versão do OpenShift, revisão de SCC, manifests renderizados, versões de CNI/CSI e testes de escrita com UID arbitrário em /tmp//data.
Nunca inclua chaves de acesso, valores de segredo, URLs pré-assinadas, chaves privadas, URLs de banco de dados, nomes de objetos do cliente ou conteúdos de objetos na evidência da release ou em pacotes de suporte.

​
Resposta de segurança

Quando uma vulnerabilidade de SDK de armazenamento ou de provedor for divulgada, determine se o código e a configuração afetados estão presentes e alcançáveis, publique um aviso com escopo, atualize as imagens/SBOMs afetados e reexecute os testes de contrato e restauração. A desativação de um provedor é uma decisão de ciclo de vida do produto com aviso explícito, orientação de migração e datas de suporte. A orientação atual do CaseBender trata uma implantação MinIO legada somente como origem externa de migração/rollback; esta política não inventa uma data de fim de suporte ao cliente além de um plano de mudança aprovado do cliente.