Seguridad administrativa de precisión

En releases anteriores de WebSphere Application Server versión 6.1, los roles administrativos otorgados por los usuarios podían administrar todos los recursos de la célula. Ahora WebSphere Application Server es mucho más preciso, lo que significa que se puede otorgar el acceso a cada usuario por recurso.

Por ejemplo, se puede otorgar a los usuarios acceso de configurador a una instancia específica de un único recurso (una aplicación, un servidor de aplicaciones o un nodo). Los usuarios no pueden acceder a ningún otros recurso fuera de los recursos que se les asigne. Los roles administrativos ahora son por recurso y no para toda la célula. No obstante, existe un grupo de autorización de toda la célula para la compatibilidad con versiones anteriores. Los usuarios asignados a roles administrativos del grupo de autorización de toda la célula pueden continuar accediendo a todos los recursos de la célula.
Nota: Los nodos de versiones anteriores a WebSphere Application Server Versión 6.1 de un entorno de células se filtran de la correlación de recursos.

Para obtener esta seguridad basada en instancias o seguridad de precisión, los recursos que requieren los mismos privilegios se colocan en un grupo denominado grupo de autorización administrativa o grupo de autorización. Se puede otorgar a los usuarios el acceso al grupo de autorización asignándoles el rol administrativo necesario.

La seguridad administrativa de precisión también se utiliza en entornos de un único servidor. Aplicaciones distintas de un sólo servidor se pueden agrupar y colocar en diferentes grupos de autorización. Por tanto, existen distintas restricciones de autorización para las distintas aplicaciones. Tenga en cuenta que el servidor por sí mismo no puede formar parte de ningún grupo de autorización en un entorno de un solo servidor.

Puede asignar usuarios y grupos al rol adminsecuritymanager en el nivel de célula mediante scripts wsadmin y la consola administrativa. Mediante el rol adminsecuritymanager, puede asignar usuarios y grupos a los roles de usuario administrativo y grupo administrativo.

Cuando se utiliza una seguridad de administración precisa, los usuarios a los que se otorga el rol adminsecuritymanager pueden gestionar grupos de autorización. Consulte Roles administrativos y autorización de servicios de nombres para obtener una explicación detallada de todos los roles administrativos.

Un administrador no puede asignar usuarios y grupos a los roles de usuario administrativo y grupo administrativo, incluido el rol adminsecuritymanager. Consulte Roles administrativos para obtener más detalles.

Existen varios mandatos de seguridad administrativa que pueden utilizarse para crear grupos de autorización, correlacionar recursos con los grupos de autorización y asignar usuarios a los roles administrativos de los grupos de autorización. A continuación aparecen varios ejemplos utilizando wsadmin:
  • Crear un nuevo grupo de autorización:
    $AdminTask createAuthorizationGroup {-authorizationGroupName authGroup1}
  • Suprimir un grupo de autorización:
    $AdminTask deleteAuthorizationGroup {-authorizationGroupName groupName}
  • Añadir recursos a un grupo de autorización:
    $AdminTask addResourceToAuthorizationGroup
    {-authorizationGroupName groupName -resourceName Application=app1}
  • Eliminar recursos de un grupo de autorización:
    $AdminTask removeResourceFromAuthorizationGroup 
    {-authorizationGroupName groupName -resourceName Application=app1}
  • Añadir los ID de usuario a los roles de un grupo de autorización:
    $AdminTask mapUsersToAdminRole {-authorizationGroupName groupName
    -roleName administrator -userids user1}
  • Añadir los ID de grupo a los roles de un grupo de autorización:
    $AdminTask mapGroupsToAdminRole {-authorizationGroupName groupName
    -roleName administrator -groupids group1}
  • Eliminar los ID de usuario de los roles de un grupo de autorización:
    AdminTask removeUsersFromAdminRole {-authorizationGroupName
    groupName -roleName administrator -userids user1}
  • Eliminar los ID de grupo de los roles de un grupo de autorización:
    $AdminTask removeGroupsFromAdminRole {-authorizationGroupName
    groupName -roleName administrator -groupids group1}

Recursos que pueden añadirse a un grupo de autorización

Sólo puede añadir recursos de los siguientes tipos a un grupo de autorización:
  • Cell
  • Nodo
  • ServerCluster
  • Servidor
  • Application
  • NodeGroup

Si un recurso no es uno de los tipos listados anteriormente, se utilizará el recurso padre.

