viernes, 31 de agosto de 2012

Seguridad informacional cuando se tienen varios perfiles

Muchas personas tienen varios perfiles. Esto hay que tomarlo en cuenta
cuando se diseña la seguridad de una solución de gestión de información.
(Imagen tomada de  http://www.freepik.es)

La semana pasada introdujimos el concepto de Modelos de seguridad. Fue en el contexto de la conversación de seguridad informacional desde la perspectiva de las conversaciones entre el Gerente de servicios de información y el Arquitecto de información. Vimos que, como habíamos estado conversando en las semanas anteriores, la seguridad se maneja en los servicios modernos a través de perfiles que se les asignan a cada una de las comunidades de usuarios con las que se trabaja. El problema se complica cuando caemos en cuenta que muchas personas no tienen un único perfil, sino varios. No pertenecen a una única comunidad, sino a varias. Eso nos lleva a hacernos la pregunta de ¿cómo afecta la pertenencia a múltiples perfiles a nuestros modelos de seguridad informacional?

El hecho de que una persona pertenezca a varias comunidades y por tanto tenga varios perfiles se toma en cuenta en Arquitectura de Información entendiendo que existen cuatro modelos a seguir: Permisos individuales, Permisos de grupo, Permisos de unión de grupos y Permisos de intersección de grupos. No hay una solución única. Es un problema que tiene que ver con el cómo nos parece que representamos mejor la solución al problema de gestión de información sobre el que trabajamos y por supuesto, con la posibilidad de establecer el modelo diseñado con las herramientas que usamos para modelar nuestra particular Arquitectura de información.

Describimos brevemente a continuación los dos primeros modelos mencionados y dejamos para la siguiente oportunidad los otros dos:

Modelo de Permisos individuales: Consiste en definir para cada persona, individualmente, lo que puede hacer y lo que no puede hacer con el sistema que desarrollamos. Como hemos visto este modelo es poco aconsejable, a no ser que el número de personas sea menor que diez ya que, como explicamos en su oportunidad (ver Una persona no es un perfil: Todos tenemos varios perfiles), los sistemas son entes vivos, las condiciones cambian y resulta completamente impráctico tener que recorrer perfiles, persona por persona, cada vez que ocurre un cambio como, por ejemplo, la incorporación de un nuevo tipo de documento o de funcionalidad.

Modelo de Permisos de grupo: Consiste en establecer como norma que aunque cada persona tiene varios perfiles o pertenece a varias comunidades, en un momento dado, o, en un espacio de interacción dado, sólo está activo en una de ellas y por eso siempre se está claro bajo que perfil está conectado. Este perfil de conexión determina lo que puede y lo que no puede hacer en esas circunstancias.

Este modelo suele ser recomendable en una gran cantidad de situaciones, es bastante sencillo de operar y hace fácil a las personas estar consciente de sus distintos roles y perfiles organizacionales. La ventaja y desventaja para la persona es que, aunque pertenezca a varias comunidades, es explícito siempre bajo cual de ellas se está conectado porque se considera que, en un instante dado, se trabaja bajo un único y explícito rol, seleccionado por la persona entre sus múltiples perfiles. Por supuesto, la funcionalidad debe permitir cambiar este rol en cualquier momento y debe hacerlo visible en la pantalla para evitar equívocos.

Una de las ventajas de esta aproximación está en el poder que da a la persona de controlar su actividad y de asumir distintas perspectivas de trabajo. Así por ejemplo, la persona puede, en un momento dado, quitarse permisos temporalmente para trabajar en forma más segura. También puede adoptar un rol y ver lo que ven los miembros de una cierta comunidad a la que se pertenece, independientemente de que se pertenezca a otras con más o menos atribuciones.

viernes, 24 de agosto de 2012

Una persona no es un perfil: Todos tenemos varios perfiles

En la imagen, simultáneamente, el rostro de una mujer o una mariposa
que visita una flor. Los arquitectos de información modelan la realidad.
Pero un modelo es siempre una representación. Por lo que ante la
misma realidad pueden haber varios modelos válidos.
Hemos estado hablando de seguridad y de las distintas perspectivas con las que podemos entrarle al tema. Precisamente la semana pasada describimos por qué la seguridad informacional se trabaja, en forma práctica, a través de perfiles y no como un conjunto de permisos que tienen personas individuales. Queremos ahondar esta semana en más detalles sobre éste punto. Cuando una persona está en varias comunidades o cuando cumple varios roles en una organización, tiene varios perfiles. ¿Cómo manejamos lo que puede o lo que no puede acceder y hacer en un sistema? Es un tema de interés central para los directores de servicios de información y nos lleva a la necesidad de introducir el concepto de modelos de seguridad.
En primer lugar es importante tomar en cuenta que el Arquitecto de Información diseña soluciones de gestión que funcionen en un cierto ambiente de uso (el público en general, un conjunto de comunidades, una organización, etc). Una solución implica un modelo de información que debe tener la virtud de representar razonablemente la realidad del problema de gestión que se desea resolver, al tiempo que es lo suficientemente sencillo como para que pueda usarse en términos prácticos.
Precisamente la semana pasada (Seguridad informacional: ¿Por qué perfiles y no manejo de usuarios individuales?) vimos como suele ser imposible atender los requerimientos de seguridad de cualquier organización gestionando el control de lo que cada una de las personas, individualmente, puede hacer o no puede hacer, en cada caso, con cada situación, con cada tipo de objeto. Por eso se usan perfiles, es decir, abstracciones de lo que un grupo de personas con características comunes pueden hacer. Como las personas las agrupamos en Comunidades es natural que a cada comunidad le asociemos un perfil. Esto nos permite ser prácticos. Definimos lo que un conjunto de individuos puede hacer manejando perfiles de comunidades y no persona por persona. Hasta allí todo está bien, el problema es que en la realidad las personas suelen tener varios roles o pertenecer a varias comunidades y, en ocasiones, pueden querer o necesitar cambiar temporalmente sus roles o perfiles.
¿Cómo la gestión de la seguridad informacional toma en cuenta esto? ¿Qué permisos debe tener una persona que tiene varios roles o que pertenece a varias comunidades? Como veremos no hay una respuesta única, sino que se trabaja con el concepto de modelos de seguridad. A veces en forma implícita, a veces en forma explícita.
Existen, de entrada, cuatro modelos de seguridad simples de entender:
  1. Permisos individuales, por persona.
  2. Permisos de grupo, atendiendo uno solo de los roles escogido por el usuario, entre todos sus perfiles.
  3. Permisos de unión de grupos, sumando todos los permisos que tienen todos los roles de un usuario.
  4. Permisos de intersección de grupos, sumando todas las restricciones de todos los roles de un usuario.
El primero de estos modelos no es muy conveniente y lo analizamos la semana pasada. En las restantes soluciones hay ventajas y desventajas asociadas, que conviene examinar con más detalles y las analizaremos en nuestro próximo post.

viernes, 17 de agosto de 2012

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.

viernes, 10 de agosto de 2012

Confidencialidad, Disponibilidad e Integridad: ¿Qué falta en la conversación?

Dentro de una comunidad puede haber difusión de contenidos, mientras
que desde fuera de la comunidad no hay ningún tipo de acceso
(imagen desde  http://icetechnologies.com)

Con estas tres palabras, Confidencialidad, Disponibilidad e Integridad, muchas veces se resume el tema de la seguridad informacional. Pero, como observamos la semana pasada, la seguridad es una conversación que tiene perspectivas diferentes según se aborde desde la Arquitectura de Información o desde la Ingeniería Informática. Una orientación no es mejor que la otra, son enfoques diferentes y complementarios. Hoy continuaremos aportando algunas distinciones adicionales, procurando siempre mantener un lenguaje asequible tanto a directores de servicios de información como a desarrolladores de aplicaciones.

Retomemos la conversación desde los tres puntos claves en los que el Arquitecto de Información se centra, antes que nada, cuando trabaja el tema de seguridad:

1) Todo el que tiene que tener acceso a ciertos contenidos, debe tenerlos.
2) La funcionalidad debe permitir la operación segura, estable, de los sistemas de información y sus reglas.
3) En todo momento, la información debe mantener su integridad, como información.

