Quitter la lecture facile
Securite-des-bases-de-donnees-les-bonnes-pratiques

Comment sécuriser ses bases de données ?

Posté le par La rédaction

Décryptage

http://www.techniques-ingenieur.fr/actualite/thematique/informatique-et-numerique/

Clé de voûte de beaucoup d'entreprises, les bases de données reposent souvent sur des produits clés en main dont les vulnérabilités sont souvent mal connues des différents services qui les utilisent. Mais comment parvenir à les sécuriser ? Voici quelques conseils à respecter.

En décembre 2001, un événement a fait réagir les acteurs du marché de l’informatique : le scandale Enron et ses conséquences, à savoir la loi Sarbanes Oxley ou les nouvelles règles comptables IAS IFRS. Désormais, les documents financiers doivent être faciles à retrouver et ils ne doivent pas pouvoir être détruits ou corrompus. De fait, la sécurité et la bonne maîtrise du système de gestion de base de données (SGBD) sont devenues indispensables. Car n’oublions pas que celui-ci contient bien souvent toutes les informations financières ou/et de production d’une entreprise. Un problème d’autant plus crucial que beaucoup d’applications dépendent de bases de données qui reposent sur des produit clés en main, et les entreprises ne le savent pas toujours, toutes les vulnérabilités qui vont avec. Mais comment parvenir à sécuriser ses bases de données ? Voici quelques conseils à respecter.

