Seguridad de colectivos
Puede utilizar los principios de seguridad de colectivo en Liberty para la direccionar datos en movimiento y datos en REST.
- La configuración de seguridad del dominio administrativo para colectivos consta de dos partes:
Para que los usuarios accedan a los beans gestionados del controlador de colectivo, deben estar en el rol de administrador. Todas las acciones administrativas a través del colectivo requieren que se haya otorgado el rol Administrador al usuario. Consulte Configuración de una conexión JMX segura con Liberty para obtener información detallada completa.
La comunicación servidor a servidor está en el dominio de servidor y no se utilizan identidades de usuario o contraseñas para comunicarse entre los miembros de un colectivo. Cada miembro del colectivo tiene una identidad exclusiva dentro del colectivo que está formada por su nombre de host, directorio de usuario y nombre de servidor. Cada miembro dentro del colectivo define la configuración de dominio de servidor, que consta de los archivos serverIdentity.jks y collectiveTrust.jks. Estos archivos contienen los certificados SSL que son necesarios para establecer las comunicaciones seguras en el colectivo. La configuración de clave HTTPS debe tener valores de confianza específicos, que se establecen de forma predeterminada.
La configuración SSL del dominio del servidor se puede personalizar añadiendo entradas de certificado de confianza adicionales al almacén de claves collectiveTrust.jks. Se copian todos los valores de confianza cuando se duplica un controlador; por lo tanto, la personalización de SSL se debe aplicar al controlador inicial. Solo es necesario añadir los valores de confianza al almacén de claves collectiveTrust.jks si no se utilizan los certificados HTTPS predeterminados. Si se modifica la configuración SSL HTTPS, se aplican las reglas siguientes de certificado:La comunicación entre servidores requiere que se admita la autenticación SSL. Si se personaliza la configuración SSL HTTPS, la configuración SSL debe especificar clientAuthenticationSupported="true". Por ejemplo:<!-- clientAuthenticationSupported set to enable bidirectional trust --> <ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" clientAuthenticationSupported="true" />
Establecer clientAuthentication="true" en el controlador colectivo es desaconsejable e impide algunos comportamientos comunes y previstos. Por ejemplo, este valor impide la autenticación con nombres de usuario y contraseñas en Centro de administración y los programas de utilidad de la línea de mandatos del colectivo.
Establecer clientAuthentication="true" en un miembro de colectivo podría ser aconsejable para evitar inicios de sesión de nombre de usuario y contraseña. Este valor no interrumpe operaciones de colectivo ya que todas las operaciones que se originan en el controlador se autentican utilizando el certificado.
Se puede impedir a los miembros que publiquen información en el controlador colectivo utilizando el MBean CollectiveRegistration. Los métodos disavow y avow impiden la autenticación y habilitan la autenticación.
La política de seguridad de datos de repositorio de colectivo abarca la política de datos en REST, específicamente la política de acceso al contenido del repositorio de colectivo.
A continuación se detalla la política de seguridad actual para los datos de colectivo:Dado que el repositorio de colectivo finalmente reside en el disco, los valores de permiso del sistema de archivos deben ser seguros para el entorno. Se recomienda que solo el usuario pueda leer y escribir en la configuración del controlador colectivo y que el grupo solo la pueda leer, y que no esté al acceso de todo el mundo, en otras palabras, chmod 0640. Siga las directrices de seguridad que haya establecido su organización.