Questions Fréquemment Posées

Non, DS ne dispose pas de telles capacités. Il convient de noter que DS est une solution de sécurité des bases de données et non un pare-feu d’application Web (WAF). DataSunrise protège les bases de données, et non les applications qui s’exécutent dessus.

La seule chose qui peut être utilisée comme une sorte de correctif virtuel est la règle de sécurité de prévention des injections SQL, car l’attaque par injection SQL est généralement effectuée au niveau de l’application en exploitant une mauvaise conception de l’application permettant à un cybercriminel d’envoyer des commandes SQL malveillantes avec des paramètres de requête non paramétrés ou non échappés.

Non, le scanner VA de DataSunrise ne peut être utilisé qu’à des fins de reporting et ne réalise aucun correctif dans le cadre de la logique de fonctionnement du scanner VA.

Cependant, pour certains moteurs et versions de SGBD sélectionnés, DataSunrise peut fournir une liste d’actions à entreprendre pour renforcer la sécurité des SGBD selon les critères de sécurité de CIS et STIG.

DataSunrise est uniquement capable de trouver et de suggérer la correction des vulnérabilités et des mauvaises configurations diagnostiquées et réparables via des commandes d’interface SQL.

DataSunrise ne dispose plus de composants pour fonctionner en mode haute disponibilité (actif/passif ou actif-actif).

La répartition de charge ou le basculement doivent être configurés à l’aide de solutions tierces (commerciales ou open-source) :

• Keepalived (basculement haute disponibilité actif/passif) sous Linux

• HAProxy (répartiteur de charge actif/actif L4/L7)

Les solutions mentionnées ci-dessous sont commerciales, nous ne pouvons pas les recommander, mais elles doivent être mentionnées :

• Citrix

• Kemp

• F5

• Tout autre répartiteur de charge matériel (par exemple CISCO)

La configuration de DS en mode haute disponibilité complète ne relève pas du périmètre de l’équipe de support de DS et doit être effectuée par les clients eux-mêmes en fonction de leurs propres décisions.

Par défaut, DataSunrise propose les techniques de haute disponibilité suivantes :

• Plusieurs nœuds DS peuvent fonctionner sur une base de données de configuration unique, réduisant ainsi la nécessité de configurer chaque nœud séparément (les paramètres sont extraits d’un dictionnaire partagé)

• En cas de perte de connexion au dictionnaire principal, utilisez une sauvegarde du dictionnaire système en tant que base de données de configuration de réserve. DS vérifie périodiquement si la connexion au dictionnaire est rétablie et revient à la normale lorsqu’elle est disponible.

• Si une base de données de stockage d’audit devient indisponible, DataSunrise peut écrire les données auditées dans des fichiers plats stockés localement et les transférer dans la base de données de stockage d’audit dès que DS détecte que la connectivité est rétablie.

Non, nous n’avons aucune recommandation concernant le renforcement de la sécurité des applications supplémentaires (points de terminaison de proxy/console de gestion).

En général, cela dépend des exigences spécifiques de l’environnement/le client pour les applications déployées sur son site.

DataSunrise offre une gamme variée de paramètres supplémentaires pour le renforcement/l’optimisation des performances. Ceux-ci sont entièrement facultatifs et doivent être discutés pour être configurés individuellement pour chaque cas.

Néanmoins, les valeurs par défaut pour la majorité des paramètres de DataSunrise ont été configurées pour être optimales dans la plupart des cas.

En termes d’architecture de processus, une instance de DataSunrise se compose d’un seul AppBackendService (ou Backend, BE pour faire court) et de zéro à plusieurs processus AppFirewallCore (ou Core pour faire court).

Le backend est une entité qui gère la configuration de DS et exécute différentes tâches utilitaires (génération de rapports, mise à jour des métadonnées, envoi d’alertes SMTP, exécution de la découverte des données, etc.)

Le Core traite le trafic reçu du Proxy/Sniffer/Trailing/Agent (TBA) et effectue l’audit, le masquage et le blocage.

La RAM consommée par un Core est déterminée par le volume des métadonnées (tables et détails de leurs colonnes, vues, packages (Oracle), procédures, fonctions, synonymes) de la base de données cible pour laquelle ce Proxy/Sniffer/Trailing/Agent est configuré : les métadonnées sont chargées dans le cache.

