Skip to content

Segurança e conformidade

Esta página descreve os controles de segurança que a plataforma aplica hoje. Cada item corresponde a um comportamento implementado, não a um plano.

A plataforma roda na sua conta de nuvem

  • Toda a infraestrutura é criada na conta AWS ou na assinatura Azure da instituição, com as credenciais da própria instituição. O estado da infraestrutura (Pulumi) também fica em armazenamento da instituição.
  • As regiões padrão são brasileiras: sa-east-1 (São Paulo) na AWS e brazilsouth na Azure.
  • A Finnest fornece apenas uma credencial somente leitura para baixar as imagens da plataforma. A Finnest não recebe acesso à conta de nuvem da instituição.
  • A licença é validada offline, por assinatura Ed25519, sem chamadas de rede.
  • As funções da CLI que falam com a Finnest (relatório de falhas, envio de pacote de suporte, atualização automática, atualização de catálogo) vêm desligadas e só funcionam se o operador as ativar. O relatório de falhas não inclui dados pessoais e envia o ambiente já redigido.

Perfil de segurança FAPI-BR

O servidor de autorização (Keycloak 26) aplica o perfil FAPI-BR v2:

  • assinatura PS256 — outros algoritmos não são anunciados nem aceitos;
  • autenticação do cliente por private_key_jwt ou tls_client_auth;
  • PAR obrigatório em todo cliente registrado por DCR, e PKCE S256;
  • tokens de acesso vinculados ao certificado mTLS do cliente;
  • ID token criptografado (RSA-OAEP com A256GCM);
  • apenas clientes confidenciais, com consentimento obrigatório;
  • no Open Insurance, clientes de aplicativo podem usar DPoP no lugar do vínculo por certificado; clientes regulatórios continuam com mTLS.

mTLS e ICP-Brasil

  • O tráfego regulado passa por um gateway dedicado (Kong) que exige certificado de cliente e valida a cadeia contra os certificados ICP-Brasil fornecidos pela instituição.
  • Os certificados e chaves ICP-Brasil (BRCAC para transporte, BRSEAL para assinatura) ficam no cofre de segredos da nuvem da instituição e chegam ao cluster pelo External Secrets Operator. Veja Rotação de certificados.

Isolamento e proteção de dados

  • Cada serviço tem seu próprio schema no PostgreSQL. Todo registro de negócio carrega o identificador do tenant, e as consultas filtram por ele na camada de aplicação.
  • Tokens OAuth de receptora, verificadores PKCE e tokens de registro DCR são criptografados na aplicação com AES-256-GCM antes de ir para o banco.
  • Os logs passam por redação automática: CPF, CNPJ, chave Pix, senhas, tokens, chaves de API e cabeçalhos de autorização são substituídos por [REDACTED], inclusive em textos livres. Uma regra de lint impede código novo de registrar esses campos.
  • As evidências gravadas pela CLI também passam por redação antes de ir para o disco.

Auditoria e eventos

  • Eventos de negócio usam outbox transacional: o evento é gravado na mesma transação da operação e entregue depois ao NATS JetStream, no formato CloudEvents 1.0.
  • Há trilhas de auditoria em tabelas próprias, incluindo um registro encadeado por hash SHA-256.

Infraestrutura

  • O banco é gerenciado pelo provedor (Amazon Aurora PostgreSQL ou Azure Database for PostgreSQL), criptografado em repouso e sem acesso público. Os backups automáticos ficam retidos por 35 dias em produção e 7 dias nos demais ambientes.
  • A rede do cluster nega tráfego por padrão (Cilium). Políticas Kyverno exigem limites de recursos e política de rede e bloqueiam exposição direta por Ingress ou LoadBalancer.
  • Políticas de infraestrutura como código (Pulumi CrossGuard) rodam em todo deploy e bloqueiam, por exemplo, grupos de segurança abertos, IAM com curinga e bancos sem proteção.

Cadeia de suprimentos

  • As imagens da plataforma, os binários da CLI e o chart Helm são assinados com cosign (keyless, identidade do GitHub Actions) e acompanhados de atestado de proveniência SLSA e SBOM CycloneDX.
  • Toda imagem publicada passa por varredura de vulnerabilidades (Trivy), que bloqueia achados altos e críticos. O repositório também passa por varreduras de segredos (gitleaks) e de dependências (OSV-Scanner), e há uma nova varredura semanal das imagens já publicadas.
  • O instalador da CLI confere o SHA-256 e a assinatura cosign de cada download antes de instalar.

Em evolução

Para evitar mal-entendidos em avaliações de segurança:

  • as chaves ICP-Brasil ficam no cofre de segredos da nuvem, não em HSM;
  • a plataforma não declara certificações como ISO 27001 ou SOC 2.

Dúvidas sobre segurança: oi@finnest.com.br.

Finnest Power — plataforma Open Finance Brasil e Open Insurance Brasil. Contato: oi@finnest.com.br