Configurar o Cloud Security

Conecte a sua primeira conta AWS passo a passo. Registre a conta, implante a role de avaliação somente leitura a partir do template gerado, valide as permissões, escolha se as mudanças serão avaliadas em tempo real e leia os primeiros resultados.

Este guia leva você de um módulo vazio a um ambiente de nuvem pontuado: ao final, você terá uma conta AWS conectada por meio de uma role que é sua, um inventário com cada recurso avaliado, uma pontuação de Cloud Risk com os fatores visíveis e os primeiros riscos contextuais e caminhos de ataque na tela. Nada aqui instala software ou compartilha uma credencial: você cria uma role somente leitura na sua conta e a WASViking a assume com sessões temporárias.

Antes de começar

O Cloud Security é um módulo adicional ativado por organização pelo seu contato WASViking ou parceiro. Com ele ligado, a seção Cloud Security aparece na barra lateral do portal. Registrar e validar contas exige a permissão Manage no módulo. Do lado da AWS, você precisa de alguém que consiga criar uma role IAM na conta que está conectando (por CloudFormation, Terraform ou pelo console) e, para uma AWS Organization, de acesso à conta de gerenciamento ou a um administrador delegado, caso pretenda implantar a role em muitas contas de uma vez.

Tenha à mão o id da conta AWS (12 dígitos) e o e-mail do time dono da conta.

Passo 1: registre a conta

Abra Cloud Security → Accounts & Connectors e clique em Connect AWS. Preencha:

• Account name, como o seu time chama a conta ("Production", "Payments shared services").
• O AWS account id (12 dígitos).
• Environment: Production, Staging, Development, Shared, Security, Sandbox ou Audit. O ambiente pesa na pontuação de risco de cada recurso da conta, então escolha o que corresponde ao que roda ali.
• Owner: o e-mail que recebe os avisos de saúde da conta.

O painel à direita mostra em que a role que você vai criar confiará: a conta AWS da WASViking, um External ID gerado só para esta conta, o nome da role (WASVikingCloudSecurityRole, que você pode renomear) e Write access: No. Clique em Register and get the deployment artifacts. A conta agora existe como Pending role e o assistente pode ser retomado pela tabela de contas a qualquer momento.

Passo 2: implante a role de avaliação

A página de implantação oferece três formas de criar a mesma role. Escolha a que o seu processo de mudança permite:

• CloudFormation (recomendado): Download template e crie uma stack com ele na conta, em qualquer região. O template cria a role com a trust policy (o seu External ID incluído) e anexa a policy gerenciada de auditoria somente leitura da AWS mais o pequeno suplemento de ações de listar e descrever de que o inventário precisa. Nada nele consegue escrever. Para uma AWS Organization, implante o mesmo template como StackSet nas unidades organizacionais que quiser; uma role por conta-membro.
• Terraform: Download module e aplique a partir do seu repositório de IaC. O nome da role, a conta WASViking e o External ID são variáveis já preenchidas.
• Manual: siga a lista de passos da página (criar a role, colar a trust policy com o External ID, anexar as duas policies).

O External ID é mostrado nesta página aos membros com a permissão Manage, com um botão de copiar; ele nunca aparece em listas, notificações ou exportações. Se algum dia vazar, Rotate External ID emite um novo e mantém o anterior válido por 24 horas, para que você atualize a trust policy sem interrupção.

Quando a stack terminar, o console abre a aba Stack info. O Stack ID mostrado ali é um identificador do CloudFormation, não o valor de que você precisa. Abra a aba Outputs da stack e copie o valor de RoleArn: ele tem a forma arn:aws:iam::<account id>:role/WASVikingCloudSecurityRole. Com Terraform, o apply imprime o mesmo valor como output; nos passos manuais, copie o ARN da página de resumo da role no IAM.

Passo 3: cole o ARN da role e valide

De volta à página de implantação, cole o ARN no campo Role ARN e clique em Validate connection. A validação assume a role, confere que a identidade pertence à conta registrada, descobre as regiões habilitadas e simula cada leitura que o inventário faz. O resultado mostra:

• a role assumida e o id da conta conferido,
• as regiões que serão varridas (regiões opt-in que você não habilitou aparecem como inativas e nunca são chamadas),
• Permission coverage: a fração das leituras que a role consegue fazer,
• as ações ausentes, se houver, com um trecho Fix access que você pode anexar à role para chegar a 100 por cento,
• a duração estimada da primeira sincronização.

Uma validação que falha permanece neste passo com o motivo e o que mudar (veja Solução de problemas). Uma validação bem-sucedida marca a conta como Healthy, ou Permission gap quando algumas leituras são negadas, e enfileira a primeira sincronização completa na hora. Os dois estados são sincronizados; uma lacuna só significa que alguns controles aparecem como Not evaluated até você adicionar as ações.

Passo 4: habilite a avaliação em tempo real (opcional)

Sem este passo, a conta é lida a cada 24 horas (configurável em Settings) e cada mudança é registrada a partir da diferença entre duas sincronizações. Com ele, uma mudança na sua conta é avaliada segundos depois de acontecer e julgada como risco introduzido, removido ou nenhum, com o ator e a ferramenta que a fizeram.