En outre, le Core de DataSunrise met également en cache les requêtes SQL reconnues dans le trafic en cours pour accélérer la vitesse de traitement.

La consommation de mémoire du Core augmente également si le serveur de base de données d’audit n’est pas en mesure de traiter les événements à temps : DataSunrise envoie les événements traités au stockage d’audit via une file d’attente interne. Le traitement se fait presque immédiatement, mais si la base de données d’audit n’est pas capable de traiter les événements à temps, les événements peuvent s’accumuler du côté du serveur DS et provoquer une consommation accrue de RAM qui disparaît au fur et à mesure que les événements sont envoyés au stockage d’audit.

Enfin, de la mémoire est réservée pour les tampons d’analyse de protocole et pour chaque connexion proxy.

Ensuite, DataSunrise rend compte de la consommation de mémoire virtuelle.

La mémoire virtuelle ne correspond pas 1:1 ou à tout autre ratio à la mémoire physique (RAM).

Cela signifie qu’une consommation élevée de mémoire virtuelle ne peut pas provoquer un crash de l’hôte DS en raison d’une faible mémoire.

DataSunrise utilise la mémoire virtuelle pour surveiller l’allocation de mémoire virtuelle pour les objets runtime que DS génère lors de son fonctionnement. Nous utilisons cette métrique pour surveiller le fonctionnement du service DataSunrise sur un hôte et, en cas de dépassement du seuil interne de consommation de mémoire, les processus peuvent être redémarrés automatiquement.

Veuillez vous référer aux paramètres supplémentaires MaxCoreMemoryForTerminate ou MaxBackendMemoryForTerminate pour connaître le seuil ultime (en unités de mémoire virtuelle) dont le dépassement force automatiquement l’arrêt du processus de Core ou Backend de DS.

Par conséquent, des pics de mémoire sont acceptables, en particulier lorsque vous utilisez des configurations matérielles moyennes.

Il est surtout important de noter que si la consommation de mémoire diminue avec le temps, il n’y a rien dont il faille s’inquiéter.

Cependant, si la consommation de mémoire virtuelle reste élevée après une période d’activité intensive, il peut y avoir des fuites de mémoire ou d’autres aspects à explorer.

Dans ce cas, il est important de partager les fichiers journaux de l’environnement problématique à l’aide du bouton Tout télécharger.

Vous pouvez le faire dans Paramètres du système -> Journaux et logs -> Onglet Journaux -> Pour chaque serveur disponible dans la liste déroulante “Télécharger tout”.

NB : Cela se traduit par le téléchargement d’une archive de fichiers journaux (ZIP) sur votre poste de travail, il est donc possible que vous deviez autoriser les pop-ups pour cette opération.

Si possible, il est recommandé de partager les moyens de reproduire la consommation de mémoire persistante. S’il y a des règles configurées, il est important de fournir les captures d’écran des paramètres de vos règles. La meilleure option est d’utiliser l’option de sauvegarde du dictionnaire dans Paramètres du système -> Général. Notez qu’un fichier de sauvegarde peut être volumineux.

DataSunrise peut fonctionner sur tout matériel de base. Aucune exigence matérielle particulière. Si DataSunrise doit être utilisé en production, nous suggérons des spécifications comme celles-ci :

• Processeur : 8 cœurs

• RAM : 8-16GB est suffisant

• Aucune exigence de stockage particulière

• Espace disque disponible : 100 GB pour l’audit des données

• Système d’exploitation : Linux 64 bits (Red Hat Enterprise Linux 7+, Debian 10+, Ubuntu 18.04 LTS+, Amazon Linux 2) ou Windows Server 2019+ 64 bits

DataSunrise prend en charge les répartiteurs de charge. Par exemple, nous supportons le Classic Load Balancer sur AWS. Vous pouvez également utiliser un certain répartiteur de charge lors du déploiement de DataSunrise sur site dans une configuration HA. DataSunrise prend en charge divers types de répartiteurs de charge. Par exemple, DataSunrise prend en charge une application basée sur AWS en étant entièrement intégré avec AWS Classic Load Balancer. De plus, DataSunrise peut être configuré pour utiliser un certain répartiteur de charge comme HAProxy, etc. Note : DataSunrise prend en charge les répartiteurs de charge uniquement lorsqu’il fonctionne en mode HA.