Autorización y permisos en SQL Server
Al crear los objetos de base de datos, se deben conceder permisos explícitamente para que estos objetos sean accesibles a los usuarios. Cada objeto tiene permisos que se pueden conceder utilizando las instrucciones específicas para definir los tipos de permiso que disfruta dicho objeto.
El principio de menor privilegio
El desarrollo de una aplicación utilizará un enfoque de cuenta de usuario con los mínimos privilegios necesarios (LUA). Se trata de una parte importante de una estrategia defensiva para contrarrestar amenazas de seguridad. El enfoque LUA garantiza que los usuarios siguen el principio de privilegios mínimos y siempre iniciarán la sesión con cuentas de usuario limitadas. Las tareas administrativas se dividen mediante funciones de servidor fijo y el uso del rol de servidor sysadmin está restringido.
En conveniente seguir siempre el principio de privilegios mínimos al conceder permisos a los usuarios de la base de datos. Por tanto se concederán los permisos mínimos necesarios a un usuario o función para realizar una tarea determinada.
Nodo de seguridad
Desarrollar y probar una aplicación utilizando el enfoque LUA añade un grado de dificultad al proceso de desarrollo. Es más fácil crear objetos y escribir código con permisos de administrador del sistema o propietario de la base de datos que hacerlo utilizando una cuenta LUA. Sin embargo, el desarrollo de aplicaciones con una cuenta altamente privilegiada puede ocultar el impacto de la reducción de la funcionalidad cuando los usuarios menos privilegiados intentan ejecutar una aplicación que requiere permisos elevados para funcionar correctamente. Conceder permisos excesivos a los usuarios para readquirir la funcionalidad perdida puede hacer una aplicación vulnerable al ataque. Diseñar, desarrollar y probar una aplicación con una cuenta LUA impone un enfoque de planificación de la seguridad que elimina sorpresas desagradables y la tentación de otorgar privilegios elevados como solución rápida. Se pueden utilizar inicios de sesión de SQL Server para realizar pruebas incluso si la aplicación está destinada a implementarse mediante la autenticación de Windows.
Permisos basados en roles
La concesión de permisos a roles en lugar de a usuarios simplifica la administración de seguridad. Los conjuntos de permisos asignados a roles son heredados por todos los miembros del rol. Es más fácil agregar o quitar usuarios de un rol que recrear conjuntos de permisos separados para usuarios individuales. Las funciones pueden anidarse; Sin embargo, demasiados niveles de anidación pueden perjudicar el rendimiento. También se pueden añadir usuarios a funciones fijas de base de datos para simplificar la asignación de permisos.
Es posible conceder permisos a nivel de esquema. Los usuarios heredarán automáticamente los permisos de todos los nuevos objetos creados en cada esquema; de este modo no será necesario conceder permisos al crear nuevos objetos.
Permisos mediante código de procedimiento
La encapsulación del acceso a datos a través de módulos como procedimientos almacenados y funciones definidas por el usuario proporciona una capa adicional de protección alrededor de la aplicación. Esto evita que los usuarios interactúen directamente con objetos de base de datos al conceder permisos sólo a procedimientos almacenados o funciones y negar permisos a objetos subyacentes como tablas. SQL Server logra esto mediante el encadenamiento de propiedad.
Declaraciones de permiso
Las tres instrucciones de permisos de Transact-SQL se describen en la siguiente tabla.
La sentencia GRANT puede asignar permisos a un grupo o rol que los usuarios de la base de datos pueden heredar. Sin embargo, la instrucción DENY tiene prioridad sobre todas las demás instrucciones de permiso. Por lo tanto, un usuario al que se le ha denegado un permiso no puede heredarlo de otro rol.
Nota. No es posible denegar permisos DENY a los miembros de la función de servidor sysadmin y los propietarios de objetos.
Cadenas de propiedad
SQL Server garantiza que sólo los usuarios principales a los que se haya concedido permiso puedan acceder a los objetos. El acceso a través de varios objetos de base de datos, uno detrás de otro, se denomina como cadena. Cuando SQL Server va enlazando accesos a través de los diferentes objetos, evalúa los permisos de manera diferente que si accediera a cada elemento por separado. Cuando se accede a un objeto a través de una cadena, SQL Server compara primero el propietario del objeto con el propietario del objeto que llama (el enlace anterior de la cadena). Si ambos objetos tienen el mismo propietario, no se comprueban los permisos del objeto referenciado. Cada vez que un objeto accede a otro objeto que tiene un propietario diferente, la cadena de propiedad se rompe y SQL Server debe comprobar el contexto de seguridad del usuario que lo llama.
Código procedural y cadena de propiedad
Si se conceden a un usuario permisos de ejecución en un procedimiento almacenado determinado que selecciona datos de una tabla. Si el procedimiento almacenado y la tabla tienen el mismo propietario, no será necesario que el usuario reciba ningún permiso en la tabla e incluso se pueden denegar permisos. Sin embargo, si el procedimiento almacenado y la tabla tienen diferentes propietarios, SQL Server debe comprobar los permisos del usuario en la tabla antes de permitir el acceso a los datos.
Nota. La cadena de propiedad no se aplica en el caso de sentencias SQL dinámicas. Para llamar a un procedimiento que ejecuta una sentencia SQL, se deben conceder permisos al usuario que llama a las tablas subyacentes, dejando la aplicación vulnerable a un ataque. SQL Server proporciona nuevos mecanismos, como la suplantación y la firma de módulos con certificados, que no requieren la concesión de permisos en las tablas subyacentes. Esto también se puede utilizar con procedimientos almacenados CLR.
Roles de base de datos y servidor en SQL Server
Todas las versiones de SQL Server utilizan la seguridad basada en funciones, que permite asignar permisos a una función o grupo de usuarios, en lugar de a usuarios individuales. Los roles fijos de servidor y base de datos tienen un conjunto fijo de permisos asignados a ellos.
Roles fijos de servidor
Permisos
Como se acaba de indicar, tienen un conjunto fijo de permisos y su ámbito es todo el servidor. Están destinados para su uso en la administración de SQL Server y los permisos asignados a ellos no se pueden cambiar. Los inicios de sesión se pueden asignar a roles fijos de servidor sin necesidad de poseer una cuenta de usuario en una base de datos.
Nota de seguridad. El rol de servidor fijo sysadmin abarca todos los demás roles y tiene un alcance ilimitado. No agregue usuarios a esta función a menos que sean altamente confiables. Los miembros de la función sysadmin tienen privilegios administrativos irrevocables en todas las bases de datos y recursos del servidor.
Es necesario ser selectivo cuando se añaden usuarios a roles fijos de servidor. Por ejemplo, el rol bulkadmin permite a los usuarios insertar el contenido de cualquier archivo local en una tabla, lo que podría poner en peligro la integridad de los datos.
Roles fijos de base de datos
Los roles fijos de base de datos tienen un conjunto predefinido de permisos que están diseñados para permitir administrar grupos de permisos. Los miembros de la función db_owner pueden realizar todas las actividades de configuración y mantenimiento en la base de datos.
Roles de base de datos y usuarios
Para poder trabajar con objetos de base de datos, los inicios de sesión deben estar asignados a las cuentas de usuario de la base de datos. Los usuarios de la base de datos se pueden agregar a las funciones de la base de datos, heredando todos los conjuntos de permisos asociados con esas funciones. Pueden ser concedidos todos los permisos.
También se deben considerar los roles public, dbo y guest (invitado) a la hora de diseñar las directivas de seguridad para una aplicación.
El rol public
El rol público está contenido en cada base de datos, que incluya bases de datos del sistema. No se puede eliminar y no está permitido agregar o quitar usuarios de él. Los permisos concedidos a este rol son heredados por todos los demás usuarios y roles porque pertenecen al rol público de forma predeterminada. A este rol se concederán sólo los permisos que se desee que tengan todos los usuarios.
La cuenta de usuario dbo
El dbo, o propietario de la base de datos, es una cuenta de usuario que tiene permisos implícitos para realizar todas las actividades en la base de datos. Los miembros del rol fijo de servidor sysadmin se asignan automáticamente a dbo.
Nota. Dbo es también el nombre de un esquema, tal y como se describe en Ownership and User-Schema Separation in SQL Server.
La cuenta de usuario dbo se confunde a menudo con el rol fijo de base de datos db_owner. El ámbito de db_owner es una base de datos; El ámbito de sysadmin es el servidor completo. La pertenencia a la función db_owner no confiere privilegios de usuario dbo.
La cuenta de usuario invitado (guest)
Una vez que un usuario ha sido autenticado y se le permite iniciar sesión en una instancia de SQL Server, debe existir una cuenta de usuario independiente en cada base de datos a la que el usuario tenga acceso. Esto requiere tener una cuenta de usuario en cada base de datos para evitar que los usuarios se conecten a una instancia de SQL Server y accedan a todas las bases de datos del servidor. La existencia de una cuenta de usuario invitado evita este requisito permitiendo un inicio de sesión sin una cuenta de usuario de base de datos para acceder a una base de datos.
La cuenta de invitado es una cuenta incorporada en todas las versiones de SQL Server. De forma predeterminada, se deshabilita en las nuevas bases de datos. Si está habilitada, puede desactivarse revocando sus permisos de conexión ejecutando la sentencia REVOKE CONNECT FROM GUEST.
Nota de seguridad. Hay que tratar de evitar usar la cuenta de invitado (guest); Todos los inicios de sesión sin sus propios permisos de base de datos obtienen los permisos de base de datos concedidos a esta cuenta. Si debe usar la cuenta de invitado, es mejor concederle los permisos mínimos
Prácticas recomendadas: al planificar una solución de seguridad, considerar las siguientes prácticas recomendadas:
Proporcionar a cada usuario sólo los permisos que realmente necesite.
Utilizar la herencia de seguridad para minimizar el número de permisos implícitos que deben habilitarse.
Utilizar contenedores principales, como grupos o roles, para crear una capa de abstracción entre los principales permisos. Después se utilizará la pertenencia a estos grupos para controlar el acceso. Los cambios en el personal no deben requerir cambios en los permisos.
Más información en:
No hay comentarios:
Publicar un comentario