Meilleures pratiques des règles de DataSunrise

Introduction

DataSunrise Database Security est une solution puissante de surveillance des activités de la base de données/audit des données et de protection des données en temps réel ainsi qu’un pare-feu pour bases de données qui augmente considérablement le niveau de sécurité des données et de la base de données, tant sur site que dans le cloud. Souvent, il est difficile de comprendre quelles données doivent être protégées, où ces données se trouvent dans votre base de données et comment configurer la suite DataSunrise pour obtenir la protection la plus élevée possible.

Ce document contient une description détaillée des meilleures pratiques des règles de DataSunrise qui vous aideront à créer la configuration de sécurité des données la plus efficace et appropriée.

Fonctionnalités et capacités clés de DataSunrise

1. Surveillance de l’activité de la base de données/Audit des données

La surveillance de l’activité de la base de données (DAM) par DataSunrise permet un suivi en temps réel de toutes les actions des utilisateurs et des modifications apportées à une base de données. Alors que l’audit des bases de données est principalement utilisé pour l’enquête sur les violations de données, la surveillance continue de l’activité des bases de données aide à détecter les tentatives d’abus de droits d’accès et à prévenir les préparations de violations de données à l’avance.

En outre, DataSunrise utilise des algorithmes auto-apprenants intelligents et une analyse comportementale pour accélérer le processus de déploiement du pare-feu de base de données. DataSunrise analyse le comportement des utilisateurs et des applications typiques et crée une « liste blanche » de requêtes SQL considérées comme sûres par défaut.

2. Protection des données et pare-feu de base de données

Le module de sécurité des données de DataSunrise est l’outil principal pour défendre les bases de données d’entreprise contre les actions nuisibles et hostiles et garantir la conformité. Armé d’une surveillance continue du trafic et d’algorithmes d’analyse SQL avancés, DataSunrise détecte les injections SQL et les tentatives d’accès non autorisé en temps réel. Lorsque le pare-feu de base de données de DataSunrise détecte une violation de la politique de sécurité, il bloque immédiatement la requête SQL malveillante et envoie une notification aux administrateurs via SMTP ou SNMP.

3. Gestionnaire de conformité

Le gestionnaire de conformité assure la conformité avec un certain nombre de normes et réglementations de sécurité nationales et internationales telles que HIPAA, PCI DSS, ISO 27001, RGPD et SOX. La fonctionnalité du gestionnaire de conformité prend le contrôle total de l’accès aux bases de données d’entreprise pour empêcher le traitement illégal des données, la modification non autorisée des données ou la perte accidentelle de données.

La fonctionnalité du gestionnaire de conformité repose sur une découverte automatique des données sensibles dans une base de données cible, l’attribution de certains rôles aux utilisateurs de la base de données cible et la mise en œuvre de politiques de sécurité, de masquage et d’audit selon ces rôles ainsi que sur un rapport de conformité périodique pour un examen permanent de l’activité de la base de données.

4. Découverte des données sensibles

La découverte des données de DataSunrise identifie les données sensibles dans les bases de données d’entreprise et aide à établir la protection la plus efficace de ces données. Elle permet aux entreprises de comprendre quel niveau de contrôle est approprié pour chaque type de données sensibles que contiennent leurs bases de données. Cette fonctionnalité aide également à se conformer aux exigences de réglementations telles que le RGPD, la HIPAA, la SOX, la PCI DSS et d’autres.

5. Masquage dynamique des données

DataSunrise prévient l’exposition des données sensibles grâce à son masquage dynamique des données (DDM).

Le DDM de DataSunrise sécurise les informations critiques pour l’entreprise en obscurcissant les données d’intérêt dans la base de données entière ou seulement dans des tables ou colonnes sélectionnées pour les utilisateurs indésirables. DataSunrise masque les données en remplaçant les entrées réelles de la base de données par des valeurs générées aléatoirement ou prédéfinies par l’utilisateur.

Pour prévenir les fuites potentielles de données, les entrées de la base de données spécifiées par un utilisateur de DataSunrise sont masquées à la volée avant que les données ne soient extraites de la base de données.

Gestionnaire de conformité

