Meilleures pratiques des règles DataSunrise

Introduction

DataSunrise Database Security est une solution puissante de surveillance d’activité de base de données/audit de données et de protection des données en temps réel et de pare-feu de base de données qui augmente considérablement le niveau de sécurité des données et de la base de données sur place et 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 DataSunrise Suite pour obtenir la protection la plus élevée possible.

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

Principales fonctionnalités et capacités de DataSunrise

1. Surveillance d’activité de base de données / Audit de données

La surveillance d’activité de base de données DataSunrise (DAM) permet le 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 de base de données est principalement utilisé pour l’enquête sur les violations de données, la surveillance continue de l’activité de la base de données aide à détecter les tentatives d’abus des droits d’accès et à prévenir les préparations de violations de données à l’avance.

En outre, DataSunrise utilise des algorithmes d’auto-apprentissage 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 typique des utilisateurs et des applications et crée une “liste blanche” des 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 de l’entreprise contre des actions nuisibles et hostiles et assurer la conformité. Doté d’une surveillance continue du trafic et d’algorithmes avancés d’analyse SQL, DataSunrise détecte les injections SQL et les tentatives d’accès non autorisées en temps réel. Lorsque le pare-feu de la 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 en informe les administrateurs via SMTP ou SNMP.

3. Gestionnaire de conformité

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

La fonctionnalité du Gestionnaire de conformité se base sur une découverte automatique de 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 en fonction de ces rôles ainsi que des rapports de conformité périodiques pour une révision permanente de l’activité de la base de données.

4. Découverte de données sensibles

La découverte de données sensibles 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 contenues dans leurs bases de données. Cette fonctionnalité aide également à se conformer aux exigences de réglementations telles que le GDPR, HIPAA, SOX, PCI DSS, et autres.

5. Masquage dynamique de données

DataSunrise empêche l’exposition de données sensibles avec son masquage dynamique de données (DDM).

DataSunrise DDM sécurise les informations cruciales pour l’entreprise en obscurcissant les données d’intérêt dans la base de données complète ou simplement dans les 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 au hasard ou prédéfinies par l’utilisateur.

Pour éviter d’éventuelles fuites de données, les entrées de la base de données spécifiées par un utilisateur 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 réalisant la découverte de données et en créant des entités de configuration basées sur les résultats de la découverte de données. Le Gestionnaire de conformité crée les entités suivantes :

• Règle d’audit pour les objets de base de données contenant des données sensibles
• Règle de sécurité pour le blocage des injections SQL
• Règle de sécurité pour bloquer l’accès aux données sensibles à tous, sauf à certains utilisateurs inclus dans des groupes d’utilisateurs de la base de données définis lors de l’opération du Gestionnaire de conformité
• Règle de sécurité pour bloquer toutes les requêtes administratives émises par les utilisateurs de la base de données qui ne font pas partie des groupes d’utilisateurs “autorisés”
• Règles de masquage pour l’obfuscation de données sensibles pour les utilisateurs de base de données non inclus dans les groupes d’utilisateurs “autorisés” et non autorisés à traiter les données originales.

En plus des règles décrites ci-dessus, le Gestionnaire de conformité crée également les rapports suivants :

• Rapport d’audit sur les cas d’accès à des objets de base de données sensibles
• Rapport de sécurité sur les tentatives d’accès à des données sensibles par des utilisateurs non autorisés à manipuler 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 à des données sensibles ayant entraîné l’obfuscation des données pour les utilisateurs non autorisés à manipuler les données sensibles d’origine.

Notez que le Gestionnaire de conformité ne peut 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 base de référence, première estimation pour votre cas. Bien que cette approche vous offre une configuration prête à l’emploi pour votre DataSunrise Security Suite, vous pouvez trouver le modèle de rôle suggéré inadapté à votre cas particulier. Dans ce cas, vous pouvez personnaliser les options de Sessions de filtres de vos Règles.

Découverte de données sensibles

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

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

Néanmoins, exécuter une tâche de découverte de données ne garantit pas une découverte à 100% des données sensibles. Consulter un DBA est également l’une des étapes importantes qui devraient être effectuées afin de ne pas laisser de données sensibles non sécurisées.

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

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

Veuillez noter 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 elles peuvent fournir trop de données à analyser générées par des processus tiers ou par un outil de requêtes SQL (comme PGAdmin pour PostgreSQL ou SQL Server Management Studio pour Microsoft SQL Server).

Envisagez de n’établir une surveillance que pour les objets de base de données contenant des données sensibles ou d’observer l’accès aux données qui nécessitent une observation stricte et un enregistrement de l’accès aux données. Vous pouvez utiliser la fonctionnalité Groupes d’objets pour organiser ces objets de base de données tels que les tables, vues, procédures stockées et 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 DataSunrise pour traiter 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)

Bien 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 ou même de restreindre ce type d’activité provenant de hôtes et identifiants suspects. Vous trouverez ci-dessous 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’un intrus tente de lancer une attaque par force brute sur votre base de données.

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

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

Pour éviter des tentatives fréquentes de connexion réussie ou échouée en bloquant leur source par hôte+nom d’utilisateur ou par hôte, activez “Bloquer DDOS ou Brute Force” dans la section Événements de session de votre règle.

2. Blocage des requêtes venant de l’extérieur d’une PLAGE d’adresses IP autorisée

Pour bloquer les requêtes provenant d’adresses IP potentiellement dangereuses, utilisez les options des sessions de filtre pour configurer votre règle de sécurité pour être déclenchée par toute requête NE provenant PAS des hôtes inclus dans votre liste d’hôtes DataSunrise.

