Aujourd’hui, la plupart des applications Web nécessitent au moins une stratégie de sécurité de base. Par exemple, les sites proposant du contenu protégé par mot de passe, les sites dotés uniquement d'un backend administrateur, les blogs et magazines personnels, les sites de commerce électronique, les intranets d'entreprise, etc.
L'approche de conception la plus courante pour créer ces types d'applications Web consiste à intégrer la politique de sécurité dans la logique métier de l'application Web, où l'application détermine si un utilisateur est autorisé à accéder à certaines données de la base de données. Dans ce scénario, le rôle de la base de données est simplement de stocker les données et de les servir sur demande. En d'autres termes, si une application Web commande à la base de données de fournir des informations spécifiques, la base de données exécute la commande directement sans vérifier les autorisations de l'utilisateur.
Dans cet article, vous apprendrez comment tirer parti des fonctionnalités de sécurité intégrées d'Oracle pour appliquer les règles de sécurité des applications au niveau de la base de données afin d'améliorer la sécurité globale de votre application. Autre avantage secondaire, la sécurisation de l'accès aux données directement dans la base de données améliore non seulement la sécurité des applications, mais contribue également à réduire la complexité.
Qu’en est-ilde la nécessité d’une sécurité côté base de données
pour contrôler l’accès aux données à partir des applications Web ? Dans la plupart des cas, il n'y a pas de problème ; c'est une bonne solution, surtout si les données impliquées ne sont pas critiques ou top secrètes. Cette méthode est utilisée dans de nombreux livres et ressources en ligne. En fait, un ouvrage populaire sur PHP/MySQL déconseille explicitement la création de plusieurs comptes utilisateur de base de données par application, car « des utilisateurs supplémentaires ou des autorisations complexes peuvent nécessiter davantage de vérifications avant de procéder aux informations et ralentir la vitesse d'exécution de MySQL ». C'est vrai ; cependant, il y a quelques éléments que vous voudrez peut-être prendre en compte avant d'abandonner l'idée d'intégrer la sécurité dans la logique de votre base de données. Regardons l'exemple suivant.
Disons que vous créez un système de gestion de contenu (CMS). Une base de données est utilisée pour stocker le contenu publié sur le site Internet. La plupart des données sont publiques, ce qui permet aux internautes anonymes de les lire ; seuls les éditeurs sont autorisés à modifier les données. Utilisez un seul compte de base de données pour accéder et modifier les enregistrements de la base de données, et contrôlez la sécurité avec le code PHP en protégeant par mot de passe l'accès aux pages réservées aux administrateurs.
Si le côté public d'une application Web subit une attaque telle qu'une injection SQL sur un formulaire de recherche public (c'est-à-dire un formulaire qui n'est pas suffisamment codé), l'intrus peut être en mesure d'exécuter des instructions SQL arbitraires sur des objets de base de données que le le compte public a accès. Bien entendu, dans ce cas, l’exécution de l’instruction SELECT ne pose pas de gros problème car les données sont publiques. Mais comme les droits publics et administratifs utilisent le même compte de base de données, l'intrus peut également exécuter des instructions UPDATE et DELETE, voire supprimer des tables de la base de données.
Comment pouvons-nous empêcher que cela se produise ? La méthode la plus simple consiste à restreindre complètement les autorisations du compte de base de données publique pour modifier les données. Voyons comment Oracle résout ce problème.
Présentation de base de la sécurité Oracle
Oracle Database offre aux développeurs Web de nombreuses façons de contrôler l'accès aux données, depuis la gestion de l'accès à des objets de base de données spécifiques tels que les tables, les vues et les procédures jusqu'au contrôle de l'accès aux données dans des lignes ou des colonnes individuelles. Évidemment, une discussion sur chaque fonctionnalité ou option de sécurité disponible avec Oracle dépasse le cadre de cet article. Ici, nous n'entrerons pas dans les détails, mais seulement dans les aspects les plus élémentaires de la sécurité de l'accès aux données Oracle :
· Authentification et comptes d'utilisateurs · Autorisations ·
Authentification des rôles et comptes d'utilisateurs. Comme pour les autres bases de données, chaque utilisateur (compte de base de données) demandant l'accès à Oracle doit être authentifié. La validation peut être effectuée par une base de données, un système d'exploitation ou un service réseau. En plus de l'authentification de base (authentification par mot de passe), Oracle prend également en charge des mécanismes d'authentification forts tels que Kerberos, CyberSafe, RADIUS, etc.
Rôle. Un rôle Oracle est un ensemble nommé d'autorisations. Bien que vous puissiez accorder directement des autorisations aux comptes d'utilisateurs, l'utilisation de rôles peut grandement simplifier la gestion des utilisateurs, en particulier lorsque vous devez gérer un grand nombre d'utilisateurs. Il est très efficace de créer de petits rôles gérables, puis d'accorder aux utilisateurs un ou plusieurs rôles en fonction de leur niveau de sécurité. Sans parler de la simplicité de modification des autorisations : il suffit de modifier le rôle auquel le rôle est associé, plutôt que de modifier chaque compte utilisateur.
Pour simplifier le travail initial de création de nouveaux utilisateurs, Oracle propose trois rôles prédéfinis :
· Rôle CONNECT : ce rôle permet aux utilisateurs de se connecter à la base de données et d'effectuer des opérations de base, telles que la création de leurs propres tables. Par défaut, ce rôle ne peut pas accéder aux tables des autres utilisateurs.
·Rôle RESOURCE : le rôle RESOURCE est similaire au rôle CONNECT, mais il permet aux utilisateurs de disposer de davantage d'autorisations système, telles que la création de déclencheurs ou de procédures stockées.
·Rôle DBA : permet à l'utilisateur de disposer de tous les privilèges système.
Autorisations et autorisations utilisées
Dans cette section, nous expliquons comment utiliser l'autorisation et les autorisations d'Oracle pour améliorer la sécurité de l'exemple simple de CMS évoqué au début de cet article. On suppose que le contenu fourni aux utilisateurs de l'application est stocké dans la table WEB_CONTENT.
Tout d’abord, créez le tableau. Démarrez Oracle Database Special Edition et connectez-vous en tant qu'administrateur système. Libérez l'exemple d'utilisateur HR s'il n'a pas encore été libéré. Suivez les instructions du Guide de démarrage inclus avec l'installation de Special Edition. Notez que par défaut, les utilisateurs RH se voient attribuer le rôle RESOURCE. Ici, donnez à l'utilisateur le rôle DBA afin que le compte puisse être utilisé pour gérer les aspects de base de données de l'application CMS. Bien entendu, le compte utilisateur RH ne sera pas utilisé pour l’accès en ligne, mais uniquement pour l’administration de la base de données.
Vous pouvez maintenant créer une nouvelle table à l'aide du navigateur d'objets ou en exécutant la fenêtre Commandes SQL. Voici le code pour créer la table :
CREATE TABLE WEB_CONTENT (
page_id NUMÉRO CLÉ PRIMAIRE,
contenu_page VARCHAR2 (255)
);
Étant donné que la table a été créée à l'aide du compte utilisateur HR, elle appartient au compte HR et se trouve dans le schéma RH, et les autres utilisateurs ne peuvent pas accéder à la table tant qu'ils n'ont pas explicitement obtenu l'autorisation d'y accéder. Si vous n'y croyez pas, vous pouvez créer un nouvel utilisateur et essayer d'utiliser cet utilisateur pour accéder à la table WEB_CONTENT.
Maintenant, créez deux nouveaux utilisateurs, CMS_USER et CMS_EDITOR. Enfin, CMS_USER se verra accorder des autorisations en lecture seule sur la table WEB_CONTENT, et cet utilisateur sera utilisé comme compte de base de données qui diffuse le contenu en tant qu'utilisateur Web anonyme. Le compte CMS_EDITOR aura plus d'autorisations sur la table et sera utilisé comme compte de l'éditeur CMS (le compte nécessaire pour modifier et maintenir les données dans la table).
De nouveaux utilisateurs peuvent être créés à l'aide de l'interface graphique de XE ou en exécutant la commande suivante :
CREATE USER cms_user IDENTIFIED BY cms_user;
CRÉER UN UTILISATEUR cms_editor IDENTIFIÉ PAR cms_editor ;
(Pour plus de simplicité, le mot de passe ici correspond au nom d'utilisateur.)
Pour que les deux comptes se connectent à la base de données, nous devons leur donner le rôle CONNECT. Pour ce faire, cochez la case CONNECT sous Informations utilisateur dans la section Administration/Utilisateurs de base de données de l'interface graphique XE, ou exécutez la commande suivante :
GRANT CONNECT to cms_user;
GRANT CONNECT to cms_editor ;
Maintenant, si vous essayez de vous connecter en tant qu'utilisateur CMS_USER ou CMS_EDITOR et essayez de lire les données de la table WEB_CONTENT (sélectionnez * dans hr.web_content ;), vous rencontrerez l'erreur suivante :
ORA-00942 : table ou vue. n'existe pas
Pour accéder aux données ou simplement voir le tableau, vous devez accorder aux comptes CMS_USER et CMS_EDITOR des autorisations en lecture seule sur la table WEB_CONTENT :
GRANT SELECT sur hr.web_content à cms_user ;
GRANT SELECT sur hr.web_content vers cms_editor ;
Le code ci-dessus permet à ces deux comptes d'effectuer des instructions SELECT sur la table WEB_CONTENT. Si vous essayez d'exécuter d'autres instructions, vous rencontrerez une erreur. Par exemple, insérer une ligne :
INSERT INTO hr.web_content (page_id,page_content) VALUES (1,'hello world');
produira le message d'erreur
ORA-01031 : privilèges insuffisants
pour permettre à CMS_EDITOR de modifier le contenu de cette table. les autorisations suivantes doivent être accordées :
GRANT INSERT,UPDATE,DELETE sur hr.web_content vers cms_editor ;
Désormais, le compte CMS_EDITOR peut exécuter les instructions INSERT, UPDATE et DELETE sur la table WEB_CONTENT.
Voyez comme c'est facile ! On peut constater que la gestion des autorisations via les rôles est une méthode plus efficace. Si la base de données Oracle utilisée n'est pas XE, vous pouvez effectuer les opérations suivantes :
Créer un rôle :
CREATE ROLE lecteur ;
CREATE ROLE écrivain ;
Accorder des autorisations de rôle :
GRANT SELECT ON web_content TO reader ;
GRANT INSERT,UPDATE,DELETE ON web_content TO write;
Donner le rôle d'utilisateur :
GRANT reader TO cms_user ;
GRANT reader TO cms_editor ; (ils doivent aussi lire)
GRANTwriter TO cms_editor;
Notez que si vous modifiez la définition du rôle READER, ces modifications affectent tous les comptes d'utilisateurs dotés de ce rôle. Si les autorisations sont accordées directement aux utilisateurs, chaque compte utilisateur doit être mis à jour individuellement.
Après avoir terminé les étapes ci-dessus, vous pouvez configurer votre application PHP pour utiliser le compte CMS_USER pour toutes les connexions à la base de données demandées par des utilisateurs Web anonymes et le compte CMS_EDITOR pour les connexions initiées par des pages d'administration protégées par mot de passe. Désormais, même si un formulaire Web public est compromis, l'impact sur la base de données sera minime car le compte CMS_USER ne dispose que d'autorisations en lecture seule.
Conclusion
Dans cet article, nous n'avons présenté que brièvement certaines des fonctionnalités les plus élémentaires de la sécurité de l'accès aux données Oracle. En outre, Oracle propose de nombreuses autres fonctionnalités qui font passer la sécurité de vos applications Web à un niveau supérieur, notamment la base de données privée virtuelle (VPD) et la sécurité des balises.