Controis de acceso para usuarios e funcións en SQL

by Mike Chapple

A seguridade é primordial para os administradores de bases de datos que buscan protexer os seus gigabytes de datos empresariais vitais dos ollos curiosos de forasteros e intrusos non autorizados que intentan superar a súa autoridade. Todos os sistemas de xestión de bases de datos relacional proporcionan algún tipo de mecanismos intrínsecos de seguridade deseñados para minimizar estas ameazas. Eles van desde a sinxela protección por contrasinal que ofrece Microsoft Access á complexa estrutura de usuario / rol compatible con bases de datos relacionales avanzadas como Oracle e Microsoft SQL Server. Este artigo céntrase nos mecanismos de seguridade comúns a todas as bases de datos que implementan o Language Structured Query (ou SQL ). Xuntos, percorreremos o proceso de fortalecemento dos controis de acceso a datos e garantir a seguridade dos teus datos.

Usuarios

As bases de datos baseadas en servidor admiten un concepto de usuario similar ao empregado nos sistemas operativos da computadora. Se estás familiarizado coa xerarquía de usuario / grupo atopada en Microsoft Windows NT e Windows 2000, atoparás que os grupos de usuarios / roles compatibles con SQL Server e Oracle son moi similares.

É moi recomendable que cree contas individuais de usuarios de bases de datos para cada persoa que acceda á súa base de datos. É técnicamente posible compartir contas entre usuarios ou simplemente usar unha conta de usuario para cada tipo de usuario que precisa acceder á súa base de datos, pero desalentado esta práctica por dous motivos. En primeiro lugar, eliminará a responsabilidade individual: se un usuario fai un cambio na súa base de datos (digamos, dándolle un aumento de $ 5,000), non poderá rastrexalo a unha persoa específica mediante o uso de rexistros de auditoría. Ademais, se un usuario específico abandona a súa organización e quere eliminar o seu acceso da base de datos, verá obrigado a cambiar o contrasinal que confían todos os usuarios.

Os métodos para crear contas de usuario varían de plataforma a plataforma e terás que consultar a túa documentación específica de SGBD para o procedemento exacto. Os usuarios de Microsoft SQL Server deberían investigar o uso do procedemento almacenado sp_adduser. Os administradores da base de datos Oracle atoparán o comando CREATE USER útil. Tamén pode querer investigar esquemas de autenticación alternativos. Por exemplo, Microsoft SQL Server admite o uso de seguridade integrada de Windows NT. Baixo este esquema, os usuarios identificáronse á base de datos polas súas contas de usuario de Windows NT e non están obrigadas a introducir unha ID de usuario e contrasinal adicional para acceder á base de datos. Esta visión é moi popular entre os administradores da base de datos porque cambia a carga da xestión da conta ao persoal da administración da rede e proporciona a facilidade dun único inicio de sesión para o usuario final.

Papeis

Se estás nun ambiente cun pequeno número de usuarios, probabelmente probas que a creación de contas de usuario e a asignación de permisos directamente ás mesmas é suficiente para as túas necesidades. Non obstante, se tes unha gran cantidade de usuarios, é probable que estea abrumado pola carga de manter as contas e os permisos adecuados. Para facilitar esta carga, as bases de datos relacionales soportan a noción de roles. Os roles de base de datos funcionan de forma similar aos grupos de Windows NT. As contas de usuario están asignadas a roles e os permisos asignaranse ao rol no seu conxunto e non ás contas de usuarios individuais. Por exemplo, poderiamos crear un rol de DBA e engadir as contas de usuario do noso persoal administrativo a este papel. Unha vez feito iso, podemos asignar un permiso específico a todos os administradores presentes (e futuros) simplemente asignando o permiso ao rol. Unha vez máis, os procedementos para crear roles varían de plataforma a plataforma. Os administradores de MS SQL Server deberían investigar o procedemento almacenado sp_addrole mentres que os DBA de Oracle deberían usar a sintaxe CREATE ROLE.

Concesión de permisos

Agora que engadimos usuarios á nosa base de datos, é hora de comezar a fortalecer a seguridade engadindo permisos. O noso primeiro paso será proporcionar permisos de base de datos axeitados aos nosos usuarios. Fixemos isto a través do uso da declaración SQL GRANT.

Aquí está a sintaxe da declaración:

CONCERTO
[ON

]
A
[CON OPCIÓN DE SUBIDA]

Agora, imos facer unha ollada a esta declaración por liña. A primeira liña, GRANT , permítenos especificar os permisos de táboas específicos que estamos outorgando. Estes poden ser permisos de nivel de táboa (como SELECT, INSERT, UPDATE e DELETE) ou permisos de base de datos (como CREATE TABLE, ALTER DATABASE e GRANT). Pode concederse máis dun permiso nunha única declaración GRANT, pero os permisos a nivel de táboa e os permisos de nivel de base de datos poden non combinarse nunha única declaración.

A segunda liña, ON

