Segurança da Informação na Recruta

Princípios de segurança que orientam a engenharia

• Defesa em profundidade. Nenhuma camada confia sozinha. Cada controle assume que a camada anterior pode falhar.
• Princípio do privilégio mínimo. Cada usuário, sistema ou integração só acessa o que é estritamente necessário.
• Segurança por design. Controles aplicados na construção, não como remediação posterior.
• Auditabilidade. Toda ação sensível deixa rastro imutável. Sem exceção.
• Transparência operacional. Documentação técnica acessível para quem precisa avaliar antes de contratar.

Arquitetura em camadas isoladas

Separação física entre as três camadas. Contrato estrito entre elas. O browser do candidato jamais fala diretamente com o banco.

Camada Frontend

• Hospedado em Vercel Edge Network, com PoPs no Brasil para baixa latência.
• HTTPS obrigatório fim-a-fim. Sem fallback para HTTP.
• Content Security Policy estrito, bloqueando scripts não autorizados.
• Subresource Integrity em assets de terceiros (fontes, CDN).
• Sem armazenamento de credencial ou segredo no lado do cliente.
• Cookies de sessão com flags Secure, HttpOnly e SameSite=Strict.

Camada Backend / API

• Hospedado em AWS (região São Paulo, sa-east-1), com uptime SLA de 99,9%.
• Containers em microsserviços, isolados por função (autenticação, ATS, IA, integração).
• Cada microsserviço com escopo mínimo de permissão.
• Validação rígida de toda entrada (whitelist, não blacklist).
• Rate limiting por endpoint e por usuário, para mitigação de abuso.
• Sem acesso direto ao banco a partir do navegador.

Camada de Dados

• PostgreSQL gerenciado via Supabase, hospedado em São Paulo.
• Row Level Security (RLS) aplicado por padrão em todas as tabelas com dado pessoal.
• Service role controlado, com chaves rotacionadas periodicamente.
• Backups automáticos com retenção configurada (point-in-time recovery).
• Criptografia em repouso por padrão da plataforma.
• Acesso administrativo registrado em log imutável.

Autenticação

Criptografia

Permissões e Row Level Security

Controle de acesso começa no papel do usuário, passa pela camada de aplicação e termina no banco. Cada camada filtra de forma independente.

Papéis padrão

• Admin Recruta, acesso restrito a operações de plataforma, sem visibilidade de dado pessoal de candidato.
• Admin Empresa, administração do tenant da empresa-cliente.
• RH-Compliance, visualiza dados sensíveis (laudo PCD) somente para vagas ativas em que tem responsabilidade.
• Recrutador, visualiza dados gerais de candidatos em suas vagas. Não vê laudo.
• Gestor de vaga, visualiza apenas shortlist apresentada formalmente. Não vê base bruta.
• Candidato, visualiza apenas os próprios dados.

Aplicação no banco (RLS)

O Postgres aplica Row Level Security por empresa (tenant) e por papel. Mesmo que uma query escape do app, o banco bloqueia a leitura. Políticas são versionadas junto com o schema, revisadas a cada release.

Mudança de papel

Toda alteração de papel gera evento de auditoria com timestamp, ator, papel anterior e papel novo. O evento é replicado para o log imutável.

Logs imutáveis para ações sensíveis

As seguintes ações são registradas em log imutável (append-only, sem capacidade de edição ou exclusão):

• Exportação de dados
• Alteração de papel de usuário
• Leitura de laudo médico ou dado sensível
• Comunicação enviada ao candidato
• Aprovação ou rejeição em decisão automatizada
• Acesso administrativo ao banco

Retenção mínima: 5 anos. Acesso aos logs: apenas DPO e auditoria, com pedido formal e justificativa registrada.

Gerenciamento de secrets

• Chaves de API, tokens e segredos ficam em gerenciador dedicado de secrets.
• Nenhum segredo é versionado no repositório de código (auditoria automática no pipeline).
• Rotação periódica programada.
• Rotação imediata em caso de exposição suspeita.

APIs e integrações

Cada integração entra por um contrato explícito, com credencial dedicada e escopo mínimo. Nada fica implícito.

Webhook recebido sem assinatura válida é descartado. Log de integração retido por 90 dias e disponível para auditoria.

Monitoramento de eventos críticos

• Alertas em tempo real para login suspeito, escalada de privilégio, exportação em volume incomum.
• Painel operacional com KPIs de segurança consultado diariamente pelo time técnico.
• Auditoria mensal de acesso a dados sensíveis.
• Teste de penetração (pentest) periódico, conduzido por terceiro especializado.

Dependências e pipeline de release

• Dependências auditadas automaticamente no pipeline de build.
• Vulnerabilidades conhecidas bloqueiam o deploy.
• Atualizações de segurança aplicadas em até 7 dias para CVE crítico, 30 dias para alto.
• Sem segredo, chave ou credencial em código versionado (varredura automática).
• Isolamento por ambiente (dev, staging, produção) com credenciais distintas.

Governança da IA

A IA da Recruta opera com três camadas de supervisão, descritas em detalhe no post sobre treinamento da IA:

1. IA jurídica e compliance, supervisão em tempo real, aplicando LGPD, GDPR e legislação trabalhista.
2. IA árbitra, controle de qualidade e validação cruzada das saídas.
3. 15 agentes operacionais, apenas saídas filtradas chegam aos agentes que entregam valor ao usuário.

Decisões críticas (descarte de candidato, aprovação de oferta) têm revisão humana obrigatória por design. O direito do titular de pedir revisão complementar é sempre garantido (art. 20 da LGPD).

Resposta a incidentes

Plano formal documentado, testado periodicamente. Fluxo em caso de incidente:

1. Identificação e contenção, em até 1 hora do alerta.
2. Avaliação de impacto, em até 24 horas.
3. Notificação à ANPD e aos titulares afetados, quando aplicável, em prazo razoável conforme art. 48 da LGPD.
4. Documentação para auditoria, registrada e arquivada por 5 anos no mínimo.
5. Revisão pós-incidente, em até 30 dias, com plano de prevenção atualizado.

Divulgação responsável de vulnerabilidades

Encontrou uma vulnerabilidade no site ou na plataforma da Recruta? Avise antes de divulgar publicamente.

• E-mail: seguranca@arecruta.com.br (com canal alternativo em contato@arecruta.com.br com assunto "Vulnerabilidade").
• O que esperamos: descrição reprodutível, impacto, sugestão de mitigação (opcional).
• O que prometemos: resposta em até 5 dias úteis, crédito público se desejado, correção em prazo proporcional ao risco.