Veiller à la formation des utilisateurs et de l’administrateur
La formation des utilisateurs et leur sensibilisation aux bonnes pratiques est indispensable et la politique de sécurité doit être adaptée en fonction du contexte selon que les utilisateurs ont un accès direct via un client standard SQL ou par l’intermédiaire d’une application frontale. Mais l’administration et la sécurisation des SGBD reste une affaire de spécialiste où l’administrateur a sa part de responsabilité. Son rôle est de maintenir le SGBD sous toutes ses formes, tant au niveau de la création et de la gestion de comptes mais aussi en maintenant la bonne marche ainsi que les performances et l’intégrité du système. Pourtant, il est rarement précisé que son rôle est prépondérant dans la gestion de la sécurité, sauf dans des sociétés travaillant dans le domaine financier/assurance ou de la défense. Il n’a donc souvent aucune conscience de sécurité, est mal préparé dans la plupart des cas et n’a souvent suivi aucune formation en ce sens. Une fois formé, il faut aussi gérer l’aspect documentation. Il faut la créer, la maintenir mais aussi la partager. Souvent, un seul administrateur sur toute une équipe est envoyé en formation pour ensuite transmettre l’information en interne. Malheureusement, cette pratique montre qu’une personne a tendance à centraliser toutes les connaissances. Si celle-ci quitte la société, la connaissance part avec elle. Il est donc primordial que tous les administrateurs soient au même niveau de connaissance grâce à une bonne circulation de l’information.
Détecter et corriger les failles de sécurité les plus courantes
Les failles les plus fréquemment rencontrées sont loin d’être anodines. Les risques peuvent être extrêmement élevés et les dégâts associés importants. Des données, par exemple, peuvent être modifiées, ce qui peut nuire gravement à la stabilité d’une société. Ce point peut se résoudre par une stratégie de sauvegarde et de restauration ou encore DRP ( 1) complète et bien maîtrisée. Mais encore faut-il s’en rendre compte si aucune mesure d’audit n’est mise en place ! Quant aux mises à jour aléatoires, elles peuvent engendrer une détection trop tardive, rendant inutile les sauvegardes effectuées. Plusieurs failles classiques ont été répertoriées depuis les 10 dernières années. Dans l’univers des systèmes de gestion de grandes bases de données, le nom d’Oracle est traditionnellement associé à celui d’une référence. Mais, lorsque l’on parle de sécurité, le résultat n’est pas le même. A ce jour, plus de 250 failles ont été répertoriées chez Oracle, 130 sur MySQL et 80 sur Microsoft SQL Server. Parmi celles-ci, il n’est pas rare de trouver des failles permettant la prise de contrôle à distance du SGBDR par le réseau. Celles-ci doivent obligatoirement être corrigées. En plus des faiblesses découlant d’une mauvaise installation du système d’exploitation, socle du SGBDR, telles des services réseaux à risque ou l’utilisation abusive de privilèges excessifs, il est fréquent de constater que des fichiers du SGBDR sont accessibles à tout compte utilisateur ayant accès à la machine hôte, démontrant que les administrateurs n’ont pas conscience que cela permet de corrompre le SGBDR ou ses données. Il y a aussi toutes les petites faiblesses longtemps cachées par les éditeurs comme les mots de passes codés en dur dans des fichiers systèmes non chiffrés. Les mots de passe sont bien souvent peu ou pas complexes et non modifiés lors d’une première installation du produit. Lors de l’installation d’une base Oracle, plusieurs comptes très sensibles ont des mots de passe génériques comme SYS, SYSTEM ou encore APPS. La mise en place de règles pour vérifier automatiquement la complexité des mots de passe, le blocage des comptes génériques, la fixation d’un nombre défini d’authentifications ratées, l’interdiction de réutiliser un mot de passe déjà utilisé par le passé, ou de mettre un mot de passe sur le module d’écoute de la base de données doit faire partie des règles de base. Nous avons aussi affaire à des failles sur les contrôles d’accès aux données. Il s’agit de n’autoriser l’accès aux données stockées qu’aux personnes autorisées (principe des vues). Ce contrôle doit permettre de distinguer différents modes d’accès, au moins lecture ou écriture, et une granularité variable, par exemple au niveau d’une base, d’une table ou encore d’une colonne. Une bonne politique d’attribution de droits doit être étudiée et validée. De nos jours, les bénéfices de la cybercriminalité ont dépassé ceux de la drogue. Le vol de numéros de cartes bancaires ou encore de données personnelles sont souvent à la une des journaux. Ce qui démontre bien que le SGBD est bien au centre de ces évènements. Protéger une base de données est une tâche simple, mais qui peut s’avérer complexe si on veut le faire de manière exhaustive et sans impacter la stabilité. Mais cette sécurisation passe avant tout par la prise en compte des particularités et des spécificités de la base par les Directions des Systèmes d’Information de l’entreprise.   Ce qu’il faut retenir
  1. La sensibilisation du personnel est une des choses les plus importantes au sein de l’entreprise car les principales erreurs sont souvent d’origines humaines.
  2. Une bonne maîtrise du produit et des formations adaptées permettent aux administrateurs de réduire considérablement les problèmes de sécurité.
  3. L’administration de SGBD reste l’affaire de spécialistes qui doivent obligatoirement suivre l’évolution de leur produit.
  4. La plupart des produits disponibles sur le marché disposent de mécanismes permettant de mettre très simplement en place des règles de sécurité. Il est important d’installer les mises à jour proposées par les éditeurs et de ne pas attendre qu’un problème arrive.
  5. Mettre en place des règles de gestion des mots de passe.

Par Sébastien Berrue

Notes
1 : Le DRP (disaster recovery plan) est le processus prévoyant les mesures à mettre en oeuvre en cas de sinistre informatique et pour s’en prémunir.

Posté le par La rédaction

Imprimer l'article Commenter cet article Partager l'article par email

Les derniers commentaires Commentez
  1. Je voulais masquer mes codes sources après la conception de ma base de données mais aussi je voulais faire que ma base de données soit comme un programme que je peux installer sur n’importe quelle machine

Réagissez à cet article

Commentaire sans connexion

Pour déposer un commentaire en mode invité (sans créer de compte ou sans vous connecter), c’est ici.

Votre adresse de messagerie ne sera pas publiée.

Captcha

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Connectez-vous

Vous avez déjà un compte ?
Connectez-vous et retrouvez plus tard tous vos commentaires dans votre espace personnel.