Sécurité des bases de données dans Oracle

Ce n'est un secret pour personne que l'information fait tourner le monde actuellement. Si une entreprise prend soin de sa propriété intellectuelle et que chaque employé peut facilement obtenir les informations nécessaires, l'entreprise peut espérer la croissance. S'il y a du chaos dans les données, l'entreprise échouera malgré l'esprit d'équipe.

Dans cet article, nous allons explorer les bases de la sécurité des bases de données et des exemples de protection des informations dans Oracle. En fait, les bases théoriques de la protection des informations dans la base de données, que nous allons examiner dans cet article, seront également utiles aux personnes travaillant avec d'autres bases de données.

Autorisations d'accès

Dans la plupart des entreprises pour lesquelles j'ai travaillé, tous les administrateurs et développeurs avaient un accès complet aux bases de données, de même qu'un employé du service informatique était un dieu et pouvait faire tout ce qu'il voulait. Pourquoi cela arrive-t-il ? Il y a deux raisons à cela :

Tandis qu'ils travaillent dans un service, les employés peuvent se rencontrer pendant 8 heures par jour et devenir amis. Comment ne peuvent-ils pas accorder l'accès? L'amitié est une chose, mais les affaires sont les affaires.
L'octroi de certains droits d'accès ou la modification de certaines configurations peuvent nécessiter certains privilèges. Parfois, les administrateurs pensent que les programmeurs configurent mieux les paramètres. Ainsi, ils fournissent aux programmeurs des droits d'accès inutiles. Au lieu de cela, les programmeurs ne doivent pas être impliqués dans l'administration et ne doivent avoir aucun droit pour cela.

D'après mon expérience, le deuxième problème est très courant, nous allons donc l'analyser en détail.

Lors du développement de programmes pour les bases de données, les programmeurs connaissent un mot de passe de superutilisateur ou ont simplement des droits d'administrateur de base de données. Ceci est inutile et absolument dangereux. Seul l'administrateur de la base de données doit avoir tous les droits. Même le chef de service, le directeur et les meilleurs amis peuvent avoir moins de privilèges.

Par exemple, lors du développement de programmes, il suffit d'avoir les droits du propriétaire du schéma dans la base de données Oracle qui stocke les tables de travail. Ces droits sont suffisants pour créer de nouvelles tables, packages, index et autres objets, ainsi que pour accorder des droits d'accès aux objets de schéma à d'autres utilisateurs. Vous n'avez pas besoin des droits système pour travailler à temps plein.

S'il n'y a pas d'administrateur de base de données à plein temps, c'est très mauvais. Il est préférable qu'une personne soit responsable des performances, de l'optimisation et de la sécurité de la base de données. Au moins, vous devez nommer un programmeur qui en sera responsable et qui aura les droits exclusifs.

Selon les statistiques, les employés de l'entreprise causent le plus souvent des pertes de données. Pourtant, malgré ce fait, la plupart des entreprises continuent d'ignorer ce fil et différentes bases de données stockées sur des disques en libre accès sont vendues même dans le métro.

Utilisateurs et rôles

Il existe deux types d'objets pour accorder des droits d'accès aux bases de données :les utilisateurs et les rôles. Les rôles sont des groupes qui combinent des utilisateurs qui doivent avoir des droits similaires. Par exemple, tous les comptables peuvent avoir besoin d'accéder aux documents financiers. Pour vous éviter d'accorder des droits à chaque comptable, nous pouvons les combiner dans un rôle avec l'accès nécessaire.

Comme vous pouvez le voir, le principe des rôles est similaire aux groupes dans le système d'exploitation Windows. Pourtant, il a quelques différences. Non sans raison, les trois types d'objets tels que les utilisateurs, les groupes et les rôles peuvent être implémentés dans la base de données. Cependant, seuls les utilisateurs et les rôles sont implémentés dans la plupart des bases de données. Il est nécessaire de gérer et de surveiller tous ces objets afin que chaque utilisateur obtenant les droits accordés par les rôles puisse avoir accès aux données qui sont réellement nécessaires pour résoudre les tâches. Il est nécessaire d'utiliser les droits d'accès comme règles pour un pare-feu. En utilisant ces droits, vous pouvez résoudre le même problème :autoriser un utilisateur à n'effectuer que certaines tâches et éviter d'éventuelles pertes ou corruptions.

