|
Mise en place d'un système d'information sous Oracle basé sur une architecture trois tiers( Télécharger le fichier original )par Saher Tegane Université El-Hadj Lakhdar - BATNA - Ingénieur d’Etat en Informatique 2008 |
CHAPITRE 7
2.1 L'authentification des utilisateurs Dans les architectures à deux niveaux où les utilisateurs connectent directement au serveur, la base de donnée authentifiée les utilisateurs lors de la connexion et leur associée le nécessaire pour ses travails. Typiquement, dans les architectures trois tiers, l'intermédiaire est le responsable de l'authentification des utilisateurs, et de plus il traite les données envoyées par les utilisateurs avant de les transmis vers le serveur de base données. Un seul intermédiaire est commun entre les utilisateurs et la base de données (un seul point d'entrée), pour cette raison la base de donnée délègue l'authentification des utilisateurs à l'intermédiaire, dans ce niveau la réalisation d'une authentification est plus compliquée que l'architecture deux tiers. 2.2 Le contrôle d'accès des utilisateurs Une fois que l'utilisateur est authentifié par l'intermédiaire, le système doit contrôler quelles données, applications et ressources l'utilisateur peut accédera dans le système. Les données ne doivent pas être protéger seulement contre les intrusions mais aussi les accès des utilisateurs ayant des limites qui doivent être respecté. A l'incrémentation des besoins des entreprises, oracle a défini initialement deux méthodes pour protéger l'accès au niveau des lignes des tables, qui sont basées sur les vues pour la première et les procédures pour la deuxième, mais elles étaient non praticables pour un non petit nombre des utilisateurs. Pour contrôler l'accès il faut d'abord renforcer comment les utilisateurs fait accès. La sécurité typique dans les systèmes trois tiers, exige que chaque utilisateur soit limité par l'exécution des applications spécifiques sur l'intermédiaire, dépendant sur l'identité de l'utilisateur et le rôle lui accorder dans l'organisation. Un utilisateur qui accède à partir d'un intermédiaire ne doit pas avoir la permission d'accéder directement à la base de données. 2.3 La protection des données de l'utilisateur Le changement des données entre les trois tiers doit être protéger contre les révélation et les modification non attendis, le cryptage est le mécanisme standard pour ce but. Le SSL (Secure Sockets Layer) est le protocole qui assurer le cryptage et la communication confidentielle dans le réseau entre le client et l'intermédiaire aussi qu'entre l'intermédiaire et la base de données. 2.4 L'audit des accès de l'utilisateur L'audit des accès est nécessaire pour déterminer l'utilisateur responsable de telle action dans la base de données, et comme les utilisateurs accèdent à partir d'un intermédiaire, il est difficile à un système audit de garder la trace et de corréler les activités qui peuvent être sensitives à la sécurité. 2.5 Limitation du privilège de l'intermédiaire : Puisque le mécanisme d'authentification de l'intermédiaire est moins fort que celui de la base de données et que l'intermédiaire situé en d'hors de la zone protégée par le firewall en face des intrusions interviennes de l'Internet, la base de données doit limiter les privilèges d'un intermédiaire, et de le permis d'accéder au nom des utilisateurs spécifiques.
Figure 1 : La sécurité du système trois tiers. 2.6 La base privée virtuelle (Virtual Private Database ou VPD) A l'incrémentation des besoins des organisations et des
entreprises, la base privée création d'une politique de sécurité -au niveau de la base de données- commun entre toutes les applications, ce qui permet au chaque utilisateur d'accéder seulement à ces données, et quelque soit la manière de la quelle l'utilisateur accède à la base il ne peut pas dépasser cette politique de sécurité.
Figure 2 : les utilisateurs voir seul leurs données. 2.7 Le répertoire Internet d'oracle (OID Oracle Internet Directory) L'OID utilisant LDAP (Lightweight Directory Access Protocol) est le meilleur mécanisme pour le but de centraliser les données communes entre différentes parties d'une entreprise tel que les identités des utilisateurs, en vue de faciliter la gestion, et d'éviter la redondance et l'inconsistance des données. Les privilèges et les informations du contrôle d'accès sont les informations les plus supportées pour être stocker dans un OID. Les administrateurs du système sont les seuls qui ont le droit de modifier les informations d'un OID. L'OID avec le schéma partagé construirent une bonne solution pour les grandes entreprises qui utilisent plusieurs bases de données. 2.8 Les schémas partagés Les schémas partagés permettent à la base de données de déléguer la gestion des identités des utilisateurs, tel que les privilèges, à un OID. Par exemple dans une entreprise qui comporte un nombre de 500 utilisateur qui veulent accèdent aux données des plusieurs bases, au lieu de maintient 500 schéma dans chaque base, oracle permet aux administrateurs de créer un seul schémas commun, avec les privilège approprier dans chaque base de données, et de créer les 500 utilisateur dans un OID, Quand ils connectent à une base spécifique, les utilisateur sont dirigés vers le schémas commun, et ils obtient les rôles qui les associés dans l'OID. 2.9 Signature unique « Single Sign On » Les utilisateurs ont accès avec un mot de passe unique à l'ensemble des applications qu'il s'agisse d'applications Oracle ou non (Yahoo, LeMonde.fr, ...) via des mécanismes de signature unique de Single Sign On (SSO). L'utilisateur s'authentifie en toute sécurité auprès de multiples applications en une seule séquence. La vérification de son identité est valide pour la durée de la session utilisateur, et pour chaque application participant à l'infrastructure d'authentification.
3. La solution appliquée Dans les architecture trois tiers où le dernier niveau est un navigateur web accède via un réseau Intranet ou Internet, la sécurité est une condition très importante pour le bon fonctionnement du système, et puisque le réseau Internet est publique le chalenge de construire un système fiable augmente, c'est le cas de notre projet. La sécurité en oracle nécessite une administration au niveau base de donnée et autre au niveau serveur d'application (security administrator) mais le développeur aussi a un grand devoir ce qui concerne la sécurité de ses applications. 3.1 L'authentification Les utilisateurs accèdent à notre système via l'intermédiaire (le serveur d'application) où réside la logique applicative, dans ce cas la base de données délègue l'authentification des utilisateurs à l'intermédiaire, si le client est un utilisateur de la base données le serveur d'application contrôle les droit d'accès à l'application demandé, s'ils sont bien confirmées, le serveur d'application connecte à la base de données au nom de l'utilisateur (c'est un Proxy). Dans ce cas les utilisateurs sont connu par la base de donnée; et peuvent être stockées dans la base de données lui même ou bien dans un Répertoire Internet d'oracle (OID). L'utilisation d'un OID est la meilleure solution, car le OID centralise ces identités entre plusieurs bases des données ce qui empêche la redondance et l'incohérence des données. Jusqu'au cette moment d'écriture de ce document, la solution précédente reste typique pour nous mais sans réalisation à cause d'un manque matériel et un manque de temps pour fini ce modeste travail. Et pour que ne laisse pas les mains croisées devant ces contraintes, on a reculé vers une autre solution assurée par les applications en profitant de la richesse du langage PL/SQL et l'outil Forms. 3.2 Le contrôle d'accès Les trois éléments de l'université sont restrictifs dans ses accès en deux niveaux : Premièrement au niveau des applications, l'étudiant ne doit pas pouvoir utilisé une application d'enseignant ni d'administration, aussi le cas pour l'enseignant " il ne doit pas pouvoir utilisé une application d'administration ni d'étudiant " et le cas pour l'administration. Typiquement cette tache est sur le compte du serveur d'application oracle, jusqu'à maintenant elle est assurée par un contrôle juste après l'authentification de l'utilisateur. Le Deuxièmes c'est au niveau des données, chaque élément de l'université ne peut voir que ses données personnelles, malgré que touts les étudiants accède aux mêmes tables par le même rôle, et aussi le cas pour les enseignants et les administrateurs. On est devant la notion de la base de donnée privée virtuelle. Comme on a déjà expliqué, le VPD (fine-grained access control) contrôle l'accès au niveau des lignes de la table, et on a bien adapté cette solution pour notre base de données. L'application est un moyen fort de la sécurité des données, donc il est interdit qu'un utilisateur accède à la base de données d'une manière direct, c'est-à-dire sans passé par l'application. La seule solution qui existe, et qu'on a réalisée c'est l'utilisation des rôles. Pour qu'un utilisateur peut accéder au données il faut qu'il possède des privilèges lui offerts via un rôle, ce rôle ne doit pas activer si et seulement si l'utilisateur connecte via un Proxy (le serveur d'application). Pour éviter des catastrophes en cas d'intrusion, les privilèges donnés aux utilisateurs via les rôles sont très limités que possible. Pour construire un système dans un environnement Internet, il est très difficile de le doter par un mécanisme de sécurité fiable et solide. Oracle fournit plusieurs méthodes pour garantir une haute sécurité couvert toutes les aspects du système, mais ça dépend de l'expérience du développeur et de l'administrateur du système. 4. Recommandations pour sécuriser Oracle La sécurisation parfaite d'un système Oracle n'est pas une tâche simple. Cependant Il est possible d'améliorer très nettement la sécurité d'Oracle en appliquant quelques recommandations. Certaines de ces recommandations relèvent du bon sens, mais la réalité montre qu'il n'est jamais inutile de les rappeler, surtout dans un domaine aussi complexe que les systèmes Oracle :
4. Conclusion
D'après ce qu'on a fait, on peut limiter les aspects de la sécurité postulée dans ce qui suit : Une meilleure méthode d'authentification. Le cryptage des données les plus sensibles pendant la transmission. La sécurité doit prend sa place dans chaque niveau. Le contrôle d'accès au niveau des applications. Le contrôle d'accès au niveau de la base de données.
|
|
