Sistemas de información en defensa: control de acceso y trazabilidad

El control por roles («ingeniero», «jefe de programa», «administrador») resuelve la mayoría de aplicaciones empresariales, pero se queda corto cuando el criterio de acceso depende del dato. En defensa es habitual que dos ingenieros con el mismo puesto tengan accesos distintos porque trabajan en programas diferentes, tienen habilitaciones distintas o pertenecen a empresas distintas de un mismo consorcio.

Por eso estos sistemas suelen combinar roles con atributos: cada registro o documento lleva metadatos (programa, compartimento, nivel de sensibilidad, organización propietaria, restricciones de nacionalidad si las hubiera) y cada usuario tiene atributos equivalentes con fecha de validez. El acceso se concede solo si se cumplen todas las condiciones. Es lo que se conoce como control de acceso basado en atributos, y la guía de autorización de OWASP lo recomienda frente a los roles puros para aplicaciones con reglas finas.

• Denegar por defecto: si no hay una regla que permita el acceso, no lo hay.
• Comprobar el permiso en cada petición en el servidor, no solo al mostrar u ocultar botones en la interfaz.
• Aplicar el filtro también a búsquedas, exportaciones, informes e integraciones; son las vías por donde más se escapa información.
• Dar a los atributos del usuario una fecha de caducidad y revisarlos periódicamente: una habilitación vencida debe cortar el acceso sin intervención manual.
• Prever accesos temporales y excepcionales con aprobación explícita y caducidad automática.

Una traza útil permite responder, meses después, a preguntas como «¿quién consultó la revisión C de este plano entre marzo y abril?» o «¿quién cambió el estado de esta orden de mantenimiento y con qué justificación?». Para eso no basta con los registros técnicos del servidor: hace falta un registro de auditoría pensado desde el negocio.

El registro debe protegerse frente a manipulaciones: escritura solo por adición, copia a un almacenamiento separado al que no tengan acceso de escritura los administradores de la aplicación, y mecanismos para detectar huecos o alteraciones, como encadenar cada evento con un resumen criptográfico del anterior. También hay que decidir cuánto tiempo se conserva, quién puede consultarlo y qué no debe registrarse nunca: contraseñas, tokens de sesión o el contenido sensible en sí.

La segregación reduce el daño que puede causar un error o una persona con malas intenciones. En una aplicación de gestión para defensa se aplica en varios planos:

• De funciones: quien administra usuarios no debería poder concederse permisos a sí mismo ni borrar su rastro; quien revisa la auditoría no debería ser quien administra la aplicación.
• De datos: la información de cada programa o compartimento se separa lógicamente y, cuando el riesgo lo justifica, también físicamente, en bases de datos o instalaciones distintas.
• De entornos: desarrollo, pruebas y producción separados; el equipo de desarrollo trabaja con datos sintéticos o anonimizados, nunca con información real.
• De redes: si el sistema opera en una red aislada, el diseño debe contemplarlo desde el principio, con actualizaciones y dependencias que puedan entregarse por medios controlados.

Este último punto tiene consecuencias de ingeniería que a menudo se descubren tarde: no se puede depender de servicios en la nube pública, de descargas de paquetes durante la instalación ni de telemetría externa. El software tiene que poder construirse y desplegarse a partir de un paquete verificable, con un inventario de componentes que el cliente pueda revisar.

Imagina tres empresas que colaboran en un programa y comparten un repositorio de documentación técnica. Cada documento pertenece a una de ellas y tiene un nivel de difusión: solo la empresa propietaria, todo el consorcio o una lista concreta de personas. Un sistema podría modelarlo así: cada documento lleva propietario, programa y nivel; cada usuario, empresa, programas autorizados y fecha de validez de su autorización. Las búsquedas filtran antes de devolver resultados, de modo que un usuario ni siquiera sabe que existe un documento que no puede ver.

Cada descarga genera un evento con la versión exacta, y se puede añadir una marca visible con el nombre del usuario y la fecha en el propio archivo. Si una empresa sale del consorcio, basta con revocar sus atributos para que sus usuarios pierdan el acceso, mientras la auditoría conserva el historial de lo que consultaron.

• Cuentas genéricas compartidas por turnos, que hacen imposible atribuir acciones.
• Permisos que se acumulan con los cambios de puesto y nunca se retiran.
• Exportaciones a hoja de cálculo que sacan la información del perímetro controlado sin dejar rastro de su destino.
• Registros de auditoría que nadie revisa: sin un procedimiento de revisión, la traza solo sirve después del incidente.
• Administradores técnicos con acceso total a los datos de negocio porque «es más cómodo».

1. ¿Basta con roles o el acceso depende de atributos del dato y del usuario? Si dos personas con el mismo puesto deben ver cosas distintas, necesitas atributos.
2. ¿Qué eventos deben quedar registrados, incluidas las lecturas, y quién revisará esa información y con qué periodicidad?
3. ¿Qué funciones deben estar separadas y cómo se impide que una sola persona las reúna?
4. ¿El sistema operará en una red aislada? Si es así, ¿cómo se entregarán actualizaciones y dependencias?
5. ¿Qué requisitos impone el programa o la autoridad competente, y quién en tu organización es responsable de demostrarlos?

Estas decisiones condicionan el modelo de datos y la arquitectura, así que conviene tomarlas al inicio. Si estás planteando una aplicación con permisos finos y trazabilidad exigente, nuestra capacidad de identidad, permisos y auditoría describe cómo podemos diseñarla, siempre partiendo de los requisitos que te marquen tus responsables de seguridad.