Seguridad del gestor de trabajos

En un entorno de gestión flexible, un ID de usuario debe tener la autorización necesaria para poder utilizar el gestor de trabajos y trabajar con los nodos registrados.

Roles de seguridad necesarios

Para poder utilizar el gestor de trabajos, son necesarios los roles siguientes:

Tabla 1. Roles de seguridad necesarios para las tareas del gestor de trabajos. Los roles pueden ser administrador, operador, configurador y supervisor.
Tareas administrativas Roles de seguridad necesarios
Registrar o eliminar un registro con el gestor de trabajos. administrador
Someter un trabajo. operador
Cambiar la configuración del gestor de trabajos. configurador
Leer la configuración o el historial de trabajos del gestor de trabajos. supervisor

Si los nodos del servidor de aplicaciones base (autónomo), que gestiona un agente administrativo, se registran con un gestor de trabajos, necesita los roles siguientes para poder utilizar el agente administrativo y gestionar sus nodos:

Tabla 2. Roles de seguridad necesarios para las tareas del agente administrativo. Entre los roles se incluyen el rol administrador y los roles necesarios para la operación o el nodo.
Tareas administrativas Roles de seguridad necesarios
Registrar o eliminar del registro un nodo base (autónomo) con el agente administrativo. administrador
Trabajar con el agente administrativo: Roles administrativos necesarios para la operación que se esté ejecutando
Trabajar con el subsistema administrativo como, por ejemplo, los nodos registrados Roles administrativos necesarios para el nodo base registrado

Cuando se ejecuta un trabajo en un destino, el usuario debe tener privilegios que incluyan el rol necesario para ese trabajo. Por ejemplo, un trabajo para crear un servidor de aplicaciones necesita un rol de configurador mínimo, tanto en el nodo base como en la célula de WebSphere Application Server, Network Deployment.

Seguridad para Installation Manager o los trabajos Liberty en hosts remotos

Cuando el acceso a un host remoto como, por ejemplo, un Installation Manager o Liberty requiere un nombre de usuario y una contraseña, debe proporcionar un nombre de usuario y una contraseña válidos de un sistema operativo para que un trabajo se ejecute en el host remoto. Puede proporcionar los siguientes tipos de autorización:

Nombre de usuario y contraseña de sistema operativo
El nombre de usuario y la contraseña son los valores de inicio de sesión para el host. Si el host no requiere una contraseña, no tendrá que proporcionar una contraseña al enviar un trabajo.
Sudo
Si desea que un usuario sustituto realice mandatos en el host, puede utilizar sudo para cambiar los usuarios antes de que se ejecute un trabajo y, a continuación, especificar el nombre de usuario y la contraseña para el usuario sustituto según sea necesario. sudo significa "substitute user do" (acción que realiza un usuario sustituto). Si el host no requiere una contraseña, no tendrá que proporcionar una contraseña al enviar un trabajo.
Autenticación de claves pública-privada
Puede utilizar la autenticación de clave pública-privada. Al someter un trabajo, especifique la vía de acceso completa al almacén de claves y, si es necesario para el almacén de claves, la frase secreta. Una clave privada SSH (Secure Shell) permite a un administrador ejecutar un trabajo en el host remoto bajo un nombre de usuario específico. La clave es una contraseña cifrada para evitar el uso por parte de un usuario diferente.

Para los servidores de Liberty, el tipo de autorización que se utiliza depende de los nombres de usuario configurados para cada host:

Nombre de usuario único
Si cada host utiliza sólo un nombre de usuario, sólo debe asegurarse de que el usuario puede escribir en los directorios para instalar los recursos de Liberty. Para soportar el envío de trabajos a hosts diferentes, asegúrese de que se ha configurado el mismo nombre de usuario en cada host o utilice una clave SSH para autenticarse como un nombre de host diferente para cada host.
Cambio a un nombre de usuario único
Si los hosts soportan varios nombres de usuario, puede someter los trabajos bajo nombres de usuario diferentes, pero utilice sudo para cambiar a un nombre de usuario común único. Sólo el nombre de usuario común puede gestionar recursos de Liberty. A menudo, este nombre de usuario se ha configurado para inhabilitar el inicio de sesión.
Nombres de usuario diferentes
En algunas configuraciones, puede instalar cada recurso de Liberty bajo un nombre de usuario de sistema operativo diferente. Por ejemplo, los recursos compartidos se pueden instalar bajo uno o más nombres de usuario y se puede hacer de forma global de sólo lectura o de sólo lectura para un grupo del sistema operativo específico. Los recursos de trabajo no compartidos se pueden crear de forma exclusiva para nombres de usuario distintos.

