La sicurezza del server dipende principalmente dalla corretta configurazione delle autorizzazioni di accesso agli oggetti. Fornire a un utente autorizzazioni eccessive può causare molti problemi. No, un utente non utilizzerà i tuoi errori. Invece, qualsiasi hacker o io lo faremo. In questo caso, puoi dimenticare le tue tabelle con i dati o l'intero database.
Per qualche ragione, la sicurezza del database è la protezione dall'esterno, come un hacker. Tuttavia, questo accade molto raramente. Sono un programmatore in una grande azienda e un amministratore non pensa nemmeno a proteggere le porte del server, dove tutto è aperto. C'è un sacco di database, programmi e persino un server FTP su un singolo server e non è mai stato violato negli ultimi 5 anni. Fortunatamente, ho convinto l'amministratore a distribuire il server WEB su un hardware separato. Altrimenti, se qualcuno conoscesse l'indirizzo IP del nostro server principale, qualsiasi fannullone sarebbe in grado di hackerarlo. Né il database né Windows sono stati aggiornati per diversi anni.
Tuttavia, ogni giorno sorgono problemi interni a causa di una politica di sicurezza errata. Tutti gli utenti accedono con diritti di amministratore e possono creare tutto ciò che vogliono. Questo è un vero problema perché i permessi eccessivi consentono ai fannulloni di mostrare il loro completo analfabetismo. Pertanto, prenderemo in considerazione la sicurezza indipendentemente da dove proviene la minaccia:da un hacker o da un utente.
In questo articolo, prenderemo in considerazione tutte le basi necessarie per la protezione della sicurezza sia dagli hacker che dagli utenti. Ho scelto MS SQL Server come esempio perché contiene tutto ciò che è disponibile in altri database (Oracle, MySQL, ecc.) e ha funzionalità di gestione della sicurezza aggiuntive. Qualcuno potrebbe pensare che questo renda la SM più ripida. Tuttavia, a volte, le funzionalità aggiuntive possono essere eccessive, causando problemi.
Ruoli del server
In Windows e in altri sistemi operativi, ci sono gruppi e utenti per gestire le autorizzazioni. Possiamo unire gli utenti in un gruppo e concedere i diritti a tutti loro contemporaneamente, il che è molto più semplice che assegnare i diritti a ciascun utente individualmente. A tal fine, nelle banche dati, esiste il concetto di “ruolo”.
Si supponga che 100 utenti debbano disporre delle autorizzazioni per leggere i dati da una tabella specifica. Fornire a ciascun utente questa autorizzazione è una seccatura. È molto più semplice creare un ruolo che può leggere e quindi aggiungervi tutti gli utenti richiesti. Il risultato è simile al raggruppamento.
In SQL Server esistono due tipi di ruoli:server e database. I ruoli del server sono predefiniti e non possono essere modificati.
Aprire il ramo del ruolo di sicurezza/server in Enterprise Manager in modo da poter visualizzare un elenco di ruoli disponibili nella parte destra della finestra. La descrizione definisce cosa può fare l'utente con il ruolo corrispondente.
Ruoli del server in MS SQL Server e nella finestra del gestore ruoli
Per aggiungere un utente esistente a un ruolo, fare doppio clic sulla riga del ruolo. Nella finestra che appare, puoi aggiungere utenti al ruolo o eliminarli. La scheda Autorizzazione descrive in dettaglio cosa può fare ogni utente.
Utenti
Per gestire gli utenti, aprire il ramo Sicurezza/Accessi in Enterprise Manager. Nella parte destra vedrai un elenco di tutti gli utenti del server. Per impostazione predefinita, l'accesso è concesso agli amministratori di dominio e agli account di accesso integrati come sa.
Per aggiungere un nuovo utente, fai clic con il pulsante destro del mouse in un punto qualsiasi della parte vuota a destra della finestra e seleziona Nuovo login nel menu che appare. Nella parte superiore della finestra, seleziona un nome utente. Se devi scegliere un dominio esistente o un utente del computer, fai clic sul pulsante (...) a destra del campo di input e vedrai la casella di ricerca dell'utente nel dominio.
Aggiunta di un nuovo utente
Di seguito è possibile selezionare il tipo di autenticazione:Windows o SQL Server. Se si seleziona Windows, non è necessario specificare una password perché il server la recupererà dal sistema. Tuttavia, puoi attivare Concedi l'accesso (consenti l'accesso) o Nega l'accesso (proibisci). In quest'ultimo caso, l'utente sarà registrato nel database, ma non sarà in grado di connettersi – è vietato.
Se si seleziona l'autenticazione di SQL Server, sarà necessario impostare una password perché in questo caso verrà archiviata nelle tabelle di sistema del server di database. Tieni presente che anche se nelle impostazioni del server è specificata solo l'autenticazione di Windows, puoi creare record del server SQL, ma non sarai in grado di accedere al sistema con questi record.
Nella scheda Ruoli server è possibile specificare quale ruolo server verrà concesso a un utente. Pertanto, anche in fase di creazione, puoi aggiungere utenti ai ruoli necessari.
Accesso utente ai database
Nella scheda Accesso al database, specificare i database con cui l'utente può lavorare. Qui la finestra è divisa in due parti:nella metà superiore è possibile selezionare il database a cui è consentito l'accesso e nell'elenco in basso è possibile selezionare il ruolo del database. Questo ruolo nel database definirà le autorizzazioni utente. È possibile assegnare più ruoli a un utente.
Crea un account qq, che avrà accesso al database Northwind. Questo è un database di test standard creato durante la distribuzione del server.
Salva le modifiche.
Ora apri il ramo Database/Northwind/Utenti e visualizza l'elenco degli utenti che possono accedere al database selezionato. Si prega di notare che qui c'è l'account qq. Non esiste un account in altri database perché l'accesso ad essi è vietato al nostro nuovo utente.
Ruoli del database
Ogni database può avere i propri ruoli, che definiscono i permessi di accesso agli oggetti. A molti amministratori non piace preoccuparsi di queste autorizzazioni. Pertanto, installano il public predefinito integrato, che consente quasi tutto. Se mancano le autorizzazioni per il ruolo pubblico, è sufficiente aggiungere un utente al ruolo del server Amministratore di sistema. In questo caso, il database diventa vulnerabile.
Ogni utente dovrebbe essere dotato delle proprie e necessarie autorizzazioni. Ciò che non è consentito deve essere proibito. I ruoli già esistenti sul server non devono essere utilizzati perché i loro permessi sono aperti a tutti. Si consiglia di eliminarli anche tutti, in particolare quello pubblico.
Creazione di un ruolo
Per creare un nuovo ruolo del database, fare clic con il pulsante destro del mouse sul ramo Database/Nome database/Ruoli. Nel menu visualizzato, seleziona Nuovo ruolo database. Si apre la finestra Proprietà ruolo database – Nuovo ruolo. Nella parte superiore della finestra, digita il nome del ruolo.
Ad esempio, vogliamo creare un ruolo per i contabili. Per fare ciò, digita Buh nel campo Nome.
Creazione di un ruolo nel database
Di seguito, seleziona un tipo di ruolo, ad esempio uno standard predefinito. Al centro della finestra è presente un elenco di utenti che verranno aggiunti al ruolo. Finora, l'elenco è vuoto. Tuttavia, se facciamo clic su Aggiungi, aggiungeremo utenti, ad esempio, all'account qq creato in precedenza. Non c'è nient'altro da fare nella fase di creazione di un ruolo. Salva le modifiche facendo clic su OK.
Autorizzazioni di accesso
Ora vedremo come impostare i permessi. Fare doppio clic sul ruolo Buh creato per aprire la finestra per la modifica. Tieni presente che il pulsante di autorizzazione è ora disponibile. Solo quando il ruolo è registrato nel database, possiamo cambiarne i diritti. Fare clic su questo pulsante per aprire la finestra Proprietà ruolo database.
Impostazione delle autorizzazioni di accesso per i ruoli
Nella parte superiore della finestra è presente un elenco di ruoli del database in modo da poter passare rapidamente da uno all'altro. Ora, il ruolo Buh è selezionato. Al centro della finestra c'è una grande griglia con le seguenti colonne:
- Oggetto – nomi di oggetti;
- Proprietario – un proprietario di un oggetto;
- SELECT – autorizzazione per visualizzare i dati o eseguire l'istruzione SELECT. È disponibile solo per tabelle e viste;
- INSERT – autorizzazione per aggiungere dati o eseguire l'istruzione INSERT. È disponibile solo per tabelle e viste;
- UPDATE – autorizzazione per modificare i dati o eseguire l'istruzione UPDATE. È disponibile solo per tabelle e viste;
- Autorizzazione DELETE per eliminare i dati o eseguire l'istruzione DELETE. È disponibile solo per tabelle e viste;
- EXEC – autorizzazione per eseguire procedure e funzioni memorizzate. È disponibile solo per stored procedure e funzioni;
- DRI (integrità referenziale dichiarativa). È disponibile solo per tabelle, viste e funzioni.
Non ci sono autorizzazioni per il nuovo ruolo. Per poter visualizzare una tabella, ad esempio Categorie, selezionare la casella all'intersezione tra la riga Categorie e la colonna SELEZIONA. Vedrai un segno di spunta verde nella casella, che significa un'autorizzazione. Il secondo clic cambia il segno di spunta nel segno della croce rossa e significa divieto. Ciò può essere necessario se si concede un'autorizzazione all'utente e lo si aggiunge a un altro ruolo, in cui è consentito l'accesso all'azione selezionata. Il terzo clic rimuove tutte le autorizzazioni sull'azione e lascia la casella vuota. Ciò significa che non c'è accesso; tuttavia, può essere delegato se l'utente viene aggiunto a un altro ruolo con i permessi sull'oggetto o se i permessi sono specificati in modo esplicito.
Se selezioni una riga con l'oggetto della tabella o della vista, il pulsante Colonne diventa disponibile nella parte inferiore della finestra. Si supponga di aver selezionato la tabella e di aver fatto clic su questo pulsante. Si apre la finestra in cui puoi impostare i permessi per le singole colonne della tabella.
Impostazione delle autorizzazioni per le colonne
Questa è davvero una grande possibilità perché alcune colonne responsabili dell'integrità del database non devono essere modificate da utenti o hacker. È meglio vietare le operazioni UPDATE o SELECT (se possibile) per queste colonne.
Individualismo
I ruoli sono convenienti da usare quando è necessario combinare utenti simili. Ad esempio, numerosi contabili devono avere accesso alle tabelle finanziarie. Concedere le autorizzazioni a ciascun contabile richiede molto tempo. È molto più semplice creare un ruolo per il contabile, concedergli le autorizzazioni e quindi aggiungere tutti gli account contabili a questo ruolo.
Tuttavia, ci sono casi in cui le autorizzazioni devono essere univoche per un utente o, oltre alle autorizzazioni concesse dal ruolo, è necessario concedere autorizzazioni aggiuntive. Ad esempio, uno dei contabili deve avere accesso alle tabelle del dipartimento delle risorse umane. In questo caso, è meglio aggiungere le autorizzazioni direttamente al contabile piuttosto che creare un nuovo ruolo.
Abbiamo esplorato i ruoli prima per farci l'abitudine. Nella maggior parte dei casi, esiste un account separato per i contabili, un account separato per gli economisti, ecc. In questo caso, la maggior parte delle persone si connette al server utilizzando un account. Quindi, controllare chi fa ciò che è impossibile. È meglio utilizzare i permessi individuali ove necessario, mentre ogni utente deve avere il proprio account.
Autorizzazioni sui tavoli
Vediamo come possiamo concedere autorizzazioni su oggetti particolari, ad esempio su tabelle.
Selezionare il ramo Database/Northwind/Tabelle nell'albero degli oggetti. Nella parte destra si apre un elenco di tutte le tabelle. Fare clic con il pulsante destro del mouse su una tabella e selezionare Tutte le attività/Gestisci autorizzazioni. Viene visualizzata la finestra Proprietà autorizzazione, simile alla finestra Proprietà ruolo database con l'elenco degli utenti anziché l'elenco degli oggetti. L'oggetto è una tabella su cui abbiamo fatto clic e il suo nome verrà elencato nel menu a discesa della finestra. Ora, dobbiamo impostare le autorizzazioni su questo oggetto per utenti diversi.
Impostazione delle autorizzazioni su una tabella
L'elenco delle autorizzazioni è il seguente:visualizzazione, aggiornamento, aggiunta, eliminazione, esecuzione e gestione. Se fai clic sul pulsante Colonne, si apre la finestra per l'impostazione delle autorizzazioni sull'oggetto a livello di campi della tabella per un determinato utente.
Viste
Abbiamo due tavoli. Uno di essi memorizza l'elenco dei dipendenti, mentre un'altra tabella contiene informazioni sul numero di ore lavorate al mese e sui salari percepiti (salari ufficiali e nascosti).
Supponiamo che un funzionario delle tasse venga da te e ti chieda di mostrare i salari dei lavoratori. Inoltre, ti chiedono se hai pagato tutte le tasse. Quali azioni devi compiere dalla tua parte?
La prima proposta è arrivata dalla terza riga:creare un nuovo utente a cui è consentito leggere tabelle che includono un elenco di dipendenti e stipendi. Inoltre, non dimenticare di chiudere la colonna con il salario nascosto. In realtà la soluzione è corretta ma assolutamente inefficace.
L'opzione migliore è creare una vista, una query SQL che seleziona i dati. Nel database, sembra una tabella. È possibile selezionare i dati SQL utilizzando query e concedere autorizzazioni. Si scopre che la query verrà eseguita sulla query.
Per creare una vista, esegui la seguente query:
CREATE VIEW salary AS SELECT fields for a tax official FROM Employees, Wages WHERE joins
Ora, c'è un nuovo oggetto Salario nel ramo Database/Northwind/Viste. Se si fa clic con il pulsante destro del mouse e si seleziona Tutte le attività/Gestisci autorizzazioni, si aprirà la finestra per la concessione delle autorizzazioni. Imposta un permesso per il funzionario fiscale e salvalo. Per rivedere il contenuto della vista, esegui la query:
SELECT * FROM salary
Come puoi vedere, c'è un accesso come un semplice tavolo. Il funzionario delle imposte penserà anche di vedere i dati effettivi. Tuttavia, in effetti, questa query conterrà solo i dati di cui abbiamo bisogno.
Nella vita reale, il funzionario delle tasse non può essere ingannato così facilmente perché non sono sciocchi. Tuttavia, questo esempio mostra che la vista può essere un metodo di sicurezza perfetto. Possiamo visualizzare i dati di cui gli utenti hanno bisogno e nient'altro. Allo stesso tempo, abbiamo tutti gli strumenti per gestire i permessi sulla vista senza influire sui permessi di accesso alle tabelle.
Pertanto, visualizzazioni diverse delle stesse tabelle possono mostrare dati diversi. Se vuoi mostrare una colonna aggiuntiva, aggiungi le viste alla query. In questo caso, non è necessario modificare i permessi.
Viste di sistema
In ogni database possono essere presenti viste di sistema create automaticamente dal server. Non consiglio di concedere loro un'autorizzazione perché possono mostrare alcune informazioni aggiuntive, che possono aiutare un hacker a impostare le autorizzazioni o semplicemente distruggere i dati. Le viste di sistema iniziano con il prefisso sys e il sistema è specificato nella colonna Tipo dell'elenco.
Procedure e funzioni
I moderni server di database supportano procedure e funzioni memorizzate. Questo è un codice PL/SQL o Transact-SQL a seconda del database eseguito sul server del database. Utilizzando queste procedure, possiamo eseguire qualsiasi operazione sul server o semplicemente selezionare i dati, come nella vista. Possiamo impostare i permessi su ogni procedura.
Durante la revisione dei ruoli, abbiamo già visto le procedure nell'elenco di oggetti su cui puoi impostare i permessi e solo la colonna EXEC è disponibile in queste righe perché le procedure possono essere solo eseguite.
Le stored procedure e le funzioni sono archiviate in un database particolare. Per visualizzare le procedure del database Northwind, selezionare il ramo Database/Northwind/Stored Procedure. Esistono molte procedure di sistema, i cui nomi iniziano con il prefisso dt_ e System è specificato nella colonna Type. Si raccomanda di non concedere l'accesso a queste procedure, se possibile. Puoi vedere le funzioni nel ramo Database/Northwind/Funzione definita dall'utente.
Per modificare le autorizzazioni su procedure e funzioni, fare clic con il pulsante destro del mouse sul nome e selezionare Tutte le attività/Gestisci autorizzazioni nel menu. Nella finestra che appare, puoi modificare solo la colonna EXEC per le procedure e le colonne EXEC e DRI per le funzioni.
Norme di autorizzazione
Alcuni amministratori impostano le autorizzazioni in base al ruolo esistente, ad esempio pubblico. Questo non è vero perché, in questo ruolo, potrebbero esserci autorizzazioni di cui gli utenti non hanno bisogno. Quindi, prova a impostare una nuova autorizzazione.
Per quanto mi riguarda, creo sempre un nuovo ruolo e concedo un set minimo di autorizzazioni. Se gli utenti chiedono più permessi e sono effettivamente necessari, aggiungo più permessi. Se autorizzi tutto per impostazione predefinita, non vi è alcuna garanzia che in futuro i diritti inutili e pericolosi verranno eliminati.
Un altro problema per impostare meno autorizzazioni è un'abitudine. Gli utenti possono abituarsi al fatto che vengono concessi loro molti permessi e quindi il divieto provocherà un grave scandalo. A nessuno piace quando i propri diritti vengono violati.
Tabelle/Banche dati
I database memorizzano le impostazioni e le proprietà nascoste nelle tabelle di sistema e nei database. Non differiscono da altri oggetti di database e su di essi possono essere impostate autorizzazioni. In nessun caso, non consentire agli utenti di accedere a queste tabelle senza una necessità particolare.
In SQL Server, i dati di sistema importanti vengono archiviati nei database master e msdb. Pertanto, questi database devono essere protetti. In Oracle, ogni database esiste come oggetto separato e le tabelle di sistema sono archiviate insieme a quelle degli utenti.
Quasi tutti i server di database offrono l'installazione di database di test che possono essere utilizzati per l'apprendimento o il test del sistema. Se li hai, elimina, perché a questi database è impostato un accesso pubblico. Se un hacker conosce i nomi o le proprietà di qualsiasi oggetto esistente nel sistema, semplificherà notevolmente il suo compito.
Quando ci si connette a un database di prova, è possibile eseguire alcuni comandi sul server e danneggiare il sistema operativo o un database funzionante. Nessuna roba aggiuntiva dovrebbe essere nel sistema. Inoltre, tali tabelle/database hanno permessi piuttosto elevati anche per un ospite.
Riepilogo
Nonostante il fatto che abbiamo utilizzato MS SQL Server come esempio, i concetti di autorizzazioni, ruoli e autenticazione esistono in tutti i database.
Conoscendo tutte le regole che abbiamo considerato, l'unica cosa di cui hai bisogno è esplorare la particolarità del loro utilizzo nel tuo database.
