Autorización y permisos en SQL

Server
Al crear objetos de base de datos, se deben conceder permisos de forma
explícita para que los usuarios tengan acceso a ellos. Cada objeto susceptible de
protegerse tiene permisos que se pueden otorgar a una entidad de seguridad
mediante instrucciones de permiso.
Principio de los privilegios mínimos
Desarrollar una aplicación utilizando un enfoque basado en cuenta de usuario
de privilegios mínimos (LUA) constituye una parte importante de una estrategia
de defensa exhaustiva contra las amenazas a la seguridad. El enfoque LUA
garantiza que los usuarios siguen el principio de los privilegios mínimos y
siempre inician sesión con cuentas de usuario limitadas. Las tareas
administrativas se realizan utilizando roles fijos del servidor y el uso del rol fijo
del servidor sysadmin es muy restringido.

Cuando conceda permisos a usuarios de base de datos, siga siempre el principio

de los privilegios mínimos. Otorgue a usuarios y roles los mínimos permisos
necesarios para que puedan realizar una tarea concreta.
Importante
Cuado se desarrolla o prueba una aplicación utilizando el enfoque LUA, se
aumenta el grado de dificultad del proceso de desarrollo. Resulta más fácil crear
objetos y escribir código cuando se inicia sesión como administrador del
sistema o propietario de la base de datos que cuando se utiliza una cuenta
LUA. Sin embargo, el desarrollo de aplicaciones con cuentas de privilegios
elevados puede entorpecer el impacto de funcionalidades reducidas cuando
usuarios con privilegios de nivel bajo intentan ejecutar una aplicación que
requiere permisos elevados para funcionar correctamente. Otorgar a los
usuarios permisos excesivos para recuperar funcionalidades perdidas puede
exponer a la aplicación a posibles ataques. El diseño, desarrollo y prueba de una
aplicación en la que se ha iniciado sesión con una cuenta LUA impone un
enfoque disciplinado del planeamiento de la seguridad que evita sorpresas
desagradables, así como la tentación de recurrir a la solución rápida de otorgar
privilegios elevados. Puede utilizar un inicio de sesión de SQL Server para
realizar pruebas, incluso aunque la aplicación esté pensada para implementarse
con autenticación de Windows.
Permisos basados en roles
Otorgar permisos a roles en lugar de a usuarios simplifica la administración de
la seguridad. Los conjuntos de permisos asignados a roles los heredan todos los
miembros del rol. Es más fácil agregar o quitar usuarios de un rol que volver a
crear conjuntos de permisos distintos para cada usuario. Las roles se pueden
anidar. Sin embargo, la existencia de demasiados niveles de anidamiento puede
reducir el rendimiento. También puede agregar usuarios a roles fijos de bases
de datos para simplificar los permisos de asignación.

Puede conceder permisos en el nivel de esquema. Los usuarios heredan

automáticamente los permisos en todos los objetos nuevos creados en el
esquema; no es necesario otorgar permisos cuando se crean objetos nuevos.
Permisos a mediante código basado en
procedimiento
El encapsulamiento del acceso a los datos a través de módulos tales como
procedimientos almacenados y funciones definidas por el usuario brinda un
nivel de protección adicional a la aplicación. Se puede evitar que los usuarios
interactúen directamente con objetos de la base de datos otorgando permisos
solo a procedimientos almacenados o funciones, y denegando permisos a
objetos subyacentes tales como tablas. SQL Server lo consigue mediante
encadenamiento de propiedad.
Instrucciones de permiso
En la siguiente tabla se describen las tres instrucciones de permiso de Transact-
SQL.
Instrucción
de permiso Descripción

GRANT Concede un permiso.

REVOKE Revoca un permiso. Este es el estado predeterminado de un objeto nuevo. Un

permiso revocado a un usuario o rol se puede heredar de otros grupos o roles a los
que está asignada la entidad de seguridad.

