DDL_admin vs db_owner permisos

Me estoy haciendo cargo de un proyecto que implica eliminar y limitar los permisos de todos los usuarios de la base de datos en nuestra granja de servidores. (Tiempos divertidos)

Uno de los permisos actualmente limitados son los permisos db_owner.
Este permiso se está revisando caso por caso, pero un cambio común es reemplazar los permisos db_owner con lo siguiente:

db_datareader
db_datawriter
db_ddladmin
db_executor

Me gustaría definir la diferencia exacta entre los dos (para informar a los clientes).
Sin embargo, por lo que puedo decir, la diferencia entre los dos debería ser:

permisos db_accessadmin
permisos db_backupoperator
permisos db_securityadmin

Así que, en efecto, que perderían:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

¿Hay algo más que un usuario perdería una vez que db_owner sea reemplazado por los cuatro roles anteriores?
¿Esto realmente sirve para un gran propósito de seguridad?

sql-server permissions Reaces
fuente

Respuestas:

db_ddladmin vs db_owner

Por lo que puedo decir de lo que probé y leí, en su mayor parte su lista se ve precisa, excepto db_ddladminque lo permite CREATE SCHEMA. Confirmé que los otros permisos de seguridad que enumeró fueron denegados.

Denegado solo con DDLADMIN:

[ALTER ANY USER]

[BACKUP DATABASE]` [BACKUP LOG]`[CHECKPOINT]

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

[DROP DATABASE]

Tomando nota de que el. . .

db_datareaderpermitirá el SELECTacceso a todas las mesas
db_datarwriterpermitirá INSERT, UPDATEy DELETEacceso a todas las tablas
db_executorpermitirá el EXECUTEacceso a todos los objetos ejecutables

Además, tener permisos de rol db_ddladmin puede significar. . .

Nota: Dado que tiene tantas versiones diferentes de SQL Server de 2005 a 2014, puede ser mejor que un pequeño grupo de usuarios pruebe esto inicialmente para ver quién grita para solucionar cualquier problema, etc.

Los objetos que poseen con este rol no serán propiedad de DBO, por lo que es posible que tenga que lidiar con problemas de cambio de propiedad si alguna vez hay un problema con algo a este nivel. No estoy 100% seguro de que esto sea un problema, pero vale la pena mencionarlo por si acaso.

Fuente: cadenas de propiedad
Con esta función (puede variar según la versión de SQL Server) , pueden agregar los principios de seguridad de SQL definidos en la base de datos actual a los objetos que aún poseen, pero no todos los objetos (que no son de su propiedad) ni agregar un nuevo servidor -nivel principal definido al nivel de base de datos.

Además, no tener permisos de rol DBO puede significar. . .

Nota: Dado que tiene tantas versiones diferentes de SQL Server de 2005 a 2014, puede ser mejor que un pequeño grupo de usuarios pruebe esto inicialmente para ver quién grita para solucionar cualquier problema, etc.

No tener el rol DBO puede evitar que ciertas interfaces GUI del diseñador SSMS (la versión de SQL Server varíe) se llenen o abran sin error (por ejemplo, al modificar tablas o columnas a través de la GUI) aunque hacerlo a través de T-SQL funciona y los permisos están vigentes . En algunas versiones de SQL Server, esto puede resolverse permitiendo GRANT VIEW DEFINITIONque esto sea un problema y también puede ser solo una advertencia en ciertas versiones de SQL Server.