À l'aide de rôles, il est assez pratique de contrôler l'accès, de fournir des autorisations ou de bloquer l'ensemble du groupe d'utilisateurs. Un rôle peut être inclus dans l'autre, héritant ainsi de ses droits d'accès. Par conséquent, nous pouvons créer une structure hiérarchique des droits.

Tous les employés ayant les droits d'accès à une base de données d'entreprise peuvent être inclus dans un seul rôle avec les droits minimaux. Désormais, si vous avez besoin de privilèges supplémentaires, d'un accès à des tables particulières, vous devrez ajouter un utilisateur à d'autres rôles (si un groupe nécessite le même accès) ou fournir les droits à un compte particulier.

Dans le programme, pour contrôler l'accès aux tables, il est possible de vérifier le résultat pour les erreurs après chaque tentative d'ouverture de l'ensemble de données. Si une erreur d'accès se produit, l'accès à la table spécifiée est bloqué pour un utilisateur. Ainsi, il n'est pas nécessaire de mettre en œuvre les droits d'accès à l'application cliente. Cependant, si vous voulez mettre en œuvre cela, il n'y aura aucun mal. Au moins, je ne vois rien de critique là-dedans; il semble avoir l'effet inverse.

Audit de sécurité

Si chaque utilisateur travaille sous son propre compte dans votre base de données, vous pouvez appeler la variable utilisateur pour déterminer l'utilisateur actuel, par exemple :

SELECT user from dual

Cette requête renverra un nom d'utilisateur, sous lequel la connexion au serveur est ouverte. Si plusieurs personnes peuvent se connecter avec un même nom, cette requête renverra le même nom pour les deux et cela ne servira à rien pour l'audit. Surtout si le contrôle du verrouillage se produit au niveau du serveur.

Si plusieurs utilisateurs peuvent se connecter avec le même nom d'utilisateur, il est compliqué, mais toujours possible, d'identifier qui s'est connecté au compte. La requête suivante permet d'obtenir les informations détaillées sur la session :

select s.user#, s.username, s.osuser, s.terminal, s.program
from sys.v_$session s
WHERE username=user

Comme vous pouvez le voir, la requête a renvoyé le nom d'utilisateur, connecté à la base de données, un nom dans le système d'exploitation, un nom d'utilisateur de terminal et un programme.

Ici, vous pouvez accéder à la vue v_$session à partir du schéma système sys. Cette vue renvoie des informations sur les connexions au serveur. Dans la clause WHERE, nous limitons la sortie à l'utilisateur actuel uniquement. En conséquence, la requête renvoie l'ID utilisateur, le nom, le nom dans le système d'exploitation, le terminal et le programme à partir duquel la connexion a été établie.

Lorsque vous connaissez un nom d'utilisateur et un nom de terminal, vous pouvez identifier un utilisateur à coup sûr. Pour savoir à quels rôles l'utilisateur actuel a été ajouté, vous pouvez exécuter la requête suivante :

SELECT GRANTED_ROLE 
FROM dba_role_privs 
WHERE grantee=user

Sécurité du compte

Nous ne dirons pas qu'il ne devrait pas y avoir de mots de passe par défaut. Certaines bases de données, par exemple MySQL, se trompent lorsqu'elles créent un mot de passe système simple et bien connu après l'installation. Nous ne dirons pas non plus que le mot de passe doit être compliqué. Cette règle s'applique à tous les domaines informatiques et doit être connue même d'un utilisateur novice. Nous allons parler des problèmes de base de données.

D'après mon expérience, lors du développement de programmes d'entreprise, les développeurs utilisent le même compte pour accéder à une base de données. Les paramètres de ce compte sont enregistrés directement dans le programme, tandis que l'accès à des modules particuliers, y compris la comptabilité, l'entrepôt, le service du personnel, etc. est mis en œuvre de manière programmatique. D'une part, cette méthode est pratique, car le programme peut se connecter à la base de données avec des droits d'administrateur et n'aura pas à s'occuper des rôles et des droits d'accès aux tables. D'un autre côté, cette méthode est loin d'être sûre. Le niveau d'utilisateurs augmente et les amis des employés de votre entreprise peuvent être formés dans le domaine de la sécurité et du piratage. Après avoir connu le nom et le mot de passe sous lesquels le programme se connecte à la base de données, un utilisateur ordinaire peut obtenir plus d'opportunités que vous ne le souhaitiez.

