4 LA METODOLOGÍA PROPUESTA: ESG
4.5 APLICACIÓN DE LA METODOLOGÍA AL MODELO DE SEGURIDAD COMERCIAL
El sistema a diseñar es como en el caso anterior un sistema de archivos compartidos basado en agentes pero basado en el modelo de seguridad comercial. A lo largo de esta sección se presentará el diseño de este sistema.
4.5.1 EL ANÁLISIS
Antes de proceder con el diseño del sistema, cabe hacer mención de algunas consideraciones que han sido tomadas. La política de seguridad comercial está fundamentada en el precepto de integridad con base en la separación de funciones. La descripción de esta metodología que se presentó anteriormente es de propósito general por lo que hay que interpretarla para poder aplicarla a un sistema real.
El sistema que como ejemplo se está diseñando en esta sección presenta dos funcionalidades principales, la lectura y la escritura de archivos. Aun cuando estas funcionalidades no son muy diferentes y podrían tomarse en cuenta como funciones de una misma entidad se ha preferido tomarlas en cuenta como funciones completamente separadas para ilustrar de manera más simple el uso de la política.
En la política de seguridad se tratan conceptos tales como procedimientos de transformación, unidades de datos restringidas y no restringidas y procedimientos de verificación de integridad. Para este ejemplo tomaremos a los archivos como unidades de datos restringidas y a los datos que serán escritos a un nuevo archivo como unidades de datos no restringidas, los procedimientos de transformación serán entonces las funcionalidades de lectura y escritura de archivos.
El primer paso es establecer la organización del sistema. Uno de los fundamentos de la política comercial es la separación de funciones, esto podría llevar a hacer uso de diversas sub-organizaciones cada una de las cuales orientada hacia cierto tipo de funciones, por otra parte, la existencia de administradores y usuarios hace de cierta manera evidente la existencia de al menos dos sub-organizaciones. No obstante, dada la simplicidad del sistema y que en la política de seguridad no se restringe la organización, para el ejemplo solo tomamos en cuenta una organización.
La segunda etapa nos lleva a representar la política de seguridad a través de sus restricciones, en la figura 4.17 se presenta el modelo preliminar de restricciones para el sistema. Es necesario mencionar que la política de seguridad en este caso debe ser interpretada para su aplicación en el sistema ya que su enfoque es genérico.
Las regla C1 indica que los procedimientos de verificación de integridad deben ser validados, implícitamente esta regla indica que deben existir procedimientos que continuamente verifiquen la integridad de los CDI (que en este caso son archivos), la interpretación de esta regla se representa con las restricciones R1 y R2.
La reglas C2 y E1 en conjunto establecen que para que un procedimiento de transformación (TP) pueda manipular un CDI debe contar con un permiso generado por el administrador una vez que se ha verificado que la transformación que realiza se da de
manera correcta, para este sistema solo existen dos procedimientos de transformación, la interpretación de las dos reglas se representa con las restricciones R3, R4 y R5.
Las restricciones R6, R7 y R8 representan a las reglas C3 y E2, las cuales en conjunto indican que el administrador genera permisos para los usuarios, dichos permisos otorgan al usuario la capacidad de hacer uso de procedimientos de transformación específicos sobre CDI específicos. En este caso es necesario derivar las restricciones específicas para los dos tipos de procedimientos de transformación presentes en el sistema. De la misma manera, de la regla C4 se derivan restricciones específicas (R9 y R10) para los dos tipos de procedimientos de transformación.
Las interpretaciones de las reglas C5, E3 y E4 se representa directamente en las restricciones R11, R12 y R13. Restricción R9: Auditoria (C4) Entidad: Lector Acción: Leer Objeto: Archivo Post-condiciones: La naturaleza de la acción debe registrarse.
Restricción R3: Permisos del lector (C2, E1) Entidad: Lector
Acción: Leer Objeto: Archivo
Pre-condiciones: El archivo debe estar en la lista de CDU permitidos para este TP.
Restricción R6: Permisos de usuario(C3, E2) Entidad: Usuario
Interacción: LeerArchivo Par: Lector
Pre-condiciones: El lector y el archivo deben estar en la lista de permisos para el usuario.
Restricción R1: Verificación (C1) Verificar que los IVP validen correctamente los CDU Restricción R2: IVP (C1)
La integridad de los CDU se debe comprobar periódicamente.
Restricción R4: Permisos del escritor (C2, E1) Entidad: Escritor
Acción: Escribir Objeto: Archivo
Pre-condiciones: El archivo debe estar en la lista de CDU permitidos para este TP. Post-condiciones:
Post-condiciones: El archivo debe ser un CDU.
Restricción R7: Permisos de usuario 2 (C3, E2) Entidad: Usuario
Interacción: EscribirArchivo Par: Escritor
Pre-condiciones: El escritor y el archivo deben estar en la lista de permisos del usuario.
Restricción R5: Validación (C2) El administrador mantiene una lista de permisos para cada TP asignándole acceso a CDU específicos.
Restricción R10: Auditoria 2 (C4) Entidad: Escritor
Acción: Escribir Objeto: Archivo
Post-condiciones: La naturaleza de la acción debe registrarse.
Restricción R11: UDI (C5)
El escritor debe generar siempre una CDU al escribir un archivo.
Restricción R12: Autentificación (E3) Un mecanismo de autentificación debe existir en el sistema.
Restricción R13: Permisos (E4) Entidad: Administrador Acción: Escribir Objeto: Permisos
Pre-condiciones: Solo el administrador puede escribir este objeto.
Restricción R8: Certificación (C3) El administrador debe mantener una lista de permisos para cada usuario (con excepción de él mismo) asignando permiso para usar TP específicas en CDU específicos.
Figura 4.17. Modelo preliminar de restricciones
Una vez obtenido el modelo de restricciones la etapa subsiguiente es construir el modelo preliminar de comportamiento. En el diagrama de restricciones se hacen evidentes las entidades del sistema: usuarios, administradores, archivos, permisos de archivos, permisos de procedimientos de transformación (lectura y escritura de archivos), procedimientos de verificación de integridad y bitácoras. Estos elementos y sus restricciones se presentan en el modelo de comportamiento mostrado en la figura 4.18.
Usuario Archivo Certifica R8 Verifica R2 Lector Escritor Permisos de archivo Permisos de TP Administrador IVP Valida R5 LOG E sc rib e R 9 E sc rib e R 10 R1 LeerArchiv o R6 EscribirArch ivo R7 Lee R3 Escribe R4 R11 R12 R13 IniciaS esión Term inaSesió n R12 R12 R 12 R12 Inic iaS esió n Ter min aSes ión
Figura 4.18. Modelo preliminar de comportamiento
Para modelar el ambiente basta tomar del modelo de comportamiento a las entidades pasivas y especificar las acciones válidas sobre ellas. El modelo del ambiente para este sistema se muestra a continuación.
Leído: Archivo, PermisosDeArchivo, PermisosDeTP Cambia: Archivo, PermisosDeArchivo, PermisosDeTP, LOG
Los roles del sistema son fácilmente identificables en el modelo de comportamiento. Por cada entidad activa presente en el modelo deberá haber al menos un rol que la represente. Para este sistema los roles identificados son: usuario, lector de archivos, escritor de archivos, administrador y procedimiento de verificación de integridad (IVP). El modelo preliminar de estos roles se presenta a continuación.
Esquema de rol: Usuario
Descripción: Accede a los archivos del sistema. Protocolos y actividades: LeeArchivo, EscribeArchivo Responsabilidades:
Liveness: USUARIO =(LeeArchivo | EscribeArchivo)* Restricciones:
R3, R6, R7
Esquema de rol: Administrador
Descripción: Certifica TP, permite o restringe el acceso a archivos y a TP.
Protocolos y actividades: PermiteTP, RestringeTP, PermiteUsuario, RestringeUsuario Responsabilidades:
Liveness: ADMINISTRADOR = (PermiteTp | RestringeTP | PermiteUsuario | RestringeUsuario)* Restricciones:
R5, R8, R13
Esquema de rol: IVP
Descripción: Verifica la integridad de los archivos. Protocolos y actividades: VerificaArchivo, EmiteAlarma Responsabilidades:
Restricciones: R1, R2
Esquema de rol: Escritor Descripción: Escribe archivos.
Protocolos y actividades: EscribeArchivo, VerificaPermisos, Escribe Responsabilidades:
Liveness: ESCRITOR = | ( EscribeArchivo.VerificaPermisos.Escribe)* Restricciones:
R4, R7, R10 Esquema de rol: Lector Descripción: Lee archivos.
Protocolos y actividades: LeeArchivo, VerificaPermisos, Lee Responsabilidades:
Liveness: LECTOR = ( LeeArchivo.VerificaPermisos.Lee)* Restricciones:
R3, R6, R9
Del modelo de comportamiento se pueden obtener dos interacciones entre entidades activas: Read y Write, las cuales se dan entre el usuario y el lector y escritor de archivos respectivamente. La representación como protocolos de estas interacciones se presenta en la figura 4.19.
Par: Escritor Nombre del protocolo: LeeArchivo
Iniciador: Usuario Par: Lector Descripción: Permite al usuario leer un archivo
Nombre del protocolo: EscribeArchivo Iniciador: Usuario
Descripción: Permite al usuario escribir un archivo.
IDUsuario, IDArchivo Archivo
IDUsuario, IDArchivo, datos
Restricciones: R6 Restricciones: R7
Figura 4.19. Modelo preliminar de interacciones
De la restricción R12 se puede inferir que la autentificación del usuario deberá realizarse antes de que el usuario pueda acceder al sistema, de la misma manera, los procedimientos de transformación también deben autentificarse. De manera implícita la política de seguridad establece que una entidad administrador no puede acceder a las TP que ella misma certificó, para simplificar la representación de esta restricción podemos generalizarla estableciendo que un mismo rol no puede aplicarse a más de un tipo de entidad, de este modo una entidad administrador no puede ser al mismo tiempo un usuario y por lo tanto no puede acceder a las TP’s. A continuación se presentan las reglas organizacionales que representan estas restricciones.
IniciaSesión (Usuario)1
IniciaSesión (Usuario) LeeArchivo (Usuario) IniciaSesión (Usuario) EscribeArchivo (Usuario) IniciaSesión (Usuario) TerminaSesión (Usuario) VerificaPermisos (Escritor) Escribe (Escritor) VerificaPermisos (Lector) Lee (Lector) ~(Usuario | Administrador)
~(Usuario | Lector) ~(Usuario | Escritor) ~(Usuario | IVP)
~(Administrador | Lector) ~(Administrador | Escritor) ~(Administrador | IVP) ~(Lector | Escritor) ~(Lector | IVP) ~(Lector | IVP) 4.5.2 EL DISEÑO ARQUITECTURAL
La primera etapa de esta fase requiere el establecimiento de la estructura organizacional que presentará el sistema. La política de seguridad en este caso establece una división entre los roles pero no establece una estructura organizacional específica, existen relaciones de dependencia evidentes pues los usuarios no pueden acceder directamente a los archivos. La estructura organizacional se presenta a continuación (figura 4.20). Usuario Escritor Administrador IVP Lector Depende de Depende de par par par par par
Figura 4.20. Estructura organizacional
El siguiente paso es el de refinar el modelo de roles. Al revisar este modelo y confrontarlo con la política de seguridad se identifica la necesidad de un rol de seguridad que verifique las restricciones sobre el lector y escritor de archivos. Estos roles pueden verificar los permisos de los usuarios, pero no hay una entidad que pueda verificar los permisos de ellas mismas para acceder a los archivos. Los siguientes esquemas de roles completan el modelo provisional de roles.
Esquema de rol: Usuario
Descripción: Accede a los archivos del sistema.
Protocolos y actividades: IniciaSesión, LeeArchivo, EscribeArchivo, TerminaSesión Responsabilidades:
Liveness: USUARIO = IniciaSesión.(LeeArchivo | EscribeArchivo)*.TerminaSesión Restricciones:
R3, R6, R7
Esquema de rol: Escritor Descripción: Escribe archivos.
Protocolos y actividades: EscribeArchivo, VerificaPermisos, Escribe, IniciaSesión, TerminaSesión, IniciaSesiónTP, TerminaSesiónTP
Responsabilidades:
Liveness: ESCRITOR = IniciaSesiónTP.(IniciaSesión | TerminaSesión | ( EscribeArchivo.VerificaPermisos.Escribe))*.TerminaSesiónTP
Restricciones: R4, R7, R10
Esquema de rol: Lector Descripción: Lee archivos.
Protocolos y actividades: LeeArchivo, VerificaPermisos, Lee, IniciaSesión, TerminaSesión, IniciaSesiónTP, TerminaSesiónTP
Responsabilidades:
Liveness: LECTOR = IniciaSesiónTP.(IniciaSesión | TerminaSesión | ( LeeArchivo.VerificaPermisos.Lee))*.TerminaSesiónTP
Restricciones: R3, R6, R9
Esquema de rol: GestorArchivos
Descripción: Recupera e inserta archivos, autentifica a los TP.
Protocolos y actividades: RecuperaArchivo, InsertaArchivo, VerificaPermisos, IniciaSesiónTP, TerminaSesiónTP
Responsabilidades:
Liveness: FILEMANAGER = (IniciaSesiónTP | TerminaSesiónTP | (VerificaPermisos.(RecuperaArchivo | InsertaArchivo)) )*
Restricciones: R3, R4
Al añadir este nuevo rol es necesario modificar también el modelo de interacciones pues las acciones que los roles Lector y Escritor realizaban directamente sobre los archivos ahora dependen de una interacción con el nuevo rol. En la figura 4.21 se presenta el refinamiento al modelo de interacciones.
Par: GestorArchivos Nombre del protocolo: Lee
Iniciador: Lector Par: GestorArchivos Descripción: Permite al lector recuperar un archivo.
Nombre del protocolo: Escribe Iniciador: Escritor
Descripción: Permite al usuario insertar un archivo. IDUsuario, TPID, IDArchivo Archivo IDUsuario, TPID, IDArchivo, archivo Restricciones: R3 Restricciones: R4
Par: Lector o Escritor Nombre del protocolo: IniciaSesión
Iniciador: Usuario Par: Lector o Escritor Descripción:Permite al usuario autentificarse y obtener un token de sesión.
Nombre del protocolo: TerminaSesión Iniciador: Usuario
Descripción: Permite al usuario registrar su salida del sistema.
IDUsuario, contraseña Token
IDUsuario, token
Restricciones: R12 Restricciones: R12
Par: GestorArchivos Nombre del protocolo: IniciaSesión
Iniciador: Lector o Escritor Par: GestorArchivos Descripción: Permite al TP autentificarse e iniciar su sesión.
Nombre del protocolo: TerminaSesión Iniciador: Lector o Escritor
Descripción: Permite al TP registrar su salida del sistema.
IDTP, contraseña Token
IDTP, token
Restricciones: R12 Restricciones: R12
Figura 4.21. Refinamiento del modelo de interacciones
El refinamiento de los modelos de roles e interacciones hace necesario el refinamiento de los modelos de restricciones y de comportamiento. El primer refinamiento evidente es el crear una restricción para el rol GestorArchivos, pues este no debe poder
estar en grado de leer los archivos o escribirlos por si mismo sino que deberá solamente hacerlos disponibles a las entidades que cumplan con sus restricciones. Su función entonces será la de verificar el cumplimiento de las restricciones que se aplican a los roles Lector y Escritor.
En los modelos preliminares, las entidades lector y escritor de archivos actuaban directamente sobre los archivos. Una vez que se agregó una entidad que verifica el cumplimiento de las restricciones para estas entidades, estas tendrán que interactuar con la nueva entidad para poder cumplir con sus funciones, este cambio se debe reflejar en el modelo de restricciones. El modelo refinado de restricciones se presenta a continuación en la figura 4.22. Restricción R9: Auditoria (C4) Entidad: Lector Acción: Lee Objeto: File Post-condiciones: La naturaleza de la acción debe registrarse.
Restricción R3: Permisos del lector (C2, E1) Entidad: Lector
Interacción: Lee Par: GestorArchivos
Pre-condiciones: El archivo debe estar en la lista de CDU permitidos para este TP.
Restricción R6: User permissions (C3, E2) Entidad: Usuario
Interacción: LeerArchivo Par: Lector
Pre-condiciones: El lector y el archivo deben estar en la lista de permisos para el usuario.
Restriction R1: Verificación (C1) Verificar que los IVP validen correctamente los CDU Restricción R2: IVP (C1)
La integridad de los CDU se debe comprobar periódicamente.
Restricción R4: Permisos del escritor (C2, E1) Entidad: Escritor
Interacción: Escribe Par: GestorArchivos
Pre-condiciones: El archivo debe estar en la lista de CDU permitidos para este TP. Post-condiciones:
Post-condiciones: El archivo debe ser un CDU.
Restricción R7: User permissions 2 (C3, E2) Entidad: Usuario
Interacción: EscribirArchivo Par: Escritor
Pre-condiciones: El escritor y el archivo deben estar en la lista de permisos del usuario.
Restricción R5: Validación (C2) El administrador mantiene una lista de permisos para cada TP asignándole acceso a CDU específicos.
Restricción R10: Auditoria 2 (C4) Entidad: Escritor
Acción: Escribe Objeto: Archivo
Post-condiciones: La naturaleza de la acción debe registrarse.
Restricción R11: UDI (C5)
El escritor debe generar siempre una CDU al escribir un archivo.
Restricción R12: Autentificación (E3) Un mecanismo de autentificación debe existir en el sistema.
Restricción R13: Permisos (E4) Entidad: Administrador Acción: Escribe Objeto: Permisos
Pre-condiciones: Solo el administrador puede escribir este objeto.
Restricción R14: Preservación El Gestor de Archivos no debe poder escribir o leer archivos por voluntad propia.
Restricción R8: Certificación (C3) El administrador debe mantener una lista de permisos para cada usuario (con excepción de él mismo) asignando permiso para usar TP específicas en CDU específicos.
Figura 4.22. Modelo de restricciones
Estos cambios deben ser reflejados también en el modelo de comportamiento, los refinamientos al mismo se presentan en la figura 4.23.
Archivo Certifica R8 Verifica R2 Permisos de archivo Permisos de TP Administrador IVP Valida R5 R1 Lee R3 Escribe R4 R13 GestorArchivos Recupera R14 Inserta R14 Lee Lee Usuario Lector Escritor LOG E sc rib e R 9 E sc rib e R 10 LeerArchiv o R6 Escrib irArchivo R7 R11 IniciaS esión Term inaSesió n R12 R12 R 12 R12 Inic iaS esió n Ter min aSes ión TerminaSesiónTP R12 Term inaS esió nTP IniciaS esiónT P Inicia SesiónTP R12 R12 R12
Figura 4.23. Modelo de comportamiento
Antes de continuar hacia la fase de diseño arquitectural es necesario retomar la estructura organizacional del sistema. Dicha estructura no ha cambiado pero se ha agregado un nuevo elemento, el administrador de archivos. Cabe mencionar que este nuevo elemento está a la par del administrador y de los procedimientos de verificación de integridad pero tanto el lector de archivos como el escritor de los mismos dependen de este nuevo elemento para realizar sus funciones. A continuación, en la figura 4.24, se muestra la estructura organizacional del sistema tomando en cuenta el nuevo elemento.
Usuario Escritor Administrador IVP Lector Depende de Depende de
par par par
par GestorArchivos
Depende de
Figura 4.24. Estructura organizacional
4.5.3 EL DISEÑO DETALLADO
El primer paso en esta etapa es definir clases de agentes y los roles que cada clase adoptará. Las reglas organizacionales indican una exclusión entre la mayoría de los roles. Esto implica que por cada rol se establecerá una clase de agente que lo adopte, no obstante para el rol administrador de archivos no se estableció este tipo de regla.
Una misma clase de agente podría adoptar el rol de administrador de archivos en conjunto con otro de los roles. Los roles de lector de archivos y escritor de archivos quedan descartados para coexistir con el administrador de archivos en una sola clase de agente pues esto iría en contra de las restricciones. El rol de administrador por su naturaleza debe ser aislado, sin embargo el rol de IVP no presenta ningún inconveniente para ser adoptado por la misma clase de agente que el administrador de archivos. Tomando esto en cuenta, a continuación se presenta el modelo de agentes para este sistema.
AgenteUsuario ejecuta Usuario
AgenteLector ejecuta Lector
AgenteEscritor ejecuta Escritor
AgenteGestorArchivos ejecuta IVP, GestorArchivos AgenteAdministrador ejecuta Administrador
Las restricciones que directamente e indirectamente aplican sobre cada elemento del sistema se presentan a continuación en la tabla de restricciones.
Entidad Agente Restricción Aplicación
Usuario AgenteUsuario R12 Este agente debe ser autentificado.
R6 Para leer un archivo sus permisos deben ser verificados. R7 Para escribir un archivo sus permisos deben ser
verificados.
Lector AgenteLector R12 Este agente debe ser autentificado.
R3 Para leer un archivo sus permisos deben ser verificados. R9 Este agente debe escribir en una bitácora la naturaleza de
todas sus acciones e interacciones. Escritor AgenteEscritor R12 Este agente debe ser autentificado.
R4 Para escribir un archivo sus permisos deben ser verificados.
R10 Este agente debe escribir en una bitácora la naturaleza de todas sus acciones e interacciones.
Administrador AgenteAdministrador R5 Este agente debe mantener una lista de permisos para que los usuarios interactúen con los agentes lector y escritor. R8 Este agente debe mantener una lista de permisos para la
interacción que los agentes lector y escritor realizan con el agente gesto de archivos en nombre cada usuario.
IVP AgenteGestorArchivos R1 Se debe verificar que este agente verifique correctamente la integridad de los archivos.
R2 Este agente deberá verificar la integridad de los archivos periódicamente.
GestorArchivos AgenteGestorArchivos R14 Este agente no deberá ser capaz de leer o escribir archivos por cuenta propia.
Una vez que hemos establecido las clases de agentes, su relación con las entidades del sistema y las restricciones que sobre ellos recaen, el siguiente paso es establecer los servicios que los agentes proveerán. El modelo de servicios se muestra en la siguiente tabla.
Service Pre-condiciones Post-condiciones Entradas Salidas
IniciaSesión El usuario debe estar registrado en el sistema. El usuario es autentificado y recibe un token de sesión Id de usuario y contraseña. Token de sesión.
LeeArchivo El token debe ser válido, el archivo debe existir y R6 debe mantenerse.
El archivo es leído por el usuario.
Id de usuario, token e id de archivo.
Archivo
EscribeArchivo El token debe ser válido y R7 debe mantenerse.
El archive es escrito por el usuario.
Id de usuario, token, id de archivo y datos. TerminaSesión El token debe ser válido. El token es invalidado
y la sesión terminada. Token. IniciaSesiónTP El agente debe estar
registrado en el sistema. El agente es autentificado y recibe un token de sesión. Id de agente, contraseña. Token de sesión Lee El token debe ser válido, el
archive debe existir y R6 debe mantenerse.
El archive es leído por el usuario.
Id de usuario, id de agente, token e id de archivo.
Archivo
Escribe El token debe ser válido y R7 debe mantenerse. El archivo es escrito por el usuario. Id de usuario, id de agente, token, id de archivo y datos. TerminaSesiónTP El token debe ser válido. El token es invalidado
y la sesión terminada.
Token. RecuperaArchivo El token debe ser válido, el