Edge Threat Radar (Google Cloud Armor)

Conecte o Google Cloud Armor para que o Edge Threat Radar correlacione o tráfego adversário com a sua postura. Somente leitura por padrão; um papel opcional para o bloqueio de IP condicionado a aprovação.

A integração com o Google Cloud Armor alimenta o Edge Threat Radar para workloads que ficam atrás de um Application Load Balancer externo do Google Cloud em vez da Cloudflare (ou ao lado dela). A WASViking^® lê os logs de requisições do load balancer, onde toda decisão do Cloud Armor fica registrada, por meio da API do Cloud Logging e os correlaciona com os seus achados abertos, amplificando o Risk Score quando o tráfego adversário corresponde a uma exposição real.

Se a sua borda é a Cloudflare, siga o guia da Cloudflare em vez deste. Você pode usar as duas ao mesmo tempo: cada zona ou política conectada conta na mesma franquia de alvos do Edge Threat Radar do seu plano.

O que esta integração faz

• Coleta as decisões de allow/deny do Cloud Armor e os acionamentos de regras de WAF a cada 5 minutos, direto dos logs de requisições do seu load balancer.
• Correlaciona os eventos com os achados abertos e amplifica o Risk Score.
• Enriquece os IPs com AbuseIPDB e ThreatFox.
• Alimenta o mesmo dashboard do Edge Threat Radar, o mesmo escopo do assistente de IA e os mesmos alertas multicanal da integração com a Cloudflare: os dados dos dois provedores chegam a um só lugar.
• Opcionalmente, mantém regras de deny gerenciadas pela WASViking na sua política de segurança do Cloud Armor, com a mesma salvaguarda da Cloudflare: nenhum IP é bloqueado automaticamente. Cada bloqueio depende de aprovação explícita do cliente, por evento.
• Lê as suas zonas públicas do Cloud DNS (somente leitura) como fonte adicional de descoberta de subdomínios, revelando hosts escondidos atrás de certificados wildcard para o Certificate Monitoring, a mesma capacidade que a integração com a Cloudflare obtém com o escopo de zona DNS (Read).

Postura de acesso

• Somente leitura por padrão. A conta de serviço só precisa de permissão para ler logs e zonas de DNS. Nenhum tráfego é interceptado, nenhuma regra é enviada, nenhuma infraestrutura é alterada.
• Uma exceção: o bloqueio opcional condicionado a aprovação precisa do papel Compute Security Admin para que a WASViking possa gravar regras de deny na política. Ele é usado somente para executar bloqueios que o cliente aprovou explicitamente.
• A descoberta de subdomínios no Cloud DNS usa apenas o papel somente leitura DNS Reader: zonas e registros são listados, nunca criados ou alterados, e zonas privadas nunca são lidas.
• Revogável a qualquer momento pelo lado do Google Cloud (exclua a chave da conta de serviço ou a própria conta de serviço).

Pré-requisitos

Configuração do Google Cloud com gcloud

Tudo do lado do Google Cloud é feito pela linha de comando, então você pode executar em um projeto existente, aquele que já hospeda o seu load balancer e a sua política do Cloud Armor. Abra o Cloud Shell (sem necessidade de instalação local) ou um terminal com a CLI gcloud autenticada.

Defina as variáveis uma vez e reutilize-as no restante deste guia:

# The project that hosts the load balancer and the security policy.
# This is the project ID (e.g. my-company-prod), not the display name.
export PROJECT_ID="your-project-id"

# The existing objects you want to monitor.
export SECURITY_POLICY="your-cloud-armor-policy"
export BACKEND_SERVICE="your-backend-service"

gcloud config set project "$PROJECT_ID"

Passo 1: Ative os sinais na origem

O Cloud Armor não tem API de eventos. Toda decisão de allow/deny que ele toma é gravada nos logs de requisições do load balancer, e são esses logs que a WASViking lê. Três configurações precisam estar corretas para que os logs tragam dados úteis.

1.1 Confirme que a política está vinculada ao backend service

