Arquitetura da plataforma

Como a WASViking é construída e operada. A postura de segurança, o modelo de isolamento e as práticas de engenharia por trás da plataforma.

Esta página é o resumo de arquitetura que as equipes de compras e de segurança de clientes em potencial costumam pedir. Ela cobre os componentes, como eles se comunicam, como os dados são protegidos e as práticas de engenharia por trás da plataforma. Foi escrita para poder ser anexada a uma resposta de due diligence de fornecedor sem edição adicional.

Componentes

Plano de dados

O schema pertence a uma única fonte da verdade, no lado do portal. A API consome esse schema em modo predominantemente de leitura para as suas próprias necessidades de dados. Migrations e mudanças de schema passam pelo mesmo fluxo de pull request que o código da aplicação.

Criptografia

A rotação de chaves é automatizada para material de curta duração (certificados de cliente do agente, chaves de sessão) e conduzida por operador para material de longa duração (chaves de API, com uma janela de sobreposição de 24 horas).

Isolamento entre tenants

O isolamento é imposto em quatro camadas:

• Camada de view: toda view de cliente recusa uma requisição sem contexto de organização.
• Camada de ORM: os querysets têm escopo restrito à organização do usuário que faz a requisição. Consultas entre tenants são tratadas como bug.
• Camada de auditoria: toda linha de auditoria registra a organização do operador. A trilha de auditoria voltada ao cliente segue esse mesmo escopo.
• Camada de faturamento: as linhas de faturamento se vinculam à organização, não aos usuários, de modo que um usuário excluído não perde a trilha de faturamento.

As chaves de API carregam a organização que as emitiu. O uso de uma chave em outra organização retorna 404 (não 403), para não revelar a existência de outros tenants.

O Partner Console usa uma tabela de identidades separada do realm de clientes. Operadores de parceiros não são usuários de clientes. Os dois não conseguem se ver entre hosts.

Identidade e acesso

• SAML 2.0 SSO como Service Provider. Mapeamento padrão de atributos, propagação opcional de grupo para papel. O primeiro login assume Read-only por política; a promoção exige um Admin ou Manager já existente.
• Autenticação multifator é obrigatória para todo operador. Baseada em TOTP quando o SSO não é obrigatório; imposta pelo IdP quando o SSO está ativo.
• RBAC com quatro papéis padrão (Admin, Manager, Analyst, Read-only) e um catálogo granular de capacidades com 25+ escopos. Os papéis são editáveis por organização.
• Chaves de API com escopo por organização. Conjunto granular de escopos por chave. Em hash em repouso, rotacionáveis com sobreposição, opcionalmente restritas por IP.
• Login local de emergência para organizações com SSO obrigatório, como break-glass, TTL de 72 horas, evento de auditoria de alta severidade quando usado.

Arquitetura de rede

• O agente Sentinel é apenas de saída. O agente inicia a conexão com a WASViking de dentro da rede do cliente. Sem portas de entrada, sem allowlist de IP estático, sem exigência de VPN.
• Terminação de mTLS no proxy, com o certificado de cliente verificado encaminhado para dentro. Compatível com load balancers gerenciados de nuvem. A chave privada do agente nunca sai do host.
• Mascaramento no gateway, na camada de serviço gRPC. O servidor nunca registra em log payloads completos de proto, de job ou de resposta, de modo que cookies, tokens CSRF e corpos de alvos internos não aparecem nos logs de operador.
• Os endpoints públicos ficam atrás de uma CDN gerenciada com rate limiting na borda e gestão de bots. Os limites de taxa na camada de aplicação rodam por cima, como uma segunda barreira.

Hardening

Agente:

• Binário Go estático único, distribuído com assinaturas cosign para que os clientes possam verificar antes de executar.
• Unit do systemd com NoNewPrivileges, ProtectSystem=strict, MemoryDenyWriteExecute e filtro restrito de chamadas de sistema.
• Build enterprise ofuscado, opcional, para clientes com exigência de garantia mais alta.

Plataforma:

• Imagens de container construídas a partir de imagens base mínimas, sem volumes de código-fonte em produção.
• Princípio do menor privilégio em tempo de execução no nível da conta de nuvem.
• O acesso à produção exige MFA, tem prazo limitado e é registrado em log.
• Gerenciador de secrets para as credenciais da aplicação. Nenhum secret de longa duração em texto claro no disco.

Desenvolvimento seguro de software

A WASViking usa o próprio produto contra a própria base de código:

