Cours sécurité dans les bases de données, tutoriel & guide de travaux pratiques en pdf.

Sécurité

Bien que la sécurité soit l’une des raisons de l’architecture trois couches, plusieurs challenges praticables sont enlevés lors de la construction du système tel que l’authentification des utilisateurs, le contrôle des accès et Audit les actions des utilisateurs, la protection des données entre les couches, la limitation des privilèges de l’intermédiaire, et la construction des systèmes extensibles.

Propriétés principales

La sécurité des bases de données inclus trois principales propriétés : la confidentialité, l’intégrité et la disponibilité.
• Confidentialité : L’information protégée ne doit pas être accessible aux utilisateurs ou un programme non autorisés. C’est crucial:
 Dans des environnements critiques ou stratégiques: militaires ou commerciaux, par exemple.
 Pour respecter le droit des individus à décider comment et dans quel but les informations les concernant peuvent être extraites, mémorisées ou transmises à d’autres individus.
• Intégrité : Les données ne peuvent être modifiées que par les utilisateurs habilités à le faire qu’elles soient dues à :
 Des pannes de système,
 Des manipulations erronées,
 Des sabotages.
• Disponibilité : Il s’agit de détecter ou d’empêcher des dénis de service.
Il y a déni de service lorsqu’un utilisateur ne parvient pas à accéder dans un délai raisonnable, à une information ou à une ressource pour laquelle il a une autorisation d’accès.

Processeur de sécurité

Figure II.1: Processeur de sécurité.
Autorisation, interdiction et obligation :
• Les règlements les plus simples ne contiennent que des autorisations: ce qui n’est pas autorisé est interdit.
• Certains règlements incluent des interdictions à fin de spécifier des exceptions à des permissions générales. Exemple: les patients ont droit de consulter leur dossier médical sauf Jean Dupont.
• D’autres enfin, plus sophistiqués, incluent des obligations: difficiles à implanter dans les systèmes informatiques.

Attaque

• Les violations de la sécurité d’une BD consistent en des lectures ou des mises à jour illicites.
• Les événements qui portent ces violations sont appelés des attaques.
Les attaques à une BD peuvent exploiter les failles des applications opérant sur cette BD:
 Stockage des mots de passe dans les fichiers de configuration de l’application,
 Scripts de connexion à la BD accessibles dans le code source de l’application,
 Attaques par injection SQL,
 Attaques exploitant les débordements de tampons.

Types d’attaques

On distingue:
• Les attaques non frauduleuses:
 Catastrophes naturelles,
 Pannes de logiciel ou de matériel,
 Erreurs humaines…
• Les attaques frauduleuses:
 Utilisation abusive de leurs droits par les utilisateurs,
 Agents hostiles exécutant des actions de destruction du logiciel ou du matériel, ou lisant ou mettant à jour des données protégées,
 Ces agents peuvent être cachés dans des actions légales : chevaux de Troie.

Qui attaque?

Dans cette partie on présente les différents attaquants :
• Pirate externe : il est capable de s’infiltrer sur le serveur BD et de lire ses fichiers, il peut aussi casser une clé de chiffrement avec un texte connu.
• Pirate utilisateur : ce type de pirate est reconnu par le SGBD et à accès à une partie des données suivant le mode de chiffrement, il a accès à certaines clés.
• Pirate administrateur (DBA) : employé peu scrupuleux ou pirate s’étant octroyé ces droits ; A accès à des données inaccessibles aux autres pirates (journal) et aussi peut espionner le SGBD pendant l’exécution.
Figure II.2: Différents attaquants.

Les risques encourus

Les risques propres à une source de données sont les suivants :
Le vol de données induit la perte de confidentialité des données stockées. La divulgation de données financières hautement confidentielles peut avoir un impact néfaste sur l’activité d’une entreprise : risque juridique, atteinte à l’image de marque, perte de confiance des partenaires industriels…
L’altération de données induit une perte d’intégrité, c’est-à-dire que les données ne sont plus dignes de confiance. En fonction de la rapidité de détection et de la qualité des sauvegardes, les conséquences peuvent en être réduites. Mais une application fonctionnant sur des données falsifiées peut voir son comportement fortement influencé : par exemple, un site de commerce électronique pourrait débiter le compte d’un autre client que celui réalisant la commande !
La destruction de données remet sérieusement en cause la continuité de l’activité de l’entreprise concernée. Privée de ses données clients, sans sauvegarde, c’est le dépôt de bilan garanti !
L’augmentation du niveau de privilèges d’un utilisateur d’une application est plus insidieuse que les risques précédents, car comme pour l’altération de données, il n’est remarqué qu’après un certain laps de temps durant lequel le pirate peut réaliser un grand nombre d’actions malveillantes. Il peut ainsi s’attribuer le droit d’accès à des informations confidentielles, le droit d’accès à des opérations sensibles, voire même prendre le contrôle d’une application.
Selon le SGBD utilisé, des ressources systèmes peuvent être attribuées à chaque utilisateur (nombre de requêtes par unité de temps…). Ces ressources peuvent être limitées par l’administrateur système afin d’éviter l’écroulement des capacités de traitement du serveur (déni de service) par un utilisateur malveillant. De plus, ceci permet de limiter la portée d’une attaque par altération ou vol de données en limitant le nombre d’opérations réalisables en un temps donné. La conséquence d’un tel risque peut être la paralysie du serveur (perte de disponibilité).
On le voit, les risques sont variés et leurs conséquences potentiellement dramatiques. Ainsi, il est nécessaire d’attribuer les droits d’accès avec parcimonie.

Les types d’utilisateurs

Il faut identifier les utilisateurs ayant besoin d’un accès à la base de données, ils peuvent être de différents types :
L’administrateur est une personne physique ayant tous les droits sur le SGBD, mais pas forcément sur le contenu des bases de données : il peut réaliser des opérations de gestion des droits d’accès et des ressources systèmes mais on pourra choisir d’exclure ou non les droits d’accès en lecture et/ou écriture au contenu des bases de données. Bien que parfaitement logique d’un point de vu métier, pour la protection de données sensibles par exemple, retirer à un administrateur les droits de lecture et d’écriture sur le contenu d’une base de données n’a pas de sens d’un point de vu technique puisqu’il possède les capacités techniques de s’octroyer ses droits là. De plus, les opérations de sauvegarde, de restauration et de maintenance après incident peuvent l’amener à devoir accéder au contenu d’une base de données.
Bref, normalement, c’est l’utilisateur qui a tous les droits sur le SGBD et les bases de données hébergées. C’est normalement une personne de confiance, compétente et prudente.
Une application peut être une application web, un outil de synchronisation entre sources d’informations ou tout programme accédant pour lui-même à la base de données. Ce type d’utilisateur logique n’a rien à voir avec l’utilisateur réel dénotant une personne physique ayant des besoins particuliers. Même si une application est utilisée par des personnes physiques, on pourra choisir de déléguer à l’application la gestion des droits d’accès à l’information en fonction des habilitations qu’elle décide de lui attribuer. Ainsi, une application peut être vue comme un utilisateur de base de données auquel on attribue des droits qu’elle pourra restreindre de façon transparente pour l’utilisateur final de l’application ainsi que pour le SGBD.
L’utilisateur est une personne physique se connectant directement à la base de données (commande mysql sous Linux) ou via une interface graphique (script phpMyAdmin sur un Intranet) ou utilisant une application qui va se connecter à la base de données sous l’identité de l’utilisateur (client lourd MySQL Query Browser).