Inicio del cambio

Listas de control de acceso

Las entras ACL (Lista de control de acceso) conceden o deniegan el acceso de un usuario a un objeto. No obstante, las entradas ACL no protegen el objeto debido a que la entrada ACL no puede verificar la identidad del usuario. Una entrada ACL contiene el nombre de usuario y puede especificar un nombre de host o un nombre de dominio. Por ejemplo, un usuario puede obtener acceso a los objetos creando una cuenta en un sistema que tenga un nombre de host igual al de un nombre de dominio Windows autorizado. Utilice las entradas ACL para controlar el acceso a los objetos del dominio del intermediario pero no confíe en las entradas ACL para proteger los dominios del intermediario. Utilice SSL o las salidas de seguridad para proteger los canales entre los componentes del dominio del intermediario.

WebSphere Message Broker utiliza las entradas ACL para controlar los usuarios y grupos que pueden manipular objetos en el dominio del intermediario. Hay cuatro niveles de acceso diferentes que se pueden conceder a un usuario o grupo: Total, Vista, Desplegar y Editar. No todos los niveles de acceso son válidos para todos los tipos de objetos. Consulte Permisos de ACL para obtener una lista de los permisos que se pueden aplicar a cada tipo de objeto y un resumen de las acciones que el usuario o grupo puede realizar.

Para reducir el número de entradas de control de accesos que un administrador de intermediario debe crear, los permisos de ACL se comportan de un modo jerárquico. La raíz del árbol es el objeto ConfigManangerProxy que tiene tres hijos: RootTopic, Subscriptions y PubSubTopology. El objeto PubSubTopology tiene cero o más intermediarios como hijos y cada intermediario puede tener cero o más grupos de ejecución como hijos. Cuando se añade un entrada ACL a un objeto determinado, se concede a dicho objeto y a todos los objetos que hay debajo del mismo en la jerarquía, a menos que esté alterada temporalmente por otra entrada ACL.

En z/OS, debe definir un segmento OMVS para los ID de usuario y de grupo, para que un Gestor de configuración pueda obtener información de ID de usuario y de grupo de la base de datos ESM (External Security Manager).

El diagrama siguiente muestra una jerarquía de ejemplo:

Este diagrama muestra una jerarquía de ejemplo. La raíz es CMP, que tiene tres hijos: RootTopic, Subscriptions y PubSubTopology. PubSubTopology tiene dos hijos: Intermediario1 e Intermediario2. Cada intermediario tiene dos hijos: Eg1A y Eg1B.

Los ejemplos siguientes muestran como funciona este comportamiento jerárquico en la práctica.

Ejemplo 1

El UsuarioA no tiene entradas de control de acceso. Por consiguiente, el UsuarioA no puede manipular ningún objeto de la jerarquía ni ver ninguno de los objetos definidos en la jerarquía.

Ejemplo 2

El UsuarioB tiene una entrada ACL que le proporciona autorización de despliegue para el grupo de ejecución Eg1A. Esto le proporciona la autorización de vista implícita para PubSubTopology e Intemediario1. El UsuarioB debe poder ver PubSubTopology e Intermediario1, por ejemplo, en el Kit de herramientas de Message Brokers, para poder desplegar Eg1A.

Dado que el UsuarioB no tiene entradas ACL para PubSubTopology o Intermediario1, el UsuarioB no hereda el acceso a otro intermediario o grupos de ejecución de la jerarquía. En la práctica, esto significa que el UsuarioB puede ver que hay otro grupo de ejecución definido en el Intermediario1 pero no puede ver los detalles (incluido el nombre del grupo de ejecución). De forma similar, el UsuarioB puede ver que existe otro intermediario en la topología, pero no puede ver ningún detalle. El UsuarioB no tiene acceso a RootTopic o Subscriptions (la tabla de suscripciones).

El mandato siguiente crea la entrada ACL para el UsuarioB:
mmqsicreateaclentry testcm -u UsuarioB -a -x D -b Intermediario1 -e Eg1A
El mandato mqsilistaclentry visualiza a continuación la información siguiente:
BIP1778I: userb -USER  -  D  -  Intermediario1/Eg1A      -  ExecutionGroup