3. Empêcher l’établissement de connexions non sécurisées

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

4. Surveillance des connexions utilisateur root et privilégiées

L’observation de l’activité générale 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 filtre 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 d’administrateur si vous devez éviter d’utiliser un compte d’utilisateur root.

Recommandations pour les requêtes (session)

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

Les règles audit/sécurité basées sur des groupes d’objets sont préférées aux règles basées sur le 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 nécessaires soit depuis le navigateur d’objets en choisissant les objets répertoriés dans la règle pour être traités ou 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 une règle 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 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 ne se déclencher que 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étraquera pas. Pour cela, configurez les paramètres des sessions de filtre de la règle.

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

DataSunrise dispose d’un mécanisme de détection des injections SQL basé sur des points de pénalité 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 mettre en place une alerte dans la section Notifications de la règle d’audit. Les valeurs de pénalité de votre filtre doivent correspondre aux requêtes d’injection SQL “faibles” qui ne peuvent causer aucun dommage à une base de données.

Parallèlement aux règles d’audit avec les 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 significatifs à une base de données. Les valeurs de pénalité doivent être supérieures à celles de la règle d’audit.

3. Les requêtes qui renvoient un nombre énorme de lignes

Un grand nombre de lignes affectées/récupérées lorsqu’aucune requête correspondante n’est utilisée par l’application ou par des outils BI peut indiquer une activité suspecte se produisant 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 option est d’utiliser une règle d’audit avec un filtre de type groupe d’objets configuré et un abonné attaché pour recevoir des notifications sur ce type d’événements se produisant dans la base de données.

4. Les requêtes exécutées trop longtemps

Lorsque vos requêtes prennent trop de temps pour s’exécuter, cela peut entraîner des problèmes de performance, une mauvaise expérience utilisateur et peut également être un signe qu’un initié essaie de voler vos précieuses données puisque de telles données sont obtenues en interrogeant une table entière, ce qui peut prendre un certain temps. Utilisez une règle d’audit avec des é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 qu’une telle requête longue soit auditée et signalée à l’aide de la fonctionnalité d’abonnés.

5. Les 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, utilisez une règle d’événements de session d’audit avec l’option “Audit des erreurs d’opération” activée. Configurez la fréquence des erreurs considérée comme suspecte et nécessitant l’attention de l’administrateur de base de données ou de l’équipe de sécurité. Attachez un abonné pour informer le personnel responsable des erreurs SQL fréquentes survenant lors de l’établissement de la connexion.

6. Les requêtes qui accèdent aux tables sensibles

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

7. Table pot de miel

Envisagez de créer une table (tables) contenant de fausses données sensibles qui agiront comme un piège pour les pirates. Dans le cas où une requête est adressée à cette table, la source de la requête devrait être bloquée de manière permanente. Vous pouvez également appliquer une règle d’apprentissage pour 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 pot de miel dans une instance de base de données séparée de votre environnement et mettez-la derrière une autre instance de DataSunrise avec un stockage d’audit séparé et des bases de données de dictionnaire.

8. Blocage des requêtes indésirables

Pour suivre et/ou bloquer certaines instructions SQL que vous ne souhaitez pas exécuter, utilisez les Groupes de requêtes de DataSunrise. Vous pouvez les configurer soit en tant que modèles de requêtes (en utilisant des expressions régulières) soit en tant que requêtes exactes qui seront vérifiées et auditées/bloquées lors de 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 “Traiter le groupe de requêtes”. Il convient de noter qu’un groupe de requêtes doit être créé à l’avance pour être sélectionnable dans la liste susmentionnée. Utilisez les groupes de requêtes pour établir une surveillance et/ou restreindre l’utilisation de certaines requêtes telles que les déclarations GRANT.

9. Requêtes visant les 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és dans le trafic de base de données, puis audités et/ou bloqués. 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 correspondant spécifiés. Cela vous permet d’établir un contrôle complet sur les types de requêtes d’intérêt grâce à la surveillance et à la restriction de l’exécution des catégories de requêtes choisies. Envisagez de combiner des groupes de requêtes et des règles de type de requête pour atteindre le niveau de contrôle souhaité 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 autant de données que 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 ces 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 l’option “La requête inclut l’expression “SELECT *”” cochée. Lorsque cette option est activée, DataSunrise vérifie et bloque les requêtes comme SELECT * FROM TABLE et SELECT * FROM TABLE WHERE CONDITION=VALEUR.

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

Règles de masquage dynamique

Recommandations générales

• Associez des règles d’audit avec des règles de masquage pour fournir 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ù une règle de masquage dynamique est utilisée pour obscurcir les données auxquelles les utilisateurs d’application accèdent dans des systèmes complexes comme SAP ECC et Oracle EBS.
• Si le masquage des valeurs incluses dans une ligne entière est nécessaire, envisagez d’utiliser la fonctionnalité “Masquer les lignes” au lieu du masquage dynamique régulier. L’utilisation de Masquer les lignes permet de cacher des lignes entières qui remplissent les conditions de la règle de masquage. Utilisez les sessions de filtre pour définir dans quelles conditions votre règle de masquage de type Masquer les lignes sera déclenchée.

Conclusion

Ce document accumule les recommandations sous forme de cas d’utilisation que les utilisateurs peuvent rencontrer lors de l’utilisation de la sécurité de la base de données. Les suggestions et les cas d’utilisation fournis ne sont pas obligatoires mais peuvent être utilisés comme référence lors de la création d’une configuration personnalisée de DataSunrise.

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