Le gestionnaire de conformité est un bon outil pour créer une configuration initiale de DataSunrise. En bref, il automatise les étapes de configuration de DataSunrise en effectuant la découverte des données et en créant des entités de configuration basées sur les résultats de la découverte des données. Le gestionnaire de conformité crée les entités suivantes :

• Règle d’audit pour les objets de la base de données contenant des données sensibles
• Règle de sécurité pour bloquer les injections SQL
• Règle de sécurité pour bloquer l’accès aux données sensibles à tout le monde, sauf à certains utilisateurs inclus dans les groupes d’utilisateurs de la base de données définis lors du fonctionnement du gestionnaire de conformité
• Règle de sécurité pour bloquer toutes les requêtes administratives émises par des utilisateurs de la base de données qui n’appartiennent pas à des groupes d’utilisateurs « autorisés »
• Règles de masquage pour l’obscurcissement des données sensibles pour les utilisateurs de la base de données non inclus dans les groupes d’utilisateurs « autorisés » et non autorisés à traiter les données d’origine.

En plus de l’ensemble de règles décrit ci-dessus, le gestionnaire de conformité crée également les rapports suivants :

• Rapport d’audit sur les cas d’accès aux objets sensibles de la base de données
• Rapport de sécurité sur les tentatives d’accès aux données sensibles par des utilisateurs non autorisés à traiter les données protégées
• Rapport d’erreurs sur les requêtes qui n’ont pas été exécutées en raison d’erreurs de toute origine
• Rapport d’événements système sur les événements survenus dans DataSunrise pendant la période d’intérêt
• Rapport de masquage sur les cas d’accès aux données sensibles ayant entraîné l’obscurcissement des données pour les utilisateurs non autorisés à traiter les données sensibles d’origine.

Notez que le gestionnaire de conformité ne peut pas garantir une couverture à 100% de toutes les données non sécurisées contenues dans une base de données cible. Le gestionnaire de conformité vous fournit une configuration que vous pouvez utiliser comme point de départ, première estimation de configuration pour votre cas. Bien que cette approche vous offre un cadre prêt à l’action pour votre suite de sécurité DataSunrise, vous pouvez trouver que le modèle de rôle proposé ne convient pas à votre cas particulier. Dans ce cas, vous pouvez personnaliser les options de sessions de filtre de vos règles.

Découverte des données sensibles

La découverte des données sensibles vous aide à rechercher les données sensibles contenues dans votre base de données. Il est judicieux de configurer une tâche périodique de découverte des données qui découvre en continu les données sensibles selon les multiples normes de sécurité intégrées. En utilisant les résultats de la découverte des données, vous pouvez sécuriser vos données sensibles selon vos politiques de sécurité, excluant la recherche manuelle et la sécurisation manuelle de ces données en même temps.

Pour avoir une représentation visuelle des données sensibles trouvées, il est recommandé de configurer également des tâches périodiques de génération de rapports PDF/CSV.

Cependant, exécuter une tâche de découverte des données ne garantit pas une découverte à 100% des données sensibles. Consulter le DBA est également l’une des étapes importantes qui doit être effectuée afin de ne laisser aucune donnée sensible non sécurisée.

Bien que la découverte des données ait un impact mineur sur la base de données (par rapport à une application cliente qui interroge les N premiers (N=100 par défaut) lignes de chaque table dans chaque base de données), vous pouvez réduire l’ensemble de l’échantillonnage en utilisant l’option “Nombre de lignes analysées” des paramètres avancés.

Règles d’audit et Règles de sécurité

Notez que les paramètres des Règles d’audit et de sécurité sont similaires à l’exception de la section Actions. Cela signifie que vous pouvez surveiller ou bloquer l’activité de la base de données d’intérêt en fonction de votre choix sans manquer aucune possibilité.

Lorsqu’il s’agit d’affiner les règles d’audit et de sécurité, la recommandation générale est d’éviter de créer des règles générales « tout-en-un » car cela peut fournir trop de données pour l’analyse générée par des processus tiers ou par un outil de requête SQL (tel que PGAdmin pour PostgreSQL ou SQL Server Management Studio pour Microsoft SQL Server).