Recursos
- No ha iniciado sesión como propietario de la base de datos o como usuario miembro de la función db_owner. No podrá guardar los cambios en las tablas que no le pertenecen.
- El rol db_ddladmin no permite el uso de funciones de "diseño" en SSMS
  _{"Tratamos de evitar dar dbo a los usuarios / desarrolladores en sus bases de datos de control de calidad tanto como podamos. Uno de los problemas con esto es que todavía necesitan poder crear y modificar objetos de bases de datos como tablas de usuarios. Muchos desarrolladores son nuevos en MS SQL y, por lo tanto, tienden a quedarse con la GUI (SSMS) para este tipo de trabajo. El problema surge cuando les otorgamos db_ddladmin (no dbo) y ya no pueden modificar tablas o columnas a través de la GUI del diseñador de tablas. tienen que tomarse un tiempo adicional para aprender los comandos TSQL y su sintaxis (que tal vez nunca más vuelvan a necesitar) o comprometerse con el equipo de DBA, lo que les quita tiempo a nuestras otras actividades.}
  
  _{No sé si esto es un error o una solicitud de función, pero lo considero un error ya que el usuario tiene permisos suficientes para alterar la tabla a través de TSQL, pero la GUI les da mensajes que indican:}
  
  _{" No ha iniciado sesión como propietario de la base de datos o administrador del sistema. Es posible que no pueda guardar los cambios en las tablas que no le pertenecen". Y "La tabla [schema].[table]está configurada para solo lectura, el usuario no tiene suficientes derechos sobre esta tabla " .}
  
  _{Un rastro parece apuntar a que la comprobación es is_member ('db_owner'), lo que impedirá que los miembros de db_ddladmin, aunque de hecho tengan permisos para modificar el objeto. Microsoft SQL Server Management Studio "}
  
  _{_{Publicado por el Agente DBA el 25/01/2010 a las 7:06 a.m.}}
  
  _{Tuve un problema similar y logré resolverlo realizando la siguiente subvención}
```
GRANT view definition on schema:: <schemaname> to <username>
```

Otras Consideraciones

Como usted afirma que esto se está revisando caso por caso

Uno de los permisos actualmente limitados son los permisos db_owner.

Este permiso se está revisando caso por caso, pero un cambio común es reemplazar los permisos db_owner con lo siguiente:

db_datareader

db_datawriter

db_ddladmin

db_executor

¿Ha considerado crear roles personalizados adicionales para obtener más acceso a nivel de base de datos de "todos los objetos" que cada persona necesita en lugar de otorgarles el db_ddladmin rol, ya que eso probablemente les dará más de lo que realmente necesitan para objetos de nivel de base de datos también.

Por lo general, les doy exactamente lo que se necesita y nada más para que hagan su trabajo y si hay una necesidad "habitual" o "estándar" de acceso a objetos de nivel de base de datos a todos los objetos en una base de datos, creo un rol de base de datos personalizado como el db_executorpero mira mi ejemplo a continuación. De esta manera, puede otorgar a las personas lo que realmente necesitan para TODOS los objetos de base de datos en una base de datos particular si no obtiene un nivel de objeto explícito en sus bases de datos para su seguridad.

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

También quería compartir una función db_DDLAdmin_Restriction que quizás desee considerar crear de otra manera con explícito DENYpara restringir a qué le db_ddladminda acceso, por lo que al menos podría crear esto en los DB donde les otorga esta función y establecer lo explícito DENYpara los tipos de objeto reales , etc. a los que no desea que tengan acceso.

Por ejemplo, si usted sabe que definitivamente van a ser la creación de procedimientos almacenados y funciones, puede excluir 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

Pimp Juice IT
fuente

Utilizando un script SQL para enumerar todos los permisos, fui y creé usuarios para cada caso.

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

Luego comparé los resultados y llegué a la siguiente lista, con documentación de msdn principalmente (cualquier cita que no se mencione específicamente es del enlace msdn).
A continuación se muestra parte de la documentación que utilicé para informar a las personas que estarían perdiendo los permisos dbo qué estaban perdiendo exactamente .

ALTERAR

Confiere la capacidad de cambiar las propiedades, excepto la propiedad, de un asegurable particular. Cuando se otorga en un ámbito, ALTER también otorga la capacidad de alterar, crear o descartar cualquier elemento de seguridad que esté contenido dentro de ese ámbito. Por ejemplo, el permiso ALTER en un esquema incluye la capacidad de crear, alterar y soltar objetos del esquema.

ALTERAR CUALQUIER ROL DE LA APLICACIÓN
ALTERAR CUALQUIER BASE DE DATOS AUDITORÍA
ALTERAR CUALQUIER ROL
ALTERAR A CUALQUIER USUARIO

Confiere la capacidad de CREAR, ALTERAR o BAJAR instancias individuales de la base de datos asegurable. Por ejemplo, ALTERAR CUALQUIER ESQUEMA confiere la capacidad de crear, alterar o descartar cualquier esquema en la base de datos.

Los roles de aplicación son entidades de base de datos que permiten que una aplicación se ejecute con sus propios permisos de usuario.

Revisión de cuentas una instancia de SQL Server o una base de datos de SQL Server implica el seguimiento y registro de eventos que ocurren en el sistema. El objeto de especificación de auditoría de nivel de base de datos pertenece a una auditoría. Puede crear una especificación de auditoría de base de datos por base de datos de SQL Server por auditoría.

Los roles de base de datos se usan para administrar fácilmente los permisos en sus bases de datos, SQL Server proporciona varios roles que son entidades de seguridad que agrupan a otras entidades. Son como grupos en el sistema operativo Microsoft Windows. Los roles de nivel de base de datos abarcan toda la base de datos en su alcance de permisos.

AUTENTICADO
Encontrado en msdn.

Los permisos AUTENTICATE y AUTHENTICATE SERVER solo se usan cuando se utiliza EXECUTE AS en escenarios de bases de datos cruzadas y acceso al servidor (respectivamente).

BASE DE DATOS
DE RESPALDO REGISTRO DE RESPALDO

CONECTAR REPLICACIÓN

Se utiliza para los permisos de replicación de bases de datos .

CONTROLAR

Confiere capacidades de propiedad al concesionario. El concesionario tiene efectivamente todos los permisos definidos en el asegurable. Un principal al que se le ha otorgado CONTROL también puede otorgar permisos en el asegurable.

CREAR PAPEL

Otorga al concesionario la capacidad de crear la base de datos asegurable.

SHOWPLAN

Los permisos de Showplan se usan para varias opciones de instrucciones SET de Showplan cuando se usan con lotes de Transact-SQL .

SUSCRIBIR NOTIFICACIONES DE CONSULTA

Documentación sobre notificaciones de consultas.

Basado en la infraestructura de Service Broker, las notificaciones de consulta permiten que las aplicaciones sean notificadas cuando los datos han cambiado. Esta característica es particularmente útil para aplicaciones que proporcionan una memoria caché de información de una base de datos, como una aplicación web, y necesitan ser notificadas cuando se modifican los datos de origen.

TOMAR POSESIÓN

Permite al concesionario tomar posesión del asegurable en el que se otorga.

VER ESTADO DE BASE DE DATOS

Se usa para ver las vistas y funciones de administración dinámica (Transact-SQL) .

VER DEFINICIÓN

Documentación sobre permisos de definición de vista.

El permiso VIEW DEFINITION permite al usuario ver los metadatos del asegurable en el que se otorga el permiso. Sin embargo, el permiso VIEW DEFINITION no confiere acceso al asegurable en sí. Por ejemplo, un usuario al que se le concede solo el permiso VER DEFINICIÓN en una tabla puede ver los metadatos relacionados con la tabla en la vista de catálogo sys.objects. Sin embargo, sin permisos adicionales como SELECT o CONTROL, el usuario no puede leer los datos de la tabla.

Reaces
fuente