Descoberta e mapas

Tela: Estrutura organizacional

A estrutura organizacional guarda duas árvores que agrupam tudo no Hive: Locais (Empresa ›Localidade › Prédio › Andar › Sala) e Departamentos (por exemplo Diretoria › Financeiro › Contas a pagar, com centro de custo). As máquinas se encaixam sozinhas, e a estrutura é usada pelo mapa físico, pelos alvos das implantações e para definir quem vê cada item na Loja. Fica em Descoberta ›Estrutura.

Criar a empresa e as localidades com Nova empresa ou localidade, e montar a árvore com Adicionar dentro.

Criar departamentos com Novo departamento, ligados a nomes do diretório e a OUs.

Editar um nó (nome, código, dentro de onde ele fica, tags de vínculo) ou Remover.

Alternar entre Lista e Mapa para ver a árvore.

Ver quantas máquinas há em cada nó (Máquinas, com "n direto") e abri-las no inventário.

Uma localidade também vira o site usado nas implantações para fuso, janela de manutenção e ponto de distribuição, e os sites que já existiam aparecem como nós da árvore.

Local, da regra mais forte para a mais fraca:

Departamento: o departamento do usuário principal da máquina no diretório (o nome do departamento ou um dos Nomes no diretório); senão, o departamento cujas OUs batem com o caminho da OU da conta de computador.

Uma escolha feita à mão na máquina (painel Onde fica › Trocar) vale mais que qualquer regra; Automático (pelas regras) volta para as regras. A máquina herda as tags Empresa , Localidade , Prédio , Andar , Sala e Departamento com os nomes do caminho; quando ela muda de rack, porta, rede ou usuário, elas mudam sozinhas. A estrutura é aplicada quando uma varredura termina, quando o agente manda inventário, a cada 10 minutos e sempre que a árvore muda.

Exemplo prático: localidade "São Paulo HQ" com dois andares e a sub-rede

São Paulo HQ continua contando-as, agora com "(n direto)" para as que estão só na localidade. 7. Um notebook que é do Andar 1 mas foi instalado com o token errado: abra-o, painel Onde fica, Trocar, escolha Andar 1 . Agora ele mostra "escolhido à mão".

Implantações, patches e playbooks: escolha um nó e todas as máquinas da subárvore entram.

Loja: quem vê cada item.

Mapa físico: as máquinas agrupadas pelo caminho do local.

Racks: cada rack fica numa sala, andar ou prédio.

Inventário: os filtros Local e Departamento incluem a subárvore.

Criar, editar e remover nós exige assets:write .

Remover apaga também tudo o que está dentro; as máquinas voltam às regras automáticas.

Os nomes são únicos entre irmãos ("There is already a location with this name here.").

Uma tag tem até 200 caracteres.

Só os locais têm tags de vínculo; os departamentos usam nomes do diretório e OUs.

Tags e grupos

Descoberta

Mapa de rede

Implantações

Inventário

Tela: Área de Descoberta (1/3)

Tela: Área de Descoberta (2/3)

Tela: Área de Descoberta (3/3)

Em Descoberta › Descoberta você varre redes a partir de um coletor para achar o que não tem agente: estações, servidores, impressoras, câmeras, telefones e equipamentos de rede. Cada varredura diz quais faixas, métodos, credenciais, coletor, intensidade, tags e agendamento usa; cada execução mostra o que é novo, o que mudou, o que sumiu e o que continua sem agente. Senhas, chaves e comunidades SNMP ficam no Cofre de credenciais (Integrações › Credenciais, também uma aba da Descoberta). Nada abre da internet para dentro: o coletor só faz chamadas de saída. Criar e rodar varreduras pede Administrar agentes.

Varreduras: ver cada varredura com escopo, métodos, última execução (responderam, novos, sem agente) e próxima execução; Rodar agora, Editar ou remover.

Nova varredura: o assistente de sete passos com uma estimativa antes de salvar.

Cofre de credenciais: criar, editar, testar e remover credenciais de WinRM, SSH e SNMP; ver quantas varreduras usam cada uma.

Tela da execução: acompanhar uma execução ao vivo, comparar com a anterior, ler os erros e instalar o agente nas máquinas Windows achadas sem ele.

No detalhe do ativo, Descoberto por mostra qual método, coletor e varredura trouxe cada dado.

Escopo. Marque Redes conhecidas (as cadastradas e as vistas pelos agentes, com a contagem de ativos) ou acrescente Outras faixas como rede (CIDR, como 10.20.0.0/24 ) ou De/Até. Em Exclusões,

tire faixas sensíveis como automação industrial (OT) ou equipamentos médicos. Até 65.536 endereços por varredura.

Métodos. Ligue o que esta varredura usa: ICMP (ping), ARP (MAC na mesma rede), portas TCP comuns (30 portas), certificados TLS, NetBIOS (nome do Windows), mDNS / SSDP (impressoras, TVs, IoT), WMI / WinRM (inventário do Windows sem agente, inclusive Windows 2008 R2), SSH (Linux, Unix e appliances), SNMP v1/v2c/v3 (switches, roteadores, impressoras: portas, VLANs e a tabela de MACs), LLDP e CDP (vizinhos, lidos por SNMP). NetFlow / sFlow / IPFIX não é método de varredura: o coletor recebe fluxos o tempo todo.

