Prioridad de Reglas

DataSunrise proporciona una manera inteligente de administrar la secuencia de activación de las reglas para capturar de manera eficiente la información objetivo dentro de su base de datos. Al mantener este nivel de enfoque, DataSunrise elimina la ejecución redundante y/o la generación de registros de auditoría por el mismo módulo de regla dos veces, lo cual debe tenerse 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 orden de prioridad, la cual, por supuesto, puede cambiarse según sus requisitos.

El motor de DataSunrise opera de una 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 rastros 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 requieren atención específica, no las de mayor prioridad o viceversa.

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

En el siguiente ejemplo, demostramos cómo DataSunrise procesará la prioridad de las reglas de auditoría con sujetos 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, aunque como queda claro por el nombre, la configuración se ha hecho de manera que algunas consultas podrían coincidir con los criterios de activación en cada una de ellas:
   1. 1st_EmployeesTable: esta regla está creada para auditar las actividades a nivel de la tabla Employees (del esquema HR).
   2. 2nd_auditHRschema: esta regla está creada para auditar las actividades a nivel del esquema.
   3. 3rd_audit_ORCL_db: esta regla está creada para auditar cualquier actividad en toda la base de datos.
   4. QueryTypes: esta regla está creada para auditar TODO tipo de consultas aparte de SELECT.
2. He ejecutado dos sentencias SQL (una bastante simple y la otra bastante compuesta):
   • Esas dos sentencias SQL han resultado en los siguientes rastros de auditoría (un rastro para la primera consulta y tres rastros para la segunda consulta):
   • La primera consulta califica técnicamente para activar las tres primeras reglas, siendo:
     1. tabla EMPLOYEES (Regla# 1).
     2. miembro del esquema HR (Regla# 2).
     3. en la base de datos (Regla# 3).

     Sin embargo, solo genera ID de Auditoría# 1, como podemos ver en los resultados a continuación, y la razón de eso 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.

     
   • Sin embargo, por otro lado, la razón por la que la segunda consulta genera tres rastros 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 diferentes:
     1. La primera regla 1st_EmployeesTable ha sido activada por la sentencia SELECT que involucraba la tabla EMPLOYEES de la sentencia principal CTAS (Crear Tabla Como Select).
     2. La segunda regla 2nd_auditHRschema ha sido activada por la cláusula JOIN en la misma sentencia SELECT de la sentencia CTAS principal que llama a otra tabla (DEPARTMENTS) que no está siendo abordada por la primera regla.
     3. La cuarta regla QueryTypes ha sido activada por la cláusula CREATE de la sentencia CTAS.

Entonces, para resumir todo esto, si el motor de DataSunrise reconoce múltiples componentes en la consulta que pueden activar distintivamente múltiples reglas, lo hará, a menos que sea el mismo componente en cuyo caso solo activará la regla una vez como lo que ocurrió en el rastro de auditoría de la primera consulta para SELECT * FROM employees;.

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

Para las reglas de seguridad se aplican los mismos conceptos anteriores y se debe considerar otro aspecto en relación al número de filas afectadas/obtenidas:

1. Las siguientes reglas cumplen dos objetivos diferentes:
   • La primera regla permite la ejecución de cualquier consulta que obtenga/afecte más de 1 fila.
   • La segunda regla bloquea la ejecución de cualquier consulta que obtenga/afecte más de 10 filas.
2. En ese caso, a la primera regla se le ha dado mayor prioridad que a la segunda, lo que significa virtualmente que cualquier consulta que intente obtener 1 fila o más tendrá permitido hacerlo independientemente de las otras reglas que traten los criterios (número de filas obtenidas/afectadas).
3. Si damos un paso más y habilitamos una tercera regla que bloquee todas las consultas incondicionalmente, eso cubriría criterios adicionales de seguridad aparte del enfoque en el número de filas obtenidas/afectadas y en ese caso, independientemente del nivel de prioridad, DataSunrise habilitará la tercera regla: