Les mécanismes mis en oeuvre pour la sécurité

Sécurité des systèmes et des SGBDs
La sécurité n’est pas seulement la confidentialité. De nombreux autres concepts sont
impliqués dans la gestion de la sécurité. Ils sont souvent applicables autant aux OS qu’aux
SGBDs, ces deux domaines étant extrêmement proches.
 confidentialité
Tout ne doit pas être accessible à tout le monde. En effet, se connecter à l'OS ou à la
base de données donne un certain nombre de droits et de ressources en fonction d’un
profil défini et maintenu par un administrateur. La granularité d’accès peut aller
jusqu’à la vision unique d’un champ d’un enregistrement d’une table particulière.
 disponibilité
C’est la faculté de délivrer correctement un service en terme de délai et de qualité à
l'utilisateur. Se mesure en pourcentage du temps de fonctionnement total.
 fiabilité
Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale,
partielle, incrémentale), ainsi que des mécanismes de journalisation, et de reprise
permettent de restaurer une information sans pratiquement aucune perte, dans tous les
cas de problème matériel ou logiciel.
 intégrité
Que les données soient réparties ou non (dans ce dernier cas les mécanismes mis en
jeux seront plus complexes) elles doivent être cohérentes. Cela sous entend, d’une part
que les accès concurrents d’utilisateurs, notamment lors de mises à jour, ne doivent
pas compromettre la cohérence des données et d’autre part que ces dernières
satisfassent aux contraintes d’intégrité du modèle, et / ou aux règles de gestion de
l’entreprise.
 tracabilité
En cas de problème important ou d’attaque du système, on peut recourir à l’analyse de
traces ou de logs (journaux). Le niveau de détail de ces traces est paramétrable, et
concerne soit les aspects système, soit réseaux, soit l’accès aux données élémentaires
elles-mêmes.
 maintenabilité
C’est l’aptitude à la réparation, l’évolution, la maintenance du système. Mesuré en
temps de reprise après panne (Mean Time To Recover)
Les mécanismes mis en oeuvre pour la sécurité
Les SGBDs fournissent un certain nombre de mécanismes internes ou de fonctionnalités
assurant un niveau satisfaisant de sécurité.
 L'authentification, est le processus qui permet de vérifier qu'un utilisateur réclamant
un accès est bien celui qu'il prétend être, ou plus simplement le processus qui contrôle
l'identité de l'utilisateur. Cette action (login) se fait en général via la fourniture du
couple nom d'utilisateur / mot de passe.
Dans certains cas l'authentification peut être implicite et héritée d'une authentification
précédente, ou reconnue automatiquement (@IP du user sur le réseau par exemple),
bien que simplifiant les accès ce choix peut évidemment s'avérer dangereux.

La multiplication des couches logicielles et l'inflation d'applications sur les postes
utilisateur fait que ce dernier est fréquemment amené à s'authentifier des dizaines de
fois par jour. La signature unique (Single Sign On ou SSO) est un objectif intéressant
mais difficile à mettre en œuvre.
Il est recommandé d'établir des connexions au serveur avec le protocole SSL, pour
chiffrer les échanges clients/serveur, afin d'améliorer la sécurité. On peut aussi utiliser
un client SSH pour chiffrer la connexion entre les clients et le serveur de bases de
données. Si l'une de ces deux protections est mise en place, il sera difficile de
surveiller votre trafic et de comprendre les informations échangées.
 Les droits et privilèges : une fois correctement identifié l'utilisateur doit pouvoir
accéder aux informations et ressources auxquelles il a droit (et uniquement à celle là)
Ce problème est résolu le plus simplement avec la gestion de droits élémentaires
accordé à un utilisateur, ou plus efficacement avec des rôles et / ou profils affectés à
des groupes d’utilisateurs...
Lors de la création de la base de données, un utilisateur propriétaire en est responsable.
Généralement, seul le propriétaire (et le super utilisateur) peuvent intervenir avec les
tables de cette base, et il faut que ce dernier donne des droits à tous les intervenants
qui auront à travailler sur cette base.
Les applications ne doivent jamais se connecter au serveur de bases de données sous le
nom du propriétaire ou de l'administrateur, car ces utilisateurs ont des droits très
importants, et pourront exécuter n'importe quelle requête, comme la modification de
tables, l'effacement de lignes ou même encore, la destruction de la base.
Il faut créer différents utilisateurs de bases de données pour chaque aspect de
l’application, avec des droits limités aux seules actions planifiées. Il faut alors éviter
que le même utilisateur dispose des droits de plusieurs cas d'utilisation. Cela permet
que si des intrus obtiennent l'accès à la base avec l'un de ces jeux de droits, ils ne
puissent pas affecter toute l'application.
 Les LOGs ou traces : permet d'enregistrer tout ou partie des informations concernant
