WASViking Sentinel Tunnel

Analise as aplicações que nunca tocam a internet. Instale o agente Sentinel dentro da sua rede, registre-o com um token de uso único e deixe que ele abra um túnel mTLS de saída que você pode rotacionar ou revogar a qualquer momento.

As suas aplicações mais sensíveis costumam ser justamente as que um scanner em nuvem não enxerga: o ambiente de staging atrás da VPN, a API interna que só a rede do escritório alcança, o painel administrativo em um endereço privado. Testá-las normalmente força uma escolha ruim: abrir um buraco no firewall para um fornecedor ou deixá-las sem teste.

O WASViking^® Sentinel elimina essa escolha. Ele é um agente pequeno que você instala em um host Linux dentro da sua rede. O agente inicia uma conexão de saída para a nuvem da WASViking por TLS mútuo e mantém um túnel aberto; o tráfego de scan dos seus alvos internos passa por esse túnel. Nada se conecta de fora para dentro. O seu firewall mantém todas as portas de entrada fechadas, e os scans alcançam os endereços privados da sua infraestrutura de Dev e STG como se o scanner estivesse ao lado deles.

Por que a sua equipe de segurança vai aprovar isto

Esta é a parte para levar à revisão de segurança e conformidade antes de instalar qualquer coisa:

• Somente saída. O agente abre uma única conexão HTTPS de saída na porta 443. Sem portas de entrada, sem regras de NAT, sem contas de VPN para terceiros, nada para um atacante externo encontrar.
• TLS mútuo com uma identidade por agente. Durante o registro, o agente recebe os seus próprios certificados de cliente, vinculados à sua organização. Os dois lados se autenticam; uma conexão sem um certificado de cliente válido para a sua organização é recusada.
• O kill switch fica com você. Todo agente pode ter o token rotacionado ou ser revogado pelo portal, e um agente revogado é cortado imediatamente. O acesso da WASViking à sua rede interna existe apenas enquanto você mantém um agente registrado e em execução.
• Bootstrap de uso único. O token de registro é exibido uma vez e vale para um único registro. Depois disso, o certificado é a identidade; o token é inútil para quem o encontrar mais tarde.
• Alcance delimitado. O agente só analisa os alvos internos que você cadastra no portal, e você pode restringir ainda mais o alcance de rede dele com as suas próprias regras de firewall em torno do host em que ele roda.

O detalhe completo de transporte e hardening está em Arquitetura do Sentinel; o texto foi escrito para ser entregue a um revisor de segurança.

Onde isto ajuda no dia a dia

• Dev e STG antes da release. O mesmo motor de scan que cobre o seu site público roda contra endereços de pré-produção, de modo que os problemas são detectados antes de irem para produção.
• Aplicações somente internas. Aplicações de intranet, APIs internas e painéis administrativos recebem o mesmo fluxo de trabalho de achados, a mesma pontuação de risco e o mesmo mapeamento de conformidade que todo o resto.
• Redes segmentadas. Instale um agente por segmento ou data center; o portal roteia cada scan pelo agente certo.
• Evidência para o auditor. As aplicações internas aparecem na sua postura com histórico de scans, o que responde à pergunta recorrente de auditoria sobre a cobertura além do perímetro público.

Pré-requisitos

Passo 1: Abra a página Sentinel Agents

No portal, vá em Infra → Sentinel Agents.

A página agrupa cada identidade Sentinel pelo que ela faz. Quatro cartões no topo (Scan Tunnels, AI Guardian, CI/CD Pipelines e Infrastructure Defense) mostram quantos agentes cada grupo tem e quantos estão conectados, aguardando ou pedindo atenção. Clique em um cartão para abrir a lista dele. Este guia usa Scan Tunnels.

A lista de Scan Tunnels mostra cada agente com o hostname, o status, a versão, o último contato e o número de alvos de scan vinculados a ele. A busca e os filtros de status reduzem a lista, e Show revoked traz de volta os agentes revogados. A coluna Actions reúne Details, Update (quando há uma versão mais nova), Rotate Token (rotacionar o token) e Revoke (revogar).

