Cloud Security

Postura de segurança sem agente para as suas contas AWS, por meio de uma role somente leitura. Inventário, avaliação de controles mapeada para os frameworks que você reporta, riscos contextuais que combinam exposição, identidade, dados e vulnerabilidades, caminhos de ataque com o movimento que os quebra, mudanças e drift com o efeito de risco julgado, remediação guiada e relatórios com valor de evidência.

O WASViking^® Cloud Security é a postura de segurança das contas de nuvem que sustentam o seu negócio, lida por meio de uma role que você cria na sua própria conta e mantém sob o seu controle. Nada é instalado, nenhuma access key é compartilhada, e a role só consegue listar e descrever configuração: ela não altera um recurso e não lê os dados dentro dele. A partir dessa visão somente leitura, o módulo monta um inventário, avalia cada recurso contra um catálogo de controles, cruza o resultado com o que o restante da plataforma já sabe sobre a sua exposição, os seus hosts e as suas identidades, e diz o que corrigir primeiro e por quê.

Ele nunca termina em "N achados". Um finding carrega a pontuação com cada ponto nomeado, a confiança que a evidência sustenta, a correção em quatro formas e uma verificação que só o fecha quando a avaliação seguinte prova a mudança. A AWS é o primeiro provedor; o modelo e as telas são neutros em relação ao provedor.

Como funciona

Você conecta uma conta em quatro passos: registra a conta, implanta a role de avaliação com o template que o assistente gera, cola o identificador da role e valida, e opcionalmente liga a avaliação de mudanças em tempo real. O passo a passo está em Configurar o Cloud Security.

Cada conta conectada passa então a ser lida em uma cadência (a cada 24 horas por padrão) e sob demanda:

• Inventário. Identidade (usuários, roles, grupos, policies, access keys), rede (VPCs, subnets, gateways, tabelas de rota, security groups, load balancers, API gateways, CloudFront), computação (instâncias, launch templates, containers, funções Lambda, clusters EKS), armazenamento e dados (S3, RDS, DynamoDB, EFS, snapshots, chaves KMS, secrets), logging e detecção (CloudTrail, Config, GuardDuty, Security Hub) e os serviços de IA (Bedrock, SageMaker). Cada recurso guarda a sua configuração com histórico de versões, as suas tags, o dono, o ambiente e a criticidade, e os relacionamentos que o ligam aos demais.
• Controles. Um catálogo embutido avalia cada tipo de recurso contra as práticas que os frameworks que você reporta esperam, com cada controle mapeado para o AWS Foundational Security Best Practices, o CIS AWS Foundations, o PCI DSS 4.0.1 e o NIST SP 800-53. Um controle passa, falha, não se aplica, ou aparece como Not evaluated com o motivo quando a role não conseguiu ler uma entrada. Not evaluated nunca conta como aprovado.
• Posture findings e riscos contextuais. Um controle que falha vira um finding pontuado pela severidade e pelo contexto: a exposição do recurso, os dados que ele guarda, a identidade com a qual roda, as vulnerabilidades do host por trás dele, quantas joias da coroa ele alcança. Um risco contextual é uma combinação que a plataforma resolve sozinha, como um store com dados pessoais alcançável da internet, uma carga de trabalho alcançável da internet rodando software com vulnerabilidades exploráveis, ou uma porta administrativa aberta em uma carga crítica que fontes hostis já estão sondando.
• Exposição, confirmada de fora. O caminho de rede da internet até cada recurso é resolvido a partir da configuração armazenada (gateway, tabela de rota, subnet, security group, network ACL, endereço). Um caminho que resolve é confirmado pela nuvem; a sonda externa da plataforma e a telemetria de borda do Edge Threat Radar o confirmam então de fora, ou reportam tráfego hostil que já o atinge. Atrás de um network load balancer, é o security group do workload que decide quem passa. Uma porta que o seu security group admite só de origens nomeadas (o endereço de um escritório, uma faixa de VPN) aparece com essas origens e a descrição de cada regra, nunca é contada como aberta para a internet e nunca é sondada; uma porta administrativa liberada assim é um risco baixo de higiene, ou médio quando uma das origens é uma faixa pública ampla. Um recurso com um agente Sentinel Host mostra as vulnerabilidades do host ao lado dos fatos da nuvem.
• Identidade e dados. Cada principal recebe um perfil: o privilégio efetivo, os caminhos de escalada que ele detém (passar uma role a um serviço de computação, reescrever uma policy, assumir qualquer role), a confiança que estende para fora da sua organização, credenciais dormentes e MFA ausente. Cada data store recebe a sua classificação (declarada por tag, inferida do serviço, do nome ou de um relacionamento de log, ou definida à mão), se responde publicamente, a criptografia em repouso e em trânsito, os backups e as identidades que conseguem lê-lo.
• Caminhos de ataque. Cadeias determinísticas sobre o grafo armazenado, de um ponto de entrada até um alvo sensível: internet até dados por uma carga vulnerável, internet até um banco ou bucket público, uma identidade de CI até a administração da conta, uma conta externa até dados, uma função pública até uma role privilegiada, um caminho de secret exposto, um snapshot público, movimento lateral por um security group compartilhado. Cada caminho mostra todos os passos com a evidência por trás, uma confiança, uma pontuação, e as opções de quebra ordenadas por impacto, com uma recomendada.
• Mudanças e drift. Com o tempo real ligado, uma mudança na sua conta é avaliada segundos depois de acontecer: o recurso é relido, os controles que dependem da configuração alterada rodam de novo e a mudança é julgada como risco introduzido, risco removido ou sem mudança de risco, nomeando os findings e os caminhos de ataque que ela criou ou fechou e o ator e a ferramenta que a fizeram (console, API, CloudFormation, uma ferramenta de IaC, um pipeline). Sem o tempo real, cada sincronização agendada registra as mesmas mudanças a partir da diferença do inventário.
• Remediação. Um item de trabalho é montado a partir de um finding (a correção do catálogo em forma de console, CLI, Terraform e CloudFormation, o patch do host quando uma vulnerabilidade participa, e a verificação) ou a partir da opção de quebra de um caminho de ataque. O item passa por To do, In progress e In review; Resolved só é escrito pela avaliação seguinte que prova a correção. Um finding pode ser enviado ao Jira ou ao ServiceNow pela integração de ticketing da plataforma.
• Remediação assistida (opcional). Com uma segunda role separada na sua conta e uma política de governança definida por você, a WASViking aplica por você uma lista curta de correções reversíveis: Block Public Access em um bucket, uma porta de administração ou de banco aberta para o mundo, IMDSv2, uma instância ou um snapshot de banco públicos, uma chave de acesso esquecida, a validação de arquivos de log, a rotação de chave, a recuperação pontual, o scan on push. Cada uma é pedida em um item de trabalho com o que muda e como reverte, decidida por um aprovador (ou pela política, para uma ação de baixo impacto), executada por essa role, verificada pela avaliação seguinte e guardada como um registro de quem pediu, quem decidiu, o que foi lido e o que foi escrito; uma reversão escreve o estado anterior de volta.
• Exceções. Aceitar um risco, registrar uma exceção, um falso positivo ou um controle compensatório é sempre limitado no tempo, exige um aprovador e reabre o finding quando expira.

