Modelling AES64 Parameters

Estos son lenguajes para definir el comportamiento de los objetos gestionados. Se trata de lenguajes para definir políticas que según el paradigma de gestión basada en políticas, pueden ser distribuidas a los PDPs o puntos de toma de decisión.

3.4.2.1 RBAC

RBAC (Role Based Access Control, Control de Acceso Basado en Roles) [Ferraiolo92, Ferraiolo95, Sandhu96] es un modelo o entorno de seguridad completo que ha conseguido aceptación general, permitiendo tanto la especificación como la ejecución o forzado de políticas de control de acceso organizacional o de alto nivel.

Elementos del Lenguaje

En [Ferraiolo92] se presenta una descripción formal de la semántica de RBAC en términos de conjuntos y relaciones. En lo relativo a la implementación, no tiene una sintaxis como tal asociada, sino que podría especificarse mediante cualquier lenguaje con expresividad suficiente.

Su concepto fundamental es la distinción entre roles y usuarios a la hora de adquirir permisos:

• los permisos son asignados a los roles de forma permanente

• a los usuarios se les puede asignar roles de forma dinámica (por sesión)

Un usuario puede tener múltiples roles, mientras que un rol puede ser asignado a múltiples usuarios. En la Fig. 3.9 se representa el modelo de RBAC.

Figura 3.9. Modelo RBAC.

Como ya se ha indicado, RBAC se orienta a la definición y ejecución de políticas de control de acceso, no políticas de obligación u otras.

Las asignaciones de permisos a roles, roles a usuarios y las relaciones de herencia son asociaciones sobre las que se pueden definir restricciones.

Además, los roles son organizados en una estructura jerárquica con herencia y especialización:

• herencia: los roles hijos heredan los permisos de sus padres

• especialización: pueden ampliar los permiso heredados con nuevos permisos

La herencia de roles a veces plantea problemas, por ejemplo cuando un rol no hereda exactamente todos los permisos de otro rol, o los usuarios adquieren permisos individuales que nada tienen que ver con el rol asociado. Esto se soluciona mediante los roles privados (realmente son permisos privados), que no se heredan de padres a hijos. La ventaja de esta organización es que permite agrupar permisos en roles y reutilizarlos.

La introducción de los modelos RBAC ha fomentado el cambio desde los modelos de control de acceso tradicionales de naturaleza obligatoria y discrecional a nuevos marcos donde las políticas de control de acceso no están desarrolladas sobre el código de la implementación ni son delegadas al propietario de cada recurso, sino que pueden ser especificadas de forma explícita y clara.

3.4.2.2 PDL

PDL [Lobo99] (Policy Description Language) se trata de un lenguaje simple para la especificación de comportamiento a nivel de dispositivo (bajo nivel). El ámbito de aplicación de PDL es el de equipos de conmutación de Lucent. Un ejemplo puede ser la implementación del control de admisión de conexiones a Internet en un servidor de acceso: la llegada de numerosas conexiones activa el modo de funcionamiento restringido, en el cual no se aceptan todas las conexiones, mientras que una reducción de esta tasa devuelve al sistema al modo normal, en el que se aceptan todas. Se trata por tanto de políticas que especifican el comportamiento del elemento gestionado.

Elementos del Lenguaje

Su modelo está orientado a la representación de políticas de obligación, incluyendo la representación explícita de eventos, condiciones y acciones (reglas del tipo

event-condition-action), y en reglas para disparar eventos. Existen dos tipos de construcciones: 1. La Regla (PolicyRule):

event causes action (t1 = y1, ... = vk) ifcondition. 2. El evento (Policy Defined Event, pde):

