Autorizzazioni DDL_admin vs db_owner

Sto assumendo un progetto che prevede la rimozione e la limitazione delle autorizzazioni di tutti gli utenti del database nella nostra server farm. (momenti divertenti)

Una delle autorizzazioni attualmente limitate sono le autorizzazioni db_owner.
Questa autorizzazione viene esaminata caso per caso, ma una modifica comune è quella di sostituire le autorizzazioni db_owner con le seguenti:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Vorrei definire la differenza esatta tra i due (per informare i clienti).
Tuttavia, per quanto posso dire, la differenza tra i due dovrebbe essere:

• Autorizzazioni db_accessadmin
• autorizzazioni db_backupoperator
• autorizzazioni db_securityadmin

Quindi, in effetti avrebbero perso:
[ALTER ANY USER]
[CREATE SCHEMA]
[BACKUP DATABASE], [BACKUP LOG], [CHECKPOINT]
[ALTER ANY APPLICATION ROLE],[ALTER ANY ROLE]
[DROP DATABASE]

C'è qualcos'altro che un utente perderebbe una volta che db_owner è sostituito dai quattro ruoli precedenti?
Questo in realtà serve molto a uno scopo di sicurezza saggio?

db_ddladmin vs db_owner

Da quello che posso dire da ciò che ho testato e letto, per la maggior parte il tuo elenco sembra accurato tranne db_ddladminche ti consente CREATE SCHEMA. Ho confermato che le altre autorizzazioni di sicurezza che hai elencato sono state effettivamente negate.

Negato solo con DDLADMIN:

[ALTER ANY USER]

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

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

[DROP DATABASE]

Notando che il. . .

1. db_datareaderconsentirà l' SELECTaccesso a tutte le tabelle
2. db_datarwriterpermetterà INSERT, UPDATEe DELETEl'accesso a tutte le tabelle
3. db_executorconsentirà l' EXECUTEaccesso a tutti gli oggetti eseguibili

Inoltre, potrebbe essere necessario disporre delle autorizzazioni per il ruolo db_ddladmin. . .

Nota: dal momento che hai così tante versioni diverse di SQL Server dal 2005 al 2014, potrebbe essere meglio che un piccolo gruppo di utenti lo provi inizialmente per vedere chi urla per appianare eventuali nodi, ecc.

• Gli oggetti che possiedono con questo ruolo non saranno di proprietà di DBO, quindi potresti dover affrontare i problemi di cambio di proprietà se c'è mai un problema con qualcosa a questo livello. Non sono sicuro al 100% che questo sarebbe un problema, ma vale la pena menzionarlo per ogni evenienza.

  Fonte: catene di proprietà

• Con questo ruolo (può variare a seconda della versione di SQL Server) potrebbero essere in grado di aggiungere principi di sicurezza SQL definiti nel database corrente agli oggetti che possiedono ancora, semplicemente non tutti gli oggetti (quelli che non possiedono) né aggiungere un nuovo server livello definito principale a livello di DB.

Inoltre, potrebbe non significare avere autorizzazioni di ruolo DBO. . .

Nota: dal momento che hai così tante versioni diverse di SQL Server dal 2005 al 2014, potrebbe essere meglio che un piccolo gruppo di utenti lo provi inizialmente per vedere chi urla per appianare eventuali nodi, ecc.

