web-dev-qa-db-fra.com

Autorisations DDL_admin vs db_owner

Je prends en charge un projet qui implique la suppression et la limitation des autorisations de tous les utilisateurs de base de données dans notre batterie de serveurs. (des moments de plaisir)

L'une des autorisations actuellement limitées est les autorisations db_owner.
Cette autorisation est en cours de révision au cas par cas, mais une modification courante consiste à remplacer les autorisations db_owner par ce qui suit:

Je voudrais définir la différence exacte entre les deux (pour informer les clients).
Cependant, pour autant que je sache, la différence entre les deux devrait être:

  • autorisations db_accessadmin
  • autorisations db_backupoperator
  • autorisations db_securityadmin

Donc, en fait, ils perdraient:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE], [ALTER ANY ROLE]
[DROP DATABASE]

Y a-t-il autre chose qu'un utilisateur perdrait une fois db_owner remplacé par les quatre rôles ci-dessus?
Est-ce que cela sert en grande partie à des fins de sécurité?

sql-serverpermissions
16
Reaces

db_ddladmin vs db_owner

D'après ce que je peux dire d'après ce que j'ai testé et lu, la plupart de votre liste semble exacte, sauf db_ddladmin VOUS autorise CREATE SCHEMA. J'ai confirmé que les autres autorisations de sécurité que vous avez répertoriées ont bien été refusées.

Refusé avec DDLADMIN uniquement:

[ALTER ANY USER]

[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]

[ALTER ANY APPLICATION ROLE], [ALTER ANY ROLE]

[DROP DATABASE]

Notant que le. . .

  1. db_datareader permettra à SELECT d'accéder à toutes les tables
  2. db_datarwriter permettra à INSERT, UPDATE et DELETE d'accéder à toutes les tables
  3. db_executor permettra à EXECUTE d'accéder à tous les objets exécutables

De plus, avoir des autorisations de rôle db_ddladmin peut signifier. . .

Remarque: Étant donné que vous disposez de nombreuses versions différentes de SQL Server de 2005 à 2014, il peut être préférable d'avoir un petit ensemble d'utilisateurs testez ceci initialement pour voir qui crie pour aplanir les plis, etc.

  • Les objets qu'ils possèdent avec ce rôle ne seront pas la propriété de DBO, vous devrez donc peut-être faire face à des problèmes de changement de propriété s'il y a un problème avec quelque chose à ce niveau. Je ne suis pas sûr à 100% que ce serait un problème, mais il convient de le mentionner au cas où.

    Source: Chaînes de propriété

  • Avec ce rôle (peut varier selon la version de SQL Server) ils peuvent être en mesure d'ajouter des principes de sécurité SQL définis dans la base de données actuelle aux objets qu'ils possèdent toujours, mais pas tous les objets (celles qu'ils ne possèdent pas) ni ajouter un nouveau principal défini au niveau du serveur au niveau de la base de données.

De plus, ne pas avoir d'autorisations de rôle DBO peut signifier. . .

Remarque: Étant donné que vous disposez de nombreuses versions différentes de SQL Server de 2005 à 2014, il peut être préférable d'avoir un petit ensemble d'utilisateurs testez ceci initialement pour voir qui crie pour aplanir les plis, etc.

  • Ne pas avoir le rôle DBO peut empêcher certaines interfaces GUI du concepteur SSMS (la version de SQL Server varie) de se remplir ou de s'ouvrir sans erreur (par exemple lors de la modification de tables ou de colonnes via l'interface graphique) même si le faire via T-SQL fonctionne et que les autorisations sont en place. Dans certaines versions de SQL Server, cela peut être résolu en autorisant GRANT VIEW DEFINITION où il s'agit d'un problème et il peut également s'agir uniquement d'un avertissement sur certaines versions de SQL Server.

    Ressources

    • Vous n'êtes pas connecté en tant que propriétaire de la base de données ou en tant qu'utilisateur membre du rôle db_owner. Vous ne pourrez pas enregistrer les modifications apportées aux tables qui ne vous appartiennent pas.

    • le rôle db_ddladmin n'autorise pas l'utilisation des fonctions de "conception" dans SSMS

      "Nous essayons d'empêcher autant que possible de donner aux utilisateurs/développeurs dbo dans leurs bases de données QA. L'un des problèmes avec cela est qu'ils doivent toujours être en mesure de créer et de modifier des objets de base de données tels que des tables d'utilisateurs. De nombreux développeurs sont nouveaux dans MS SQL et ont donc tendance à s'en tenir à l'interface graphique (SSMS) pour ce type de travail. Le problème se pose lorsque nous leur accordons db_ddladmin (et non dbo) et qu'ils ne sont plus en mesure de modifier des tables ou des colonnes via l'interface graphique du concepteur de table. Au lieu de cela, ils doivent prendre plus de temps pour apprendre les commandes TSQL et leur syntaxe (dont ils n'auront peut-être plus jamais besoin) ou engager l'équipe DBA, ce qui prend du temps sur nos autres activités.

      Je ne sais pas s'il s'agit d'un bogue ou d'une demande de fonctionnalité mais je le considère comme un bogue car l'utilisateur dispose des autorisations suffisantes pour modifier la table via TSQL mais l'interface graphique leur donne des messages indiquant:

      " Vous n'êtes pas connecté en tant que propriétaire de la base de données ou administrateur système. Vous ne pourrez peut-être pas enregistrer les modifications apportées aux tables dont vous n'êtes pas propriétaire." ET "Table [schema].[table] est défini en lecture seule, l'utilisateur ne dispose pas de droits suffisants sur cette table. "

      Une trace semble indiquer que la vérification est un is_member ('db_owner') qui exclura les membres de db_ddladmin même s'ils ont en fait les autorisations pour modifier l'objet. Microsoft SQL Server Management Studio "

      Publié par l'agent DBA le 25/01/2010 à 07:06

      J'ai eu un problème similaire et j'ai réussi à le résoudre en effectuant la subvention suivante

      GRANT view definition on schema:: <schemaname> to <username>

