NOVOJá está disponível a primeira ferramenta de auditoria de visibilidade em IA para Web3 do mundo.Faça uma auditoria grátis →
Política de segurança · Em vigor desde 13 de abril de 2026

Como a Crawlux protege seus dados.

Arquitetura de segurança defense-in-depth cobrindo criptografia, controle de acesso, resposta a incidentes e divulgação de vulnerabilidades. Construída em AWS com hosting primário em região UE para alinhamento com GDPR.

Ver detalhes de segurançaGDPR · Criptografia em repouso · Nenhum dado bruto do site armazenado

Fatos-chave de segurança

5Camadas de defesa
15minMeta de detecção de incidentes
72hSLA de notificação ao usuário
90dJanela de divulgação
MFAObrigatório para acesso de administrador
Seção 01
// Defesa em profundidade

Cinco camadas de segurança

Crawlux aplica defesa em camadas através de infraestrutura, rede, aplicação, dados e controles operacionais. Um atacante precisaria comprometer múltiplas camadas independentes para acessar a data de usuários, com cada camada elevando o custo do ataque.

01Infraestrutura

Hospedado em AWS com região UE primária

A produção roda em AWS eu-west-1 com réplicas de backup em eu-central-1. Segurança de hardware, controle de acesso físico e integridade de cadeia de suprimentos herdados dos controles SOC 2 Type II de AWS.

02Network

Isolamento VPC com proteção WAF e DDoS

As VPCs de produção isoladas da internet pública exceto através de endpoints ALB. O WAF de CloudFlare filtra padrões de ataque conhecidos. AWS Shield Standard mitiga DDoS na borda da rede.

03Aplicação

Autenticação, limitação de taxa e proteção CSRF

Todas as rotas autenticadas exigem tokens de sessão válidos. Rate limits aplicados por IP e por conta. Tokens CSRF para operações que mudam estado. Validação de input em cada fronteira de API.

04Data

Criptografia AES-256 em repouso, TLS 1.3 em trânsito

Base de dados, object storage e backup storage todos criptografados com AES-256 usando chaves gerenciadas por AWS KMS. Tráfego de API protegido com TLS 1.3 mínimo. As API keys e secrets de webhooks usam envelope encryption.

05Operacional

Logs de acesso, trilhas de auditoria e admin com MFA obrigatório

O acesso à base de dados de produção exige MFA. Todo o acesso logado com usuário, ação e timestamp. As auditorias mensais de acesso identificam e removem permissões sem uso. O acesso a data do cliente exige justificativa logada.

Seção 02
// O que é criptografado

Cobertura de criptografia

A criptografia se aplica a cada categoria de data que Crawlux gerencia. A tabela abaixo mapeia cada tipo de data ao mecanismo de criptografia e à abordagem de gerenciamento de chaves.

Data typeEm trânsitoEm repousoKey management
Audit JSON outputTLS 1.3AES-256AWS KMS
PDF reportsTLS 1.3AES-256AWS KMS · S3 SSE-KMS
User account dataTLS 1.3AES-256AWS RDS encryption
Chaves de API (quando lançadas)TLS 1.3AES-256 · envelopeChaves isoladas por cliente
Segredos de assinatura de webhooksTLS 1.3AES-256 · envelopeChaves isoladas por cliente
Payment dataTLS 1.3 to StripeStripe-side onlyStripe PCI infrastructure
Backups de banco de dadosTLS 1.3AES-256Cross-region replicated
Server logsTLS 1.3AES-256CloudWatch encryption

Criptografia de chaves isolada por cliente

As API keys e secrets de assinatura de webhooks usam envelope encryption onde os secrets de cada cliente estão criptografados com uma chave KMS por-cliente. Uma brecha da camada de storage de um cliente não expõe os secrets de outros clientes.

Seção 03
// Access control

Quem tem acesso aos seus dados

O acesso a sistemas de produção e data do cliente está restrito a membros da equipe de engenharia com necessidade de negócio documentada. O princípio de menor privilégio se aplica através de cada sistema. Todo o acesso está logado.

01

MFA obrigatório para acesso admin

O acesso à base de dados de produção, console de infraestrutura e dashboard admin exigem autenticação multi-fator. Chaves de segurança por hardware preferidas. MFA baseado em SMS não permitido.

02

Menor privilégio por padrão

Os novos membros da equipe começam com zero acesso a produção. Privilégios concedidos por necessidade documentada com aprovação do manager. Acesso por tempo limitado para tarefas específicas quando é possível.

03

Todo acesso registrado