les accès (réussis ou échoués). Cette trace pourra être plus ou moins détaillée et son
volume étroitement surveillée. De ce fait on l'utilisera de manière ciblée sur des
périodes de temps spécifiques
 tolérance aux pannes : permet par du matériel ou du logiciel redondant (CPUs,
disques, IOs) de supporter de manière partiellement ou complètement transparentes
différents types de pannes, tant au niveau du client, que du réseau, que du serveur. Une
tolérance totale est cependant coûteuse.
 sauvegarde et restauration : permet de sauvegarder les données sur des supports
externes (disques, bandes, etc.) et pouvoir les restituer, le plus à jour possible. Le but
est de ne pas perdre de données suite à un problème matériel (panne disque), logiciel
(bug) ou une fausse manipulation d'un utilisateur.
 mécanismes transactionnels
l'atomicité des transactions, par définition assure la cohérence des données, même
dans des environnements distribués. L'image avant modification, stockée de manière
redondante dans ou hors de la BD, permet de faire d'éventuels retours arrière pour

retrouver le dernier état cohérent, ou de s'assurer qu'il n'y a pas eu d'opérations
partielles ou incomplètes (transaction bancaires par exemple)
Aspect sécurité
mécanisme mis en oeuvre
exemple d'implémentation
au niveau SGBD
confidentialité
 authentification
 indépendance logique
/ physique
 référentiel utilisateur /
mot de passe
 tables de user
applicatifs
 identification externe
 tables / fichiers
 vues (1)
 virtual private
database chez Oracle
 droits et privilèges
 droits d’accès aux
données
 rôles
traçabilité
 logs et traces
 tables d’audit
 log Oracle Net
fiabilité, disponibilité,
maintenabilité
 tolérance de panne
 stand by DB
 cluster logiciels
 sauvegarde et
restauration
 physique : sauvegarde
+ journalisation +
restauration
 logique : export /
import
intégrité
 transaction atomique
 contraintes d'intégrité
 Two Phase Commit
(2PC)
 contraintes 'reference'
 read consistancy
Les principales menaces
Au delà des attaques accidentelles ou les défaillances du système, les attaques 'malveillantes'
nous intéresserons plus particulièrement.
Les menaces les plus connues visent à paralyser, ou détruire tout ou partie du système
d'information. Elles ne ciblent pas particulièrement les SGBDs mais nous les citerons
néanmoins parce qu’un SGBD est hébergé sur une machine pouvant y être vulnérable.
Quelques définitions données par le grand glossaire de la sécurité de ECHU.ORG :
(http://www.echu.org/portail/modules/glossaire/)

 Virus : Au sens large du terme, on qualifie généralement de virus tout programme
capable de se reproduire (techniquement, se recopier) lui-même et d'endommager des
données informatiques. On les classe en plusieurs catégories, principalement: parasite,
compagnon, amorce, multiformes, résident mémoire ou non, furtifs, polymorphes,
réseau et flibustier. Pour plus de détails reportez-vous aux définitions correspondantes.
 Ver (ou Worm) : programme qui peut s'auto-reproduire et se déplacer à travers un
réseau en utilisant les mécanismes réseau, sans avoir réellement besoin d'un support
physique ou logique (disque dur, programme hôte, fichier ...) pour se propager; un ver
est donc un virus réseau.
 Cheval de Troie : (en anglais trojan horse) un programme informatique effectuant des
opérations malicieuses à l'insu de l'utilisateur : vol des mots de passe, copie de
données sensibles, exécution d'action nuisible ...
Un peu moins connus mais plus probables dans le domaine des SGBDs :
 Back doors : ("Portes dérobées") : Programmes usurpateurs qui détournent des
fonctionnalités systèmes dans le but d'ouvrir des accès utiles aux pirates pour contrôler
à distance les machines ciblées (modification des programmes de login avec
user/passwd en dur, ouverture de ports particuliers, etc.). Ces programmes sont la
plupart du temps installés par le biais d'un "cheval de Troie". Parmi les plus
« célèbres », on peut citer BackOrifice (BO) ou encore NetBus.
Les accès illicites via ces backdoors pouvant être facilement détectés par des
commandes système standards (liste des process connectés, des ports ouverts) ils sont
parfois utilisés conjointement avec des rootkits, ensemble de commandes standards
modifiées pour masquer les intrusions.
 Certaines back doors peuvent être inclues dans le code d'applications standards, sans
intention forcément malveillante mais pour réserver au développeur du programme, un
accès 'privé' à toute les machines hébergeant son code. L'accès au code source d'un
logiciel libre peut nous prémunir contre ce genre d'indélicatesse.
 Altération du SQL : L'altération SQL (souvent restreinte à l'injection SQL) est une
