Quanto è pericoloso concedere l'autorizzazione ALTER TABLE?

Immagina il seguente scenario

CREATE DATABASE test

GO

USE test;    

CREATE TABLE dbo.Customer
  (
     CustomerId   INT,
     Email        VARCHAR(100),
     SensitiveData VARCHAR(20)
  );

INSERT INTO dbo.Customer
VALUES     (1,'abc@foo.com','12346789');

Ad un certo punto viene scritto un processo ETL che esegue alcune attività nel testdatabase.

CREATE USER etlUser WITHOUT LOGIN; /*For demo purposes*/

CREATE TABLE dbo.StagingTable
  (
     StagingTableId INT,
     SomeData       VARCHAR(100),
  )

GRANT UPDATE,INSERT,DELETE,SELECT,ALTER ON dbo.StagingTable TO etlUser;

DENY SELECT ON dbo.Customer TO etlUser;
DENY SELECT ON dbo.Customer (SensitiveData) TO etlUser; /*For good measure*/

EtlUser non dovrebbe avere le autorizzazioni per la Customertabella (e certamente non per la SensitiveDatacolonna), quindi questi sono esplicitamente negati sopra.

Il processo ETL viene troncato, dbo.StagingTablepertanto vengono concesse le ALTERautorizzazioni per la tabella.

Questo è segnalato durante un controllo di sicurezza. Quanto è pericoloso questo scenario?

Abbastanza pericoloso ...

Oltre all'ovvia autorizzazione a modificare la struttura di StagingTablese stessa, l' ALTER TABLEautorizzazione consente loro di creare trigger sul tavolo. Quindi, in questo caso, attraverso il concatenamento della proprietà, entrambi sono in grado di visualizzare i dati sensibili dei clienti (nonostante le DENYautorizzazioni esplicite ) ed eseguire atti di vandalismo su questa seconda tabella.

EXECUTE AS user='etlUser'

GO

CREATE OR ALTER TRIGGER TR ON dbo.StagingTable AFTER UPDATE AS 
/*Exposure of sensitive data*/
SELECT * FROM dbo.Customer;

/*Vandalism*/
DELETE FROM dbo.Customer;

go

--Fire the trigger
UPDATE dbo.StagingTable SET SomeData = SomeData WHERE 1=0;

REVERT

Oltre a poter aggiungere trigger, l' autorizzazione ALTER TABLE consente anche:

1. Disabilitazione dei trigger (evitare audit trail)
2. Disabilita i vincoli (consentendo dati errati)
3. Modifica delle contraffazioni (consentendo dati errati)
4. Modifica delle definizioni delle colonne (modifica tipo di dati, dimensione massima, nullità)
5. Aggiungi una colonna calcolata che chiama un UDF T-SQL (rendendo molto difficile ottenere un piano parallelo, che potrebbe facilmente danneggiare le prestazioni)

Permette anche di rimuovere le colonne, ma è probabile che non passi inosservato (poiché sembra che qui stiamo cercando potenziali azioni più ingannevoli che dannose).

Fortunatamente, non è mai necessario concedere questa autorizzazione a nessuno, né è necessario racchiuderlo in una procedura memorizzata che utilizza la EXECUTE ASclausola (generalmente seguita da 'dbo'o OWNER). La firma del modulo consente una facile astrazione di azioni privilegiate dietro il codice firmato (procedure memorizzate, trigger, UDF scalari e TVF multiistruzione). Ho un codice di esempio che mostra come eseguire ciò nelle seguenti risposte, qui su DBA.SE:

• Autorizzazione SQL per troncare la tabella
• Autorizzazioni di SQL Server TRUNCATE TABLE

La differenza tra queste due risposte è l'autorizzazione concessa all'utente basato sulla firma. L'autorizzazione da concedere (o ruolo DB da aggiungere) dipende dall'ambito di ciò che è necessario. Se hai bisogno solo dell'autorizzazione per una singola tabella, concedi solo ALTERquella tabella. Se è necessaria l'autorizzazione per tutte le tabelle in uno schema specifico, non concedere l'autorizzazione a singole tabelle, ma concedere invece l'autorizzazione allo schema stesso. E così via.

La firma del modulo prevede alcuni passaggi aggiuntivi rispetto alla creazione di uno schema specifico per l'utente ETL o all'utilizzo della EXECUTE ASclausola, ma:

1. è davvero solo una semplice copia e incolla dato che il codice è disponibile in entrambe le risposte collegate sopra e
2. è certamente l'opzione più sicura disponibile. Consente solo tale operazione tramite quel pezzo di codice e solo a quelli a cui è stata concessa l' EXECUTEautorizzazione per quel codice. Essere un proprietario dello schema consente determinate autorizzazioni implicite che non sono necessarie. E, usando EXECUTE AS 'dbo'o EXECUTE AS OWNER(supponendo che il proprietario lo sia dbo) si darà a tutto il processo , da quel momento in poi, le dboautorizzazioni, non solo la stored procedure / trigger / funzione con cui si è utilizzato EXECUTE AS. La firma del modulo limita le autorizzazioni solo al codice che hai firmato e non a qualsiasi codice chiamato dal codice firmato.

Una pratica migliore sarebbe quella di creare uno schema di gestione temporanea, di proprietà dell'utente ETL. Quindi il processo ETL può troncare le tabelle, disabilitare i vincoli, eseguire il cambio di partizione, ecc. All'interno dello schema di gestione temporanea. L'utente ETL avrebbe bisogno solo di autorizzazioni limitate per gli altri schemi.

È inoltre possibile utilizzare un ruolo di database anziché un singolo utente.

Ovviamente puoi anche consentire al tuo utente limitato di eseguire troncamenti di tabella con una procedura memorizzata di proprietà di dbo, come questa:

create procedure truncate_t 
with execute as owner
as
begin
  truncate table t;
end