La seguridad es primordial para los administradores de bases de datos que buscan proteger sus gigabytes de datos empresariales vitales de las miradas indiscretas de personas externas e internas no autorizadas que intentan exceder su autoridad. Todos los sistemas de gestión de bases de datos relacionales proporcionan algún tipo de mecanismos de seguridad intrínseca diseñados para minimizar estas amenazas. Van desde la simple protección con contraseña ofrecida por Microsoft Access hasta la compleja estructura de roles/usuarios soportada por bases de datos relacionales avanzadas como Oracle y Microsoft SQL Server. Esto se centra en los mecanismos de seguridad comunes a todas las bases de datos que implementan el lenguaje de consulta estructurado (o SQL). Juntos, pasaremos por el proceso de fortalecer los controles de acceso a los datos y garantizar la seguridad de sus datos.

Usuarios

Todas las bases de datos basadas en servidores soportan un concepto de usuario similar al utilizado en los sistemas operativos de los ordenadores. Si está familiarizado con la jerarquía de usuarios/grupos que se encuentra en Microsoft Windows NT y Windows 2000, encontrará que los grupos de usuarios/roles soportados por SQL Server y Oracle son muy similares.

Se recomienda encarecidamente que cree cuentas de usuario individuales para cada persona que vaya a acceder a su base de datos. Es técnicamente posible compartir cuentas entre usuarios o simplemente usar una cuenta de usuario para cada tipo de usuario que necesite acceder a su base de datos, pero desaconsejo esta práctica por dos razones. En primer lugar, eliminará la responsabilidad individual: si un usuario realiza un cambio en su base de datos (por ejemplo, si se da a sí mismo un aumento de 5.000 dólares), no podrá rastrearlo hasta una persona específica mediante el uso de registros de auditoría. Además, si un usuario específico abandona su organización y usted desea eliminar su acceso de la base de datos, se verá obligado a cambiar la contraseña en la que confían todos los usuarios.

Los métodos para crear cuentas de usuario varían de una plataforma a otra y tendrá que consultar la documentación específica de su DBMS para conocer el procedimiento exacto. Los usuarios de Microsoft SQL Server deben investigar el uso del procedimiento almacenado sp_adduser. Los administradores de bases de datos Oracle encontrarán útil el comando CREAR USUARIO. También es posible que desee investigar esquemas de autenticación alternativos. Por ejemplo, Microsoft SQL Server soporta el uso de Windows NT Integrated Security. Bajo este esquema, los usuarios son identificados a la base de datos por sus cuentas de usuario de Windows NT y no se requiere que introduzcan un ID de usuario y contraseña adicionales para acceder a la base de datos. Este enfoque es extremadamente popular entre los administradores de bases de datos porque traslada la carga de la gestión de cuentas al personal de administración de la red y proporciona la facilidad de un único inicio de sesión para el usuario final.

Roles

Si se encuentra en un entorno con un pequeño número de usuarios, probablemente encontrará que crear cuentas de usuario y asignarles permisos directamente es suficiente para sus necesidades. Sin embargo, si tiene un gran número de usuarios, lo más probable es que se sienta abrumado por la carga de mantener las cuentas y los permisos adecuados. Para aliviar esta carga, las bases de datos relacionales apoyan la noción de roles. Los roles de la base de datos funcionan de manera similar a los grupos de Windows NT. Las cuentas de usuario se asignan a las funciones y los permisos se asignan a la función en su totalidad en lugar de a las cuentas de usuario individuales. Por ejemplo, podríamos crear un rol de DBA y luego agregar las cuentas de usuario de nuestro personal administrativo a este rol. Una vez hecho esto, podemos asignar un permiso específico a todos los administradores presentes (y futuros) simplemente asignando el permiso al rol. Una vez más, los procedimientos para crear roles varían de una plataforma a otra. Los administradores de MS SQL Server deben investigar el procedimiento almacenado sp_addrole mientras que los DBAs de Oracle deben usar la sintaxis CREATE ROLE.

Concesión de permisos

Ahora que hemos añadido usuarios a nuestra base de datos, es el momento de empezar a reforzar la seguridad añadiendo permisos. Nuestro primer paso será conceder los permisos de base de datos adecuados a nuestros usuarios. Esto lo lograremos mediante el uso de la declaración SQL GRANT.

Aquí está la sintaxis de la declaración:

SUBVENCIÓN [ON ]
TO
CON OPCIÓN DE SUBVENCIÓN]

Ahora, echemos un vistazo a esta declaración línea por línea. La primera línea, GRANT , nos permite especificar los permisos específicos de la tabla que estamos concediendo. Estos pueden ser permisos a nivel de tabla (como SELECT, INSERT, UPDATE y DELETE) o permisos de base de datos (como CREATE TABLE, ALTER DATABASE y GRANT). Se pueden conceder más de un permiso en una única instrucción GRANT, pero los permisos a nivel de tabla y los permisos a nivel de base de datos no se pueden combinar en una sola instrucción.

