Conectar uma assinatura Azure

Conecte uma assinatura Azure passo a passo. Registre a assinatura, delegue-a à WASViking com a role Reader pelo Azure Lighthouse usando o template ARM, o módulo Terraform, o script da Azure CLI ou os passos do portal gerados, valide, conceda opcionalmente o consentimento somente leitura do diretório e leia os primeiros resultados em palavras do Azure, com as mudanças julgadas a partir do Activity Log.

Este guia conecta uma assinatura Azure ao WASViking^® Cloud Security ao lado das suas contas AWS e dos seus projetos Google Cloud, nas mesmas telas. Ao final, a assinatura é lida por meio de uma delegação que é sua, cada recurso está no inventário e avaliado, as mudanças administrativas são julgadas minutos depois que o Azure as registra, e os primeiros riscos contextuais e caminhos de ataque aparecem na tela em palavras do Azure. Nada aqui cria uma credencial no seu tenant: você delega a assinatura ao tenant da WASViking com a role integrada Reader pelo Azure Lighthouse e remove essa delegação quando quiser.

Antes de começar

O Cloud Security é um módulo adicional, disponível a partir do plano Pro, habilitado por organização pelo seu contato ou parceiro WASViking. O pacote inclui uma conta conectada; uma conta AWS, um projeto Google Cloud e uma assinatura Azure contam como uma cada. Registrar e validar conectores exige a permissão Manage no módulo.

Do lado do Azure você precisa de alguém que tenha Owner na assinatura que está conectando e que seja membro do tenant da assinatura: o Azure Lighthouse recusa uma delegação implantada por uma conta convidada. Essa pessoa implanta o template ARM, aplica o módulo Terraform, executa o script da Azure CLI no Cloud Shell ou segue os passos do portal.

Tenha em mãos o subscription id (o GUID que a página Subscriptions mostra, não o nome de exibição) e o e-mail da equipe dona da assinatura.

A delegação precisa do resource provider Microsoft.ManagedServices registrado na assinatura. O script o registra; com o template ou o módulo, registre-o uma vez em Subscriptions, Resource providers, se a implantação pedir. Os providers dos serviços que você usa ficam como estão: um serviço cujo provider não está registrado aparece como not enabled na validação e os seus recursos simplesmente não são lidos.

Opcional, para o diretório: para ler o Microsoft Entra ID ao lado da assinatura (usuários, grupos, service principals, aplicações, registro de MFA, papéis de diretório, Conditional Access e security defaults), um Global Administrator do tenant concede um consentimento no Passo 3. Todo o resto funciona sem ele.

Passo 1: registre a assinatura

Abra Cloud Security → Accounts & Connectors e clique em Connect account. Escolha o cartão Azure e preencha:

• Account name, como a sua equipe chama a assinatura ("Aplicações de clientes", "Pagamentos produção").
• O Azure subscription id: o GUID, como a página Subscriptions o mostra.
• Environment: Production, Staging, Development, Shared, Security, Sandbox ou Audit. O ambiente pondera o score de risco de cada recurso da assinatura.
• Owner: o e-mail que recebe os avisos de saúde da assinatura.

O campo Delegated role mostra Reader (built-in) e não pode ser alterado: uma delegação do Azure Lighthouse carrega somente roles integradas, e Reader é toda leitura do plano de controle e nenhuma escrita. O painel à direita mostra em que a delegação que você está prestes a criar vai confiar: o tenant da WASViking, o principal delegado WASViking Cloud Security, um External ID gerado somente para este conector, a role e Write access: No. Clique em Register and get the deployment artifacts. A assinatura passa a aparecer na tabela de contas e o assistente pode ser retomado dali a qualquer momento.

Passo 2: delegue a assinatura

A página de implantação oferece quatro maneiras de criar a mesma delegação. As quatro criam dois objetos na sua assinatura: uma registration definition que nomeia o tenant da WASViking e o principal WASViking Cloud Security com a role Reader, e a registration assignment que a aplica. A descrição da definition carrega o External ID deste conector. Nenhuma cria uma credencial e nenhuma concede uma escrita.