Autres considérations

Puisque vous déclarez que cela est examiné au cas par cas

L'une des autorisations actuellement limitées est les autorisations db_owner.

Cette autorisation est en cours de révision au cas par cas, mais une modification courante consiste à remplacer les autorisations db_owner par ce qui suit:

  • db_datareader
  • db_datawriter
  • db_ddladmin
  • db_executor

Avez-vous envisagé de créer des rôles personnalisés supplémentaires pour un accès au niveau de la base de données "tous les objets" dont chaque personne a besoin plutôt que de lui accorder le db_ddladmin rôle car cela leur donnera probablement plus que ce dont ils ont réellement besoin pour les objets de niveau DB également.

Je donne habituellement ce dont ils ont besoin exactement et rien de plus pour qu'ils fassent leur travail et s'il y a un besoin "habituel" ou "standard" d'accès aux objets de niveau DB à tous les objets d'une base de données, je crée un rôle de base de données personnalisé un peu comme le db_executor mais voir mon exemple ci-dessous. De cette façon, vous pouvez accorder aux utilisateurs ce dont ils ont vraiment besoin pour TOUS les objets DB dans une base de données particulière si vous n'obtenez pas de niveau d'objet explicite dans vos bases de données pour leur sécurité.

----Custom Database Roles

/* CREATE A NEW ROLE  -- Execute to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Execute
GRANT EXECUTE TO db_All_StoredProc_Execute

/* CREATE A NEW ROLE  -- Alter to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_Alter
GRANT ALTER ANY SCHEMA TO db_All_StoredProc_Alter

/* CREATE A NEW ROLE  -- View Definition to all stored procs including newly created ones*/
-- Database specific
CREATE ROLE db_All_StoredProc_View
GRANT VIEW DEFINITION TO db_All_StoredProc_View

/* CREATE A NEW ROLE - Any schema alter and create procedure permissions */
-- Database specific
CREATE ROLE db_All_CreateProc_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateProc_AlterSchema
GRANT CREATE PROCEDURE TO db_All_CreateProc_AlterSchema
GO

/* CREATE A NEW ROLE - Any schema alter and create table permissions */
-- Database specific
CREATE ROLE db_All_CreateTable_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateTable_AlterSchema
GRANT CREATE TABLE TO db_All_CreateTable_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create function permissions */
-- Database specific
CREATE ROLE db_All_CreateFunction_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateFunction_AlterSchema
GRANT CREATE FUNCTION TO db_All_CreateFunction_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create aggregate permissions */
-- Database specific
CREATE ROLE db_All_CreateAggregate_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateAggregate_AlterSchema
GRANT CREATE AGGREGATE TO db_All_CreateAggregate_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create view permissions */
-- Database specific
CREATE ROLE db_All_CreateView_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateView_AlterSchema
GRANT CREATE VIEW TO db_All_CreateView_AlterSchema