Clique em Download events template e crie essa segunda stack em cada região que quiser cobrir. Ela cria uma regra do EventBridge para os serviços que o módulo avalia e a pequena role de que a regra precisa para entregar os eventos à WASViking; ela envia apenas eventos de configuração, nunca dados. O passo mostra um estado, não um interruptor: Waiting for events até o primeiro chegar, Receiving events com o horário do último depois disso, ou Paused quando a organização desligou a avaliação em tempo real em Settings. A tabela de contas mostra Periodic, Receiving ou Paused para cada conta.

Passo 5: permita a remediação assistida (opcional)

Todo finding vem com um plano guiado que você mesmo aplica. O Passo 5 deixa a WASViking aplicar por você uma lista curta de correções, cada uma uma mudança de configuração reversível (ligar o Block Public Access em um bucket, fechar uma porta de administração ou de banco de dados aberta para o mundo, exigir IMDSv2 em uma instância, tornar privada uma instância de banco ou um snapshot, desativar uma chave de acesso esquecida, habilitar a validação de arquivos de log, a rotação de chave, a recuperação pontual ou o scan on push). Nada roda sem um pedido em um item de trabalho e uma aprovação sob a política de governança que você define.

O passo cria uma segunda role na sua conta, separada da role de avaliação somente leitura, com o seu próprio External ID e uma policy que permite apenas as ações que você marcar. Marque-as, clique em Enable assisted remediation, baixe o template da role de remediação, crie essa stack, cole o identificador da role e clique em Validate remediation role; o passo mostra Ready quando a role foi assumida com o seu External ID e responde por esta conta. Mudar a lista depois pede que você atualize a stack e valide de novo; Disable assisted remediation esquece a role do nosso lado, e você a apaga na AWS.

Depois abra Settings, ligue Assisted remediation governance, escolha se toda ação precisa de um aprovador ou só as de alto impacto, mantenha a regra de que quem pede nunca aprova o próprio pedido, e marque as ações e os ambientes que você permite. Em um item de trabalho, o bloco Assisted actions lista o que se aplica ao recurso dele com o que muda e como reverte; Request this action cria um registro que um aprovador decide na mesma página (Approve and run ou Reject com uma nota), e os canais dos aprovadores recebem o pedido quando assinaram o evento. O registro guarda quem pediu, quem decidiu, o que foi lido antes da mudança e o que foi escrito; Roll back escreve o estado anterior de volta. O próximo passe de pontuação verifica o item como qualquer correção feita à mão.

A primeira sincronização

A tabela de contas mostra a sincronização avançando por etapa de coleta (identidade, rede, computação, armazenamento e dados, logging e detecção, serviços de IA), com o número de recursos vistos. O Overview permanece no estado "first sync running" até a avaliação terminar, e então mostra o anel de Cloud Risk com cada ponto nomeado, a postura por domínio e os primeiros findings. A primeira sincronização de uma conta de porte médio leva alguns minutos; a página de validação informou a estimativa.

O que olhar em seguida:

1. Overview: a faixa de confiança de cobertura (se abaixo de 100 por cento, abra as lacunas e anexe o trecho Fix access), a combinação tóxica principal e os riscos de maior prioridade.
2. Posture Findings: comece pela aba Contextual risks; cada uma nomeia os componentes da combinação e como quebrá-la.
3. Attack Paths: a cadeia em destaque e a opção de quebra recomendada; Open remediation plan a transforma em um item de trabalho.
4. Cloud Inventory: abra qualquer recurso para ler a configuração, o grafo ao redor, o contexto de host e de superfície de ataque e o caminho de exposição.

Segundo dia

• Settings: diga ao módulo quais chaves de tag nomeiam o dono, o ambiente, a criticidade e a classificação de dados dos seus recursos; declare as regras de joia da coroa; escolha os sinais nativos a ingerir e a retenção de recursos apagados.
• Policies & Controls: habilite os policy packs que combinam com a conta (a linha de base enterprise está sempre ligada); solicite, aprove e revogue exceções; toda exceção é limitada no tempo e reabre o finding quando expira.
• Data Security: defina à mão a classificação de um store que a inferência errou; o valor manual sobrevive a toda sincronização posterior.
• Reports & Evidence: baixe o PDF executivo, as exportações CSV de postura e de inventário ou o pacote de evidências, e agende o relatório semanal ou mensal para os membros que precisam dele.
• Canais de notificação: os eventos do Cloud Security (novo finding crítico ou alto, exceção solicitada ou expirada, caminho de ataque criado) podem ser roteados para Slack, Teams, e-mail ou um webhook como qualquer outro alerta. Habilite-os por canal seguindo Notification Channels.
• Ticketing: um finding pode ser enviado ao Jira ou ao ServiceNow a partir da sua página, uma vez conectada a integração da plataforma.
• Mais contas: repita os quatro passos por conta ou, em uma AWS Organization, implante o StackSet uma vez e registre as contas conforme aparecem.

Solução de problemas

Removendo uma conta

Remove na tabela de contas interrompe as leituras na hora. O inventário e as evidências são mantidos pela janela de retenção de recursos apagados definida em Settings, para que os relatórios continuem reproduzíveis, e depois são expurgados. Apague a stack (ou a role) do seu lado quando terminar; nada do lado da WASViking consegue apagá-la por você.