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:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

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 effet , 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 fait une grande partie de la sécurité?

db_ddladmin vs db_owner

D'après ce que je peux dire de ce que j'ai testé et lu, pour la plupart, votre liste semble exacte, sauf db_ddladminque vous le permet 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_datareaderpermettra l' SELECTaccès à toutes les tables
2. db_datarwriterpermettra INSERT, UPDATEet l' DELETEaccès à toutes les tables
3. db_executorpermettra l' EXECUTEaccès à 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 qu'un petit groupe d'utilisateurs teste cela initialement pour voir qui hurle pour aplanir les défauts, etc.

• Les objets qu'ils possèdent avec ce rôle n'appartiendront pas à DBO, vous devrez donc peut-être faire face à des problèmes de changement de propriété en cas de 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 (ceux qu'ils ne possèdent pas) ni ajouter un nouveau serveur principal défini au niveau de la base de données.

De plus, le fait de ne pas disposer des 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 qu'un petit groupe d'utilisateurs teste cela initialement pour voir qui hurle pour aplanir les défauts, etc.

• Le fait de ne pas avoir le rôle DBO peut empêcher certaines interfaces GUI du concepteur SSMS (la version de SQL Server variant) 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 cela se fait via des travaux T-SQL et que les autorisations sont en place . Dans certaines versions de SQL Server, cela peut être résolu en autorisant GRANT VIEW DEFINITIONlà où il s'agit d'un problème et cela peut également être juste un avertissement uniquement 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 dont vous n'êtes pas propriétaire.

  • db_ddladmin Le rôle 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 donc ont tendance à s'en tenir à l'interface graphique (SSMS) pour ce type de travail. Le problème se pose lorsque nous leur accordons db_ddladmin (pas dbo) et 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 qui ne vous appartiennent pas." ET "La table [schema].[table]est définie 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 plus d'accès au niveau DB "tous les objets" dont chaque personne a besoin plutôt que de leur accorder le db_ddladminrôle, car cela leur donnera probablement plus que ce dont ils ont réellement besoin pour les objets de niveau DB également.

Je donne généralement 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" pour l'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_executormais 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 explicite DENYpour restreindre ce qui db_ddladmindonne 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 l'explicite DENYpour les types d'objets réels , etc. vous ne voulez pas qu'ils y aient accès.

Par exemple, si vous savez qu'ils vont certainement créer des procédures stockées et fonctions, 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

À 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 je suis arrivé à la liste suivante, avec de la documentation provenant principalement de 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 de ce qu'elles perdaient exactement .

MODIFIER

Confère la possibilité de modifier les propriétés, sauf la propriété, d'un élément sécurisable particulier. Lorsqu'il est accordé 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, de modifier et de 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.

Les 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.

L'audit d' 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.

Les 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.

AUTHENTIFIER
Trouvé dans 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).

JOURNAL DE SAUVEGARDE DE LA BASE DE DONNÉES

CONNECTER LA RÉPLICATION

Utilisé pour les autorisations de réplication de 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 .

S'INSCRIRE AUX NOTIFICATIONS DE DEMANDE

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 à partir d'une base de données, telle qu'une application Web, et doivent être notifiées lorsque les données source sont modifiées.

PRENDRE POSSESSION

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

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

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

VOIR LA DÉFINITION

Documentation sur les autorisations de définition de vue.

L'autorisation VIEW DEFINITION permet à un utilisateur de voir les métadonnées de l'élément 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.