Trust Center: Segurança & Privacidade

Visão Geral de Segurança

A Fhinck adota uma abordagem de Defense in Depth, implementando múltiplas camadas de controles de segurança em toda a nossa infraestrutura, aplicações e processos operacionais.

Zero Trust

Privacy by Design

Minimização de Dados

Defesa em Camadas

Transparência

Infraestrutura de Nuvem

Hospedagem segura e certificada

Google Cloud Platform (GCP)

Região: Google Cloud, processamento principal nos EUA

Certificações do GCP:

ISO 27001 / 27017 / 27018: Gestão de segurança da informação, segurança em nuvem e proteção de dados pessoais
SOC 2 Type II: Controles de segurança, disponibilidade e confidencialidade auditados por terceiros
PCI DSS Nível 1: Padrão internacional para proteção de dados de pagamento
FedRAMP / C5 / HIPAA: Certificações governamentais EUA, Alemanha (BSI) e setor de saúde
GDPR/LGPD Compliant: Cláusulas de proteção de dados pessoais

SLA e Disponibilidade:

SLA GCP: 99,95%

Compromisso Fhinck: 99,5%

O compromisso de 99,5% é deliberadamente conservador: fica abaixo do SLA de 99,95% da infraestrutura GCP porque reserva margem para a camada de aplicação — deploys e janelas de manutenção — em vez de repassar o teto da nuvem como se fosse o de toda a plataforma.

Arquitetura Serverless:

Cloud Functions & Cloud Run
Escalabilidade automática
Patches automáticos de segurança

Bancos de Dados Seguros

BigQuery (Data Warehouse):

• Criptografia AES-256 em repouso
• Controles granulares de acesso
• Auditoria completa de queries

Firestore (NoSQL):

• Criptografia automática
• Regras de segurança personalizadas

Segregação de Ambientes

Desenvolvimento

Dados sintéticos ou anonimizados

Staging

Testes pré-produção isolados

Produção

Ambiente protegido e monitorado

Criptografia

Criptografia em Trânsito

TLS 1.2+ (1.3 preferencial)

Todas as comunicações via HTTPS
Certificados SSL/TLS gerenciados e renovados automaticamente — sem intervenção manual, sem risco de expiração, com verificação contínua
Configuração hardened (sem ciphers fracos)
HSTS (HTTP Strict Transport Security)

Cliente → TLS 1.3 → Load Balancer → TLS interno → Backend

Criptografia em Repouso

AES-256 (Advanced Encryption Standard)

Dados armazenados criptografados no BigQuery
Cópias de recuperação criptografadas em repouso (AES-256, gerenciado pelo GCP)

Gerenciamento de Chaves:

• Segredos no Google Secret Manager — nunca em código
• Criptografia at-rest gerenciada pelo GCP (AES-256, chaves Google)
• Isolamento por cliente: dataset BigQuery dedicado

Hash de Senhas:

Firebase Auth (scrypt) - hashing de senhas gerenciado, resistente a ataques de força bruta

Pseudonimização e Anonimização

Opções disponíveis para clientes:

Pseudonimização

ID substituído por hash único

Anonimização Completa

Remoção de identificadores pessoais

Agregação

Apenas dados agregados

Controles de Acesso e Autenticação

Autenticação Multi-Fator (MFA)

Obrigatória para todos os acessos críticos:

Google Workspace (SSO)

GCP (infraestrutura)

GitHub (código-fonte)

1Password (secrets)

Dashboard Fhinck (recomendado)

Single Sign-On (SSO)

Integração Disponível:

SAML 2.0: Padrão enterprise
OIDC: Protocolo moderno de identidade
Google, Azure AD, Okta, Auth0

Benefícios:

Gestão centralizada de identidades
Credenciais únicas para múltiplos sistemas
Políticas de senha corporativas aplicadas
Revogação instantânea de acesso

Controle de Acesso Baseado em Função (RBAC)

Perfis granulares no Dashboard:

Visualizador

Acesso somente leitura

Analista

Criação de relatórios

Gestor

Acesso ao departamento

Administrador

Gestão completa

Auditor

Acesso a logs

Princípio do Menor Privilégio: Cada usuário recebe apenas as permissões necessárias para suas funções.

Desenvolvimento Seguro de Software

SAST

Análise Estática de Código

• ESLint Security Plugin
• Semgrep (OWASP/CWE)
• Gitleaks (segredos)

DAST

Análise Dinâmica de Aplicações

• OWASP ZAP
• Baseline & Full Scan
• API Security Scan

Vulnerabilidades

Gestão Proativa

• npm audit (diário)
• Trivy (diário: dependências e infraestrutura como código)
• OWASP ZAP (semanal: varredura dinâmica)

Prazos de Correção de Vulnerabilidades

CRÍTICAS

< 48h

ALTAS

< 10 dias

MÉDIAS

< 30 dias

BAIXAS

< 90 dias

Avaliação de Segurança Web

Frequência

Mensal

Última Execução

Setembro/2026

Resultado

✓ Nenhuma vuln. crítica

Privacidade e Proteção de Dados

Conformidade LGPD

Status: Totalmente Conforme

Política de Privacidade publicada

DPIA realizada

DPO designado e identificado

Registro de atividades de tratamento

Cláusulas contratuais (DPA)

Procedimentos de resposta a incidentes

Mecanismos para exercício de direitos

Transparência e consentimento

Funções e Responsabilidades

Controlador: Cliente

Determina finalidades e meios de tratamento

Operador: Fhinck

Processa dados conforme instruções do Controlador

DPO: Michel Zarzour Filho

dpo@fhinck.com
(11) 98367-3803

Minimização de Dados

✓ Coletamos

• ID usuário, hostname
• Metadados de apps
• Tempos de atividade

✗ NÃO Coletamos

• Screenshots
• Keylogging
• Conteúdo de docs

Resposta a Incidentes de Segurança

Processo de Resposta

1

Detecção

0-2 horas

2

Contenção

2-8 horas

3

Notificação

Até 48h

4

Resolução

Pós-incidente

Equipe de Resposta a Emergências (ERT)

Michel Zarzour Filho

CIO/DPO

dpo@fhinck.com

André Murta

Tech Lead

support@fhinck.com

Paulo Castello

CEO

support@fhinck.com

Auditorias e Conformidade

Auditorias Internas

FrequênciaAnual

Última RealizaçãoOutubro/2025

PróximaOutubro/2026

Resultado✓ CONFORME

Conformidade e referências

Conformidade LGPD

Totalmente conforme

Marco Civil da Internet

Conforme

OWASP Top 10

Mitigações implementadas

Por que conformidade contínua

Segurança que evolui junto com a operação — não uma foto anual

Controles contínuos, não uma vez por ano

A análise estática de segurança e a verificação de dependências rodam todos os dias, e a varredura dinâmica, toda semana, o ano inteiro. Evidência sempre atual vale mais do que um atestado emitido em um único dia.

AI-first: a operação muda o tempo todo

Com IA, fluxos e arquitetura evoluem continuamente. Uma certificação amarrada a um escopo congelado envelhece em meses. Nossa governança acompanha a mudança em vez de travá-la.

Investimento direto em proteção real

Em vez de direcionar orçamento ao ciclo de auditoria/certificação, a Fhinck investe em controles, observabilidade de segurança em tempo real e avaliação automatizada mensal de segurança web (Beagle Security) — proteção onde ela gera resultado.

Implementado

Matriz de Controles de Segurança

Visão estruturada dos 10 domínios de controle e de como cada um opera hoje

Além do SOC 2 e da ISO 27001

Segurança para uma operação AI-first

Os frameworks acima, SOC 2 e ISO/IEC 27001, descrevem controles desenhados para uma operação humana, e a Fhinck está alinhada a elas. Mas a Fhinck opera por agentes de IA. Para uma plataforma AI-first, os parâmetros que de fato importam são os definidos pelos padrões específicos de IA: o NIST AI Risk Management Framework, a ISO/IEC 42001 (gestão de IA) e o OWASP Top 10 para LLM e para Aplicações Agênticas. Abaixo, os riscos que esses frameworks classificam como críticos para sistemas de IA — e como a Fhinck endereça cada um, com evidência no próprio repositório.

O recorte AI-first

Uma auditoria tradicional pergunta "há um humano aprovando isto?". Numa operação agêntica, a pergunta certa é "o que impede o agente de agir sozinho — e isso é testável?".

Defesa contra prompt injection e jailbreak

Defesa ativa

Padrão de referência: OWASP LLM01:2025 · Agentic ASI01

Toda entrada que chega a um modelo pode tentar sequestrar suas instruções. Tratamos input de usuário como não-confiável.

Como a Fhinck cumpre

Copiloto do dashboard: detecção determinística de injeção e jailbreak em português e inglês (override de instrução, role-hijack, tentativa de extrair o system prompt, token smuggling), teto de 4.000 caracteres, remoção de HTML/script e rate-limit adversarial dedicado por sessão. O pipeline de backend aplica defesa própria (sandwich defense).

Padrões de injeção bloqueados na entrada (PT+EN)

Guardrails de saída e anti-vazamento