• ARM template (recomendado): Download template e implante-o na assinatura, seja com az deployment sub create --location eastus --template-file <file> a partir do diretório que guarda o arquivo, seja pela página Deploy a custom template do portal com Build your own template in the editor. A localização guarda apenas os metadados da implantação; a delegação não tem região.
• Terraform: Download module e aplique-o com uma identidade que tenha Owner na assinatura: envie o arquivo para um diretório vazio e execute ali terraform init e terraform apply. Os ids da definition e da assignment são estáveis, então uma aplicação posterior atualiza a delegação no lugar.
• Azure CLI: Download script e execute-o com bash no Cloud Shell ou em um terminal autenticado no tenant da assinatura. Ele registra o resource provider, cria a definition e a assignment com dois comandos az managedservices e lista a delegação ao final.
• Manual: See the steps: cole o template na implantação personalizada do portal, implante-o na assinatura e confira que Service providers, Delegations lista WASViking Cloud Security com a role Reader e o External ID na sua descrição.

O External ID aparece nesta página para 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. Enquanto a janela está aberta, a página de implantação mostra um bloco Rotation pending com a linha da Azure CLI que atualiza no lugar a descrição da delegação existente; implantar o template de novo, ou aplicar o módulo de novo no diretório da primeira aplicação, faz o mesmo.

Passo 3: valide e conceda o consentimento do diretório (opcional)

Não há nada para colar. Clique em Validate connection: a WASViking lê a assinatura por meio da delegação, encontra a delegação que carrega o External ID deste conector, mede a role que ela concede contra cada leitura de que o inventário precisa, lista os resource providers registrados e descobre as localizações. O resultado mostra:

• a delegação encontrada e a sua role,
• a assinatura confirmada, com o seu tenant,
• o consentimento do diretório, concedido ou não,
• a leitura de identidades, concedida ou não (opcional, veja abaixo),
• as localizações que serão lidas,
• os serviços cujo resource provider não está registrado, se houver (os seus recursos não são lidos; nada a corrigir, a menos que você os use),
• Permission coverage: a fração das leituras que a delegação permite,
• as leituras que faltam, se houver, com um bloco Fix access: o template a implantar de novo quando a delegação nomeia outra role, ou o consentimento a conceder quando falta uma permissão do diretório,
• a duração estimada da primeira sincronização.

Uma validação que falha fica neste passo com o motivo e o que mudar (veja Solução de problemas). Uma validação bem-sucedida marca a assinatura como Healthy, ou Permission gap quando algumas leituras são negadas, e coloca a primeira sincronização completa na fila na hora.

O bloco Directory reads (optional) oferece Grant the directory consent. Um Global Administrator do tenant clica nele, entra na página de consentimento da Microsoft e aceita cinco permissões de aplicação, todas somente leitura: AuditLog.Read.All, Directory.Read.All, Policy.Read.All, RoleManagement.Read.Directory e UserAuthenticationMethod.Read.All. A página volta para o assistente e a próxima validação mostra Directory consent: Granted. Sem o consentimento, os registros do diretório (MFA para administradores e para todos os usuários, autenticação legada, o número de Global Administrators, consentimento de usuário, convites de convidados, contas inativas, credenciais de aplicações) aparecem como Not evaluated com o motivo, nunca como Passed, e todos os demais registros são avaliados normalmente.

Leitura de identidades (opcional)

Uma delegação do Azure Lighthouse nunca mostra as atribuições de role do seu próprio tenant: quem tem qual role na assinatura, incluindo as managed identities das suas cargas de trabalho. Para a WASViking avaliá-las (as identidades das suas cargas de trabalho, quem consegue ler cada repositório de dados e os caminhos de ataque que passam por uma identidade), o bloco Identity reads (optional) do Passo 3 pede mais uma concessão somente leitura, depois do consentimento do diretório:

1. Conceda primeiro o consentimento do diretório: ele registra a aplicação WASViking Cloud Security no seu tenant.
2. Dê a essa aplicação a role nativa Reader na assinatura (no management group quando o conector lê um management group). Rode a linha do Azure CLI que o bloco mostra, no Cloud Shell conectado ao seu tenant, com uma identidade que possa atribuir roles (Owner ou User Access Administrator), ou abra a assinatura no portal do Azure, Access control (IAM), Add role assignment, escolha Reader e selecione WASViking Cloud Security como membro.
3. Clique em Validate again: o resultado mostra Identity reads: Granted e a próxima sincronização lê as atribuições de role do seu tenant.

