Seguridad de colectivos

Puede utilizar los principios de seguridad de colectivo en Liberty para la direccionar datos en movimiento y datos en REST.

Las dos áreas principales de la seguridad de colectivo son:
  • Configuración de seguridad de dominio administrativo

    Datos de direcciones en movimiento, autenticación y autorización

  • Seguridad de datos de repositorio de colectivo

    Datos de direcciones fijas, autenticación y autorización

Configuración de seguridad de dominio administrativo
La configuración de seguridad del dominio administrativo para colectivos consta de dos partes:
  • Dominio de usuario

    Este dominio se basa en seguridad basada en roles Java™ que define el rol de administrador. Este tipo de seguridad se puede correlacionar con usuarios dentro del registro de usuarios configurados.

  • Dominio de servidor

    Este dominio se basa en la autenticación basada en certificados SSL.

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:
  • Todos los controladores y miembros de colectivo deben establecer la confianza HTTPS en el colectivo. Si se modifican los certificados SSL HTTPS, se deben añadir los firmantes raíz siguientes del controlador de colectivo al almacén de confianza SSL HTTPS:
    • Se debe añadir el firmante controllerRoot del almacén de confianza rootKeys.jks al almacén de confianza SSL HTTPS de todos los miembros de colectivo.
    • Se deben añadir los firmantes controllerRoot y memberRoot del almacén de claves rootKeys.jks al almacén de confianza SSL HTTPS de todos los controladores colectivos.
  • Cada miembro puede realizar una conexión saliente a un controlador de colectivo. El almacén de claves collectiveTrust.jks del controlador de colectivo debe contener una cadena de certificado que confíe en el certificado SSL HTTPS para cada miembro. Resulta muy recomendable que un firmante raíz firme todos los certificados HTTPS, que después se pueden añadir al almacén de claves collectiveTrust.jks. Utilizar certificados SSL individuales que no tienen un firmante raíz común es suficiente para establecer una confianza, pero no se escalará.
  • Cada controlador puede realizar una conexión saliente a un miembro de colectivo. El almacén de claves collectiveTrust.jks del miembro de colectivo debe contener una cadena de certificado que confíe en el certificado SSL HTTPS para cada controlador. Resulta muy recomendable que un firmante raíz firme todos los certificados HTTPS, que después se pueden añadir al almacén de claves collectiveTrust.jks. Utilizar certificados SSL individuales que no tienen un firmante raíz común es suficiente para establecer una confianza, pero no se escalará.
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.

Seguridad de datos de repositorio de colectivo

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:
  • El sistema reserva tres nombres de nodo: sys.host.auth.info, sys.jmx.auth.info y sys.nologin. Estos nodos están bajo un host o un espacio de nombres de repositorio del servidor. Los nodos creados por usuarios deben evitar utilizar el prefijo sys..
  • Los nodos sys.host.auth.info y sys.jmx.auth.info no son accesibles mediante el bean gestionado para impedir la revelación de las credenciales del sistema. El acceso a los datos que están almacenados en estos nodos genera una respuesta nula.
  • Un miembro de colectivo está restringido a modificar solo su propia información del repositorio. Los usuarios administrativos autenticados tienen acceso no restringido a la información del repositorio excepto si se ha indicado anteriormente. A los usuarios administrativos autenticados se les otorga a todos el rol administrativo.

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.


Icono que indica el tipo de tema Tema de concepto

Nombre de archivo: cwlp_collective_sec.html