technique permettant de récupérer des informations confidentielles de la base de
données, ou simplement des méta données, en outrepassant les droits applicatifs
'normaux'.
Le principes et de modifier indirectement les ordres SQL envoyés au serveur, en y
incluant des chaînes de caractères spéciales en lieu et place des paramètres attendus
par l'applicatif.
 Buffer Overflow : Un buffer overflow (BOF) est littéralement un dépassement de la
capacité d'un buffer de données. Cela arrive fréquemment lorsque l'on programme
sans trop de précautions.
La conséquence est généralement un 'crash' du programme, qui tente un accès à des
zones en dehors de son espace d'adressage.
La saturation ou le crash de serveur n'est généralement pas le but ultime des hackers.
L'acquisition de privilèges ou l'ouverture de backdoor est plus souvent ciblée.
Dans le domaine de la sécurité cette technique du BOF est utilisée pour 'dérouter' la
séquence normale des instructions d'un programme et le forcer à exécuter une routine
spécifique, permettant généralement l'obtention de droits 'super utilisateur'. Cette
routine ou ce programme exploitant la faille est appelée un "exploit" (en Anglais dans
le texte)

Les principales failles de sécurité
 « portes » ouvertes : (pas seulement les 'back doors’)
porte de la salle machine ouverte, poste ou serveur sans mot de passe ou mot de passe
faible, poste sans veille, post it…
Solution : fermer les portes, mettre en oeuvre la gestion de mots de passe
 Installation par défaut :
- les valeurs de paramètres sont connues (port 80 / 1525, mot de passe SYS et
SYSTEM),
- des services superflus sont accessibles (serveur ftp, serveur samba, serveur d'admin,
etc…),
- les communications ne sont pas chiffrées (ftp, telnet, pop)
Solution : se documenter, auditer les serveurs
 mauvaise politique de gestion des droits:
- installation confortable : tous les logiciels sont installés sous root, tous les utilisateurs
de l'applicatif sont DBAs
- allow all implicite... (dans un firewall…)
- utilisation abusive de l'héritage
Solution : maîtriser la gestions des droits des OS / logiciels serveurs / bases de données
 bugs (qui peuvent provoquer un simple déni de service voire l'arrêt du système)
Solution : faire de la veille, patcher régulièrement les applications
 mauvais codage (paramètres en clair dans les URLs, connexion non chiffrées, etc.)
Solution : se documenter (best practices, test des programmes)
 contrôle d'accès au niveau applicatif, qui peut facilement être court circuité
Solution : centraliser (et factoriser) les contrôles au niveau données : contraintes
d'intégrité…
C'est le maillon le plus faible de la chaîne qui cassera immanquablement. On peut mettre en
place un système très complexe, il sera bien inutile si un administrateur est resté 'loggé' root
sur son poste (Statistiquement la majorité des attaques provient de l'intérieur des entreprises)
Cependant, on n'oubliera pas de rester pragmatique. Les besoins et les objectifs doivent être
clairement définis au départ et l'adéquation de la solution vérifiée. Un certains nombres
d'utilitaires libres sont disponibles sur internet pour vérifier la fiabilité d’un système
d'information.
Il faudra de plus trouver un équilibre entre niveau de sécurité satisfaisant et confort (voire
simple possibilité) de travail des autres acteurs.
Sources
ECHU.org : http://www.echu.org/modules/glossaire/index.php