Priorité des Règles

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

À cet égard, DataSunrise optera toujours pour la première règle dans la liste des ordres de priorité, qui bien entendu peut être modifiée 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 traces d’audit qui se rapportent à plusieurs règles qui se chevauchent avec 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 particulière, et non les autres de 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 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é faite de manière à ce que certaines requêtes puissent correspondre aux critères de déclenchement dans 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 l’ensemble de 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 (l’une assez simple et l’autre assez complexe) :
   • Ces deux instructions SQL ont abouti aux traces d’audit suivantes (une trace pour la première requête et trois traces pour la deuxième requête) :
   • La première requête satisfait techniquement les critères de déclenchement des trois premières règles, étant :
     1. table EMPLOYEES (Règle #1).
     2. membre du schéma HR (Règle #2).
     3. dans la base de données (Règle #3).

     Elle ne génère toutefois qu’un seul identifiant d’audit (#1) comme nous pouvons le voir dans les résultats ci-dessous, la raison en est qu’une partie de cette requête nécessite une focalisation d’audit, à savoir le SELECT sur la table EMPLOYEES, de sorte qu’aucune autre partie de cette requête ne déclenche de nouvelles 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 traces est que le moteur de DataSunrise reconnaît trois composantes dans cette requête associées distinctement à trois règles différentes sous trois aspects de déclenchement différents :
     1. La première règle 1st_EmployeesTable a été déclenchée par l’instruction SELECT impliquant la table EMPLOYEES de l’instruction principale CTAS (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 principale CTAS qui appelle une autre table (DEPARTMENTS) qui n’est pas adressée par la première règle.
     3. La quatrième règle QueryTypes a été déclenchée par la clause CREATE de l’instruction CTAS.

En résumé, si le moteur de DataSunrise reconnaît plusieurs composantes dans la requête qui peuvent déclencher distinctement plusieurs règles, il le fera, à moins qu’il ne s’agisse de la même composante auquel cas il ne déclenchera la règle qu’une seule fois, comme cela s’est produit dans la trace 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 mentionnés ci-dessus s’appliquent et une autre considération quant au nombre de lignes affectées/récupérées doit être prise en compte :

1. Les règles suivantes atteignent 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é supérieure à la seconde, ce qui signifie virtuellement que toute requête qui essaie de récupérer au moins une ligne sera autorisée à le faire, indépendamment des autres règles traitant du critère (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 sans condition, cela couvrirait des critères de sécurité supplémentaires autres que le nombre de lignes récupérées/affectées. Dans ce cas, quelle que soit la priorité, DataSunrise activera la troisième règle :