• DAST contínuo é executado contra as implantações de staging a cada release.
• SBOM e SCA com cruzamento com o KEV são executados no CI para todos os serviços.
• Detecção de secrets é executada no CI a cada push. Os exit codes do CI bloqueiam merges quando há componentes listados no KEV ou secrets verificados como ativos.
• Revisão de dependências é obrigatória em pull requests.
• Proteção de branch com revisões obrigatórias, commits assinados onde a plataforma oferece suporte e verificações de status obrigatórias antes do merge.
• Artefatos de release assinados para as releases do agente (cosign) e para os containers internos.
• Revisão interna de modelo de ameaças para novos analisadores e para qualquer mudança na superfície de identidade, faturamento ou isolamento de dados.

Este é o mesmo conjunto de gates que a WASViking entrega como produto. O conjunto de páginas do produto traz a referência completa: CI/CD com o wasviking-sentinel.

Higiene operacional

A plataforma executa um pequeno conjunto de jobs em segundo plano para manter o plano de dados consistente e o canal de alertas apenas com sinal:

• Scans agendados (conforme a configuração de cada organização).
• Varreduras de higiene para scans órfãos e scans de longa duração que ficaram parados.
• Ingestão diária de threat intel (OSV.dev + CISA KEV) com correspondência retroativa contra os SBOMs ativos.
• Regras inteligentes de renotificação, para que os alertas só disparem de novo em caso de entrada no KEV, aumento de severidade ou disponibilidade de correção.
• Polling de integrações (Jira, resumo de violações de SLA, reinício da cota de IA).
• Prévias mensais de faturamento; tarefa diária de renovação anual.

Os nomes e os agendamentos dos jobs são um detalhe interno de implementação. Os clientes veem os resultados: dashboards, achados, webhooks, eventos de auditoria.

Logs e auditoria

• Trilha de auditoria voltada ao cliente em /portal/audit-log/, controlada pela capacidade de RBAC audit_logs.view. Escopo REST público audit_logs:read.
• Eventos de mutação (mudança de RBAC, emissão de chave de API, transição de status de achado, acesso a Posture Share, acesso a Evidence Bundle) são gravados de forma imutável.
• Eventos de operador e de sistema são transmitidos para a stack de observabilidade do lado da WASViking, com retenção própria.
• A retenção padrão de auditoria é de 24 meses; configurável até 7 anos nos planos Enterprise.
• Eventos de webhook assinados espelham as transições relevantes para auditoria, para ingestão em um SIEM externo.

Backups, durabilidade e recuperação de desastres

• Backups diários automatizados dos bancos de dados relacional e de documentos.
• Retenção de backups de 30 dias por padrão.
• Replicação entre regiões para planos Enterprise, com recuperação point-in-time em uma região secundária.
• A restauração é iniciada por operador e auditada; não há rollbacks silenciosos.
• Exercícios trimestrais de recuperação validam o runbook.

Residência de dados

Os dados de produção estão hospedados hoje em regiões da AWS nos Estados Unidos. Opções de residência regional para outras jurisdições fazem parte do roadmap do Enterprise. Os suboperadores e as suas regiões estão documentados no Trust Center.

Postura de conformidade

Duas posturas, mantidas estritamente separadas:

O que o produto suporta. A WASViking mapeia achados para controles de PCI DSS v4.0, LGPD, GDPR, BACEN (CMN 4.893 e BCB 85) e ISO 27001:2022, a partir de uma única tabela de regras. Os Evidence Bundles são projetados para ser anexados diretamente a uma pasta de auditoria. Veja Mapeamento de frameworks.

Para o que a empresa é certificada. A WASViking LLC está em preparação para SOC 2 Type I e certificação ISO 27001. O status atual, a lista de suboperadores, o DPA e o questionário de segurança (CAIQ / SIG) estão disponíveis no Trust Center em wasviking.com/trust-center/.

Divulgação de vulnerabilidades

A WASViking recebe bem a divulgação coordenada. A política, o escopo, o safe harbor e a chave PGP estão em Como reportar vulnerabilidades. Quem reportou e foi reconhecido é citado nominalmente (com permissão) quando a WASViking notifica os clientes afetados sobre o problema.

O que publicamos externamente

• Esta documentação.
• O site institucional de marketing.
• O Trust Center com DPA, política de privacidade, suboperadores e o roadmap de SOC 2.
• Uma política de divulgação coordenada e a chave PGP.

O que não publicamos externamente

Os itens a seguir são compartilhados apenas mediante NDA mútuo assinado (ou não são compartilhados):

• Faixas de IP internas, diagramas de rede e identificadores de contas em provedores.
• Versões específicas de frameworks, bancos de dados e runtimes em uso.
• Rotas administrativas internas e runbooks de operador.
• Modelos de margem e de custo.
• Procedimentos de resposta a incidentes.
• Configurações específicas de clientes.

Eles são retidos deliberadamente porque são operacionalmente sensíveis e não oferecem nenhum valor de segurança a um cliente em potencial.