A role é somente leitura e aparece na sua página de Access control como qualquer outra atribuição. O bloco também mostra a linha que a remove; sem ela todo o resto funciona e os registros de identidade ficam apenas com a visão da delegação.

Passo 4: mudanças em tempo real

Nada a implantar. A WASViking lê o Activity Log da assinatura a cada minuto pela mesma delegação, então uma mudança administrativa vira uma linha de mudança julgada minutos depois que o Azure a registra, em vez de esperar a próxima sincronização completa. O Azure grava um evento de três a vinte minutos depois da operação; a linha de mudança guarda o horário da operação, quem chamou (uma pessoa pelo nome de login, uma aplicação pelo nome quando o inventário a conhece, uma managed identity pela sua carga de trabalho), o endereço do cliente e onde a mudança foi feita (o portal do Azure, a linha de comando, um pipeline). Somente a categoria administrativa é lida, e os corpos de requisição e resposta de um evento nunca são guardados.

O passo mostra um estado em vez de um interruptor: Waiting for events até a primeira mudança chegar, Receiving events com o horário da última 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 conector. As mudanças que a sincronização completa encontra entre duas leituras nomeiam o seu autor pelo mesmo log.

A remediação assistida (o Passo 5 na AWS e no Google Cloud) não é oferecida em um conector Azure: cada achado traz o seu plano guiado em quatro formas (passos do portal, Azure CLI, Terraform e a definição do Azure Policy que impede o estado, com o seu id integrado quando existe) e você o aplica.

A primeira sincronização

A tabela de contas mostra a sincronização avançando por coletor (a assinatura e os seus resource groups, role assignments e roles personalizadas, managed identities, o diretório Entra e os seus principals quando consentido, redes virtuais, network security groups, interfaces e endereços públicos, load balancers e application gateways, firewalls, Bastion, gateways, private endpoints, route tables e NAT gateways, Network Watcher e flow logs, zonas DNS, máquinas virtuais e scale sets, AKS, Container Registry, App Service, discos gerenciados e snapshots, storage accounts, key vaults, Azure SQL, os servidores flexíveis PostgreSQL e MySQL, Cosmos DB, Azure Cache for Redis, Event Hubs, Service Bus, a exportação e os alertas do Activity Log, Log Analytics, Microsoft Defender for Cloud, Azure Policy, Azure AI services e Azure Machine Learning). A Overview fica no estado de "first sync running" até a avaliação terminar e então mostra o anel do Cloud Risk com cada ponto nomeado, a postura por domínio e os primeiros achados. Os controles de uma assinatura Azure são referenciados ao CIS Microsoft Azure Foundations Benchmark v3.0.0, ao PCI DSS 4.0.1 e ao NIST SP 800-53; a página Compliance mostra o cartão CIS Microsoft Azure da assinatura.

O que olhar em seguida:

1. Overview: o banner de confiança da cobertura (se estiver abaixo de 100 por cento, abra as lacunas e aplique o bloco Fix access), a principal combinação tóxica e os riscos de maior prioridade.
2. Posture Findings: comece pela aba Contextual risks; cada um nomeia os componentes da combinação e como quebrá-la. A aba Control failures filtrada pela assinatura lista cada controle que falha com a sua referência CIS Microsoft Azure.
3. Attack Paths: a cadeia em destaque e a sua opção de quebra recomendada, escrita em palavras do Azure (acesso anônimo a blobs, as regras de firewall de um servidor SQL, a managed identity com que um app público roda, a role assignment a estreitar).
4. Cloud Inventory: abra qualquer recurso para ler a sua configuração, o grafo ao redor e o seu caminho de exposição (o endereço público, a interface de rede e os network security groups da sub-rede e da interface que admitem a internet até ele).
5. Architecture Map: a assinatura desenhada com as suas redes virtuais, as suas sub-redes e as máquinas colocadas na sub-rede da sua interface.

Lendo todas as assinaturas de um management group