Ejemplo 3

El UsuarioC tiene una entrada ACL que le proporciona autorización de vista para el Proxy del Gestor de configuración (CMP) y una entrada ACL que le proporciona autorización total para Intermediario1. Esto le proporciona las autorizaciones siguientes:

CMP Ver
RootTopic Ver
Subs Ver
Topology Ver
Intermediario1 Total
Eg1A Total
Eg1B Total
Intermediario2 Ver
Eg2A Ver
Eg2B Ver

Los mandatos siguientes crean las entradas ACL para el UsuarioC:
mqsicreateaclentry testcm -u UsuarioC -a -x V -p
mqsicreateaclentry testcm -u UsuarioC -a -x F -b Intermediario1
El mandato mqsilistaclentry visualiza a continuación la información siguiente:
BIP1778I: userc                -  USER  - V  -  ConfigManagerProxy  -  ConfigManagerProxy
BIP1778I: userc                -  USER  -  F  -  Intermediario1              -  Broker

Ejemplo 4

El UsuarioD tiene una entrada ACL que le proporciona autorización total para el CMP y una entrada ACL que le proporciona autorización de vista para Intermediario1. Al proporcionar al UsuarioD autorización de vista para acceder a Intermediario1, el UsuarioD no hereda la autorización completa. Este uso de las entradas ACL de vista resulta útil porque permite a los usuarios que generalmente tienen control total sobre un objeto determinado disminuir temporalmente su acceso para impedir una supresión o despliegue accidental. Si el usuario necesita el control total del objeto, al suprimir la entrada de vista se restaura la autorización total, de modo que pueden realizar las operaciones que necesita y, a continuación, restaurar la entrada de vista. El UsuarioD tiene las autorizaciones siguientes:

CMP Total
RootTopic Total
Subs Total
Topology Total
Intermediario1 Ver
Eg1A Ver
Eg1B Ver
Intermediario2 Total
Eg2A Total
Eg2B Total

Los siguientes mandatos crean las entradas ACL para el UsuarioD:
mqsicreateaclentry testcm -u UsuarioD -a -x F -p
mqsicreateaclentry testcm -u UsuarioD -a -x V -b Intermediario1
El mandato mqsilistaclentry visualiza a continuación la información siguiente:
BIP1778I: userd                -  USER  - F  -  ConfigManagerProxy  -  ConfigManagerProxy
BIP1778I: userd                -  USER  -  V  -  Intermediario1              -  Broker
A continuación, el mandato siguiente puede suprimir las entradas ACL para el UsuarioD:
mqsideleteaclentry testcm -u UsuarioD -a -b Intermediario1

Para cambiar las entradas de control de acceso para un objeto, un usuario debe tener autorización total para dicho objeto o cualquier padre de la jerarquía. Esto significa que el permiso de cambiar las ACL propiamente dichas funciona del mismo modo que se ha descrito anteriormente, con la excepción que el acceso a las ACL no se puede suprimir concediendo un permiso que esté en un lugar inferior del árbol. Esto es necesario debido a que, de lo contrario, un usuario podría concederse a sí mismo una entrada de vista y después no podría suprimirla.

Las entradas ACL se pueden manipular utilizando la API Java de Proxy del Gestor de configuración o utilizando los mandatos mqsicreateaclentry, mqsideleteaclentry y mqsilistaclentry.

Conceptos relacionados
Autorización de acceso a los recursos de tiempo de ejecución
Habilitación del Gestor de configuración en z/OS para obtener información de ID de usuario
Seguridad basada en temas
Tareas relacionadas
Configuración de la seguridad del dominio de intermediarios
Habilitación de la seguridad basada en temas
Cancelación de un despliegue en curso
Adición de un tema nuevo
Referencia relacionada
Mandato mqsicreateaclentry
Mandato mqsideleteaclentry
Mandato mqsilistaclentry
Permisos de ACL
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ap01380_


Fin del cambio