Credenciais. Para cada método com credencial (WinRM, SSH, SNMP), marque uma ou mais credenciais do cofre ou crie uma Nova credencial ali mesmo. A senha fica no cofre e só vai ao coletor junto com a tarefa.

Coletor e intensidade. Escolha o coletor dentro da rede e a intensidade: Leve (50 pacotes/s, 32 de cada vez), Normal (200 pacotes/s, 128 de cada vez) ou Rápida (1000 pacotes/s, 256 de cada vez, pede confirmação). A varredura pausa sozinha se a rede ficar lenta. Se quiser, Rodar só nesta janela de horário (por exemplo das 22:00 às 06:00).

Tags de origem. Todo ativo achado recebe a tag Descoberto por: <método> · <coletor> · <varredura> (sempre com este nome, em qualquer idioma) e as tags que você incluir aqui (tecle Enter depois de cada uma).

Agendamento.Só quando eu pedir, Todo dia ou Alguns dias da semana, num horário do seu fuso. Rodar agora, depois de salvar começa a primeira execução na hora.

Revisão. Dê o Nome da varredura e confira a estimativa: endereços, duração estimada e carga na rede, com avisos para intensidade rápida, credenciais e escopos grandes. Depois, Salvar varredura.

Em Integrações › Credenciais, Nova credencial pede um Nome, o Tipo e:

WMI / WinRM: usuário como DOMÍNIO\usuário ou usuário@domínio , senha, Transporte do WinRM HTTPS (5986) ou HTTP (5985).

SSH: usuário, senha e a porta, se não for a 22.

SNMP: a versão — v1 ou v2c com a Comunidade, ou v3 com o Usuário SNMP v3, o Nível de segurança (authPriv, authNoPriv ou noAuthNoPriv), o Protocolo de autenticação (SHA-1 a SHA-512, ou MD5) e a senha, e o Protocolo de privacidade (AES-128, AES-192, AES-256 ou DES) e a senha (em branco usa a senha de autenticação).

Só nestas redes (opcional): limita onde a credencial pode ser usada, como 10.20.0.0/16 .

Testar roda por um coletor contra uma máquina em três etapas — Alcançar a porta, Entrar, Coletar— e mostra o que o método traz (sistema, nome da máquina, programas, serviços). Editar uma credencial atualiza todas as varreduras que a usam; o segredo nunca volta a ser exibido.

A página da execução mostra o estado (Esperando o coletor, Rodando, Concluída, Falhou, Cancelada), o andamento em endereços e os números Responderam, Novos, Alterados, Desaparecidos (vistos na execução anterior e não nesta), Sem agente e Pausas (rede lenta). As abas listam os aparelhos de cada tipo com IP, nome, MAC, fabricante, sistema, tipo, métodos e portas abertas, e Erros explica cada falha (credencial recusada, porta fechada). Em Sem agente, selecione máquinas Windows e clique em Instalar agente: o coletor da varredura instala por WinRM com uma credencial do cofre. Cancelar execução para a execução; Execuções lista o histórico.

Um aparelho achado por uma varredura entra no inventário pela mesma conciliação do agente. Do mais confiável para o menos:

Tabelas ARP e DNS que ninguém limpa guardam MACs e IPs de aparelhos que já saíram, então o Hive as trata com cuidado: um MAC de ARP ambíguo nunca une dois registros, um MAC de ARP que jápertence a outro aparelho não é copiado, e os nomes vêm só do que o aparelho informa (sem DNS reverso). Quando um IP passa a responder por um aparelho, ele sai dos outros registros sem agente que ainda o guardavam. Se a máquina já tem agente, a descoberta só registra que a viu.

Exemplo prático: varredura semanal de 10.10.0.0/16 com SNMP v3, SSH e WinRM

Domingo de manhã, abra a última execução da varredura em Varreduras (clique na entrada em Última execução).

Dois notebooks já compartilham o MAC 00:1a:2b:3c:4d:5e no inventário (um adaptador de rede USB antigo). A varredura vê 10.10.8.12 só com esse MAC, vindo da tabela ARP. O Hive não escolhe um dos dois: o aparelho entra como ativo novo pelo IP, e o MAC não é copiado para ele.

WS-0231 (Windows sem agente, lido por WinRM) recebeu 10.10.4.20 por DHCP; esse IP ainda estava no registro de WS-0198 , também sem agente. A varredura casa WS-0231 pelo número de série, acrescenta 10.10.4.20 a ele e tira o IP de WS-0198 . Se WS-0198 tivesse agente, os endereços dele ficariam como estão.

Até 65.536 endereços por varredura; divida escopos maiores. As exclusões não podem tirar todos os endereços.

Uma varredura não começa de novo enquanto a execução anterior ainda está esperando ou rodando.

Rápida pode deixar a rede lenta e pede confirmação; prefira Normal com uma janela de horário.

Sem um coletor online não há o que escolher no passo 4: instale um antes.

Os nomes das varreduras são únicos (até 80 caracteres).

A instalação a partir de uma execução pega até 500 máquinas por vez e só máquinas Windows ainda sem agente.

Remover uma varredura remove o histórico dela; os ativos que ela achou continuam no inventário.

Rede e topologia

Distribuir o agente

Passo a passo: criar um coletor

Agentes e coletores

Tela: Rede e topologia

