La sécurité du serveur dépend principalement de la manière dont vous pouvez correctement configurer les autorisations d'accès sur les objets. Fournir à un utilisateur des autorisations excessives peut entraîner de nombreux problèmes. Non, un utilisateur n'utilisera pas vos erreurs. Au lieu de cela, n'importe quel pirate ou moi le ferons. Dans ce cas, vous pouvez oublier vos tables avec des données ou toute la base de données.
Pour une raison quelconque, la sécurité de la base de données est une protection contre l'extérieur, comme un pirate informatique. Cependant, cela arrive très rarement. Je suis programmeur dans une grande entreprise et un administrateur ne pense même pas à protéger les ports du serveur, là où tout est ouvert. Il existe un tas de bases de données, de programmes et même un serveur FTP sur un seul serveur et il n'a jamais été piraté au cours des 5 dernières années. Heureusement, j'ai persuadé l'administrateur de déployer le serveur WEB sur un matériel séparé. Sinon, si quelqu'un connaissait l'adresse IP de notre serveur principal, n'importe quel fainéant pourrait le pirater. Ni la base de données ni Windows n'ont été corrigés depuis plusieurs années.
Cependant, des problèmes internes surviennent chaque jour en raison d'une politique de sécurité incorrecte. Tous les utilisateurs se connectent avec des droits d'administrateur et peuvent créer ce qu'ils veulent. C'est un vrai problème car les autorisations excessives permettent aux fainéants de montrer leur analphabétisme complet. Par conséquent, nous considérerons la sécurité indépendamment de l'origine de la menace - d'un pirate informatique ou d'un utilisateur.
Dans cet article, nous allons examiner toutes les bases nécessaires à la protection de la sécurité contre les pirates et les utilisateurs. J'ai choisi MS SQL Server comme exemple car il contient tout ce qui est disponible dans d'autres bases de données (Oracle, MySQL, etc.) et dispose de capacités de gestion de la sécurité supplémentaires. Quelqu'un pourrait penser que cela rend la SP plus raide. Cependant, parfois, les fonctionnalités supplémentaires peuvent être excessives, causant des problèmes.
Rôles de serveur
Dans Windows et d'autres systèmes d'exploitation, il existe des groupes et des utilisateurs pour gérer les autorisations. Nous pouvons combiner les utilisateurs dans un groupe et leur accorder des droits à tous en même temps, ce qui est beaucoup plus facile que d'attribuer des droits à chaque utilisateur individuellement. À ces fins, dans les bases de données, il existe le concept de "rôle".
Supposons que 100 utilisateurs doivent avoir les autorisations pour lire les données d'une table spécifique. Fournir cette autorisation à chaque utilisateur est un problème. Il est beaucoup plus simple de créer un rôle autorisé à lire, puis d'y ajouter tous les utilisateurs requis. Le résultat est similaire au regroupement.
Dans SQL Server, il existe deux types de rôles :serveur et base de données. Les rôles de serveur sont prédéfinis et ne peuvent pas être modifiés.
Ouvrez la branche de rôle Sécurité/Serveur dans Enterprise Manager afin de voir une liste des rôles disponibles dans la partie droite de la fenêtre. La description définit ce que l'utilisateur peut faire avec le rôle correspondant.
Rôles de serveur dans MS SQL Server et la fenêtre du gestionnaire de rôles
Pour ajouter un utilisateur existant à un rôle, double-cliquez sur la ligne du rôle. Dans la fenêtre qui apparaît, vous pouvez ajouter des utilisateurs au rôle ou les supprimer. L'onglet Autorisation décrit en détail ce que chaque utilisateur peut faire.
Utilisateurs
Pour gérer les utilisateurs, ouvrez la branche Sécurité/Connexions dans Enterprise Manager. Dans la partie droite, vous verrez une liste de tous les utilisateurs du serveur. Par défaut, l'accès est accordé aux administrateurs de domaine et aux comptes de connexion intégrés tels que sa.
Pour ajouter un nouvel utilisateur, faites un clic droit n'importe où dans la partie droite vide de la fenêtre et sélectionnez Nouvelle connexion dans le menu qui apparaît. Tout en haut de la fenêtre, sélectionnez un nom d'utilisateur. Si vous devez choisir un domaine existant ou un utilisateur d'ordinateur, cliquez sur le bouton (…) à droite du champ de saisie et vous verrez la zone de recherche d'utilisateur dans le domaine.
Ajouter un nouvel utilisateur
Ci-dessous, vous pouvez sélectionner le type d'authentification - Windows ou SQL Server. Si vous sélectionnez Windows, vous n'avez pas besoin de spécifier de mot de passe car le serveur le récupérera du système. Cependant, vous pouvez basculer entre Accorder l'accès (autoriser l'accès) ou Refuser l'accès (interdire). Dans ce dernier cas, l'utilisateur sera enregistré dans la base de données, mais il ne pourra pas se connecter - c'est interdit.
Si vous sélectionnez l'authentification SQL Server, vous devrez définir un mot de passe car dans ce cas, il sera stocké dans les tables système du serveur de base de données. Veuillez noter que même si seule l'authentification Windows est spécifiée dans les paramètres du serveur, vous pouvez créer des enregistrements de serveur SQL, mais vous ne pourrez pas vous connecter au système avec ces enregistrements.
Dans l'onglet Rôles de serveur, vous pouvez spécifier le rôle de serveur qui sera accordé à un utilisateur. Par conséquent, même au stade de la création, vous pouvez ajouter des utilisateurs aux rôles nécessaires.
Accès utilisateur aux bases de données
Dans l'onglet Accès à la base de données, spécifiez les bases de données avec lesquelles l'utilisateur peut travailler. Ici, la fenêtre est divisée en deux parties :dans la moitié supérieure, vous pouvez sélectionner la base de données à laquelle l'accès est autorisé, et dans la liste inférieure, vous pouvez sélectionner le rôle de la base de données. Ce rôle dans la base de données définira les autorisations de l'utilisateur. Plusieurs rôles peuvent être attribués à un même utilisateur.
Créez un compte qq, qui aura accès à la base de données Northwind. Il s'agit d'une base de données de test standard créée lors du déploiement du serveur.
Enregistrez les modifications.
Maintenant, ouvrez la branche Databases/Northwind/Users et consultez la liste des utilisateurs autorisés à accéder à la base de données sélectionnée. Veuillez noter qu'il y a le compte qq ici. Il n'y a pas de compte dans d'autres bases de données car l'accès à celles-ci pour notre nouvel utilisateur est interdit.
Rôles de base de données
Chaque base de données peut avoir ses propres rôles, qui définissent les autorisations d'accès sur les objets. De nombreux administrateurs n'aiment pas s'embarrasser de ces autorisations. Ainsi, ils installent le public intégré par défaut, qui autorise presque tout. S'il manque des autorisations pour le rôle public, ajoutez simplement un utilisateur au rôle de serveur Administrateur système. Dans ce cas, la base de données devient vulnérable.
Chaque utilisateur doit disposer de ses propres autorisations nécessaires. Ce qui n'est pas permis doit être interdit. Les rôles qui existent déjà sur le serveur ne doivent pas être utilisés car leurs autorisations sont ouvertes à tous. Il est même recommandé de tous les supprimer, en particulier le public.
Créer un rôle
Pour créer un nouveau rôle de base de données, cliquez avec le bouton droit sur la branche Bases de données/Nom de la base de données/Rôles. Dans le menu qui s'affiche, sélectionnez Nouveau rôle de base de données. La fenêtre Propriétés du rôle de la base de données – Nouveau rôle s'ouvre. Dans la partie supérieure de la fenêtre, saisissez le nom du rôle.
Par exemple, nous voulons créer un rôle pour les comptables. Pour ce faire, tapez Buh dans le champ Nom.
Création d'un rôle de base de données
Ci-dessous, sélectionnez un type de rôle, par exemple, un rôle standard par défaut. Au centre de la fenêtre, il y a une liste d'utilisateurs qui seront ajoutés au rôle. Pour l'instant, la liste est vide. Cependant, si nous cliquons sur Ajouter, nous ajouterons des utilisateurs, par exemple, au compte qq créé précédemment. Il n'y a rien d'autre à faire au stade de la création d'un rôle. Enregistrez les modifications en cliquant sur OK.
Autorisations d'accès
Maintenant, nous allons voir comment nous pouvons définir des autorisations. Double-cliquez sur le rôle Buh créé pour ouvrir la fenêtre de modification. Veuillez noter que le bouton Autorisation est maintenant disponible. Ce n'est que lorsque le rôle est enregistré dans la base de données que nous pouvons modifier ses droits. Cliquez sur ce bouton pour ouvrir la fenêtre Propriétés du rôle de la base de données.
Définir les autorisations d'accès pour les rôles
En haut de la fenêtre, il y a une liste de rôles de base de données afin que vous puissiez basculer rapidement entre eux. Maintenant, le rôle Buh est sélectionné. Au centre de la fenêtre, il y a une grande grille avec les colonnes suivantes :
- Objet – noms d'objets ;
- Propriétaire - un propriétaire d'un objet ;
- SELECT - autorisation d'afficher des données ou d'exécuter l'instruction SELECT. Il n'est disponible que pour les tables et les vues ;
- INSERT - autorisation d'ajouter des données ou d'exécuter l'instruction INSERT. Il n'est disponible que pour les tables et les vues ;
- UPDATE - autorisation de modifier des données ou d'exécuter l'instruction UPDATE. Il n'est disponible que pour les tables et les vues ;
- autorisation DELETE pour supprimer des données ou exécuter l'instruction DELETE. Il n'est disponible que pour les tables et les vues ;
- EXEC - autorisation d'exécuter des procédures et des fonctions stockées. Il n'est disponible que pour les procédures et fonctions stockées ;
- DRI (intégrité référentielle déclarative). Il n'est disponible que pour les tables, les vues et les fonctions.
Il n'y a pas d'autorisations pour le nouveau rôle. Pour pouvoir visualiser un tableau, par exemple Catégories, cochez la case à l'intersection de la ligne Catégories et de la colonne SELECT. Vous verrez une coche verte dans la case, ce qui signifie une autorisation. Le deuxième clic change la coche en croix rouge et signifie interdiction. Cela peut être nécessaire si vous accordez une autorisation à l'utilisateur et l'ajoutez à un autre rôle, où l'accès à l'action sélectionnée est autorisé. Le troisième clic supprime toutes les autorisations sur l'action et laisse la case vide. Cela signifie qu'il n'y a pas d'accès; cependant, il peut être délégué si l'utilisateur est ajouté à un autre rôle avec les autorisations sur l'objet ou si les autorisations sont explicitement spécifiées.
Si vous sélectionnez une ligne avec l'objet de la table ou de la vue, le bouton Colonnes devient disponible en bas de la fenêtre. Supposons que vous avez sélectionné la table et cliqué sur ce bouton. La fenêtre s'ouvre, dans laquelle vous pouvez définir des autorisations pour des colonnes de tableau individuelles.
Définir les autorisations de colonne
C'est en effet une grande possibilité car certaines colonnes responsables de l'intégrité de la base de données ne doivent pas être modifiées par des utilisateurs ou des pirates. Il est préférable d'interdire les opérations UPDATE ou SELECT (si possible) pour ces colonnes.
Individualisme
Les rôles sont pratiques à utiliser lorsqu'il est nécessaire de combiner des utilisateurs similaires. Par exemple, de nombreux comptables doivent avoir accès aux tableaux financiers. Accorder des autorisations à chaque comptable prend du temps. Il est beaucoup plus facile de créer un rôle pour le comptable, de lui accorder des autorisations, puis d'ajouter tous les comptes comptables à ce rôle.
Cependant, il existe des cas où les autorisations doivent être uniques pour un utilisateur, ou en plus des autorisations accordées par le rôle, il est nécessaire d'accorder des autorisations supplémentaires. Par exemple, l'un des comptables doit avoir accès aux tableaux du service des ressources humaines. Dans ce cas, il est préférable d'ajouter des autorisations directement au comptable plutôt que de créer un nouveau rôle.
Nous avons d'abord exploré les rôles pour nous y habituer. Dans la plupart des cas, il existe un compte séparé pour les comptables, un compte séparé pour les économistes, etc. Dans ce cas, la plupart des gens se connectent au serveur en utilisant un seul compte. Ainsi, contrôler qui fait quoi est impossible. Il est préférable d'utiliser des autorisations individuelles si nécessaire, tandis que chaque utilisateur doit avoir son propre compte.
Autorisations sur les tableaux
Voyons comment nous pouvons accorder des autorisations sur des objets particuliers, par exemple sur des tables.
Sélectionnez la branche Bases de données/Northwind/Tables dans l'arborescence des objets. Dans la partie droite, une liste de toutes les tables s'ouvre. Cliquez avec le bouton droit sur n'importe quelle table et sélectionnez Toutes les tâches/Gérer les autorisations. La fenêtre Propriétés d'autorisation s'ouvre, qui est similaire à la fenêtre Propriétés du rôle de base de données avec la liste des utilisateurs au lieu de la liste des objets. L'objet est une table sur laquelle nous avons cliqué et son nom sera listé dans le menu déroulant de la fenêtre. Maintenant, nous devons définir des autorisations sur cet objet pour différents utilisateurs.
Définir les autorisations sur une table
La liste des autorisations est la suivante :afficher, mettre à jour, ajouter, supprimer, exécuter et gérer. Si vous cliquez sur le bouton Colonnes, la fenêtre s'ouvre pour définir les autorisations sur l'objet au niveau des champs de table pour un utilisateur particulier.
Vues
Nous avons deux tableaux. L'un d'eux stocke la liste des employés, tandis qu'un autre tableau contient des informations sur le nombre d'heures travaillées par mois et les salaires perçus (salaires officiels et cachés).
Supposons qu'un agent des impôts vienne vous voir et vous demande de montrer les salaires des travailleurs. De plus, ils vous demandent si vous avez payé toutes les taxes. Quelles actions devez-vous effectuer de votre côté ?
La première proposition est venue de la troisième ligne - créer un nouvel utilisateur autorisé à lire des tableaux comprenant une liste d'employés et de salaires. De plus, il ne faut pas oublier de fermer la colonne avec le salaire caché. En fait, la solution est correcte mais absolument inefficace.
La meilleure option est de créer une vue, une requête SQL qui sélectionne les données. Dans la base de données, cela ressemble à une table. Vous pouvez sélectionner des données SQL à l'aide de requêtes et accorder des autorisations. Il s'avère que la requête sera exécutée sur la requête.
Pour créer une vue, exécutez la requête suivante :
CREATE VIEW salary AS SELECT fields for a tax official FROM Employees, Wages WHERE joins
Maintenant, il y a un nouvel objet Wage dans la branche Databases/Northwind/Views. Si vous faites un clic droit dessus et sélectionnez Toutes les tâches/Gérer les autorisations, la fenêtre d'octroi des autorisations s'ouvrira. Définissez une autorisation pour l'agent des impôts et enregistrez-la. Pour revoir le contenu de la vue, exécutez la requête :
SELECT * FROM salary
Comme vous pouvez le voir, il y a un accès comme à un simple tableau. L'agent des impôts pensera également qu'il voit des données réelles. Cependant, en fait, cette requête ne contiendra que les données dont nous avons besoin.
Dans la vraie vie, l'agent des impôts ne peut pas être trompé si facilement parce qu'il n'est pas dupe. Cependant, cet exemple montre que la vue peut être une méthode de sécurité parfaite. Nous pouvons afficher les données dont les utilisateurs ont besoin et rien d'autre. En même temps, nous avons tous les outils pour gérer les autorisations sur la vue sans affecter les autorisations d'accès sur les tables.
Ainsi, différentes vues des mêmes tables peuvent afficher des données différentes. Si vous souhaitez afficher une colonne supplémentaire, ajoutez les vues à la requête. Dans ce cas, il n'est pas nécessaire de modifier les autorisations.
Vues système
Dans chaque base de données, il peut y avoir des vues système créées automatiquement par le serveur. Je ne recommande pas de leur accorder une autorisation car ils peuvent afficher des informations supplémentaires, ce qui peut aider un pirate à définir des autorisations ou simplement à détruire des données. Les vues système commencent par le préfixe sys et le système est spécifié dans la colonne Type de la liste.
Procédures et fonctions
Les serveurs de base de données modernes prennent en charge les procédures et les fonctions stockées. Il s'agit d'un code PL/SQL ou Transact-SQL selon la base de données exécutée sur le serveur de base de données. En utilisant ces procédures, nous pouvons effectuer toutes les opérations sur le serveur ou simplement sélectionner des données, comme dans la vue. Nous pouvons définir des autorisations sur chaque procédure.
Lors de l'examen des rôles, nous avons déjà vu les procédures dans la liste des objets sur lesquels vous pouvez définir des autorisations et seule la colonne EXEC est disponible dans ces lignes car les procédures peuvent uniquement être exécutées.
Les procédures et fonctions stockées sont stockées dans une base de données particulière. Pour voir les procédures de la base de données Northwind, sélectionnez la branche Bases de données/Northwind/Procédures stockées. Il existe de nombreuses procédures système, dont les noms commencent par le préfixe dt_ et System est spécifié dans la colonne Type. Il est recommandé de ne pas accorder l'accès à ces procédures, si possible. Vous pouvez voir les fonctions dans la branche Bases de données/Northwind/Fonction définie par l'utilisateur.
Pour modifier les autorisations sur les procédures et les fonctions, faites un clic droit sur son nom et sélectionnez Toutes les tâches/Gérer les autorisations dans le menu. Dans la fenêtre qui apparaît, vous ne pouvez modifier que la colonne EXEC pour les procédures et les colonnes EXEC et DRI pour les fonctions.
Politique d'autorisation
Certains administrateurs définissent des autorisations en fonction du rôle existant, par exemple public. Ce n'est pas vrai car, dans ce rôle, il peut y avoir des autorisations dont les utilisateurs n'ont pas besoin. Par conséquent, essayez de définir une toute nouvelle autorisation.
Quant à moi, je crée toujours un nouveau rôle et accorde un ensemble minimum d'autorisations. Si les utilisateurs demandent plus d'autorisations et qu'elles sont réellement nécessaires, j'ajoute plus d'autorisations. Si vous autorisez tout par défaut, il n'y a aucune garantie qu'à l'avenir les droits inutiles et dangereux seront supprimés.
Un autre problème pour définir moins d'autorisations est une habitude. Les utilisateurs peuvent s'habituer au fait que de nombreuses autorisations leur sont accordées, puis l'interdiction provoquera un grave scandale. Personne n'aime quand ses droits sont bafoués.
Tables/Bases de données
Les bases de données stockent leurs paramètres et propriétés masquées dans des tables système et des bases de données. Ils ne diffèrent pas des autres objets de base de données et des autorisations peuvent être définies sur eux. En aucun cas, n'autorisez pas les utilisateurs à accéder à ces tables sans besoin particulier.
Dans SQL Server, les données système importantes sont stockées dans les bases de données master et msdb. Ainsi, ces bases de données doivent être protégées. Dans Oracle, chaque base de données existe en tant qu'objet séparé et les tables système sont stockées avec celles des utilisateurs.
Presque tous les serveurs de bases de données proposent d'installer des bases de données de test qui peuvent être utilisées pour apprendre ou tester le système. Si vous en avez, supprimez - car un accès public est défini pour ces bases de données. Si un pirate connaît les noms ou les propriétés d'un objet existant dans le système, cela simplifiera grandement sa tâche.
Lors de la connexion à une base de données de test, vous pouvez exécuter certaines commandes sur le serveur et endommager le système d'exploitation ou une base de données de travail. Aucun élément supplémentaire ne doit se trouver dans le système. De plus, ces tables/bases de données ont des autorisations assez élevées, même pour un invité.
Résumé
Bien que nous ayons utilisé MS SQL Server comme exemple, les concepts d'autorisations, de rôles et d'authentification existent dans toutes les bases de données.
Connaissant toutes les règles que nous avons considérées, la seule chose dont vous avez besoin est d'explorer la particularité de leur utilisation dans votre base de données.
