Je viens vers vous pour vous demander une information sur la création des
vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise
SQL Server. Dans les différentes bases de données, nous avons des tables
évidemment, ainsi que des procédures stockées.
Jusqu'ici, notre client n'avait accès à cette base de données que par
l'interface de l'application que nous avons développée.
Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations
dans la base de données à partir d'une autre avec un outil de
synchronisation de données (Scribe je crois). Le problème est que nous ne
voulons pas qu'il ait un accès complet à la base de données, c'est à dire
qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni
modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base
de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder
qu'à la vue (et donc à la base de données origine) pour mettre à jour que
certaines données. Comment l'empêcher de consulter le code des procédures
stockées et autres informations de la BDD d'origine?
Merci par avance pour votre aide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
jeorme
s'il y a un mot de passe pour sa et qu'il ne le connaisse pas normalement, il n'a pas accès à Entreprise manager alors ! Verifiez aussi qu'il ne puisse exécuter sp_helptext 'ma procedure' car ça donne la syntaxe de la proc ou de la vue.
Est que l'autorisation du nouvel utilisateur n'est que sur la nouvelle vue ?
Comment va t-il se connecter sur le SGBD (par l'analyseur de requete , par entreprise ou par ACCESS) ?
"C. Vidal" a écrit dans le message de news: #
Bonjour à tous,
Je viens vers vous pour vous demander une information sur la création des vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise SQL Server. Dans les différentes bases de données, nous avons des tables évidemment, ainsi que des procédures stockées. Jusqu'ici, notre client n'avait accès à cette base de données que par l'interface de l'application que nous avons développée. Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations dans la base de données à partir d'une autre avec un outil de synchronisation de données (Scribe je crois). Le problème est que nous ne voulons pas qu'il ait un accès complet à la base de données, c'est à dire qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder qu'à la vue (et donc à la base de données origine) pour mettre à jour que certaines données. Comment l'empêcher de consulter le code des procédures stockées et autres informations de la BDD d'origine? Merci par avance pour votre aide.
C. Vidal
s'il y a un mot de passe pour sa et qu'il ne le connaisse pas normalement,
il n'a pas accès à Entreprise manager alors !
Verifiez aussi qu'il ne puisse exécuter sp_helptext 'ma procedure' car ça
donne la syntaxe de la proc ou de la vue.
Est que l'autorisation du nouvel utilisateur n'est que sur la nouvelle vue ?
Comment va t-il se connecter sur le SGBD (par l'analyseur de requete , par
entreprise ou par ACCESS) ?
"C. Vidal" <cvidal_nospam@univer-com.com> a écrit dans le message de news:
#GYFlUVzEHA.2600@TK2MSFTNGP09.phx.gbl...
Bonjour à tous,
Je viens vers vous pour vous demander une information sur la création des
vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise
SQL Server. Dans les différentes bases de données, nous avons des tables
évidemment, ainsi que des procédures stockées.
Jusqu'ici, notre client n'avait accès à cette base de données que par
l'interface de l'application que nous avons développée.
Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations
dans la base de données à partir d'une autre avec un outil de
synchronisation de données (Scribe je crois). Le problème est que nous ne
voulons pas qu'il ait un accès complet à la base de données, c'est à dire
qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni
modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base
de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder
qu'à la vue (et donc à la base de données origine) pour mettre à jour que
certaines données. Comment l'empêcher de consulter le code des procédures
stockées et autres informations de la BDD d'origine?
Merci par avance pour votre aide.
s'il y a un mot de passe pour sa et qu'il ne le connaisse pas normalement, il n'a pas accès à Entreprise manager alors ! Verifiez aussi qu'il ne puisse exécuter sp_helptext 'ma procedure' car ça donne la syntaxe de la proc ou de la vue.
Est que l'autorisation du nouvel utilisateur n'est que sur la nouvelle vue ?
Comment va t-il se connecter sur le SGBD (par l'analyseur de requete , par entreprise ou par ACCESS) ?
"C. Vidal" a écrit dans le message de news: #
Bonjour à tous,
Je viens vers vous pour vous demander une information sur la création des vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise SQL Server. Dans les différentes bases de données, nous avons des tables évidemment, ainsi que des procédures stockées. Jusqu'ici, notre client n'avait accès à cette base de données que par l'interface de l'application que nous avons développée. Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations dans la base de données à partir d'une autre avec un outil de synchronisation de données (Scribe je crois). Le problème est que nous ne voulons pas qu'il ait un accès complet à la base de données, c'est à dire qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder qu'à la vue (et donc à la base de données origine) pour mettre à jour que certaines données. Comment l'empêcher de consulter le code des procédures stockées et autres informations de la BDD d'origine? Merci par avance pour votre aide.
C. Vidal
Fred BROUARD
vous pouvez utiliser l'option d'encryption des SP avec un utilisateur spécifique à l'application pour éviter qu'il voit le code des SP.
Autre technique complémentaire : ajouter une colonne de contrôle dans toutes vos tables, dont la valeur est calculée par un algorithme de code de contrôle dans le client comme par une fonction dans SQL Server. On vérifie la valeur du code passé dans un trigger de chaque table. Si cette valeur n'est pas correcte alors on fait un rollback dans le trigger.
Extrait d'un de mes cours sur l'optimisation des bases de données sous SQL Server :
" 6.4 Empêcher la corruption des données
Si vous êtes éditeur de progiciel, l'un des pires choses est l'intervention à la main dans les données par des utilisateurs qui croient maîtriser votre modèle de données. Certains clients n'hésitent pas parfois à modifier des valeurs clefs directement dans les tables afin de rectifier leurs erreurs, plutôt que d'utiliser une procédure prévue a cet effet ou d'appeler la hot line... Pour ce faire vous pouvez mettre en place entre le programme client et la base un mécanisme de contrôle des données par redondance.
Un tel mécanisme nécessite un trigger et une colonne supplémentaire dans chaque table clef. Le principe est basé sur un calcul de contrôle permettant de recoller l'information. Il est préférable d'externaliser le calcul de la valeur de contrôle à l'aide d'une UDF.
La fonction de contrôle transforme tous les caractères en leur valeur UNICODE, les additionne et calcule le modulo à 65535 : CREATE FUNCTION FN_DATA_CONTROL_OK (@DATA VARCHAR(8000), @CODE_CONTROL INT) RETURNS BIT AS BEGIN
-- effets de bord IF @DATA IS NULL OR @CODE_CONTROL IS NULL RETURN NULL IF @DATA = '' AND @CODE_CONTROL = 0 RETURN 0
-- boucle de contrôle DECLARE @PART INT, @I SMALLINT, @RESULT BIT SELECT @I = 1, @PART = 0 WHILE @I < LEN(@DATA) BEGIN SET @PART = @PART + (UNICODE(CAST(SUBSTRING(@DATA, @I, 1) AS NCHAR(1)))) - 32768 SET @I = @I + 1 END
SET @PART = @PART % 65535 -- contrôle IF @PART <> @CODE_CONTROL SET @RESULT = 0 ELSE SET @RESULT = 1
RETURN @RESULT
END
En partant d'une définition de table comme suit : CREATE TABLE T_CLIENT_CLI (CLI_ID INT NOT NULL PRIMARY KEY, CLI_NOM CHAR(24), CLI_PRENOM VARCHAR(16), CLI_CONTROL INT)
Le trigger s'écrit : CREATE TRIGGER D_IU_CLI_CTRLOK ON T_CLIENT_CLI FOR INSERT, UPDATE AS
IF EXISTS (SELECT * FROM inserted WHERE dbo.FN_DATA_CONTROL_OK(CAST(CLI_ID AS VARCHAR(16)) + RTRIM(CLI_NOM) + RTRIM(CLI_PRENOM), CLI_CONTROL) <> 1) ROLLBACK
ELSE UPDATE T_CLIENT_CLI SET CLI_CONTROL = NULL FROM T_CLIENT_CLI C INNER JOIN inserted i ON C.CLI_ID = i.CLI_ID L'utilisateur ne voit donc jamais aucune donnée présente dans la colonne CLI_CONTROL...
Ainsi lors de l'insertion des données dans la table des clients, une valeur inexacte du code de contrôle provoquera la disparition de la ligne que l'on tente d'insérer sans la moindre explication.
Seule l'insertion ou la modification de lignes avec un calcul exact du code de contrôle est possible.
Exemple : INSERT INTO T_CLIENT_CLI VALUES (1, 'Eric', 'DUPONT', -64714) "
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
C. Vidal a écrit:
Bonjour à tous,
Je viens vers vous pour vous demander une information sur la création des vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise SQL Server. Dans les différentes bases de données, nous avons des tables évidemment, ainsi que des procédures stockées. Jusqu'ici, notre client n'avait accès à cette base de données que par l'interface de l'application que nous avons développée. Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations dans la base de données à partir d'une autre avec un outil de synchronisation de données (Scribe je crois). Le problème est que nous ne voulons pas qu'il ait un accès complet à la base de données, c'est à dire qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder qu'à la vue (et donc à la base de données origine) pour mettre à jour que certaines données. Comment l'empêcher de consulter le code des procédures stockées et autres informations de la BDD d'origine? Merci par avance pour votre aide.
C. Vidal
vous pouvez utiliser l'option d'encryption des SP avec un utilisateur spécifique
à l'application pour éviter qu'il voit le code des SP.
Autre technique complémentaire : ajouter une colonne de contrôle dans toutes vos
tables, dont la valeur est calculée par un algorithme de code de contrôle dans
le client comme par une fonction dans SQL Server. On vérifie la valeur du code
passé dans un trigger de chaque table. Si cette valeur n'est pas correcte alors
on fait un rollback dans le trigger.
Extrait d'un de mes cours sur l'optimisation des bases de données sous SQL Server :
"
6.4 Empêcher la corruption des données
Si vous êtes éditeur de progiciel, l'un des pires choses est l'intervention à la
main dans les données par des utilisateurs qui croient maîtriser votre modèle de
données. Certains clients n'hésitent pas parfois à modifier des valeurs clefs
directement dans les tables afin de rectifier leurs erreurs, plutôt que
d'utiliser une procédure prévue a cet effet ou d'appeler la hot line...
Pour ce faire vous pouvez mettre en place entre le programme client et la base
un mécanisme de contrôle des données par redondance.
Un tel mécanisme nécessite un trigger et une colonne supplémentaire dans chaque
table clef. Le principe est basé sur un calcul de contrôle permettant de
recoller l'information. Il est préférable d'externaliser le calcul de la valeur
de contrôle à l'aide d'une UDF.
La fonction de contrôle transforme tous les caractères en leur valeur UNICODE,
les additionne et calcule le modulo à 65535 :
CREATE FUNCTION FN_DATA_CONTROL_OK (@DATA VARCHAR(8000), @CODE_CONTROL INT)
RETURNS BIT
AS
BEGIN
-- effets de bord
IF @DATA IS NULL OR @CODE_CONTROL IS NULL RETURN NULL
IF @DATA = '' AND @CODE_CONTROL = 0 RETURN 0
-- boucle de contrôle
DECLARE @PART INT, @I SMALLINT, @RESULT BIT
SELECT @I = 1, @PART = 0
WHILE @I < LEN(@DATA)
BEGIN
SET @PART = @PART
+ (UNICODE(CAST(SUBSTRING(@DATA, @I, 1) AS NCHAR(1))))
- 32768
SET @I = @I + 1
END
SET @PART = @PART % 65535
-- contrôle
IF @PART <> @CODE_CONTROL
SET @RESULT = 0
ELSE
SET @RESULT = 1
RETURN @RESULT
END
En partant d'une définition de table comme suit :
CREATE TABLE T_CLIENT_CLI
(CLI_ID INT NOT NULL PRIMARY KEY,
CLI_NOM CHAR(24),
CLI_PRENOM VARCHAR(16),
CLI_CONTROL INT)
Le trigger s'écrit :
CREATE TRIGGER D_IU_CLI_CTRLOK
ON T_CLIENT_CLI
FOR INSERT, UPDATE
AS
IF EXISTS (SELECT *
FROM inserted
WHERE dbo.FN_DATA_CONTROL_OK(CAST(CLI_ID AS VARCHAR(16)) +
RTRIM(CLI_NOM) +
RTRIM(CLI_PRENOM),
CLI_CONTROL) <> 1)
ROLLBACK
ELSE
UPDATE T_CLIENT_CLI
SET CLI_CONTROL = NULL
FROM T_CLIENT_CLI C
INNER JOIN inserted i
ON C.CLI_ID = i.CLI_ID
L'utilisateur ne voit donc jamais aucune donnée présente dans la colonne
CLI_CONTROL...
Ainsi lors de l'insertion des données dans la table des clients, une valeur
inexacte du code de contrôle provoquera la disparition de la ligne que l'on
tente d'insérer sans la moindre explication.
Seule l'insertion ou la modification de lignes avec un calcul exact du code de
contrôle est possible.
Exemple :
INSERT INTO T_CLIENT_CLI VALUES (1, 'Eric', 'DUPONT', -64714)
"
A +
--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
C. Vidal a écrit:
Bonjour à tous,
Je viens vers vous pour vous demander une information sur la création des
vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise
SQL Server. Dans les différentes bases de données, nous avons des tables
évidemment, ainsi que des procédures stockées.
Jusqu'ici, notre client n'avait accès à cette base de données que par
l'interface de l'application que nous avons développée.
Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations
dans la base de données à partir d'une autre avec un outil de
synchronisation de données (Scribe je crois). Le problème est que nous ne
voulons pas qu'il ait un accès complet à la base de données, c'est à dire
qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni
modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base
de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder
qu'à la vue (et donc à la base de données origine) pour mettre à jour que
certaines données. Comment l'empêcher de consulter le code des procédures
stockées et autres informations de la BDD d'origine?
Merci par avance pour votre aide.
vous pouvez utiliser l'option d'encryption des SP avec un utilisateur spécifique à l'application pour éviter qu'il voit le code des SP.
Autre technique complémentaire : ajouter une colonne de contrôle dans toutes vos tables, dont la valeur est calculée par un algorithme de code de contrôle dans le client comme par une fonction dans SQL Server. On vérifie la valeur du code passé dans un trigger de chaque table. Si cette valeur n'est pas correcte alors on fait un rollback dans le trigger.
Extrait d'un de mes cours sur l'optimisation des bases de données sous SQL Server :
" 6.4 Empêcher la corruption des données
Si vous êtes éditeur de progiciel, l'un des pires choses est l'intervention à la main dans les données par des utilisateurs qui croient maîtriser votre modèle de données. Certains clients n'hésitent pas parfois à modifier des valeurs clefs directement dans les tables afin de rectifier leurs erreurs, plutôt que d'utiliser une procédure prévue a cet effet ou d'appeler la hot line... Pour ce faire vous pouvez mettre en place entre le programme client et la base un mécanisme de contrôle des données par redondance.
Un tel mécanisme nécessite un trigger et une colonne supplémentaire dans chaque table clef. Le principe est basé sur un calcul de contrôle permettant de recoller l'information. Il est préférable d'externaliser le calcul de la valeur de contrôle à l'aide d'une UDF.
La fonction de contrôle transforme tous les caractères en leur valeur UNICODE, les additionne et calcule le modulo à 65535 : CREATE FUNCTION FN_DATA_CONTROL_OK (@DATA VARCHAR(8000), @CODE_CONTROL INT) RETURNS BIT AS BEGIN
-- effets de bord IF @DATA IS NULL OR @CODE_CONTROL IS NULL RETURN NULL IF @DATA = '' AND @CODE_CONTROL = 0 RETURN 0
-- boucle de contrôle DECLARE @PART INT, @I SMALLINT, @RESULT BIT SELECT @I = 1, @PART = 0 WHILE @I < LEN(@DATA) BEGIN SET @PART = @PART + (UNICODE(CAST(SUBSTRING(@DATA, @I, 1) AS NCHAR(1)))) - 32768 SET @I = @I + 1 END
SET @PART = @PART % 65535 -- contrôle IF @PART <> @CODE_CONTROL SET @RESULT = 0 ELSE SET @RESULT = 1
RETURN @RESULT
END
En partant d'une définition de table comme suit : CREATE TABLE T_CLIENT_CLI (CLI_ID INT NOT NULL PRIMARY KEY, CLI_NOM CHAR(24), CLI_PRENOM VARCHAR(16), CLI_CONTROL INT)
Le trigger s'écrit : CREATE TRIGGER D_IU_CLI_CTRLOK ON T_CLIENT_CLI FOR INSERT, UPDATE AS
IF EXISTS (SELECT * FROM inserted WHERE dbo.FN_DATA_CONTROL_OK(CAST(CLI_ID AS VARCHAR(16)) + RTRIM(CLI_NOM) + RTRIM(CLI_PRENOM), CLI_CONTROL) <> 1) ROLLBACK
ELSE UPDATE T_CLIENT_CLI SET CLI_CONTROL = NULL FROM T_CLIENT_CLI C INNER JOIN inserted i ON C.CLI_ID = i.CLI_ID L'utilisateur ne voit donc jamais aucune donnée présente dans la colonne CLI_CONTROL...
Ainsi lors de l'insertion des données dans la table des clients, une valeur inexacte du code de contrôle provoquera la disparition de la ligne que l'on tente d'insérer sans la moindre explication.
Seule l'insertion ou la modification de lignes avec un calcul exact du code de contrôle est possible.
Exemple : INSERT INTO T_CLIENT_CLI VALUES (1, 'Eric', 'DUPONT', -64714) "
A +
-- Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com ************************ www.datasapiens.com *************************
C. Vidal a écrit:
Bonjour à tous,
Je viens vers vous pour vous demander une information sur la création des vues et la sécurité associée. Et c'est un peu urgent.
Nous avons développé pour l'un de nos clients une application qui utilise SQL Server. Dans les différentes bases de données, nous avons des tables évidemment, ainsi que des procédures stockées. Jusqu'ici, notre client n'avait accès à cette base de données que par l'interface de l'application que nous avons développée. Aujourd'hui, notre client souhaite pouvoir mettre à jour des informations dans la base de données à partir d'une autre avec un outil de synchronisation de données (Scribe je crois). Le problème est que nous ne voulons pas qu'il ait un accès complet à la base de données, c'est à dire qu'il ait accès aux informations qu'il souhaite, mais qu'il ne puisse ni modifier ni consulter le code des procédures stockées...
Pour apporter une solution, nous avons créé une vue dans une nouvelle base de données ainsi qu'un nouvel utilisateur. Cet utilisateur ne doit accéder qu'à la vue (et donc à la base de données origine) pour mettre à jour que certaines données. Comment l'empêcher de consulter le code des procédures stockées et autres informations de la BDD d'origine? Merci par avance pour votre aide.
