2010-12-14 7 views
1

Salutations,Création d'utilisateurs SQL et en limitant leurs autorisations

Mon programme crée une base de données SQL en utilisant des API ADO.NET pour se connecter à un serveur SQL et manipuler des connexions SQL/transactions. Lorsque la base de données est créée, je me connecte au serveur en utilisant les informations d'identification 'sa'. Ce sera la seule fois que je me connecterai à la base de données en utilisant les informations d'identification 'sa'. Au cours de cette même connexion initiale, j'ai besoin de créer un couple de connexions et d'utilisateurs, de sorte qu'à partir de là, les informations d'identification de ces utilisateurs seront utilisées. Maintenant, je sais comment je peux créer des connexions et des utilisateurs, mais je ne peux pas sembler obtenir des restrictions d'accès. Plus précisément, j'ai besoin de créer 1 login db et un utilisateur qui aura accès à toutes les procédures stockées créées pour la base de données - un peu comme un administrateur DB, mais très restreint (à seulement procs stockés). Et le deuxième login/utilisateur db n'aura accès qu'à quelques procédures stockées spécifiques. Des pointeurs? Merci!

+0

Édité mon post pour ajouter plus de détails. N'hésitez pas à demander si ce que j'ai écrit n'est pas clair :) – LaGrandMere

Répondre

1

Je créerais un rôle de base de données, puis ajoutez les utilisateurs à lui. Pour le second utilisateur, j'ai inclus dans le rôle, puis refusé l'autorisation de 2 sprocs. Si vous refusez l'autorisation à de nombreux sprocs et accordez seulement des permissions à quelques sprocs, il peut être préférable/plus facile de ne pas inclure le second utilisateur dans le rôle et d'accorder individuellement des permissions, pour chaque objet que vous souhaitez accorder. C'est à vous de décider et de quelle façon est le plus gérable pour votre situation.


--Replace db with your database name 
USE db 

--Create a database role 
CREATE ROLE db_execonly 

--Grant EXEC permissions to the role 
GRANT EXECUTE TO db_execonly 

--Add users to the new role 
EXEC sp_addrolemember 'db_execonly', 'user1' 
EXEC sp_addrolemember 'db_execonly', 'user2' 

--Deny permissions to specific objects for user2 
DENY EXEC ON OBJECT::dbo.usp_sproc1 TO user2 
DENY EXEC ON OBJECT::dbo.usp_sproc2 TO user2 
+0

merci, brian. Im jouant avec les deux solutions, celui-ci semble être plus élégant. je vais le tester et afficher les résultats – kateroh

1

Ici vous pouvez trouver une procédure stockée qui donne accès à toutes les procédures stockées à un utilisateur:

MS SQL Tips

Tout ce que vous avez à faire est d'appeler avec l'utilisateur qui a besoin d'avoir des droits à exec toutes les procédures stockées en tant que paramètre.

De ce script, vous pouvez voir la libéralité pour permettre l'accès à une procédure stockée est:

GRANT EXEC ON ' + '[' + @OwnerName + ']' + '.' + '[' + @ObjectName + ']' + ' TO ' + @user 

Edit: coller la procédure stockée à partir du lien

CREATE PROCEDURE spGrantExectoAllStoredProcs @user sysname 
AS 

/*---------------------------------------------------------------------------- 
-- Object Name: spGrantExectoAllStoredProcs 
-- Author: Edgewood Solutions 
-- Development Date: 03.19.2007 
-- Called By: TBD 
-- Description: Issue GRANT EXEC statement for all stored procedures 
-- based on the user name that is passed in to this stored procedure 
-- Project: SQL Server Security 
-- Database: User defined databases 
-- Business Process: SQL Server Security 
-- 
---------------------------------------------------------------------------- 
-- Num | CRF ID | Date Modified | Developer | Description 
---------------------------------------------------------------------------- 
-- 001 | N\A  | 03.15.2007 | Edgewood | Original code for the GRANT 
-- EXEC process 
-- 
-- 
*/ 

SET NOCOUNT ON 

-- 1 - Variable declarations 
DECLARE @CMD1 varchar(8000) 
DECLARE @MAXOID int 
DECLARE @OwnerName varchar(128) 
DECLARE @ObjectName varchar(128) 

-- 2 - Create temporary table 
CREATE TABLE #StoredProcedures 
(OID int IDENTITY (1,1), 
StoredProcOwner varchar(128) NOT NULL, 
StoredProcName varchar(128) NOT NULL) 

-- 3 - Populate temporary table 
INSERT INTO #StoredProcedures (StoredProcOwner, StoredProcName) 
SELECT ROUTINE_SCHEMA, ROUTINE_NAME 
FROM INFORMATION_SCHEMA.ROUTINES 
WHERE ROUTINE_NAME NOT LIKE 'dt_%' 
AND ROUTINE_TYPE = 'PROCEDURE' 

-- 4 - Capture the @MAXOID value 
SELECT @MAXOID = MAX(OID) FROM #StoredProcedures 

-- 5 - WHILE loop 
WHILE @MAXOID > 0 
BEGIN 

-- 6 - Initialize the variables 
SELECT @OwnerName = StoredProcOwner, 
@ObjectName = StoredProcName 
FROM #StoredProcedures 
WHERE OID = @MAXOID 

-- 7 - Build the string 
SELECT @CMD1 = 'GRANT EXEC ON ' + '[' + @OwnerName + ']' + '.' + '[' + @ObjectName + ']' + ' TO ' + @user 

-- 8 - Execute the string 
-- SELECT @CMD1 
EXEC(@CMD1) 

-- 9 - Decrement @MAXOID 
SET @MAXOID = @MAXOID - 1 
END 

-- 10 - Drop the temporary table 
DROP TABLE #StoredProcedures 

SET NOCOUNT OFF 
GO 

Ici, il est .

Tout ce que vous avez besoin est d'appeler cette procédure avec votre utilisateur sa;)

+0

Merci pour les conseils. Je dois être en mesure d'accorder EXEC sur tous les proc stockés dans la base de données de cette manière. – kateroh

+0

@kateroh: c'est ce que la procédure stockée donnée dans le lien fait :) Mais je ne voulais pas le coller car c'est long. Ok, je modifie mon post pour le coller. Je prends la version SQL Server 2005, si ce n'est pas la bonne, allez sur le lien. – LaGrandMere

+0

@LaGandMere: merci pour votre réponse. Chaque fois qu'un nouveau proc stocké est ajouté, ce code devra être relancé pour tous les utilisateurs, ce qui n'est pas très agréable. N'est-ce pas la solution avec un rôle db qui n'est accordé que des permissions 'execute' plus élégantes (proposées par brian ci-dessous)? Y a-t-il des inconvénients avec son approche? Merci! – kateroh

Questions connexes