Seguridad de colectivo

Puede utilizar los principios de seguridad colectiva en el perfil 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

    Soluciona los datos en movimiento, la autenticación y la autorización

  • Seguridad de datos de repositorio colectivo

    Soluciona los datos en REST, la autenticación y la autorización

Configuración de seguridad de dominio administrativo
La configuración de seguridad de dominio administrativo para el colectivo se compone de dos partes:
  • Dominio de usuario

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

  • 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 otorgue al usuario el rol de administrador. Consulte Configuración de una conexión JMX segura con el perfil Liberty para obtener información detallada completa.

Las comunicaciones entre servidores están dentro del dominio de servidor y, como tales, no se utiliza ninguna identidad de usuario ni contraseña para comunicarse entre los miembros de un colectivo. Cada miembro del colectivo tiene una identidad exclusiva en el colectivo que se compone de 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 de dominio del servidor se puede personalizar añadiendo más entradas de certificado de confianza al almacén de claves collectiveTrust.jks . Se copian todos los valores de confianza cuando se duplica un controlador; por lo tanto, se debe aplicar la personalización SSL 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. El uso de certificados SSL individuales que no tienen un firmante raíz común para establecer confianza 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. El uso de certificados SSL individuales que no tienen un firmante raíz común para establecer confianza 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". Se recomienda que no utilice clientAuthenticationRequired="true"; dado que impedirá la autenticación con nombres de usuario y contraseñas. Por ejemplo:
<!-- clientAuthenticationSupported establecido para habilitar la confianza bidireccional -->
    <ssl id="defaultSSLConfig"
         		 keyStoreRef="defaultKeyStore"
         		 trustStoreRef="defaultTrustStore"
         clientAuthenticationSupported="true" />

Se puede impedir que los miembros publiquen información al controlador colectivo mediante el uso del MBean CollectiveRegistration. Los métodos disavow y avow impedirán o habilitarán la autenticación, respectivamente.

Seguridad de datos de repositorio colectivo

La política de seguridad de datos de repositorio colectivo cubre la política de datos específicamente en REST, la política de acceso al contenido del repositorio 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 el usuario 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 almacenados en estos nodos dará como resultado 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 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 la configuración del controlador de colectivo, que solo el grupo pueda leerla y que no sea accesible para para todo el mundo, dicho de otro modo, chmod 0640. Siga las directrices de seguridad que haya establecido su organización.


Icono que indica el tipo de tema Tema de concepto

Términos y condiciones para centros de información | Comentarios


Icono de indicación de fecha y hora Última actualización: 15 de junio de 2015
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-libcore-mp&topic=cwlp_collective_sec
Nombre de archivo:cwlp_collective_sec.html