Como al primero de estos puntos ya nos referimos (Ver Seguridad informacional bajo la perspectiva del Arquitecto de Información), trabajaremos hoy con los dos últimos:

La Arquitectura de información debe garantizar que la funcionalidad permita la operación segura, estable, de los sistemas de información y sus reglas. Cada quien no sólo debe tener acceso a ciertos contenidos de la base de información (punto uno), sino que debe poder hacer con ellos lo que se espera que pueda hacer. En esa dinámica de uso cotidiano, los contenidos crecen y se desarrollan, mientras la información debe mantener la coherencia, la estructura, la practicidad, la integridad con la que fueron definidas las reglas iniciales. Para un novel esto es algo que se da por hecho, sin embargo, en las dinámicas que impone el uso pueden haber degradaciones en la consistencia de la información o en las premisas que se hicieron cuando se construyó un sistema. De allí que lo sano sea, entre otras cosas, una cierta labor de medición y seguimiento de esta coherencia informacional y esto debe incluirse en las conversaciones y las actividades.

En el tercer punto se toca el aspecto de la Integridad. Hay que señalar que aunque en la literatura (y numerosas páginas de la Internet) se habla de ella, la conversación muchas veces se realiza dentro de marcos excesivamente tecnológicos que dejan de lado aspectos importantes de la gestión de información: En concreto, hay que distinguir lo que puede ser integridad de datos, que garantizan los informáticos en sus contextos y con sus herramientas, de la integridad de información con la que trabajan los Arquitectos de Información.

