DBA è il custode dei dati e ci sono due aspetti dell'essere un tutore. Il primo è l'integrità. Include attività come la verifica della coerenza del database, la creazione di backup e, in caso di problemi, un piano di ripristino del database completo e ben progettato.
Il secondo aspetto è la sicurezza. Suggerisce di assicurarsi che solo gli utenti autorizzati abbiano accesso ai dati e solo ai dati di cui hanno bisogno.
Sul Web puoi trovare numerose risorse dedicate alla sicurezza. Tuttavia, penso che alcune cose importanti manchino di un'attenzione adeguata. In questo articolo vorrei concentrarmi su queste opzioni e dimostrare perché è importante esserne consapevoli e gestirle correttamente.
Una missione per compromettere un server SQL
Facciamo un gioco di ruolo in cui sei un agente segreto e la tua missione, se lo accetti, è rubare dati molto importanti dal TargetDB database ospitato da un SQL Server. Devi ottenere questi dati ed eliminarli.
È possibile ottenere un accesso per te, ma ogni accesso sul server ha autorizzazioni NEGATE esplicite sul database e sui dati di destinazione. L'unica informazione che il nostro agente può fornirti è quella generata per la verifica dal protocollo di sicurezza durante la creazione del tuo login.
Informazioni sul database dal server di destinazione.
Autorizzazioni del server:
Autorizzazioni database:
Come ogni agente decente, facciamo i compiti e controlliamo con cosa hai a che fare.
Non puoi semplicemente accedere e connetterti a TargetDB , poiché ogni singola autorizzazione viene negata per il tuo accesso e il relativo utente mappato in modo esplicito. Devi entrare da un altro database.
Una porta chiusa a chiave
Le azioni tra database non sono cose facili da fare. Considerala come una porta chiusa con due serrature. Non ci concentreremo sui dettagli tecnici qui, ma puoi fare riferimento all'articolo Estensione della rappresentazione del database utilizzando l'articolo ESEGUI COME MSDN (consiglio vivamente di farlo).
Il primo blocco è Fidarsi dell'autenticatore e il secondo è Fidarsi del database .
Iniziamo con il primo blocco. Affidarsi all'autenticatore significa che per accedere a un altro database B, al proprietario del database A deve essere concesso (esplicitamente o implicitamente) l'AUTENTICAZIONE autorizzazione nel database B.
Apetta un minuto! L'autenticatore a livello di database è il proprietario del database stesso (non confonderlo con db_owner ruolo del database!).
Controlla i proprietari del database:
Anche se seguono una buona pratica utilizzando un account per server, che non è SA , in questo modo ti hanno gentilmente aperto il primo lucchetto.
Concentriamoci sul secondo blocco.
In qualche modo, devi avere un database creato sul server con TRUSTWORTHY proprietà ON . La procedura consigliata qui è impostare la proprietà del database TRUSTWORTHY su OFF .
Questo è il momento in cui dovremmo dire:e se avessi già un database del genere?
È il database MSDB.
Il secondo blocco è fatto. Non hai nemmeno bisogno di rompere nessuno dei lucchetti.
L'importanza del ruolo db_owner
In questo momento, devi affrontare una sfida. In qualche modo, devi entrare nel database MSDB con db_owner ruolo del database perché dispone di un'autorizzazione implicita e rappresentativa.
Poiché MSDB di solito non è al centro dell'attenzione degli amministratori di database, questa missione non è più impossibile. Vediamo cosa puoi fare solo perché hai un utente con db_owner ruolo del database nel database MSDB:
Prova a connetterti al TargetDB :
Questo è un errore previsto. Ricorda il protocollo di sicurezza applicato al login fornito. Iniziamo.
Prova a connetterti al TargetDB e per selezionare i dati di destinazione:
Funziona! Modifichiamolo e successivamente verifichiamo l'azione.
Questo è tutto.
Missione compiuta.
Come hai visto, mi sono concentrato su una particolare combinazione di configurazione del database di sicurezza. Quelli erano il proprietario del database e il TRUSTWORTHY opzione database prestando particolare attenzione a MSDB. Lo scenario presentato era solo quello in cui i dati sensibili possono essere compromessi allo stesso modo. Esaminiamo ora un altro possibile scenario.
Proprietario database + FIDUCIA
Controlliamo i dettagli del background partendo dal noto problema:la proprietà del database. Quali dettagli di accesso dovrebbe utilizzare il proprietario dei tuoi database? Molte persone dicono che SA è una scelta appropriata.
Ho fatto una rapida ricerca su Google e ho trovato risposte come le seguenti:
"Non ricordo che questa sia stata una preoccupazione per me. Oltre a sembrare fastidioso nei rapporti o non essere in grado di rimuovere l'utente se possiede un database, ma non penso che influisca sulle operazioni del server. Puoi semplicemente scegliere sa per coerenza."
Oppure
"Non credo che possedere un database di SA o di qualsiasi altro utente dovrebbe destare preoccupazione. Ciò che conta è chi esegue "cosa" nel tuo database. Quindi, è una buona idea creare utenti con privilegi validi. Per semplicità, puoi specificare il proprietario come SA."
La situazione attuale è che l'utilizzo dell'account SA come proprietario del database è la pratica PEGGIORE . Personalmente penso che questo dovrebbe essere evidenziato in ogni blog e in ogni documentazione, relativa a questo argomento.
Se creiamo utenti con solo privilegi validi, sarebbe sufficiente, ma sfortunatamente non è così che di solito funzionano le cose. Devi essere preparato per gli scenari "possibili peggiori". Pensa a cosa potremmo fare nei nostri esempi precedenti se il proprietario del database predefinito fosse SA !
Procediamo con la seconda opzione, la FIDUCIA opzione database. La situazione è un po' migliorata, ma ha ancora un problema comune. Come comunemente si pensa, la procedura consigliata qui è Impostare la proprietà del database "Affidabile" su Off . Abbiamo appena visto perché questa opzione è cattiva .
Ma questo non è tutto. Se provi a trovare degli script per controllare questa proprietà, probabilmente troverai uno script simile a questo:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'Il sp_Blitz lo script che controlla l'integrità di SQL Server controlla anche le impostazioni predefinite dei database (incluso TRUSTWORTHY come valore predefinito 0) e segnala ogni database con impostazioni non predefinite. Tuttavia, lo script ignora i database di sistema.
Inoltre, c'è un articolo di MS KB, che si concentra su questo argomento. Fare riferimento alle linee guida per l'utilizzo delle impostazioni del database TRUSTWORTHY in SQL Server:
C'è un esempio di codice nell'articolo, che elenca i database che hanno il bit TRUSTWORTHY ON e i cui proprietari di database appartengono al ruolo del server sysadmin:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
Cosa c'è di comune in questi script? Ogni script esclude MSDB, ma come osserva l'articolo di MS KB, l'hai appena visto nella nostra "missione":
Nota :per impostazione predefinita, l'impostazione TRUSTWORTHY è impostata su ON per il database MSDB. La modifica di questa impostazione rispetto al valore predefinito può causare un comportamento imprevisto da parte dei componenti di SQL Server che utilizzano il database MSDB.
Vorrei sottolineare che l'obiettivo principale di questa sezione non è né l'opzione del database TRUSTWORTHY né la proprietà del proprietario del database stesso, ma la combinazione di queste due opzioni. Mi sono concentrato principalmente su MSDB perché l'impostazione TRUSTWORTHY è impostata su ON per il database MSDB per impostazione predefinita.
Conclusione
È tutto per ora. Abbiamo esaminato e verificato gli scenari pratici relativi alla sicurezza di SQL Server. Abbiamo anche esaminato opzioni di database così importanti, come il proprietario del database e l'impostazione del database TRUSTWORTHY.
Volevo solo mettere in risalto queste opzioni poiché, poiché sono fondamentali, soprattutto quando ne parliamo in combinazione.