gcloud compute backend-services describe "$BACKEND_SERVICE" \
    --global \
    --format="yaml(name,securityPolicy)"

A linha securityPolicy deve apontar para a sua política. Se estiver vazia, vincule-a:

gcloud compute backend-services update "$BACKEND_SERVICE" \
    --global \
    --security-policy="$SECURITY_POLICY"

Use exatamente o mesmo nome de $SECURITY_POLICY depois, no portal (Passo 3). Um erro de digitação aqui é o motivo mais comum para uma integração que conecta, mas permanece vazia.

1.2 Ative o log de requisições no backend service

Se o log estiver desativado, o Cloud Armor continua protegendo você, mas nada é gravado para a WASViking ler.

gcloud compute backend-services update "$BACKEND_SERVICE" \
    --global \
    --enable-logging \
    --logging-sample-rate=1.0

Confirme que a alteração foi aplicada:

gcloud compute backend-services describe "$BACKEND_SERVICE" \
    --global \
    --format="yaml(logConfig)"
# logConfig:
#   enable: true
#   sampleRate: 1.0

Uma taxa de amostragem abaixo de 1.0 registra apenas essa fração das requisições. A integração continua funcionando, mas o Radar só enxerga a fatia amostrada. Para visibilidade de segurança, mantenha em 1.0.

1.3 Mude a política para o log verbose

Por padrão, o Cloud Armor registra a decisão, mas não o detalhe. O log verbose acrescenta o país do atacante e as regras de WAF específicas que foram acionadas, o contexto que o Radar usa para atribuição geográfica e detalhe por regra. Essa flag existe apenas na CLI; o console não tem um controle para ela.

gcloud compute security-policies update "$SECURITY_POLICY" \
    --log-level=VERBOSE

Se você deixar em NORMAL, a ingestão continua funcionando: as colunas de país e de regra acionada apenas ficam mais pobres. O Google recomenda o verbose principalmente durante ajustes ou solução de problemas, já que ele grava mais detalhes das requisições nos seus logs; para visibilidade de ameaças na borda, vale a pena deixá-lo ativado.

1.4 Confirme que as decisões do Cloud Armor estão sendo registradas

Envie uma requisição pelo load balancer (ou aguarde tráfego real) e depois leia os logs do load balancer. Confirmar isso agora mostra que o lado do Google está correto antes de você configurar o portal:

gcloud logging read \
  'resource.type="http_load_balancer"
   AND jsonPayload.enforcedSecurityPolicy.name="'"$SECURITY_POLICY"'"' \
  --project="$PROJECT_ID" \
  --freshness=30m \
  --limit=20 \
  --format="table(
    timestamp,
    httpRequest.remoteIp,
    httpRequest.requestMethod,
    httpRequest.requestUrl,
    httpRequest.status,
    jsonPayload.statusDetails,
    jsonPayload.enforcedSecurityPolicy.priority,
    jsonPayload.enforcedSecurityPolicy.outcome
  )"

Você deve ver uma linha por requisição. Uma requisição normal aparece como OUTCOME: ACCEPT; uma bloqueada, como OUTCOME: DENY com STATUS: 403 e STATUS_DETAILS: denied_by_security_policy. Se quiser forçar um DENY para confirmar que o bloqueio é registrado, acesse um caminho que as suas regras de WAF rejeitam, por exemplo:

curl -i -A "sqlmap/1.8" "http://YOUR_LB_IP/"

Se esta consulta não retornar nada, pare aqui: o problema está no lado do Google (log desativado, taxa de amostragem 0, política não vinculada ou erro de digitação no nome da política), não na WASViking. Corrija antes do Passo 3.

Passo 2: Crie a conta de serviço e a chave

A WASViking se autentica na API do Cloud Logging com uma conta de serviço dedicada, seguindo o mesmo modelo de pull da integração com a Cloudflare. Mantenha-a separada de todo o resto para que possa ser revogada de forma independente.

2.1 Crie a conta de serviço e conceda os papéis

