Ajuste de configuraciones de seguridad
Puede ajustar la seguridad para equilibrar el rendimiento con la función. Puede obtener este equilibrio siguiendo las consideraciones de ajuste de la seguridad general, CSIv2 (Common Secure Interoperability version 2), la autenticación LDAP (Lightweight Directory Access Protocol), la autenticación web y la autorización.
Acerca de esta tarea
Procedimiento
- Tenga en cuenta las recomendaciones siguientes para ajustar la seguridad general.
- Considere la posibilidad de inhabilitar el gestor de seguridad de Java 2 si sabe exactamente qué código se ha puesto en el servidor y no necesita proteger los recursos de procesos. Recuerde que si lo hace, pondrá en peligro los recursos locales.
- Considere la propagación de nuevos valores de seguridad a todos los nodos antes de
reiniciar el gestor de despliegue y los agentes de nodo para cambiar la nueva política de
seguridad.
Si las configuraciones de seguridad no son coherentes en todos los servidores, puede obtener errores de acceso denegado. Por lo tanto, debe propagar nuevos valores de seguridad, al habilitar o inhabilitar la seguridad administrativa.
Los cambios de configuración se propagan normalmente utilizando la sincronización de configuraciones. Si está habilitada la sincronización automática, puede esperar a que pase el intervalo de sincronización automática, o bien puede forzar la sincronización antes de que caduque el intervalo de sincronización. Si está utilizando la sincronización manual, debe sincronizar todos los nodos.
Si la célula está en un estado de configuración y la política de seguridad está mezclada con nodos que tienen la seguridad habilitada e inhabilitada, puede utilizar el programa de utilidad syncNode para sincronizar los nodos donde no se han propagado los nuevos valores.
Si desea más información detallada sobre cómo habilitar la seguridad en un entorno distribuido, consulte Habilitación de la seguridad del dominio.
- Considere aumentar la memoria caché y el tiempo de espera excedido de la señal, si cree que el entorno es lo suficientemente seguro. Si aumenta estos valores, deberá reautenticarse con menos frecuencia. Esta acción permite que las
solicitudes subsiguientes utilicen las credenciales ya creadas. El
inconveniente de aumentar el tiempo de espera de señales es el peligro de
que se pirateen las señales ya que se proporciona más tiempo para que se
piratee el sistema antes de que caduque la señal. Puede utilizar las
propiedades del sistema siguientes para determinar el tamaño inicial de
las memorias caché de la tabla de totales de control primaria y secundaria,
que afectan la frecuencia con que se vuelve a aplicar el algoritmo hash
y la distribución de dichos algoritmos.
Consulte el artículo Valores de memoria caché de autenticación para obtener una lista de estas propiedades.
- Considere cambiar de conector administrativo SOAP (Simple Object Access Protocol) por RMI (Remote Method Invocation) puesto que RMI utiliza conexiones con estado mientras que SOAP es por completo sin estado. Ejecute las pruebas comparativas para evaluar el rendimiento del sistema y determinar si ha mejorado en el entorno.
- Utilice el script wsadmin para completar los ID de acceso para todos los usuarios y grupos para acelerar el arranque de la aplicación. Complete esta acción si las aplicaciones contienen muchos usuarios y grupos, o si las aplicaciones se detienen e inician frecuentemente. WebSphere Application Server correlaciona los nombres de usuario y grupo con los ID de acceso exclusivos en la tabla de autorizaciones. El formato exacto del ID de acceso depende del repositorio. El ID de acceso sólo se puede determinar durante y después de un despliegue de aplicación. Las tablas de autorización creadas durante el momento de ensamblaje no tienen el ID de acceso correcto. Consulte el artículo Mandatos de AdminApp para obtener más información sobre cómo actualizar los ID de acceso.
Considere ajustar el ORB (Object Request Broker) porque es un factor en el rendimiento de los enterprise bean con o sin la seguridad habilitada. Consulte la información sobre las directrices para el ajuste de ORB.
- Si utiliza SSL, habilite la opción de mecanismo de seguimiento de sesiones SSL, tal como se describe en el tema sobre los valores de la gestión de sesiones.
En algunos casos, utilice el archivo de políticas JCE (Java Cryptography Extension) sin limitaciones para mejorar el rendimiento. Consulte la información sobre el ajuste de la seguridad de servicios Web.
- La distribución de la carga de trabajo en varias JVM (Java Virtual Machines) en lugar de una sola JVM en una sola máquina puede aumentar el rendimiento de la seguridad, ya que hay menos competencia para las decisiones de autorización.
- Tenga en cuenta los pasos siguientes para ajustar CSIv2 (Common Secure
Interoperability versión 2).
- Considere la posibilidad de utilizar certificados de cliente SSL (Secure Sockets Layer) en lugar de un ID de usuario y una contraseña para autenticar los clientes Java. Puesto que ya está efectuando la conexión SSL, si utiliza la autenticación mutua se añadirá un poco la información mientras se elimina totalmente el contexto de servicio que contiene el ID de usuario y la contraseña.
- Si envía una gran cantidad de datos que no sean críticos, reduzca la potencia del cifrado. Cuantos más datos tenga que cifrar en lote y cuánto más fuerte sea el cifrado, más tarda en llevarse a cabo la acción. Si los datos no son críticos, no malgaste tiempo de proceso con cifrados de 128 bits.
- Considere poner sólo un asterisco (*) en la lista de ID de servidor de confianza (lo que significa que todos los servidores son de confianza), cuando utilice la aserción de identidad para la delegación en sentido descendente. Utilice la autenticación mutua SSL entre servidores para proporcionar esta confianza. Si se añade este paso adicional en el reconocimiento de comunicación SSL se obtiene un mejor rendimiento que si se autentica el servidor en sentido ascendente y se comprueba la lista de confianza. Si se utiliza un asterisco (*), se confía en la señal de identidad. La conexión SSL confía en el servidor a través de la autenticación de certificado de cliente.
- Asegúrese de que las sesiones con estado están habilitadas para CSIv2. Este es el valor por omisión, pero requiere la autenticación sólo en la primera solicitud y en cualquier caducidad de señal posterior.
- Considere el cambio de los valores de la memoria caché de la sesión CSIv2. Si cambia estos valores podrá evitar que se produzca una situación de escasez de recursos. Consulte el tema sobre comunicaciones de salida de Common Secure Interoperability Versión 2 para más información.
- Si sólo se está comunicando con servidores
WebSphere Application Server
Versión 5 o posteriores, utilice CSI como protocolo de autenticación activo, en lugar de CSI y SAS. Esta acción elimina una invocación de interceptor para cada solicitud tanto
en el cliente como en el servidor. Importante: z/SAS sólo está soportado entre servidores de la versión 6.0.x y anteriores que se hayan federado en una célula de la Versión 6.1.
- Considere los pasos siguientes para ajustar la autenticación LDAP (Lightweight
Directory Access Protocol).
- En la consola de administración, pulse Seguridad > Seguridad global.
- En Repositorio de cuentas de usuario,pulse la lista desplegable Definiciones de reino disponibles, seleccione Registro LDAP autónomo y pulse Configurar.
- Seleccione la opción Ignorar mayúsculas para autorización en la configuración del registro LDAP autónomo, si no es importante distinguir entre mayúsculas y minúsculas.
- Seleccione la opción Reutilizar conexión.
- Utilice los dispositivos de memoria caché que soporta el servidor LDAP.
- Seleccione el tipo de directorio IBM Tivoli Directory Server o SecureWay, si utiliza un servidor IBM Tivoli Directory Server. El servidor IBM Tivoli Directory Server presenta un mejor rendimiento porque está programado para utilizar los nuevos atributos de miembros de grupo para mejorar las búsquedas de miembros de grupo. Sin embargo, la autorización no debe ser sensible a las mayúsculas y minúsculas para utilizar el servidor IBM Tivoli Directory Server.
- Seleccione iPlanet Directory Server (también conocido como Sun ONE) o Netscape como directorio, si es usuario de iPlanet Directory. Si utiliza el directorio iPlanet Directory Server puede aumentar el rendimiento en las búsquedas de miembros de grupo. Sin embargo, utilice Rol sólo para los mecanismos de grupo.
- Considere los pasos siguientes para ajustar la autenticación web.
- Aumente los valores de memoria caché y de tiempo de espera excedido de señal, si cree que el entorno es lo suficientemente seguro. La información de autenticación web se almacena en estas antememorias y, siempre y cuando la información de autenticación esté en la antememoria, no se invocará el módulo de inicio de sesión para autenticar al usuario. Esta acción soporta solicitudes posteriores para reutilizar las credenciales que ya se han creado. Un inconveniente de aumentar el tiempo de espera excedido de señal es el peligro de que se pirateen las señales ya que se proporciona más tiempo para que se piratee el sistema antes de que caduque la señal.
- Habilite el inicio de sesión único (SSO). Para configurar SSO, pulse Seguridad >
Seguridad global. En Seguridad Web, pulse Inicio de sesión único (SSO).
EL SSO sólo está disponible cuando configura LTPA como mecanismo de autenticación en el panel Mecanismos de autenticación y caducidad. No obstante, puede seleccionar SWAM (Simple WebSphere Authentication Mechanism) como mecanismo de autenticación en el panel Mecanismos de autenticación y caducidad. Al seleccionar SSO, una sola autenticación a un servidor de aplicaciones es suficiente para realizar solicitudes para varios servidores de aplicación en el mismo dominio SSO. Existen algunas situaciones en las que SSO no es una opción deseable y, por lo tanto, no desee utilizarlo en estas situaciones.
- Inhabilite o habilite la opción Propagación de atributos de seguridad de entrada Web en el panel Inicio de sesión único (SSO), si la función no es necesaria. En algunos casos, tener la función habilitada puede mejorar el rendimiento. Este aumento se produce generalmente en casos de grandes volúmenes en los que un número elevado de llamadas de registro de usuarios reduce el rendimiento. En otros casos, tener el dispositivo inhabilitado puede mejorar el rendimiento. Este aumento se produce generalmente cuando las llamadas de registro de usuarios no necesitan demasiados recursos.
- Las dos propiedades personalizadas siguientes pueden ayudar a
mejorar el rendimiento cuando la propagación de atributos de seguridad
está habilitada:
- com.ibm.CSI.propagateFirstCallerOnly
El valor predeterminado de esta propiedad es true. Si esta propiedad personalizada se establece en true, el primer emisor de la señal de propagación que permanece en la hebra se registra cuando la propagación de atributos de seguridad está habilitada. Cuando se establece esta propiedad como false, se registran todos los conmutadores del llamador, lo que podría afectar al rendimiento.
- com.ibm.CSI.disablePropagationCallerList
Si esta propiedad personalizada se establece en true, la posibilidad de añadir una lista de emisores o hosts a la señal de propagación está completamente inhabilitada. Esta función es beneficiosa cuando la lista de emisores o hosts de la señal de propagación no es necesaria en el entorno.
- com.ibm.CSI.propagateFirstCallerOnly
- Considere los pasos siguientes para ajustar la autorización.
- Correlacione los usuarios con los grupos en el registro de usuario. Asocie los grupos con los roles de Java EE (Java Platform, Enterprise Edition). Esta asociación mejora de forma significativa el rendimiento, cuando aumenta el número de usuarios.
- Asigne juiciosamente los permisos de métodos para enterprise beans. Por ejemplo, puede utilizar un asterisco (*) para indicar todos los miembros del elemento method-name. Cuando todos los métodos de enterprise beans requieren el mismo permiso, puede utilizarse un asterisco (*) para method-name para indicar todos los métodos. Esta indicación disminuye el tamaño del descriptores de despliegue y por consiguiente disminuye la memoria necesaria para cargar el descriptor de despliegue. También reduce el tiempo de búsqueda durante la comparación de métodos-permisos para el método de enterprise beans.
- Asigne juiciosamente las restricciones de seguridad para servlets. Por ejemplo, puede utilizar el patrón URL *.jsp para aplicar las mismas limitaciones de datos de autenticación para indicar todos los archivos JSP (JavaServer Pages). Para un URL concreto, la coincidencia exacta en el descriptor de despliegue tiene prioridad sobre la coincidencia de vía de acceso más larga. Utilice la comparación de extensiones *.jsp, *.do, *.html, si no hay ninguna coincidencia exacta, ni ninguna coincidencia de la vía de acceso más larga para un URL determinado en las restricciones de seguridad.
- Utilice nuevos parámetros de ajuste cuando
utilice la seguridad de
Java
2. Los nuevos parámetros de ajuste
pueden aumentar el rendimiento significativamente e introducir un nuevo concepto
denominado Sujeto de sólo lectura que habilita una nueva memoria caché para los
sujetos de autenticación J2C cuando se utilizan alias de datos de autenticación
gestionados por contenedor. Si el sujeto de autenticación J2C no debe
modificarse una vez creado, pueden utilizarse los nuevos parámetros de
ajuste siguientes para mejorar el rendimiento de la seguridad de
Java
2:
- com.ibm.websphere.security.auth.j2c.cacheReadOnlyAuthDataSubjects=true
- com.ibm.websphere.security.auth.j2c.readOnlyAuthDataSubjectCacheSize=50 (Este es el número máximo de sujetos en la tabla hash de la memoria caché. Cuando la memoria caché alcanza este tamaño, algunas de las entradas se depuran. Para mejorar el rendimiento, este tamaño debe ser igual al número de sujetos exclusivos (memoria caché basada en la exclusividad del principal de usuario + alias de datos de autenticación + instancia de fábrica de conexiones gestionada) cuando se utilizan conjuntamente la seguridad basada en roles y la seguridad de Java 2).
- Utilice nuevos parámetros de ajuste para
mejorar el rendimiento de la Propagación de atributos de seguridad. Los
nuevos parámetros de ajuste pueden establecerse mediante propiedades personalizadas
en la consola administrativa para reducir la sobrecarga adicional de la Propagación
de atributos de seguridad:
- com.ibm.CSI.disablePropagationCallerList=true
- com.ibm.CSI.propagateFirstCallerOnly=true (utilícelo si sólo desea realizar un seguimiento del primer llamante).
- Vuelva a evaluar los valores de la memoria caché de seguridad (WSSecureMap) que puedan afectar al rendimiento de la Propagación de atributos de seguridad. Los valores de la memoria caché de seguridad WSSecureMap pueden ajustarse en las propiedades personalizadas en la consola administrativa.
- com.ibm.ws.security.WSSecureMapInitAtStartup=true
- com.ibm.ws.security.WSSecureMapSize (entero igual o mayor que 100)
Resultados
Qué hacer a continuación
Subtopics
Sugerencias sobre el rendimiento de la capa de sockets seguros
Utilice esta página para obtener información acerca de las recomendaciones de rendimiento SSL (Capa de sockets seguros) Tenga siempre en cuenta que las cuestiones de rendimiento suelen implicar encontrar el equilibrio entre función y velocidad. Por lo general, cuantas más funciones y procesos haya menor será el rendimiento.Sugerencias para el ajuste de la seguridad
Generalmente, ocurren dos cosas al aumentar la seguridad: el coste por transacción aumenta y el rendimiento disminuye. Tenga en cuenta la información de seguridad siguiente cuando configure WebSphere Application Server.Ajuste del rendimiento de seguridad
Utilice los siguientes procedimientos para ajustar el rendimiento, sin comprometer los valores de seguridad.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_tune
File name: tsec_tune.html