Envisagez d’établir une surveillance uniquement pour les objets de la base de données contenant des données sensibles ou d’observer l’accès à des données nécessitant une observation stricte de l’accès aux données et une journalisation. Vous pouvez utiliser la fonctionnalité Groupes d’objets pour organiser ces objets de la base de données, tels que des tables, des vues, des procédures stockées et des fonctions, en groupes.

L’utilisation des Groupes d’objets dans vos règles d’audit/sécurité vous permet d’établir un contrôle et une surveillance sur vos parties de stockage de données d’intérêt pour obtenir des données d’audit claires et pertinentes.

Ci-dessous, vous trouverez quelques « recettes » sur la façon de configurer les règles de DataSunrise afin de résoudre les problèmes les plus répandus qui peuvent causer des problèmes dans votre base de données ou peuvent être les premiers signes d’une attaque sur votre stockage de données.

Audit/Blocage d’une tentative de connexion suspecte (tentative de connexion)

Malgré le fait que les applications puissent établir de nombreuses connexions à une base de données, il est important de surveiller le nombre anormal de connexions ou les échecs de connexion, voire de restreindre ce type d’activité provenant d’hôtes et de connexions suspects. Ci-dessous, vous trouverez quelques conseils sur la façon de créer une règle d’audit/sécurité qui couvre tous les principaux cas de tentatives de connexion suspectes qui signifient souvent qu’une personne malveillante essaie de lancer une attaque par force brute sur votre base de données.

1. Audit/Blocage de connexions fréquentes réussies/échouées (dans une période de temps)

Pour surveiller les connexions réussies à une base de données via un proxy DataSunrise, utilisez des événements de session d’audit avec l’option « Audit Frequent Connections » activée pour auditer les cas où il y a de nombreuses connexions fréquentes provenant d’un certain utilisateur + hôte ou hôte.

Pour prévenir les tentatives de connexion fréquentes réussies ou échouées en bloquant leur source par hôte + nom d’utilisateur ou par hôte, activez « Block DDOS or Brute Force » dans la section Événements de session de votre règle.

2. Blocage des requêtes provenant de l’extérieur d’une plage IP autorisée

Pour bloquer les requêtes provenant d’adresses IP potentiellement dangereuses, utilisez les options de session de filtrage pour configurer votre règle de sécurité afin qu’elle soit déclenchée par des requêtes ne provenant PAS des hôtes inclus dans votre liste d’hôtes de DataSunrise.

3. Prévention des connexions non sécurisées d’être établies

Un proxy DataSunrise peut être configuré pour n’accepter que les connexions SSL en activant l’option “N’accepter que les connexions SSL” dans les paramètres du proxy de votre profil de base de données cible dans la console Web.

4. Surveillance des connexions d’utilisateur Root et privilégié

L’observation de l’activité globale de connexion Root peut être accomplie en créant un groupe d’objets d’audit par défaut ou une règle de type de requête et en configurant les paramètres des sessions de filtrage basés sur le nom de l’utilisateur de la base de données root (par exemple, « root » pour MySQL, « system/sys » pour Oracle, etc.) ou le nom de l’utilisateur de la base de données avec des privilèges administratifs si vous devez éviter d’utiliser un compte utilisateur root.

Recommandations pour les requêtes (Session)

1. Requêtes de langage de modification de données

Les règles d’audit/sécurité de groupe d’objets sont préférées aux règles de type de requête. Elles permettent d’établir une surveillance et/ou un blocage des principales opérations CRUD effectuées sur une base de données en ajoutant les objets requis soit à partir du navigateur d’objets en choisissant les objets répertoriés dans la règle à traiter, soit en spécifiant un groupe d’objets créé à l’avance manuellement ou en utilisant la découverte de données. Si l’observation de types de requêtes particuliers est requise ou restreinte, utilisez la règle d’audit/sécurité de type de requête. Notez qu’il est également possible de surveiller l’exécution des types de requêtes choisis sur certains objets de la base de données en spécifiant un groupe d’objets dans les paramètres de la règle. De plus, toutes les règles peuvent être configurées pour être déclenchées uniquement par des requêtes provenant d’une certaine application, utilisateur, utilisateur d’application, hôte garantissant ainsi que la règle de sécurité créée ne se déclenchera pas accidentellement. Pour cela, configurez les paramètres de filtrage des sessions de la règle.

2. Règles d’audit et de sécurité de type injection SQL

DataSunrise propose un mécanisme de détection des injections SQL basé sur des points de pénalité (sanctions) qui vous permet de définir votre propre niveau de requêtes « autorisées » adressées à votre base de données.

Nous vous recommandons de configurer une règle d’audit d’injection SQL pour surveiller les requêtes suspectes et de configurer une alerte dans la section Notifications de la règle d’audit. Les valeurs de pénalité de votre filtre doivent correspondre à des requêtes d’injection SQL « faibles » qui ne peuvent causer aucun dommage à une base de données.

En plus des règles d’audit avec des alertes configurées, il est nécessaire de configurer une règle de sécurité de type injection SQL qui bloquera les requêtes d’injection SQL dépassant le nombre spécifié de points de pénalité.

Notez que le nombre de pénalités doit correspondre aux requêtes d’injection SQL pouvant causer des dommages importants à une base de données. Les valeurs de pénalité devraient être supérieures à celles de la règle d’audit.

3. Requêtes retournant un nombre énorme de lignes

Un grand nombre de lignes affectées/récupérées lorsque aucune requête correspondante utilisée par l’application ou les outils de BI peut indiquer qu’une activité suspecte se produit dans la base de données ou que l’application a été compromise. Pour empêcher l’exécution de telles requêtes, utilisez une règle de sécurité de type groupe d’objets avec « Déclencher la règle uniquement si le nombre de lignes affectées/récupérées n’est pas inférieur à » activé suivi du nombre de lignes affectées/récupérées considéré comme anormal dans votre environnement. Une autre méthode consiste à utiliser une règle d’audit avec filtre de type groupe d’objets configuré et un abonné attaché afin de recevoir des notifications sur ce type d’événements se produisant dans la base de données.

4. Requêtes exécutées pendant trop longtemps

Lorsque l’exécution de vos requêtes prend trop de temps, cela peut entraîner des problèmes de performance, une mauvaise expérience utilisateur et également être un signe qu’une personne interne essaie de voler vos données précieuses car ces données sont obtenues en interrogeant une table entière, ce qui peut prendre un certain temps. Utilisez une règle d’audit avec événements de session configurés : activez « l’exécution de la requête prend plus de temps que » et définissez une valeur (durée en secondes) considérée comme anormale et cette requête longue à exécuter doit être auditée et signalée à l’aide de la fonctionnalité d’abonnés.

5. Requêtes avec une syntaxe incorrecte (celles qui retournent une erreur)

Pour surveiller les requêtes qui n’ont pas été exécutées en raison d’une erreur de syntaxe quelconque, utilisez une règle de type événements de session d’audit avec l’option « Audit Operation Errors » activée. Configurez la fréquence des erreurs considérées comme suspectes et nécessitant l’attention de l’équipe DBA ou sécurité. Attachez un abonné pour informer le personnel en charge des erreurs SQL fréquemment rencontrées lors de l’établissement de connexions.

6. Requêtes accédant à des tables sensibles

Pour limiter l’accès à un éventail d’objets de la base de données, il est recommandé d’utiliser une règle de sécurité de type groupe d’objets. L’utilisation de ce type de règles de sécurité vous permet de limiter l’accès à certains objets de la base de données à l’aide soit d’une liste d’objets pouvant être sélectionnés via le navigateur d’objets, soit en utilisant un groupe d’objets contenant les objets de la base de données d’intérêt. Afin de fournir un niveau raisonnable de restriction d’accès aux données, il est conseillé de configurer les sessions de filtre pour activer cette règle à être déclenchée ou ignorée pour certains utilisateurs d’application/de base de données/hôte et groupes d’utilisateurs de base de données/utilisateurs d’application/hôtes.

7. Table piège à miel

Envisagez de créer une table (ou des tables) contenant des données sensibles factices qui agiront comme un appât pour les pirates. En cas de requête adressée à cette table, la source de la requête devrait être bloquée en permanence. Vous pouvez également appliquer une règle d’apprentissage afin d’obtenir plus d’informations sur la stratégie des attaquants (requêtes, hôtes, applications, etc.). En général, envisagez de créer une base de données piège dans une instance de base de données séparée dans votre environnement et placez-la derrière une autre instance de DataSunrise avec un stockage d’audit séparé et des bases de données dictionnaires.

