Aparência
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 ebrazilsouthna 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_jwtoutls_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.