Priorité des Règles

DataSunrise fournit une méthode intelligente pour gérer la séquence de déclenchement des Règles afin de capturer efficacement les informations ciblées dans votre base de données. Tout en maintenant ce niveau de concentration, DataSunrise élimine l’exécution redondante et/ou la génération de journaux d’audit par le même module de règle deux fois, cela doit donc être gardé à l’esprit lors de l’ordre de priorité des Règles qui se chevauchent (le cas échéant).

À cet égard, DataSunrise optera toujours pour la première Règle dans l’ordre de priorité, qui peut bien sûr être modifié selon vos besoins.

Le moteur de DataSunrise fonctionne de manière à capturer toutes les parties d’une requête complexe en séquence pour imposer une surveillance de sécurité granulaire ; par conséquent, il générera plusieurs pistes d’audit qui concernent plusieurs Règles qui se chevauchent à différents niveaux de gravité, car cela pourrait être essentiel pour imposer des notifications et/ou des alertes pour certaines activités dans des requêtes complexes qui nécessitent une attention spécifique, pas celles d’une priorité plus élevée ou vice versa.

Gestion de la Priorité des Règles d’Audit dans DataSunrise :

Dans l’exemple suivant, nous démontrons comment DataSunrise traitera la priorité des Règles d’Audit avec des sujets qui se chevauchent.

1. La liste suivante de Règles contient des Règles d’Audit pour auditer TOUTES les activités de la base de données dans une base de données Oracle, mais, comme il est clair d’après les noms, la configuration a été réalisée de manière à ce que certaines requêtes puissent correspondre aux critères de déclenchement de chacune d’entre elles :
   1. 1st_EmployeesTable : cette Règle est créée pour auditer les activités au niveau de la table Employees (du schéma HR).
   2. 2nd_auditHRschema : cette Règle est créée pour auditer les activités au niveau du schéma.
   3. 3rd_audit_ORCL_db : cette Règle est créée pour auditer toutes les activités dans toute la base de données.
   4. QueryTypes : cette Règle est créée pour auditer TOUS les types de requêtes autres que SELECT.
2. J’ai exécuté deux instructions SQL (une assez simple et l’autre assez composite) :
   • Ces deux instructions SQL ont abouti aux pistes d’audit suivantes (une piste pour la première requête et trois pistes pour la deuxième requête) :
   • La première requête répond techniquement aux critères pour déclencher les trois premières Règles, à savoir :
     1. table EMPLOYEES (Règle n° 1).
     2. membre du schéma HR (Règle n° 2).
     3. dans la base de données (Règle n° 3).

   Pourtant, elle ne génère que l’Audit ID# 1 comme nous pouvons le voir dans les résultats ci-dessous et la raison en est qu’une partie de cette requête nécessite une concentration d’audit qui est le SELECT sur la table EMPLOYEES, donc étant donné qu’aucune autre partie de cette requête ne déclenche d’autres Règles, aucune ne sera déclenchée.

   
   • D’un autre côté, la raison pour laquelle la deuxième requête génère trois pistes est le fait que le moteur de DataSunrise reconnaît trois composants dans cette requête associés distinctement à trois Règles différentes de trois aspects de déclenchement différents :
     1. La première Règle 1st_EmployeesTable a été déclenchée par l’instruction SELECT qui impliquait la table EMPLOYEES de l’instruction CTAS principale (Create Table As Select).
     2. La deuxième Règle 2nd_auditHRschema a été déclenchée par la clause JOIN dans la même instruction SELECT de l’instruction CTAS principale qui appelle une autre table (DEPARTMENTS) qui n’est pas abordée par la première Règle.
     3. La quatrième Règle QueryTypes a été déclenchée par la clause CTAS de l’instruction CREATE.

Donc pour résumer tout cela, si le moteur de DataSunrise reconnaît plusieurs composants dans la requête capables de déclencher distinctement plusieurs Règles, il le fera, à moins qu’il ne s’agisse du même composant auquel cas il ne déclenchera la Règle qu’une seule fois comme ce qui s’est passé dans la piste d’audit de la première requête pour SELECT \* FROM employees;

Gestion de la Priorité des Règles de Sécurité dans DataSunrise :

Pour les Règles de Sécurité, les mêmes concepts ci-dessus s’appliquent et une autre considération concernant le nombre de lignes affectées/récupérées doit être prise en compte :

1. Les Règles suivantes réalisent deux objectifs différents :
   • La première Règle autorise l’exécution de toute requête qui récupère/affecte plus d’une ligne.
   • La deuxième Règle bloque l’exécution de toute requête qui récupère/affecte plus de 10 lignes.
2. Dans ce cas, la première Règle a été donnée une priorité plus élevée que la deuxième, ce qui signifie pratiquement que toute requête qui essaie de récupérer 1 ligne ou plus sera autorisée à le faire, quelle que soit l’autre Règle qui traite des critères (nombre de lignes récupérées/affectées).
3. Si nous allons un peu plus loin et activons une troisième Règle qui bloquerait toutes les requêtes inconditionnellement, cela couvrirait des critères de sécurité supplémentaires autres que l’accent mis sur le nombre de lignes récupérées/affectées et dans ce cas, peu importe le niveau de priorité, DataSunrise activera la troisième Règle :