Seguridad de recursos de ejecución: listas de control de acceso

Inicio del cambioLas entradas de la lista de control de acceso (ACL) permiten o deniegan el acceso de un usuario a recursos de ejecución específicos. Los recursos de tiempo de ejecución son objetos de WebSphere Event Broker que existen durante la ejecución en el dominio de intermediarios.Fin del cambio

Inicio del cambioCada objeto de tiempo de ejecución tiene una lista de control de acceso (ACL) que determina qué usuarios y grupos pueden acceder al objeto. Mediante las entradas ACL, puede controlar el acceso de los usuarios a objetos específicos del dominio de intermediarios y permite a un usuario o grupo ver, modificar o desplegar el objeto. Puede manipular las entradas ACL utilizando la API entorno de trabajo, la API Proxy del Gestor de configuración de Java o los mandatos mqsicreateaclentry, mqsideleteaclentry y mqsilistaclentry. Fin del cambio

Inicio del cambioPor ejemplo, el usuario USER1 puede tener acceso para modificar BROKERA, pero no tener derechos de acceso a BROKERB. En otro ejemplo, el mismo usuario puede tener acceso para desplegar al grupo de ejecución EXEGRP1, pero no a EXEGRP2, aunque ambos sean miembros de BROKERA.Fin del cambio

Cuando intenta ver o modificar un objeto para el que necesita un permiso, se pasa la información siguiente al Gestor de configuración:

Inicio del cambioGestor de configuración comprueba la tabla ACL y si su ID de usuario está incluido en la entrada ACL del objeto nombrado, tiene autorización para realizar la operación.Fin del cambio

Hay cuatro niveles de acceso diferentes que se pueden conceder a un usuario o grupo: Control total, Ver, Desplegar y Editar. No todos los niveles de acceso son válidos para todos los tipos de objetos. Consulte Permisos de ACL para ver 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.

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 de intermediarios pero no confíe en las entradas ACL para proteger los dominios de intermediarios. Utilice SSL o salidas de seguridad para proteger los canales entre los componentes del dominio de intermediarios. Aunque las ACL permiten o deniegan el acceso de un usuario a un objeto según el ID de usuario, no protegen el objeto ya que una entrada ACL no puede verificar la identidad del usuario.

Para reducir el número de entradas ACL 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 otorga permiso a dicho objeto y a todos los objetos que hay debajo del mismo en la jerarquía, a menos que se altere temporalmente especificando otra entrada ACL. El diagrama siguiente muestra una jerarquía de ejemplo de las entradas de la lista de control de acceso:

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.

Inicio del cambio-Para ver ejemplos que muestran cómo está jerarquía funciona en la práctica, consulte Configuración de la seguridad para los componentes del dominio.Fin del cambio

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 para 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 otorgando un permiso que esté en un lugar inferior del árbol. Esto es necesario porque, de lo contrario, un usuario podría otorgarse a sí mismo una entrada de vista y después no podría suprimirla.

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

Entradas y grupos ACL

En versiones anteriores de WebSphere Event Broker, el acceso a los objetos de tiempo de ejecución se controlaba definiendo un conjunto de grupos y asignando usuarios a dichos grupos. Las entradas ACL permiten controlar el acceso con más granularidad que los grupos. Las entradas ACL también permiten que un solo Gestor de configuración gestione los sistemas de desarrollo, prueba y producción por separado, configurando el acceso de los usuarios a cada intermediario. Si utilizara grupos, tendría que colocar los sistemas de desarrollo, prueba y producción en dominios de intermediarios separados, cada uno de ellos controlado por un Gestor de configuración individual.

Si migra un Gestor de configuración desde una versión anterior de WebSphere Event Broker, se definen automáticamente entradas ACL para los grupos siguientes:
  • mqbrkrs
  • mqbrops
  • mqbrdevt
  • mqbrasgn
  • mqbrtpic
Sin estas entradas ACL, los usuarios que pertenecen a estos grupos no tienen autorización para realizar acciones en los objetos del dominio.

Cuando utilice las ACL de usuario individuales, debe definir los usuarios en la estación de trabajo que está accediendo a los objetos (es decir, la máquina en la que se ejecuta el kit de utilidades), pero no necesita definirlas en la estación de trabajo que ejecuta el Gestor de configuración. Sin embargo, cuando esté utilizando las ACL de grupo, debe definir los usuarios en ambas estaciones de trabajo y, a continuación, definir los grupos en la estación de trabajo que ejecuta el Gestor de configuración, antes de añadir los usuarios a los grupos. Esto es necesario porque no se pasa información de grupo entre las estaciones de trabajo.

Conceptos relacionados
Visión general de seguridad
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 para los componentes del dominio
Configuración de la seguridad del dominio de intermediarios
Habilitación de la seguridad basada en temas
Cancelación de un despliegue en curso
Referencia relacionada
Requisitos de seguridad para las tareas administrativas
Mandato mqsicreateaclentry
Mandato mqsideleteaclentry
Mandato mqsilistaclentry
Permisos de ACL
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. Reservados todos los derechos.
Última actualización : 2009-02-16 14:31:18

ap01380_