O InvGate Asset Management agora governa bancos de dados como ativos. Ele descobre instâncias em cinco engines, sinaliza as que rodam versões que o fornecedor não suporta mais, mapeia o que depende delas e captura evidência registrada antes que uma mudança crítica em um registro de banco de dados seja salva.
Os bancos de dados ficaram fora do registro de ativos na maioria das organizações, administrados por quem é dono deles e redescobertos durante uma auditoria. Este artigo aborda o que o InvGate Asset Management descobre, como o status de suporte e as dependências aparecem nesse registro, e o que a etapa de evidência captura quando algo muda.
O que o InvGate Asset Management descobre
O discovery é executado a partir do agente já instalado no host, que detecta os serviços de banco de dados em execução ali e informa o que é cada instância e como ela está configurada. A forma de conexão varia conforme o engine: PostgreSQL e SQL Server são configurados como Discovery Sources, enquanto MySQL, Oracle e MariaDB são coletados sem nenhuma credencial de banco de dados. Cada instância descoberta chega como um CI (item de configuração) que contém:
- Engine e versão.
- Endereço IP e porta.
- Uptime e arquitetura.
- O servidor host em que ela é executada.
- Os bancos de dados que ela hospeda.
Os registros são atualizados no ciclo regular de inventário do agente, então as instâncias aparecem, mudam e desaparecem do inventário sem que ninguém as insira à mão. Uma equipe de TI da área de saúde que executa o discovery antes de uma auditoria pode encontrar uma instância de MySQL 5.7 com quatro anos que ninguém conhecia, já fora do suporte do fornecedor, a tempo de desativá-la antes de o auditor chegar.
Visibilidade do ciclo de vida com o Atlas
O Atlas preenche o status de EoL (fim de vida) e EoS (fim de suporte) por versão de engine diretamente no CI, então ninguém precisa cruzar a documentação do fornecedor uma instância por vez. A cobertura acompanha o que cada fornecedor publica, então ela varia conforme o engine e a versão, em vez de abranger todas as versões.
O ganho é planejar em vez de reagir. Uma equipe de universidade que gerencia 47 instâncias em três ambientes pode ordenar por data de fim de suporte e ver exatamente o que precisa de atualização nos próximos doze meses, o que transforma um trabalho de coleta de várias semanas em um filtro.
Mapeamento de dependências com conexões de CIs
Os bancos de dados participam da mesma camada de conexões de CIs que o resto do parque, ao lado de ativos, pessoas, ativos de nuvem e aplicações de negócio. Cinco tipos nativos já vêm prontos para uso:
- Proprietário técnico.
- Proprietário comercial.
- Auditor de segurança.
- Executado em.
- Armazenado em.
Dois deles carregam a maior parte do peso para um banco de dados: “Executado em” liga o banco ao ativo ou ativo de nuvem que o hospeda, e “Armazenado em” liga a onde ele está armazenado. Toda conexão registra uma criticidade, baixa, média ou alta, e aparece na aba CIs relacionados dos dois perfis no momento em que é criada, então ela é escrita uma vez e lida a partir de qualquer uma das pontas. Organizações que nomeiam as coisas do seu próprio jeito podem adicionar os próprios tipos em Configurações.
As conexões são declaradas, não inferidas: uma pessoa registra que este banco de dados sustenta aquela aplicação, e essa declaração é o que o mapa mostra. Manter isso atualizado não é manual: uma mudança pode disparar uma automação, e uma conexão cuja outra ponta desaparece é limpa ou sinalizada para revisão. O julgamento continua com uma pessoa.
Evidência de mudança em uma mudança governada
Toda mudança em um CI já é registrada em "Atividades", que registra o que mudou. A governança acrescenta o que "Atividades" deixa de fora: quando ela está habilitada, uma mudança em uma propriedade crítica de um item de configuração de banco de dados dispara uma etapa de captura de evidência, na qual a pessoa que faz a mudança registra o autor real, a data efetiva e o motivo por trás dela. As propriedades críticas incluem status, proprietário, outras propriedades nativas e campos personalizados.
O que isso acrescenta é específico. As Atividades não conseguem dizer por que uma mudança foi feita, quem a autorizou ou se a pessoa que editou o registro é a mesma que fez a mudança no mundo real, e essas são as perguntas que uma revisão de segurança faz meses depois. Um DBA que reatribui a propriedade de uma instância de produção fornece esse contexto na hora, e a revisão lê o relato completo no histórico de mudanças.
Conclusão
Um banco de dados tem uma versão, um proprietário, um host, um ciclo de vida e uma data depois da qual ninguém aplica patches. Governá-lo como um ativo significa que o discovery o coloca no registro, o Atlas marca o status de suporte dele, as conexões de CIs mostram o que ele sustenta, e a etapa de evidência registra quem o mudou e por quê.
Os quatro funcionam no mesmo registro que o resto do parque, então nada disso roda como um exercício separado ao lado do Asset Management. Você pode executar o discovery no seu próprio ambiente com uma avaliação gratuita de 30 dias, ou falar com a equipe de Vendas para definir quais engines e ambientes estão ao alcance.