Infra → Sentinel Agents.

Passo 2: Registre o agente e copie o token

Clique em Add Sentinel Agent (adicionar agente Sentinel) e dê a ele um nome de exibição. É um rótulo para humanos, exibido no portal, não o hostname da máquina, e precisa ser único na sua organização. Nomeie o agente de acordo com a localidade e o segmento que ele vai atender, por exemplo Acme Brazil - Sao Paulo Staging, para que daqui a um ano a tabela continue parecendo um mapa da sua rede.

Um rótulo amigável para humanos, único na sua organização. Você pode renomeá-lo depois.

Clique em Create. O portal exibe o token de bootstrap RAW uma única vez. Copie o token e guarde-o em local seguro; é ele que você vai usar no host no próximo passo. O token autoriza um único registro, então, se você perdê-lo antes de registrar, use Rotate Token na linha do agente para emitir um novo.

O token de bootstrap é exibido uma única vez. Copie-o antes de fechar.

Se você está implantando em vários segmentos, Create another (criar outro) repete o fluxo sem sair do diálogo. Um agente por segmento ou data center é o padrão que escala.

Passo 3: Instale e registre no host

Clique em Get Agent (obter o agente) para abrir as instruções de instalação da sua plataforma. Para Ubuntu/Debian, o fluxo tem três comandos.

Baixe o pacote .deb e, se o seu processo de mudança exigir, confira o SHA256 e a assinatura com o link Verify download. Em seguida, instale e ative o serviço:

sudo dpkg -i wasviking-sentinel_<version>_amd64.deb
sudo systemctl enable --now wasviking-sentinel

O serviço já inicia e fica aguardando o registro, então não é preciso fazer mais nada antes do próximo comando.

Registre o agente com o token do Passo 2, a partir de qualquer diretório. O registro é executado uma única vez por agente: ele baixa com segurança os certificados de cliente que passam a ser a identidade do agente, grava a configuração em /opt/wasviking-sentinel/configs/config.yaml e entrega os arquivos à conta de serviço.

sudo /opt/wasviking-sentinel/wasviking-sentinel register --token <YOUR_TOKEN_FROM_PORTAL>

O serviço em execução detecta o registro e se conecta sozinho em cerca de 15 segundos, sem reinício. Se você encontrar instruções que executam ./wasviking-sentinel register de dentro do diretório do agente sem sudo, use o comando acima no lugar delas: a forma antiga falha por permissão de arquivo.

Get Agent: baixar, verificar, instalar e registrar.

Passo 4: Confirme que o túnel está ativo

De volta a Infra → Sentinel Agents, o agente passa de Pending para Active e a coluna Last Seen começa a ser atualizada com o heartbeat dele. Essa é a sua confirmação de que o túnel de saída foi estabelecido.

No host, o status do serviço confirma o mesmo:

sudo systemctl status wasviking-sentinel

As linhas mais recentes incluem Tunnel connected to sentinel.wasviking.com:443.

Se o agente continuar em Pending por mais de alguns minutos, execute a verificação embutida no host:

sudo /opt/wasviking-sentinel/wasviking-sentinel check

Ela lê a instalação e testa o caminho até a plataforma sem alterar nada, depois imprime um veredito (PASS, WARN ou FAIL) com a causa raiz mais provável e o próximo passo exato. A causa é quase sempre uma destas:

• O agente não foi registrado, ou o serviço não consegue ler os seus arquivos.
• A saída TCP 443 para sentinel.wasviking.com está bloqueada para esse host: firewall do host, security group ou network ACL da nuvem, NAT ou proxy.
• Um proxy corporativo ou um appliance de interceptação de TLS está quebrando o handshake do TLS mútuo. O túnel precisa passar sem ser tocado.
• O relógio do sistema está errado; verifique o NTP.

