Les rôles facilitent l'octroi et la révocation des privilèges pour les utilisateurs d'une base de données relationnelle. Au lieu de gérer les privilèges pour chaque utilisateur individuellement, vous gérez les privilèges pour chaque rôle et tous les changements s'appliquent à tous les utilisateurs qui sont assignés à ce rôle. Les organisations créent souvent plusieurs rôles pour répondre à leurs besoins uniques.
Contenu connexe sélectionné :
Toutefois, la plupart des bases de données sont fournies avec un rôle prédéfini appelé PUBLIC. Dans ce blog, nous expliquons ce que signifie le rôle PUBLIC dans Oracle et les principales meilleures pratiques pour son utilisation.
Quel est le rôle PUBLIC dans Oracle ?
Le rôle PUBLIC est un rôle spécial que chaque utilisateur de base de données hérite implicitement lors de sa création. La documentation d'Oracle 11g indique que le rôle PUBLIC est accessible à chaque utilisateur de la base de données, et donc tous les privilèges et rôles accordés au rôle PUBLIC sont accessibles à chaque utilisateur de la base de données. Bien qu'un administrateur puisse émettre une commande pour accorder le rôle PUBLIC à un utilisateur particulier ou le révoquer, ces commandes n'ont aucun effet pratique ; l'utilisateur aura toujours ce rôle.
Il est intéressant de noter que la vue DBA_ROLES ne liste pas le rôle PUBLIC :
SQL> SELECT * FROM DBA_ROLES WHERE ROLE =’PUBLIC’;
no rows selected
Cependant, l'interrogation de la table SYS.USER$ montre que PUBLIC existe bien et sa valeur de type# de 0 indique qu'il s'agit d'un rôle :
SQL> SELECT user#, type#, name FROM SYS.USER$ WHERE type# = 0 ORDER BY 1;
La nature implicite de l'attribution du rôle PUBLIC à tous les utilisateurs de la base de données peut être observée dans l'exemple suivant. Accorder le privilège CONNECT au rôle PUBLIC permettra à celui-ci d'être hérité par le nouvel utilisateur sans qu'il soit accordé explicitement.
SQL> CREATE USER bob IDENTIFIED BY MyPassword;
SQL> conn bob/MyPassword;
Meilleures pratiques pour le rôle PUBLIC
Le rôle PUBLIC ne doit pas être utilisé pour la gestion des privilèges des utilisateurs. En d'autres termes, n'attribuez jamais un privilège ou un rôle à PUBLIC à moins que l'intention ne soit d'accorder ces privilèges et rôles à tous les utilisateurs actuels de la base de données et à tout nouveau utilisateur qui pourrait être créé à l'avenir.
En effet, accorder des privilèges et des rôles directement au rôle PUBLIC est classé comme une constatation par l'Agence d'Information des Systèmes de Défense (DISA) : le guide d'implémentation technique de sécurité DISA (STIG) identifiant de vulnérabilité V-61435 stipule que les privilèges de base de données ou système ne doivent pas être accordés à PUBLIC, et V-61443 indique que les permissions des rôles d'application ne doivent pas être assignées à PUBLIC.
Comprendre pourquoi nécessite un peu de contexte. Dans un environnement de base de données conteneurisée (CDB) ou de base de données enfichable (PDB), il existe un concept de rôles communs et de rôles locaux. Dans une CDB, les rôles communs sont créés dans la racine et sont connus de tous les conteneurs actuels et futurs. Dans un environnement PDB, les rôles locaux sont propres à une PDB spécifique ; ils ne peuvent être utilisés que dans la PDB où ils sont définis.
Cependant, dans un environnement Oracle multi-tenant, les rôles sont un peu plus compliqués. Par défaut, tous les privilèges qu'Oracle accorde au rôle PUBLIC sont octroyés localement et de manière commune. Selon Oracle, les privilèges ne devraient jamais être accordés au rôle PUBLIC de manière commune. Autrement dit, ne jamais accorder aucun type de privilège au rôle PUBLIC dans la racine ou le CDB. Bien qu'il soit possible de modifier le rôle PUBLIC dans chaque CDB séparément, cela n'est pas recommandé à moins que cela ne soit nécessaire.
Tous les privilèges accordés par les utilisateurs au rôle PUBLIC peuvent être révoqués sans conséquences néfastes. Cependant, il convient de faire preuve de prudence lors de la révocation des privilèges par défaut accordés au rôle PUBLIC dans le cadre de la création de la base de données, car ces privilèges pourraient être réattribués lors d'une future mise à niveau ou d'un processus de correction.
Pour obtenir de l'aide dans l'énumération de tous les rôles et privilèges Oracle, y compris le rôle PUBLIC, envisagez d'investir dans une solution tierce telle que Netwrix StealthAUDIT, capable de produire des rapports de droits détaillés clés en main.
Partager sur
En savoir plus
À propos de l'auteur
Kevin Joyce
Directeur de Product Management
Directeur de Product Management chez Netwrix. Kevin a une passion pour la cybersécurité, en particulier pour comprendre les tactiques et techniques utilisées par les attaquants pour exploiter les environnements des organisations. Avec huit ans d'expérience en gestion de produit, se concentrant sur la sécurité d'Active Directory et de Windows, il a utilisé cette passion pour aider à développer des solutions permettant aux organisations de protéger leurs identités, infrastructures et données.
En savoir plus sur ce sujet
Lois sur la confidentialité des données par État : Différentes approches de la protection de la vie privée
Exemple d'analyse des risques : Comment évaluer les risques
Qu'est-ce que la gestion des documents électroniques ?
Expressions régulières pour débutants : Comment commencer à découvrir des données sensibles
Partage externe dans SharePoint : Conseils pour une mise en œuvre judicieuse