O que você vê

• Overview: a confiança de cobertura, o anel de Cloud Risk com cada ponto nomeado, a postura por domínio de segurança, a tendência de 30 dias com a velocidade de remediação, o feed de mudanças ao vivo, os riscos de maior prioridade e os cards dos frameworks.
• Accounts & Connectors: cada conta com o seu estado, cobertura, regiões, última sincronização e estado do tempo real; o assistente de conexão.
• Cloud Inventory: cada recurso com filtros por conta, serviço, região, exposição e dados; a página do recurso com a configuração, as versões, o grafo ao redor, o contexto de host e de superfície de ataque, os findings, o caminho de exposição, o perfil de dados, os caminhos de ataque em que ele está e a linha do tempo de mudanças.
• Architecture Map: a topologia das suas contas desenhada a partir do inventário, com exposição, identidade, dados e findings por cima. Veja abaixo.
• Posture Findings: as falhas de controle e os riscos contextuais, com o fluxo de trabalho (dono, estado, SLA), a evidência e a correção.
• Identity & Entitlements, Network Exposure, Data Security: os perfis acima, cada um com os seus filtros e KPIs.
• Compliance: a declaração por framework a partir das avaliações ao vivo, com a exportação.
• Attack Paths: os caminhos, a cadeia em destaque, as opções de quebra.
• Changes & Drift: a linha do tempo julgada, o drift por origem da mudança, as regras de watch salvas e a exportação.
• Policies & Controls: a biblioteca de controles, os policy packs que você habilita e a governança de exceções.
• Remediation: os itens de trabalho e a sua verificação.
• Reports & Evidence: o PDF executivo, as exportações CSV de postura e de inventário, o pacote de evidências e os relatórios agendados.
• Settings: a cadência de reconciliação, a retenção, as chaves de tag que nomeiam dono, ambiente, criticidade e classificação de dados, os sinais nativos a ingerir e as regras de joia da coroa.

O Architecture Map

O Architecture Map desenha o seu ambiente do jeito que você desenharia num quadro: cada conta, as suas regiões, as VPCs dentro delas e as subnets públicas e privadas de cada VPC, com cada serviço no lugar onde roda e as identidades e os serviços globais em faixas próprias. As linhas dizem como as coisas se ligam, em palavras simples: um registro resolve para uma distribuição, uma distribuição encaminha para a sua origem, um load balancer envia tráfego para os seus alvos, uma role está anexada a uma instância, uma role pode ler um bucket, uma chave criptografa um armazenamento, uma web ACL ou um security group protege um recurso. A internet é um nó próprio na frente de cada ponto de entrada considerado alcançável, e uma linha fica vermelha quando a exposição é confirmada de fora ou quando a ligação faz parte de um caminho de risco.

