4 LA METODOLOGÍA PROPUESTA: ESG
4.4 APLICACIÓN DE LA METODOLOGÍA AL MODELO DE SEGURIDAD MLS
El sistema a diseñar es un sistema de archivos compartidos basado en agentes y cuyo funcionamiento será gobernado por la política de seguridad del modelo MLS. A continuación se presentará el diseño de este sistema siguiendo las fases descritas en la metodología GAIA los lineamientos descritos en la sección 4.3.
4.4.1 EL ANÁLISIS
Como ya se describió, la primera etapa de esta fase es la de identificar la organización o sub-organizaciones del sistema. En este caso, por simplicidad se establece una sola organización para los elementos del sistema.
Para construir el modelo de comportamiento del sistema, es necesario representar la política de seguridad a través de un conjunto de reglas. El modelo MLS puede representarse mediante las reglas presentadas en la sección 4.2.1. Haciendo uso de los esquemas descritos en las secciones precedentes el modelo preliminar de restricciones para el sistema es el mostrado en la figura 4.11.
Tomando como base el modelo preliminar de restricciones, se procede a construir el modelo preliminar de comportamiento del sistema. Para el sistema de archivos podemos identificar claramente dos entidades: usuarios y archivos, así como las interacciones entre ellos: lectura y escritura. Estos elementos en conjunto con las restricciones que sobre ellos aplican son representados en el siguiente modelo de comportamiento (figura 4.12).
Entidad: Usuario Atributo: Nivel
Restricción R1: Valor único {unclassified, classified, secret, top-secret}
Atributo: Etiquetas
Restricción R3: Conjunto de valores
Entidad: Archivo Atributo: Nivel
Restricción R2: Valor único {unclassified, classified, secret, top-secret}
Atributo: Etiquetas
Restricción R4: Conjunto de valores Atributo: Permisos
Restricción R5: Conjunto de tuplas {leer, escribir}
Restricción R6: Simple security Entidad: Usuario Acción: LeerArchivo Objeto: Archivo Pre-condiciones: (Usuario.nivel>=Archivo.nivel) ^ (Usuario.etiquetas C Archivo.Etiquetas) ^ (leer ЄArchivo.permisos) Restricción R7: * property Entidad: Usuario Acción: EscribirArchivo Objeto: Archivo Pre-condiciones: (Usuario.nivel<=Archivo.nivel) ^ (Usuario.etiquetas C Archivo.etiquetas) ^ (escribir ЄArchivo.permisos) Restricción R8: Autentificación Un mecanismo de autentificación debe existir en el sistema
Restricción R9: Autentificación 2 Entidad: Usuario
Acción: IniciaSesión Objeto: Sistema
Pre-condiciones: El usuario debe estar registrado en el sistema.
Post-condiciones: La identidad del usuario ha sido verificada.
Figura 4.11. Modelo preliminar de restricciones
Usuario Nivel Etiquetas Permisos Archivo Nivel Etiquetas LeerArchivo R6 EscribirArchivo R7 R1 R3 R2 R4 R5 R8 R9
Figura 4.12. Modelo preliminar de comportamiento
El modelo del ambiente, que es la etapa subsiguiente, se construye tomando en cuenta el modelo de comportamiento, en el cual ya se establecieron las entidades activas (que serán tomadas como roles) y las entidades pasivas (recursos) sobre las que actúan, para completar el modelo del ambiente es necesario solamente especificar las acciones que se podrán realizar sobre los recursos del sistema. A continuación se presenta el modelo del ambiente para el sistema.
Leído: Archivo Cambia: Archivo
La siguiente etapa es la de especificar los roles presentes en el sistema, para ello se deberán construir los esquemas de roles necesarios, los cuales en conjunto conforman el modelo preliminar de roles. Las entidades activas presentes en el modelo de comportamiento deberán ser tomadas en cuenta como roles. Para este ejemplo se identifica solamente una entidad activa por lo que el modelo preliminar de roles consta solamente de un esquema de rol. El modelo preliminar de roles se muestra a continuación.
Descripción: Accede a los archivos del sistema.
Protocolos y Actividades: IniciaSesión, EscribeArchivo, LeeArchivo, TerminaSesión Responsabilidades:
Liveness: USUARIO = IniciaSesión.(LeeArchivo | EscribeArchivo)*.TerminaSesión Restricciones:
R1, R3, R6, R7, R9
Una vez que se cuenta con el modelo preliminar de roles se puede construir el modelo preliminar de interacciones. En el modelo preliminar de comportamiento las únicas interacciones presentes son las acciones que los usuarios realizan sobre los archivos pero, ya que los archivos son solo recursos del sistema, estas acciones no son tomadas en cuenta como interacciones. Sin embargo, del modelo de restricciones podemos identificar al menos dos interacciones para los usuarios: inicio de sesión y fin de sesión. Estas dos interacciones son necesarias para cumplir con la regla 9, el inicio de sesión está descrito explícitamente mientras que la terminación de la sesión se hace evidente ya que los usuarios no estarán indefinidamente dentro del sistema. El modelo preliminar de interacción para el sistema se presenta en la figura 4.13.
Par: ? Nombre del protocolo: IniciaSesión
Iniciador: Usuario Par: ?
Descripción: Permite al usuario demostrar su identidad.
Nombre del protocolo: TerminaSesión Iniciador: Usuario
Descripción: Permite al usuario registrar su salida del sistema
ID Usuario, Contraseña Token
ID Usuario
Restricciones: R8, R9 Restricciones: Figura 4.13. Modelo preliminar de interacciones
Para terminar con la fase de análisis se deben establecer las reglas organizacionales. Cabe mencionar que estas reglas no son las mismas que las que definen a la política de seguridad sino que son reglas que se deben establecer de modo que el sistema cumpla con la política. Para este sistema podemos establecer las siguientes reglas organizacionales:
IniciaSesión (Usuario)1
IniciaSesión (Usuario) LeeArchivo (Usuario) IniciaSesión (Usuario) EscribeArchivo (Usuario) IniciaSesión (Usuario) TerminaSesión (Usuario)
Estas reglas establecen que la acción de iniciar sesión se deberá realizar una vez por cada entidad que adopte el rol de usuario y que las acciones leer archivo, escribir archivo y terminar sesión no podrán ser realizadas antes que la acción iniciar sesión sea realizada.
4.4.2 EL DISEÑO ARQUITECTURAL
La primera etapa de esta fase es el establecimiento de la estructura organizacional del sistema. Para este sistema, la estructura organizacional inicial es simple, tomando en cuenta el modelo de comportamiento identificamos que el sistema estará poblado de entidades que adoptan el rol de usuario y que acceden a los recursos del sistema por lo que la estructura es de un conjunto de pares como se muestra a continuación.
Usuariopar Usuario
A continuación debemos refinar el modelo de roles. El protocolo IniciaSesión está restringido por las reglas 8 y 9 pero no están definidas las entidades que llevarán a cabo este protocolo, un nuevo rol de seguridad es necesario, el autentificador. Las acciones restringidas, por ejemplo LeeArchivo y EscribeArchivo conllevan a la creación de otro rol de seguridad, este rol será el encargado de verificar que la restricción se cumpla, esto se debe a que la entidad que está restringida no puede ser quien verifique el cumplimiento de la restricción. A continuación se presentan los esquemas de roles que completan el modelo para el sistema.
Esquema de rol: Auntentificador
Descripción: Auntentifica a los usuarios y mantiene una lista de usuarios presentes. Protocolos y actividades: IniciaSesión, AutentificaUsuario, TerminaSesión Responsabilidades:
Liveness: AUTENTIFICADOR = ( (IniciaSesión.AutentificaUsuario) | TerminaSesión )ω
Restricciones: R8, R9
Esquema de rol: GestorArchivos
Descripción: Controla el acceso a los archivos del sistema. Protocolos y actividades: EscribeArchivo, LeeArchivo Responsabilidades:
Liveness: GESTORARCHIVOS = (LeeArchivo| EscribeArchivo)ω
Restricciones: R6, R7
Ya que se refinó el modelo de roles, es necesario refinar el modelo de interacciones de modo que sea coherente con el nuevo modelo de roles. Un primer refinamiento es completar los esquemas de los protocolos de inicio y terminación de sesión, el segundo refinamiento es incorporar los protocolos necesarios para la lectura y escritura de archivos, las cuales previamente eran consideradas como simples acciones y no como interacciones. En la figura 4.14 se presenta el modelo de interacción para el sistema.
Par: GestorArchivos Nombre del protocolo: LeeArchivo
Iniciador: Usuario Par: GestorArchivos Descripción: Permite al usuario leer archivos
Nombre del protocolo: EscribeArchivo Iniciador: Usuario
Descripción: Permite al usuario escribir archivos IDUsuario, IDArchivo, token Archivo IDUsuario, IDArchivo Token, file Restrictions: R6 Restrictions: R7 Par: Autentificador Nombre del protocolo: IniciaSesión
Iniciador: Usuario Par: Autentificador Descripción: Permite al usuario demostrar su identidad.
Nombre del protocolo: TerminaSesión Iniciador: Usuario
Descripción: Permite al usuario registrar su salida del sistema
ID Usuario, Contraseña Token
ID Usuario
Restricciones: R8, R9 Restricciones:
Figura 4.14. Modelo de interacciones
Tomando en cuenta los cambios en los roles (entidades activas) e interacciones es necesario refinar el modelo de restricciones. Los refinamientos necesarios para el sistema son mostrados en la figura 4.15. Estos refinamientos incluyen el cambio de acción a
interacción en las reglas 6 y 7, la incorporación de la nueva entidad Auntentificador en la regla 9 y la creación de la regla 10 para mantener la coherencia con el modelo de seguridad.
Restricción R6: Simple security Entidad: Usuario Interacción: LeerArchivo Par: GestorArchivos Pre-condiciones: (Usuario.nivel>=Archivo.nivel) ^ (Usuario.etiquetas C Archivo.Etiquetas) ^ (leer ЄArchivo.permisos) Restricción R7: * property Entidad: Usuario Interacción: EscribirArchivo Par: GestorArchivos Pre-condiciones: (Usuario.nivel<=Archivo.nivel) ^ (Usuario.etiquetas C Archivo.etiquetas) ^ (escribir ЄArchivo.permisos) Restricción R10: Preservar R6, R7 GestorArchivos no podrá acceder a los archivos por voluntad propia
Restricción R9: Autentificación 2 Entidad: Usuario
Interacción: IniciaSesión Par: Autentificador
Pre-condiciones: El usuario debe estar registrado en el sistema.
Post-condiciones: La identidad del usuario ha sido verificada.
Figura 4.15. Modelo de restricciones
De la misma manera el modelo de comportamiento debe refinarse para reflejar los cambios realizados. En la figura 4.16 se presenta el modelo de comportamiento refinado.
In icia Se sión Usuario Nivel Etiquetas Permisos Archivo Nivel Etiquetas LeeArchivo R6 EscrieArchivo R7 R1 R3 R2 R4 R5 R9 R10 GestorArchivos Authenticator R 8 T erm in aS esió n Lee Escribe
Figura 4.16. Modelo de comportamiento
4.4.3 EL DISEÑO DETALLADO
En la primera etapa de esta fase debemos establecer una correspondencia entre roles y agentes, es decir establecer las clases de agentes que existirán en el sistema y los roles que adoptará cada uno de ellos. Para este sistema podemos establecer dos clases de agentes: agentes de usuario y agentes de sistema. Los agentes de usuario adoptarán el rol de usuario mientras que los agentes de sistema adoptarán los roles de autentificador y de gestor de archivos. Estos dos roles podrían ser adoptados por diferentes clases de agentes sin embargo la política de seguridad no requiere esta separación. El modelo de agentes para este sistema se presenta a continuación.
AgenteUsuario ejecuta Usuario
Para complementar el modelo de agentes se incluye la tabla de restricciones en la que se establece la correspondencia entre agentes, entidades y las restricciones que sobre ellos recaen. Para este sistema, la tabla de restricciones se muestra en la siguiente tabla.
Entidad Agente Restricción Aplicación
Usuario AgenteUsuario R1 El atributo nivel y sus restricciones deben aplicarse a este agente. R3 El atributo etiquetas y sus restricciones deben aplicarse a este
agente.
R9 El agente deberá autentificarse con el sistema. Autentificador AgenteGestor
Archivos R8 Este agente deberá proveer un mecanismo de autentificación. R9 Este agente deberá verificar la identidad de los agentes de usuario. GestorArchivos AgenteGestor
Archivos
R6 Este agente verificará el cumplimiento de la restricción. R7 Este agente verificará el cumplimiento de la restricción. R10 Este agente no contará con mecanismos para leer o escribir
archivos por si mismo.
Archivo R2 El atributo nivel y sus restricciones deben aplicarse a este objeto. R4 El atributo etiquetas y sus restricciones deben aplicarse a este
objeto.
R5 El atributo permisos y sus restricciones deben aplicarse a este objeto.
La siguiente etapa de esta fase es la de construir un modelo de servicios en el cual se describen las actividades acciones e interacciones que llevarán a cabo los agentes. El modelo de servicios para este sistema se muestra en la siguiente tabla.
Servicio Pre-condiciones Post-condiciones Entradas Salidas
IniciarSesión El usuario deberá estar registrado en el sistema.
El usuario es autentificado y su sesión abierta.
IDUsuario, contraseña Token de sesión. LeerArchivo El token deberá ser válido, el
archivo debe existir y R6 debe cumplirse.
El archivo es leído por el usuario.
IDUsuario, IDArchivo, token.
Contenido del archivo. EscribirArchivo El token deberá ser válido y
R7 debe cumplirse. El archivo es escrito por el usuario. IDUsuario, IDArchivo, token y datos. TerminarSesión El token debe ser válido. La sesión de usuario
termina, el token es invalidado.
User id
El proceso de diseño termina en esta fase. El diseño del sistema incluye un conjunto de agentes, roles, acciones, interacciones y restricciones que en conjunto constituirán al sistema y que respetan la política de seguridad establecida.