Mapas › Mapa de rede mostra a rede como o Hive a lê: switches, roteadores e impressoras lidos por SNMP, as ligações entre eles achadas por LLDP e CDP, qual aparelho está ligado em cada porta (pela tabela de MACs do switch), o tráfego de cada porta e os racks e salas. Tem três abas: Mapa físico, Portas e Racks. Os dados vêm de varreduras da descoberta com SNMP ligado; os fluxos (NetFlow, sFlow, IPFIX) e as conexões informadas pelos próprios agentes acrescentam o tráfego entre as máquinas.

Mapa físico: ver o mapa de conexões da internet até cada máquina, filtrar por Local, Destacar VLAN e clicar em qualquer elemento para acender o caminho dele até a internet.

Portas: escolher um equipamento e ver o painel frontal do switch, cada porta com estado, velocidade, VLAN, vizinho, aparelhos conectados, tráfego em Mb/s e o uso do link nas últimas 24 horas.

Racks: criar racks com sala, unidades e lugar na estrutura, e ver quantos aparelhos cada um tem.

Em cada ativo (aba Hardware, Rede física): a porta em que está ligado, o histórico de portas, o rack e a unidade, o caminho até a internet e o mapa de dependências.

Crie uma credencial SNMP em Integrações › Credenciais (comunidade para v1/v2c, ou usuário, autenticação e privacidade para v3) e ligue SNMP, LLDP e CDP numa varredura com essa credencial.

A cada leitura, o coletor traz as portas (estado, velocidade, VLAN), os nomes das VLANs, a tabela de MACs e os vizinhos LLDP/CDP. Um aparelho é posto numa porta pela tabela de MACs, ignorando os uplinks (portas com vizinho ou com mais de 8 MACs). Ele passa a ter as tags Switch: <switch> e Porta: <switch> · <porta> ; quando muda de porta, as tags mudam sozinhas e a mudança vai para o histórico de portas.

O Mapa de conexões é uma árvore: a internet no topo, cada switch pendurado no seu uplink (o vizinho LLDP/CDP mais rápido), as máquinas na porta em que estão ligadas (com porta e VLAN) e as VMs tracejadas abaixo do host. Linha grossa é um link agregado (LAG ×N com a velocidade somada); tracejada é um link desligado ou virtual; vermelha tem erros; vizinhos que o Hive ainda não lê ficam agrupados à parte. Pontos em movimento mostram o tráfego em direção à internet. Os aparelhos são agrupados pelo lugar na estrutura; Local mostra só aquele lugar, o que está abaixo dele e o caminho até a saída, e os aparelhos cujas portas têm erros novos desde a última leitura ficam destacados. Destacar VLAN apaga todo aparelho que não leva a VLAN escolhida.

Em Portas, escolha o Equipamento. O Painel frontal do switch desenha as portas como no aparelho: verde ligada, cinza desligada, laranja com erros novos e borda azul no uplink; passe o mouse para ver porta, velocidade, VLAN e quem está conectado. Abaixo, cada porta mostra o estado, o vizinho, os aparelhos ligados nela e o Tráfego (↓ entrada · ↑ saída em Mb/s e % do link), calculado comparando os contadores de bytes de duas leituras SNMP. Clicar na taxa abre Uso do link nasúltimas 24 h (contadores SNMP).

Em Racks, Novo rack pede o nome, a Sala, as Unidades (U) (1 a 60, padrão 42) e o Lugar na estrutura (sala, andar ou prédio). Num aparelho (aba Hardware, Rede física), escolha o Rack e a Unidade: ele herda as tags Rack: <rack> e Sala: <sala> . Implantações, patches e playbooks podem mirar um switch, um rack ou uma sala por essas tags.

O coletor sempre escuta fluxos: aponte switches, roteadores e firewalls para o IP dele — NetFlow v5/v9 e IPFIX na UDP 2055, sFlow v5 na UDP 6343 (cada amostra conta o tamanho do quadro × a taxa de amostragem). Os agentes também informam as conexões da própria máquina (quem falou com quem, em qual porta), sem nada para configurar no switch; quando as duas pontas têm agente, só o lado servidor conta, então nada é contado em dobro. Os fluxos são somados por minuto e alimentam o mapa lógico e o caminho do serviço.

Exemplo prático: achar onde um notebook está ligado e seguir o caminho dele

Exemplo prático: um rack para o 3º andar e o tráfego de um uplink

Nada aparece até uma varredura ler pelo menos um equipamento por SNMP ("Nenhum equipamento de rede lido por SNMP ainda.").

O tráfego precisa de duas leituras SNMP para calcular uma taxa; a primeira leitura só mostra contadores.

Uma porta com mais de 8 MACs ou com vizinho é tratada como uplink e não posiciona aparelhos.

O último salto do caminho pode ser um vizinho que o Hive ainda não lê: inclua-o numa varredura com SNMP para ir mais longe.

Os nomes das tags Porta e Sala são fixos, seja qual for o idioma do console.

