viernes, 28 de septiembre de 2012

¿Cuanto tiempo se espera por un usuario?

Los usuarios descansan, atienden llamadas y necesidades varias. Por
ello, para un Arquitecto de Información y un Responsable de Servicios
de Información, la pregunta de cuánto tiempo esperar por un usuario
que se ha ido es absolutamente pertinente

La seguridad informacional es un tema permanente, que hay que definir muy bien, y que, cómo hemos estado viendo, tiene una perspectiva informática y una perspectiva informacional. Los responsables de servicios de información saben que uno de los factores que tienen que tomar en cuenta cuando definen cómo van a trabajar la seguridad es el tiempo en que se espera por un usuario, luego que éste interrumpe su trabajo por cualquier motivo. Dedicamos este post a este problema, muy simple, pero a veces muy importante por sus implicaciones en la seguridad…

Efectivamente, el hecho sucede cotidianamente, múltiples veces, en todas partes, en todo tipo de interacciones. En sistemas cuyo servicios principales son públicos y en sistemas cuyos servicios son todos o casi todos privados. Siempre hay tareas que son restringidas a ciertas personas, las que tiene un determinado perfil. Estas personas deben identificarse, de alguna manera, por ejemplo, lo más típico, indicando su nombre de conexión y su contraseña. Los esquemas de autenticación pueden variar de un caso a otro, de una institución a otra. Pueden ser muy simples o pueden ser muy sofisticados. Pueden resolverse en términos de una aplicación o pueden que sean resueltos en términos de una institución. No faltan los casos en que la autenticación se resuelve en términos de una macro institución, certificadora de autenticación para múltiples instituciones, a través de Internet.

Pero independientemente de que el procedimiento sea simple o complejo, local o no, el usuario se autentica. ¿Qué pasa luego? Con esa autenticación se identifica su perfil y con este perfil el usuario tiene acceso a determinados tipos de contenidos y a determinadas funciones sobre esos contenidos. El problema aparece porque siempre ocurre que los usuarios abandonan el contacto con el computador, bien sea ocasionalmente o bien en forma más definitiva, y los descuidos abundan. A veces porque se pensó en volver rápido y luego se sucedieron incidentes que impidieron el propósito y a veces, simplemente, por olvido. No faltan las ocasiones en que el problema se presenta por ignorancia en el procedimiento.

La pregunta pertinente es ¿Cuánto tiempo se debe esperar por un usuario que no ha vuelto hacer contacto con el teclado o el ratón? No hay una respuesta única correcta, cinco minutos de espera pueden ser suficientes y más, algo intolerable. Pero otras veces se debe ser mucho más flexible y se deben poder esperar lapsos mayores. Incluso mucho mayores, hay sistemas que esperan todo el día y sólo exigen reautenticación al día siguiente. Lo cierto es que si el usuario debe poder leer varias páginas de contenidos o revisar una cantidad de relaciones equivalentes, hay que estar dispuestos a esperar. Adicionalmente, es muy típico hoy en día que los usuarios sean multitareas, que hagan varias cosas a la vez, que tengan varias ventanas abiertas. Este hecho obliga a ser más laxos en los tiempos de espera en detrimento de la seguridad.

En los casos extremos hay que exigir al usuario concentración y, si éste se va con su atención a otra ventana durante un tiempo mayor del permitido, se le penaliza obligándolo a autenticarse de nuevo al momento en que vuelva con su atención. Por ejemplo, si se trata de un sistema bancario, es lógico que así sea y que los umbrales sean menores que otros que manejan contenidos menos delicados.

En el futuro, los sistemas biométricos sabrán quién es la persona que está al frente, pero lo que está claro es que hoy un Arquitecto de información y un Responsable de servicios deben poder conversar muchas cosas sobre seguridad, entre ellas, cuánto tiempo se espera por un usuario…

viernes, 21 de septiembre de 2012

Hay reglas generales de seguridad, pero a cada documento también se le da la palabra


Con Arquitectura de Información se diseñan reglas sobre tipos de documentos
 y comunidades. Pero cada instancia especifica de un tipo de objeto de
 información,  es decir,  cada documento concreto, tiene el derecho a convertirse
en una excepción.
Seguridad en tipos de documentos y en instancias de un tipo de documento. ¿Quién puede modificar qué? Continuando con las interesantes conversaciones acerca de la seguridad informacional hoy queremos analizar un poco más en detalle los elementos que intervienen en el cómo se toma la decisión de si el acceso a un documento se deja al alcance del usuario. Como veremos, las reglas generales cuentan, pero también lo que en específico dice el documento mismo acerca de quien puede acceder a su contenido, más allá del hecho que en un sistema o solución de gestión hay unas reglas generales para el acceso a cada tipo de documento, donde se toman en cuenta los perfiles de las distintas comunidades de usuarios y las características del tipo de documento en cuestión.