8. Blocage des requêtes indésirables

Pour suivre et/ou bloquer certaines déclarations SQL que vous ne souhaitez pas exécuter, utilisez les Groupes de requêtes de DataSunrise. Vous pouvez les configurer soit comme des modèles de requêtes (en utilisant des expressions régulières) soit comme des requêtes exactes qui seront vérifiées et audit/bloquées à leur exécution. Une règle de sécurité doit être configurée pour vérifier si une requête entrante est incluse dans le groupe de requêtes attaché à la règle en utilisant la liste déroulante « Process Group of Query ». Il convient de noter qu’un groupe de requêtes doit être créé à l’avance afin de pouvoir être sélectionné dans la liste susmentionnée. Utilisez les groupes de requêtes pour établir la surveillance et/ou restreindre l’utilisation de certaines requêtes telles que les déclarations GRANT.

9. Requêtes visant des manipulations de privilèges

Vous pouvez utiliser la fonctionnalité de Groupes de requêtes pour créer des ensembles de requêtes SQL qui doivent être identifiées dans le trafic de la base de données, puis audit/bloquées. Cependant, la meilleure option pour surveiller les requêtes GRANT est d’utiliser des règles d’audit/sécurité configurées en tant que type de requête avec les types de requêtes correspondants spécifiés. Cela vous permet d’établir un contrôle complet sur les types de requêtes d’intérêt en surveillant et en restreignant l’exécution des catégories de requêtes choisies. Envisagez de combiner les Groupes de requêtes et les Règles de type de requête afin d’atteindre le niveau de contrôle désiré sur l’activité de la base de données.

10. Gestion des requêtes SQL SELECT *

SELECT * FROM TABLE n’est pas une requête courante. Dans de nombreux cas, de telles requêtes peuvent signifier que quelqu’un essaie d’obtenir le plus de données possible afin de télécharger l’ensemble des résultats de la base de données. Cela peut entraîner une fuite de données. Il est recommandé de contrôler de telles requêtes en restreignant leur exécution dans la base de données. Pour gérer les requêtes SELECT *, utilisez une règle de sécurité avec « La requête inclut l’expression « SELECT * » » cochée. Lorsque cette option est cochée, DataSunrise vérifie et bloque les requêtes comme SELECT * FROM TABLE et SELECT * FROM TABLE WHERE CONDITION=VALUE.

Si l’exécution de telles requêtes est requise, réduisez la liste des utilisateurs/applications/utilisateurs d’applications/hôtes autorisés en utilisant les options de sessions de filtre.

Règles de masquage dynamique

Recommandations générales

• Associez les règles d’audit avec des règles de masquage pour assurer une couverture complète de l’accès aux données sensibles
• Utilisez l’option « Filtrer la session » d’une règle de masquage pour éviter que la règle ne soit déclenchée par des utilisateurs indésirables.
• Utilisez le filtre « Utilisateur d’application » pour les cas où la règle de masquage dynamique est utilisée pour obscurcir les données accédées par des utilisateurs d’application dans des systèmes complexes tels que SAP ECC et Oracle EBS.
• S’il est nécessaire de masquer les valeurs incluses dans une ligne entière, envisagez d’utiliser la fonctionnalité « Masquer les lignes » au lieu d’un masquage dynamique régulier. L’utilisation de Masquer les lignes permet de masquer des lignes entières qui répondent aux exigences de la règle de masquage. Utilisez les sessions de filtre pour définir dans quelles conditions votre règle de masquage dynamique de type Masquer les lignes sera déclenchée.

Conclusion

Ce document regroupe les recommandations sous forme de cas d’utilisation auxquels les utilisateurs peuvent être confrontés lors de l’utilisation de la sécurité des bases de données. Les suggestions et cas d’utilisation fournis ne sont pas obligatoires, mais peuvent servir de référence lors de la création d’une configuration DataSunrise personnalisée.

Le document couvre les principales astuces et recommandations sur les types de règles et les options à utiliser afin de tirer parti de la surveillance de l’activité des bases de données, du pare-feu des bases de données et du masquage des données.