test

Guía del administrador de negocio de Sun Identity Manager 8.1

Capítulo 12 Seguridad

Este capítulo contiene información acerca de las funciones de seguridad de Identity Manager e instrucciones detalladas para reducir aún más los riesgos de seguridad.

Los temas siguientes le ayudarán a administrar mejor la seguridad del sistema con Identity Manager.

Funciones de seguridad

Identity Manager ayuda a reducir los riesgos de seguridad con las siguientes funciones:

Además, la arquitectura del sistema está diseñada para reducir los riesgos de seguridad al máximo. Por ejemplo, una vez cerrada una sesión, no es posible acceder a las páginas recién visitadas con la función Retroceder del navegador.

Limitación de sesiones concurrentes

De manera predeterminada, un usuario de Identity Manager puede iniciar sesiones simultáneas. No obstante, las sesiones simultáneas se pueden limitar a una por aplicación de inicio de sesión. Para ello, abra el objeto de configuración del sistema para modificarlo (Edición de objetos de configuración de Identity Manager) y edite el valor del atributo de configuración security.authn.singleLoginSessionPerApp. Este atributo es un objeto que contiene un atributo para cada nombre de aplicación de inicio de sesión (por ejemplo, la interfaz de administración, la interfaz de usuario o Identity Manager IDE). Al cambiar el valor de este atributo a true, se asegura que haya una sola sesión por cada usuario.

Si se ejecuta, un usuario podrá iniciar sesión en varias sesiones; sin embargo, sólo la última sesión iniciada permanecerá activa y válida. Si el usuario realiza una acción en una sesión no válida, se le expulsará automáticamente de la sesión y ésta terminará.

Administración de contraseñas

Identity Manager ofrece administración de contraseñas en varios niveles:

Autenticación al paso

Utilice autenticación al paso para conceder acceso de usuario y administrador con una o más contraseñas distintas.

Identity Manager administra la autenticación mediante la implementación de:

Acerca de las aplicaciones de inicio de sesión

Las aplicaciones de inicio de sesión hacen referencia a un conjunto de grupos de módulos de inicio de sesión que definen el conjunto y orden de los módulos de inicio de sesión que se utilizarán cuando un usuario inicie una sesión de Identity Manager. Cada aplicación de inicio de sesión consta de uno o más grupos de módulos de inicio de sesión.

Al iniciar la sesión, la aplicación comprueba el conjunto de los grupos de módulos de inicio de sesión. Si sólo hay un grupo de módulos de inicio de sesión establecido, se utiliza dicho módulo y se procesan los módulos de inicio de sesión contenidos en él en el orden definido por el grupo. Si la aplicación de inicio de sesión tiene más de un grupo de módulos de inicio de sesión definido, Identity Manager comprueba las reglas de restricción de inicio de sesión que se aplican a cada grupo de módulos de inicio de sesión para determinar el grupo que va a procesar.

Reglas de restricciones de inicio de sesión

Las reglas de restricciones de inicio de sesión se aplican a los grupos de módulos de inicio de sesión. Para cada conjunto de grupos de módulos de inicio de sesión de una aplicación de inicio de sesión, sólo puede haber uno que no tenga una regla de restricciones de inicio de sesión aplicada.

Al determinar el grupo de módulos de inicio de sesión de un conjunto que se va a procesar, Identity Manager evalúa la primera regla de restricciones del grupo de módulos de inicio de sesión. Si la evalúa correctamente, procesa ese grupo de módulos de inicio de sesión. Si falla, evalúa cada grupo de módulos de inicio de sesión hasta encontrar una regla de restricciones adecuada o evaluar un grupo de módulos de inicio de sesión sin regla de restricciones (que será el que se utilice).

Nota –

Si una aplicación de inicio de sesión contiene más de un grupo de módulos de inicio de sesión, el grupo de módulos de inicio de sesión sin reglas de restricciones de inicio de sesión debe colocarse en último lugar.

Ejemplo de regla de restricciones de inicio de sesión

En el siguiente ejemplo de una regla de restricciones de inicio de sesión basada en la ubicación, la regla toma la dirección IP del solicitante del encabezado HTTP y después la comprueba para ver si se encuentra en la red 192.168. Si se encuentra 192.168. en la dirección IP, la regla devolverá un valor “true” y se seleccionará el grupo de módulos de inicio de sesión.

Ejemplo 12–1 Regla de restricciones de inicio de sesión basada en ubicación


<Rule authType=’LoginConstraintRule’ name=’Sample On Local Network’> 
<match> <ref>remoteAddr</ref> <s>192.168.</s> </match> 
<MemberObjectGroups> <ObjectRef type=’ObjectGroup’ name=’All’/> </MemberObjectGroups> 
</Rule>

Edición de aplicaciones de inicio de sesión

En la barra de menús, seleccione Seguridad -> Inicio de sesión para acceder a la página de inicio de sesión.

La lista de aplicaciones de inicio de sesión muestra:

En la página de inicio de sesión puede:

Para editar una aplicación de inicio de sesión, selecciónela en la lista.

Configuración de los límites de sesión de Identity Manager

