Sommaire | Recherche | Envoyer | Répondre | Précédent | Suivant
Nom: Anton DIACONU
Email: adiaconu@genie-micro.com
Version: V 8.x
OS: Windows NT
Type: Programmes
L’architecture de la sécurité d’un serveur SQL est basée sur une structure hiérarchique d’utilisateurs. Les utilisateurs sont organisés en rôles. Un rôle est une unité administrative à l’intérieure de SQL Server. Un rôle peut être système, utilisateur ou application. Dans le cadre des progiciels Magic qui utilisent une base de données SQL les applications ont leur propre gestion des droits. Il est difficile de déléguer la gestion des droits au niveau le plus bas : le système de sécurité de la base de données. Une application Magic qui utilise correctement la puissance d’une base de données relationnelle doit utiliser des triggers et des procédures stockées au niveau du serveur. Dans ces conditions un utilisateur d’une application Magic doit avoir le rôle système « dbcreator » pour pouvoir générer une base de données de l’application avec tous les objets du langage de manipulation des données (procédures stockées, triggers). Chaque utilisateur de l’application doit avoir la possibilité d’utiliser la base de données. Une solution envisagée est d’utiliser pour l’application un seul utilisateur du serveur SQL. L’utilisateur peut être créé par l’application Magic au premier lancement. Cet utilisateur a le rôle ‘dbcreator’. L’administrateur du serveur SQL n’a pas en charge la gestion de sécurité de la base de données. Chacun des logins utilisateur de l’application Magic génère au niveau du serveur deux processus : un processus client (application) et un processus serveur (gateway). Le processus client (application) est identifié par la variable système ‘@@SPID’. L’unicité d’un utilisateur Magic au niveau du serveur est donnée par le processus de l’application. L’administrateur du serveur a le rôle ‘sysadmin’. Il peut donner des droits à d’autres utilisateurs SQL sur la base de données de l’application Magic. Dans certains cas il est important d’assurer la sécurité des données des tables (factures, écritures comptables, etc.) et d’empêcher leur modification par d’autres applications même si l’utilisateur a le droit ‘sysadmin’. Une solution de protection est l’utilisation des déclencheurs. Soit une application Magic qui utilise la table sécurisée <TAB>. La table <TAB> a une colonne ‘TAB_USER_MODIF’ pour enregistrer l’utilisateur de l’application Magic. Pour contrôler la modification des données de la table <TAB> l’application utilise la table de contrôle de sécurité <T_SEC> avec la structure suivante : CREATE TABLE T_SEC ( [TS_USER] [char] (8) NOT NULL , [TS_XLOG] [binary] (10) NOT NULL ) ON [PRIMARY] La colonne TS_XLOG est une colonne de type mot de passe.
Avant chaque modification de la table TAB l’application Magic doit créer une ligne dans la table T_SEC avec le code de l’utilisateur et le mot de passe de la fonction de modification. Le trigger défini pour la table <TAB> est le suivant :
CREATE TRIGGER Maj_Tab ON TAB WITH ENCRYPTION
FOR INSERT, UPDATE, DELETE AS
declare @test binary declare @utilisateur sysname declare @user_appl char(8) SET @utilisateur = ‘UTILISATEUR_MAGIC’ select @user_appl = TAB_USER_MODIF from inserted
if @user_appl is null begin select @user_appl = TAB_USER_MODIF from deleted end
SELECT @test = TS_XLOG FROM T_SEC WHERE TS_USER = @user_appl
IF (SUSER_SNAME() <> @utilisateur or @test is null or @test <>’mot_passe’) BEGIN RAISERROR ('La table TAB doit être modifiée par l’application Magic.', 16, 1) ROLLBACK TRANSACTION END
Le trigger Maj_Tab est crypté. Si l’utilisateur ‘sysadmin’ ne connaît pas le mot de passe et le système de protection la seule solution de modifier les données le la table TAB est de supprimer le trigger. L’application Magic peut tester l’existence du trigger et de bloquer l’utilisation si le trigger a été supprimé.
visiteurs depuis le 10/06/96.