> ## 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.

# Segurança da release de armazenamento

> Qualificação da release, revisão de SBOM e evidência assinada de armazenamento

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:

```sh theme={null}
cosign verify \
  --certificate-identity-regexp '<approved-release-identity>' \
  --certificate-oidc-issuer '<approved-issuer>' \
  registry.example.com/casebender/webapp@sha256:<digest>

cosign verify-attestation \
  --type cyclonedx \
  --certificate-identity-regexp '<approved-release-identity>' \
  --certificate-oidc-issuer '<approved-issuer>' \
  registry.example.com/casebender/webapp@sha256:<digest>

trivy image --severity HIGH,CRITICAL \
  registry.example.com/casebender/webapp@sha256:<digest>
```

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.