Um conector pode ler todas as assinaturas de um management group. No Passo 1, preencha Management group scope com o id do management group (o identificador, não o nome de exibição; por exemplo mg-platform) e registre uma assinatura dele como a central. O Azure Lighthouse delega assinaturas, nunca um management group, então os artefatos do Passo 2 atribuem no management group a Azure Policy que a Microsoft documenta para isso: ela implanta a delegação deste conector (a mesma role Reader, o mesmo External ID) em cada assinatura do management group, as existentes por uma tarefa de remediação e as novas conforme chegam.

• Registre antes o resource provider Microsoft.ManagedServices nas assinaturas; o script faz isso em cada assinatura habilitada do tenant que você enxerga.
• Implante o template no management group (az deployment mg create, ou a implantação personalizada do portal no escopo do management group) com uma identidade que tenha Owner ali. Ele cria a definição da policy, a sua atribuição com uma managed identity atribuída pelo sistema e Owner para essa identidade no management group: a policy precisa disso para criar as delegações. Essa identidade é sua, no seu tenant; a WASViking nunca a vê.
• O Azure Policy avalia uma atribuição nova em cerca de trinta minutos. Depois, delegue as assinaturas existentes: execute o script de novo com REMEDIATE=1, ou abra Policy, Remediation e remedeie a atribuição. O módulo Terraform cria a tarefa de remediação sozinho.

Depois da primeira sincronização da assinatura central, cada assinatura delegada com este External ID aparece na tabela de contas como um conector próprio, marcado como Discovered subscription. Ela não precisa de nada implantado: se valida assim que é descoberta e roda a primeira sincronização logo em seguida. Uma rotação do External ID do conector central leva junto cada assinatura descoberta; o bloco Rotation pending traz a linha que atualiza as delegações já feitas. Uma assinatura já delegada à WASViking por outro conector continua com esse conector.

Dia dois

• Settings: a tag data-classification em uma storage account, um banco de dados ou um key vault declara a sua classificação (pii, pci, phi, secrets, internal), a tag public-by-design em uma máquina ou em um site do App Service declara que ele responde à internet de propósito, e as chaves de tag de dono, ambiente e criticidade são as que você define ali, como na AWS.
• Identity: cada principal que tem uma role assignment na assinatura é perfilado (pessoas, grupos, aplicações e managed identities), nomeado pela sua entrada no diretório quando o consentimento é concedido, com os caminhos de escalonamento que as suas roles abrem (Owner, User Access Administrator, Managed Identity Operator, uma role personalizada que escreve role assignments, um administrador do diretório).
• Native signals: os planos do Microsoft Defender for Cloud, o secure score, as avaliações não saudáveis e os contatos de segurança, e as atribuições do Azure Policy (a iniciativa Microsoft cloud security benchmark, uma política de localizações permitidas), contam para os controles de detecção e de guardrail. Todos são lidos pela Reader.
• Policies & Controls: os pacotes de políticas valem para todos os provedores; a biblioteca de controles lista os controles Azure com as suas referências CIS; as exceções têm prazo e precisam de um aprovador.
• Reports & Evidence: o PDF executivo, as exportações de postura e de inventário e o pacote de evidências incluem a assinatura Azure ao lado das contas AWS e dos projetos Google Cloud.
• Permission baseline: a Reader carrega toda leitura do plano de controle, então uma verificação nova raramente pede algo a você; quando a WASViking acrescenta uma permissão do diretório, a validação a lista e o consentimento é concedido de novo no Passo 3.
• More subscriptions: um conector é uma assinatura; repita os passos por assinatura, ou limite um conector a um management group (acima). O template e o módulo recebem o subscription id e o External ID, então uma segunda assinatura é uma segunda implantação.

Solução de problemas

Removendo uma assinatura

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 excluídos definida em Settings para que os relatórios continuem reproduzíveis, e depois são apagados. Do seu lado, exclua a delegação em Service providers, Delegations (ou destrua o módulo Terraform), remova a role Reader da aplicação WASViking Cloud Security se você concedeu a leitura de identidades e, se você concedeu o consentimento do diretório, exclua a aplicação WASViking Cloud Security em Enterprise applications; nada do lado da WASViking pode mantê-los.