Arquitetura do Sentinel
Como o agente inicia uma conexão mTLS de saída para abrir um túnel, e por que nenhuma porta de entrada é necessária em momento algum.
O WASViking® Sentinel é um binário em Go que você instala em um host dentro da sua rede. O agente inicia uma conexão de saída com a WASViking por TLS mútuo e abre um túnel gRPC bidirecional. Todo analisador dinâmico roteia as suas sondas HTTP por esse túnel de forma transparente, sem código específico por analisador.
Transporte
- Somente de saída. Sem portas de entrada, sem allow-list de IP estático, sem VPN. É o agente quem inicia.
- TLS mútuo. O certificado de cliente é provisionado durante o
wasviking-sentinel registere é rotacionado de forma programada. - gRPC sobre HTTP/2. Stream de longa duração, controle de fluxo no lado do servidor.
- Compatível com load balancers padrão. Funciona atrás de load balancers gerenciados comuns, que terminam o mTLS e encaminham o certificado de cliente verificado.
- Vínculo com a organização. O CN/O do certificado identifica a organização. Requisições entre tenants são recusadas na camada de serviço gRPC.
Hardening no host
O pacote do Sentinel traz uma unit do systemd com:
NoNewPrivileges=trueProtectSystem=strictMemoryDenyWriteExecute=true- Chamadas de sistema restritas
- Releases assinadas com Cosign (verificáveis com a chave pública publicada)
Um build enterprise ofuscado está disponível para ambientes que o exigem.
Privacidade do operador
O serviço gRPC mascara secrets na fronteira. O servidor nunca registra em log payloads completos de proto, de job ou de resposta. Cookies, tokens CSRF e corpos de alvos internos não aparecem nos logs do operador.
Isso é imposto em código na camada de serviço, não em política. Todo novo método gRPC já nasce com o mascaramento embutido, por design.
Analisadores pelo túnel
O túnel é uma propriedade da plataforma, não um recurso de um único scanner. Os mesmos analisadores DAST que rodam contra alvos externos rodam contra alvos internos pelo túnel:
- SQL Injection, XSS, JWT e as verificações da classe de injeção.
- GraphQL, SOAP/WSDL e WebSocket.
- Detecção de componentes, exposição de arquivos e caminhos sensíveis e headers de segurança.
Nenhum analisador carrega código específico de túnel. A camada HTTP roteia de forma transparente.
O que o agente faz além de DAST
A CLI do Sentinel também expõe:
wasviking-sentinel sbom: geração de SBOM no ambiente do cliente, enriquecimento com OSV + KEV, envio por REST.wasviking-sentinel secrets: scan de secrets no sistema de arquivos e no histórico do git, verificação ao vivo opcional, apenas hash + prévia mascarada em trânsito.wasviking-sentinel ci: gate de CI/CD para SCA, secrets e scans orientados por template, com exit codes determinísticos.
Veja as próximas páginas desta seção para cada subcomando.
Despacho de jobs
Os scans internos são enfileirados no lado da WASViking. O servidor gRPC entrega um job ao agente conectado da organização certa, o agente o executa localmente e transmite os resultados de volta em stream. Heartbeats mantêm a conexão saudável e detectam agentes zumbis.
Modos de falha
| Sintoma | Causa provável |
|---|---|
| O agente não consegue se registrar | Token expirado ou rotacionado. Emita outro pelo portal. |
| O túnel cai a cada poucos minutos | O proxy de rede impõe um timeout de ociosidade. Configure keep-alive. |
| 403 nos endpoints de envio | Divergência no vínculo com a organização. Registre novamente ou confira o CN do certificado. |
| Scans na fila, mas sem executar | Agente desconectado. Verifique systemctl status wasviking-sentinel. |
A página Sentinel Agents no portal mostra o estado do agente, o último heartbeat e o histórico de provisionamento.
Para correções passo a passo (agente que fica em Pending, túnel que cai o tempo todo, problemas de certificado), veja a seção de solução de problemas de Instalação do agente Sentinel.