Como hemos estado viendo en las oportunidades anteriores, no hay una receta universal, sino orientaciones útiles a la hora de modelar sistemas de información. Los modelos no sólo tienen que permitir representar la realidad, también tienen que ser lo más simple posibles para que sean prácticos, entendibles por sus usuarios. Por eso se comienza siempre con unas reglas generales y simples que se van sofisticando a través de las iteraciones de diseño. Cada vez que se va a introducir un nuevo concepto o una nueva regla tenemos que revisar si ésta es necesaria o se puede vivir sin ella, porque mientras más simples sean los modelos de información que construyamos, más fácil será su mantenimiento.

Como hemos visto se comienza por establecer la estructura de cada tipo de documento y luego su funcionalidad. Luego se analizan la relación que ese tipo de documento tiene con cada comunidad de usuarios y se establece entonces lo que cada comunidad debe poder hacer con los documentos de ese tipo. Para atender a las personas que tiene varios perfiles o pertenecen a varias comunidades se define el modelo de seguridad con el que se trabaja (Ver: Seguridad informacional cuando se tienen varios perfiles). Todavía puede ser que hablar de modificación sea muy general y necesitemos introducir diferencias en los contextos lo que nos lleva a la necesidad de definir servicios de ingreso y modificación, como vimos la semana pasada ( Ver: El contexto del ingreso y la modificación de documentos y la seguridad informacional ).

Hablando precisamente de aspectos más sofisticados de la seguridad, vemos entonce que el acceso a un documento en específico puede depender de la conjunción de varios factores. Uno de ellos es el de si la comunidad a la que pertenece un usuario está autorizada o no para consultar o editar un documento de ese tipo, o en un sentido más general, si el modelo de seguridad y los perfiles que posee el usuario nos permiten considerar el acceso de éste a un documento de un cierto tipo.

Pero el cuento no acaba allí. El propio documento puede decir que, aunque en general este tipo de documento puede ser consultado por la comunidad de usuarios a la que pertenece su creador (o de acuerdo a las reglas del modelo de seguridad con el que se está trabajando), en particular, el creador del documento ha preferido mantenerlo aún de acceso restringido.

También puede haber una especificación en un sentido contrario: Aunque un documento de este tipo podría ser consultado solamente por su creador o sólo por la comunidad a la que éste pertenece, por ejemplo, el creador, ha decidido permitir su consulta pública por todos los usuarios.

Así pues, una cosa son las reglas generales y otra las específicas de una instancia de un tipo de documento, lo que al final determina qué se puede hacer con un documento en particular. La Arquitectura de información establece reglas, pero en el uso, a los documentos se les da la palabra.

viernes, 14 de septiembre de 2012

El contexto del ingreso y la modificación de documentos y la seguridad informacional

La edición de contenidos o documentos se realiza en contextos.
Los contextos tiene implicaciones funcionales y de seguridad.

Llevamos varias semanas hablando de la seguridad informacional. Un tema fundamental en la prestación de servicios y que como hemos estado viendo nos conduce a la necesidad de tener modelos de seguridad: representaciones de cómo nos interesa manejar el acceso y lo que se puede hacer con un documento o una funcionalidad a la que nos aproximamos digitalmente. Muchas veces al hablar de acceso a documentos la gente se refiere (implícita o explícitamente) sólo a la consulta. Pero el acceso a documentos es mucho más complejo que la mera consulta. Por un lado está la edición de documentos y, por otro, siguiendo en profundidad, los contextos en que se realiza la edición. Hoy queremos llegar a entender cómo es que se trabaja el tema de la seguridad en los contextos en que se realiza la edición de documentos. Eso nos llevará, por cierto, a la necesidad de ciertas definiciones adicionales.

Para empezar, recordemos que tenemos que distinguir la posibilidad de consultar un contenido de información de la posibilidad de editarlo. Y descomponiendo la edición, vemos que una cosa es la posibilidad de modificar un contenido y otra es la de eliminarlo o de agregar nuevos registros. Por eso en un esquema completo de permisos no se trata de definir si tenemos acceso o no a un tipo de documento (lo que resultaría demasiado general), sino qué es lo que podemos hacer sobre ese tipo de contenido o documento: consultar, insertar, modificar o eliminar.

Todavía podemos sofisticar los diseños de los modelos cuando pensamos que los ingresos a ciertos tipos de contenidos de información o documentos se hacen en situaciones dadas y eso significa que en algunos casos necesitamos poder ingresar un conjunto de campos (metadatos, variables) y en otros requerimos poder ingresar otro conjunto de campos.