/* CREATE A NEW ROLE - Any schema alter and create schema permissions */
-- Database specific
CREATE ROLE db_All_CreateSchema_AlterSchema
GRANT ALTER ANY SCHEMA TO db_All_CreateSchema_AlterSchema
GRANT CREATE SCHEMA TO db_All_CreateSchema_AlterSchema

Je voulais également partager un rôle db_DDLAdmin_Restriction que vous voudrez peut-être envisager de créer autrement avec DENY explicite pour restreindre ce que db_ddladmin donne accès à afin que vous puissiez au moins le créer sur les bases de données où vous leur accordez ce rôle et définir le DENY explicite pour les types d'objets réels, etc. auxquels vous ne voulez pas qu'ils aient accès.

Par exemple, si vous savez qu'ils vont certainement créer des procédures et des fonctions stockées, vous pouvez exclure DENY CREATE FUNCTION, DENY CREATE PROCEDURE, DENY ALTER ANY SCHEMA.

---Create ddladmin restriction custom DB role
DENY ALTER ANY Assembly                    TO db_DDLAdmin_Restriction
DENY ALTER ANY ASYMMETRIC KEY              TO db_DDLAdmin_Restriction
DENY ALTER ANY CERTIFICATE                 TO db_DDLAdmin_Restriction
DENY ALTER ANY CONTRACT                    TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE DDL TRIGGER        TO db_DDLAdmin_Restriction
DENY ALTER ANY DATABASE EVENT NOTIFICATION TO db_DDLAdmin_Restriction
DENY ALTER ANY DATASPACE                   TO db_DDLAdmin_Restriction
DENY ALTER ANY FULLTEXT CATALOG            TO db_DDLAdmin_Restriction
DENY ALTER ANY MESSAGE TYPE                TO db_DDLAdmin_Restriction
DENY ALTER ANY REMOTE SERVICE BINDING      TO db_DDLAdmin_Restriction
DENY ALTER ANY ROUTE                       TO db_DDLAdmin_Restriction
DENY ALTER ANY SCHEMA                      TO db_DDLAdmin_Restriction
DENY ALTER ANY SERVICE                     TO db_DDLAdmin_Restriction
DENY ALTER ANY SYMMETRIC KEY               TO db_DDLAdmin_Restriction
DENY CHECKPOINT                            TO db_DDLAdmin_Restriction
DENY CREATE AGGREGATE                      TO db_DDLAdmin_Restriction
DENY CREATE DEFAULT                        TO db_DDLAdmin_Restriction
DENY CREATE FUNCTION                       TO db_DDLAdmin_Restriction
DENY CREATE PROCEDURE                      TO db_DDLAdmin_Restriction
DENY CREATE QUEUE                          TO db_DDLAdmin_Restriction
DENY CREATE RULE                           TO db_DDLAdmin_Restriction
DENY CREATE SYNONYM                        TO db_DDLAdmin_Restriction
DENY CREATE TABLE                          TO db_DDLAdmin_Restriction
DENY CREATE TYPE                           TO db_DDLAdmin_Restriction
DENY CREATE VIEW                           TO db_DDLAdmin_Restriction
DENY CREATE XML SCHEMA COLLECTION          TO db_DDLAdmin_Restriction
DENY REFERENCES                            TO db_DDLAdmin_Restriction
GO
16
Pimp Juice IT

À l'aide d'un script SQL pour répertorier toutes les autorisations, je suis allé créer des utilisateurs pour chaque cas.

EXECUTE AS USER = 'test_user'
SELECT 
    permission_name 
FROM fn_my_permissions(null, 'DATABASE')
ORDER BY subentity_name, permission_name
REVERT;

J'ai ensuite comparé les résultats, et suis arrivé à la liste suivante, avec la documentation principalement msdn (toutes les citations non spécifiquement référencées proviennent du lien msdn).
Vous trouverez ci-dessous une partie de la documentation que j'ai utilisée pour informer les personnes qui perdraient les autorisations dbo quoi exactement qu'ils perdaient.