En la página Modificar aplicación de inicio de sesión puede definir un valor de tiempo de espera (límites) para cada sesión iniciada en Identity Manager. Seleccione horas, minutos y segundos y, a continuación, haga clic en Guardar. Los límites que establezca se mostrarán en la lista de aplicaciones de inicio de sesión.

Puede definir tiempos de espera de sesión para cada aplicación de inicio de sesión en Identity Manager. Cuando un usuario inicia una sesión en una aplicación de Identity Manager, el valor de tiempo de espera de sesión configurado actualmente se aplica para calcular la fecha y la hora en que la sesión del usuario terminará por inactividad. La fecha calculada se almacena con la sesión de Identity Manager del usuario de modo que pueda comprobarse cada vez que se efectúe una solicitud.

Si un administrador de inicio de sesión cambia el valor de tiempo de espera de sesión de una aplicación de inicio de sesión, dicho valor se aplicará a todos los inicios de sesión posteriores. Las sesiones existentes terminarán de acuerdo con el valor que había vigente cuando el usuario inicio la sesión.

El valor definido para el tiempo de espera de HTTP afecta a todas las aplicaciones de Identity Manager tiene prioridad sobre el valor de tiempo de espera de sesión de la aplicación de inicio de sesión.

Inhabilitación del acceso a aplicaciones

En las páginas Crear aplicación de inicio de sesión y Modificar aplicación de inicio de sesión se puede seleccionar la opción Inhabilitar para inhabilitar una aplicación de inicio de sesión, con el fin de impedir el acceso de los usuarios. Si un usuario intenta iniciar una sesión en una aplicación inhabilitada, se le redirige a una página alternativa que le advierte de que la aplicación está inhabilitada en ese momento. Para editar el mensaje que aparece en dicha página puede editar el catálogo personalizado.

Las aplicaciones de inicio de sesión permanecen inhabilitadas hasta que se desactiva la opción. Como medida de seguridad, el usuario no puede inhabilitar el inicio de sesión del administrador.

Edición de grupos de módulos de inicio de sesión

La lista de grupos de módulos de inicio de sesión muestra:

En la página Grupos de módulos de inicio de sesión puede crear, editar y eliminar grupos de módulos de inicio de sesión. Para editar un grupo de módulos de inicio de sesión, selecciónelo en la lista.

Edición de módulos de inicio de sesión

A continuación se explica cómo introducir detalles o seleccionar opciones para los módulos de inicio de sesión. (No todas las opciones están disponibles para cada módulo de inicio de sesión.).

Haga clic en Guardar para guardar el módulo de inicio de sesión. Una vez guardado, puede ubicar el módulo con relación a los otros módulos del grupo de módulos de inicio de sesión.

Precaución – Precaución –

Si el inicio de sesión de Identity Manager está configurado para autenticar en más de un sistema, se debe definir el mismo ID de usuario de cuenta y la misma contraseña en todos los sistemas en los que Identity Manager realiza la autenticación.

Si varían las combinaciones de ID de usuario y contraseña, el inicio de sesión puede fallar en los sistemas cuyos ID de usuario y contraseña no coincidan con aquéllos introducidos en el formulario de inicio de sesión de Identity Manager.

Algunos de estos sistemas pueden tener una directiva de bloqueo que fuerce el bloqueo de una cuenta tras un número de intentos erróneos de inicio de sesión. En estos casos, las cuentas se acaban bloqueando, incluso aunque los usuarios sigan iniciando las sesiones satisfactoriamente en Identity Manager.

El Ejemplo 12–2 contiene seudocódigo que describe los pasos que sigue Identity Manager para asignar IDs de usuario autenticado a usuarios de Identity Manager.

Ejemplo 12–2 Lógica de proceso de módulo de inicio de sesión


if an existing IDM user’s ID is the same as the specified user ID 

   if that IDM user has a linked resource whose resource name matches the 
   resource that was authenticated and whose accountId matches the resource 
   accountId returned by successful authentication (e.g. dn), then we have 
   found the right IDM user 

   otherwise if there is a LoginCorrelationRule associated with the 
   configured login module 

      evaluate it to see if it maps the login credentials to a single IDM 
      user 

      otherwise login fails 

   otherwise login fails 

if the specified userID does not match an existing IDM user’s ID 

   try to find an IDM user that has a linked resource whose resource 
   name matches the resource accountID returned by successful authentication 

     if found, then we have found the right IDM user 

     otherwise if there is a LoginCorrelationRule associated with the 
     configured login module 

         evaluate it to see if it maps the login credentials to a single 
         IDM user 

         otherwise login fails 

     otherwise login fails

En el Ejemplo 12–2, el sistema intentará encontrar un usuario coincidente de Identity Manager empleando los recursos vinculados del usuario (información de recursos). Si falla el intento con la información de recursos y hay configurada una regla de correlación de inicio de sesión, el sistema intentará encontrar un usuario coincidente aplicando dicha regla.

Configuración de la autenticación para recursos comunes

Si tiene múltiplos recursos que son lógicamente iguales (por ejemplo, varios servidores de dominio de Active Directory que comparten una relación de confianza), o diversos recursos que residen en el mismo host físico, puede especificar que son recursos comunes.