La conversación es interesante, porque puede haber integridad de datos sin que haya integridad en la información: Si se rompió la conexión entre uno de los títulos de un documento, o entre un cierto dato y el objeto de información al que pertenece, por ejemplo, lo más probable es que las revisiones de integridad de bases de datos señalen que éstas están correctas, pero las revisiones de integridad de información señalen las faltas.

El punto es que para el usuario final, la pérdida de integridad de información puede ser tan nefasta como la pérdida de integridad física de los dispositivos que la contienen.

Reuniendo los comentarios de la semana pasada (ver) con los de ésta podemos notar que aunque en muchos discursos se establece que la Seguridad de información tiene que ver con tres aspectos básicos: Confidencialidad, Disponibilidad e Integridad, en la práctica la discusión que se hace es, en demasiadas ocasiones, menos útil de lo que debería porque no se comprenden o no se abordan las diferencias y complementos entre los enfoques de la Informática y de la Arquitectura de información. En nuestra experiencia, si no se conversa adicionalmente sobre Acceso, Comunidades y Objetos de información y sobre Funcionalidad e Integridad dinámica de información se dejan por fuera aspectos que son claves para las organizaciones. En otras palabras, siempre hay que tener en cuenta que el estudio de la seguridad informacional tiene perspectivas y contextos.

viernes, 3 de agosto de 2012

Seguridad informacional bajo la perspectiva del Arquitecto de Información


En cada problema de desarrollo de espacios que requieren de construcción civil
funcional, las perspectivas del Ingeniero y del Arquitecto son complementarias.
Analogías existen en servicios de información (foto:  http://www.velavke.co.za  )
La semana pasada vimos que la Seguridad informacional tiene muchas aristas y mencionamos algunas de ellas, señalando en la conversación que el tema cambia de forma significativa los puntos claves y el lenguaje con el que se debe manejar según la perspectiva funcional que tomemos y que, por eso, siempre hay que aclarar de qué seguridad estamos hablando. Como veremos hoy, la aproximación a la seguridad en Arquitectura de Información resulta natural en las conversaciones cotidianas de los gerentes de servicios de información y por eso para los desarrolladores de soluciones y responsables de servicios resulta conveniente manejar las distinciones que exponemos a continuación.

Mucha de la literatura que leemos en la Internet no lo aclara, pero hay abordajes de Seguridad informacional que son más propios de Ingeniería informática y aproximaciones que están más ligadas a la Arquitectura de Información. Quizá con los primeros enfoques colocamos pilares para los segundos, pero la relación es de complementariedad y no de jerarquía.

Muy en concreto, la semana pasada mencionamos tres puntos críticos conversación de seguridad con el Arquitecto de Información: 1) Todo el que tiene que tener acceso a ciertos contenidos, debe tenerlos. 2) La funcionalidad debe permitir la operación segura, estable, de los sistemas de información y sus reglas. 3) La información debe mantener su integridad, como información. Comentemos:

En relación al primer punto, se dice fácil que hay asegurar todo el que tiene que tener acceso a ciertos contenidos lo tenga. Pero hay detalles que están vinculados con lo que se llama disponibilidad lógica y observaciones que hay que hacer sobre la confidencialidad. Veamos:

El acceso a los contenidos mencionado arriba requiere de la disponibilidad, e implica, desde luego, en la misma afirmación, un lado prohibitivo complementario: que no se tenga acceso a lo que no se debe tener, que ciertos contenidos luzcan como no disponibles. De allí que la disponibilidad lógica que ocupa al Arquitecto de Información no es la física que ocupa al Ingeniero de infraestructura. Es decir, no se trata de que los equipos estén encendidos, operacionales y las bases de datos estén trabajando. Eso es seguridad física. Antes bien el punto para el Arquitecto de información es que los contenidos deben estar accesibles según ciertas reglas establecidas institucionalmente para las comunidades involucradas en cada caso.

En relación a la confidencialidad, es importante entender algunas complejidades adicionales, propias del quehacer cotidiano institucional. En una organización las personas son miembros de equipos (comunidades, instancias organizativas) que comparten información: confidencialidad significa que desde afuera de una comunidad no se debe tener acceso a ciertos contenidos, pero hay que observar que internamente, dentro de la comunidad, puede haber hasta difusión. Este detalle hay que examinarlo en el contexto de cada tipo de contenido y cada comunidad involucrada o no con él. Como las propiedades son además dinámicas (varían en el tiempo) y como las personas pueden ser miembros de varias comunidades, se requiere de herramientas para manejar contenidos o bases de información. No son suficientes las herramientas básicas que proporcionan las bases de datos.

En nuestro próximo post comentaremos sobre los puntos dos y tres mencionados arriba y aportaremos algunas distinciones sobre seguridad informacional que son importantes tener claro cuando uno participa en equipos que desarrollan soluciones de gestión de información o cuando se es responsable de servicios.