Seguridad informacional: ¿Por qué perfiles y no manejo de usuarios individuales?

La seguridad informacional se administra bien cuando se establecen
perfiles para cada comunidad de usuarios y para cada tipo de documentos

Llevamos varias semanas con el tema de la seguridad informacional. Hemos hecho la observación de que hay varias perspectivas complementarias en la conversación de seguridad, algunas de ellas más cercanas a los temas duros de la ingeniería y otras más vinculadas con el tema de la gestión de contenidos y de servicios. Todas ellas son muy importantes para el gerente de servicios de información o el desarrollador de aplicaciones. Hoy queremos trabajar un poco con la relación entre la gestión de perfiles de comunidades de usuarios y la seguridad, un punto clave en Arquitectura de información.

Es claro para todo el que ha administrado un servicio de información que siempre hay que gestionar la seguridad y, como vimos en nuestro último post (Ver), la conversación no se acaba cuando hablamos de disponibilidad, confidencialidad e integridad.

Hay un punto muy importante y es acceso. En un servicio en funcionamiento, cada persona tiene que tener la posibilidad de acceder a los contenidos que requiere y a la funcionalidad que necesita para manejar esos contenidos. Quizá consultar cierta información es suficiente, pero en muchas ocasiones se requiere la posibilidad de modificar los contenidos, crearlos e, incluso, eliminarlos. También hay que considerar otras funciones: diseminación, validación, autorizaciones, etc.

Una manera de manejar estas operaciones puede ser el darle, a través de un sistema, autorizaciones a cada persona para marcar lo que ésta puede o no puede hacer. Precisamente allí está el punto que queremos señalar hoy. En términos informáticos este control por persona es posible y puede hacerse muy minuciosamente. Sin embargo es completamente desaconsejado. Ningún Arquitecto de Información lo recomendaría. ¿Por qué?

La razón es que este esquema de controlar lo que una persona individualmente puede hacer no escala, no permite crecimiento y por eso choca con una parte crucial de lo que el Arquitecto de Información debe estar siempre pendiente: la escalabilidad del servicio. Suena perfecto, minucioso y hasta meritorio establecer lo que una persona pueda realizar con cada funcionalidad del sistema. Sin embargo, un sistema así no es administrable.

En la práctica los sistemas son entes vivos que tienen una dinámica que cambia y en la vida institucional el rol de las personas dentro de las organizaciones suele cambiar también. Cuando alguien se va de vacaciones o se enferma, por ejemplo, puede haber un movimiento temporal de roles. Es demasiado complicado que cuando se incorporen nuevas funcionalidades, o cuando se cambien temporal o en forma permanente procesos previamente establecidos, haya que tener que recorrerse, persona por persona, la lista de usuarios, para ajustar lo que cada una puede hacer o lo que cada una no puede hacer. Si el sistema fuera algo usado por una decena de personas quizá podría funcionar, pero en la práctica, incluso con una pocas decenas de personas es inmanejable el tema del control de la funcionalidad y de la seguridad si no tenemos comunidades y perfiles asociados a ellas. Estos perfiles los usamos para controlar lo que cada quien tiene acceso como contenido y como funcionalidad. La experiencia señala que lo que cada quien puede hacer con la información a la que tiene acceso depende de las comunidades a las que pertenece.

Este tipo de gestión de la seguridad por comunidades de usuarios permite administrar sistemas reales donde los cambios están a la orden del día.

A veces se argumenta que una persona es muy especial y que ella tiene que poder hacer, individualmente, algo que no está en ningún perfil. Esta argumentación es insostenible. No suele ser cierta, pero incluso si lo fuera, lo que estamos definiendo es un rol y por tanto un perfil de una comunidad en la que, aparentemente, hoy hay sólo una persona, cosa que, por cierto, siempre recomendamos revisar.