Debe declarar los recursos comunes para que Identity Manager sepa que sólo debe intentar autenticar con un grupo de recursos a la vez. De lo contrario, si un usuario escribe una contraseña equivocada, Identity Manager probará la misma contraseña en cada recurso. Ello puede ocasionar el bloqueo de la cuenta del usuario a raíz de varios fallos de inicio de sesión, incluso aunque el usuario sólo haya introducido mal la contraseña una vez.

Los recursos comunes permiten que un usuario autentique en un solo recurso común, mientras que Identity Manager intentará asignar el usuario a los demás recursos del grupo de recursos comunes. Por ejemplo, una cuenta de usuario de Identity Manager se puede vincular a una cuenta de recursos para el recurso AD-1. Sin embargo, el grupo de módulos de inicio de sesión puede establecer que los usuarios deben autenticarse en el recurso AD-2.

Si AD-1 y AD-2 se han definido como recursos comunes (en este caso, en el mismo dominio de confianza), cuando el usuario autentica con éxito en AD-2, Identity Manager también puede asignar el usuario a AD-1 buscando el mismo ID de cuenta de usuario en el recurso AD-1.

Precaución – Precaución –

Todos los recursos incluidos en un grupo de recursos comunes también deben incluirse en la definición del módulo de inicio de sesión. Si dicha definición no contiene una lista completa de los recursos comunes, la funcionalidad de recursos comunes no actuará correctamente.

Los recursos comunes pueden definirse en el objeto de configuración del sistema (Edición de objetos de configuración de Identity Manager) con el formato indicado a continuación.

Ejemplo 12–3 Configuración de la autenticación para recursos comunes


<Attribute name=’common resources’> 
<Attribute name=’Common Resource Group Name’> 
<List> 
<String>Common Resource Name</String> 
<String>Common Resource Name</String> 
</List 
</Attribute> </Attribute>

Configuración de la autenticación mediante certificado X509

Utilice la información y los procedimientos descritos a continuación para configurar la autenticación basada en el certificado X509 para Identity Manager.

Requisitos previos de configuración

Para poder realizar autenticación basada en el certificado X509 en Identity Manager, asegúrese de que esté bien configurada la autenticación SSL bidireccional (de cliente y servidor). Desde la perspectiva del cliente, esto significa que se debe haber importado al navegador un certificado de usuario conforme con X509 (o tenerlo disponible en un lector de tarjetas inteligentes), y que el certificado de confianza empleado para firmar el certificado de usuario debe importarse al almacén de claves de certificados de confianza situado en el servidor de aplicaciones.

Asimismo, el certificado de cliente debe habilitarse para autenticación de cliente.

ProcedurePara verificar si está seleccionada la opción de autenticación de cliente del certificado de cliente

  1. En Internet Explorer, elija Herramientas y después Opciones de Internet.

  2. Seleccione la ficha Contenido.

  3. En el área Certificados, pulse Certificados.

  4. Seleccione el certificado de cliente y pulse Avanzadas.

  5. Dentro de Propósito del certificado, asegúrese de que esté marcada la opción Autenticación del cliente.

Configuración de la autenticación mediante certificado X509 en Identity Manager

ProcedurePara configurar la autenticación mediante certificado X509

  1. Inicie una sesión en la interfaz de administración como configurador (o con permisos equivalentes).

  2. Seleccione Configurar y después Inicio de sesión para acceder a la página de inicio de sesión.

  3. Haga clic en Administrar grupos de módulos de inicio de sesión para ver la página Grupos de módulos de inicio de sesión.

  4. Seleccione un grupo de módulos de inicio de sesión en la lista.

  5. Elija Módulo de inicio de sesión con certificado X509 de Identity Manager en la lista Asignar módulo de inicio de sesión. Identity Manager muestra la página Modificar módulo de inicio de sesión.

  6. Defina el requisito para un inicio de sesión correcto.

    Se admiten los valores siguientes:

    • Requerido. Es necesario el módulo de inicio de sesión para una autenticación con éxito. Independientemente de si se realiza con éxito o falla, la autenticación continúa con el siguiente módulo de inicio de sesión de la lista. Si es el único módulo de inicio de sesión, el usuario o el administrador ha iniciado la sesión con éxito.

    • Requisito. Es necesario el módulo de inicio de sesión para una autenticación con éxito. Si se realiza con éxito, la autenticación continúa con el siguiente módulo de inicio de sesión de la lista. Si falla, la autenticación no continúa.

    • Suficiente. No es necesario el módulo de inicio de sesión para una autenticación con éxito. Si se realiza con éxito, el proceso de autenticación no necesita pasar al siguiente módulo de inicio de sesión y el administrador accede correctamente. Si fracasa, el proceso de autenticación continúa con el siguiente módulo de inicio de sesión de la lista.

    • Opcional. No es necesario el módulo de inicio de sesión para una autenticación con éxito. Independientemente de si se realiza con éxito o falla, la autenticación continúa con el siguiente módulo de inicio de sesión de la lista.

  7. Seleccione una regla de correlación de inicio de sesión. Puede ser una regla de correlación interna o personalizada. (En la próxima sección se explica cómo crear reglas de correlación personalizadas.)

  8. Pulse Guardar para volver a la página Modificar grupo de módulos de inicio de sesión.

  9. Si lo desea, reordene los módulos de inicio de sesión (cuando hay varios módulos de inicio de sesión asignados al grupo) y pulse Guardar.

  10. Asigne el grupo de módulos de inicio de sesión a una aplicación de inicio de sesión si aún no está asignado. En la página Grupos de módulos de inicio de sesión, haga clic en Volver a las aplicaciones de inicio de sesión y seleccione una aplicación de inicio de sesión. Una vez asignado un grupo de módulos de inicio de sesión a la aplicación, hacer clic, pulse Guardar.

    Nota –

    Si la opción allowLoginWithNoPreexistingUser está definida en true en el archivo waveset.properties, al configurar el Módulo de inicio de sesión con certificado X509 de Identity Manager, se le pedirá que seleccione una regla de nombre de usuario nuevo. Esta regla determina cómo se nombran los nuevos usuarios creados cuando no los encuentra la regla de correlación de inicio de sesión asociada. La regla de nombre de usuario nuevo tiene disponibles los mismos argumentos de entrada que la regla de correlación de inicio de sesión. Devuelve una sola cadena, consistente en el nombre de usuario empleado para crear la nueva cuenta de usuario de Identity Manager. En idm/sample/rules, hay un ejemplo de regla de nombre de usuario nuevo denominada NewUserNameRules.xml.