gcloud iam service-accounts create wasviking-edge-radar \
    --display-name="WASViking Edge Threat Radar" \
    --description="Read-only access to Cloud Armor load balancer logs and Cloud DNS zones"

export SERVICE_ACCOUNT_EMAIL="wasviking-edge-radar@${PROJECT_ID}.iam.gserviceaccount.com"

# Required: read the load balancer request logs.
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/logging.viewer"

# Required: read the public Cloud DNS zones for subdomain discovery.
gcloud services enable dns.googleapis.com --project="$PROJECT_ID"

gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/dns.reader"

O DNS Reader espelha o escopo de zona DNS (Read) da integração com a Cloudflare: ele permite que a WASViking leia os registros das zonas como fonte adicional de descoberta de subdomínios. Ele revela hosts escondidos atrás de um certificado wildcard, que os logs públicos de certificados não conseguem enumerar, e alimenta o Certificate Monitoring. O acesso permanece estritamente somente leitura: nenhum registro DNS é criado ou alterado, e zonas privadas nunca são lidas, apenas zonas públicas alimentam a descoberta. Se este projeto não hospeda zonas públicas do Cloud DNS (o seu DNS fica em outro lugar), a concessão é inofensiva e a descoberta simplesmente continua funcionando a partir das fontes públicas.

Adicione o papel opcional somente se você quiser o bloqueio de IP condicionado a aprovação. Ele permite que a WASViking grave na política regras de deny aprovadas pelo cliente; sem ele, a integração é estritamente somente leitura e o botão de bloqueio no portal apenas informa que a ação está indisponível.

# Optional: only for one-click, approval-gated blocking.
gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/compute.securityAdmin"

O menor privilégio vence. Se você ainda não tem certeza, conceda agora os dois papéis obrigatórios somente leitura e adicione roles/compute.securityAdmin depois, quando decidir ativar o bloqueio.

2.2 Crie a chave JSON

gcloud iam service-accounts keys create wasviking-edge-radar-key.json \
    --iam-account="$SERVICE_ACCOUNT_EMAIL"

O arquivo wasviking-edge-radar-key.json é o que você cola no portal no Passo 3. Guarde-o apenas até a configuração ser salva e depois exclua a cópia local (rm wasviking-edge-radar-key.json). No Cloud Shell, use antes o menu ⋮ → Download do arquivo para trazê-lo para a sua máquina.

2.3 Se a criação da chave estiver bloqueada

Muitas organizações aplicam a política de organização constraints/iam.disableServiceAccountKeyCreation (o Google a ativa por padrão para organizações criadas a partir de 3 de maio de 2024). Quando ela está ativa, o comando da chave falha com:

FAILED_PRECONDITION: Key creation is not allowed on this service account.

Se isso acontecer, um Organization Policy Administrator precisa permitir a criação de chaves para este projeto. É uma alteração no nível da organização, e um Project Owner não consegue fazê-la:

gcloud services enable orgpolicy.googleapis.com --project="$PROJECT_ID"

cat > allow-sa-keys.yaml <<EOF
name: projects/${PROJECT_ID}/policies/iam.disableServiceAccountKeyCreation
spec:
  rules:
  - enforce: false
EOF

gcloud org-policies set-policy allow-sa-keys.yaml

Depois, execute novamente o Passo 2.2. Se uma tentativa com falha deixou um wasviking-edge-radar-key.json vazio para trás, exclua-o antes, para não colar um arquivo vazio no portal.

Se a sua organização proíbe totalmente chaves de conta de serviço e não concede uma exceção por projeto, entre em contato com o suporte da WASViking: é possível combinar uma configuração sem chave.

2.4 Verifique se a chave é válida

Antes de colar, confirme que o arquivo é uma chave JSON completa. Um arquivo truncado ou vazio é a causa mais comum de falha na conexão:

python3 -c "import json,sys; d=json.load(open('wasviking-edge-radar-key.json')); sys.exit('Invalid key file') if not (d.get('private_key') and d.get('type')=='service_account') else print('OK', d['client_email'])"

Passo 3: Configure no lado da WASViking

