Controls d'accés per a usuaris i rols en SQL

La seguretat és primordial per als administradors de la base de dades que busquen protegir els seus gigabytes de dades empresarials vitals dels ulls intel·ligents d'estrangers no autoritzats i d'usuaris interns que intenten superar la seva autoritat. Tots els sistemes de gestió de bases de dades relacionals proporcionen algun tipus de mecanisme de seguretat intrínsec dissenyat per minimitzar aquestes amenaces. Van des de la simple protecció de contrasenyes que Microsoft Access ofereix a l'estructura complexa de l'usuari / rol compatible amb bases de dades relacionals avançades com Oracle i Microsoft SQL Server. Aquest article se centra en els mecanismes de seguretat comuns a totes les bases de dades que implementen l' Idioma de consulta estructurada (o SQL ). Junts, anem a recórrer el procés d'enfortiment dels controls d'accés a dades i garantir la seguretat de les vostres dades.

Usuaris

Les bases de dades basades en servidors són compatibles amb un concepte d'usuari similar al que s'utilitza en els sistemes operatius de l'ordinador. Si esteu familiaritzat amb la jerarquia d'usuari / grup que es troba a Microsoft Windows NT i Windows 2000, trobareu que els grups d'usuaris / rols compatibles amb SQL Server i Oracle són molt similars.

Es recomana que creeu comptes d'usuari de bases de dades individuals per a cada persona que accedeixi a la vostra base de dades. És tècnicament possible compartir comptes entre usuaris o simplement utilitzar un compte d'usuari per a cada tipus d'usuari que necessiti accedir a la vostra base de dades, però evito fortament aquesta pràctica per dos motius. En primer lloc, s'eliminarà la responsabilització individual: si un usuari fa un canvi en la seva base de dades (diguem donant-se un augment de $ 5,000), no podreu rastrejar-lo de nou a una persona específica mitjançant l'ús de registres d'auditoria. A més, si un usuari específic deixa la vostra organització i voleu eliminar-ne l'accés de la base de dades, se us obligarà a canviar la contrasenya que confien tots els usuaris.

Els mètodes per crear comptes d'usuari varien de plataforma a plataforma i hauran de consultar la documentació específica del SGBD per al procediment exacte. Els usuaris de Microsoft SQL Server haurien d'investigar l'ús del procediment emmagatzemat sp_adduser. Els administradors de la base de dades Oracle trobaran la comanda CREATE USER útil. També és possible que vulgueu investigar esquemes d'autenticació alternatius. Per exemple, Microsoft SQL Server admet l'ús de la seguretat integrada de Windows NT. Sota aquest esquema, els usuaris s'identifiquen a la base de dades pels seus comptes d'usuari de Windows NT i no estan obligats a introduir una identificació d'usuari i una contrasenya addicionals per accedir a la base de dades. Aquest enfocament és extremadament popular entre els administradors de la base de dades perquè canvia la càrrega de la gestió del compte al personal de l'administració de la xarxa i proporciona la facilitat d'iniciar un únic inici de sessió a l'usuari final.

Rols

Si esteu en un entorn amb un nombre reduït d'usuaris, és probable que trobeu que la creació de comptes d'usuari i l'assignació de permisos directament a ells és suficient per a les vostres necessitats. Tanmateix, si teniu un gran nombre d'usuaris, és probable que us trobeu aclaparat per la càrrega de mantenir comptes i permisos adequats. Per facilitar aquesta càrrega, les bases de dades relacionals admeten la noció de rols. Els rols de la base de dades funcionen de manera similar als grups de Windows NT. Els comptes d'usuari s'assignen a la (s) funció (es) i els permisos s'assignen a la totalitat del rol en lloc dels comptes d'usuari individuals. Per exemple, podríem crear un rol de DBA i afegir els comptes d'usuari del nostre personal administratiu a aquesta funció. Un cop ho hàgim fet, podem assignar un permís específic a tots els administradors presents (i futurs) simplement assignant el permís a la funció. Una vegada més, els procediments per crear rols varien de plataforma a plataforma. Els administradors de MS SQL Server han d'investigar el procediment emmagatzemat sp_addrol mentre que els Oracle DBA han d'utilitzar la sintaxi CREATE ROLE.

Concessió de permisos

Ara que hem afegit usuaris a la nostra base de dades, és hora de començar a reforçar la seguretat afegint permisos. El nostre primer pas serà concedir permisos de bases de dades adequats als nostres usuaris. Ho aconseguirem a través de la instrucció SQL GRANT.

Aquí teniu la sintaxi de la declaració:

CONCERT
[ON

]
A
[AMB OPCIÓ DE SUBIDA]

Ara, fem una ullada a aquesta declaració de línia per línia. La primera línia, GRANT , ens permet especificar els permisos de taula específics que estem concedint. Aquests poden ser permisos de nivell de taula (com SELECT, INSERT, UPDATE i DELETE) o permisos de base de dades (com ara CREATE TABLE, ALTER DATABASE i GRANT). Es pot concedir més d'un permís en una única declaració GRANT, però els permisos de nivell de taula i els permisos de nivell de base de dades no es poden combinar en una sola instrucció.

