Artículo
09/29/2010

Extender la suplantación de la base de datos mediante EXECUTE AS

SQL Server admite la posibilidad de suplantar a otra entidad de seguridad de forma explícita mediante la instrucción EXECUTE AS independiente, o de forma implícita mediante la cláusula EXECUTE AS en los módulos. La instrucción EXECUTE AS independiente puede utilizarse para suplantar a entidades de seguridad de nivel de servidor, o inicios de sesión, mediante la instrucción EXECUTE AS LOGIN. La instrucción EXECUTE AS independiente también puede utilizarse para suplantar a entidades de seguridad de nivel de base de datos, o usuarios, mediante la instrucción EXECUTE AS USER.

Las suplantaciones implícitas que se realizan a través de la cláusula EXECUTE AS en los módulos suplantan el usuario o el inicio de sesión especificado en la base de datos o en el servidor. Esta suplantación depende de si el módulo es un módulo de base de datos, como un procedimiento almacenado o una función, o un módulo de servidor, como un desencadenador de servidor.

Conceptos básicos acerca del ámbito de la suplantación

Al suplantar a una entidad de seguridad mediante la instrucción EXECUTE AS LOGIN, o en un módulo de ámbito de servidor mediante la cláusula EXECUTE AS, el ámbito de la suplantación afecta a todo el servidor. Esto significa que después del cambio de contexto es posible obtener acceso a cualquier recurso del servidor en el que el inicio de sesión suplantado tenga permisos.

Sin embargo, cuando se suplanta a una entidad de seguridad mediante una instrucción EXECUTE AS USER, o en un módulo de ámbito de base de datos mediante la cláusula EXECUTE AS, el ámbito de la suplantación está limitado a la base de datos de forma predeterminada. Esto significa que las referencias a objetos fuera del ámbito de la base de datos devolverán un error. Observe el siguiente escenario para comprender mejor el motivo de este comportamiento predeterminado.

Es posible que el propietario de una base de datos, a pesar de tener todos los permisos posibles dentro de esa base de datos, no tenga ningún permiso fuera del ámbito de la base de datos. Por lo tanto, SQL Server no permite al propietario de la base de datos suplantar, ni conceder a nadie más la capacidad para suplantar, a otro usuario con el fin de obtener acceso a los recursos fuera del ámbito de los permisos actuales del propietario de la base de datos.

Por ejemplo, imaginemos dos bases de datos en un entorno de host que pertenecen cada una a una entidad de propiedad diferente. El propietario de Database1 es Bob y el de Database2 es Fred. Ni Bob ni Fred desean que otros usuarios obtengan acceso a los recursos de sus bases de datos. Como propietario de la Database1, Bob puede crear un usuario para Fred en su base de datos y, puesto que dispone de todos los permisos en la Database 1, Bob también puede suplantar al usuario Fred. Sin embargo, debido a las restricciones de seguridad impuestas por SQL Server, Bob no puede tener acceso a la base de datos de Fred en un contexto suplantado. Si estas restricciones predeterminadas no estuvieran vigentes, Bob podría obtener acceso a los datos de Fred sin el conocimiento de Fred. Este es el motivo por el que el ámbito de las suplantaciones de base de datos está limitado de forma predeterminada por la base de datos.

No obstante, en determinadas circunstancias, puede resultar útil extender selectivamente el ámbito de la suplantación más allá de la base de datos. Por ejemplo, esto ocurriría con una aplicación que utiliza dos bases de datos y necesita obtener acceso a una base de datos desde la otra.

Supongamos la existencia de una aplicación de mercadotecnia que invoca un procedimiento almacenado denominado GetSalesProjections en la base de datos Marketing y en el procedimiento almacenado se ha definido un cambio de contexto de ejecución. El procedimiento almacenado llama a la base de datos Sales para recuperar la información de ventas de la tabla SalesStats. De forma predeterminada, este escenario no funcionará porque un contexto de ejecución establecido dentro de una base de datos no es válido fuera de ella. Sin embargo, los programadores de la aplicación de mercadotecnia no desean que los usuarios de la aplicación tengan acceso directo a la base de datos Sales ni permisos en ninguno de sus objetos. La solución ideal sería utilizar la cláusula EXECUTE AS en el procedimiento almacenado para suplantar a un usuario que dispone del permiso necesario en la base de datos Sales. No obstante, las restricciones predeterminadas actualmente en vigor lo impiden. Así pues, la cuestión es cómo pueden los programadores solucionar este problema.

En SQL Server, puede extender selectivamente el ámbito de la suplantación de la base de datos definida en una base de datos estableciendo un modelo de confianza entre las dos bases de datos. Sin embargo, antes de describir este modelo de confianza y cómo puede el ámbito de la suplantación extenderse selectivamente, debería familiarizarse con la autenticación y la función de los autenticadores en SQL Server.

Conceptos básicos acerca de los autenticadores

La autenticación es el proceso mediante el cual una determinada entidad de seguridad establece y prueba su identidad en un sistema. Un autenticador es una entidad que autentica, o certifica, la autenticidad de una determinada entidad de seguridad. Por ejemplo, cuando se establece una conexión a SQL Server, el inicio de sesión que se establece para esa conexión la autentica la instancia de SQL Server.

Supongamos una situación en la que un usuario cambia explícitamente el contexto en el servidor mediante la instrucción EXECUTE AS LOGIN. Para ello se necesitan permisos de suplantación en el servidor. Estos permisos otorgan al receptor del permiso, el usuario que ha llamado a la instrucción EXECUTE AS LOGIN, la capacidad para suplantar el inicio de sesión especificado en cualquier lugar de la instancia de SQL Server. Efectivamente, la sentencia permite al creador de la llamada simular la acción de inicio de sesión como el inicio de sesión suplantado. El propietario de los permisos en el ámbito del servidor es el usuario sysadmin propietario de la instancia de SQL Server. En este caso de suplantación en el servidor, el autenticador es el usuario sysadmin o la propia instancia de SQL Server.

Sin embargo, supongamos una situación en la que se establece un contexto debido a una instrucción EXECUTE AS USER o una cláusula EXECUTE AS en un módulo de ámbito de base de datos. En estos casos, se comprueban los permisos de suplantación dentro del ámbito de la base de datos. El valor predeterminado de los permisos IMPERSONATE en los usuarios es la propia base de datos, cuyo propietario es dbo. Asimismo, el autenticador de estas suplantaciones es el propietario de la base de datos. Además, es el propietario de la base de datos quien establece de manera efectiva la identidad del usuario suplantado y certifica su autenticidad. Puesto que el propietario de la base de datos es el propietario de la base de datos completa, el contexto suplantado se considera auténtico en toda esa base de datos. Sin embargo, fuera de esa base de datos, el contexto suplantado no es válido.

Cómo se utilizan los autenticadores

Los autenticadores se utilizan para determinar si un contexto establecido es válido en un determinado ámbito. A menudo, el autenticador es el administrador del sistema (SA) o la instancia de SQL Server o, en el caso de bases de datos, dbo. El autenticador es efectivamente el propietario del ámbito en el que se establece el contexto para un determinado usuario o inicio de sesión. Esta información del autenticador se captura en la información del token que se mantiene para el inicio de sesión y el usuario y está visible a través de las vistas sys.user_token y sys.login_token. Para obtener más información, vea Descripción del contexto de ejecución.

[!NOTA]

Si en la vista del token no se devuelve información acerca del autenticador, significa que el autenticador es la instancia de SQL Server. Esto es cierto si no se produce un cambio de contexto o si la suplantación se realiza en el servidor.

Un contexto de ejecución cuyo propietario de un ámbito es el autenticador será válido en ese ámbito. Esto se debe a que el propietario de un ámbito, por ejemplo, una base de datos, tiene implícitamente la confianza de todas las entidades del ámbito. El contexto también es válido en otros ámbitos, por ejemplo, otras bases de datos o la instancia de SQL Server, en la que el autenticador goza de confianza. Por lo tanto, la validez del contexto del usuario suplantado fuera del ámbito de la base de datos depende de si el autenticador del contexto es de confianza en el ámbito de destino. Esta confianza se establece concediendo al autenticador el permiso AUTHENTICATE si el ámbito de destino es otra base de datos, o el permiso AUTHENTICATE SERVER si el ámbito de destino es una instancia de SQL Server.

Extender el ámbito de una suplantación

Para extender el ámbito de una suplantación de una base de datos a un ámbito de destino, como otra base de datos o la instancia de SQL Server, deben cumplirse las siguientes condiciones.

El autenticador debe ser de confianza en el ámbito de destino.
La base de datos de origen debe marcarse como de confianza.

Confiar en el autenticador

Basándose en los ejemplos de bases de datos Sales y Marketing anteriores, la siguiente ilustración muestra el procedimiento almacenado GetSalesProjections en la base de datos Marketing obteniendo acceso a los datos de la tabla SalesStats en la base de datos Sales. El procedimiento almacenado contiene la cláusula EXECUTE AS USER MarketingExec. El propietario de la base de datos Sales es SalesDBO y el propietario de la base de datos Marketing es MarketingDBO.

EXECUTE AS cambia el contexto de ejecución de un módulo

Cuando un usuario invoca el procedimiento almacenado GetSalesProjections, la cláusula EXECUTE AS cambia explícitamente el contexto de ejecución del procedimiento almacenado del usuario que llama al usuario MarketingExec. El autenticador de este contexto es MarketingDBO, el propietario de la base de datos Marketing. De forma predeterminada, este procedimiento puede obtener acceso a cualquier recurso de la base de datos Marketing a la que el usuario MarketingExec tiene permitido el acceso. Sin embargo, para tener acceso a una tabla de la base de datos Sales, la base de datos Sales debe confiar en el autenticador MarketingDBO.

Esto se consigue creando un usuario en la base de datos Sales denominado MarketingDBO que se asigne al inicio de sesión de MarketingDBO y, a continuación, concediendo a ese usuario permiso AUTHENTICATE en la base de datos Sales. Como resultado, cualquier contexto de ejecución cuyo receptor del permiso es su autenticador será válido en la base de datos. Puesto que al autenticador MarketingDBO se le concede el permiso AUTHENTICATE en la base de datos Sales, el contexto del usuario MarketingExec establecido por la cláusula EXECUTE AS en el procedimiento almacenado GetSalesProjections de la base de datos Marketing es de confianza en la base de datos Sales.

Si bien este ejemplo demuestra cómo extender el ámbito de la suplantación para permitir el acceso a un objeto de una base de datos externa, también es posible extender el ámbito de la suplantación a la instancia de SQL Server. Por ejemplo, si debe crear un inicio de sesión, que es una acción de servidor que requiere un permiso válido para todo el servidor, el permiso AUTHENTICATE SERVER deberá concederse al autenticador del contexto. Esto requiere una semántica en la que todo contexto que tiene el receptor del permiso AUTHENTICATE SERVER como su autenticador sea de confianza en toda la instancia de SQL Server**,** como si el contexto iniciara directamente la sesión a la instancia de SQL Server.

Confiar en la base de datos

En SQL Server, el modelo de confianza va un paso más allá para proporcionar seguridad y granularidad adicionales a la extensión del ámbito de la suplantación en la base de datos. Puede utilizar el permiso AUTHENTICATE como una forma para que el ámbito de destino confíe en el autenticador del contexto, pero también puede determinar si la instancia de SQL Server confía en la base de datos de origen y en su contenido.

Para ilustrar este ejemplo, supongamos que la entidad de seguridad de MarketingDBO es propietaria de otra base de datos denominada Conference. Supongamos asimismo que MarketingDBO desea que los contextos de ejecución especificados dentro de la base de datos de Marketing tengan acceso a los recursos de la base de datos Sales. Sin embargo, no desea que ningún contexto establecido en la base de datos Conference tenga acceso a la base de datos Sales.

Para lograr este requisito, la base de datos que contiene el módulo en el que se utiliza un contexto de suplantación para obtener acceso a los recursos fuera de la base de datos debe marcarse como confiable. La propiedad TRUSTWORTHY indica si la instancia de SQL Server confía en la base de datos y en su contenido. La propiedad TRUSTWORTHY cumple dos objetivos:

Reduce las amenazas procedentes de las bases de datos conectadas a la instancia de SQL Server y que potencialmente pueden contener módulos malintencionados que se ejecuten bajo el contexto de un usuario con mayores privilegios.

Esto se consigue asegurándose de que las bases de datos conectadas no se han marcado como confiables de forma predeterminada. También se puede lograr asegurándose de que el acceso a los recursos que están fuera de la base de datos a través de módulos potencialmente malintencionados implica que la base de datos debe marcarse como confiable. El establecimiento de la propiedad TRUSTWORTHY en una base de datos está restringido a los miembros de la función fija de servidor sysadmin.
Permite al administrador de una instancia de SQL Server distinguir entre las bases de datos a las que se debería conceder acceso a los recursos externos y a los que no cuando la base de datos tiene el mismo propietario, y dicho propietario es un autenticador de confianza en el mismo ámbito.

Este comportamiento puede controlarse mediante la propiedad TRUSTWORTHY. Por ejemplo, supongamos un escenario en el que los contextos suplantados de una base de datos, Database1, deberían ser de confianza mientras que los contextos de otra base de datos, Database 2, no deberían ser de confianza y ambas comparten el mismo propietario que es de confianza como autenticador en el ámbito de destino. La propiedad TRUSTWORTHY puede establecerse en ON para database1 y en OFF para database2 con el fin de asegurarse de que los módulos en Database 2 no pueden obtener acceso a los recursos situados fuera de esa base de datos.

La siguiente ilustración muestra el uso de la propiedad de base de datos TRUSTWORTHY para controlar el acceso a los recursos ubicados fuera del ámbito de la base de datos de origen. A MarketingDBO se le conceden permisos AUTHENTICATE en la base de datos Sales y es propietario de las bases de datos Marketing y Conference. El procedimiento almacenado GetSalesProjections de la base de datos Marketing puede tener acceso a la base de datos Sales correctamente porque cumple los dos requisitos de seguridad: el autenticador, MarketingDBO, es de confianza en el ámbito de destino y la base de datos de origen, Marketing, es de confianza. Los intentos de acceso a la base de datos Sales desde la base de datos Conference son denegados porque sólo se cumple un requisito: el autenticador, MarketingDBO, es de confianza en el ámbito de destino.

Controlar el acceso de base de datos a recursos externos

Siempre que se realiza un intento de obtener acceso a un recurso fuera del ámbito de la base de datos mediante un contexto suplantado, la instancia de SQL Server comprueba que la base de datos desde donde se originó la solicitud es de confianza y que el autenticador es confiable.

Certificados y claves asimétricas como autenticadores

Un contexto de suplantación establecido en una base de datos puede extenderse para obtener acceso a los recursos situados fuera del ámbito de la base de datos utilizando el propietario de la base de datos como un autenticador. A tal efecto, es necesario que el propietario de la base de datos sea de confianza para el recurso externo y que la propia base de datos también lo sea. Sin embargo, este enfoque implica que cuando a un propietario de una base de datos de confianza se le conceden los permisos AUTHENTICATE o AUTHENTICATE SERVER en el ámbito de destino y la base de datos de llamada es de confianza, cualquier contexto suplantado que se haya establecido en esa base de datos será válido en todo el ámbito de destino que confía en el propietario de la base de datos.

Es posible que se necesite un nivel de confianza más granular. Supongamos que el requisito empresarial indica que sólo se debe confiar en unos pocos módulos de la base de datos de origen mediante la cláusula EXECUTE AS para tener acceso al recurso de destino, pero no en toda la base de datos de origen. Por ejemplo, imaginemos que SalesDBO desea asegurarse de que únicamente el procedimiento almacenado GetSalesProjections puede obtener acceso a la tabla SalesStats como el usuario MarketingExec, pero no desea que todos los usuarios de la base de datos Marketing con permisos de suplantación en MarketingExec puedan obtener acceso a los recursos en la base de datos Sales. La confianza en MarketingDBO y el establecimiento de la base de datos Marketing como confiable no serán suficientes para realizar esta tarea. Para proporcionar un nivel de granularidad adicional con el fin de cumplir este requisito, el modelo de confianza permite utilizar los certificados o las claves asimétricas como autenticadores. Para ello se utiliza una técnica denominada firma. Para obtener más información acerca de la firma, vea ADD SIGNATURE (Transact-SQL).

Utilizar firmas

Las firmas de un módulo comprueban que solamente la persona con acceso a la clave privada que se utiliza para firmar el módulo pueda modificar el código de un módulo. Teniendo en cuenta las garantías del proceso de firma, puede confiar en el certificado o la clave asimétrica especificada en la firma. Más concretamente, puede confiar en el propietario del certificado o clave asimétrica en lugar de solamente el propietario de la base de datos.