Creación e importación de reglas de correlación de inicio de sesión

Una regla de correlación de inicio de sesión sirve al Módulo de inicio de sesión con certificado X509 de Identity Manager para establecer cómo asignar los datos del certificado al usuario adecuado de Identity Manager. Identity Manager incluye una regla de correlación de inicio de sesión interna, denominada Correlacionar con SubjectDN de Certificado X509.

También se pueden agregar reglas de correlación propias. Consulte el ejemplo de LoginCorrelationRules.xml , situado en el directorio idm/sample/rules.

Cada regla de correlación debe respetar estas pautas:

Estos son los argumentos que admiten las reglas de correlación de inicio de sesión:

Los argumentos de certificado que admiten las reglas de correlación de inicio de sesión siguen esta convención de nomenclatura:

cert.field name.subfield name

Los nombres de argumento de ejemplo disponibles para la regla incluyen:

La regla de correlación de inicio de sesión, con los argumentos admitidos, devuelve una lista de una o varias AttributeConditions. El Módulo de inicio de sesión con certificado X509 de Identity Manager utiliza estas condiciones para encontrar el usuario de Identity Manager asociado.

En idm/sample/rules hay un ejemplo de regla de correlación de inicio de sesión denominada LoginCorrelationRules.xml.

Tras crear una regla de correlación personalizada, debe importarla a Identity Manager. En la interfaz de administración, seleccione Configurar y después Importar archivo de intercambio para usar la utilidad de importación.

Verificación de la conexión SSL

