Firma de registros

Hay muchas formas de cumplir con los requisitos de firma de registros, también conocidos como archivos de registro firmados.

• La protección de integridad de la base de datos EJBCA incorporada (descrita aquí).

• Firme los registros con herramientas externas a medida que se rotan. Para más información, consulte la sección "Firma de registros externos" en Seguridad EJBCA.

La implementación del Registro de Auditoría de Seguridad de IntegrityProtectedDevice almacena las entradas del registro en la base de datos y se basa en la Protección de Integridad de la Base de Datos de EJBCA para proteger la autenticidad de los eventos del registro. Cada evento del registro recibe un identificador compuesto por un "nodeId" y un "sequenceNumber" que forma parte de los datos protegidos por la integridad. El nodeId es configurable y debe ser único para cada JVM en un clúster con acceso compartido a la base de datos. El "sequenceNumber" es único para cada nodeId y comienza en 0. El sequenceNumber de un nodo (JVM) se lee cuando se escribe la primera entrada del registro en este dispositivo y se guarda en memoria durante la vida útil de la JVM.

Para obtener más detalles técnicos, consulte Protección de integridad de la base de datos en Seguridad EJBCA.

La seguridad de esta implementación depende de:

• Token de protección de integridad de la base de datos.

• El número de secuencia en la memoria para cada nodo (JVM).

El uso de un número de secuencia evitará que se elimine una sola entrada del registro sin que sea posible detectarla. Mantener el número de secuencia en la JVM evitará que se eliminen todas las entradas del registro hasta un momento anterior sin que sea posible detectarlas.

Esta implementación no puede detectar:

• Eliminación de todas las últimas entradas de registro de un nodo hasta un punto anterior en el tiempo si la JVM del nodo no se está ejecutando.

• Entradas de registro falsificadas si el token de protección de integridad de la base de datos se ve comprometido.

La motivación de este diseño es que cada nodo (JVM) no tiene que esperar a otros nodos en un clúster (solo para bases de datos compartidas). Internamente, en cada JVM, el único bloqueo entre subprocesos ocurre cuando el número de secuencia se actualiza automáticamente. Esto permitirá un escalamiento horizontal muy alto sin necesidad de comunicación entre JVM cuando la base de datos compartida admita el bloqueo de filas.

Al utilizar esta implementación, la integridad de cada entrada de registro obtenida siempre se valida cuando se carga desde la base de datos, pero no se realiza una validación completa con verificaciones de números de secuencia faltantes.

La configuración del dispositivo de registro de integridad protegida se encuentra en los archivos:

• conf/cesecore.properties

• conf/databaseprotection.properties

Es posible verificar una tabla completa con la herramienta CLI de Base de Datos Local. Si alguna fila de la tabla no se puede verificar, la herramienta la mostrará. En el caso de la tabla AuditRecordData, también se comprobará con el número de secuencia que no falte ninguna fila.

Verificación de la integridad de los registros de auditoría de seguridad protegidos

La CLI de base de datos local se puede utilizar para verificar la protección de la base de datos tanto en una instancia EJBCA en línea como en una base de datos donde solo se ha exportado un registro de auditoría de seguridad.

Para obtener más información sobre la CLI de la base de datos local, consulte Interfaces de línea de comandos .

Reparación de brechas de secuencia

El número de secuencia del Registro de Auditoría de Seguridad por nodo es un contador. Siempre que sea necesario escribir una entrada en el Registro de Auditoría de Seguridad, se obtiene el contador y se incrementa (como una operación atómica). Si la escritura en la base de datos falla:

• El contador no se reducirá (dado que varios subprocesos pueden estar operando en él, no hay forma de saber cuál es la entrada faltante).

• Habrá una brecha de secuencia en el registro.

Esto también podría ocurrir si un atacante elimina ciertas entradas de la base de datos para ocultar su rastro. Dado que no escribir el registro de auditoría en la base de datos revertirá la transacción que inició el evento de seguridad, este no se ejecutará. Lo más probable es que se pueda correlacionar esto con los registros del servidor del momento en que esto ocurrió para descubrir que la base de datos no estaba disponible por razones técnicas. Por ejemplo, un clúster de MariaDB+Galera que esté en proceso de reformar un quórum podría experimentar algunas transacciones fallidas antes de volver a estar operativo.

Actualmente no existe una manera fácil de "reparar" dicha secuencia, pero debería documentarse por qué sucedió esto (o más bien, que la causa fue técnica y no maliciosa).

Una forma no fácil de usar para reparar brechas de secuencia sigue este principio:

• En una copia de la base de datos, elimine todos los registros excepto 1 (o tantos como huecos tenga)

• Actualice el(los) registro(s), usando SQL para cambiar sequenceNumber por los que faltan y primaryKey por algo único

• Ejecute ejbca-db-cli export desde la base de datos de copia. Esto generará un volcado con solo estos registros, que coinciden con los espacios vacíos en la base de datos original.

• Ejecute ejbca-db-cli import para importar este volcado en la base de datos original. Esto insertará los números de secuencia faltantes, utilizando la protección de base de datos configurada en ejbca-db-cli.

Iniciar un nuevo registro de auditoría

Si el registro de auditoría se vuelve demasiado grande o se daña, puede crear uno nuevo en lugar de intentar reparar uno antiguo. Dado que el registro de auditoría se controla por nodo EJBCA, puede hacerlo globalmente (para todos los nodos) o para un solo nodo.

Para iniciar un nuevo registro de auditoría a nivel global, para todos los nodos, haga lo siguiente:

1. Detener todos los nodos EJBCA.

2. Archivar/Exportar la tabla AuditRecordData existente, para tener el registro de auditoría antiguo disponible sin conexión (no desea simplemente eliminarlo sin conservar una copia).

3. Trunca la tabla AuditRecordData, eliminando todos los registros existentes.

4. Reinicie los nodos EJBCA. Con AuditRecordData vacío, cada nodo iniciará un nuevo registro de auditoría.

Exportación de registros de auditoría de seguridad

Cada instalación tiene requisitos específicos para gestionar los registros de auditoría. Existen varias maneras de exportar los registros de auditoría de seguridad.

• Rotar los archivos de registro del sistema (incluido el registro de auditoría) y archivar/procesar los archivos de registro rotados

• Utilice un SYSLOG adjunto para enviar el registro del sistema (incluido el registro de auditoría) a un servidor de registro central que realiza funciones de monitoreo.

• Exportar el registro de auditoría de la base de datos mediante la CLI de base de datos local

• Exportar el registro de auditoría de la base de datos mediante herramientas de base de datos

• Exportar una vista específica de la página Registro de auditoría en CA UI a un archivo XML

• Exportar una vista específica de la página del Registro de auditoría en CA UI a un CMS firmado (sintaxis de mensaje criptográfico)