Defesa ativa

Padrão de referência: OWASP LLM02 · LLM05 · LLM07

Nenhuma resposta de IA sai sem filtro contra vazamento de dado pessoal, de outro cliente ou do próprio sistema.

Como a Fhinck cumpre

O filtro de saída redige CPF, CNPJ, e-mail externo, cartão, telefone e tokens; um canary token descarta a resposta inteira se houver sinal de extração do system prompt. No agente de suporte, 15 padrões determinísticos de vazamento (datasets de cliente, IDs internos, nomes de tabela e de workflow) interrompem a execução.

Saída com dado sensível redigido automaticamente

Harness e contrato de comportamento do agente

Bloqueio por hook

Padrão de referência: OWASP LLM06 · Agentic ASI02/ASI03

O risco nº 1 de sistemas agênticos é a "agência excessiva". Cada agente roda sob um contrato mecânico, não sob confiança no modelo.

Como a Fhinck cumpre

Subagentes só executam quando: as skills declaradas foram efetivamente invocadas, as afirmações quantitativas vêm com evidência estrutural (arquivo:linha ou output) e existe um artefato persistente — regras C1–C4 verificadas por um hook que bloqueia a chamada. O limite de briefing também é enforçado por um hook que bloqueia a chamada.

Aprovação humana para ações críticas

Bloqueio por hook

Padrão de referência: OWASP Agentic ASI09 · NIST AI RMF

Ação destrutiva ou em produção nunca acontece só porque o agente decidiu.

Como a Fhinck cumpre

Comandos críticos (deploy em produção, DROP/TRUNCATE, force-push, delete em nuvem) exigem código de uso único (TOTP) + assinatura criptográfica verificada offline, ou um artefato de Triple Gate do dia. Freeze windows bloqueiam deploy em horário de cliente e todo bypass gera trilha de auditoria.

Comando destrutivo bloqueado até aprovação humana

Red-team adversarial e LLM-as-judge contínuos

Contínuo

Padrão de referência: NIST AI RMF (MEASURE) · MITRE ATLAS

Os agentes são atacados de propósito e julgados por qualidade antes de qualquer promoção.

Como a Fhinck cumpre

Framework interno de auditoria de agente com 33 casos adversariais (prompt injection, bypass de confirmação, abuso de permissão). Mudanças no pipeline de suporte só sobem após um gate de LLM-as-judge em 4 dimensões (ação, qualidade, compliance, efetividade) com nota mínima 4,5/5, sobre suíte sintética e tickets reais sanitizados.

Gate LLM-as-judge — mínimo 4,5/5 por dimensão

Observabilidade de cada run de agente

Em produção

Padrão de referência: OWASP Agentic ASI10 · NIST AI RMF

Decisão de agente não pode ser caixa-preta: tem que ser auditável depois.

Como a Fhinck cumpre

Canal único de telemetria em formato OTel GenAI no BigQuery (decisões de hook, runs de agente, deploys, achados de auditoria), com redação automática de PII e retenção de 365 dias; log append-only de invocação de skills usado para enforcement.

Telemetria de runs em formato OTel GenAI

Isolamento entre clientes e raio de impacto contido

Isolamento estrutural

Padrão de referência: OWASP LLM02:2025 · NIST AI RMF (MANAGE)

Numa operação agêntica, um agente comprometido ou uma credencial vazada não pode alcançar o dado de outro cliente. O raio de impacto de qualquer falha fica contido a um único cliente.

Como a Fhinck cumpre

Cada cliente vive em um dataset BigQuery dedicado e toda consulta é escopada e sanitizada por empresa antes de tocar o dado — o identificador da empresa é validado e fixado no caminho da tabela, sem query cross-cliente. As credenciais de serviço seguem o menor privilégio, e a separação de chaves por cliente está disponível sob contrato.

Consulta escopada e sanitizada por cliente — sem acesso cross-cliente

Padrões de referência

Equivalência de controles AI-First

O mesmo objetivo de cada controle, cumprido de forma nativa de IA

Por que não buscamos o selo

SOC 2 e ISO 27001 foram escritas para uma empresa onde cada controle é executado e aprovado por uma pessoa. A Fhinck opera por IA: o selo certificaria procedimentos humanos que não descrevem como realmente operamos. Cumprimos o objetivo de cada controle — só não executamos a atividade na forma humana que a norma presume.

Objetivo × atividade

Toda norma tem duas camadas: o objetivo do controle (o que ele protege) e a atividade prescrita (o procedimento humano). A Fhinck entrega cada objetivo por mecanismos de máquina — auditáveis e contínuos.

A norma presume — operação humana