Dans ce deuxième chapitre, nous allons faire un zoom sur certaines techniques de défense que nous avons évoquées à la fin du chapitre précédent dans notre schéma. Ainsi, nous allons discuter de l’authentification, du contrôle d’accès et de l’audit.
L'authentification
À quoi sert l'authentification ?
L’authentification sert à s’assurer que la personne qui se connecte sur le système d’information est bien une personne donnée. Par la suite, cette personne aura des droits en lecture ou en écriture sur les données. Ces droits vont dépendre des règles de contrôle d’accès. La problématique de l’authentification est de savoir si la personne qui se connecte est bien la personne qu’elle prétend être.
Comment fonctionne l'authentification ?
Comment va fonctionner l’authentification, c’est-à-dire comment peut-on identifier une personne ? Il existe trois méthodes permettant d’identifier une personne.
La première méthode consiste à regarder ce que la personne possède. C’est ce qu’il se passe lorsque vous arrivez devant un coffre-fort à la banque : si vous avez la clé de ce coffre, vous réussissez à l’ouvrir. Pour cet exemple, il n’y a pas véritablement d’authentification car lorsque vous êtes dans la salle des coffres, si vous ne possédez pas de clé, vous ne pouvez pas ouvrir le coffre en question. Dans le monde informatique, il existe le "token matériel" ou le "token physique" : cela peut être, par exemple, une sorte de carte à puces ou bien un dispositif que vous pouvez brancher sur votre ordinateur et qui va vous authentifier.

Le deuxième point est l'authentification à l’aide d’une information que vous connaissez. C’est la technique classique du mot de passe ou de la question secrète : on vous demande quel est votre mot de passe ou bien on vous pose une question, vous répondez, et si vous avez la bonne réponse, alors on va estimer qu’effectivement vous êtes bien la personne que vous prétendez être. En effet, en général, ce mot de passe et cette question vont être associés à un login, donc à un individu du système d’information.

Enfin, le troisième point est l'authentification avec ce que vous êtes : nous parlons ici de biométrie. Vous pouvez vous authentifier à l’aide d’une empreinte digitale, d’une empreinte rétinienne, etc.