Puede controlar quién puede instalar recursos de Liberty controlando los permisos de archivos del directorio raíz para cada recurso. Si define el directorio como grabable por sólo un usuario, sólo un usuario puede realizar la instalación en dicho directorio. Si define el directorio como grabable por un grupo de usuarios, los usuarios que pertenecen a dicho grupo pueden instalar recursos bajo el directorio raíz. Si define el directorio como grabable de forma global, cualquier usuario puede realizar la instalación en dicho directorio.

Durante la instalación, puede definir los permisos de archivo que impiden a otros usuarios modificar los recursos. Por ejemplo, puede crear previamente ${WLP_WORKING_DIR}/project1 con permisos de archivo de modo que se pueda grabar sólo por un usuario específico, o un grupo específico. Después de que el usuario instala un nuevo Liberty, como server1, puede configurar ${WLP_WORKING_DIR}/project1/server1 de forma que un usuario diferente no lo pueda modificar.

Si varios usuarios pueden acceder a los recursos, debe definir variables o parámetros de trabajo que permiten a un trabajo de inventario encontrar todos los recursos disponibles:

  • Debe definir la variable WLP_ADDITIONAL_DIRS para que se puedan buscar recursos en todas las vías de acceso relevantes; o
  • Debe asegurarse de que todos los recursos son legibles por el nombre de usuario utilizado para ejecutar el trabajo de inventario. Los recursos se deben crear como legibles de forma global, los recursos deben poder ser leídos por el grupo del sistema con el nombre de usuario que pertenece al grupo o el nombre de usuario root se debe utilizar para ejecutar el trabajo de inventario.

Configuración de seguridad básica

El agente administrativo y el gestor de trabajos admiten dos configuraciones de seguridad básicas distintas:

  • Mismo dominio de seguridad

    En esta configuración, todas las células de la topología comparten el mismo registro de usuarios y, por tanto, el mismo dominio de seguridad. Lo mismo ocurre con el agente administrativo y sus nodos base registrados, y también con cualquier gestor de trabajos o células de WebSphere Application Server, Network Deployment de la topología.

  • Dominios de seguridad diferentes

    En esta configuración, todas las células se configuran con registros de usuarios distintos y, por consiguiente, con dominios de seguridad distintos.

Para la topología del agente administrativo, cuando un usuario inicia la sesión en el puerto del conector JMX de un subsistema administrativo, o elige el nodo registrado desde la consola administrativa, se utiliza la tabla de autorizaciones para el nodo base.

Por ejemplo, supongamos que el Usuario1 está autorizado como administrador para el primer nodo base, pero no lo está para el segundo nodo. El Usuario2 está autorizado como configurador para el segundo nodo, pero no lo está para el primer nodo. En la figura Mismo registro de usuarios se ilustra este ejemplo:

Configuración del mismo dominio de seguridad

Supongamos, además, que el Usuario1 puede iniciar la sesión en el gestor de trabajos como un operador, con un nombre de usuario y una contraseña. El Usuario1 también puede iniciar la sesión en el gestor de despliegue como supervisor, con un nombre de usuario y una contraseña. En la figura Registro de usuarios distinto se ilustra este ejemplo:

Configuración de un dominio de seguridad distinto

Aunque el Usuario1 tenga el mismo nombre de usuario tanto para el gestor de trabajos como para el gestor de despliegue, es probable que el Usuario1 tenga nombres de usuario y contraseñas diferentes.

Transferencia de información de seguridad