A verificação também grava um pacote de suporte, um arquivo .json e um .txt, no diretório atual. Envie os dois ao suporte da WASViking se precisar de ajuda. A referência completa, com as opções e uma tabela de problemas comuns, está em Solução de problemas com o comando check.

Passo 5: Execute o primeiro scan interno

Cadastre um alvo interno da mesma forma que você cadastrou o seu primeiro alvo público, mas aponte-o para o endereço privado (por exemplo, https://erp.saopaulo.acme.internal ou http://10.20.30.40:8080).

Em seguida, inicie o scan em AppSec → New Scan (/portal/scans/new). Este é o passo que de fato roteia o scan pelo túnel: em Preferences → Scan Method, defina Execution Path como Sentinel Tunnel (Internal) e escolha o seu agente no dropdown Sentinel Agent, por exemplo Acme Brazil - Sao Paulo Staging (Active).

Quando um template de scan está selecionado, as configurações abaixo dele seguem o template e ficam travadas. Ligue Override template settings for this scan only, logo abaixo do template, para escolher o caminho de execução deste scan.

Não deixe Execution Path em Direct (External) para um alvo interno. Direct é para endereços que são públicos na internet; o scanner em nuvem não alcança um endereço privado, então um scan interno despachado como Direct não tem nada para testar. Sentinel Tunnel (Internal) com o agente certo é o que leva o scan com segurança até o endereço interno.

Preferences → Scan Method: Execution Path e o agente criado no Passo 2.

Clique em Scan now. O scan é despachado pelo túnel, roda contra o endereço interno, e os achados vão para o mesmo fluxo de trabalho de Findings que todo o resto, com o alvo claramente marcado como interno.

Antes de qualquer teste, o scan verifica, a partir do agente, se o alvo aceita conexões nas portas 443 e 80, e na porta do endereço quando ela existe. Se nada responder, o scan para, normalmente em menos de um minuto, e a lista de Scans o mostra como Failed com Target unreachable. Passe o mouse sobre ele para ler o motivo, que informa o alvo, as portas verificadas e o agente. Confirme que a aplicação está no ar e que o firewall do alvo aceita conexões vindas do host do agente, por exemplo com curl -v http://10.20.30.40:8080/ executado nesse host, e inicie o scan de novo.

Os campos do alvo, as opções de autenticação e o roteamento por agente estão documentados em Scans internos.

Operando o parque

• Rotate Token emite um novo bootstrap para um agente, que é o que fazer quando um token vazou antes do registro ou quando você reconstrói um host e precisa registrar de novo.
• Revoke corta o agente imediatamente. Os certificados registrados deixam de ser aceitos, os scans deixam de ser roteados por ele e a linha permanece na tabela para a trilha de auditoria.
• Update instala uma release mais nova em um agente conectado, e Update all faz o mesmo em todos os agentes que podem ser atualizados. Vale para agentes instalados pelo pacote Debian, versão 1.23.0 ou posterior. Só pacotes assinados pela WASViking são instalados, e um administrador do host pode desligar as atualizações remotas. Veja Atualização pelo portal.
• Details abre a página do agente. A partir da versão 1.24.0, ela mostra Host and tunnel health: CPU, memória e rede do host, o quanto o túnel está ocupado e observações que dizem o que verificar quando os scans que passam por ele ficam lentos. Veja Saúde do host e do túnel.
• Um agente por segmento. Agentes custam pouco para rodar; dê a cada segmento de rede ou data center o seu, nomeie-os de forma consistente, e o roteamento por alvo escolhe o agente certo.
• O mesmo binário instalado também executa sbom e secrets contra os seus repositórios, de modo que o host que você acabou de configurar também pode alimentar os módulos de cadeia de suprimentos.

Próximos passos

• Aponte o seu primeiro alvo interno para o agente: Scans internos.
• Entregue o desenho do transporte à sua equipe de segurança: Arquitetura do Sentinel.
• Coloque o mesmo binário no seu pipeline: wasviking-sentinel em CI/CD.
• Agende scans internos recorrentes: Agendamentos de scan.