Buenas prácticas de seguridad

Esta sección describe las prácticas recomendadas para mejorar la seguridad de una instalación de OpenKM, especialmente en entornos de producción. Cubre la protección de valores de configuración sensibles, la seguridad de las comunicaciones de red y la auditoría de la actividad dentro de la aplicación.

Cifrado de contraseñas en openkm.properties

El fichero openkm.properties puede contener varias contraseñas en texto plano. En un entorno de producción, se recomienda encarecidamente almacenar estos valores de forma cifrada en lugar de en texto plano. Las propiedades más relevantes son:

Propiedad	Descripción
spring.datasource.password	Contraseña usada para conectar con la base de datos.
ldap.manager.password	Contraseña del usuario que OpenKM usa para conectarse al servidor LDAP/Active Directory cuando la integración LDAP está habilitada.
spring.mail.password	Contraseña de la cuenta de correo que usa OpenKM para enviar notificaciones por correo electrónico.

OpenKM proporciona una utilidad integrada para cifrar estos valores, disponible en Administration > Utilities > Password encryption. Debe usarse esta utilidad para generar el valor cifrado que debe establecerse en openkm.properties, en lugar de escribir la contraseña en texto plano. Para más detalles sobre cómo usar esta utilidad, consulte Password encryption.

Comunicaciones seguras (TLS/SSL)

Todas las comunicaciones con OpenKM deben cifrarse mediante HTTPS. Ejecutar la aplicación sobre HTTP sin cifrar en un entorno de producción expone las credenciales de inicio de sesión, las cookies de sesión y el contenido de los documentos a la interceptación en la red. Se recomienda encarecidamente colocar OpenKM detrás de un proxy inverso configurado con un certificado TLS/SSL válido, de forma que todo el tráfico entre los clientes y el servidor esté cifrado.

Para instrucciones paso a paso sobre cómo configurarlo, consulte Configuring Apache HTTPS Reverse-Proxy.

Atributos de cookie Secure, HttpOnly y SameSite

Más allá de cifrar el canal de transporte, la propia cookie de sesión puede reforzarse con atributos adicionales establecidos en la cabecera de respuesta HTTP Set-Cookie. Estos atributos son aplicados por el navegador y reducen el impacto de ataques comunes como el robo de cookies mediante XSS, la interceptación de cookies en conexiones sin cifrar y la falsificación de solicitudes entre sitios (CSRF).

Atributo	Finalidad y consideraciones
HttpOnly	Impide que el JavaScript del lado del cliente lea la cookie, lo que mitiga el secuestro de sesión mediante ataques Cross-Site Scripting (XSS). No afecta a la transmisión normal de la cookie y es seguro habilitarlo en cualquier entorno.
Secure	Restringe la cookie para que solo se envíe por conexiones HTTPS, evitando la interceptación en la red. Este atributo solo debe habilitarse cuando toda la aplicación se sirve por HTTPS; si alguna parte del entorno se accede por HTTP sin cifrar, el navegador dejará de enviar silenciosamente la cookie de sesión en esas solicitudes, rompiendo la autenticación.
SameSite	Controla si la cookie se envía en solicitudes entre sitios, lo que ayuda a mitigar ataques Cross-Site Request Forgery (CSRF). Establecerlo en Strict ofrece la protección más fuerte pero impide que la cookie se envíe cuando OpenKM está embebido en un iframe de otro origen, o se accede mediante un enlace o redirección entre sitios (por ejemplo, SSO o enlaces en correos electrónicos), lo que puede hacer que el usuario aparezca como no autenticado. Establecerlo en None restaura esas integraciones, pero requiere que el atributo Secure también esté habilitado.

Estos atributos no forman parte de la aplicación OpenKM y deben configurarse a nivel del servidor de aplicaciones, sin modificar el propio OpenKM.

HttpOnly y Secure se configuran en tomcat/conf/web.xml (o en el propio web.xml de la aplicación), dentro del elemento session-config:

<session-config>
    <session-timeout>30</session-timeout>
    <cookie-config>
        <http-only>true</http-only>
        <secure>true</secure>
    </cookie-config>
</session-config>

SameSite no forma parte de este elemento y debe configurarse por separado mediante el CookieProcessor, ya sea en tomcat/conf/context.xml (aplica a todas las aplicaciones web desplegadas en esa instancia de Tomcat) o en un fichero de contexto limitado a una sola aplicación (aplica solo a esa aplicación):

<Context>
    <CookieProcessor className="org.apache.tomcat.util.http.Rfc6265CookieProcessor"
                      sameSiteCookies="strict" />
</Context>

Dado que cada instalación de OpenKM suele ejecutarse en su propia instancia de Tomcat, estos ajustes pueden adaptarse por entorno. Por ejemplo, Secure debería dejarse deshabilitado en instalaciones que aún no se sirven por HTTPS, y las instalaciones que embeben OpenKM en un iframe de otro dominio deberían usar SameSite=None junto con Secure en lugar de Strict.

Auditoría y registro de eventos

OpenKM proporciona un rastro de auditoría completo de las acciones realizadas dentro de la aplicación. Prácticamente cualquier acción realizada sobre el repositorio de gestión documental puede auditarse, y el nivel de detalle registrado es configurable.

Por defecto, OpenKM ya audita las acciones más relevantes, que cubren las necesidades de auditoría más habituales. Las acciones auditadas por defecto son:

LOGIN
LOGIN_FAILED
LOGOUT
CREATE_.*
DELETE_.*
PURGE_.*
MOVE_.*
COPY_.*
SEND_MAIL_.*
DOWNLOAD_.*
ADMIN_CONFIG_.*
CHECKOUT_DOCUMENT
CHECKIN_DOCUMENT
GET_DOCUMENT_CONTENT.*
ADD_PROPERTY_GROUP
REMOVE_PROPERTY_GROUP
SET_PROPERTY_GROUP_PROPERTIES

Este nivel por defecto puede ampliarse para auditar acciones adicionales si es necesario. Para más información sobre cómo funciona el registro de actividad y cómo configurar las acciones auditadas, consulte Activity log.

Además del rastro de auditoría a nivel de aplicación, los administradores también deberían considerar habilitar la auditoría a nivel de sistema operativo (por ejemplo, acceso al sistema de ficheros, autenticación y llamadas al sistema en el servidor que aloja OpenKM). Este tipo de auditoría es independiente de OpenKM y debe configurarse y gestionarse a nivel del sistema operativo.

Restringir el acceso a las plantillas de documentos

OpenKM puede generar documentos a partir de plantillas en formatos HTML, PDF y ODT, usando el motor de plantillas FreeMarker para insertar contenido dinámico. Dado que estas plantillas se procesan y ejecutan en el lado del servidor, una plantilla que contenga etiquetas FreeMarker maliciosas podría usarse como vector de ataque contra el servidor.

Por este motivo, se recomienda encarecidamente que solo los administradores de la aplicación tengan permisos de escritura sobre la carpeta de plantillas y sus subcarpetas, de forma que los usuarios normales no puedan crear ni modificar plantillas. También se recomienda mantener esta carpeta permanentemente auditada, de forma que cualquier cambio realizado en una plantilla pueda rastrearse y revisarse.