[~ # ~] modifier [~ # ~]

Confère la possibilité de modifier les propriétés, sauf la propriété, d'un élément sécurisable particulier. Lorsqu'elle est accordée sur une étendue, ALTER confère également la possibilité de modifier, créer ou supprimer tout élément sécurisable contenu dans cette étendue. Par exemple, l'autorisation ALTER sur un schéma inclut la possibilité de créer, modifier et supprimer des objets du schéma.

MODIFIER TOUT RÔLE D'APPLICATION
MODIFIER TOUT AUDIT DE BASE DE DONNÉES
MODIFIER TOUT RÔLE
MODIFIER TOUT UTILISATEUR

Confère la possibilité de créer, modifier ou supprimer des instances individuelles de la base de données sécurisable. Par exemple, ALTER ANY SCHEMA confère la possibilité de créer, modifier ou supprimer n'importe quel schéma dans la base de données.

Rôles d'application sont des principes de base de données qui permettent à une application de s'exécuter avec ses propres autorisations de type utilisateur.

Audit une instance de SQL Server ou d'une base de données SQL Server implique le suivi et la journalisation des événements qui se produisent sur le système. L'objet de spécification d'audit au niveau de la base de données appartient à un audit. Vous pouvez créer une spécification d'audit de base de données par base de données SQL Server par audit.

Rôles de base de données sont utilisés pour gérer facilement les autorisations dans vos bases de données, SQL Server fournit plusieurs rôles qui sont des entités de sécurité qui regroupent d'autres entités. Ils sont comme des groupes dans le système d'exploitation Microsoft Windows. Les rôles au niveau de la base de données sont étendus à la base de données dans leur étendue d'autorisations.

[~ # ~] authentifiez [~ # ~]
Trouvé en msdn.

Les autorisations AUTHENTICATE & AUTHENTICATE SERVER ne sont utilisées que lorsque vous utilisez EXECUTE AS dans des scénarios de bases de données croisées et d'accès au serveur (respectivement).

BASE DE DONNÉES DE SAUVEGARDE
JOURNAL DE SAUVEGARDE

CONNECTER LA RÉPLICATION

Utilisé pour les autorisations réplication de la base de données .

[~ # ~] contrôle [~ # ~]

Confère des capacités de type propriété au bénéficiaire. Le bénéficiaire a effectivement toutes les autorisations définies sur le sécurisable. Un principal qui a reçu CONTROL peut également accorder des autorisations sur le sécurisable.

CRÉER UN RÔLE

Confère au bénéficiaire la possibilité de créer la base de données sécurisable.

[~ # ~] showplan [~ # ~]

Les autorisations Showplan sont utilisées pour diverses options de l'instruction Showplan SET lorsqu'elles sont utilisées avec des lots Transact-SQL .

NOTIFICATIONS DE DEMANDE D'INSCRIPTION

Documentation sur les notifications de requête.

Basées sur l'infrastructure Service Broker, les notifications de requête permettent aux applications d'être notifiées lorsque les données ont changé. Cette fonctionnalité est particulièrement utile pour les applications qui fournissent un cache d'informations provenant d'une base de données, telle qu'une application Web, et doivent être notifiées lorsque les données source sont modifiées.

ACCEPTEZ LA PROPRIÉTÉ

Permet au bénéficiaire de s'approprier la valeur mobilière sur laquelle il est octroyé.

AFFICHER L'ÉTAT DE LA BASE DE DONNÉES

Utilisé pour afficher Vues et fonctions de gestion dynamique (Transact-SQL) .

AFFICHER LA DÉFINITION

Documentation sur voir les autorisations de définition.

L'autorisation VIEW DEFINITION permet à un utilisateur de voir les métadonnées du sécurisable sur lequel l'autorisation est accordée. Cependant, l'autorisation VIEW DEFINITION ne confère pas l'accès au sécurisable lui-même. Par exemple, un utilisateur qui ne bénéficie que de l'autorisation VIEW DEFINITION sur une table peut voir les métadonnées liées à la table dans la vue de catalogue sys.objects. Cependant, sans autorisations supplémentaires telles que SELECT ou CONTROL, l'utilisateur ne peut pas lire les données de la table.

8
Reaces