No portal, vá para Settings → System Settings → Edge Threat Radar. Abaixo do card da Cloudflare você encontra o card Google Cloud Armor Settings, que lista as políticas já conectadas a esta organização, cada uma com o seu projeto, a janela de lookback, o status e a última execução.

Settings → System Settings → Edge Threat Radar → Google Cloud Armor Settings.

3.1 Adicione uma política

Clique em + Add Cloud Armor Policy. O diálogo Google Cloud Armor Configuration é aberto. Preencha:

Ao contrário da Cloudflare, aqui não há listas para carregar: o Cloud Armor não tem o conceito de lista. Os endereços confiáveis ficam neste diálogo, e a lista de bloqueio fica dentro da própria política, como regras gerenciadas pela WASViking (mais sobre isso abaixo).

O diálogo Google Cloud Armor Configuration, aberto a partir de + Add Cloud Armor Policy.

3.2 Salve e confirme

Clique em Save. A política volta para a lista. Assim que a primeira coleta for bem-sucedida, a linha dela mostra Active com um badge success e um horário em Last run, e o dashboard do Edge Threat Radar começa a ser preenchido em poucos minutos. Para alterar qualquer campo depois, use Edit na linha. Na edição, deixar o campo da chave em branco mantém a chave armazenada.

O que a WASViking coleta

Por entrada de log do load balancer:

• IP de origem.
• País (com o log verbose ativado).
• URL e método atacados.
• Status HTTP retornado.
• A decisão do Cloud Armor (allow, deny, throttle, redirect).
• A prioridade da regra e as expressões de regras de WAF pré-configuradas que foram acionadas (com o log verbose ativado).
• User agent.
• Timestamp.

Cada evento é enriquecido com a reputação do AbuseIPDB e do ThreatFox, correlacionado com os achados abertos e exibido no mesmo dashboard do Edge Threat Radar que o seu tráfego da Cloudflare.

O Cloud Armor não tem uma pontuação de bot equivalente à do Bot Management da Cloudflare. A pontuação comportamental da própria WASViking (taxa de requisições, dispersão de caminhos, sondagem de caminhos sensíveis, assinaturas de ferramentas) cumpre esse papel, então a classificação continua funcionando: ela apenas se apoia em comportamento em vez de uma pontuação vinda do provedor.

Como o bloqueio funciona no Cloud Armor

Ativação da ação de bloqueio (uma única vez)

O bloqueio fica desativado até você concedê-lo. Com apenas os dois papéis somente leitura do Passo 2.1, a integração não consegue alterar nada: o botão de bloqueio no portal informa que a ação está indisponível, e qualquer tentativa retorna um HTTP 403 do Google. Para ativá-lo, conceda o papel de bloqueio à mesma conta de serviço, sem necessidade de nova chave nem de alteração no portal:

gcloud projects add-iam-policy-binding "$PROJECT_ID" \
    --member="serviceAccount:${SERVICE_ACCOUNT_EMAIL}" \
    --role="roles/compute.securityAdmin"

Alterações de IAM podem levar até um minuto para propagar. Depois disso, o botão Block this IP at the edge (bloquear este IP na borda) de um IP do Cloud Armor passa a funcionar e grava na sua política. Para confirmar que a política está acessível, descreva-a: gcloud compute security-policies describe "$SECURITY_POLICY" --format="value(name)".

Tenha o menor privilégio em mente: este papel permite que a WASViking adicione e remova regras de deny na política. Ele nunca toca nas regras que você criou (veja abaixo). Se depois você quiser tornar a integração somente leitura de novo, remova o binding com gcloud projects remove-iam-policy-binding usando os mesmos --member/--role.

O que um bloqueio faz

Não há uma lista de bloqueio separada para criar. Quando você aprova um bloqueio no portal, a WASViking grava uma regra de deny diretamente na sua política de segurança:

• Toda regra gerenciada recebe a tag wasviking-managed e é colocada em uma prioridade alta (a partir de 100000), de modo que nunca se sobrepõe às regras que você criou. A WASViking só lê ou altera as próprias regras marcadas com a tag: as suas regras nunca são tocadas.
• A ação é deny(403).
• Há um limite de capacidade para a quantidade de endereços que podem ser bloqueados dessa forma. Se ele for atingido, você recebe uma mensagem clara no portal em vez de uma falha silenciosa.

O fluxo de aprovação é idêntico ao da Cloudflare:

Edge event detected
        │
        ▼
WASViking risk amplification
        │
        ▼
Notification email to the operator (event details + approve link)
        │
        ▼
Operator approves in the portal
        │
        ▼
WASViking adds a deny rule to the security policy
        │
        ▼
Cloud Armor blocks the IP at the edge

Nenhuma regra chega à política sem a etapa do operador. A decisão de aprovar / rejeitar fica registrada na trilha de auditoria dos dois lados.

Se a WASViking também executa scans DAST contra a aplicação atrás deste load balancer, adicione a sua própria regra de allow para os IPs de saída do scanner da WASViking em uma prioridade menor que 100000 (número menor = precedência maior). Isso garante que um bloqueio aprovado nunca atinja os seus próprios testes de segurança.

Seus primeiros resultados

Depois que a política é salva e ativada, a primeira coleta roda em poucos minutos e o dashboard do Edge Threat Radar (Dashboard → Edge Intelligence) começa a ser preenchido: um mapa global de ataques, a distribuição por classificação e um ranking dos principais atacantes com país, pontuação de risco, volume de requisições e horário da última ocorrência. O tráfego do Cloud Armor e o da Cloudflare aparecem lado a lado. A partir daqui você pode abrir qualquer IP para ver a inteligência completa e aprovar um bloqueio quando for o caso.

Dashboard → Edge Intelligence, preenchido alguns minutos após a configuração.

Notas de operação

• Cadência. A WASViking faz a coleta a cada 5 minutos por política, assim como nas zonas da Cloudflare.
• Franquia compartilhada. Cada coletor conectado, seja zona da Cloudflare ou política do Cloud Armor, consome um alvo do Edge Threat Radar do seu plano. Veja a aba Usage.
• Janela de lookback. Cada coleta lê a janela que você configurou (padrão de 60 minutos); eventos já vistos são deduplicados, então janelas sobrepostas são seguras.
• Múltiplas políticas. Adicione uma configuração por política de segurança. A mesma chave de conta de serviço pode ser reutilizada entre políticas do mesmo projeto.

Problemas comuns

Como revogar a integração

• Revogação branda: no portal da WASViking, abra Settings → System Settings → Edge Threat Radar, clique em Edit na política e desative Enable this configuration for Edge Intel ingestion. As leituras param; a configuração é mantida para que você possa reativá-la depois.
• Revogação definitiva: exclua a chave (ou a conta de serviço inteira) no Google Cloud. A WASViking mostra um erro na próxima coleta e para de tentar. Nenhum dado é retido além da janela de retenção de eventos configurada.

```bash # List the key IDs, then delete the one in use: gcloud iam service-accounts keys list \ --iam-account="$SERVICE_ACCOUNT_EMAIL" gcloud iam service-accounts keys delete KEY_ID \ --iam-account="$SERVICE_ACCOUNT_EMAIL"

# Or remove the service account entirely: gcloud iam service-accounts delete "$SERVICE_ACCOUNT_EMAIL" ```

Postura de conformidade

• Alinhada ao princípio do menor privilégio.
• Papel somente leitura por padrão; um papel administrativo opcional, condicionado à aprovação explícita do cliente por evento.
• Compatível com os requisitos de monitoramento e auditoria de ISO 27001, LGPD, GDPR, NIST e OWASP Top 10.

Onde isto se encaixa na plataforma

• A capacidade está em Edge Threat Radar.
• A versão Cloudflare desta integração está documentada em Edge Threat Radar (Cloudflare).
• A lógica de amplificação de risco está documentada em Achados e Risk Score.
• O roteamento de alertas está documentado em Slack e Teams e Webhooks.