• Non avere il ruolo DBO potrebbe impedire il popolamento o l'apertura senza errori di alcune interfacce GUI del designer SSMS (che variano la versione di SQL Server) (ad es. Quando si modificano tabelle o colonne attraverso la GUI) anche se lo si fa tramite T-SQL funziona e le autorizzazioni sono in atto . In alcune versioni di SQL Server questo può essere risolto consentendo GRANT VIEW DEFINITIONladdove si tratti di un problema e può anche essere solo un avviso solo su alcune versioni di SQL Server.

  risorse

  • Non si è effettuato l'accesso come proprietario del database o come utente membro del ruolo db_owner. Non sarai in grado di salvare le modifiche alle tabelle che non possiedi.

  • db_ddladmin Il ruolo non consente l'uso delle funzioni di "progettazione" in SSMS

    _{"Cerchiamo di impedire agli utenti / sviluppatori di eseguire il dbo nei loro database QA il più possibile. Uno dei problemi è che devono ancora essere in grado di creare e modificare oggetti di database come le tabelle degli utenti. Molti sviluppatori sono nuovi a MS SQL e quindi tendono a rimanere con la GUI (SSMS) per questo tipo di lavoro. Il problema sorge quando concediamo loro db_ddladmin (non dbo) e non sono più in grado di modificare tabelle o colonne tramite la GUI di progettazione tabelle. devono impiegare più tempo per apprendere i comandi TSQL e la loro sintassi (di cui potrebbero non aver mai più bisogno) o per coinvolgere il team DBA che prende tempo lontano dalle altre nostre attività.}

    _{Non so se si tratta di un bug o di una richiesta di funzionalità, ma lo considero un bug poiché l'utente dispone di autorizzazioni sufficienti per modificare la tabella tramite TSQL ma la GUI fornisce loro messaggi che affermano:}

    _{" Non si è effettuato l'accesso come proprietario del database o amministratore di sistema. Potrebbe non essere possibile salvare le modifiche alle tabelle di cui non si è proprietari." E "La tabella [schema].[table]è impostata in sola lettura, l'utente non dispone di diritti sufficienti su questa tabella. "}

    _{Una traccia sembra indicare che check è un is_member ('db_owner') che precluderà i membri di db_ddladmin anche se in realtà dispongono delle autorizzazioni per modificare l'oggetto. Microsoft SQL Server Management Studio "}

    ---

    _{Inserito dall'agente DBA il 25/01/2010 alle 07:06}

    _{Ho avuto un problema simile e sono riuscito a risolverlo eseguendo la seguente sovvenzione}

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

altre considerazioni

Dal momento che dichiari che questo viene rivisto caso per caso

Una delle autorizzazioni attualmente limitate sono le autorizzazioni db_owner.

Questa autorizzazione viene esaminata caso per caso, ma una modifica comune è quella di sostituire le autorizzazioni db_owner con le seguenti:

• db_datareader
• db_datawriter
• db_ddladmin
• db_executor

Hai preso in considerazione la possibilità di creare ruoli personalizzati aggiuntivi per un accesso a livello di DB "tutto oggetto" di cui ogni persona ha bisogno piuttosto che concedergli il db_ddladminruolo in quanto probabilmente fornirà loro più di quello di cui hanno effettivamente bisogno anche per gli oggetti a livello di DB.

Di solito do esattamente ciò che è necessario e niente di più per loro di fare il loro lavoro e se c'è una necessità "normale" o "standard" di accesso agli oggetti a livello di DB a tutti gli oggetti in un DB, creo un ruolo DB personalizzato come il db_executorma vedi il mio esempio di seguito. In questo modo è possibile garantire alle persone ciò di cui hanno realmente bisogno per TUTTI gli oggetti DB in un determinato DB se non si ottiene esplicito livello di oggetto nei propri DB per la loro sicurezza.

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

Volevo anche condividere un ruolo db_DDLAdmin_Restriction che potresti prendere in considerazione per prendere in considerazione l'idea di creare altrimenti con esplicito DENYper limitare ciò a cui db_ddladmindare accesso in modo da poter almeno creare questo sui DB in cui concedi loro questo ruolo e imposta l'esplicito DENYper i tipi di oggetto effettivi , ecc. a cui non vuoi che abbiano accesso.

Ad esempio, se si sa che sarà sicuramente la creazione di stored procedure e funzioni, è possibile escludere 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 uno script SQL per elencare tutte le autorizzazioni, sono andato e ho creato utenti per ogni caso.

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

Ho quindi confrontato i risultati e sono arrivato al seguente elenco, con la documentazione principalmente da msdn (tutte le citazioni non specificatamente citate provengono dal collegamento msdn).
Di seguito è riportata una parte della documentazione che ho usato per informare le persone che avrebbero perso i permessi del dbo che cosa stavano perdendo.

ALTER

Conferisce la possibilità di modificare le proprietà, ad eccezione della proprietà, di un determinato elemento protetto. Se concesso su un ambito, ALTER offre anche la possibilità di alterare, creare o eliminare qualsiasi elemento sicuro contenuto in tale ambito. Ad esempio, l'autorizzazione ALTER su uno schema include la possibilità di creare, modificare e rilasciare oggetti dallo schema.

MODIFICA QUALSIASI RUOLO DELL'APPLICAZIONE
ALTER QUALSIASI AUDIT DI DATABASE
ALTER QUALSIASI RUOLO
ALTER QUALSIASI UTENTE

Conferisce la possibilità di CREARE, ALTER o DROP singole istanze di Database Securable. Ad esempio, ALTER ANY SCHEMA conferisce la possibilità di creare, modificare o eliminare qualsiasi schema nel database.

I ruoli dell'applicazione sono entità del database che consentono l'esecuzione di un'applicazione con autorizzazioni proprie simili a quelle dell'utente.

Il controllo di un'istanza di SQL Server o di un database SQL Server implica il tracciamento e la registrazione degli eventi che si verificano sul sistema. L'oggetto Specifica controllo a livello di database appartiene a un controllo. È possibile creare una specifica di controllo del database per database di SQL Server per controllo.

I ruoli del database vengono utilizzati per gestire facilmente le autorizzazioni nei database, SQL Server fornisce diversi ruoli che sono entità di sicurezza che raggruppano altre entità. Sono come gruppi nel sistema operativo Microsoft Windows. I ruoli a livello di database hanno ampie dimensioni di database nell'ambito delle autorizzazioni.

AUTENTICATO
Trovato in msdn.

Le autorizzazioni AUTHENTICATE & AUTHENTICATE SERVER vengono utilizzate solo quando si utilizza EXECUTE AS in scenari cross-database e di accesso al server (rispettivamente).

DATABASE
DI BACKUP REGISTRO DI BACKUP

CONNECT REPLICATION

Utilizzato per le autorizzazioni di replica del database .

CONTROLLO

Conferisce capacità simili alla proprietà sul beneficiario. L'affiliato ha effettivamente tutte le autorizzazioni definite sul sicuro. Un'entità a cui è stato concesso CONTROL può anche concedere autorizzazioni per la sicurezza.

CREA RUOLO

Conferisce all'utente autorizzato la possibilità di creare un database sicuro.

SHOWPLAN

Le autorizzazioni Showplan vengono utilizzate per varie opzioni dell'istruzione SET Showplan quando vengono utilizzate con batch Transact-SQL .

ISCRIVITI ALLE NOTIFICHE

Documentazione sulle notifiche di query.

Basate sull'infrastruttura di Service Broker, le notifiche delle query consentono alle applicazioni di essere avvisate quando i dati sono cambiati. Questa funzione è particolarmente utile per le applicazioni che forniscono una cache di informazioni da un database, come un'applicazione Web, e devono essere informate quando i dati di origine vengono modificati.

ASSUMERE LA PROPRIETÀ

Consente al beneficiario di assumere la proprietà del titolo sul quale è concesso.

VISUALIZZA STATO DATABASE

Utilizzato per visualizzare le viste e le funzioni di gestione dinamica (Transact-SQL) .

VISUALIZZA DEFINIZIONE

Documentazione sulle autorizzazioni di definizione della vista.

L'autorizzazione VIEW DEFINITION consente a un utente di visualizzare i metadati del dispositivo di sicurezza su cui viene concessa l'autorizzazione. Tuttavia, l'autorizzazione VIEW DEFINITION non conferisce l'accesso al sicuro stesso. Ad esempio, un utente a cui è concessa solo l'autorizzazione VISUALIZZA DEFINIZIONE su una tabella può visualizzare i metadati relativi alla tabella nella vista del catalogo sys.objects. Tuttavia, senza autorizzazioni aggiuntive come SELECT o CONTROL, l'utente non può leggere i dati dalla tabella.