Cada recurso traz um selo com os seus findings abertos: vermelho para crítico, laranja para alto, âmbar para médio, verde quando os controles que se aplicam a ele passaram, cinza quando nenhum controle o avalia ainda. Uma caixa traz o pior risco do que ela contém, então um finding numa route table continua aparecendo na sua VPC. Findings nunca viram nós: ficam no recurso a que se referem.

O modo muda o que o mapa destaca. Topology mostra como os serviços se ligam. Security acrescenta os security groups e coloca a faixa de risco em cada borda. Exposure mantém só o caminho de entrada a partir da internet, da esquerda para a direita, para você ver por onde o tráfego entra e quais workloads o recebem. A chave Critical paths desenha os caminhos de ataque ativos sobre o mapa, e cada caminho leva à página Attack Paths, que o explica e mostra a menor correção que o quebra.

Contas grandes continuam legíveis. Regiões que só têm a rede padrão se juntam num único nó, e muitos recursos de um mesmo tipo viram um grupo só, como "S3 buckets (112)", que mantém os mais arriscados do lado de fora. Dê um duplo clique num grupo ou numa caixa fechada para abri-la e numa caixa aberta para fechá-la; um duplo clique nas subnets públicas ou privadas mostra uma caixa por subnet, agrupadas por availability zone. A busca encontra um recurso por nome, identificador, ARN, endereço IP ou tag e abre o que o contém.

Clique num recurso para ler os detalhes sem sair do mapa: onde ele roda, se é público e alcançável, a criptografia, a role, os security groups, a classe de dados, os findings e as falhas de compliance, o que chega até ele e o que ele alcança, os caminhos de ataque que passam por ele, a evidência de exposição e as mudanças recentes, cada um com um link para a página que tem a história completa. O mesmo painel destaca as relações, o raio de impacto ou o caminho da internet até ele.

Os presets acendem o que responde a uma pergunta: exposição à internet, confiança e privilégio de identidades, caminhos até dados sensíveis, a superfície de ataque crítica, recursos públicos, confiança entre contas, os recursos alterados nas últimas 24 horas e só os findings críticos.

Arraste os nós para organizar o mapa e salve a visualização com o escopo, o modo, as caixas que você abriu e as posições que escolheu; uma visualização salva é compartilhada com a sua organização. Export PNG / SVG baixa o desenho da tela. Ler o mapa exige a permissão de leitura do Cloud Security; exportar exige a permissão de exportação.

Seguro por desenho

• Somente leitura, na sua conta. A role de avaliação carrega a policy gerenciada de auditoria somente leitura da AWS mais um pequeno suplemento de ações de listar e descrever; ela nunca escreve, e nunca lê conteúdo de objetos, valores de secrets, valores de parâmetros, código de funções ou linhas de banco de dados. Você revisa a policy exata antes de criá-la.
• Nenhuma credencial compartilhada. A role confia na conta WASViking com um External ID único gerado para a sua conta, como a orientação da AWS sobre o problema do confused deputy descreve; as sessões são temporárias. Você pode rotacionar o External ID a qualquer momento com uma janela de carência.
• Permissão ausente nunca é silêncio. Uma leitura negada marca o recurso e os seus controles como Not evaluated, reduz a cobertura da conta e aparece no Overview como confiança de cobertura; a página de validação lista as ações exatas a adicionar.
• Nada é chamado de "compliant". O produto reporta controles técnicos aprovados e reprovados em cada framework e deixa o julgamento para o seu avaliador.
• Remover uma conta interrompe as leituras na hora; você apaga a role do seu lado e nada do nosso lado consegue mantê-la.
• Escritas são opcionais, separadas e aprovadas. A role de avaliação nunca escreve. A remediação assistida usa uma segunda role que você cria a partir do próprio template dela, com o seu próprio External ID e uma lista de permissão com apenas as ações que você marcar, cada uma reversível; nada roda sem um pedido e uma aprovação sob a sua política de governança, e cada execução é um registro que você pode reverter.

Planos e papéis

O Cloud Security é ativado por organização pelo seu contato WASViking ou parceiro, com uma franquia de contas conectadas. Ler as telas exige a permissão view no módulo; registrar e validar contas, habilitar policy packs e salvar as configurações exigem manage; o fluxo de remediação exige remediate; aprovar exceções exige approve; as exportações exigem export. Um Admin tem todas elas.

Configuração

Siga Configurar o Cloud Security: registre a conta, implante a role somente leitura a partir do template, cole o identificador da role, valide e deixe a primeira sincronização preencher o Overview. O módulo também tem a sua linha em Ative os seus módulos.