Cada query de base de dados, leitura de objeto S3 e ação admin está logada com usuário, timestamp e operação. Logs retidos por 1 ano no mínimo. Os padrões anômalos são marcados para revisão.

04

Auditorias mensais de acesso

A engenharia revisa as permissões de acesso a produção mensalmente. As permissões sem uso são removidas. Os roles fora da responsabilidade atual são revogados. Os relatórios de auditoria são arquivados para revisão de compliance.

05

Acesso a dados do cliente registrado

As solicitações de suporte que exigem acesso a data do cliente exigem justificativa documentada. Cada acesso logado com solicitante, destinatário, justificativa e timestamp. Os clientes podem solicitar seu log de acesso.

06

Offboarding dentro de 24 horas

Quando os membros da equipe saem, todo o acesso a produção é revogado dentro de 24 horas. As credenciais de conta rotacionadas. As sessões ativas invalidadas. As chaves de acesso removidas dos pools de rotação.

Seção 04
// Resposta a incidentes

Respuesta a incidentes de 5 fases

Quando um incidente de segurança é detectado, a resposta segue um processo definido de 5 fases com objetivos claros de tempo em cada fase. A página de status loga todos os incidentes confirmados publicamente com timestamps.

Fase 01

Detecção (objetivo: 15 min)

O monitoramento automatizado alerta sobre padrões anômalos: localizações de login incomuns, picos de autenticações falhadas, egresso inesperado de data, picos de taxa de erros. Engenheiro on-call acionado dentro da janela objetivo.

Fase 02

Contenção (objetivo: 1 hora)

Isolar sistemas afetados para prevenir movimento lateral. Revogar credenciais comprometidas. Bloquear IPs de atacantes a nível WAF. Preservar evidência forense em estado read-only. Não prejudicar a investigação em curso.

Fase 03

Avaliação (objetivo: 4 horas)

Determinar alcance: quais sistemas, qual data, quais usuários. Categorizar severidade. Avaliar obrigações de notificação regulatória. Documentar linha do tempo. Identificar hipóteses de causa raiz para planejamento de remediação.

Fase 04

Remediação (típico: 24 horas)

Corrigir a vulnerabilidade. Rotacionar credenciais expostas. Restaurar sistemas a partir de backups limpos se necessário. Verificar a efetividade da remediação através de testes direcionados. Atualizar regras de detecção para capturar futuros ataques similares.

Fase 05

Comunicação (objetivo: 72 horas)

Notificar os usuários afetados via email dentro de 72 horas da confirmação. Atualizar a página de status com detalhes do incidente. Apresentar notificações regulatórias onde for exigido (GDPR, UAE PDPL). Publicar revisão pós-incidente para aprendizado.

Fase 06

Revisão pós-incidente

Dentro de 2 semanas da resolução, a equipe de engenharia conduz um postmortem sem culpa. Os achados documentados no changelog. As melhorias de processo rastreadas até sua conclusão. Os incidentes maiores revisados no all-hands trimestral.

Seção 05
// Divulgação de vulnerabilidades

Programa de divulgação responsável

Os pesquisadores de segurança que encontram vulnerabilidades podem divulgar essas vulnerabilidades através do nosso programa de divulgação responsável. Seguimos os princípios de divulgação coordenada com objetivos de tempo de resposta que escalam com a severidade.

SeveridadeResposta inicialMeta de correção
Crítica (RCE, bypass de autenticação, exposição de dados)24 horas7 dias a partir da confirmação
Alta (escalonamento de privilégios, divulgação de dados sensíveis)3 dias úteis30 dias a partir da confirmação
Média (divulgação de informações, problemas de menor impacto)5 dias úteis60 dias a partir da confirmação
Baixa (problemas menores, defesa em profundidade)10 dias úteis90 dias a partir da confirmação
Sim

Crédito público e reconhecimento

Os pesquisadores que divulgam são creditados publicamente no nosso hall de reconhecimento de segurança (com permissão). Os achados significativos recebem um agradecimento personalizado e reconhecimento detalhado no changelog.

No

Sem bug bounty no momento

Crawlux atualmente não oferece bug bounties monetários. Um programa formal de bug bounty está no roadmap para Q3 2027 uma vez que as plataformas API e SDK tenham se estabilizado.

Safe harbor para pesquisadores

Os pesquisadores agindo de boa fé dentro do alcance desse programa não estão sujeitos a ação legal sob os termos de serviço. Fora de alcance: engenharia social do staff, ataques físicos, testes de denial-of-service, ataques contra contas de clientes.

Seção 06
// Compliance posture

Certificações e roadmap

