Estrutura de Ativos

Na gestão de ativos, um framework é o modelo que transforma registros dispersos de equipamentos e licenças em um programa governado. Ele define quatro coisas: uma taxonomia de categorias de ativos, um ciclo de vida com etapas que cada ativo percorre, papéis que atribuem propriedade, custódia e supervisão, e regras de decisão para aprovar, alterar e descartar ativos. Ele existe para que as respostas a perguntas práticas venham de uma política, não de improviso. Um departamento pode comprar os próprios notebooks? Quem aprova a compra de um software?

O termo é mais amplo do que qualquer registro ou banco de dados. Uma planilha de números de série não é um framework, e uma ferramenta de descoberta também não é, por mais completa que seja a varredura. O framework é o conjunto de definições e responsabilidades que decide o que esses registros devem conter, quem os mantém e quais decisões eles alimentam. Dentro da gestão de ativos de TI, ele é a estrutura que as ferramentas automatizam. Elas não o substituem.

Um framework começa dividindo a população de ativos em categorias. A categoria determina tudo o que vem depois: quais atributos são registrados, quais controles se aplicam, quem é o dono natural e como o ativo é avaliado. Uma taxonomia típica em empresas distingue as cinco categorias abaixo.

Duas regras sustentam a taxonomia. As categorias devem ser mutuamente exclusivas, para que cada ativo ocupe exatamente um lugar na estrutura. Devem também ser coletivamente exaustivas, para que nada em que a organização gasta dinheiro fique de fora. Cada categoria precisa de uma regra de nomenclatura e etiquetagem, descrita em identificação de ativos. Quando um novo tipo de ativo não se encaixa, o próprio framework é alterado. Listas improvisadas fora dele são onde começa o shadow IT.

Nenhuma organização precisa criar um framework do zero. Há vários corpos de prática amplamente adaptados. A série ISO 55000 descreve um sistema de gestão de ativos em termos genéricos: decisões alinhadas sobre ativos, o ciclo planejar-fazer-verificar-agir e uma linha de visão da política até cada ativo individual. A ITIL trata a gestão de ativos como prática de gestão de serviços e liga o ciclo de vida do ativo à entrega de serviços, aos registros de configuração e ao banco de dados de gerenciamento de configuração. A visão de segurança acrescenta o requisito de inventário. A NIST SP 800-53 espera um inventário completo e atualizado dos componentes do sistema, revisado em intervalos definidos. A ISO/IEC 27001 exige um inventário de ativos com responsabilidade atribuída.

Organizações maduras raramente adotam uma referência por inteiro. O padrão comum é uma camada de governança no estilo ISO 55000, a ligação com o ciclo de vida no estilo ITIL e um requisito de inventário orientado à segurança, adaptados à escala e ao perfil de risco da organização.

O ciclo de vida é a espinha dorsal do framework. Cada ativo está sempre em exatamente uma etapa, e cada etapa tem critérios de entrada, critérios de saída e um papel responsável. O modelo clássico tem cinco etapas:

1. 1

   Planejar

   Os requisitos são identificados, os orçamentos aprovados e os padrões de compra definidos. Registros-chave: padrões aprovados, linhas de orçamento.

2. 2

   Adquirir

   O ativo é comprado, alugado ou recebido, depois registrado e etiquetado. Registros-chave: nota de compra, entrada no inventário, etiqueta do ativo.

3. 3

   Implantar e operar

   O ativo é configurado, entregue, mantido e revalidado periodicamente. Registros-chave: histórico de atribuições, registros de manutenção.

4. 4

   Alterar

   Realocação, atualização, redistribuição ou reclassificação conforme o uso evolui. Registros-chave: histórico de mudanças, atributos atualizados.

5. 5

   Descartar

   O ativo é desativado, seus dados são removidos e o equipamento é reutilizado, vendido ou destruído. Registros-chave: registro de baixa, evidência de sanitização.

O modo de falha mais comum é comprar uma ferramenta e dar o trabalho por encerrado. Um agente de descoberta que lista cada endpoint não é um framework, e um banco de gerenciamento de configuração também não. O framework é o acordo sobre categorias, propriedade, etapas e direitos de decisão que esses sistemas registram e aplicam. A ferramenta é onde os registros ficam. Sem framework, a saída da ferramenta vira uma lista sem dono. Sem ferramenta, o framework se afoga em manutenção manual.

O teste prático é saber se a organização consegue responder a partir de seus registros, não da memória. Que ativos temos? Quem responde por cada um? Em que etapa do ciclo de vida cada um está? Quando a resposta foi verificada pela última vez? Um framework sólido torna essas perguntas rotineiras. Um fraco transforma cada uma em uma investigação.

No Anexet Inventory, o cartão de cada estação de trabalho tem uma aba Devices que lista cada componente com seu tipo e fabricante. No cartão de um servidor, a mesma aba acrescenta as colunas de número de inventário e número de série, para que o registro possa ser conferido com as notas de compra e o estoque físico.

1 / 2

• 
• 

O framework atribui o trabalho a papéis nomeados, não a quem perceber um problema primeiro. O conjunto de papéis é pequeno e estável, e cada um responde por uma decisão:

Comece pelas categorias e seus donos, não pelo software. Nomeie um dono para cada categoria, combine as cinco etapas do ciclo de vida e só então escolha uma ferramenta que registre o que o framework já decide. Conecte cedo o framework à gestão de licenças de software, porque é nas licenças que o custo e o risco de uma lista sem dono aparecem primeiro.