La segunda línea, ON , se utiliza para especificar la tabla afectada para los permisos a nivel de tabla. Esta línea se omite si estamos concediendo permisos a nivel de base de datos. La tercera línea especifica el usuario o función al que se le están concediendo permisos.

Finalmente, la cuarta línea, CON OPCIÓN DE SUBVENCIÓN, es opcional. Si esta línea está incluida en la sentencia, el usuario afectado también puede conceder estos mismos permisos a otros usuarios. Tenga en cuenta que la OPCIÓN CON SUBVENCIÓN no se puede especificar cuando los permisos se asignan a una función.

Ejemplos

Veamos algunos ejemplos. En nuestro primer escenario, hemos contratado recientemente a un grupo de 42 operadores de entrada de datos que añadirán y mantendrán registros de clientes. Necesitan poder acceder a la información de la tabla Clientes, modificar esta información y añadir nuevos registros a la tabla. No deberían poder borrar por completo un registro de la base de datos. Primero, debemos crear cuentas de usuario para cada operador y luego agregarlas todas a un nuevo rol, DataEntry. A continuación, debemos utilizar la siguiente sentencia SQL para concederles los permisos adecuados:

SELECCIONAR CONCESIÓN, INSERTAR, ACTUALIZAR
>.ON Clientes
>TO DataEntry

Y eso es todo lo que hay que hacer! Ahora vamos a examinar un caso en el que estamos asignando permisos a nivel de base de datos. Queremos permitir a los miembros de la función de DBA añadir nuevas tablas a nuestra base de datos. Además, queremos que puedan conceder a otros usuarios permiso para hacer lo mismo. Aquí está la declaración SQL:

CREAR TABLA DE BECAS
TO DBA
CON OPCIÓN DE SUBVENCIÓN

Note que hemos incluido la línea de OPCIÓN CON BECA para asegurar que nuestros DBAs puedan asignar este permiso a otros usuarios.

Eliminación de permisos

Una vez que hemos concedido los permisos, a menudo resulta necesario revocarlos en una fecha posterior. Afortunadamente, SQL nos proporciona el comando REVOKE para eliminar permisos previamente concedidos. Aquí está la sintaxis:

REVOCAR[OPCIÓN DE SUBVENCIÓN] >.ON
FROM

Notará que la sintaxis de este comando es similar a la del comando GRANT. La única diferencia es que WITH GRANT OPTION se especifica en la línea de comandos REVOKE en lugar de al final del comando. A modo de ejemplo, imaginemos que queremos revocar el permiso previamente otorgado a Mary para eliminar registros de la base de datos de Clientes. Usaríamos el siguiente comando:

REVOKE DELETE
ON Clientes
>DE María

Y eso es todo lo que hay que hacer! Hay un mecanismo adicional soportado por Microsoft SQL Server que vale la pena mencionar: el comando DENY. Este comando se puede utilizar para denegar explícitamente un permiso a un usuario que de otro modo podría tener a través de una membresía de rol actual o futura. Aquí está la sintaxis:

DENY ON
TO

Ejemplos

Volviendo a nuestro ejemplo anterior, imaginemos que Mary también era miembro del rol de Managers que también tenía acceso a la tabla de Clientes. La anterior declaración REVOKE no sería suficiente para negarle el acceso a la tabla. Eliminaría el permiso concedido a través de una declaración GRANT dirigida a su cuenta de usuario, pero no afectaría a los permisos obtenidos a través de su pertenencia a la función de administrador. Sin embargo, si usamos una declaración DENY, bloqueará su herencia del permiso. Aquí está el comando:

DENY DELETE
ON Clientes
>A María

El comando DENY crea esencialmente un «permiso negativo» en los controles de acceso a la base de datos. Si más tarde decidimos dar permiso a Mary para eliminar filas de la tabla Clientes, no podemos usar simplemente el comando GRANT. Ese comando sería inmediatamente anulado por el DENY existente. En su lugar, primero utilizaremos el comando REVOKE para eliminar la entrada de permiso negativa de la siguiente manera:

REVOKE DELETE
ON Clientes
>DE María

Notará que este comando es exactamente el mismo que el utilizado para eliminar un permiso positivo. Recuerde que los comandos DENY y GRANT funcionan de manera similar*mdash; ambos crean permisos (positivos o negativos) en el mecanismo de control de acceso a la base de datos. El comando REVOKE elimina todos los permisos positivos y negativos para el usuario especificado. Una vez que se haya dado este mandato, María podrá borrar filas de la mesa si es miembro de un rol que posee ese permiso. Alternativamente, se podría emitir un comando GRANT para proporcionar el permiso DELETE directamente a su cuenta.

A lo largo de este curso, usted ha aprendido mucho sobre los mecanismos de control de acceso soportados por el Lenguaje de Consultas Estándar. Esta introducción debería proporcionarle un buen punto de partida, pero le animo a que consulte la documentación de su DBMS para conocer las medidas de seguridad mejoradas que soporta su sistema. Encontrará que muchas bases de datos soportan mecanismos de control de acceso más avanzados, como la concesión de permisos sobre columnas específicas.