No Mapa físico, os botões Rede, Virtualização e Kubernetes acrescentam camadas à árvore (a escolha fica guardada): switch → porta → host do hipervisor (ESXi, Hyper-V, Proxmox ou Nutanix, pela máquina do inventário do host) → as VMs dele → os nós do Kubernetes que rodam nessas VMs. Clicar num host abre a visão do hipervisor; clicar num nó abre o cluster. Host, VM ou nó sem porta de switch conhecida vai para o grupo Sem porta de switch conhecida, nunca para baixo de um switch qualquer. O atalho Mapas › Virtualização abre /network?layers=virt ; /network?layers=k8s abre a camada do Kubernetes.

Área de Descoberta

Caminho do serviço e mapa lógico

Estrutura organizacional

Passo a passo: criar um coletor

Tela: IPAM, DNS e DHCP

Mapas › Mapa físico, aba IPAM, mostra as suas sub-redes e o uso de cada endereço. "Em uso" vem do que o Hive já vê — os IPs dos ativos, as varreduras da descoberta dos últimos 30 dias e as concessões de DHCP ativas — e "reservado" das reservas feitas à mão (pela API) ou importadas do DHCP. Zonas de DNS e escopos e concessões de DHCP são importados de arquivos (BIND, Windows, ISC, Kea). O IPAM só lê: nunca cria nem junta ativos.

Sub-redes: adicione uma sub-rede à mão com Adicionar sub-rede ou clique em Achar sub- redes (faixas da descoberta, escopos de DHCP importados e as redes /24 com pelo menos 2 IPs de ativos). Cada sub-rede mostra a barra de ocupação, os endereços em uso, reservados e livres e quando um endereço foi visto por último. Clique na sub-rede para ver a grade de endereços (até /22) e a tabela com MAC, nome, ativo e origem.

Conflitos: o mesmo IP visto com MACs diferentes nos últimos 7 dias (varreduras e DHCP), o mesmo IP reservado mais de uma vez (à mão e num servidor DHCP, ou em dois servidores) e um MAC reservado em dois endereços.

DNS: importe uma zona e veja Velho: sem máquina viva (registro A cujo endereço não foi visto em 7 dias) e Reverso não bate (o PTR do endereço aponta para outro nome).

DHCP: importe escopos e concessões e veja, em cada concessão, o ativo que tem aquele MAC.

Arquivo de zona do BIND: cole ou escolha o arquivo da zona ( $ORIGIN , $TTL , nomes relativos e SOA em várias linhas são entendidos).

DNS do Windows: Get-DnsServerResourceRecord -ZoneName corp.local exportado com as colunas HostName , RecordType , RecordData e TimeToLive ( Export-Csv ).

ISC: dhcpd.leases (vale a última entrada de cada endereço) e, no mesmo conteúdo, o dhcpd.conf com os escopos subnet … netmask … { range … } .

| Get-DhcpServerv4Lease | Export-Csv para as concessões; as reservas ( ActiveReservation ) viram reservas daquele servidor.

Abra Importar uma zona de DNS (em DNS) ou Importar escopos e concessões de DHCP (em DHCP), preencha Servidor (e Zona, no DNS), escolha o Formato, escolha o Arquivo ou cole em Conteúdo e clique em Importar. Importar de novo substitui os dados do mesmo servidor (e da zona, no DNS).

Exemplo prático: achar um endereço livre e uma reserva duplicada na rede do escritório

Só IPv4. Sub-redes de /16 a /32; a grade de endereços é desenhada até /22.

Adicionar, achar e remover sub-redes e importar DNS ou DHCP exigem assets:write ; ler exige assets:read . Arquivos importados acima de 20 MB são recusados.

Reservas à mão só são feitas pela API ( POST /api/v1/ipam/reservations ); a tela as mostra, mas não tem botão para criar nem remover.

A concessão só aponta para um ativo pelo MAC e só quando um único ativo tem aquele MAC; nome de máquina ou nome no DNS nunca liga (ARP e DNS são último recurso e dado ambíguo não junta ativos).

"Velho" depende do que o Hive vê: o endereço de uma máquina que nenhuma varredura, agente ou concessão alcança parece velho.

O conector do Infoblox (WAPI) e a leitura direta dos servidores DNS/DHCP do Windows pelo coletor ainda não existem: exporte os arquivos e importe.

Remover uma sub-rede não remove endereços, reservas nem os dados de DNS/DHCP.

Rede e topologia

Linha do tempo do mapa e exportação

Área de descoberta

Tela: Firewalls, Wi-Fi e backup de configuração (1/2)

Tela: Firewalls, Wi-Fi e backup de configuração (2/2)

Mapas › Firewalls e Wi-Fi lê FortiGate, Palo Alto, Cisco Meraki e Ubiquiti UniFi pelas APIs deles, com uma conta só leitura. Cada firewall, ponto de acesso e switch que a API devolve vira um equipamento de rede no inventário (o mesmo que a leitura SNMP e o mapa físico usam), com interfaces, versão do firmware, estado de HA, SSIDs, clientes do Wi-Fi e a porta do switch onde cada ponto de acesso estáligado. Mapas › Backup de configuração guarda cada versão da configuração de firewalls e switches, com os segredos mascarados, mostra a diferença entre duas versões e abre alerta quando a configuração muda fora de uma janela de mudança. O Hive nunca restaura uma configuração: vocêbaixa a versão e aplica você mesmo.

Adicionar uma fonte com Adicionar fonte: um FortiGate, um firewall Palo Alto, uma organização Meraki ou um controlador UniFi.