Le langage SQL n'est pas un langage secret et compliqué. Il existe de nombreux programmes à l'aide desquels vous pouvez facilement visualiser toutes les données de la base de données. Avec le nom d'utilisateur et le mot de passe, n'importe qui peut voler toutes vos données. Ainsi, il sera vendu dans n'importe quel stand vendant des disques.

Un nom d'utilisateur et un mot de passe ne doivent jamais être stockés dans le programme. L'accès au programme doit également être limité et impossible pour les tiers. Il est tout à fait logique de combiner les deux connexions en une seule. Il est nécessaire de créer un compte séparé sur le serveur de base de données avec les droits minimum nécessaires pour chaque utilisateur de l'organisation. Ces noms et mots de passe doivent être utilisés lors de la connexion au programme. Vous pouvez utiliser une logique commune et très efficace - si vous pouvez vous connecter à la base de données avec les données saisies, l'accès est autorisé ; sinon, vous devez abandonner le programme. Ce processus est simple et efficace car nous avons utilisé l'autorisation de la base de données.

Pour vérifier que les utilisateurs ne travaillent pas simultanément depuis deux ordinateurs différents sous le même nom, vous pouvez exécuter la requête suivante :

select s.username, s.terminal, count(*)
from sys.v_$session s
WHERE username=user
HAVING count(*)>1
GROUP BY s.username, s.terminal

En fait, il ne doit renvoyer aucun enregistrement.

Vues

Les vues sont un moyen très pratique de se déconnecter de la structure des données et de créer en même temps un niveau de protection supplémentaire. C'est vrai que les opinions ont un impact négatif sur la productivité, cependant, elles ont un impact positif sur la sécurité. Nous pouvons accorder leurs propres droits d'accès, tandis que les tables à partir desquelles les données sont récupérées peuvent rester inaccessibles à ce compte.

Quand est-il préférable d'utiliser les vues ? Définissons d'abord quels sont leurs inconvénients. Une vue est une instruction SELECT pour récupérer des données. Il peut accéder à la fois à une et plusieurs tables. Si vous sélectionnez simplement les données dans la vue, il n'y aura aucune perte de performances. Cependant, nous pouvons utiliser des vues dans d'autres requêtes pour sélectionner des données et y faire référence comme dans les tables. Par exemple :

SELECT list of fields
FROM view, table_1, table_2
WHERE some parameters

Dans ce cas, la requête récupère les données de la vue et de deux tables. De plus, nous pouvons voir une relation entre tous les objets et une condition supplémentaire peut être définie.

Examinons maintenant la requête telle que l'optimiseur de base de données la voit :

SELECT list of fields
FROM (SELECT ...), table1, table2
WHERE some parameters

Dans ce cas, j'ai remplacé la vue par une instruction SELECT abstraite entre parenthèses qui constitue la vue. Il s'avère que le serveur voit une requête avec une sous-requête. Si la sous-requête renvoie des données dynamiques, plutôt qu'une valeur statique, cette sélection de données fonctionnera plus lentement que si nous écrivions la même requête sans la sous-requête.

Sécurité des données

Vous ne devez jamais accorder un accès complet aux objets sans besoin particulier. Je commence toujours à fournir des droits uniquement pour permettre la sélection de données avec l'instruction SELECT. Si l'utilisateur a vraiment besoin d'insérer de nouveaux enregistrements et qu'il ne peut pas effectuer les tâches qui lui sont assignées, dans ce cas, ajoutez la permission sur l'instruction INSERT de la table spécifiée.

Les opérations les plus dangereuses pour les données sont la modification et la suppression, à savoir UPDATE et DELETE, respectivement. Vous devez accorder ces droits avec soin. Assurez-vous que les données peuvent être modifiées ou supprimées. Seulement dans ce cas, sélectionnez les droits appropriés. Certaines tables ne sont étendues que par nature.

