Prioridad de Reglas

DataSunrise proporciona una manera inteligente de gestionar la secuencia de activación de Reglas para capturar eficientemente la información específica dentro de su base de datos. Al mantener este nivel de enfoque, DataSunrise elimina la ejecución redundante y/o generación de registros de auditoría por el mismo módulo de Regla dos veces, por lo que se debe tener en cuenta al ordenar la prioridad de las Reglas superpuestas (si las hay).

En ese sentido, DataSunrise siempre optará por la primera Regla en el listado de orden de prioridad, el cual por supuesto puede ser cambiado según sus requisitos.

El motor de DataSunrise opera de manera que captura todas las partes de una consulta compleja en secuencia para imponer un monitoreo de seguridad granular; por lo tanto, generará múltiples Pistas de Auditoría que se relacionan con múltiples Reglas superpuestas de diferentes niveles de severidad, ya que esto podría ser esencial para imponer notificaciones y/o alertas para ciertas actividades en consultas complejas que requieran atención específica, no las otras de mayor prioridad o viceversa.

Gestión de Prioridad de Reglas de Auditoría en DataSunrise:

En el siguiente ejemplo, demostramos cómo DataSunrise procesará la prioridad de las Reglas de Auditoría con temas superpuestos.

1. La siguiente lista de Reglas contiene Reglas de Auditoría para auditar TODAS las actividades de la base de datos en una base de datos Oracle, y como es claro por los nombres, la configuración se ha realizado de manera que algunas consultas puedan coincidir con los criterios de activación en cada una de ellas:
   1. 1st_EmployeesTable: esta Regla se crea para auditar las actividades de la tabla Employees (del esquema HR).
   2. 2nd_auditHRschema: esta Regla se crea para auditar las actividades a nivel de esquema.
   3. 3rd_audit_ORCL_db: esta Regla se crea para auditar cualquier actividad en toda la base de datos.
   4. QueryTypes: esta Regla se crea para auditar TODO tipo de consultas que no sean SELECT.
2. He ejecutado dos sentencias SQL (una bastante simple y la otra bastante compuesta):
   • Esas dos sentencias SQL han dado como resultado las siguientes Pistas de Auditoría (una pista para la primer consulta y tres pistas para la segunda consulta):
   • La primera consulta técnicamente califica para activar las primeras tres Reglas, siendo:
     1. tabla EMPLOYEES (Regla# 1).
     2. miembro del esquema HR (Regla# 2).
     3. una en la base de datos (Regla# 3).

     Sin embargo, solo genera la ID de Auditoría# 1 como podemos ver en los resultados a continuación y la razón de ello es que una parte de esa consulta requiere enfoque de Auditoría, que es el SELECT en la tabla EMPLOYEES, por lo que dado que ninguna otra parte de esa consulta activa más Reglas, ninguna será activada.

     
   • En cambio, la razón por la cual la segunda consulta genera tres pistas es el hecho de que el motor de DataSunrise reconoce tres componentes en esa consulta asociados distintamente con tres Reglas diferentes de tres aspectos de activación distintos:
     1. La primera Regla 1st_EmployeesTable ha sido activada por la sentencia SELECT que involucró la tabla EMPLOYEES de la sentencia principal CTAS (Create Table As Select).
     2. La segunda Regla 2nd_auditHRschema ha sido activada por la cláusula JOIN en la misma sentencia SELECT de la sentencia principal CTAS que llama a otra tabla (DEPARTMENTS) que no está siendo tratada por la primera Regla.
     3. La cuarta Regla QueryTypes ha sido activada por la cláusula CREATE de la sentencia CTAS.

Así que para resumir todo esto, si el motor de DataSunrise reconoce múltiples componentes en la consulta que pueden activar distintamente múltiples Reglas lo hará, a menos que sea el mismo componente en cuyo caso solo activaría la Regla una vez como lo que sucedió en la pista de auditoría de la primera consulta para SELECT * FROM employees;.

Gestión de Prioridad de Reglas de Seguridad en DataSunrise:

Para las Reglas de Seguridad se aplican los mismos conceptos anteriores y otra consideración con respecto al número de filas afectadas/recuperadas debe ser considerada:

1. Las siguientes Reglas están logrando dos objetivos diferentes:
   • La primera Regla permite la ejecución de cualquier consulta que recupere/afecte más de 1 fila.
   • La segunda Regla bloquea la ejecución de cualquier consulta que recupere/afecte más de 10 filas.
2. En ese caso, se le ha dado mayor prioridad a la primera Regla que a la segunda, lo que virtualmente significa que cualquier consulta que intente recuperar 1 fila o más se permitirá hacerlo independientemente de las otras Reglas que tratan con los criterios (número de filas recuperadas/afectadas).
3. Si damos un paso más y habilitamos una tercera Regla que bloquearía todas las consultas incondicionalmente, cubriría criterios adicionales de Seguridad distintos al enfoque en el número de filas recuperadas/afectadas y en ese caso, independientemente del nivel de prioridad, DataSunrise habilitará la tercera Regla: