Bases de datos parcialmente contenidas

Bases de datos contenidas

Una base de datos contenida es una base de datos que está aislada de otras bases de datos y de la instancia de SQL Server que aloja la base de datos.  Existen varios tipos de datos aislados de la base de datos y de la instancia.

Los metadatos que describen una base de datos.

La autenticación del usuario.

El entorno de SQL Server.

Algunas características de bases de las bases de datos parcialmente contenidas, como el almacenamiento de metadatos en la base de datos, se aplican a todas las bases de datos de SQL Server. Algunos beneficios de las bases de datos parcialmente contenidas, como la autenticación de nivel de base de datos y la intercalación de catálogos, deben habilitarse antes para que estén disponibles. La contención parcial se habilita con  sentencias CREATE DATABASE y ALTER DATABASE o utilizando el SQL Server Management Studio. 

Concepto de base de datos parcialmente contenida

Una base de datos totalmente contenida incluye todas las configuraciones y metadatos necesarios para definir la base de datos. Las bases de datos parcialmente contenidas facilitan la separación de una base de datos de su instancia de SQL Server y otras bases de datos.

Cualquier entidad definida por el usuario que dependa únicamente de las funciones que residen en la base de datos se considera totalmente contenida. Cualquier entidad definida por el usuario que depende de funciones que residen fuera de la base de datos se considera no contenida.

Los siguientes términos se aplican al modelo de base de datos contenido.

Base de datos no contenida

Es una base de datos que tiene la contención establecida en NONE. Todas las bases de datos en versiones anteriores a SQL Server 2012 no están contenidas. De forma predeterminada, todas las bases de datos de SQL Server 2012 y posteriores tienen una contención establecida en NONE.

Base de datos parcialmente contenida

Una base de datos parcialmente contenida, es una base de datos contenida que puede permitir que algunas características crucen el límite de la base de datos. SQL Server incluye la capacidad de determinar cuándo se cruzan los límites de contención.

La función de base de datos contenida está actualmente disponible sólo en un estado parcialmente contenido. Una base de datos parcialmente contenida es una base de datos contenida que permite el uso de características no contenidas.

Se puede utilizar la vista sys.dm_db_uncontained_entities y sys.sql_modules  para devolver información sobre objetos o características no contenidas. Determinando el estado de contención de los elementos de su base de datos, se puede descubrir qué objetos o características deben ser reemplazados o alterados para promover la contención.

Importante. Dado que determinados objetos tienen un valor de contención predeterminado de NONE, esta vista puede devolver falsos positivos.

Usuario contenido

Hay dos tipos de usuarios para las bases de datos contenidas.

Usuario de base de datos contenida con contraseña

Los usuarios de la base de datos contenida con contraseñas son autenticados por la base de datos. 

Usuarios de Windows

Los usuarios autorizados de Windows y los miembros de grupos de Windows autorizados pueden conectarse directamente a la base de datos y no necesitan inicios de sesión en la base de datos master. La base de datos confía en la autenticación de Windows.

Los usuarios basados en inicios de sesión en la base de datos master pueden tener acceso a una base de datos contenida, pero eso crearía una dependencia en la instancia de SQL Server.

Importante. Habilitar bases de datos parcialmente contenidas controla el acceso a la instancia de SQL Server a los propietarios de la base de datos. Para obtener más información, Security Best Practices with Contained Databases. 

Límites de la base de datos

Debido a que las bases de datos parcialmente contenidas separan la funcionalidad de la base de datos de las de la instancia, existe una línea claramente definida entre estos dos elementos llamada límite de la base de datos.

Dentro del límite de la base de datos se encuentra el modelo de base de datos, donde se desarrollan y gestionan las bases de datos. Por ejemplo, las entidades ubicadas dentro de la base de datos incluyen las tablas de sistema como sys.tables, los usuarios de bases de datos con contraseñas y tablas de usuario de la base de datos referenciada con un nombre de dos partes.

Fuera del límite de la base de datos se encuentra el modelo de gestión, que se refiere a funciones y gestión a nivel de instancia. Ejemplos de entidades ubicadas fuera del límite de la base de datos incluyen tablas del sistema como sys.endpoints, usuarios asignados a los inicios de sesión y tablas de usuario en otra base de datos referenciada por un nombre de tres partes.

Contención

Las entidades de usuario que residen completamente dentro de la base de datos se consideran contenidas. Las entidades que residen fuera de la base de datos, o dependen de la interacción con funciones fuera de la base de datos, se consideran no contenidas.

En general, las entidades de usuario pertenecen a las siguientes categorías de contención:

Entidades de usuario completamente contenidas (son aquellas que nunca cruzan el límite de la base de datos), por ejemplo sys.indexes. Cualquier código que utilice estas características o cualquier objeto que sólo hace referencia a estas entidades también está totalmente contenido.

Las entidades de usuario no contenidas (aquellas que cruzan el límite de la base de datos), por ejemplo, sys.server_principals o un servidor principal (login). Cualquier código que utiliza estas entidades o cualquier función que hace referencia a estas entidades no contienen.

Beneficios del uso de bases de datos parcialmente contenidas

Hay problemas y complicaciones asociadas a las bases de datos no contenidas que se pueden resolver utilizando una base de datos parcialmente contenida.

Movimiento de una base de datos parcialmente contenida

Uno de los problemas que se produce al mover bases de datos es que alguna información importante puede no estar disponible cuando migra una base de datos de una instancia a otra. Por ejemplo, la información de inicio de sesión que se almacena dentro de la instancia en lugar de en la base de datos. Cuando se migra una base de datos no contenida de una instancia a otra instancia de SQL Server, se pierde esta información. Se debe identificar la información que falta y moverla con su base de datos a la nueva instancia de SQL Server. Este proceso puede ser difícil y requerir mucho tiempo.

Una base de datos parcialmente contenida puede almacenar información importante en la base de datos para que la base de datos conserve la información después migrarla.

Nota. Una base de datos parcialmente contenida puede proporcionar documentación que describa las características que son utilizadas por una base de datos que no se puede separar de la instancia. Esto incluye una lista de otras bases de datos interrelacionadas, configuraciones del sistema que la base de datos requiere pero no se puede contener, y así sucesivamente.

Beneficio de las bases de datos contenidas: los usuarios de siempre están activados

Al reducir los vínculos a la instancia de SQL Server, las bases de datos parcialmente contenidas pueden ser útiles durante la conmutación por error cuando se utiliza siempre en grupos de disponibilidad.

La creación de usuarios contenidos, permite al usuario conectarse directamente a la base de datos contenida. Esta es una característica muy significativa en los escenarios de alta disponibilidad y recuperación de desastres, como en una solución Siempre en Línea. Si los usuarios están contenidos, en caso de conmutación por error, la gente podría conectarse a la secundaria sin crear inicios de sesión en la instancia que aloja la secundaria. Esto proporciona un beneficio inmediato. 

Desarrollo inicial de bases de datos

Como un desarrollador no tiene por qué saber dónde se desplegará una nueva base de datos,  limitando los impactos ambientales desplegados en la base de datos disminuirá el trabajo y la preocupación del desarrollador. En el modelo no contenido, el desarrollador debe considerar posibles impactos ambientales en la nueva base de datos. Sin embargo, al usar bases de datos parcialmente contenidas, los desarrolladores pueden detectar impactos a nivel de instancia en la base de datos.

Autorizaciones y permisos en servidores SQL Server

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 

Permisos 

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:

Identidad y control de acceso (motor de base de datos)

Entidades de seguridad (motor de base de datos)

Autorizar logins para acceder a bases de datos

Creación de un inicio de sesión (Login)

Para acceder al motor de base de datos, los usuarios necesitan un inicio de sesión (Login). El inicio de sesión puede representar la identidad del usuario como una cuenta de Windows o como miembro de un grupo de Windows o el inicio de sesión puede ser un inicio de sesión de SQL Server que sólo existe en SQL Server. Siempre que sea posible, se utilizará la autenticación de Windows.

De forma predeterminada, los administradores del equipo tienen acceso completo a SQL Server. Para este ejemplo, queremos tener un usuario con menos privilegios; Por lo tanto, se creará una nueva cuenta local de autenticación de Windows en el equipo. Para ello, es necesario administrador del equipo. A continuación, concede a ese nuevo usuario el acceso a SQL Server.

Para crear una nueva cuenta de Windows:

Hacer click en Inicio, hacer click en Ejecutar, en el cuadro Abrir, escribir

% SystemRoot% \ system32 \ compmgmt.msc / s

Autenticación y autorización de usuarios en SQL Server

Autenticar conexiones con SQL Server

Existen dos modos posibles: modo de autenticación de Windows y modo mixto. El modo de autenticación de Windows habilita la autenticación de Windows y deshabilita la autenticación de SQL Server. El modo mixto permite la autenticación de Windows y la autenticación de SQL Server. La autenticación de Windows siempre está disponible y no se puede deshabilitar.