Cuando el producto transfiere un trabajo del gestor de trabajos al agente administrativo, al gestor de despliegue o al sistema host, el producto también transfiere la información de seguridad acerca del emisor de trabajos. Esta transferencia autentica y autoriza al usuario mientras se ejecuta el trabajo. Con un trabajo sometido se puede pasar la información de seguridad de usuario siguiente:

  • Nombre de usuario y contraseña

    Al someter un trabajo, el usuario puede especificar un nombre de usuario y una contraseña. Cuando el trabajo alcance el subsistema administrativo o el gestor de despliegue, se utilizarán el nombre de usuario y la contraseña para poder iniciar la sesión.

    Para la configuración del mismo registro de usuarios, si Jaime somete un trabajo respecto al primer nodo base, puede especificar su nombre de usuario y contraseña como parte del trabajo. El nombre de usuario y la contraseña se utilizan para iniciar la sesión en el primer subsistema administrativo, y se ejecuta el trabajo. Si Jaime somete un trabajo respecto a la célula del gestor de despliegue o el segundo nodo base, el trabajo falla, debido a que Jaime no está autorizado.

    En el caso de la configuración de registro de usuarios distinto, Jaime puede someter un trabajo respecto a la célula del gestor de despliegue, especificando su nombre de usuario y contraseña para dicha célula del gestor de despliegue. Cuando el trabajo llegue al gestor de despliegue, el inicio de sesión se realiza de forma satisfactoria, y el trabajo se ejecuta. Si Jaime somete un trabajo respecto a los nodos base, se deniega el acceso, y el trabajo falla.

  • Señal de seguridad

    Si el usuario no especifica el nombre de usuario y la contraseña con un trabajo, la credencial del usuario se persiste automáticamente, como una señal de seguridad, en la base de datos de trabajos. La señal contiene los atributos de seguridad del usuario, incluidos los grupos. Cuando se capta un trabajo, la señal se utiliza para autenticar y autorizar respecto el subsistema administrativo, o el gestor de despliegue.

    En el caso de la configuración del mismo registro de usuarios, Jaime puede someter un trabajo respecto al primer nodo base, sin tener que especificar ni el nombre de usuario ni la contraseña. El trabajo se ejecuta porque las credenciales de Jaime se propagan automáticamente como una señal de seguridad al subsistema administrativo, y se utilizan para autenticarle y autorizarle para el trabajo. Si Jaime somete un trabajo respecto al segundo nodo base o a la célula del gestor de despliegue, el trabajo falla porque esta señal de seguridad no está autorizada en estos dos entornos.

    En el caso de la configuración del registro de usuarios distinto, la señal de seguridad de un usuario no permite que, automáticamente, el trabajo sometido se ejecute respecto al subsistema administrativo o el gestor de despliegue. Para habilitar una señal de usuario para un reino distinto, deberá utilizar la característica de varios dominios de seguridad. En primer lugar, deberá establecer el reino del gestor de trabajos como un reino de confianza para los nodos base registrados y la célula del gestor de despliegue. Además, deberá importar el ID de acceso del usuario del gestor de trabajos a la tabla de autorizaciones local, y otorgar un rol al ID de acceso. Después, el usuario podrá someter un trabajo sin tener que pasar el nombre de usuario y la contraseña.

    Supongamos que Jaime es un operador en el gestor de trabajos, pero su ID de acceso se importa como administrador, en la tabla de autorizaciones administrativa del primer nodo base. Aunque Jaime no exista en el registro de usuarios del nodo base, al pasar la señal de seguridad y la definición de la tabla de autorizaciones administrativa, Jaime estará autorizado como administrador en el nodo base. Jaime puede someter un trabajo para el primer nodo base sin tener que especificar ni un nombre de usuario ni una contraseña.

    Si Jaime somete un trabajo respecto al gestor de despliegue, el trabajo fallará. La señal de seguridad de Jaime es a partir del reino del gestor de trabajos, y el ID de acceso de Jaime no tiene autorización para el gestor de despliegue. En este caso, el administrador puede exportar el ID de acceso de Jaime del gestor de trabajos, e importarlo al gestor de despliegue. O bien, Jaime puede someter un trabajo pasando un nombre de usuario y una contraseña que tuviera para el gestor de despliegue, que le permite a Jaime ejecutar trabajos con el rol de supervisor.

    El mismo mecanismo funciona si se está utilizando la característica de seguridad precisa. Debe estar autorizado en la tabla de autorizaciones para un grupo de autorización nuevo. La tabla de autorizaciones también puede contener un ID de acceso externo.

Configuración de registros combinados

En una topología más compleja, donde algunas células comparten el mismo registro de usuarios y algunas células no, se aplican las reglas siguientes:

  • Siempre puede especificar un nombre de usuario y una contraseña durante la sometimiento de trabajos si el nodo de destino o el gestor de despliegue reconocen el nombre de usuario y la contraseña.
  • Si el gestor de trabajos y el nodo de destino o un gestor de despliegue tienen el mismo registro de usuarios, el sometimiento de trabajos no requiere ni el nombre de usuario ni la contraseña. No obstante, debe estar autorizado para el nodo de destino o el gestor de despliegue.
  • Si el gestor de trabajos y el nodo de destino o un gestor de despliegue tienen registros de usuarios distintos, se han establecido los reinos de confianza, y el ID de acceso del emisor de trabajos se ha importado a la tabla de autorizaciones administrativas del nodo de destino o del gestor de despliegue, el sometimiento de trabajos no requiere ni el nombre de usuario ni la contraseña.

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=cagt_jobmgr_security
File name: cagt_jobmgr_security.html