Conjunto de reglas de implementación de Oracle JRE: control de JRE

Con este ejemplo nos gustaría mostrarte una aplicación concreta de ScriptRunner en una empresa:

El reto

En entornos de aplicaciones complejos existe el desafío de que diferentes aplicaciones Java deben ejecutarse en paralelo y que esto requiere una determinada versión de Java en cada caso. Por este motivo, se deben instalar varios Java Runtime Environment (JRE) uno al lado del otro en todos los dispositivos afectados para garantizar la compatibilidad de las aplicaciones. Además, estos JRE también deben estar controlados administrativamente para que sólo puedan utilizarse para la aplicación particular para la que están autorizados.

Para ello existe una solución comercial de Oracle “Oracle WebLogic Server”. La lógica utilizada por WebLogic Server ya está disponible en cada instalación de JRE, pero no se utiliza. Con él sólo sería necesario configurar la lógica de control y se podría utilizar la función también sin costes adicionales.

Para solucionar este problema se propusieron cuatro soluciones diferentes. Se consideró explícitamente la distribución y mantenimiento de archivos de configuración.

A continuación se evaluaron los diferentes enfoques para las soluciones y se optó por la variante individual. Para cumplir con los requisitos, se identificaron las siguientes áreas problemáticas.

1. todos los paquetes JRE deben ser reempaquetados
2. Debería realizarse una creación automática de las directrices.
3. Es necesario desarrollar una lógica de sincronización de políticas.
4. se realizará el registro automático de la Directiva JRE

1. AppSense Environment Manager es la solución de perfil que funciona con Active Directory.
2. AppSense Environment Manager almacena una configuración con un enlace lógico para que solo se aplique una configuración JRE especial si dos JRE de ciertas versiones se instalan juntos en un cliente.
3. Esta configuración se aplica a un cliente.
4. Luego, la configuración de AppSense copia el certificado y el conjunto de reglas de implementación del recurso compartido APSource. El certificado también se copia en el almacén global de certificados Java.
5. El certificado declara que la regla de implementación establecida es confiable y la aplica a las aplicaciones Java individuales.

Conjuntos de reglas de implementación de Oracle Java

El "Conjunto de reglas de implementación" tiene como objetivo proporcionar a los administradores de empresas que se ven obligadas a utilizar versiones anteriores de Java una herramienta para proteger a los clientes de amenazas mediante reglas. Sin embargo, esto sólo funciona en entornos donde los clientes están controlados de forma centralizada. Otra limitación tiene que ver con la antigüedad de la instalación: todas las PC cliente deben tener una versión del complemento de Java que esté actualizada actualmente desde Java SE 6, Actualización 10 o posterior.

Si se cumplen estos requisitos, el administrador puede utilizar un conjunto de reglas para determinar qué subprogramas de Java o aplicaciones web de Java, que Oracle resume como aplicaciones de Internet enriquecidas (RIA), pueden ejecutarse en las PC cliente. Por ejemplo, la persona a cargo básicamente puede prohibir todos los RIA y luego definir excepciones específicas en una lista blanca. Las reglas se pueden dividir en partes de la URL de la aplicación, como el número de puerto. También pueden contener instrucciones que restrinjan la regla a determinadas versiones de Java.

Además, una actualización de la versión 7u40 del Java Development Kit (JDK) proporciona mayores alertas de seguridad para aplicaciones no firmadas o autofirmadas, así como herramientas avanzadas de monitoreo y diagnóstico para desarrolladores. A partir de ahora, se aplican restricciones a los certificados con una longitud de clave inferior a 1.024 bits. Los usuarios de dichas claves recibirán una advertencia pidiéndoles que seleccionen claves más largas. Además, el usuario también puede desactivar la verificación de la longitud de la clave.

Por último, pero no menos importante, la versión JDK 7u40 y superiores permite a un administrador de clientes controlados centralmente desactivar las advertencias sobre una versión desactualizada para que los usuarios de los clientes no intenten actualizarse ellos mismos.

Firmar el archivo del conjunto de reglas de implementación

Para firmar el archivo RuleSet, se requiere un certificado CodeSigning válido.

Tiene una validez de dos años y debe renovarse. Debe cargarse en el almacén de certificados de JVM para que la JVM clasifique y aplique DeploymentRuleSet como confiable. Además, el sitio web debe figurar en los Sitios de excepción debido a las mayores reglas de seguridad de la JVM.

Un certificado CodeSigning se puede obtener de la forma habitual en un organismo de certificación oficial.

Crear un conjunto de reglas de implementación

ArchivoMuestra el proceso para crear e instalar un archivo Deployment RuleSet.

Se requieren los siguientes archivos para completar estos pasos. Estos archivos forman parte del JDK y se pueden utilizar en diferentes versiones.

|- bin
|- msvcr100.dll
|- keytool.exe
|- jli.dll
|- jarsigner.exe
|- jar.exe
|- lib< br>|- herramientas.jar

Se desarrollaron scripts CMD para este proceso para simplificarlo.

• CreateCertificate.cmd: se utiliza para crear un certificado autofirmado
• CreateDeploymentRuleSetJAR.cmd: se utiliza para convertir un XML-RuleSet en un JAR-RuleSet firmado.
• DeployRuleSet.cmd: se utiliza para copiar un JAR-RuleSet firmado en el directorio JRE e importar el SeldSignedCertificate creado en JRE-CertificateStore.

El uso de ScriptRunner

Para automatizar este proceso se utilizó ScriptRunner. El software tiene aquí varias funciones:

• Crear un archivo excepción.sites
• Creando un archivo conjunto de reglas.xml
• Convierta un conjunto de reglas.xml en un DeploymentRuleset.jar

Conclusión

Con la automatización en ScriptRunner, la creación de estos archivos se ha simplificado enormemente, ya que a menudo son engorrosos o la sintaxis de las herramientas individuales no es realmente transparente. Además, el objetivo era poner en funcionamiento esta solución sin tener que contratar a un consultor con conocimientos avanzados de configuración de Java. Esto también asegura una alta reproducibilidad, de modo que DeploymentRuleset.jar siempre se crea con la misma metodología y no hay más errores en la configuración.