event triggers pde (t1 = y1, ... I(=vk) ifcondition.

En ambas, la aparición de un evento dispara la evaluación de la condición. En el primer caso, en el caso de cumplirse produce la realización de una acción, mientras que en el

segundo caso produce la creación de un nuevo evento. Las acciones y eventos se especifican con una serie de parámetros formales (t) que toman valores determinados (v_k). Si identificamos la generación de eventos con un tipo especial de acciones, entonces todas las construcciones son reglas del tipo ECA (event-condition-action, evento-condición-acción).

Es decir, se definen las políticas como funciones que hacen corresponder una serie de eventos en un conjunto de acciones. El lenguaje tiene una semántica claramente definida, y el modelo especifica una arquitectura para la ejecución de políticas PDL.

Expresividad y Flexibilidad

Una característica importante de PDL frente a otros modelos es que incluye la representación de eventos. Los eventos pueden ser tanto simples como compuestos. En este último caso, pueden ser la unión de eventos simultáneos (AND), su disyunción (OR), el complemento de un evento u otras estructuras lógicas más complejas.

PDL está orientado a la representación de políticas de obligación, pero no políticas de autorización u otras. Tampoco ofrece la posibilidad de realizar estructuras de agrupación asignando políticas a roles u otras. PDL no permite definir roles, ni utiliza el concepto de dominios, lo que supone cierta debilidad para su utilización en un sistema PBNM genérico. En general, PDL es un lenguaje bastante sencillo y útil para tareas de gestión poco complejas, pero demasiado simple para especificar políticas complejas y poder reutilizarlas. A pesar de la simplicidad de este lenguaje, PDL ha resultado de gran utilidad para la gestión de un gran número de tareas de gestión de red en sistemas de conmutación.

3.4.2.3 PCIM

PCIM se propuso formalmente en la RFC 3060 Policy Core Information Model [Moore01], donde se expone tanto la filosofía del IETF sobre la implantación del PBM (arquitectura, sugerencias de implementación, recomendación de uso) como los formalismos adoptados para especificar las políticas.

El objetivo de PCIM es la especificación de políticas destinadas a ser interpretadas por PDPs remotos y almacenadas en el repositorio común de políticas, en una arquitectura PBM. En [Moore01] se indica en que el objetivo es la especificación de políticas de nivel de dominio, pero algunos de los mecanismos propuestos son también válidos para las políticas de nivel de dispositivo evaluables en remoto. Utilizando estos mecanismos, la única diferencia entre las políticas de nivel de dominio y las de dispositivo sería el nivel de abstracción de las variables utilizadas y el dominio de aplicación de cada una de ellas. La propuesta del IETF para lograr estandarización es el uso de PCIM para especificar políticas en el repositorio central. Esto supone una normalización en la sintaxis de las políticas (un lenguaje estandarizado) y cierta normalización semántica (conceptos comunes). El modelo PCIM se ha concebido para ser independiente de cualquier protocolo

de intercambio de información y de cualquier mecanismo de almacenamiento de políticas, además del fabricante y modelo concreto de dispositivo.

PCIM más que un lenguaje es un metamodelo, creado mediante la extensión del Modelo Nuclear de CIM (CIMCORE) con nuevos esquemas CIM que definen:

• Clases y asociaciones para representar el lenguaje de especificación de políticas, es decir, para construir el metamodelo: reglas, condiciones, acciones, grupos de políticas, dominios, reglas, etc. A estos elementos los llamaremos elementos estructurales, y son los que constituyen realmente el lenguaje de especificación de políticas. Nótese que éste lenguaje se apoya tanto en el metamodelo CIM como en ciertos esquemas CIM (modelo de información), pero que el verdadero modelo de información es lo que se define mediante PCIM.

• Clases y asociaciones para representar nuevos elementos de información que ahora se requieren modelar y antes no estaban representados, es decir, nuevos objetos gestionados. Estos elementos sí formarían parte del modelo de información, no del lenguaje.

Tal y como se especifica en [Moore01], todas estas clases y asociaciones entre sus ejemplares están definidos de forma suficientemente genérica como para permitir la representación de todo tipo de políticas. Las aplicaciones iniciales en el IETF fueron para especificar políticas relacionadas con QoS (DiffServ e IntServ) e IPSec, mediante las siguientes RFCs, RFC3644 - Policy Quality of Service (QoS) Information Model (QPIM) [Snir03], y la RFC 3585 - IPSec Configuration Policy Information Model [Jason03]. Asimismo, el propósito del IETF es que el modelo pueda ser extendido por parte de los fabricantes, para cubrir sus propósitos específicos. Esto se hace palpable en el hecho de que no se define ningún mecanismo concreto de representar condiciones y acciones, excepto las condiciones temporales (máscaras referidas a la hora, día de la semana y del mes, y año), sino que se deja libertad al fabricante.

Finalmente, destacar que ni PCIM ni ninguna otra extensión se preocupan de cómo se llevan a cabo las correspondencias entre políticas de nivel de dominio y políticas de nivel de dispositivo, o entre políticas de nivel de dispositivo de alto nivel y las de más bajo nivel. Elementos del lenguaje

Puesto que PCIM es una extensión de CIMCORE, el esquema nuclear del modelo de información CIM, los modelos de información basados PCIM (las políticas) se basan también en CIM también (tanto directa como indirectamente a través de PCIM), y lo mismo se puede decir de los nuevos elementos estructurales definidos por PCIM. Esto significa que todas las características del metamodelo de CIM las hereda PCIM también, como la orientación a objetos, la posibilidad de definir valores por defecto, la existencia de relaciones, etc.

• PCIM está orientado a la definición de políticas de obligación sin eventos explícitos, del tipo if <condition set> then do <action list>. Los eventos deben desarrollarse en la implementación del sistema.

• Por ser un modelo orientado a objetos, las reglas son también objetos gestionados. • Las condiciones y acciones de las reglas son otros objetos que se relacionan con

éstas a través de relaciones de agregación.

Las reglas tienen una serie de atributos que las caracterizan: • Prioridad: útil para la resolución de conflictos.

• Obligatoriedad: si la política es de cumplimiento obligatorio o recomendado. • Roles: el rol es una cadena de caracteres que designa el conjunto de elementos a los

que se refiere la regla. Para su utilización se hace corresponder los distintos objetos gestionados con los roles. Pero también se puede utilizar el rol como selector de políticas, ya que permite seleccionar el conjunto de políticas que se refieren a él. Esto es útil para análisis de conflictos, porque permite decidir de forma rápida si el ámbito de aplicación de dos reglas es disjunto o no.

Expresividad y Flexibilidad

En [Moore01] se indica que el diseño del modelo de información de PCIM ha sido influenciado por una aproximación declarativa en el sentido de que no se obliga a que se especifique la secuencia de pasos a seguir para realizar el procesado de una sentencia ni los detalles de implementación. De esta manera, no se restringe la implementación al fabricante, lo que sucedería en el caso de un planteamiento de PCIM que fuese procedimental. Sin embargo, sí que se proporcionan ciertos mecanismos opcionales para especificar algunos de estos detalles y pasos a seguir en el procesado de sentencias.

Algunos de estos mecanismos son:

• Secuenciación en la realización de acciones: especificación de la importancia del orden de realización de las acciones, es decir, si debe seguirse obligatoriamente o no realizarlas si no es posible (mandatory), si simplemente se recomienda seguirlo

(recommended) o si no importa el orden (do not care).

• Las condiciones y las acciones pueden ser específicas dentro del ámbito de una regla o pueden ser independientes de éstas para permitir su reutilización en diversas reglas. En este último caso, se considera que forman parte de un repositorio común de condiciones y acciones, utilizable en un dominio de administración concreto. • Se pueden definir condiciones relativas a periodos de tiempo sofisticadas,

mediante máscaras que seleccionan horas del día (hora local o UTC), días de la semana, días del mes y meses del año para un intervalo temporal determinado.

• El conjunto de condiciones se puede especificar como CNF (Conjuctive Normal

Form, Forma Normal Conjuntiva) o DNF (Disjunctive Normal Form, Forma Normal Disyuntiva), y esto incluye también a las condiciones temporales.

• Tanto las condiciones que no son temporales como las acciones se deben definir en términos dependientes del fabricante mediante una codificación en un formato determinado y una cadena de caracteres.

• Las reglas pueden agregarse en grupos con fines organizativos y administrativos: según el periodo de validez o caducidad de la reglas y si éstas están habilitadas o no.

PCIM es un modelo orientado a la extensibilidad mediante la creación de condiciones y acciones propietarias. Es decir, el elemento que interprete cada política, habitualmente el PDP, debe ser el que comprenda los formatos. Esta extensibilidad dota al modelo de flexibilidad, pero perjudica a la estandarización al ofrecer demasiada libertad.

En [Moore03] se define PCIMe (PCIM extendido) como una extensión de PCIM para solucionar estas y otras carencias de PCIM, y para dotar al modelo de mayor expresividad. QPIM [Snir03] es una extensión de PCIM y PCIMe para especificar políticas de nivel de dominio sobre los ámbitos de DiffServ e lntServ. No aumenta la expresividad de PCIMe pero sí proporciona conceptos comunes y reutilizables para los desarrolladores.

PCIM se utiliza para especificar políticas de obligación sin eventos explícitos. Su aproximación declarativa permitiría incluir políticas de autorización, lo que implicaría definir clases específicas para aceptar o rechazar un acceso. PCIM no permite incluir eventos en la representación de las políticas, lo que podría ser útil para políticas que deban ser ejecutadas ante determinados problemas en la red.

PCIM junto con sus extensiones constituyen un modelo muy completo de definición de políticas, que permite abarcar niveles de abstracción intermedios además del bajo nivel o nivel de dispositivo.

3.4.2.4 PONDER

Ponder [Damianou01] es un lenguaje orientado a objetos de tipo declarativo que se emplea para especificar políticas de gestión y seguridad. Se desarrolló a partir del trabajo en PBM del Imperial College. En relación a él, se han propuesto diversos mecanismos para implantar las políticas. Se utiliza para especificar políticas de alto nivel de abstracción, llamadas políticas primitivas, pero además existe otra serie de políticas compuestas de carácter organizacional y auxiliar, que ayudan a estructurar el sistema a gestionar. Ponder no sólo se trata de un lenguaje, también proporciona un completo entorno de implantación de políticas:

Elementos del lenguaje

El lenguaje y entorno incluye eventos, restricciones, reglas, plantillas, y otras características útiles para la definición de políticas:

- Diversas utilidades que constituyen la herramienta de gestión de políticas

- GUIs para para gestionar las políticas (edición, actualización, eliminación y búsqueda)

- Herramientas de análisis sintáctico y semántico de las políticas,

- Módulo de transformación del lenguaje Ponder en XML directamente o en código Java

- Herramienta para la detección de conflictos entre las políticas. - Eventos: Los eventos pueden ser:

o Simples, tanto internos (e.g. timeout generado FD un temporizador) como externos. Estos últimos son notificados por componentes del servicio de monitorización (e.g. fallo en un elemento o exceso de temperatura).

o Compuestos de otros eventos simples

- Una especificación (pero no implementación) de elementos que actúan como PDPs: o Access ControllerAgents (Agentes Controladores de Acceso): asisten a los

diversos elementos en el proceso de aceptar o rechazar peticiones, interpretando las políticas de autorización

o PolicyManagementAgents (Agentes de Gestión de Políticas): asisten a los puntos que fuerzan las políticas en los procesos regulados por políticas de obligación, proporcionando una interpretación de las mismas y en muchos casos forzándolas ellos mismos

- Dominios: Un elemento empleado para modelar el sistema es el dominio. Los dominios agrupan un conjunto de objetos sobre los cuales se aplican las políticas, y se basan en criterios a conveniencia del administrador: criterios geográficos, tipo de objetos incluidos, responsabilidad y autoridad dentro de la organización, etc. El dominio no encapsula los objetos que almacena, pero sí almacena referencias a ellos, y éstos pueden ser de cualquier tipo, incluidas las personas y otros subdominios. Además, un objeto o subdominio puede ser miembro de múltiples dominios padre, porque se permite el solapamiento de dominios. Los dominios y subdominios en Ponder deben entenderse como roles relativos a recursos gestionados, ya que las políticas se especifican en función de ellos y los objetos pueden incluirse en un dominio o ser eliminados con total libertad.

Los roles de Ponder proporcionan agrupaciones semánticas de políticas con un sujeto común. Este sujeto generalmente se refiere a la posición de una persona dentro de una organización o a componentes electrónicos, y se identifica con el rol. Nótese que el concepto de rol va más allá del de dominio: aunque se refiera a un sujeto (persona o componente electrónico), el primero permite agrupar políticas, nientras que el segundo sólo agrupa recursos gestionados. Los roles admiten tipos y ejemplares.

Un ejemplo de tipo de rol es el siguiente:

type role ServiceEngineer (CallsDB callsDb) inst oblig serviceComplaint

on customerComplaint (mobileNo) do t.checkSuscriberlnfo(mobileNo);

t.checkPhoneCallList(mobileNo); trace SignalReception (mobileNo);

target t = callsDb; //calls register inst oblig deactiveAccount {.

inst auth+ serviceActionsAuth {. //other policies

En este ejemplo, se define el tipo de rol ServiceEngineer, que modela el rol de un ingeniero de servicio en un servicio de comunicaciones móviles. Este, entre otras cosas, es responsable de responder a las quejas de los clientes y sus peticiones de servicio. En Ponder, una persona puede participar en múltiples roles, pero los derechos de un rol no pueden ser utilizados para realizar acciones relacionadas con otro rol. También, hay que destacar que la existencia de roles no viene impuesta por el modelo: una persona puede tener políticas que se aplican a ella como individuo y no como rol. Esto difiere al caso de RBAC, donde la jerarquía y herencia de roles era parte del modelo, e implica mayor facilidad para separar los derechos que la persona posee por pertenecer a un rol de aquellos que son privados.

Relaciones

Las relaciones agrupan las políticas que describen interacciones entre roles: permiten definir los derechos y deberes de unos roles con respecto a otros y políticas relacionadas con recursos que son compartidos por éstos. Este mecanismo proporciona una abstracción para definir políticas que son parte de la interacción entre los roles.

Un ejemplo de relación es el siguiente:

type rel ReportingT (ProjectManagerT pm, SecretaryT secr) inst oblig reportWeekly

on timer.day(”monday”);

subject secr;

do mailReport

//. .other policies

En este ejemplo se agrupan bajo el tipo de relación ReportingT las políticas que caracterizan la relación que se establece entre un director de proyecto y su secretaria. Así, se ha destacado la obligación de la secretaria de enviar un informe al director de proyecto cada lunes, mediante la política de obligación reportWeekly.

Estructuras de gestión

Las estructuras de gestión permiten modelar unidades organizacionales (ramas de un banco, departamentos de universidades, unidades corporativas...) mediante la definición de ejemplares de roles, relaciones y otras estructuras de gestión anidadas. Ponder permite la especialización de todos los tipos de políticas mediante herencia. Cuando un tipo extiende otro, hereda todos sus elementos, sobrescribe los elementos con el mismo nombre y puede añadir nuevos elementos. Esto resulta de interés particular para las políticas compuestas, como forma de reutilizar las definiciones de conceptos organizacionales que implican.

Expresividad y Flexibilidad

En cuanto a flexibilidad y extensibilidad, PONDER ofrece todas las características de un lenguaje orientado a objetos, incluyendo jerarquías y herencia. No obstante, mientras la herramienta está operativa las políticas se mantienen como objetos Java que necesitan ser compilados, lo que implica que cambios en tiempo de ejecución no son posibles.

A continuación se describen los tipos de políticas primitivas que pueden definirse en PONDER, junto con ejemplos extraídos de [Damianou01].

Políticas de autorización

Son políticas primitivas que definen qué actividades puede realizar un miembro de un determinado dominio (dominio sujeto) con respecto a un conjunto de objetos pertenecientes a otro dominio (dominio objeto). Pueden ser tanto positivas (acciones