DENY DENY revoca un permiso de manera que no pueda ser heredado. DENY tiene
prioridad sobre todos los permisos, pero no se aplica a propietarios de objeto o
miembros de sysadmin . Si deniega permisos a un objeto en el rol public , se los
deniega igualmente a todos los usuarios y roles excepto a los propietarios del objeto
y a los miembros de sysadmin .
  La instrucción GRANT puede asignar permisos a un grupo o rol que puede
ser heredada por los usuarios de la base de datos. No obstante, la
instrucción DENY tiene prioridad sobre el resto de las instrucciones de
permiso. Por ello, un usuario al que se le ha denegado un permiso no
puede heredarlo de otro rol.

Cadenas de propiedad
SQL Server garantiza que solamente puedan tener acceso a los objetos las
entidades de seguridad a las que se les han concedido permisos. Cuando varios
objetos de base de datos tienen acceso el uno al otro, la secuencia se conoce
como "cadena". Cuando SQL Server atraviesa los vínculos de la cadena, evalúa
los permisos de manera diferente a como lo haría si estuviera obteniendo
acceso a cada elemento separadamente. Cuando se obtiene acceso a un objeto
a través de una cadena, SQL Server primero compara al propietario del objeto
con el propietario del objeto de llamada (el vínculo anterior de la cadena). Si
ambos objetos tienen el mismo propietario, los permisos del objeto al que se
hace referencia no se comprueban. Siempre que un objeto obtiene acceso a
otro objeto que tiene un propietario distinto, la cadena de propiedad se rompe
y SQL Server debe comprobar el contexto de seguridad del llamador.
Código basado en procedimiento y
encadenamiento de propiedad
Suponga que a un usuario se le otorgan permisos para ejecutar en un
procedimiento almacenado que selecciona datos desde una tabla. Si el
procedimiento almacenado y la tabla tienen el mismo propietario, el usuario no
necesita ningún permiso en la tabla y se le pueden incluso denegar
permisos. Sin embargo, si el procedimiento almacenado y la tabla tienen
distintos propietarios, SQL Server debe comprobar los permisos del usuario en
la tabla antes de permitirle el acceso a los datos.
Nota
El encadenamiento de propiedad no se aplica en el caso de las instrucciones de
SQL dinámico.Para llamar a un procedimiento que ejecuta una instrucción SQL,
el llamador debe tener permiso de acceso a las tablas subyacentes, lo que deja
a su aplicación expuesta a posibles ataques de inyección SQL. SQL Server
proporciona nuevos mecanismos, como suplantación y módulos de firma con
certificados, que no requieren otorgar permisos en las tablas subyacentes. Estos
mecanismos se pueden utilizar también con procedimientos almacenados CLR.
Crear una base de datos MySQL y un
usuario con permisos para esa base de
datos
A modo de chuleta dejo este microtutorial de cómo crear una base de
datos MySQL y un usuario con permisos para esa base de datos. Es muy
útil cuando estoy creando un sitio web y necesito una base de datos con
un usuario que solo puede acceder a esa base de datos.

Desde una línea de comandos ejecuto el cliente MySQL e introduzco la

contraseña

# mysql -u root -p
Enter password:
Creo la base de datos

mysql> CREATE DATABASE mi_base_de_datos CHARACTER SET utf8 COLLATE

utf8_general_ci;
Creo el usuario local mi_usuario con la contraseña mi_contraseña

mysql> CREATE USER 'mi_usuario'@'localhost' identified by 'mi_contraseña';

Le doy todos los permisos a ese usuario en esa base de datos

mysql> GRANT ALL PRIVILEGES ON mi_base_de_datos.* TO

mi_usuario@localhost;
mysql> FLUSH PRIVILEGES;
Salgo del cliente de base de datos

mysql> exit
Bye
Me vuelvo a contectar con el nuevo usuario e introduzco la contraseña

# mysql -u mi_usuario -p
Enter password:
Si ahora visualizo las bases de datos

mysql> show databases;

Solo debo de ver a la que tengo acceso