Un recurso sólo puede pertenecer a un grupo de autorización. Sin embargo, existe una relación de contención entre los recursos. Si un recurso padre pertenece a un grupo de autorización distinto que el del recurso hijo, el recurso hijo implícitamente pertenecerá a varios grupos de autorización. No puede añadir el mismo recurso a más de un grupo de autorización.

El siguiente diagrama muestra la relación de contención entre los recursos:

Diagrama de relación de contención

Los privilegios necesarios para las acciones en los recursos dependen de dos factores:
  • El grupo de autorización del recurso administrativo. Si a un usuario se le otorga el acceso a un grupo de autorización, se incluirán todos los recursos de dicho grupo.
  • La relación de contención del recurso. Si a un usuario se le otorga el acceso a un recurso padre, se incluirán todos los recursos hijos.

La gestión de almacén de claves requiere que un usuario tenga privilegios administrativos a nivel de célula porque se crean y se gestionan a nivel de célula. El acceso de seguridad preciso a un recurso específico no permite la gestión de los almacenes de claves asociados.

Tabla 1. Privilegios necesarios para acceder a los distintos recursos administrativos . Los privilegios necesarios para acceder a los distintos recursos administrativos se muestran en la tabla siguiente:
Recurso Acción Roles necesarios
Servidor Operaciones de tiempo de ejecución, de inicio y de detención Operador de servidor, operador de nodo, operador de célula
Servidor Nueva, suprimir Configurador de nodo, configurador de célula
Servidor Editar configuración Configurador de servidor, configurador de nodo, configurador de célula
Servidor Ver configuración, estado de tiempo de ejecución Supervisor de servidor, supervisor de nodo, supervisor de célula
Nodo Reiniciar, detener o sincronizar Operador de nodo, operador de célula
Nodo Añadir, suprimir Configurador de célula
Nodo Editar configuración Configurador de nodo, configurador de célula
Nodo Ver configuración, estado de tiempo de ejecución Supervisor de nodo, supervisor de célula
Clúster Operaciones de tiempo de ejecución, de inicio y de detención Operador de clúster, operador de célula
Clúster Nueva, suprimir Configurador de célula
Clúster Editar configuración Configurador de clúster, configurador de célula
Clúster Ver configuración, estado de tiempo de ejecución Supervisor de clúster, supervisor de célula
Miembro de clúster Operaciones de tiempo de ejecución, de inicio y de detención Operador de servidor, operador de clúster, operador de nodo, operador de célula
Miembro de clúster Nueva, suprimir Configurador de nodo, configurador de célula
Miembro de clúster Editar configuración Configurador de servidor, configurador de clúster, configurador de nodo, configurador de célula
Miembro de clúster Ver configuración, estado de tiempo de ejecución Supervisor de servidor, supervisor de clúster, supervisor de nodo, supervisor de célula
Application Todas las operaciones Consulte la sección "Roles de desplegador" en Roles administrativos.
Nodo, Clúster Añadir, suprimir Configurador de célula

Este rol de operador de servidor es el rol de operador del grupo de autorización del que forma parte la instancia de servidor. De modo parecido, el rol de operador de nodo es el rol de operador del grupo de autorización del que forma parte la instancia de nodo.

Para utilizar la seguridad administrativa de precisión en la consola administrativa, se debe otorgar a un usuario un rol de supervisor a nivel de célula como mínimo. No obstante, para iniciar la sesión mediante wsadmin, se le debe otorgar a un usuario un rol de supervisor para cualquier grupo de autorización.

Ejemplo: uso de seguridad de alta precisión

Los escenarios siguientes describen cómo utilizar la seguridad administrativa de alta precisión, especialmente el nuevo rol de despliegue.

Escenario de rol de despliegue 1.

En el escenario siguiente, hay cuatro aplicaciones configuradas en el servidor S1, como se muestra en la tabla siguiente. Cada aplicación se debe aislar de modo que el administrador de una aplicación no pueda modificar otra aplicación. Presuponga que sólo user1 puede gestionar la aplicación A1, user2 puede gestionar las aplicaciones A2 y A3 y sólo user3 puede gestionar la aplicación A4.

Nota: No se recomienda tener una aplicación en un grupo y su servidor de destino en otro grupo. No obstante, esto no es siempre posible. Es común tener muchas aplicaciones en un servidor. Hay veces en que continúa siendo necesario aislar la administración de las aplicaciones que se ejecutan en el mismo servidor.

Un ejemplo de un ASP (Application Service Provider), en el que un único servidor de aplicaciones puede tener varias aplicaciones de proveedores. En esta instancia, el administrador del servidor es el responsable de instalar todas las aplicaciones de proveedores. Una vez instaladas las aplicaciones, cada proveedor puede gestionar su propia aplicación sin interferir con las aplicaciones de otros proveedores.

