Todo relacional Sistemas de gestión de bases de datos proporcionar algún tipo de mecanismos de seguridad intrínsecos diseñados para minimizar las amenazas de pérdida de datos, corrupción de datos o robo de datos. Van desde la simple protección con contraseña que ofrece acceso Microsoft a la compleja estructura de usuario / rol compatible con bases de datos relacionales avanzadas como Oráculo yMicrosoft SQL Servidor. Algunos mecanismos de seguridad son comunes a todas las bases de datos que implementanlenguaje de consulta estructurado.
Seguridad a nivel de usuario
Las bases de datos basadas en servidor admiten un usuario concepto similar al utilizado en los sistemas operativos de las computadoras. Si está familiarizado con la jerarquía de usuarios / grupos que se encuentra en Microsoft Windows NT y Windows 2000, encontrará que las agrupaciones de usuarios / roles admitidas por SQL Server y Oracle son similares.
Cree cuentas de usuario de base de datos individuales para cada persona con acceso a su base de datos.
Evite el aprovisionamiento de cuentas genéricas accesibles para varias personas diferentes. Primero, esta práctica elimina la responsabilidad individual, si un usuario realiza un cambio en su base de datos (digamos por otorgándose un aumento de $ 5,000), no podrá rastrearlo hasta una persona específica mediante el uso de auditoría registros. En segundo lugar, si un usuario específico abandona su organización y desea eliminar su acceso de la base de datos, debe 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 sp_adduser procedimiento almacenado. Los administradores de bases de datos de Oracle encontrarán CREAR USUARIO comando útil. También es posible que desee investigar esquemas de autenticación alternativos. Por ejemplo, Microsoft SQL Server admite el uso de la seguridad integrada de Windows NT. Bajo este esquema, los usuarios son identificados en la base de datos por sus cuentas de usuario de Windows NT y no es necesario que ingresen un ID de usuario y contraseña adicionales para acceder a la base de datos. Este enfoque es popular entre los administradores de bases de datos porque traslada la carga de la cuenta gestión al personal de administración de la red y proporciona la facilidad de un inicio de sesión único al usuario final.
Seguridad a nivel de rol
Si se encuentra en un entorno con una pequeña cantidad de usuarios, probablemente encontrará que crear cuentas de usuario y asignarles permisos directamente es suficiente para sus necesidades. Sin embargo, si tiene una gran cantidad de usuarios, se verá abrumado por el mantenimiento de las cuentas y los permisos adecuados. Para aliviar esta carga, las bases de datos relacionales admiten 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 roles y los permisos se asignan al rol como un todo en lugar de a las cuentas de usuario individuales. Por ejemplo, puede crear un rol de DBA y luego agregar las cuentas de usuario de su personal administrativo a este rol. Después de eso, puede 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 sp_addrole procedimiento almacenado, mientras que los DBA de Oracle deben usar el CREAR PAPEL sintaxis.
Concesión de permisos
Ahora que hemos agregado usuarios a nuestra base de datos, es hora de comenzar a fortalecer la seguridad agregando permisos. Nuestro primer paso será otorgar los permisos de base de datos adecuados a nuestros usuarios. Lo lograremos mediante el uso de la instrucción SQL GRANT.
Aquí está la sintaxis de la declaración:
CONCEDER.
[EN.
A.
[CON OPCIÓN DE SUBVENCIÓN]
Ahora, echemos un vistazo a esta declaración línea por línea. La primera linea CONCEDER , nos permite especificar los permisos de tabla específicos que estamos otorgando. Estos pueden ser permisos de nivel de tabla (como SELECT, INSERT, UPDATE y DELETE) o permisos de base de datos (como CREATE TABLE, ALTER DATABASE y GRANT). Se puede otorgar más de un permiso en una sola declaració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 declaración.
La segunda línea EN
Finalmente, la cuarta línea, CON OPCIÓN DE SUBVENCIÓN, es opcional. Si esta línea se incluye en la declaración, el usuario afectado también puede otorgar estos mismos permisos a otros usuarios. Tenga en cuenta que WITH GRANT OPTION no se puede especificar cuando los permisos se asignan a un rol.
Subvenciones de base de datos de ejemplo
Veamos algunos ejemplos. En nuestro primer escenario, hemos contratado recientemente a un grupo de 42 operadores de entrada de datos que agregarán y mantendrán registros de clientes. Deben acceder a la información de la tabla Clientes, modificar esta información y agregar nuevos registros a la tabla. No deberían poder eliminar 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, Entrada de datos. A continuación, debemos usar la siguiente declaración SQL para otorgarles los permisos adecuados:
GRANT SELECT, INSERT, UPDATE.
EN Clientes.
TO DataEntry.
Ahora examinemos un caso en el que estamos asignando permisos a nivel de base de datos. Queremos permitir que los miembros del rol de DBA agreguen nuevas tablas a nuestra base de datos. Además, queremos que puedan otorgar permiso a otros usuarios para que hagan lo mismo. Aquí está la declaración SQL:
GRANT CREAR TABLA.
A DBA.
CON OPCIÓN DE SUBVENCIÓN.
Tenga en cuenta que hemos incluido la línea WITH GRANT OPTION para asegurarnos de que nuestros DBA puedan asignar este permiso a otros usuarios.
Eliminar permisos
SQL incluye el comando REVOKE para eliminar los permisos otorgados previamente. Esta es la sintaxis:
REVOCAR [OPCIÓN DE SUBVENCIÓN PARA]
EN.
DE.
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 comando REVOKE en lugar de al final del comando. Como ejemplo, imaginemos que queremos revocar el permiso otorgado previamente a Mary para eliminar registros de la base de datos de Clientes. Usaríamos el siguiente comando:
REVOCAR ELIMINAR.
EN Clientes.
DE María.
Hay un mecanismo adicional compatible con 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. Esta es la sintaxis:
NEGAR.
EN.
A.