La confianza en un módulo firmado se consigue concediendo permiso AUTHENTICATE o AUTHENTICATE SERVER al usuario en el ámbito de salida que está asignado al certificado o clave asimétrica.

De este modo, se establece un contexto de ejecución dentro de un módulo firmado mediante un certificado de confianza válido en el ámbito de destino en el que se confía en el certificado.

Por ejemplo, supongamos que el procedimiento GetSalesProjections se firma utilizando un certificado denominado C1. El certificado C1 debe estar presente en la base de datos Sales y un usuario, por ejemplo, CertUser1, debe estar asignado al certificado C1. A CertUser1 se le conceden permisos AUTHENTICATE en la base de datos Sales.

Cuando el procedimiento se invoca, se comprueba su firma para asegurarse de que no se alteró cuando fue firmada. Si la firma se comprueba, el contexto establecido por la cláusula EXECUTE AS en el módulo tiene el certificado C1 como su autenticador. Si la firma no se comprueba, el autenticador no se agrega al token y el intento de acceso al recurso externo no prospera.

La siguiente ilustración muestra cómo se utiliza un módulo firmado para controlar el acceso a los recursos ubicados fuera del ámbito de la base de datos de origen. El procedimiento GetSalesProjections en la base de datos Marketing se firma mediante un certificado denominado C1. El certificado C1 está presente en la base de datos Sales y el usuario CertUser se asigna al certificado. A CertUser1 se le conceden permisos AUTHENTICATE en la base de datos Sales.

Certificado usado para restringir el acceso a la base de datos

La confianza en este autenticador se comprueba de la misma manera que se verifica la confianza cuando el propietario de la base de datos es el autenticador. Es decir, se verifica comprobando el permiso AUTHENTICATE SERVER o AUTHENTICATE. Sin embargo, puesto que la confianza se establece en un nivel granular y el módulo no puede cambiarse sin modificar la firma, no hay ninguna necesidad de comprobar la propiedad TRUSTWORTHY en la base de datos.

Esto limita la amenaza que suponen las bases de datos conectadas que contienen código malintencionado. Un atacante debería firmar el módulo con la clave privada correspondiente al certificado que ya es confiable. Sin embargo, el atacante no tiene acceso a esta clave. Asimismo, si se modifica un módulo de confianza existente o se crea uno nuevo, el módulo no tendrá una firma de confianza válida.

Para obtener más información, vea Firma de módulos (Motor de base de datos).

Reglas para extender el ámbito de suplantación de la base de datos

En resumen, el ámbito de suplantación de un contexto establecido dentro de una base de datos puede extenderse a otros ámbitos únicamente si la siguiente condición es cierta:

El autenticador, ya sea el propietario de la base de datos o un certificado o clave asimétrica utilizados para firmar el módulo, debe ser confiable en el ámbito de destino. Para realizar esto, debe conceder permisos AUTHENTICATE o AUTHENTICATE SERVER a la entidad de seguridad que se asigna al propietario de la base de datos, el certificado o la clave asimétrica.
Si el autenticador es el propietario de la base de datos, la base de datos de origen debe marcarse como de confianza. Para hacer esto, debe establecer la propiedad TRUSTWORTHY en ON para la base de datos.

Seleccionar un mecanismo de confianza según sus necesidades

Tanto el método que utiliza el propietario de la base de datos como el método que utiliza la firma presentan ventajas e inconvenientes. El mejor mecanismo para sus necesidades depende de los requisitos y el entorno de su empresa.

Método del propietario de base de datos

Este método para establecer la confianza presenta las siguientes ventajas y desventajas:

No requiere conocimientos sobre conceptos criptográficos, como puedan ser certificados o firmas.
No ofrece tanta granularidad como el método que utiliza las firmas.
La conexión de una base de datos a una instancia de SQL Server establece la propiedad TRUSTWORTHY de la base de datos en OFF. Los módulos de confianza para el propietario de la base de datos no serán válidos hasta que el administrador del sistema establezca explícitamente la propiedad TRUSTWORTHY en ON. Esto implica que se requiere alguna intervención por parte del administrador del sistema para que la base de datos conectada pueda funcionar como usted desea y obtener acceso a otras bases de datos.

Método mediante el uso de firmas