Para verificar la conexión SSL, acceda a la URL de la interfaz de la aplicación configurada mediante SSL (por ejemplo, https://idm007:7002/idm/user/login.jsp). Se le advertirá que está entrando en un sitio seguro y luego se le pedirá que elija un certificado personal para enviarlo al servidor web.

Diagnóstico de problemas

Puede informar sobre los problemas de autenticación utilizando los certificados X509 como mensajes de error en el formulario de inicio de sesión.

Para realizar diagnósticos más completos, habilite el seguimiento en el servidor de Identity Manager para estas clases y niveles:

Si el atributo de certificado de cliente tiene un nombre distinto a javaxservlet.request.X509Certificate en la solicitud HTTP, un mensaje le advertirá que este atributo no se puede encontrar dicho atributo en la solicitud HTTP.

ProcedurePara corregir un nombre de atributo de certificado de cliente en una solicitud HTTP

  1. Habilite el seguimiento de SessionFactory para ver la lista completa de atributos HTTP y averiguar el nombre del certificado X509.

  2. Con la utilidad de depuración de Identity Manager (Página de depuración de Identity Manager), edite el objeto LoginConfig.

  3. Cambie el nombre de <AuthnProperty> en <LoginConfigEntry> por el nombre correcto para el Módulo de inicio de sesión con certificado X509 de Identity Manager.

  4. Guarde y vuelva a intentarlo.

    Quizá también necesite suprimir y después volver a añadir el Módulo de inicio de sesión con certificado X509 de Identity Manager en la aplicación de inicio de sesión.

Uso y administración del cifrado

El cifrado sirve para garantizar la confidencialidad y la integridad de los datos del servidor en la memoria y en el depósito, así como todos los datos transmitidos entre el servidor y la puerta de enlace de Identity Manager.

Los próximos apartados contienen más información sobre el uso y la administración del cifrado en el servidor y la puerta de enlace de Identity Manager, con respuestas a preguntas sobre las claves de cifrado de ambos.

Datos protegidos mediante cifrado

En la tabla siguiente se enumeran los tipos de datos protegidos mediante cifrado en el producto Identity Manager, incluidos los tipos de cifrado con que se protegen.

Tabla 12–1 Tipos de datos protegidos mediante cifrado

Tipo de datos  

RSAMD5 

Clave NIST Triple DES de 168 Bits (DESede/ECB/NoPadding) 

Clave de cifrado de 56 bits basada en contraseña PKCS#5 (PBEwithMD5andDES) 

Claves de cifrado de servidor 

 

predeterminado 

opción de configuración 

Claves de cifrado de puerta de enlace 

 

predeterminado 

opción de configuración 1 

Palabras del diccionario de directivas 

sí 

   

Contraseñas de usuario 

 

sí 

 

Historial de contraseñas de usuario 

 

sí 

 

Respuestas de usuario  

 

sí 

 

Contraseñas de recurso 

 

sí 

 

Historial de contraseñas de recurso 

sí 

   

Toda la carga útil entre el servidor y las puertas de enlace 

 

sí 

 

Preguntas frecuentes sobre claves de cifrado de servidor

A continuación encontrará respuestas a preguntas frecuentes sobre el origen de las claves de cifrado de servidor, su ubicación, mantenimiento y uso.

Pregunta:

¿De dónde proceden las claves de cifrado de servidor?

Respuesta:

Las claves de cifrado de servidor son claves Triple-DES simétricas de 168 bits.

El servidor admite dos tipos de claves:

Pregunta:

¿Dónde se mantienen las claves de cifrado de servidor?

Respuesta:

Las claves de cifrado de servidor son objetos que se mantienen en el depósito. Cualquier depósito puede contener muchas claves de cifrado.

Pregunta:

¿Cómo sabe el servidor qué clave utilizar para descifrar y volver a cifrar datos cifrados?

Respuesta:

Cada dato cifrado que se almacena en el depósito va precedido por el ID de la clave de cifrado del servidor utilizada para cifrarlo. Cuando un objeto que contiene datos cifrados se lee en la memoria, Identity Manager utiliza la clave de cifrado de servidor asociada al ID que precede a los datos cifrados para descifrarlos y después vuelve a cifrarlos con la misma clave si los datos han cambiado.

Pregunta:

¿Cómo se actualizan las claves de cifrado de servidor?

Respuesta:

Identity Manager ofrece una tarea llamada Administrar el cifrado del servidor.

Esta tarea permite que un administrador de seguridad autorizado realice diversas tareas de administración de claves, incluidas:

Encontrará más información sobre el uso de esta tarea dentro de la sección Administración de cifrado del servidor en este mismo capítulo.

Pregunta:

¿Qué sucede con los datos cifrados existentes si cambia la clave de servidor "actual"?

Respuesta:

Nada. Los datos cifrados se descifran o vuelven a cifrar igualmente con la clave referenciada por el ID que les precede. Si se genera una nueva clave de cifrado de servidor y se define como clave "actual", todos los nuevos datos que se cifren utilizarán la nueva clave de servidor.

A fin de evitar problemas por exceso de claves y de mantener un mayor grado de integridad de los datos, utilice la tarea Administrar el cifrado del servidor para volver a cifrar todos los datos cifrados existentes con la clave de cifrado de servidor "actual".

Pregunta:

¿Qué sucede cuando se importan datos cifrados para los que no hay disponible una clave de cifrado?

Respuesta:

Si importa un objeto que contiene datos cifrados con una clave que no se encuentra en el depósito al que se importa, los datos se importarán, pero no se descifrarán.

Pregunta:

¿Cómo se protegen las claves de servidor?

Respuesta:

Si el servidor no está configurado para utilizar el cifrado PKCS#5 basado en contraseña (PBE), que se define en el objeto de configuración del sistema mediante el atributo pbeEncrypt o la tarea Administrar el cifrado del servidor, las claves de servidor se cifran utilizando la clave predeterminada. La clave predeterminada es la misma para todas las instalaciones de Identity Manager.

Si el servidor está configurado para utilizar cifrado PBE, se genera una clave PBE cada vea que se inicia el servidor. La clave PBE se genera suministrando al algoritmo de cifrado PBEwithMD5andDES una contraseña, generada a partir de un secreto específico del servidor. La clave PBE se mantiene sólo en la memoria y nunca persiste. Además, la clave PBE es igual para todos los servidores que comparten un depósito común.

Para habilitar el cifrado PBE de las claves de servidor, debe estar disponible el algoritmo de cifrado PBEwithMD5andDES. Identity Manager no ofrece este algoritmo de manera predeterminada, pero es un estándar PKCS#5 presente en las implementaciones de muchos proveedores de JCE, como los que suministran Sun e IBM.

Pregunta:

¿Puedo exportar las claves de servidor para proteger el almacenamiento externo?

Respuesta:

Sí. Si las claves de servidor se cifran mediante PBE, antes de exportarlas se descifrarán y volverán a cifrar con la clave predeterminada. Ello permite importarlas más adelante al mismo servidor o a otro distinto, con independencia de la clave PBE del servidor local. Si las claves de servidor se cifran con la clave predeterminada, no se preprocesan antes de exportarlas.

Cuando se importan a un servidor, si éste se ha configurado para claves PBE, las claves se descifran y se vuelven a cifrar con la clave PBE del servidor local, en caso de que dicho servidor esté configurado para cifrado de claves PBE.

Pregunta:

¿Qué datos se cifran entre el servidor y la puerta de enlace?

Respuesta:

Todos los datos (carga útil) transmitidos entre el servidor y la puerta de enlace se cifran en Triple-DES con una clave de 168 bits simétrica generada aleatoriamente por sesión servidor-puerta de enlace.

Preguntas frecuentes sobre claves de puerta de enlace

A continuación encontrará respuestas a preguntas frecuentes sobre el origen de las claves de puerta de enlace, su almacenamiento, distribución y protección.

Pregunta:

¿De dónde proceden las claves de puerta de enlace para cifrar o descifrar los datos?

Respuesta:

Cada vez que un servidor de Identity Manager se conecta a una puerta de enlace, el protocolo de enlace inicial genera aleatoriamente una nueva clave de sesión Triple-DES de 168 bits. Esta clave sirve para cifrar o descifrar todos los datos que se transmitan después entre ese servidor y esa puerta de enlace. Por cada par servidor/puerta de enlace se genera una única clave de sesión.

Pregunta:

¿Cómo se distribuyen las claves de puerta de enlace a las puertas de enlace?

Respuesta:

El servidor genera aleatoriamente las claves de sesión, que después se intercambian de manera segura entre el servidor y la puerta de enlace cifrándolas con la clave maestra secreta compartida dentro del protocolo de enlace inicial servidor-a-puerta de enlace.

Cuando se ejecuta el protocolo de enlace inicial, el servidor consulta la puerta de enlace para determinar qué modo admite. La puerta de enlace puede operar en dos modos.

Pregunta:

¿Puedo actualizar las claves de puerta de enlace utilizadas para cifrar o descifrar la carga útil servidor-a-puerta de enlace?

Respuesta:

Identity Manager ofrece una tarea llamada Administrar el cifrado del servidor, que permite a un administrador de seguridad autorizado efectuar diversas tareas de administración de claves, incluida la generación de una nueva clave de puerta de enlace "actual" y la actualización de todas las puertas de enlace con dicha clave. Dicha clave se utiliza para cifrar la clave por sesión que sirve para proteger toda la carga útil transmitida entre el servidor y la puerta de enlace. La clave de puerta de enlace recién generada se cifra con la clave predeterminada o la clave PBE, según el valor que tenga el atributo pbeEncrypt en la configuración del sistema (Edición de objetos de configuración de Identity Manager).

Pregunta:

¿Dónde se almacenan las claves de puerta de enlace en el servidor y en la puerta de enlace?

Respuesta:

En el servidor, la clave de puerta de enlace se almacena en el depósito, igual que las claves de servidor. En el la puerta de enlace, la clave de puerta de enlace se almacena en una clave de registro local.

Pregunta:

¿Cómo se protegen las claves de puerta de enlace?

Respuesta:

Las claves de puerta de enlace se protegen del mismo modo que las de servidor. Si el servidor está configurado para usar cifrado PBE, la clave de la puerta de enlace se cifrará con una clave generada mediante PBE. Si la opción está definida en false, se cifrará con la clave predeterminada. Encontrará más información dentro de Preguntas frecuentes sobre claves de cifrado de servidor.

Pregunta:

¿Puedo exportar la clave puerta de enlace para proteger el almacenamiento externo?

Respuesta:

La clave de puerta de enlace se puede exportar con la tarea Administrar el cifrado del servidor, igual que las claves de servidor. Encontrará más información dentro de Preguntas frecuentes sobre claves de cifrado de servidor.

Pregunta:

¿Cómo se destruyen las claves de servidor y de puerta de enlace?

Respuesta:

Las claves de servidor y de puerta de enlace se destruyen eliminándolas del depósito del servidor. Recuerde que no se debe eliminar una clave mientras aún haya datos del servidor cifrados con dicha clave o alguna puerta de enlace que dependa de ella. Utilice la tarea Administrar el cifrado del servidor para volver a cifrar todos los datos del servidor con la clave de servidor actual y para sincronizar la clave de puerta de enlace actual con todas las puertas de enlace a fin de asegurarse de que no se siguen utilizando claves obsoletas antes de borrarlas.

Administración de cifrado del servidor

La funcionalidad de cifrado de servidor de Identity Manager permite crear nuevas claves de cifrado de servidor 3DES y cifrarlas con 3DES, PKCS#5 o AES (estándar de cifrado avanzado). Sólo los usuarios con capacidades de administrador de seguridad pueden ejecutar la tarea Administrar el cifrado del servidor, que se configura en la página Administrar el cifrado del servidor.

ProcedurePara acceder a la página Administrar el cifrado del servidor

Para abrir la página Administrar el cifrado del servidor

  1. Seleccione Tareas del servidor > Ejecutar tareas en la barra de menús.

  2. Cuando aparezca la página Tareas disponibles, haga clic en Administrar el cifrado del servidor para abrir la página del mismo nombre.

    Figura 12–1 Página Administrar el cifrado del servidor

    Figura con la página Administrar el cifrado del servidor

ProcedurePara configurar el cifrado del servidor

Use esta página para configurar el cifrado del servidor y de los objetos, claves de puerta de enlace, opciones de copia de seguridad y el modo de ejecución.

  1. Introduzca un Nombre de tarea.

    El valor predeterminado de este campo es Administrar el cifrado del servidor. Si no quiere utilizar el valor predeterminado, puede introducir otro nombre de tarea.

  2. Elija una o varias de las siguientes opciones.

    selección,

    • Administrar el cifrado del servidor. Seleccione esta opción para configurar el cifrado del servidor.

      Aparecen estas otras opciones:

      • Cifrado de las claves de cifrado del servidor. Debe especificar un método para cifrar las claves de cifrado de servidor. Los tipos de cifrado pueden ser Triple DES, PKCS#5 (DES) o PKCS#5 (AES).

        Nota –

        • En esta página sólo aparecen los tipos de cifrado que pueden instanciarse en el sistema. Por ejemplo, si su sistema no admite PKCS#5 (AES), sólo aparecen Triple DES y PKCS#5 (DES).

        • PKCS#5 (AES) requiere descargar y configurar "Unlimited Strength Jurisdiction Policy Files" para la máquina JVM que ejecuta Identity Manager. Encontrará más información en la documentación del proveedor de Java.

          Asimismo, PKCS#5 (AES) requiere instalar y configurar el archivo jar Bouncy Castle JCE provider como proveedor de JCE provider para la máquina JVM que ejecuta Identity Manager. Este archivo jar se empaqueta en la imagen de instalación de Identity Manager y puede encontrarse en el directorio wshome/WEB-INF/lib. Se incluyen dos archivos jar para usarlos con las correspondientes versiones de Java: bcprov-jdk15-137.jar y bcprov-jdk16-137.jar. Encontrará más información en la documentación del proveedor de Java y en la de Bouncy Castle.

      • Generar nueva clave de cifrado de servidor y definir como clave actual. Seleccione esta opción para generar una nueva clave de cifrado de servidor. Cada unidad de datos cifrados generados después de esta selección se cifrará con esa clave. La creación de una nueva clave de cifrado de servidor no afecta a la clave aplicada a los datos cifrados existentes.

      • Genera una nueva contraseña PBE aleatoria segura. Esta opción genera una contraseña nueva basada en un secreto específico del servidor cada vez que se inicia éste. Si no elige esta opción, o si el servidor no está configurado para utilizar cifrado basado en contraseña, Identity Manager utilizará la clave predeterminada para cifrar las claves de servidor.

    • Administrar cifrado de objetos. Esta opción sirve para especificar los tipos de objetos que deben volverse a cifrar y el método cifrado que se utiliza.

      • Cifrado de tipos de objeto Elija uno de los tipos de cifrado mostrados, que pueden ser: Triple DES (predeterminado), clave AES de 256 bits, clave AES de 192 bits o clave AES de 128 bits.

        Nota –

        Para usar claves AES de 192 o 256 bits es preciso descargar y configurar "Unlimited Strength Jurisdiction Policy Files" para la máquina JVM que ejecuta Identity Manager. Encontrará más información en la documentación del proveedor de Java.

        En esta página sólo aparecen los tipos de cifrado que pueden instanciarse en el sistema. Por ejemplo, si el sistema no admite claves AES de 192 o 256 bits con “Unlimited Strength Jurisdiction Policy Files”, sólo se verán las opciones de claves Triple DES y AES de 128 bits.

      • Seleccione los tipos de objeto que quiere volver a cifrar con la nueva clave de cifrado del servidor. Elija uno o más de los tipo de objeto de Identity Manager incluidos en la tabla.

    • Administrar las claves de puerta de enlace. Seleccione esta opción para configurar el cifrado de la puerta de enlace.

      Aparecen estas opciones:

      • Opción de selección de claves de puerta de enlace. Elija una de estas opciones:

        • Generar una nueva clave y sincronizar todas las puertas de enlace. Seleccione esta opción cuando habilite por primera vez un entorno de puerta de enlace seguro. Esta opción genera una nueva clave de puerta de enlace y la comunica a todas las puertas de enlace.

        • Sincronizar todas las puertas de enlace con la clave de puerta de enlace actual. Seleccione esta opción para sincronizar cualquier puerta de enlace nueva o aquellas puertas de enlace que no han comunicado la nueva clave de puerta de enlace. Seleccione esta opción si tenía una puerta de enlace que estaba inactiva cuando todas las puertas de enlace se sincronizaron con la clave de puerta de enlace actual. También puede seleccionarla cuando desee forzar una actualización de clave para una nueva puerta de enlace.

      • Tipo de clave de puerta de enlace. Elija uno de los tipos de clave mostrados, que pueden ser: Triple DES, clave AES de 256 bits, clave AES de 192 bits o clave AES de 128 bits.

        Nota –

        Para usar claves AES de 192 o 256 bits es preciso descargar y configurar "Unlimited Strength Jurisdiction Policy Files" para la máquina JVM que ejecuta Identity Manager. Encontrará más información en la documentación del proveedor de Java.

        En esta página sólo aparecen los tipos de cifrado que pueden instanciarse en el sistema. Por ejemplo, si el sistema no admite claves AES de 192 o 256 bits con “Unlimited Strength Jurisdiction Policy Files”, sólo se verán las opciones de claves Triple DES y AES de 128 bits.

    • Exportar las claves de cifrado del servidor para copias de seguridad. Seleccione esta opción para exportar las claves de cifrado de servidor existentes a un archivo con el formato XML. Al seleccionar esta opción, Identity Manager muestra un campo adicional para que especifique la ruta y el nombre de archivo al que exportar las claves.

      Nota –

      Seleccione también esta opción si utiliza el cifrado PKCS#5 y decide generar y definir una nueva clave de cifrado de servidor. Además, debería almacenar las claves exportadas en soportes extraíbles y en una ubicación segura (no en una red).

  3. Elija el modo de ejecución.

    Esta tarea se puede ejecutar en primer o segundo plano (valor predeterminado).

    Nota –

    Si decide volver a cifrar uno o varios tipos de objetos con una clave nueva, esta tarea puede llevar algo de tiempo y sería recomendable que se ejecutase en segundo plano.

  4. Cuando termine de configurar las opciones de esta página, pulse Iniciar.

Uso de tipos de autorización para proteger los objetos

Los permisos especificados en una capacidad AdminGroup suelen emplearse para conceder acceso a un tipo de objeto (objectType) de Identity Manager, como Configuración, Regla o TaskDefinition. Sin embargo, conceder acceso a todos los objetos de un tipo (objectType) de Identity Manager dentro de una o más organizaciones controladas a veces resulta demasiado genérico.

Los tipos de autorización (AuthType) permiten delimitar o restringir más este acceso a un subconjunto de objetos para un determinado tipo de de objeto ( objectType) de Identity Manager. Por ejemplo, quizá no le interese que sus usuarios tengan acceso a todas las reglas de su ámbito de control cuando se rellenan reglas para seleccionar en un formulario de usuario.

Para definir un nuevo tipo de autorización, edite el objeto de configuración AuthorizationTypes en el depósito de Identity Manager y agregue un nuevo elemento <AuthType>.

Este elemento requiere dos propiedades:

Por ejemplo, si desea agregar un nuevo tipo de autorización de regla denominado Marketing Rule para ampliar Rule, deberá definir lo siguiente:

<AuthType name=’Marketing Rule’ extends=’Rule’/>

A continuación, para habilitar el tipo de autorización que se debe usar, hay que referenciarlo en dos sitios:

Los siguientes ejemplos corresponden a ambas referencias. El primero muestra una definición de capacidad AdminGroup que concede acceso a Marketing Rules.

Ejemplo 12–4 Definición de capacidad AdminGroup 


<AdminGroup name=’Marketing Admin’>
  <Permissions>
    <Permission type=’Marketing Rule’ rights=’View,List,Connect,Disconnect/>
  </Permissions>
  <AdminGroups>
    <ObjectRef type=’AdminGroup’ id=’#ID#Account Administrator’/>
  </AdminGroups>
</AdminGroup>

El siguiente ejemplo muestra una definición de regla (Rule) que permite a los usuarios acceder al objeto, porque disponen de acceso a Rule o Marketing Rule.

Ejemplo 12–5 Definición de Rule 


<Rule name=’Competitive Analysis Info’ authType=’Marketing Rule’>
 ...
</Rule>
Nota –

Todos los derechos de usuario concedidos para un tipo de autorización principal, o para un tipo estático ampliado por un tipo de autorización, son los mismos derechos para todos los tipos de autorización secundarios. Por tanto, en el ejemplo anterior, todos los derechos de usuario concedidos para Rule serán los mismos para Marketing Rule. En cambio, lo contrario no es cierto.

Prácticas de seguridad

Como administrador de Identity Manager, reducirá aún más los riesgos de seguridad para las cuentas y los datos protegidos si sigue las recomendaciones indicadas a continuación, tanto al configurar como después.

Al configurar

Para reducir los riesgos de seguridad durante la configuración:

Durante el uso

Para reducir los riesgos de seguridad durante el uso:

Si su servidor de aplicaciones es conforme con Servlet 2.2, el proceso de instalación de Identity Manager configurará el tiempo de espera de sesión de HTTP en un valor predeterminado de 30 minutos. Este valor se puede cambiar editando la propiedad, pero conviene que sea un valor bajo para elevar la seguridad. No defina un valor superior a 30 minutos.

ProcedurePara cambiar el valor de tiempo de espera de sesión

  1. Edite el archivo web.xml, que se encuentra en el directorio idm/WEB-INF del árbol de directorios del servidor de aplicaciones.

  2. Cambie el valor numérico en las líneas siguientes:


    <session-config>  <session-timeout>30</session-timeout></session-config>