Crawlux roda em infraestrutura AWS com extensas certificações herdadas da plataforma. As certificações independentes de Crawlux estão no roadmap com datas objetivo publicadas abertamente.

Agora

Certificações herdadas de AWS

A infraestrutura roda em AWS que tem SOC 2 Type II, ISO 27001, ISO 27017, ISO 27018 e PCI DSS nível 1. Os relatórios de attestation estão disponíveis para clientes enterprise sob solicitação.

Q4 2026

Crawlux SOC 2 Type II

Auditoria SOC 2 Type II independente cobrindo Crawlux como entidade (em cima do attestation herdado de AWS). Conclusão objetivo Q4 2026. Contratação de firma auditora em progresso.

Q2 2027

Crawlux ISO 27001

Certificação ISO 27001 objetivo Q2 2027. Se constrói sobre o trabalho SOC 2 e se estende à documentação formal do sistema de gerenciamento de segurança de informação alinhada a padrões ISO.

// Perguntas frequentes de Segurança

Perguntas comuns

Seis perguntas cobrindo criptografia, resposta a incidentes, divulgação de vulnerabilidades, acesso interno, localização geográfica de data e certificações.

Meus dados de auditoria são criptografados?

Sim. Toda a data está criptografada em trânsito usando TLS 1.3 e em repouso usando AES-256. O storage de base de dados, storage de backup e object storage todos usam criptografia AES-256 com chaves gerenciadas pelo KMS do provedor cloud. As API keys e secrets de assinatura de webhooks estão criptografados com envelope encryption usando chaves isoladas por cliente.

Como vocês lidam com incidentes de segurança?

Os incidentes de segurança seguem um processo de resposta de 5 fases: Detecção dentro de 15 minutos via monitoramento automatizado, Contenção dentro de 1 hora para limitar o blast radius, Avaliação dentro de 4 horas para determinar alcance e impacto, Remediação tipicamente dentro de 24 horas e Comunicação aos usuários afetados dentro de 72 horas da confirmação. A página de status loga todos os incidentes confirmados com timestamps.

Vocês têm um programa de divulgação de vulnerabilidades?

Sim. Os pesquisadores de segurança podem divulgar vulnerabilidades em [email protected]. Seguimos os princípios de divulgação responsável com uma janela de divulgação coordenada de 90 dias. As vulnerabilidades críticas recebem uma janela de resposta de 24 horas. Atualmente não oferecemos bug bounties mas creditamos publicamente os pesquisadores que divulgam no nosso hall de reconhecimento.

Quem tem acesso interno aos meus dados?

O acesso está limitado a membros da equipe de engenharia com necessidade de negócio documentada. Todo o acesso está logado com usuário, ação e timestamp. O acesso à base de dados de produção exige autenticação multi-fator e é auditado mensalmente. A data do cliente nunca é acessada por razões não essenciais. As solicitações de suporte que exigem acesso a data são logadas com o solicitante, destinatário e justificativa.

Onde meus dados ficam armazenados geograficamente?

A infraestrutura primária está hospedada em AWS em regiões UE (eu-west-1 e eu-central-1) para alinhamento com GDPR. As réplicas de backup estão em regiões US de AWS (us-east-1) para redundância. Os resultados de auditoria podem ser processados em regiões de provedores upstream durante a análise (DataForSEO, motores IA) mas a data processada retorna à nossa infraestrutura primária UE dentro de minutos.

Quais certificações vocês têm?

A infraestrutura de Crawlux roda em AWS que tem SOC 2 Type II, ISO 27001 e ISO 27017. Crawlux como empresa está atualmente trabalhando rumo à certificação SOC 2 Type II independente com conclusão objetivo Q4 2026. O roadmap inclui certificação ISO 27001 objetivo Q2 2027. Os contratos enterprise podem solicitar os relatórios de attestation de AWS imediatamente.

Reportar uma vulnerabilidade
// Contato

Contato de segurança

Para divulgação de vulnerabilidades, perguntas de segurança ou reportes de incidentes, o email dedicado de segurança é roteado diretamente à equipe de segurança de engenharia.

Para dúvidas de segurança relacionadas à privacidade, consulte a política de privacidade. Para dúvidas sobre uso aceitável, consulte a política de uso aceitável. Para o status do serviço durante incidentes, consulte a status page.

FAÇA SUA PRIMEIRA AUDITORIA GRÁTIS

Veja o Crawlux no seu próprio site crypto.

Sem cadastro, sem cartão de crédito. Relatório completo de auditoria afinada para Web3 em 60 segundos.

Primeira auditoria grátis · Sem cadastro · 60 segundos · Relatório PDF completo