Con la modificación también podemos sofisticar los diseños de los modelos cuando analizamos que al considerar la modificación de ciertos tipos de documentos podemos (o debemos) distinguir contextos donde debemos poder modificar un conjunto de campos y situaciones en las que debemos poder modificar otro conjunto de ellos.

Esa noción de contexto o de situación en la que se realiza un ingreso de un documento o la modificación de los mismos nos conduce a la necesidad de introducir dos nuevas categorías que debe manejar el Arquitecto de Información. Estas categorías son particularmente útiles cuando se está entendiendo un problema de gestión, conversando con el responsable de un servicio informacional o modelando una solución: se trata de los servicios de ingreso y los servicios de modificación.

En efecto, un servicio, bien sea de ingreso o de modificación es un esquema que representa una situación o contexto de edición y que define las variables (campos o metadatos) que pueden modificarse, el orden, las características funcionales que eventualmente deben manejarse para cada variable y finalmente, el aspecto de la seguridad, para qué comunidades de usuarios es válido este servicio de edición, este contexto de trabajo que estamos definiendo.

Metodológicamente la recomendación es concentrarse en la funcionalidad del servicio y en el momento de trabajar con las comunidades y la seguridad, analizar si el servicio puede trabajar en términos de las definiciones generales de los perfiles de seguridad o hay que incluirle restricciones o consideraciones adicionales o específicas.

viernes, 7 de septiembre de 2012

Más sobre modelos de seguridad con múltiples comunidades


Lo que un usuario que pertenece a varias comunidades puede o
no hacer depende de como se interpretan las consecuencias de
pertenecer a varias comunidades
La semana pasada estuvimos analizando como se modela la seguridad informacional para manejar casos en los que las personas hacen vida dentro de varias comunidades. En estos casos no es suficiente la definición detallada del perfil de lo que pueden o no hacer los miembros de las distintas comunidades de usuarios sobre cada tipo de documentos para decidir lo que alguien puede o no hacer.

Vimos que no hay una solución única y que hay cuatro modelos principales: Permisos individuales, Permisos de grupos, Permisos de unión de grupos y Permisos de intersección de grupos. Por razones de espacio explicamos sólo los dos primeros y dejamos para esta oportunidad los dos últimos.

Tanto el Modelo de unión de grupos como el Modelo de intersección de grupos comparten la facilidad de uso de que la persona está siempre conectada como persona y no como uno de sus roles. La diferencia está en la respuesta a qué se considera que es la conexión de una persona como persona con múltiples perfiles. Veamos los detalles:

Modelo de Permisos de unión de grupos: Bajo este modelo se considera que lo que una persona puede hacer es la suma de lo que puede hacer con cada uno de sus perfiles.

Si alguien con un perfil A no puede acceder a un tipo de objeto X pero con un perfil B, que corresponde a una comunidad a la que también pertenece, si puede, finalmente el sistema le permitirá acceder el objeto X.

Bajo este modelo se enfatiza la unicidad de las personas y el poder de hacer. La persona no está conectada bajo un rol, como en el caso del Modelo de Permisos por grupos, sino con todos sus roles, con todas sus comunidades y esto significa, en términos prácticos, sumando todos las posibilidades y nunca restando de estas las restricciones. Es decir, los perfiles se usan para aumentar permisos o posibilidades.

Modelo de Permisos de intersección de grupos: Bajo este modelo se considera que lo que una persona puede hacer en cada momento debe ser lo menos permisivo de lo que puede hacer con cada uno de sus perfiles.

Si con un perfil A no puede acceder a un tipo de objeto X, el sistema finalmente no le permitirá acceder el objeto X aunque con un perfil B, asociado a una comunidad a la que la persona también pertenece si se puede. Esto porque ya hay por lo menos uno de sus perfiles (el A en este caso) que lo restringe.

Bajo este modelo también se enfatiza la unicidad de la persona pero, a diferencia del caso anterior, de sus perfiles se resalta lo no se debe poder hacer. En cambio, de manera similar al caso anterior, también se considera que la persona no está conectada bajo un rol, como en el caso del Modelo de Permisos de grupo, sino con todos sus roles, con todas sus comunidades. El punto clave está en que esto significa, en términos prácticos, sumando todas sus restricciones y nunca aumentando las posibilidades. Es decir, los perfiles se usan para aumentar limitaciones.

Es posible encontrar situaciones en los que uno de estos modelos se considere más apropiado pero siempre habrá otras en las que no. Los dos modelos que examinamos de hoy tienen la ventaja de su sencillez en el sentido de que la persona no tiene que declarar su rol, pero por otro lado, son más limitados porque a veces una persona quisiera tener la perspectiva de prescindir de uno de sus roles, por ejemplo, para evitar borrar algo por accidente o para poder hacer algo un poco más exigente, pero esto no puede hacerse con los modelos que vimos hoy.