Ver os equipamentos com firmware, HA, porta do switch, clientes do Wi-Fi, CVEs abertas e o último backup; e os SSIDs com segurança, banda, VLAN e clientes.

Ler a fonte de novo com Ler agora, ou removê-la com Remover.

Abrir um equipamento em Backup de configuração, comparar uma versão com a anterior (Lado a lado ou Unificada) e Baixar.

Enviar a configuração de um switch com Enviar configuração e abrir uma janela com Abrir janela em Janelas de mudança para que mudanças planejadas não abram alerta.

O firmware vira um software do equipamento com o CPE (FortiOS e PAN-OS), então a correlação de vulnerabilidades acha as CVEs daquela versão como faz com qualquer outro software.

A conta precisa ser só leitura: o Hive só lê (chamadas GET, op e export). Restaurar não é feito pelo Hive; Baixar entrega o arquivo mascarado, então os segredos precisam ser preenchidos à mão antes de aplicar.

Adicionar fonte, Ler agora e Remover exigem agents:admin ; Baixar, Enviar configuração e Abrir janela exigem assets:write . O Endereço precisa começar com https:// ; o Meraki exige o ID da organização e o UniFi o usuário.

O certificado do firewall ou do controlador precisa ser confiável para o servidor do Hive (importe a CA interna); certificado autoassinado é recusado.

