Tutto relazionale sistemi di gestione di database fornire una sorta di meccanismi di sicurezza intrinseca progettati per ridurre al minimo le minacce di perdita di dati, danneggiamento o furto di dati. Si va dalla semplice protezione con password offerta da accesso Microsoft alla complessa struttura utente/ruolo supportata da database relazionali avanzati come Oracolo eMicrosoft SQL Server. Alcuni meccanismi di sicurezza sono comuni a tutti i database che implementano ilStructured Query Language.
Sicurezza a livello di utente
I database basati su server supportano a utente concetto simile a quello utilizzato nei sistemi operativi dei computer. Se hai familiarità con la gerarchia utente/gruppo trovata in Microsoft Windows NT e Windows 2000, scoprirai che i raggruppamenti utente/ruolo supportati da SQL Server e Oracle sono simili.
Crea account utente del database individuali per ogni persona con accesso al tuo database.
Evita di eseguire il provisioning di account generici accessibili da più persone. Innanzitutto, questa pratica elimina la responsabilità individuale, se un utente apporta una modifica al database (diciamo con concedendosi un aumento di $ 5.000), non sarai in grado di risalire a una persona specifica attraverso l'uso dell'audit log. In secondo luogo, se un utente specifico lascia l'organizzazione e si desidera rimuovere il suo accesso dal database, è necessario modificare la password su cui fanno affidamento tutti gli utenti.
I metodi per creare account utente variano da piattaforma a piattaforma e dovrai consultare la documentazione specifica del tuo DBMS per la procedura esatta. Gli utenti di Microsoft SQL Server dovrebbero indagare sull'uso del sp_adduser procedura memorizzata. Gli amministratori di database Oracle troveranno il CREARE UN UTENTE comando utile. Potresti anche voler indagare su schemi di autenticazione alternativi. Ad esempio, Microsoft SQL Server supporta l'utilizzo di Protezione integrata di Windows NT. In questo schema, gli utenti vengono identificati nel database dai loro account utente di Windows NT e non è necessario immettere un ID utente e una password aggiuntivi per accedere al database. Questo approccio è popolare tra gli amministratori di database perché sposta l'onere dell'account gestione al personale di amministrazione della rete e fornisce la facilità di un single sign-on al utente finale.
Sicurezza a livello di ruolo
Se ti trovi in un ambiente con un numero limitato di utenti, probabilmente scoprirai che la creazione di account utente e l'assegnazione delle autorizzazioni direttamente a loro è sufficiente per le tue esigenze. Tuttavia, se hai un numero elevato di utenti, sarai sopraffatto dal mantenimento degli account e delle autorizzazioni appropriate. Per alleviare questo onere, i database relazionali supportano ruoli. I ruoli del database funzionano in modo simile ai gruppi di Windows NT. Gli account utente vengono assegnati ai ruoli e le autorizzazioni vengono quindi assegnate al ruolo nel suo insieme anziché ai singoli account utente. Ad esempio, potresti creare un ruolo DBA e quindi aggiungere gli account utente del tuo personale amministrativo a questo ruolo. Successivamente, puoi assegnare un'autorizzazione specifica a tutti gli amministratori presenti (e futuri) semplicemente assegnando l'autorizzazione al ruolo. Ancora una volta, le procedure per la creazione dei ruoli variano da piattaforma a piattaforma. Gli amministratori di MS SQL Server dovrebbero indagare sul sp_addrole stored procedure mentre i DBA Oracle dovrebbero utilizzare il CREA RUOLO sintassi.
Concessione delle autorizzazioni
Ora che abbiamo aggiunto utenti al nostro database, è ora di iniziare a rafforzare la sicurezza aggiungendo autorizzazioni. Il nostro primo passo sarà quello di concedere le autorizzazioni appropriate per il database ai nostri utenti. Lo realizzeremo attraverso l'uso dell'istruzione SQL GRANT.
Ecco la sintassi dell'istruzione:
CONCEDERE.
[SOPRA.
PER.
[CON OPZIONE DI SOVVENZIONE]
Ora, diamo un'occhiata a questa affermazione riga per riga. La prima riga, CONCEDERE , ci consente di specificare le autorizzazioni di tabella specifiche che stiamo concedendo. Possono essere autorizzazioni a livello di tabella (come SELECT, INSERT, UPDATE e DELETE) o autorizzazioni di database (come CREATE TABLE, ALTER DATABASE e GRANT). È possibile concedere più di un'autorizzazione in una singola istruzione GRANT, ma le autorizzazioni a livello di tabella e le autorizzazioni a livello di database non possono essere combinate in un'unica istruzione.
La seconda riga, SOPRA
Infine, la quarta riga, CON OPZIONE DI SOVVENZIONE, è facoltativo. Se questa riga è inclusa nell'istruzione, l'utente interessato può concedere le stesse autorizzazioni anche ad altri utenti. Si noti che non è possibile specificare WITH GRANT OPTION quando le autorizzazioni sono assegnate a un ruolo.
Esempio di sovvenzioni per database
Diamo un'occhiata ad alcuni esempi. Nel nostro primo scenario, abbiamo recentemente assunto un gruppo di 42 operatori di inserimento dati che aggiungeranno e manterranno i record dei clienti. Devono accedere alle informazioni nella tabella Clienti, modificare queste informazioni e aggiungere nuovi record alla tabella. Non dovrebbero essere in grado di eliminare completamente un record dal database.
Innanzitutto, dovremmo creare account utente per ciascun operatore e quindi aggiungerli tutti a un nuovo ruolo, Inserimento dati. Successivamente, dovremmo utilizzare la seguente istruzione SQL per concedere loro le autorizzazioni appropriate:
CONCEDI SELEZIONA, INSERISCI, AGGIORNA.
SU Clienti.
TO DataEntry.
Ora esaminiamo un caso in cui assegniamo autorizzazioni a livello di database. Vogliamo consentire ai membri del ruolo DBA di aggiungere nuove tabelle al nostro database. Inoltre, vogliamo che siano in grado di concedere ad altri utenti il permesso di fare lo stesso. Ecco l'istruzione SQL:
CONCESSIONE CREA TABELLA.
A DBA.
CON OPZIONE DI CONCESSIONE.
Nota che abbiamo incluso la riga WITH GRANT OPTION per garantire che i nostri DBA possano assegnare questa autorizzazione ad altri utenti.
Rimozione dei permessi
SQL include il comando REVOKE per rimuovere le autorizzazioni precedentemente concesse. Ecco la sintassi:
REVOCA [OPZIONE DI CONCESSIONE PER]
SOPRA.
A PARTIRE DAL.
Noterai che la sintassi di questo comando è simile a quella del comando GRANT. L'unica differenza è che WITH GRANT OPTION è specificato nella riga di comando REVOKE anziché alla fine del comando. Ad esempio, immaginiamo di voler revocare l'autorizzazione precedentemente concessa a Mary per rimuovere i record dal database Clienti. Useremmo il seguente comando:
REVOCA ELIMINA.
SU Clienti.
DA Maria.
C'è un meccanismo aggiuntivo supportato da Microsoft SQL Server che vale la pena menzionare: il comando DENY. Questo comando può essere utilizzato per negare in modo esplicito un'autorizzazione a un utente che potrebbe altrimenti avere tramite un'appartenenza a un ruolo attuale o futuro. Ecco la sintassi:
NEGARE.
SOPRA.
PER.