Permissões DDL_admin vs db_owner

Estou assumindo um projeto que envolve a remoção e limitação de permissões de todos os usuários do banco de dados em nosso farm de servidores. (momentos divertidos)

Uma das permissões atualmente limitadas são as permissões db_owner.
Essa permissão está sendo revisada caso a caso, mas uma mudança comum é substituir as permissões db_owner pelo seguinte:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Eu gostaria de definir a diferença exata entre os dois (para informar os clientes).
No entanto, até onde eu sei, a diferença entre os dois deve ser:

• Permissões db_accessadmin
• Permissões db_backupoperator
• Permissões db_securityadmin

Então, na verdade eles perderiam:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

Existe mais alguma coisa que um usuário perderia quando o db_owner fosse substituído pelas quatro funções acima?
Isso realmente serve a muitos propósitos de segurança?

db_ddladmin vs db_owner

Pelo que posso dizer pelo que testei e li, a maior parte da sua lista parece precisa, exceto que o db_ddladminpermite CREATE SCHEMA. Confirmei que as outras permissões de segurança que você listou foram realmente negadas.

Negado apenas com DDLADMIN:

[ALTER ANY USER]

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

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

[DROP DATABASE]

Observando que o. . .

1. db_datareaderpermitirá SELECTacesso a todas as tabelas
2. db_datarwriterpermitirá INSERT, UPDATEe DELETEacesso a todas as tabelas
3. db_executorpermitirá EXECUTEacesso a todos os objetos executáveis

Além disso, ter permissões de função db_ddladmin pode significar. . .

Nota: Como você tem tantas versões diferentes do SQL Server de 2005 a 2014, talvez seja melhor um pequeno conjunto de usuários testá-lo inicialmente para ver quem grita para resolver problemas, etc.

• Os objetos que eles possuem com essa função não serão de propriedade do DBO; portanto, talvez você precise lidar com problemas de propriedade, se houver algum problema com algo nesse nível. Não tenho 100% de certeza de que isso seria um problema, mas vale a pena mencionar por precaução.

  Fonte: Cadeias de Propriedade

• Com essa função (pode variar de acordo com a versão do SQL Server), eles podem adicionar princípios de segurança SQL definidos no banco de dados atual aos objetos que ainda possuem, mas nem todos os objetos (aqueles que não são de sua propriedade) nem adicionar um novo servidor principal definido por nível para o nível do banco de dados.

Além disso, não ter permissões de função DBO pode significar. . .

Nota: Como você tem tantas versões diferentes do SQL Server de 2005 a 2014, talvez seja melhor um pequeno conjunto de usuários testá-lo inicialmente para ver quem grita para resolver problemas, etc.

• Não ter a função DBO pode impedir que determinadas interfaces da GUI de designer do SSMS (versão do SQL Server varia) sejam preenchidas ou abertas sem erros (por exemplo, ao modificar tabelas ou colunas através da GUI), mesmo que isso seja feito através do T-SQL e as permissões estejam em vigor . Em algumas versões do SQL Server, isso pode ser resolvido, permitindo GRANT VIEW DEFINITIONque esse problema ocorra e também pode ser apenas um aviso apenas em determinadas versões do SQL Server.

  Recursos

  • Você não está logado como proprietário do banco de dados ou como um usuário membro da função db_owner. Você não poderá salvar as alterações nas tabelas que você não possui.

  • A função db_ddladmin não permite o uso de funções "design" no SSMS

    _{"Tentamos impedir o máximo de usuários / desenvolvedores dbo em seus bancos de dados de controle de qualidade. Um dos problemas é que eles ainda precisam criar e modificar objetos de banco de dados, como tabelas de usuários. Muitos desenvolvedores são novos no MS SQL e, portanto, tendem a ficar com a GUI (SSMS) para esse tipo de trabalho.O problema surge quando concedemos a eles db_ddladmin (não dbo) e eles não conseguem mais modificar tabelas ou colunas por meio da GUI do designer de tabelas. eles precisam dedicar mais tempo para aprender os comandos do TSQL e sua sintaxe (que talvez nunca mais precisem) ou envolver a equipe de DBA, que dedica algum tempo a outras atividades.}

    _{Não sei se é um bug ou uma solicitação de recurso, mas considero um bug, pois o usuário tem permissões suficientes para alterar a tabela via TSQL, mas a GUI fornece a eles mensagens informando:}

    _{" Você não está conectado como proprietário do banco de dados ou administrador do sistema. Talvez não seja possível salvar as alterações nas tabelas que você não possui." AND "A tabela [schema].[table]está configurada para somente leitura, o usuário não tem direitos suficientes nessa tabela " .}

    _{Um rastreio parece indicar que a verificação é um membro_do_db ('db_owner') que impedirá os membros do db_ddladmin, mesmo que eles tenham permissões para modificar o objeto. Microsoft SQL Server Management Studio "}

    ---

    _{Postado por Agent DBA em 25/01/2010 às 07:06}

    _{Eu tive um problema semelhante e consegui resolvê-lo executando a seguinte concessão}

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

outras considerações

Como você declara que isso está sendo analisado caso a caso

Uma das permissões atualmente limitadas são as permissões db_owner.

Essa permissão está sendo revisada caso a caso, mas uma mudança comum é substituir as permissões db_owner pelo seguinte:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Você já pensou em criar funções personalizadas adicionais para mais acesso no nível do banco de dados "todos os objetos" de que cada pessoa precisa, em vez de conceder a db_ddladminfunção, pois isso provavelmente lhes dará mais do que eles realmente precisam para objetos no nível do banco de dados.

Geralmente, dou exatamente o que é necessário e nada mais para que eles realizem seu trabalho e, se houver uma necessidade "usual" ou "padrão" de acesso a objetos no nível do banco de dados para todos os objetos em um banco de dados, crio uma função de banco de dados personalizada, como a db_executormas veja meu exemplo abaixo. Dessa forma, você pode conceder às pessoas o que elas realmente precisam para o objeto ALL DB em um DB específico, se você não estiver explicitando o nível do objeto nos DBs para segurança.

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

Eu também queria compartilhar uma função db_DDLAdmin_Restriction que você pode considerar criar de outra forma com explícita DENYpara restringir o que db_ddladmindá acesso, para que você possa pelo menos criar isso nos bancos de dados em que você lhes concede essa função e define o explícito DENYpara os tipos de objetos reais , etc., você não deseja que eles tenham acesso.

Por exemplo, se você sabe que vai ser definitivamente a criação de procedimentos armazenados e funções, você pode 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

Usando um script SQL para listar todas as permissões, criei usuários para cada caso.

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

Comparei os resultados e cheguei à lista a seguir, com documentação principalmente do msdn (quaisquer citações não especificamente referenciadas são do link msdn).
Abaixo está uma documentação que eu usei para informar as pessoas que estariam perdendo permissões de dbo o que exatamente estavam perdendo.

ALTERAR

Confere a capacidade de alterar as propriedades, exceto a propriedade, de um determinado passível de proteção. Quando concedido em um escopo, o ALTER também oferece a capacidade de alterar, criar ou eliminar qualquer segurança que esteja contida nesse escopo. Por exemplo, a permissão ALTER em um esquema inclui a capacidade de criar, alterar e descartar objetos do esquema.

ALTERAR QUALQUER PAPEL DE APLICATIVO ALTERAR
QUALQUER AUDITORIA DE BASE DE DADOS ALTERAR
QUALQUER PAPEL
ALTERAR QUALQUER USUÁRIO

Confere a capacidade de CREATE, ALTER ou DROP instâncias individuais do banco de dados protegível. Por exemplo, ALTER ANY SCHEMA confere a capacidade de criar, alterar ou eliminar qualquer esquema no banco de dados.

As funções de aplicativo são entidades de banco de dados que permitem que um aplicativo seja executado com suas próprias permissões semelhantes ao usuário.

A auditoria de uma instância do SQL Server ou de um banco de dados do SQL Server envolve o rastreamento e o registro de eventos que ocorrem no sistema. O objeto Especificação de auditoria no nível do banco de dados pertence a uma auditoria. Você pode criar uma especificação de auditoria de banco de dados por banco de dados SQL Server por auditoria.

As funções de banco de dados são usadas para gerenciar facilmente as permissões em seus bancos de dados; o SQL Server fornece várias funções que são entidades de segurança que agrupam outras entidades. Eles são como grupos no sistema operacional Microsoft Windows. As funções no nível do banco de dados têm todo o banco de dados em seu escopo de permissões.

AUTENTICADO
Encontrado no msdn.

As permissões AUTHENTICATE & AUTHENTICATE SERVER são usadas apenas ao usar EXECUTE AS em cenários de banco de dados cruzado e acesso ao servidor (respectivamente).

BACKUP DATABASE
BACKUP LOG

REPLICAÇÃO DE CONEXÃO

Usado para permissões de replicação de banco de dados .

AO CONTROLE

Confere ao proprietário do negócio recursos semelhantes a propriedade. O donatário tem efetivamente todas as permissões definidas no passível de proteção. Uma entidade que recebeu CONTROL também pode conceder permissões no que pode ser protegido.

CRIAR PAPEL

Confere ao usuário autorizado a capacidade de criar o Banco de Dados Protegível.

SHOWPLAN

As permissões do Showplan são usadas para várias opções de instrução SET do Showplan quando são usadas com lotes Transact-SQL .

ASSINAR NOTIFICAÇÕES DE CONSULTA

Documentação sobre notificações de consulta.

Criadas na infraestrutura do Service Broker, as notificações de consulta permitem que os aplicativos sejam notificados quando os dados forem alterados. Esse recurso é particularmente útil para aplicativos que fornecem um cache de informações de um banco de dados, como um aplicativo Web, e precisam ser notificados quando os dados de origem são alterados.

TOMAR POSSE

Permite que o beneficiário assuma a propriedade do passível de garantia ao qual é concedido.

VER ESTADO DA BASE DE DADOS

Usado para exibir modos de exibição e funções de gerenciamento dinâmico (Transact-SQL) .

VER DEFINIÇÃO

Documentação sobre permissões de definição de exibição.

A permissão VIEW DEFINITION permite que um usuário veja os metadados do protegível no qual a permissão é concedida. No entanto, a permissão VIEW DEFINITION não confere acesso ao próprio protegível. Por exemplo, um usuário que recebe apenas a permissão VIEW DEFINITION em uma tabela pode ver os metadados relacionados à tabela na exibição do catálogo sys.objects. No entanto, sem permissões adicionais, como SELECT ou CONTROL, o usuário não pode ler dados da tabela.