Tabla 2. Aplicaciones del escenario de rol de despliegue 1.

En esta tabla se ofrece una lista de las aplicaciones del escenario de rol de despliegue 1.

Application Servidor Nodo
A1 S1 N1
A2 S1 N1
A3 S1 N1
A4 S1 N1

Puede configurar los grupos de autorización como se muestra en el diagrama siguiente:

En el diagrama, la aplicación A1 se encuentra en el grupo de autorización G1, las aplicaciones A2 y A3 se encuentran en el grupo de autorización G2, y la aplicación A4 se encuentra en el grupo de autorización G3. Se asigna un rol de desplegador del grupo de autorización G1 a user1, del grupo de autorización G2 a user2, y del grupo de autorización G3 a user3.

En el diagrama, la aplicación A1 está en el grupo de autorización G1, las aplicaciones A2 y A3 están en el grupo de autorización G2 y la aplicación A4 es un grupo de autorización G3.

Se asigna user1 un rol de desplegador del grupo de autorización G1, a user2 del grupo de autorización G2 y a user3 del grupo de autorización G3.

Por consiguiente, user1 puede realizar todas las operaciones en la aplicación A1, user2 en las aplicaciones A2 y A3, y user3 en la aplicación A4. Dado que todas las aplicaciones comparten el mismo servidor, no se puede poner el mismo servidor en todos los grupos de autorización. Sólo un administrador a nivel de célula puede instalar una aplicación. Una vez completada la instalación de una aplicación, el desplegador de cada aplicación puede modificar las suyas propias. Para iniciar y detener el servidor, es necesaria la autorización administrativa a nivel de célula. Este tipo de escenario resulta útil en un entorno ASP.

Escenario de rol de despliegue 2

En el escenario siguiente, un grupo de aplicaciones requiere los mismos roles administrativos en un servidor. En este ejemplo, las aplicaciones A1 y A2 son aplicaciones relacionadas y las puede administrar un conjunto de administradores. Se ejecutan en el mismo servidor (S1). Las aplicaciones A3 y A4 requieren un conjunto de administradores diferente y se ejecutan en los servidores S2 y S3 respectivamente.

Tabla 3. Aplicaciones del escenario de rol de despliegue 2 .

En esta tabla se ofrece una lista de las aplicaciones del escenario de rol de despliegue 2.

Aplicación Servidor Nodo
A1 S1 N1
A2 S1 N1
A3 S2 N2
A4 S3 N3
En el escenario siguiente, un grupo de aplicaciones requiere los mismos roles administrativos para un servidor. En este ejemplo, las aplicaciones A1 y A2 son aplicaciones relacionadas, y pueden administrarse mediante un conjunto de administradores. Se ejecutan en el mismo servidor (S1). Las aplicaciones A3 y A4 requieren un conjunto de administradores distinto y se ejecutan en los servidores S2 y S3, respectivamente.
Escenarios que se pueden aplicar directamente en entornos de cliente.

Cada desarrollador debe poder modificar la configuración para su servidor y debe poder instalar su aplicación en dicho servidor. También debe poder iniciar y detener el servidor al igual que la aplicación en el servidor.

Los desarrolladores también deben poder configurar el servidor, de modo que puedan depurar los problemas que se encuentren. Deben tener la posibilidad de actualizar o modificar la aplicación que se está desarrollando. El grupo de autorizaciones administrativas para este desarrollador incluye al menos un servidor y cualquier aplicación que el desarrollador instala en dicho servidor.

Los desarrolladores también deben poder configurar el servidor, de modo que puedan depurar los problemas que se encuentren. Deben tener la posibilidad de actualizar o modificar la aplicación que se está desarrollando. El grupo de autorizaciones administrativas para este desarrollador incluye al menos un servidor y cualquier aplicación que el desarrollador instala en dicho servidor.

En el ejemplo siguiente, los desarrolladores del grupo de autorización G1 tienen una aplicación nueva (A11). Pueden instalar y destinar dicha aplicación nueva únicamente en los servidor del grupo de autorización G1. Asimismo, pueden colocar la aplicación nueva en el grupo de autorización (G1).

En el ejemplo siguiente, los desarrolladores del grupo de autorización G1 tienen una aplicación nueva (A11). Pueden instalar y destinar dicha aplicación nueva únicamente en los servidor del grupo de autorización G1. Asimismo, pueden colocar la aplicación nueva en el grupo de autorización (G1).
Escenario de entorno ASP.