, úsase para especificar a táboa afectada para os permisos de nivel de táboa. Esta liña omítese se concedemos permisos de nivel de base de datos. A terceira liña especifica o usuario ou o rol que se está a conceder permisos.

Finalmente, a cuarta liña, WITH GRANT OPTION, é opcional. Se esta liña está incluída na declaración, o usuario afectado tamén está autorizado a conceder estes mesmos permisos a outros usuarios. Lembre que a opción WITH GRANT OPTION non se pode especificar cando os permisos están asignados a unha función.

Exemplos

Miremos algúns exemplos. No noso primeiro escenario, contratamos recentemente un grupo de 42 operadores de entrada de datos que engadirán e manterán rexistros de clientes. Deben poder acceder á información na táboa Clientes, modificar esta información e engadir novos rexistros á táboa. Non deberían poder eliminar completamente un rexistro da base de datos. En primeiro lugar, debemos crear contas de usuario para cada operador e, a continuación, engadir todas a un novo rol, DataEntry. A continuación, deberiamos usar a seguinte instrución SQL para concederlles os permisos axeitados:

CONCELLO SELECCIONAR, INSERIR, ACTUALIZAR
ON Clientes
A DataEntry

E iso é todo o que hai para iso. Agora imos examinar un caso no que estamos asignando permisos de nivel de base de datos. Queremos permitir que membros do rol da DBA engadan novas táboas á nosa base de datos. Ademais, queremos que sexan capaces de conceder permiso aos demais usuarios para facer o mesmo. Aquí está a declaración SQL:

TAULA DE CREACIÓN DE CONCERTO
A DBA
CON OPCIÓN DE SUBIDA

Teña en conta que incluímos a liña WITH GRANT OPTION para garantir que os nosos DBAs poidan asignar este permiso a outros usuarios.

Eliminando Permisos

Unha vez que concedemos permisos, moitas veces resulta necesario revocar-los nunha data posterior. Afortunadamente, SQL ofrécenos o comando REVOKE para eliminar os permisos concedidos previamente. Aquí tes a sintaxe:

REVOCE [GRANT OPTION FOR]
ON

FROM

Notarás que a sintaxe deste comando é similar á do comando GRANT. A única diferenza é que CON OPCIÓN DE SUBIDA se especifica na liña de comando REVOKE en lugar de ao final do comando. Como exemplo, imaxinemos que queremos revogar a autorización previa concedida de Mary para eliminar rexistros da base de datos de Clientes. Usaríamos o seguinte comando:

REVOKE DELETE
ON Clientes
DE María

E iso é todo o que hai para iso. Existe un mecanismo adicional soportado por Microsoft SQL Server que vale a pena mencionar: o comando DENY. Este comando pode usarse para negar explícitamente un permiso a un usuario que poderían ter a través dunha membrecía actual ou futura. Aquí tes a sintaxe:

DENY
ON

Exemplos

Volvendo ao noso exemplo anterior, imaxinemos que Mary tamén era membro do rol de Directores que tamén tiña acceso á táboa de Clientes. A declaración anterior de REVOKE non sería suficiente para negar o seu acceso á táboa. Eliminaría o permiso concedido a ela a través dunha declaración GRANT dirixida á súa conta de usuario, pero non afectaría os permisos obtidos a través da súa participación no rol de Xestores. Non obstante, se usamos unha declaración DENY, bloqueará a herdanza do permiso. Aquí tes o comando:

DENY DELETE
ON Clientes
A María

O comando DENY crea esencialmente un "permiso negativo" nos controis de acceso á base de datos. Se máis tarde decidimos dar permiso a Mary para eliminar as filas da táboa Clientes, non podemos simplemente usar o comando GRANT. Ese comando sería inmediatamente anulado polo DENY existente. En vez diso, primeiro usariamos o comando REVOKE para eliminar a entrada de permiso negativo como segue:

REVOKE DELETE
ON Clientes
DE María

Notarás que este comando é exactamente o mesmo que o que se usou para eliminar un permiso positivo. Lembre que os comandos DENY e GRANT funcionan de xeito similar * mdash; ambos crean permisos (positivos ou negativos) no mecanismo de control de acceso á base de datos. O comando REVOKE elimina todos os permisos positivos e negativos para o usuario especificado. Unha vez emitido este comando, Mary poderá eliminar filas da táboa se é membro dun rol que posúa ese permiso. Alternativamente, un comando GRANT podería emitirse para proporcionar o permiso DELETE directamente á súa conta.

Ao longo deste artigo, aprendeu moito sobre os mecanismos de control de acceso soportados polo Idioma de consulta estándar. Esta introdución debería proporcionarlle un bo punto de partida, pero animo a que faga referencia á súa documentación de SGBD para coñecer as medidas de seguridade melloradas compatibles co seu sistema. Verá que moitas bases de datos admiten mecanismos de control de acceso máis avanzados, como a concesión de permisos en columnas específicas.

Usuarios

Papeis

Concesión de permisos

Exemplos

Eliminando Permisos

Exemplos

Alike posts

See Newest

Sapid posts