On voit que sécuriser l’authentification est crucial. Il faut, en particulier, que les mots de passe utilisés ou choisis qui sont associés à un login soient sûrs et changés souvent. En effet, il y a énormément d’attaques et beaucoup de bases de données contiennent des informations sur des mots de passe. Lorsqu’un système se fait attaquer, les pirates récupèrent une grosse base de données de mots de passe qu’ils peuvent réutiliser.
Dès lors que vous attaquez un système, c'est beaucoup plus simple et beaucoup plus rapide de tester des mots de passe qui ont déjà été utilisés une fois, plutôt que d’essayer d’en inventer. C'est la raison pour laquelle il est demandé à ce que les mots de passe soient changés souvent : il existe un risque que le mot de passe, qui est secret, se retrouve en clair dans la nature.
Sur l’iPhone, l’authentification biométrique est plutôt utilisée comme une authentification plus rapide par rapport à l'action de taper un mot de passe. Éventuellement, elle est aussi plus discrète, puisque lorsque vous tapez votre mot de passe, il est possible qu'une personne se trouvant à côté de vous puisse essayer d’entrapercevoir le code que vous êtes en train de taper.
Comme écrit précédemment, vous pouvez vous authentifier avec quelque chose que vous possédez, comme le "token" ou encore le téléphone. Prenons pour exemple les modèles de paiement en ligne des banques comme le "3D Secure" qui est très souvent utilisé pour s’assurer que vous êtes bien la personne propriétaire du compte en banque. Un code à rentrer sur un site web vous est ainsi envoyé sur votre téléphone.
Notez que l’on parle d’authentification "forte" lorsqu’un système est protégé par au moins deux moyens d’authentification différents comme, par exemple, un mot de passe et de la biométrie. Pour l'iPhone, ce n’est pas une authentification "forte", puisque c’est mot de passe ou biométrie. Très souvent, mot de passe et dispositif physique sont combinés. C’est le cas de la carte bancaire où, pour effectuer un paiement, vous devez être en possession de la carte et vous devez connaître en plus le code PIN à taper pour autoriser un paiement.
Contrôle d'accès
À quoi sert le contrôle d'accès ?
Une fois qu’un individu est authentifié par le système, donc identifié, le contrôle d’accès va indiquer ce que cette personne peut faire : lire ou accéder à certaines données, modifier des données existantes, effacer des données ou encore créer de nouvelles données.
Comment fonctionne le contrôle d'accès ?
Il existe de nombreux modèles de contrôle d’accès :
le contrôle d’accès obligatoire (MAC, en anglais) ;
le contrôle d’accès discrétionnaire (DAC) ;
le contrôle d’accès basé sur les rôles (RBAC) ;
le contrôle d’accès basé sur les attributs (ABAC).
Le contrôle d’accès définit pour chaque utilisateur et pour chaque objet de la base de données ce que l'utilisateur a le droit de faire. L'objet de la base de données peut être au niveau de l’enregistrement, au niveau de la table, au niveau de la vue ou encore au niveau d’une requête. Ainsi, pour chaque couple utilisateur et objet, vous allez avoir la possibilité de lire l’objet ou bien d’écrire, c’est-à-dire modifier l'objet. Ici, la granularité varie selon l'utilisateur : par exemple, sur une table, vous pourrez peut-être lire certains attributs et pas d’autres, ou bien écrire certains attributs et pas d’autres.
Les modalités précises dépendent du modèle de contrôle d’accès considéré.
Le modèle DAC est peut-être le plus simple : il permet aux utilisateurs de transférer leurs droits à d’autres, en estimant que chaque utilisateur va créer ses propres informations. Ainsi, par exemple, vous stockez un fichier sur un SGBD et vous autorisez d’autres utilisateurs à lire ou modifier ce fichier. Ce type de contrôle d’accès est par exemple utilisé sur Dropbox et d'autres systèmes de stockage de fichiers en ligne.
À l’inverse, le modèle MAC définit une structure extrêmement rigide d’accès, ou non, à certaines données, selon des critères d’accréditation. Chaque donnée va être qualifiée par un critère d’accréditation, par exemple "confidentiel", "top secret", "secret défense", et les utilisateurs eux-mêmes vont avoir des droits. Selon les droits des utilisateurs, donc selon leur niveau d’accréditation, ils pourront accéder ou non à certaines données.
Le modèle RBAC (le modèle de contrôle d’accès basé sur les rôles) est celui qui est le plus souvent utilisé dans les SGBD. C’est un système qui simplifie l’utilisation du contrôle d’accès par la création de rôles qui sont ensuite associés à des utilisateurs. Ainsi, un rôle va avoir le droit d’effectuer un certain nombre d’actions sur les objets d’un SGBD, et chaque utilisateur va être associé à un ou plusieurs rôles qu’il pourra ensuite activer.
L'audit
À quoi sert l'audit ?
L’audit des opérations sur une base de données permet de connaître toutes les opérations qui ont été effectuées par les utilisateurs et les administrateurs. Il permet de mettre en évidence des comportements "louches" d’utilisateurs, en regardant s'ils ont accédé à des données auxquelles normalement ils n’ont pas accès. Prenons l'exemple d'un accès non autorisé à des fichiers de police par des personnes ne travaillant pas sur une enquête en cours, et qui souhaitent obtenir des informations sur des individus.
Comment fonctionne l'audit ?
Il y a une séparation entre les droits de l’administrateur de la base de données, qui peut effectuer n’importe quel type d’opération sur les tables métier de la base, et les droits de l’administrateur système. En effet, l’audit stocke automatiquement toutes les informations de la base dans un fichier auquel l’administrateur du SGBD n’a pas accès. En revanche, l’administrateur du système lui-même, donc l’administrateur du système d’exploitation, peut avoir accès à ces informations, à ce fichier de logs qu'il peut éventuellement modifier.
Dans les fichiers de logs, il est donc possible de conserver toutes les traces des accès ou des modifications des données. Cela peut être utile pour essayer de comprendre pourquoi une erreur s’est produite. Dans tous ces accès, des informations sont également stockées. Une question se pose alors : qui a le droit d’avoir accès à ces informations de logs ? En général, cet accès va être extrêmement restreint. L’accès aux logs est uniquement exploité en cas d’accidents, par exemple dans le cas d'une panne ou d'une attaque pour essayer de reconstituer l’ensemble des événements qui se sont produits.
Security by Design
Comment appliquer ces concepts ?
Concluons ce chapitre par une question : comment appliquer les différents concepts dont nous avons discuté dans les deux premiers chapitres ?
Pour cela, c’est le concept de la sécurité et de la confidentialité "by design", c’est-à-dire par conception, qui est mobilisé. Il s’agit de prendre en compte la sécurité et la confidentialité au moment où vous concevez votre système. En effet, une bonne sécurité et une bonne confidentialité des données doivent se prévoir à l’avance. Il est en réalité beaucoup plus difficile et compliqué de rajouter après coup tous ces éléments. Imaginez que vous vouliez rajouter après coup une question de contrôle d’accès, que vous ayez mal structuré vos tables ou encore que vous n’ayez pas réfléchi à la manière d’organiser vos vues.
Dans ces cas, il vous faudra peut-être réorganiser l’ensemble de votre base de données. Aussi, il est beaucoup plus compliqué de prouver que la sécurité du système est atteinte lorsqu’on rajoute des couches de sécurité après, plutôt qu'au moment où on a "designé" le système. C'est pourquoi, dès lors que vous réalisez des systèmes autour d'objets connectés qui utilisent et exploitent des données personnelles, il est très important qu'au moment où vous concevez votre système, vous preniez en compte tous les éléments liés à la sécurité et à la confidentialité des informations.