Perché BULK INSERT è considerato pericoloso?

Vorrei capire perché i team di sicurezza informatica in generale (più di un'organizzazione con cui ho avuto a che fare) non sono autorizzati a concedere BULK INSERT(ad es. TSQL) diritti alle applicazioni e ai programmatori di database? Non posso credere alla scusa "riempire l'abuso del disco", a meno che non mi manchi qualcosa, poiché il risultato finale non è diverso da un'applicazione che fa qualcosa del tipo:

for (long i = 0; i < LONG_MAX; ++i)
    executeSQL("INSERT INTO table VALUES(...)");

ed INSERTè un comando DML comune che chiunque può disporre di un'autorizzazione di scrittura di base può eseguire.

A beneficio di un'applicazione, BULK INSERTè molto più efficiente, più veloce e allevia il programmatore dalla necessità di analizzare i file al di fuori di SQL.

Modifica: originariamente ho posto questa domanda sul sito di sicurezza delle informazioni per un motivo - non sono i DBA che sono contrari all'uso di BULK INSERT, ma è "Information Assurance" (IA in breve - la gente della Cybersecurity) a forzare il problema. Lascerò che questa domanda stufi per un altro giorno o due, ma se l'operazione in blocco ignora effettivamente i vincoli o i trigger, posso vedere che è un problema.

Dato che probabilmente ci sono tante paure infondate quanti sono i rischi sconosciuti, penso che sia difficile dire davvero perché una politica è in atto senza chiedere a chi ha creato la politica perché sono preoccupati.

Tuttavia, immagino che probabilmente abbia qualcosa a che fare con ciò che BULK INSERT/ SqlBulkCopy/ BCP / OPENROWSET(BULK ...)consente a qualcuno di fare, vale a dire:

1. vincoli disabilitare ( CHECK, DEFAULT, e FOREIGN KEYcredo)
2. disabilita i trigger (se sono presenti trigger di controllo in atto, il loro by-pass sarebbe probabilmente ritenuto indesiderabile; per ulteriori spiegazioni su questo particolare problema, vedere la risposta di @DVKs )

Le varie opzioni sono descritte nella seguente documentazione:

• SqlBulkCopyOptions Enum
• INSERTO BULK

Non ho menzionato il problema di bloccaggio tavolo notato da @RDFozz dal momento che non è specifico per BULK INSERT: chiunque barattoli un TABLOCK / XLOCK o impostare il TRANSACTION ISOLATION LEVELper SERIALIZABLE.

AGGIORNARE

Mi sono imbattuto in due ulteriori informazioni che potrebbero aiutare a restringere questo aspetto:

1. Le questioni di essere in grado di disabilitare i trigger, vincoli disabilitare, e insieme IDENTITY_INSERT ONpotrebbero non essere un motivo schiacciante per vedere ADMINISTER BULK OPERATIONS, ADMINISTER DATABASE BULK OPERATIONS(a partire da SQL Server 2017), o il bulkadminruolo del server come una minaccia. Il motivo è che per eseguire una di queste tre cose appena menzionate, l'utente deve disporre delle ALTER TABLEautorizzazioni per quella tabella o per lo schema in cui esiste la tabella. Il concatenamento della proprietà non copre le modifiche DDL. Quindi, se l'utente non ha ALTER TABLE, quindi la possibilità di fare queste tre cose è un problema.

2. Ciò che non è stato discusso finora, e quello che potrebbe essere in ultima analisi, il problema di sicurezza è che entrambi BULK INSERTe OPENROWSET(BULK...accedere alle risorse esterne, al di fuori di SQL Server. Quando si accede a SQL Server tramite un account di accesso di Windows, tale account Windows verrà rappresentato (anche se si cambia il contesto di sicurezza utilizzando EXECUTE AS LOGIN='...') per eseguire l'accesso al file system. Ciò significa che puoi leggere solo i file che ti sono stati autorizzati a leggere. Niente di sbagliato in questo.

   MA, quando si accede a SQL Server tramite un accesso a SQL Server, l'accesso esterno viene eseguito nel contesto dell'account del servizio SQL Server. Ciò significa che qualcuno con questa autorizzazione potrebbe leggere file che altrimenti non dovrebbero essere in grado di leggere e in cartelle a cui non dovrebbero avere accesso.

   Se almeno SQL Server è stato impostato per essere eseguito come account creato solo per SQL Server (il metodo preferito), tale Utente potrebbe leggere solo i file a cui ha accesso l'account "SQL Server". Sebbene questo sia un problema limitato, consente comunque di leggere file come i file di registro di SQL Server (e ho provato l'esempio seguente e funziona):

   SELECT tmp.[Col1]
   FROM   OPENROWSET(BULK
      N'C:\Program Files\Microsoft SQL Server\MSSQLxx.InstanceName\MSSQL\Log\ERRORLOG.1',
                     SINGLE_NCLOB) tmp([Col1]);

   La maggior parte delle persone non avrà accesso alla cartella MSSQL \ Log , quindi questo sarebbe un modo per aggirare le restrizioni di sicurezza esistenti.

   E, se SQL Server è in esecuzione come Local Systemaccount, sospetto solo che l'ambito del problema aumenti e che un utente con questa autorizzazione sia in grado di leggere una vasta gamma di file relativi al sistema.

   E, questo è probabilmente il motivo per cui gli altri metodi di importazione in blocco - BCP e SqlBulkCopy- non richiedono l' bulkadminautorizzazione / il ruolo: sono avviati al di fuori di SQL Server e gestiranno autonomamente le autorizzazioni del file system. In questi casi, SQL Server non legge mai il file (o non arriva al di fuori di SQL Server), riceve semplicemente i dati da importare dal file che viene letto dal processo esterno.

Possibili implicazioni a parte, è stato detto nella domanda:

A beneficio di un'applicazione, BULK INSERT è molto più efficiente, più veloce, ..

Ok continua...

e allevia il programmatore dalla necessità di analizzare i file al di fuori di SQL.

Whoa Nelly. Fermiamoci qui. T-SQL non è in genere la migliore scelta di lingue per l'analisi. Spesso è meglio eseguire l'analisi prima di inserire elementi nel DB. Un modo per farlo è utilizzare i parametri a valori di tabella (TVP). Si prega di consultare la mia risposta a un'altra domanda (qui su DBA.StackExchange) che tratta l'argomento di pre-analisi e convalida insieme a un'efficace importazione in blocco di tali dati:

T-SQL: CSV-> pipeline di tabelle con dati numerici analizzati personalizzati, valori di ricerca

Questo era un po 'alluso in una risposta precedente ("... disabilita i trigger "), ma non spiega perché la disabilitazione sarebbe indesiderabile dal punto di vista aziendale.

In molte aziende, i trigger nella tabella principale vengono utilizzati per:

1. Convalida dei vincoli di integrità (quelli con una logica aziendale più complicata di quella normalmente utilizzata nei vincoli DB)

2. Ancora più importante, per controllare i dati, in particolare per inserire i dati nella corrispondente tabella di controllo (o aggiornare i campi di controllo nella tabella principale).

È piuttosto ovvio quali siano i problemi con il primo (l'applicazione è suscettibile di inserire dati errati che hanno effetti negativi sull'elaborazione a valle). Per quanto riguarda quest'ultimo, se un trigger è disabilitato, non si dispone di alcuna informazione di controllo, il che pone due problemi dal punto di vista del controllo:

• Innanzitutto, l'audit come gruppo non può più controllare le modifiche dei dati e quindi non è in grado di svolgere la loro funzione principale di audit interno.

• In secondo luogo, la mancanza di registri di controllo può costituire una violazione dei requisiti di controllo da parte di una società (ad es. SAS 70), il che può rendere la vostra società responsabile della violazione dei contratti.

Un'altra possibilità è l'impatto dell'esecuzione di BULK INSERTun'operazione.

Normalmente questo genere di cose verrebbe eseguito fuori orario quando possibile, in modo da non interferire con la normale attività. Un inserto in blocco potrebbe bloccare una tabella per ore, evitando che si verifichino altri inserti (nonché selezionare, aggiornare o eliminare).

Oppure, dal punto di vista della sicurezza, può produrre risultati molto simili a un attacco DoS.

Certo, si può fare questo accidentalmente o deliberatamente con transazioni e semplici INSERTdichiarazioni. Tuttavia, l'utilizzo di un processo di inserimento in blocco come previsto può causare questo effetto.

In generale, mi aspetto che un DBA sia coinvolto nell'organizzazione di attività fuori orario, poiché devono anche assicurarsi che i backup e altri processi pianificati siano completi. Se le persone pianificassero questo genere di cose senza sufficiente considerazione per tali attività, i backup potrebbero fallire, il che può costituire un problema per una serie di motivi.

Un motivo può essere dovuto al chiarimento della registrazione delle azioni. Se ogni azione corrisponde a una voce in un file di registro, è abbastanza banale vedere qualcosa che ha causato un problema senza alcun riferimento aggiuntivo. Se il tuo file di registro dice "INSERT FROM external.file", senza external.file, non puoi aggiungere altro.

Naturalmente, è possibile modificare il funzionamento della registrazione, ma come punto di partenza, imporre che ogni azione sia atomica anche durante la registrazione non è un'idea terribile.