O backup de switch por SSH pelo coletor ainda não é automático: use Enviar configuração (ou a API POST /api/v1/network/devices//config-versions ) com o texto lido por SSH.

Uma versão nova só é gravada quando o texto mascarado muda, então uma mudança só num segredo (senha nova) não é vista.

Os nomes de firmware do Meraki e do UniFi não têm CPE: as CVEs deles não são correlacionadas.

Consoles UniFi OS (UDM, Cloud Key Gen2) que só respondem em /proxy/network ainda não são lidos.

Configurações acima de 5 MB são recusadas.

Rede e topologia

Vulnerabilidades

Alertas

Área de descoberta

Tela: Linha do tempo do mapa e exportação para draw.io e Visio

O Hive guarda o histórico dos mapas: sempre que o mapa muda, uma fotografia é guardada só com o que mudou (nós e ligações que entraram ou saíram). Mapas › Mapa físico, aba Linha do tempo, mostra o mapa como estava numa data e hora e o que mudou de lá até agora. Todo mapa também tem os botões draw.io e Visio, ao lado de Imagem (PNG) e Imagem (SVG), que baixam um diagrama editável.

Escolha o Mapa (mapa físico ou mapa de serviços) e mova o controle: Como estava em … mostra quantos nós e ligações o mapa tinha e lista, em verde, o que entrou desde então e, em vermelho, o que saiu.

Fotografar agora (aparece só com o mapa físico escolhido) tira uma fotografia do mapa físico na hora (o Hive também tira uma a cada hora, a primeira uns 15 minutos depois de o núcleo subir); se nada mudou, nada é guardado.

Em qualquer mapa, draw.io baixa um arquivo .drawio (abra no draw.io ou no diagrams.net) e Visio um arquivo .vdx (desenho XML do Visio).

Exemplo prático: o que mudou na rede desde a segunda-feira passada

O histórico começa quando o recurso é instalado: não há nada antes da primeira fotografia. Até lá a aba mostra Nenhuma fotografia ainda.

Os botões draw.io e Visio somem em telas estreitas (celular); use uma janela mais larga ou Imagem (PNG).

O mapa físico é fotografado a cada hora, então uma mudança que veio e voltou dentro da hora pode não aparecer. O mapa de serviços só tem linha do tempo quando os nós e ligações são enviados pela API ( POST /api/v1/map-timeline/service/snapshot ); a console ainda não envia sozinha.

A exportação para o Visio é no formato de desenho XML ( .vdx ), não .vsdx : o Visio 2013 ou mais novo abre e salva como .vsdx ; o Visio para a web não abre .vdx .

A exportação lê o mapa desenhado: formas viram caixas ou elipses com o texto, linhas viram conectores presos às formas onde começam e terminam. Ícones, cores e tracejados não vão; use SVG para uma imagem fiel.

Rede e topologia

Mapa de serviços

Montador de mapas

IPAM, DNS e DHCP

Tela: Virtualização

A Virtualização lê seus hipervisores por um coletor, com uma conta somente leitura, e mostra os hosts, as VMs (e qual máquina do inventário cada uma é), os switches virtuais, os datastores e os snapshots.

Fica em Descoberta › Virtualização. Existem quatro tipos de conexão: vCenter / ESXi, Hyper-V, Proxmox VE e Nutanix (Prism Central).

Conectar um hipervisor com Conectar hipervisor e acompanhar a leitura na aba Conexões.

Ler uma conexão de novo com Ler agora, ou removê-la com Desconectar.

Ver a topologia de uma conexão na aba Mapa (visões Física e Lógica).

Listar os Hosts (hardware, cluster, VMs ligadas e total) e as VMs (estado, sistema, placas de rede, máquina do inventário).

Achar as VMs que não estão no inventário com Só VMs fora do inventário.

Consultar a aba Armazenamento (datastores e snapshots das VMs) e a aba Switches virtuais (uplinks e grupos de portas com a VLAN).

A senha ou o token vão para o cofre e só seguem para o coletor na hora da leitura. Cada conexão élida de novo a cada hora.

Cada VM e cada host é casado com uma máquina do inventário, da evidência mais confiável para a menos confiável: UUID da BIOS (também com os três primeiros campos invertidos, como o Windows mostra o UUID de algumas VMs VMware), MAC, IP e nome. A aba VMs diz como cada uma foi casada ("casada pelo UUID da BIOS", "casada pelo MAC"...).

Um MAC, IP ou nome repetido em mais de uma máquina só decide se exatamente uma delas tem o agente; senão o item não é ligado (tabela ARP ou registro DNS velho não ganha).

Uma VM ou host que não casa com nenhuma máquina vira ativo com o hipervisor como origem ("incluída no inventário pelo hipervisor"). Isso vale para VMs desligadas: elas também entram no inventário e aparecem nos mapas com a relação host → VM. Quando várias VMs têm o mesmo UUID da BIOS (cópias restauradas de backup), as VMs ligadas escolhem primeiro.

Quando um ativo criado pelo hipervisor encontra depois o registro de verdade da máquina pelo UUID ou MAC (agente instalado, descoberta, integração), os dois são unidos sozinhos: fica o registro de verdade, que recebe as tags, os grupos e o histórico do criado pelo hipervisor. Se casarem só por IP ou nome, os dois ficam e podem aparecer como possíveis duplicados.

Se a máquina já existe, o hipervisor só liga e preenche o que está vazio: o que o agente informa vale mais.

A página da máquina mostra onde ela roda (VM em qual host e cluster) ou, num host, as VMs que rodam nele. É isso que liga o nó do Kubernetes e o servidor de banco à VM e ao host nos mapas.

Armazenamento lista os storages de cada nó com capacidade, livre e % usado, e os snapshots das VMs com a idade.

A equipe conecta o vCenter SP e também, para um teste, o host ESXi esx03.corp.local direto, como ESX03 direto .

Só UUID ou MAC unem itens vistos por duas conexões; IP ou nome sozinhos nunca unem.

Conectar, ler agora e desconectar exigem agents:admin ; ver exige assets:read .

Uma nova leitura não começa enquanto outra roda ("The hypervisor is being read now.").

Se o coletor não terminar em uma hora, a conexão vai para Erro com "The collector did not finish the read." e a correção "Check that the collector is online and reaches the hypervisor." (o coletor está online e alcança o hipervisor?).

Datastores e snapshots vêm do vCenter e do Proxmox. Hyper-V e Nutanix mostram hosts, VMs e redes.

No Proxmox, o ID do token de API precisa ser usuario@realm!token .

A impressão precisa ser o SHA-256 do certificado (64 dígitos hexadecimais, com ou sem ":").

A tela não tem formulário de edição: para mudar o endereço, a conta ou o intervalo de leitura (15 a 1440 minutos, padrão 60) use a API ( PUT /api/v1/virtualization/connections/ ); senha ou token novos substituem os do cofre. Desconectar e conectar de novo baixaria os ativos criados pela conexão.

Descoberta

Mapa de rede

Kubernetes

Caminho do serviço e mapa lógico

Inventário

Tela: Kubernetes

O Kubernetes lê seus clusters por um coletor, com uma conta somente leitura: o que roda, as imagens e seus CVEs, as dependências e o mapa do serviço publicado até o banco. Fica em Descoberta ›Kubernetes. A lista mostra cada cluster com o estado, o conteúdo ("nós · cargas · pods"), as imagens com CVEs e a última leitura; clique num cluster para abrir o detalhe.

Conectar um cluster com Conectar cluster (um assistente de 3 passos).

Abrir um cluster e usar as abas: Mapa lógico, Caminhos do serviço, Cargas, Imagens, Nós e Namespaces.

Ler o cluster de novo com Ler agora, mudar como o Hive se autentica em Acesso, ou removê-lo com Desconectar.

Clicar num objeto do mapa para ver do que ele depende, quem o usa e o que para se ele cair.

(sem Secrets), a ligação, um token válido por um ano, e imprimem o endereço da API e a CA do cluster. Cada linha tem Copiar. Em Opcional: Gateway API, Istio ou rotas do OpenShift hámais dois comandos para ler esses objetos. Clique em Avançar.

O token ou o certificado ficam no cofre e só vão ao coletor na hora da leitura.

Nós, namespaces, cargas (Deployment, StatefulSet, DaemonSet), pods e contêineres (imagem e portas), Services, Endpoints, Ingress, políticas de rede, volumes e, só quando ligado, ConfigMaps; com os comandos opcionais, Gateway API, virtual services do Istio ou rotas do OpenShift. Secrets nunca são lidos. De variáveis de ambiente (e ConfigMaps, quando lidos) só os endereços (host:porta, URLs sem senha) saem do cluster, para desenhar as dependências. Os nós são ligados às máquinas do inventário pelo nome ou IP.

Se a conta não consegue listar alguns tipos, o cluster mostra "Leitura parcial" com os tipos que faltam; informe o Usuário (conta de serviço) em Acesso para ver os comandos exatos que dão a leitura do resto.

Mapa lógico: da esquerda para a direita, o que é publicado (Ingress, rotas), Services, cargas, dados e destinos fora do cluster, e os nós (Mostrar nós). Cada ligação diz de onde veio (regra de Ingress, seletor de rótulos, Endpoints, variável de ambiente, ConfigMap, política de rede, service mesh ou conexão vista pelo agente) e a confiança: linha cheia alta, tracejada média, pontilhada baixa. Um destino que é máquina do inventário mostra o nome dela; um banco gerenciado de nuvem aparece como Serviço de nuvem. Quando o agente do nó vê a conexão, a dependência fica "confirmado pelo agente".

Caminhos do serviço: uma linha por endereço publicado, da entrada até o fim da cadeia, com os dados em negrito.

Cargas e Nós: o que roda, quantas réplicas estão prontas e a máquina do inventário de cada nó.

Imagens: produto e versão vêm do nome e da tag da imagem (postgres:16.2 → PostgreSQL 16.2) e os CVEs são os dessa versão no NVD, com os explorados (KEV) em destaque. Imagens sem versão fixa mostram "sem versão fixa (latest ou digest)". Pacotes dentro da imagem não são lidos.

Namespaces: um cartão por namespace com o que roda nele; clique para abrir o mapa dele.

Clique em qualquer objeto do mapa para ver Vai para, Usado por e Se cair: o que para e o que sóperde capacidade (uma carga com réplicas em outros nós).

Conectar, ler agora, mudar o acesso e desconectar exigem agents:admin ; ver exige assets:read .

O endereço da API precisa começar com https:// . A CA precisa ser o PEM já decodificado (BEGIN CERTIFICATE).

Um certificado de cliente colado no campo do token é recusado com "This is a client certificate: choose that option." (escolha a opção de certificado).

Desconectar apaga o que foi lido e o token no cofre; o cluster em si não é alterado.

O intervalo de leitura (15 a 1440 minutos, padrão 60) só muda pela API.

O mapa lógico vai da esquerda para a direita (ou de cima para baixo: Horizontal, Vertical ou Automática, lembrada por pessoa): o que é publicado (Ingress, rotas), Services, cargas, dados e destinos fora do cluster, e os nós. Cada ligação diz de onde veio — regra do Ingress, seletor de rótulos,

Endpoints, variável de ambiente, ConfigMap, política de rede, malha de serviço ou conexão vista pelo agente — e a confiança (alta, média, baixa). Um destino que é máquina do inventário (um servidor de banco) aparece com o nome dela; um banco gerenciado na nuvem (RDS, Azure SQL, Cloud SQL) aparece como serviço de nuvem. Quando o agente do nó vê a conexão para o destino, a dependência fica confirmada.

Use Níveis para mostrar das entradas até o nível escolhido (1 = só o que é publicado; o último = tudo até os nós); ele começa num nível legível. Com mais de um namespace, cada namespace é uma caixa; no Mapa do cluster inteiro clique no nome para recolher ou expandir. Uma camada grande vira várias colunas, a ordem cruza o mínimo de linhas e Ajustar faz caber na tela. Clicar num objeto abre o painel ao lado do mapa: do que ele depende, quem ele afeta e o que para se ele cair.

Caminhos do serviço mostra, para cada endereço publicado, os saltos até o banco, agrupados por namespace (busca por nome ou host, filtro por namespace e host). Cada salto é um chip com o tipo, o nome e uma situação curta: host:porta e TLS na entrada, tipo e portas no Service, réplicas prontas/desejadas na carga e o endereço do dado no fim. Clique num caminho para ver o mini-mapa e o painel com o host público, os pods e os nós em que rodam, as imagens com CVEs/KEV e o que para se o fim da cadeia cair; Abrir no mapa lógico mostra o mapa inteiro com a cadeia em destaque (ou sóela). Clique num objeto no mapa para ver o que para se ele cair: quem depende dele para; uma carga com réplicas em outros nós perde capacidade quando um nó cai.

Um cluster descoberto por uma conta de nuvem (Nuvem → Recursos, tipo Kubernetes) é lido com a identidade da conta de nuvem, sem token de conta de serviço: Ler este cluster pega o endereço da API e a CA no provedor e, a cada leitura, o núcleo gera um token de vida curta que vai ao coletor junto com a tarefa (nunca é guardado). Na conta, Kubernetes liga a leitura automática de todo cluster gerenciado, com o coletor que alcança a API. A lista do Kubernetes mostra o provedor e a conta; a página do cluster volta ao recurso na nuvem. Token ou certificado de cliente em Acesso continuam valendo para qualquer cluster.

Exemplo — EKS. A conta "AWS prod" (chave de acesso do usuário IAM hive-reader) acha o aurora-eks em us-east-1. Ler este cluster chama o DescribeCluster (endereço e CA) e cada leitura usa o mesmo token do aws eks get-token . Se o cluster responder 401 ou 403, a página mostra os comandos com o ARN da chave: aws eks create-access-entry --cluster-name aurora-eks --region us-east-1 --principal-arn arn:aws:iam::123456789012:user/hive-reader e aws eks associate-access-policy ... --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy --access-scope type=cluster . Se nós ou volumes continuarem faltando, ligue o hive-read a um grupo e ponha o grupo na access entry ( --kubernetes-groups hive-readers ). Só clusters no modo CONFIG_MAP (aws-auth) usam eksctl create iamidentitymapping .

Exemplo — AKS. A conta "Azure prod" (registro de aplicativo com Reader) acha o aurora-aks. O núcleo pega o endereço e a CA pelo listClusterUserCredential e entra com um token do Microsoft Entra para o aplicativo do servidor do AKS. Dê à entidade de serviço "Azure Kubernetes Service RBAC

Reader" e "Azure Kubernetes Service Cluster User Role" no cluster ( az role assignment create --assignee <app id> --role ... --scope <id do cluster> ) ou, com RBAC do Kubernetes, ligue o hive-read ao object id dela ( --user=<object id> ). Cluster só com contas locais não aceita o token do Entra: conecte-o com token.

Exemplo — GKE. A conta "GCP lab" (chave da conta de serviço) acha o aurora-gke. O núcleo pega o endpoint e a CA pelo clusters.get e entra com o token OAuth da conta de serviço. Dê a ela roles/container.viewer ( gcloud projects add-iam-policy-binding <projeto> --member=serviceAccount:<e-mail>--role=roles/container.viewer ) ou ligue o hive-read ao e-mail da conta de serviço.

ConfigMaps costumam guardar senhas, tokens e chaves, por isso o papel principal hive-read não os inclui mais. No assistente, Opcional: ler ConfigMaps (desligado por padrão) mostra um aviso e dois comandos à parte ( hive-read-configmaps ); ligue Ler ConfigMaps (só endereços) em Acesso para usá-los. Mesmo assim o coletor guarda só o que parece endereço e descarta todo o resto antes de enviar:

Fica: host e porta de URLs ( postgres://app:[email protected]:5432/pedidos → pg.data:5432 ), de JDBC ( jdbc:sqlserver://mssql.corp:1433;… , Oracle @//ora.corp:1521/ORCL ), de DSN ( Server=sql01,1433;… , host=pg port=5433 … , user:pw@tcp(mysql:3306)/db ) e de listas host:porta (bootstrap do Kafka).

Sai: usuários, senhas, tokens, chaves, certificados, caminhos, parâmetros e qualquer valor que não seja endereço; só fica o nome das chaves que tinham endereço.

Com a leitura desligada, o cluster mostra a nota "ConfigMap não lido (opcional; pode conter segredos)"— ele nunca aparece como faltando numa leitura parcial.

O Service chega à carga, nesta ordem: pelos pods das EndpointSlices (discovery.k8s.io) ou dos Endpoints; pelo seletor nos rótulos dos pods; pelo seletor no modelo de pod da carga (carga escalada para 0). Um pod cujo ReplicaSet não foi lido chega ao Deployment pelo pod-template-hash . Sem nada disso, a cadeia termina num marcador explícito em vez de parar em silêncio: Service sem endpoints (nenhum pod casa com o seletor, nenhum pod pronto ou sem seletor) ou a carga com 0 réplicas.

Nomes do DNS do cluster levam ao Service de verdade, em qualquer namespace, e não a um nó "fora do cluster": svc , svc.ns , svc.ns.svc , svc.ns.svc.cluster.local e o nome de pod de um Service headless ( kafka-0.kafka-headless.hml-tools.svc.cluster.local ), achados em variáveis de ambiente, argumentos, endereços de ConfigMap, ExternalName e rotas do Gateway e do Istio. Mais duas fontes criam ligações: o tráfego visto (NetFlow/IPFIX e os fluxos dos agentes de um IP de pod para um ClusterIP ou IP de pod, origem visto no tráfego, confiança alta; também confirma uma ligação que a configuração já declarava) e uma NetworkPolicy com namespaceSelector (declarada, confiança média).

Abrir um namespace mostra um mapa consolidado com todos os caminhos dele: as entradas àesquerda, os objetos usados por vários caminhos marcados compartilhado por N, o fim comum marcado e cada namespace de que ele depende como um bloco ("hml-tools · 3 daqui dependem dele", com o que é usado lá). Clique no bloco para abri-lo no lugar (recursivamente, seguindo os Níveis) ou em ↗ para abrir o mapa dele em outra aba.

Escolher um objeto desenha o impacto no mapa, mesmo fora de Só este caminho ou dos níveis mostrados: vermelho para, laranja perde capacidade, cinza usa, azul é aquilo de que ele depende; o que está fora do recorte original fica tracejado. Mostrar impacto / Voltar ao caminho alterna. Clicar num item do painel lateral o mostra no mapa (e o primeiro clique num nó afetado o destaca no painel).

Serviços publicados que param lista cada entrada (host, tipo, namespace e o serviço de negócio, quando há) com um link para o caminho dela em Caminhos do serviço.

Nuvem

Virtualização

Caminho do serviço e mapa lógico

Vulnerabilidades

Tela: Inventário de APIs

O inventário de APIs lista as APIs da empresa com as operações (método, caminho, autenticação e tags) e mostra as shadow APIs: rotas que as aplicações atendem ou que o Ingress publica sem nenhuma documentação. Fica em Descoberta › APIs.

Importar um documento OpenAPI 3 ou Swagger 2 (JSON ou YAML), colado ou buscado de um endereço https.

Ler as APIs de um gateway: Kong Admin API, Azure API Management ou Apigee.

Abrir uma API para ver cada operação e quais não declaram autenticação.

Ver o Service do Kubernetes que publica a API (achado pelo caminho do Ingress) e o serviço de negócio.

Comparar o documentado com o visto: rotas sem documentação e operações documentadas nunca chamadas.