La segona línia, ON

, s'utilitza per especificar la taula afectada per als permisos de nivell de taula. Aquesta línia s'omet quan concedim permisos de nivell de base de dades. La tercera línia especifica l'usuari o la funció que es concedeix permisos.

Finalment, la quarta línia, AMB OPCIÓ DE SUBIDA, és opcional. Si aquesta línia s'inclou a la declaració, l'usuari afectat també pot permetre concedir aquests mateixos permisos a altres usuaris. Tingueu en compte que WITH GRANT OPTION no es pot especificar quan els permisos s'assignen a una funció.

Exemples

Vegem alguns exemples. En el nostre primer escenari, recentment hem contractat un grup de 42 operadors d'entrada de dades que agregaran i mantindran els registres de clients. Han de poder accedir a la informació de la taula Customers, modificar aquesta informació i afegir nous registres a la taula. No han de poder eliminar completament un registre de la base de dades. En primer lloc, hem de crear comptes d'usuari per a cada operador i, a continuació, afegir-los a una nova funció, DataEntry. A continuació, hauríem d'utilitzar la següent instrucció SQL per concedir-los els permisos adequats:

CONCESSIÓ SELECCIONAR, INSERIR, ACTUALITZAR
ON Clients
A DataEntry

I això és tot. Ara examinem un cas en què estem assignant permisos de nivell de base de dades. Volem permetre als membres de la funció DBA afegir taules noves a la nostra base de dades. A més, volem que puguin concedir permisos a altres usuaris per fer el mateix. Aquí teniu la instrucció SQL:

TAULA DE CREACIÓ DE CONCESSIONES
A DBA
AMB OPCIÓ DE SUBIDA

Tingueu en compte que hem inclòs la línia WITH GRANT OPTION per garantir que els nostres DBA poden assignar aquest permís a altres usuaris.

S'estan eliminant els permisos

Quan hàgim concedit permisos, sovint és necessari revocar-los més endavant. Afortunadament, SQL ens proporciona la comanda REVOKE per eliminar permisos prèviament concedits. Aquí teniu la sintaxi:

REVOKE [OPTION GRANT PER]
ON


FROM

Notaràs que la sintaxi d'aquesta comanda és similar a la de l'ordre GRANT. L'única diferència és que WITH GRANT OPTION s'especifica a la línia d'ordres REVOKE en comptes de al final de la comanda. Com a exemple, imaginem que volem revocar el permís prèviament concedit de Mary per eliminar registres de la base de dades Customers. Utilitzaríem el següent comandament:

REVOKE DELETE
ON Clients
DE Maria

I això és tot. Hi ha un mecanisme addicional suportat per Microsoft SQL Server que val la pena esmentar: l'ordre DENY. Aquesta ordre es pot utilitzar per denegar explícitament un permís a un usuari que d'una altra manera podria tenir a través d'una membresía de rol actual o futura. Aquí teniu la sintaxi:

DENY
ON


A

Exemples

Tornant al nostre exemple anterior, imaginem que Mary també era membre del rol de Gestors que també tenia accés a la taula de clients. L'anterior declaració de REVOKE no seria suficient per negar-li l'accés a la taula. Treure el permís que se li ha concedit a través d'una declaració GRANT dirigida al seu compte d'usuari, però no afectaria els permisos obtinguts a través de la seva pertinença a la funció Administradors. Tanmateix, si utilitzem una declaració de DENY, bloquejarà l'herència del permís. Aquí teniu la comanda:

DENY DELETE
ON Clients
A Mary

L'ordre DENY bàsicament crea un "permís negatiu" als controls d'accés a la base de dades. Si més tard decideixem donar a Mary permís per eliminar files de la taula Customers, no podem simplement utilitzar l'ordre GRANT. Aquest comandament seria immediatament anul·lat pel DENY existent. En lloc d'això, primer usem la comanda REVOKE per eliminar l'entrada de permís negatiu de la manera següent:

REVOKE DELETE
ON Clients
DE Maria

Notaràs que aquesta ordre és exactament la mateixa que la que s'utilitza per eliminar un permís positiu. Recordeu que els comandaments DENY i GRANT treballen de manera similar *, ja que creen permisos (positius o negatius) al mecanisme de control d'accés a la base de dades. La comanda REVOKE elimina tots els permisos positius i negatius per a l'usuari especificat. Una vegada emesa aquesta comanda, Mary podrà eliminar les files de la taula si és membre d'una funció que posseeix aquest permís. Alternativament, es pot emetre un comandament GRANT per proporcionar el permís DELETE directament al seu compte.

Al llarg d'aquest article, heu après molt sobre els mecanismes de control d'accés compatibles amb l'idioma de consulta estàndard. Aquesta introducció us ha de proporcionar un bon punt de partida, però us animo a fer una referència a la vostra documentació del SGBD per obtenir informació sobre les mesures de seguretat millorades que admet el vostre sistema. Trobareu que moltes bases de dades admeten mecanismes de control d'accés més avançats, com ara concedir permisos a columnes específiques.