Marco de Activos

En la gestión de activos, un framework es el modelo que convierte registros dispersos de equipos y licencias en un programa gobernado. Define cuatro cosas: una taxonomía de categorías de activos, un ciclo de vida con etapas por las que pasa cada activo, roles que asignan propiedad, custodia y supervisión, y reglas de decisión para aprobar, cambiar y retirar activos. Existe para que las respuestas a preguntas prácticas provengan de una política y no de la improvisación. ¿Puede un departamento comprar sus propias laptops? ¿Quién aprueba una compra de software?

El término es más amplio que cualquier registro o base de datos. Una hoja de cálculo con números de serie no es un framework, y tampoco lo es una herramienta de descubrimiento, por completa que sea su escaneo. El framework es el conjunto de definiciones y responsabilidades que decide qué deben contener esos registros, quién los mantiene y qué decisiones alimentan. Dentro de la gestión de activos de TI, es la estructura que las herramientas automatizan. No la reemplazan.

Un framework empieza dividiendo la población de activos en categorías. La categoría determina todo lo que sigue: qué atributos se registran, qué controles aplican, quién es el propietario natural y cómo se valora el activo. Una taxonomía empresarial típica distingue las cinco categorías siguientes.

Dos reglas hacen funcionar la taxonomía. Las categorías deben ser mutuamente excluyentes, para que cada activo ocupe exactamente un lugar en la estructura. También deben ser colectivamente exhaustivas, para que nada en lo que la organización gasta quede fuera. Cada categoría necesita una regla de nombrado y etiquetado, descrita en identificación de activos. Cuando un tipo de activo nuevo no encaja, se modifica el propio framework. Las listas improvisadas fuera de él son donde empieza el shadow IT.

Ninguna organización necesita inventar un framework desde cero. Hay varios cuerpos de práctica muy adaptados. La serie ISO 55000 describe un sistema de gestión de activos en términos genéricos: decisiones alineadas sobre los activos, el ciclo planificar-hacer-verificar-actuar y una línea de visión desde la política hasta cada activo individual. ITIL trata la gestión de activos como una práctica de gestión de servicios y vincula el ciclo de vida del activo con la entrega del servicio, los registros de configuración y la base de datos de gestión de la configuración. La visión de seguridad añade el requisito de inventario. NIST SP 800-53 espera un inventario completo y actualizado de los componentes del sistema, revisado en intervalos definidos. ISO/IEC 27001 exige un inventario de activos con propiedad asignada.

Las organizaciones maduras rara vez adoptan una referencia completa. El patrón habitual es una capa de gobierno al estilo ISO 55000, un vínculo con el ciclo de vida al estilo ITIL y un requisito de inventario orientado a la seguridad, adaptados a la escala y al perfil de riesgo de la organización.

El ciclo de vida es la columna vertebral del framework. Cada activo siempre está en exactamente una etapa, y cada etapa tiene criterios de entrada, criterios de salida y un rol responsable. El modelo clásico tiene cinco etapas:

1. 1

   Planificar

   Se identifican los requisitos, se aprueban los presupuestos y se fijan los estándares de compra. Registros clave: estándares aprobados, partidas presupuestarias.

2. 2

   Adquirir

   El activo se compra, se arrienda o se recibe, y luego se registra y se etiqueta. Registros clave: factura de compra, alta en el inventario, etiqueta del activo.

3. 3

   Desplegar y operar

   El activo se configura, se entrega, se mantiene y se revalida periódicamente. Registros clave: historial de asignaciones, registros de mantenimiento.

4. 4

   Cambiar

   Reubicación, actualización, reasignación o reclasificación a medida que evoluciona el uso. Registros clave: historial de cambios, atributos actualizados.

5. 5

   Retirar

   El activo se da de baja, sus datos se eliminan y el equipo se reutiliza, se vende o se destruye. Registros clave: acta de baja, evidencia de sanitización.

El fallo más común es comprar una herramienta y dar el trabajo por hecho. Un agente de descubrimiento que lista cada endpoint no es un framework, como tampoco lo es una base de datos de gestión de la configuración. El framework es el acuerdo sobre categorías, propiedad, etapas y derechos de decisión que esos sistemas registran y hacen cumplir. La herramienta es donde viven los registros. Sin framework, la salida de la herramienta se convierte en una lista sin dueño. Sin herramienta, el framework se ahoga en el mantenimiento manual.

La prueba práctica es si la organización puede responder a partir de sus registros y no de la memoria. ¿Qué activos tenemos? ¿Quién responde por cada uno? ¿En qué etapa del ciclo de vida está cada uno? ¿Cuándo se verificó la respuesta por última vez? Un framework sólido convierte estas preguntas en rutina. Uno débil convierte cada una en una investigación.

En Anexet Inventory, la ficha de cada estación de trabajo tiene una pestaña Devices que enumera cada componente con su tipo y fabricante. En la ficha de un servidor, la misma pestaña añade columnas de número de inventario y número de serie, de modo que el registro puede cruzarse con las facturas de compra y el stock físico.

1 / 2

• 
• 

Un framework asigna el trabajo a roles con nombre, no a quien note primero un problema. El conjunto de roles es pequeño y estable, y cada uno tiene una decisión que le corresponde:

Empiece por las categorías y sus dueños, no por el software. Asigne un responsable a cada categoría, acuerde las cinco etapas del ciclo de vida y solo entonces elija una herramienta que registre lo que el framework ya decide. Conecte pronto el framework con la gestión de licencias de software, porque las licencias son donde primero aparecen el costo y el riesgo de una lista sin dueño.