En este escenario, el cliente es un ASP. Tienen sus propios clientes a los que proporcionan la función de servicio de aplicaciones. Desean que los clientes puedan administrar y supervisar las aplicaciones pero que no puedan ver ni administrar las aplicaciones de clientes diferentes. No obstante, en este ejemplo, el ASP tiene administradores de personal internos cuyo trabajo es mantener los servidores.

Este administrador de personal ASP interno ha de mover una aplicación de un servidor a otro para asegurarse de que una aplicación permanece disponible. El administrador del personal ASP interno debe poder detener e iniciar los servidores y modificar su configuración.

Por el contrario, el administrador del cliente ASP no debe poder detener ni iniciar los servidores. No obstante, el administrador del cliente ASP debe poder actualizar las aplicaciones que se ejecutan en dichos servidores. El grupo de autorización administrativa para el administrador ASP interno puede ser la célula completa o puede incluir un subconjunto de servidores, nodos, clústeres y aplicaciones. El grupo de autorización administrativa para el administrador de cliente sólo incluye las aplicaciones a las que este ASP debe dar servicio y que el cliente ha pagado.

Cuando actualice el repositorio de configuración, ejecute los scripts de administración desde el gestor de despliegue para que las reglas de seguridad de administración precisa se apliquen cuando se ejecuten los scripts de administración desde el lado del gestor de despliegue.

El diagrama siguiente contiene un escenario en el que dos clientes diferentes tienen dos tipos de aplicaciones diferentes y puede gestionar sus propias aplicaciones. No obstante, los servidores y nodos en los que se ejecutan las aplicaciones se aíslan de sus clientes. Los servidores y nodos sólo los pueden mantener los administradores internos. Asimismo, los clientes no pueden destinar sus aplicaciones a un servidor diferente. Esto sólo puede realizarlo el administrador interno o los desplegadores internos.

El siguiente diagrama contiene un escenario en el que dos clientes distintos tienen dos tipos distintos de aplicaciones, y pueden gestionar sus propias aplicaciones. No obstante, los servidores y nodos en los que se ejecutan las aplicaciones se aíslan de sus clientes. Los servidores y nodos sólo los pueden mantener los administradores internos. Asimismo, los clientes no pueden destinar sus aplicaciones a un servidor diferente. Esto sólo puede realizarlo el administrador interno o los desplegadores internos.
Escenario de organización regional.

En este escenario, el cliente es una empresa global de gran tamaño. Los nodos y los servidores de la empresa se organizan de modo que dan servicio a las aplicaciones a regiones diferentes (o alternativamente, diferentes líneas de empresa). Desean que los representantes de las diferentes áreas regionales puedan supervisar y administrar los nodos y servidores asociados a dicha región. No obstante, no desean que el administrador regional pueda afectar cualquier nodo y servidor asociado a una región diferente.

El grupo de autorización administrativa para cada representante regional incluye los nodos, servidores, clústeres y aplicaciones asociados a dicha región.

Por ejemplo, presuponga que se trata de una empresa que proporciona varios servicios como, por ejemplo, una institución financiera que proporciona servicios como, cuentas de tarjetas de crédito, cuentas de negocio, cuentas bancarias o cuentas de viaje. Cada uno de estos servicios pueden ser aplicaciones diferentes y el administrador de cada una de estas aplicaciones también debe ser diferente. La figura siguiente muestra un modo de configurar un sistema de este tipo:

La figura siguiente muestra un modo de configurar un sistema de este tipo.

La figura siguiente muestra cómo se pueden agrupar los recursos de un sistema de este tipo para aislar a los administradores entre sí:

La figura siguiente muestra cómo se pueden agrupar los recursos de un sistema de este tipo para aislar a los administradores entre sí:

Tenga en cuenta que los nodos no forman parte de ningún grupo de autorización. Por lo tanto, un administrador de aplicaciones de comercio no puede detener un servidor de cualquiera de los nodos y no puede detener una aplicación de viajes.

El mismo sistema se puede configurar de otro modo como se muestra a continuación:

El mismo sistema se puede configurar de otro modo como se muestra a continuación:

La figura siguiente muestra cómo se pueden agrupar los recursos de un sistema de este tipo para aislar a los administradores entre sí:

La figura siguiente muestra cómo se pueden agrupar los recursos de un sistema de este tipo para aislar a los administradores entre sí:

Icon that indicates the type of topic Concept topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_fineg_admsec
File name: csec_fineg_admsec.html