Whitepaper & Trust Center (A9)

whitepaper de arquitetura autonomous — plataforma de aiops central it · autonomous · whitepaper de arquitetura autor equipe de tecnologia — central it controle do documento versão data autor descrição 1 1 04/09/2026 equipe de tecnologia — central it whitepaper de arquitetura do sistema autonomous base documental consultada este whitepaper foi elaborado a partir das seguintes fontes verificadas no repositório oficial do produto repositório principal (orquestrador) — autonomous center principal (gitlab da central it) sub repositórios da stack — autonomous center, autonomous collector, autonomous discovery, autonomous pipeline e autonomous assets readme md e claude md do repositório principal, docker compose yml e script operacional b sh inventários funcionais em docs/ (inventario funcional autonomous center md, collector md, discovery md, pipeline md) manuais funcionais por domínio em docs/manual funcional autonomous center/ e demais componentes manual de habilitação de autenticação keycloak em docs/auth setup md baseline de produto em docs/baseline produto autonomous center html introdução este documento apresenta a arquitetura do sistema autonomous — plataforma de aiops (ia aplicada a operações de ti) da central it — considerando seus principais componentes funcionais, técnicos, integrações, mecanismos de autenticação e autorização, camadas de dados, rastreabilidade, implantação e controles de segurança aplicáveis ao escopo analisado o objetivo é fornecer uma visão clara e auditável da solução, demonstrando como o autonomous unifica observabilidade (logs, ocorrências, métricas e traces) em um único plano de dados e aplica correlação determinística combinada com inteligência artificial generativa para converter o ruído de centenas de alertas em poucos eventos acionáveis, com contexto de ativo, topologia e narrativa de causa raiz este documento não descreve arquitetura criptográfica governada pelo cliente o foco desta versão está na arquitetura do sistema autonomous e nos controles efetivamente identificados nos documentos e no código fonte analisados sumário executivo o autonomous foi concebido como uma plataforma corporativa de aiops para unificar observabilidade e segurança em um único plano cobre desde a coleta multi fonte de logs, métricas, traces, webhooks e syslog, passando por descoberta ativa de rede e inventário de ativos, correlação multi estratégia com ia generativa, até a gestão do ciclo de vida de eventos, ação autônoma orquestrada por agentes e notificação por múltiplos canais a arquitetura se apoia em um repositório orquestrador (autonomous center principal) que integra cinco componentes de aplicação versionados em repositórios dedicados autonomous center (backend spring boot + frontend vite/react), autonomous collector, autonomous discovery, autonomous pipeline e autonomous assets a infraestrutura compartilhada inclui postgresql e opensearch a autenticação em ambientes produtivos é apoiada por keycloak a observabilidade interna do próprio produto é feita via opentelemetry (dogfooding), com gateway otel collector convergência de logs, métricas, traces, ocorrências e eventos correlacionados em um plano único de dados descoberta automática de rede e inventário/cmdb integrados, alimentando cálculo de blast radius e causa raiz correlação multi estratégia (assinatura, ativo/grupo, grafo de rede, anomalia estatística e grupo de serviço) com narrativa gerada por ia segurança convergente com inteligência de ameaças multi provedor e índice de comprometimento por cve/epss/kev rastreabilidade de eventos, ocorrências, alterações de configuração e transições do ciclo de vida integração com hyperagent para ação autônoma e execução assistida contexto e motivação o cenário atual de operações de ti envolve grande volume de alertas dispersos entre ferramentas de monitoração, segurança e observabilidade, dificultando a priorização e o diagnóstico ferramentas isoladas (por exemplo, zabbix e wazuh) monitoram e emitem sinais, mas não convergem em uma visão única de incidente, ativo e topologia, e não trazem consigo uma camada de correlação e narrativa de causa raiz a solução autonomous busca responder a esse cenário como uma camada acima das fontes existentes consome sinais dessas ferramentas, adiciona correlação, redução de ruído e inteligência de incidente, e devolve poucos eventos acionáveis, cada um enriquecido com contexto de ativo, topologia e recomendação de ação a motivação arquitetural é organizar os componentes em uma stack modular, reutilizável e operacionalmente implantável, com pontos de acoplamento claros (portas, apis, filas, índices), separação de responsabilidades entre coleta, descoberta, pipeline de risco, inventário e experiência do operador, além de aderência a padrões abertos (opentelemetry, oidc/oauth2, opensearch, postgresql) para reduzir lock in e favorecer soberania do dado objetivos da arquitetura definir uma visão técnica consolidada dos componentes da plataforma explicar como a solução organiza autenticação, autorização e permissionamento entre backend, frontend e serviços internos mapear repositórios de dados (postgresql e opensearch), índices, schemas e datasources de leitura/escrita registrar integrações externas relevantes (wazuh, zabbix, nvd, epss, kev, provedores de ameaças, hyperagent) descrever mecanismos de auditoria, histórico e rastreabilidade de eventos e configurações indicar requisitos técnicos mínimos para implantação, operação e suporte da stack apresentar limitações conhecidas e pendências que precisam de validação técnica antes de generalização em produção servir como referência para arquitetura, segurança, infraestrutura, operação, governança e auditoria escopo da solução dentro do escopo arquitetura lógica e funcional do autonomous (center, collector, discovery, pipeline e assets) camada de apresentação, navegação e renderização do frontend (vite/react) processo de implantação da stack via docker compose e utilitário b sh do repositório orquestrador persistência em postgresql (schemas do center, do assets e do pipeline) e em opensearch (índices log intelligence e correlatos) configuração por variáveis de ambiente por ambiente ( env) e dogfooding de opentelemetry integração com keycloak como provedor de identidade em ambientes produtivos gestão de perfis, roles e permissões via realm dedicado no keycloak logs operacionais e trilha de auditoria funcional das transições de ciclo de vida de eventos fora do escopo detalhamento de infraestrutura compartilhada (postgresql e opensearch) — subida por repositório separado (bigdata dt/autonomous infra) detalhamento do autonomous agent como componente containerizado — o agente é executado no host monitorado (windows/systemd/launchd), fora do docker compose da stack governança criptográfica governada pelo cliente (chave gerenciada pelo cliente) — não escopo desta versão configurações específicas de rede corporativa, vpn, firewall e outros controles de perímetro do cliente visão geral da arquitetura a arquitetura do autonomous pode ser entendida como a composição de cinco componentes de aplicação, uma camada de infraestrutura compartilhada e uma camada de identidade externa o repositório orquestrador (autonomous center principal) mantém o docker compose, o script de operação b sh e a documentação técnica; ele não contém código de negócio os componentes de aplicação são autonomous center — backend spring boot (porta 8080) e frontend vite/react (porta 5173) núcleo do produto correlação, event intelligence, painéis analíticos, ciclo de vida de eventos, integração com hyperagent e visão de ativos autonomous collector — maven/java (porta 8081, com syslog tcp na porta 5514) recebe e normaliza logs, syslog, webhooks, otlp, integrações com wazuh e zabbix, aplica políticas de descarte, cluster de padrões e correlação de borda autonomous discovery — maven/java (porta 8085, com api key) executa descoberta ativa em rede ping, arp, portas, dns, netbios, snmp, cdp/lldp, ssh, wmi, docker, kubernetes e ssdp autonomous pipeline — spring boot (porta 8090) ingere feeds de vulnerabilidades (nvd, epss, cisa kev), sincroniza ativos, faz matching entre softwares e cpes e calcula risco/comprometimento autonomous assets — spring boot (porta 8086) concentra o inventário/cmdb do produto, com dois datasources leitura restrita no schema do center e leitura/escrita restrita ao seu próprio schema inventory autenticação e autorização em ambientes produtivos são apoiadas pelo keycloak a persistência utiliza um postgresql compartilhado (múltiplos schemas por componente) e um cluster opensearch (https na porta 9200), com dashboards na porta 5601 a observabilidade interna é feita por opentelemetry, com o agente java opcional injetado por java tool options e um gateway otel collector componentes técnicos componente descrição responsabilidade arquitetural usuário / navegador ponto de acesso da solução web via spa permitir interação com telas, menus, dashboards, mapa de rede, event intelligence e demais domínios conforme perfil autonomous center — frontend spa em vite/react servida em desenvolvimento na porta 5173; empacotada como static no jar do backend em ambientes produtivos apresentar dashboards, ocorrências, eventos, ativos, service groups, configurações e integrar autenticação oidc via keycloak js autonomous center — backend spring boot na porta 8080, com integração opensearch, postgresql, hyperagent e otlp servir apis de negócio, executar orquestração de correlação, expor endpoints /api/hyper e /api/orchestration, agendar sincronização com hyperagent autonomous collector componente maven/java na porta 8081, com syslog tcp na porta 5514 quando habilitado coletar, normalizar, deduplicar e enriquecer sinais de log, syslog, webhooks, otlp, wazuh, zabbix, banco e kafka autonomous discovery componente maven/java na porta 8085, protegido por api key executar descoberta ativa multi protocolo e persistir topologia via serviço externo de banco autonomous pipeline spring boot na porta 8090, com flyway aplicando migrações em múltiplos schemas ingerir feeds de cve, epss e kev; sincronizar ativos; realizar matching cpe↔software; calcular risco e comprometimento autonomous assets spring boot na porta 8086, com dois datasources segregados persistir inventário/cmdb, expor api de ativos e mediar enrolamento do autonomous agent autonomous agent binário go instalado no host monitorado (windows/systemd/launchd); não roda em container fazer check in periódico contra o assets via assets base url utilizando bootstrap token de enrolamento postgresql instância compartilhada (porta 5454 no host local), com database autonomous e múltiplos schemas persistir dados de negócio, inventário, pipeline e configurações operacionais opensearch + dashboards opensearch em https na porta 9200 e dashboards na 5601 índice principal log intelligence indexar logs, ocorrências, métricas, traces, eventos e correlações consultáveis pelo center opentelemetry collector gateway interno para telemetria dos próprios componentes receber traces, métricas e logs otlp dos serviços java e do frontend, encaminhando para os backends de observabilidade keycloak identity provider externo em auth centralit com br, com realm dedicado autonomous center em ambientes controlados fornecer autenticação oidc (authorization code + pkce s256) para o frontend e validar jwt nas apis hyperagent plataforma de agentes que operacionaliza ação autônoma sobre eventos críticos executar remediações orquestradas e refletir status de volta ao center via sincronização periódica diagrama de referência o diagrama abaixo apresenta uma visão conceitual dos principais componentes e fluxos da solução autonomous a representação deve ser validada com a arquitetura final de infraestrutura, rede e operação antes de uso como evidência definitiva figura 1 — visão conceitual da arquitetura lógica do autonomous coletas (logs, syslog, webhooks, otlp, wazuh, zabbix, kafka) → autonomous collector (porta 8081, syslog tcp 5514) → opensearch (log intelligence, traces, metrics, events, correlated) e postgresql rede corporativa → autonomous discovery (porta 8085, api key) → topologia persistida via serviço externo autonomous pipeline (porta 8090) consulta nvd, epss e cisa kev, faz matching cpe↔software e alimenta o center autonomous assets (porta 8086) mantém cmdb e enrolamento do autonomous agent autonomous center (backend 8080 + frontend 5173) consome os índices opensearch (https 9200) e o postgresql, integra com hyperagent e keycloak (authorization code + pkce s256) opentelemetry collector recebe telemetria dos serviços via otlp arquitetura lógica da solução o operador acessa a plataforma pela interface web (spa em vite/react) a autenticação em ambientes produtivos é intermediada pelo keycloak via oidc com authorization code e pkce s256; o token de acesso permanece em memória na instância keycloak js e é enviado no header authorization bearer nas chamadas às apis o backend do center valida o jwt como oauth2 resource server (jwtdecoder), consultando o jwks do realm quando inventory security enabled está ativo as telas consomem apis rest do backend do center, que orquestra as consultas em opensearch (logs, ocorrências, métricas, traces, eventos e correlações) e em postgresql (configurações, service groups, ativos, ciclo de vida) a coleta é realizada pelo autonomous collector, que aplica parsers, políticas de descarte, clusterização por fingerprint e correlação de borda antes de entregar dados ao opensearch e ao kafka quando habilitado a descoberta ativa é realizada pelo autonomous discovery a partir do console (assíncrono) ou por cli, com resultados persistidos pelo serviço discovery db service e consumidos pelo center para análise de ativos, mapa de rede e conciliação o autonomous pipeline executa jobs programados que consultam nvd, epss e kev, sincronizam ativos, realizam matching cpe↔software e calculam risco e comprometimento, publicando leituras para o center via visões auto cve e tabelas pipeline core o autonomous assets fornece o cmdb do produto, com datasource de leitura sobre o schema do center e datasource de leitura/escrita no schema inventory, e media o enrolamento do autonomous agent nos hosts monitorados eventos críticos podem ser encaminhados para ação autônoma via hyperagent; o status do agente é refletido de volta em opensearch por um serviço de sincronização periódica a telemetria dos próprios serviços é opcionalmente exportada via opentelemetry (agente java carregado por java tool options) para o gateway otel collector interno camada de apresentação e deploy a camada de apresentação é uma spa em vite/react, servida em desenvolvimento na porta 5173 em ambientes produtivos, o dist do frontend é empacotado como recurso estático dentro do jar do backend isso implica que alterações de variáveis de build do frontend exigem geração de nova imagem — não são resolvidas apenas por variáveis de runtime o ciclo de build e implantação local é executado pelo script b sh do repositório orquestrador, com os seguintes verbos principais comando efeito /b sh setup clona os quatro sub repositórios, normaliza links simbólicos, executa docker compose pull, roda maven e npm build, builda imagens locais, sobe a stack e executa a validação http /b sh compile compila os módulos java (mvn clean package dskiptests) e gera o build do frontend (npm build) /b sh build constrói as imagens docker locais da stack /b sh up / down / restart sobe, derruba ou reinicia a stack (ou um serviço específico) /b sh validate executa smoke tests http contra opensearch, dashboards, backend /api/collectors, frontend, collector /api/webhook/generic, discovery /api/discovery/scan (202) e o índice log intelligence /b sh repos status / pull consolida operações git nos cinco repositórios do workspace (principal, center, collector, discovery, pipeline) cada serviço define, no docker compose, variáveis específicas de opentelemetry (otel service name, otel exporter otlp endpoint, otel traces sampler) para participar do dogfooding de observabilidade o java tool options carrega o agente otel opcionalmente, por variável de ambiente controlada em cada ambiente camada de dados a camada de dados combina postgresql (dados estruturados, inventário, ciclo de vida, configuração) e opensearch (dados de observabilidade e correlação), ambos providos como infraestrutura compartilhada e não recriados dentro do docker compose desta stack postgresql — schemas por componente componente schema / role principal finalidade autonomous center public (via cve user em desenvolvimento) configurações operacionais, service groups, ativos lógicos (logical asset), observações, dispositivos, ciclo de vida de eventos e vínculos com hyperagent (event hyper issue) autonomous assets inventory (role assets rw, rw) e public (role inventory ro, ro) inventário/cmdb próprio do módulo, migrações flyway do assets (74+ migrations); leitura restrita das entidades do center autonomous pipeline pipeline ops, pipeline raw, pipeline core, pipeline stage e auto cve execuções (pipeline runs, etl sync log), dados brutos de feeds, dados normalizados (cve, cpe, ativos), estágios intermediários e visões finais consumidas pelo center o isolamento de credenciais do assets é intencional o datasource de leitura sobre o schema do center é aberto apenas com a role inventory ro (select), enquanto o datasource sobre o schema inventory usa a role assets rw (todas as operações restritas àquele schema) isso limita o raio de qualquer defeito ou vulnerabilidade no módulo assets a apenas seu próprio schema opensearch — índices de observabilidade índice uso log intelligence índice principal de logs e ocorrências consultado pelo center (pesquisa, dashboards, timelines, análise de padrões) opensearch index traces índice de traces distribuídos consultados por pesquisa de traces, waterfall e blast radius opensearch index metrics índice de métricas consultadas por pesquisa de métricas e correlação com eventos opensearch index events índice de eventos correlacionados, ciclo de vida e vínculos com hyperagent opensearch index correlated índice auxiliar de correlações (eventos derivados e agrupamentos) o acesso ao opensearch é feito via https (opensearch scheme=https, opensearch port=9200) com credenciais em formato usuário\ senha via variáveis de ambiente (opensearch username e opensearch password) os índices e nomes efetivos são parametrizados por ambiente autenticação, autorização e permissionamento a solução utiliza keycloak como identity provider em ambientes produtivos o manual docs/auth setup md descreve a arquitetura de autenticação verificada no código frontend (spa) adapter keycloak js v26 no modo oidc padrão — authorization code flow com pkce (s256) os tokens ficam em memória na instância keycloak js (kc token e kc refreshtoken) e não em localstorage o interceptor http envia authorization bearer nas chamadas de api e renova via updatetoken/refresh token backend (spring boot, autonomous assets como referência) oauth2 resource server (jwt) valida o token pela jwks (spring security oauth2 resourceserver jwt jwk set uri) o ligar/desligar da exigência é controlado por inventory security enabled a busca do jwks é preguiçosa — a aplicação sobe mesmo sem o keycloak estar disponível em ambientes controlados foi provisionado um realm dedicado autonomous center no keycloak da central it, contendo realm roles inventory editor e administradores — as write roles esperadas pelo securityconfig do assets, lidas via realm access roles no jwt (jwtrolesconverter) client front manager público (spa), standard flow + pkce, direct access grants desligado redirect uris cadastradas conforme o ambiente client autonomous agent confidencial, service accounts habilitado, sem standard flow (uso machine to machine) a service account recebe a role inventory editor o center também mantém integração com o hyperagent em duas superfícies /api/hyper/ — autenticação por board key persistida no banco (registro hyper agent config) de forma cifrada com aes; a board key nunca é retornada ao frontend nem gravada em log /api/orchestration/ — autenticação via variável de ambiente hyperagent api key (bearer) e endpoint base hyperagent api base a rota /companies é board scoped e retorna 403 quando chamada com uma chave de agente controle aplicação na arquitetura autenticação oidc via keycloak (authorization code + pkce s256); tokens em memória no adapter keycloak js autorização validação de jwt como oauth2 resource server; leitura de roles via realm access roles; inventory security enabled como interruptor papéis realm roles inventory editor e administradores; role de service account para o autonomous agent tokens access token e refresh token gerenciados pelo adapter; renovação transparente via updatetoken credenciais board key do hyperagent cifrada em banco; api key do hyperagent em variável de ambiente isolamento de dados datasources segregados no assets (inventory ro para leitura, assets rw para escrita restrita ao schema inventory) menor privilégio roles postgres específicas por finalidade; nenhum role tem acesso ao schema do outro sem grant explícito perfis e personas o autonomous foi desenhado como uma plataforma unificada para operações de noc, soc e sre, e a experiência do operador se adapta ao perfil e às permissões atribuídas via keycloak os perfis funcionais identificados na documentação e no frontend são perfil / persona objetivo de uso operador de noc/soc acompanhar dashboards de ocorrências e eventos, reconhecer, tratar e fechar incidentes; disparar chat contextual de ia no evento analista de segurança investigar eventos correlacionados, consultar inteligência de ameaças, revisar hits em ativos e priorizar tratamento por comprometimento (cve/epss/kev) sre / engenharia de plataforma consultar métricas, traces, request flow map, service monitor, blast radius e dossiê de investigação; ajustar regras de correlação e políticas de descarte administrador da plataforma configurar coletores, políticas, canais de notificação, prompts de ia, integração com hyperagent e gestão de usuários/roles no keycloak gestor / liderança técnica acompanhar kpis de eventos (mttr, compressão de alertas), morning call e visão consolidada de saúde por serviço time de implantação executar setup local via /b sh setup, subir infraestrutura compartilhada e validar a stack via /b sh validate autonomous agent (service account) realizar enrolamento e check in periódico contra o assets via bootstrap token; utilizar service account do keycloak com role inventory editor integrações externas o autonomous prevê integração com um conjunto de sistemas externos — parte para consumo de sinais de operação e segurança, parte para publicação de alertas e ações as integrações identificadas no código e na documentação são integração finalidade arquitetural observação wazuh ingestão de eventos de segurança, inventário e correlação com cves utilizado por wazuhingestionservice e como fonte de inventário no pipeline zabbix ingestão de sinais de monitoração de infraestrutura consumido pelo collector como fonte de eventos e enriquecimento kafka barramento de ingestão opcional com fallback automático configurável no collector; utilizado para desacoplamento e resiliência otlp (opentelemetry) ingestão de traces, métricas e logs de aplicações externas e dogfooding interno gateway otel collector interno; cada serviço define otel service name e endpoint nvd ingestão de cves para o pipeline executado por nvdcvepuller, com dados brutos gravados antes da normalização epss enriquecimento das cves com probabilidade de exploração executado por epsspuller no pipeline cisa kev enriquecimento das cves com evidência de exploração conhecida executado por kevpuller no pipeline inteligência de ameaças (iocs) consumo de indicadores de múltiplos provedores para enriquecer eventos e ativos provedores registrados na baseline abuseipdb, otx, threatfox, urlhaus, phishtank, shodan, censys, greynoise, entre outros keycloak provedor de identidade oidc/oauth2 para spa e serviços realm dedicado autonomous center; jwks em auth centralit com br hyperagent plataforma de agentes para ação autônoma sobre eventos críticos duas superfícies /api/hyper (board key) e /api/orchestration (api key) sincronização periódica configurada por hyperagent sync interval ms notificações (slack, teams, webhook, whatsapp) disparo de alertas por canal com filtros por severidade e responsável configurado no center; whatsapp por template; suporta janela de silêncio e reenvio manual com diagnóstico gestão de documentos e anexos o autonomous não é uma plataforma orientada a documentos e contratos, e por isso não implementa gestão documental no mesmo sentido de um crm ou de um sistema jurídico a camada equivalente na plataforma é a gestão de artefatos operacionais e evidências de investigação, com as seguintes práticas identificadas dossiê de investigação — briefing estruturado gerado por ia para eventos críticos (resumo executivo, hipóteses, evidências, próximos passos, impacto ao negócio, nível de confiança) é persistido junto ao evento e pode ser exportado em pdf pela event intelligence anexos e evidências operacionais em ocorrências e eventos — arquivos e artefatos podem ser vinculados ao caso investigado, respeitando o perfil e o contexto de acesso prompts editáveis de ia — as instruções de ia da plataforma são editáveis nas configurações gerais, com validação e proteção contra manipulação (challenge de board key) configurações versionadas — configurações de coletores, políticas de descarte, regras de processamento, regras de correlação e canais de notificação são versionadas com histórico de alterações consultável auditoria e rastreabilidade a rastreabilidade é um requisito transversal do autonomous o ciclo de vida de um evento é uma máquina de estados validada no servidor, com controle de concorrência (para impedir que dois operadores se atropelem) e auditoria por transição as transições típicas são registrado → reconhecido → em andamento → enviado para ação → fechado, com descartar e reabrir como caminhos alternativos, e o fechamento exige categoria de resolução e causa raiz evento auditável descrição recomendada criação e transição de evento registrar usuário responsável, timestamp, estado anterior/posterior e comentário quando aplicável fechamento de evento registrar categoria de resolução obrigatória e causa raiz declarada, alimentando relatórios e aprendizado descarte de ocorrência ou evento registrar usuário, motivo e política/regra aplicada envio para ação autônoma (hyperagent) registrar identificador do incidente na plataforma hyperagent e resultado da sincronização periódica em event hyper issue alteração de coletor / regra / política registrar quem alterou, o quê e quando, com histórico versionado enrolamento e check in do autonomous agent registrar bootstrap token utilizado, host de origem e horário do check in via assets integração externa (webhook, syslog, otlp) registrar requisição, resposta, sucesso ou falha e identificador de correlação (trace id, quando disponível) acesso a dado sensível registrar quando aplicável, respeitando os controles de pii descritos na seção 17 a telemetria interna dos próprios serviços (dogfooding) via opentelemetry contribui para a rastreabilidade técnica, permitindo correlacionar chamadas entre backend, collector, discovery, pipeline e assets a partir de um mesmo trace id segurança da informação a arquitetura adota os seguintes controles para reduzir riscos de acesso indevido, manipulação de dados e exposição de informações sensíveis autenticação centralizada por keycloak (oidc/oauth2) em ambientes produtivos, com pkce s256 na spa e validação de jwt como resource server no backend segregação de credenciais postgres do autonomous assets, com dois roles dedicados (inventory ro apenas para leitura no schema public e assets rw apenas para o schema inventory) board key do hyperagent persistida cifrada em banco (aes) e jamais retornada ao frontend ou registrada em log api key exigida no autonomous discovery em cada requisição rest (post /api/discovery/scan) bootstrap token no enrolamento do autonomous agent, comunicado ao assets no primeiro check in mascaramento de pii (cpf, cnpj, e mail) por design na análise por ia na borda do collector, alinhado às diretrizes de lgpd segurança embutida na coleta do discovery — endurecimento contra injeção de comando e manipulação de credenciais configurações centralizadas no center e aplicadas automaticamente aos coletores, sem exposição de segredos em cada host validação de campos obrigatórios e categorias de fechamento antes da persistência de transições de estado separação entre ambientes por variáveis de env, incluindo prefixos de projeto no docker compose (compose project name) e offset de portas para evitar colisão entre workspaces paralelos restrição das origens cors via cors allowed origins quando ligada a autenticação real do assets ia generativa on premise disponível como opção, mantendo o dado no cliente sem depender de provedores externos governança de dados e lgpd o autonomous manipula dados operacionais de infraestrutura (logs, métricas, traces, eventos), dados de ativos (inventário/cmdb) e, potencialmente, dados pessoais presentes em logs corporativos a arquitetura observa princípios de necessidade, finalidade, controle de acesso, rastreabilidade e proteção de dados sensíveis tipo de dado exemplos controle recomendado dados de observabilidade logs, métricas, traces, eventos, ocorrências índices dedicados no opensearch, retenção configurável por índice, acesso restrito por perfil e políticas de descarte no collector dados de inventário hosts, endereços ip, softwares instalados, versão de so, dispositivos de rede persistido no schema inventory do assets, com role de escrita restrita (assets rw); check in do agente autenticado por bootstrap token dados de vulnerabilidade cve, cpe, epss, kev, matching ativo↔cve persistido nos schemas do pipeline; visões auto cve como contrato estável de leitura para o center dados pessoais em logs cpf, cnpj, e mail, ip de usuário, cabeçalhos com identificadores mascaramento de pii por design na análise por ia na borda; políticas de descarte e clusterização por fingerprint reduzem retenção incidental credenciais e segredos operacionais board key do hyperagent, api keys, senhas de banco board key cifrada em banco (aes); segredos operacionais em variáveis de ambiente e não em logs configurações e histórico regras, coletores, políticas, service groups versionamento com histórico consultável; alterações críticas registradas em log operacional cenários de falha e continuidade cenário impacto comportamento esperado mitigação falha no keycloak usuários podem não conseguir autenticar via spa bloqueio seguro do acesso; apis com jwt válido em cache continuam operando até expiração; jwks é buscado sob demanda monitoramento do idp, plano de contingência e comunicação operacional imediata falha em integração externa (wazuh, zabbix, ioc provider, nvd, epss, kev) enriquecimento pode ficar defasado; jobs de ingestão do pipeline podem falhar manter fluxo interno com dados já ingeridos; registrar falha e agendar retentativa retentativas controladas, fallback manual e alerta operacional; etl registra em pipeline ops etl sync log falha na conexão postgresql persistência de configurações, ativos e ciclo de vida pode falhar retornar erro controlado nas apis afetadas e evitar perda de dados por rollback transacional monitoramento do datasource, reprovisionamento das roles postgres e restauração a partir de backup falha no opensearch pesquisas, dashboards, eventos e correlações ficam indisponíveis registrar falha, degradar dashboards e bloquear consultas dependentes cluster opensearch monitorado, snapshot recorrente e comunicação com bigdata dt/autonomous infra falha no autonomous agent em um host inventário daquele host fica defasado; check in não ocorre assets sinaliza ausência de check in; nenhum impacto direto no restante da stack reinstalar o agente localmente e refazer enrolamento com bootstrap token válido falha na ação autônoma (hyperagent) eventos críticos não são remediados automaticamente registrar tentativa e status; permitir reenvio manual e trilha de auditoria via event hyper issue reenvio manual pela event intelligence; validação do board key e da api key do hyperagent colisão entre workspaces paralelos dois docker compose podem competir pelos mesmos containers/portas compose project name e offset de portas isolam cada workspace manter o offset +10000 documentado no ac agent deploy/ env e nunca omitir compose project name requisitos técnicos mínimos ambiente docker com docker compose para orquestração local; maven e node js/npm para compilação dos componentes postgresql e opensearch como infraestrutura compartilhada, subida pelo repositório bigdata dt/autonomous infra (rede externa auto network) database autonomous no postgresql, com roles inventory ro e assets rw provisionados conforme scripts documentados no readme do repositório principal cluster opensearch em https na porta 9200 com credenciais fornecidas em opensearch username e opensearch password acesso aos cinco repositórios gitlab do produto autonomous center principal, autonomous center, autonomous collector, autonomous discovery e autonomous pipeline; o repositório autonomous assets é adicional arquivo env com as variáveis do docker compose corretamente preenchidas por ambiente keycloak configurado com realm dedicado (autonomous center em ambientes controlados) e clients front manager e autonomous agent quando a autenticação estiver ligada opentelemetry collector interno para dogfooding, quando o dogfooding estiver ligado por java tool options plano de execução para /b sh setup, /b sh validate e /b sh healthcheck após a subida rede corporativa com visibilidade dos ativos a serem descobertos pelo autonomous discovery bootstrap tokens para enrolamento do autonomous agent nos hosts monitorados limitações conhecidas a infraestrutura compartilhada (postgresql e opensearch) não faz parte deste docker compose e depende do repositório bigdata dt/autonomous infra estar disponível na mesma rede auto network o autonomous agent não é containerizado por design — ele precisa rodar como serviço no host que está sendo inventariado (windows service, systemd ou launchd) a configuração do keycloak no frontend está compilada no bundle (vite) trocar vite keycloak url, vite keycloak realm e vite keycloak client id exige rebuild da imagem a url de produção default embutida no dockerfile do frontend (https //itsmx centralit com br) é um default de outro ambiente e ainda não foi verificada como redirect uri válida para o realm autonomous center a ativação de inventory security enabled=true depende do fluxo oidc do frontend estar apontado para o client front manager do realm autonomous center a variável keycloak jwk set uri, mesmo com o security desligado, precisa de um placeholder não vazio (a auto configuração do spring security cria o bean jwtdecoder pela presença da propriedade) provisionamento do keycloak (client, roles, redirect uris e atribuição de usuários no realm central prd) depende de coordenação com o time iam/segurança da central it a conformidade regulatória (lgpd e demais) depende de políticas, contratos, evidências, retenção formal e controles operacionais adicionais recomendações de implantação validar pré requisitos de infraestrutura (docker, maven, node js, postgresql e opensearch compartilhados) antes do primeiro setup executar /b sh setup em ambiente limpo para clonar os sub repositórios, ajustar links simbólicos e subir a stack de forma idempotente executar as consultas sql de provisionamento de roles (inventory ro e assets rw) documentadas no readme do repositório principal antes de subir o autonomous assets em ambiente novo configurar as credenciais postgres do assets no env como center db user=inventory ro e inventory db user=assets rw, com senhas fortes por ambiente executar /b sh validate após a subida para confirmar opensearch/dashboards, backend, frontend, collector, discovery e o índice log intelligence executar /b sh healthcheck em ambientes kubernetes (via kubectl) para verificação avançada ativar opentelemetry via otel javaagent em java tool options apenas com um sampler apropriado (por exemplo, parentbased traceidratio com argumento 0 2) ligar inventory security enabled=true somente quando o fluxo oidc do frontend estiver apontado para o realm autonomous center executar smoke test de syslog tcp do collector quando syslog tcp enabled=true executar smoke test rápido do discovery via curl em post /api/discovery/scan com discoveryname=arp smoke validar integração com hyperagent nos dois eixos /api/hyper (board key cifrada) e /api/orchestration (bearer via hyperagent api key) formalizar aceite técnico, funcional e de segurança antes de promover para produção checklist de validação pergunta atendido? observação a arquitetura do sistema foi descrita sem escopo criptográfico governado pelo cliente? sim documento adaptado para arquitetura do autonomous os componentes principais foram listados? sim center (backend/frontend), collector, discovery, pipeline, assets, postgresql, opensearch, keycloak, hyperagent e opentelemetry o fluxo lógico da aplicação foi descrito? sim inclui autenticação oidc, coleta, descoberta, correlação, persistência, integrações e ação autônoma o modelo de autenticação e autorização foi explicado? sim oidc pkce s256 no frontend; oauth2 resource server no backend; realm dedicado autonomous center a camada de dados foi documentada? sim postgresql (schemas do center, inventory do assets, schemas do pipeline) e opensearch (índices log intelligence, traces, metrics, events, correlated) as integrações externas foram mapeadas? sim wazuh, zabbix, kafka, otlp, nvd, epss, kev, provedores de ioc, keycloak, hyperagent e canais de notificação as limitações foram informadas? sim incluídas de forma transparente na seção 21 há recomendações práticas de implantação? sim checklist de implantação na seção 22 glossário termo definição aiops inteligência artificial aplicada a operações de ti camada acima das fontes de monitoração que adiciona correlação, redução de ruído e narrativa de incidente autonomous center núcleo do produto backend spring boot + frontend vite/react; consome opensearch e postgresql; expõe apis de negócio, event intelligence e integração com hyperagent autonomous collector componente maven/java de captura, normalização, descarte, clusterização e correlação de borda autonomous discovery componente maven/java de descoberta ativa multi protocolo em rede autonomous pipeline componente spring boot de ingestão de vulnerabilidades (nvd/epss/kev), matching cpe↔software e cálculo de risco/comprometimento autonomous assets componente spring boot de inventário/cmdb com dois datasources segregados; media o enrolamento do autonomous agent autonomous agent binário go instalado no host monitorado (windows/systemd/launchd) que faz check in periódico contra o assets fingerprint impressão digital estrutural do log (mascara ips, datas e variáveis), base para deduplicação e correlação ocorrência linha de log estruturada e enriquecida (data, nível, equipamento, ip, regra, risco, fingerprint) — matéria prima da correlação evento grupo de ocorrências relacionadas tratado como caso único, com narrativa de ia e ciclo de vida auditado correlação multi estratégia combinação de cinco eixos (assinatura, ativo/grupo, grafo de rede, anomalia estatística e grupo de serviço) que agrupa ocorrências em eventos blast radius raio de impacto de uma falha derivado dos links de topologia do inventário health score nota de 0 a 100 que resume a saúde de um ativo com base em eventos, ameaças e correlações índice de comprometimento cruzamento entre inventário de ativos e vulnerabilidades conhecidas (cve / epss / kev), calculado pelo pipeline hyperagent plataforma de agentes que executa ação autônoma sobre eventos críticos e reflete status de volta ao center keycloak identity provider utilizado para autenticação oidc/oauth2; realm dedicado autonomous center em ambientes controlados opentelemetry padrão aberto de instrumentação (traces, métricas, logs) usado internamente para dogfooding via otlp e gateway otel collector opensearch cluster de indexação e busca utilizado para logs, ocorrências, métricas, traces, eventos e correlações jndi / datasource modelo de conexão de banco utilizado internamente pelos serviços java para acessar o postgresql compartilhado audit log registro de evento técnico ou funcional para rastreabilidade e conformidade