Il faut être sûr que les données seront fréquemment affectées. Par exemple, la table des employés peut être étendue et modifiée, mais un seul enregistrement ne doit jamais être supprimé. La suppression peut influencer le contexte de travail des employés, les rapports et l'intégrité des données. Le cas où un responsable des ressources humaines ajoute accidentellement un enregistrement supplémentaire et souhaite le supprimer est toujours possible. Cependant, de tels cas sont rares et l'erreur peut être corrigée par l'administrateur de la base de données. Nous comprenons que personne ne veut se surmener et qu'il est plus facile d'accorder une autorisation, cependant, la sécurité est plus précieuse.

L'octroi des droits s'effectue à l'aide de l'opérateur GRANT. En général, cela ressemble à ceci :

GRANT quoi donner des droits aux objets ON aux utilisateurs ou aux rôles

Par exemple, la requête suivante accorde le droit d'insérer et d'afficher la table TestTable à l'utilisateur 1 :

GRANT Select, Insert ON TestTable TO User1

Clés étrangères

De nombreux utilisateurs ont peur des clés étrangères car elles n'autorisent généralement pas la suppression de données lorsqu'il existe une jointure externe. Le problème peut être facilement résolu si une suppression en cascade est établie. Cependant, la plupart des spécialistes n'aiment pas cette possibilité. Une action ridicule peut corrompre des données très importantes sans aucune demande de confirmation. Les données liées doivent être supprimées explicitement, et uniquement si l'utilisateur a consciemment confirmé que les données peuvent être supprimées.

N'ayez pas peur des clés étrangères. Ils nous fournissent un moyen pratique de contrôler l'intégrité des données à partir du serveur de base de données, c'est donc une sécurité qui ne fait jamais de mal. Le fait qu'il puisse y avoir des problèmes avec la suppression n'est qu'un avantage. Il vaut mieux ne pas supprimer les données plutôt que de les perdre à jamais. La clé étrangère avec l'index ne réduit pas les performances. Il s'agit juste d'une petite vérification lors de la suppression des données ou de la modification du champ clé auquel les données sont connectées dans différentes tables.

Sauvegarde

La sauvegarde est également l'un des facteurs de sécurité que nous ignorons avant la première perte de données. Cependant, personnellement, je l'aurais inclus dans les principaux. La perte de données peut être causée non seulement par des pirates et des utilisateurs inaptes, mais également par des dysfonctionnements de l'équipement. Les défaillances de l'équipement peuvent entraîner la perte de la base de données, dont la restauration peut prendre des heures, voire des jours.

Il est nécessaire de développer à l'avance la politique de sauvegarde la plus efficace. Qu'entend-on par là ? Les temps d'arrêt causés par la perte de données et jusqu'au moment de la restauration de la capacité de travail doivent être minimes. La perte de données doit également être minime et la sauvegarde ne doit pas affecter le travail de l'utilisateur. S'il y a de l'argent et des opportunités, il est préférable d'utiliser des systèmes tels que le RAID, le cluster ou même la réplication de données.

La sauvegarde et la restauration sont un sujet distinct et intéressant. Nous n'avons pas pu l'aborder ici, mais nous ne l'examinerons pas en détail.

Résumé

Nous avons pensé aux fondamentaux de la sécurité, notamment pour Oracle. N'oubliez pas que la protection fournie par la base de données n'est qu'à un seul niveau, alors que la protection doit être à plusieurs niveaux. Pour dormir un peu la tête tranquille, il faut mettre en place l'ensemble des fonctions de sécurité sur le réseau, les serveurs et tous les ordinateurs, y compris antivirus, anti-spyware, VPN, IDS, etc. Plus il y a de niveaux de protection, plus il sera difficile de les surmonter.

Il devrait y avoir une politique et un contrôle de sécurité clairs. Si un employé part, son compte est supprimé. Si des utilisateurs travaillent avec le même mot de passe ou utilisent un mot de passe de groupe pour effectuer des tâches, tous ces mots de passe doivent être modifiés. Par exemple, si un administrateur part et que tous les administrateurs utilisent le même compte, vous devez modifier le mot de passe.

La sécurité est nécessaire. Vous devez vous protéger non seulement des pirates mais aussi des utilisateurs « novices », qui peuvent corrompre les données par leur inexpérience. Une bonne politique de sécurité aide à prévenir de tels cas et cette possibilité ne peut être exclue. Il est préférable de fournir la possibilité de sécuriser à l'avance les données contre l'inexpérience plutôt que de perdre beaucoup de temps à restaurer les données et d'obtenir des temps d'arrêt inutiles.