SEGURIDAD Y PROTECCION DE

UN MOTOR DE BASE DE DATOS

Motor de base de datos de SQL

Server
SQL Server 2008

El siguiente aporte se construy con la finalidad de ayudar a todas las

personas que deseen aprender SEGURIDAD Y PROTECCION DE UN MOTOR DE
BASE DE DATOS en SQL ya que no encontr navegando algo que me
convenciera espero que les ayude si hay sugerencias escribirme que no
tengo duda de poder resolverlo.
Se tratara

los siguientes puntos:

Seguridad
Amenazas
Vulnerabilidad
Identidad y control de acceso
Implementacin segura

El Motor de base de datos es el servicio principal para almacenar, procesar y

proteger datos. El Motor de base de datos proporciona acceso controlado y
procesamiento de transacciones rpido para cumplir con los requisitos de las
aplicaciones consumidoras de datos ms exigentes de su empresa.
Use Motor de base de datos para crear bases de datos relacionales para el
procesamiento de transacciones en lnea o datos de procesamiento analtico en

lnea. Esto incluye la creacin de tablas para almacenar datos y objetos de

base de datos (p.ej., ndices, vistas y procedimientos almacenados) para ver,
administrar y proteger datos. Puede usar SQL Server Management Studio para
administrar los objetos de bases de datos y SQL Server Profiler para capturar
eventos de servidor.

Informacin general sobre seguridad

3.- Mitigacin de amenazas y

vulnerabilidades (motor de base de datos)
Aunque SQL Server incluye varios mecanismos de seguridad, todo sistema tiene
caractersticas que se podran aprovechar con fines malintencionados. Esta pgina contiene
vnculos que le ayudarn a encontrar la informacin que necesita en relacin con las
amenazas y vulnerabilidades en SQL Server Database Engine (Motor de base de datos de
SQL Server) y cmo puede eliminarlas.

Matriz de amenazas y vulnerabilidad (motor de base de

datos)
Aunque SQL Server incluye varios mecanismos de seguridad, todo sistema tiene
caractersticas que se podran aprovechar con fines malintencionados. Cualquier
caracterstica que exponga datos u otra informacin puede constituir un riesgo si se
implementa incorrectamente.
Aunque cualquier caracterstica podra representar un riesgo, no todos los riesgos son
iguales. Algunos requieren un cambio de procedimiento, otros de configuracin y algunos
de cdigo. En las tablas siguientes se explican los riesgos y los pasos proactivos que se
pueden dar para disminuirlos.
Amenazas y vulnerabilidades de los procesos

Amenaza o
Definicin
vulnerabilidad

Mitigacin

Directivas de
seguridad

Una directiva de seguridad es un

registro de los procesos y
procedimientos que debe seguir una
organizacin para evitar, realizar un
seguimiento y responder a las
amenazas de seguridad. Contiene
directivas relacionadas con el acceso
adecuado a los sistemas, la
aplicacin de revisiones y los
firewalls, as como mecanismos de
prevencin antivirus.

Cree, revise, distribuya y mantenga

una directiva de seguridad efectiva.
Para obtener ms informacin
acerca de cmo crear una directiva
de seguridad, vea Proteger SQL
Server.

Principio de
"privilegios
mnimos"

Segn el principio de "privilegios

mnimos", un sistema slo debera
permitir el nivel de acceso necesario
a un objeto protegible. Adems, el
acceso slo debera estar habilitado
para quienes tienen una necesidad
directa y slo durante un tiempo
especificado. Las aplicaciones
pueden estar codificadas para
proporcionar ms acceso del
necesario y las cuentas podran tener
demasiado acceso.

Revise e implemente la seguridad

de acuerdo con el principio de
privilegios mnimos. Para obtener
ms informacin sobre cmo
desarrollar aplicaciones que utilizan
los conceptos de privilegios
mnimos, vea el tema relativo a
procedimientos recomendados en
un entorno con privilegios mnimos
en MSDN.

Boletines de
seguridad

Microsoft publica informacin de

seguridad tan pronto como se
comprueba y se prueba en distintas
plataformas. Las organizaciones que
no estn al corriente de estos
boletines ponen en peligro sus
sistemas al no implementar las
instrucciones de seguridad
adecuadas.

Revise y haga un seguimiento de

los boletines de seguridad de SQL
Server. Para obtener ms
informacin, vea la bsqueda de
boletines de seguridad de Microsoft
en TechNet.

Amenazas y vulnerabilidades de la plataforma

Amenaza o
vulnerabilidad

Definicin

Microsoft publica
actualizaciones de software
El sistema no est
para mejorar la seguridad de
actualizado (no se han
SQL Server. Si no se siguen
aplicado las
o se aplican estas
actualizaciones de
actualizaciones de software,
software)
el sistema ser ms
vulnerable a los ataques.

Vulnerabilidades de
seguridad de los
puertos de red

Configuracin
incorrecta de las
cuentas de servicio

Mitigacin

Revise y aplique todos los Service

Packs y todas las revisiones en cuanto
estn disponibles. Para obtener ms
informacin, consulte la pgina de
descargas en SQL Server TechCenter.

Utilice un firewall en el servidor si est

expuesto a Internet y utilice la
herramienta Administrador de
configuracin de SQL Server para
establecer la configuracin de la red.
Considere tambin la posibilidad de
utilizar SSL (Capa de sockets seguros)
La red es la principal va de para aumentar an ms la seguridad.
acceso para los ataques
Para obtener ms informacin acerca
contra SQL Server. Si los
de los firewalls y SQL Server, vea
puertos estndar estn
Cmo configurar Firewall de Windows
abiertos a Internet, se
para el acceso al motor de base de
favorecern los ataques.
datos. Para obtener ms informacin
acerca de cmo cambiar la
configuracin de la red, vea
Administrador de configuracin de
SQL Server. Para obtener ms
informacin acerca de cmo utilizar
SSL en SQL Server, vea Cifrar
conexiones a SQL Server.

Las cuentas de servicio de Las cuentas de servicio de SQL Server

SQL Server suelen tener
deberan funcionar bajo el principio de
ms acceso a la plataforma o privilegios mnimos y deberan tener
a la red del que necesitan. contraseas seguras. Para obtener ms
informacin acerca de las cuentas de
servicio, vea Configurar cuentas de
servicio de Windows. Para obtener ms

informacin acerca de las contraseas,

vea Contraseas seguras.

rea expuesta
demasiado grande

Use el Administrador de configuracin

de SQL Server y la Administracin
Las caractersticas y
basada en directiva para controlar las
capacidades de SQL Server
caractersticas y los dems
pueden estar expuestas
componentes. Para obtener ms
cuando no es necesario.
informacin, vea Descripcin de la
configuracin del rea expuesta.

Procedimientos
almacenados
innecesarios
habilitados

Algunos procedimientos
almacenados extendidos
permiten el acceso al
sistema operativo o al
registro.

No habilite los procedimientos

almacenados que permiten el acceso al
sistema operativo o al registro si no es
completamente necesario. Para obtener
ms informacin, vea Descripcin de
la configuracin del rea expuesta.

Amenazas y vulnerabilidades de autenticacin

Amenaza o
Definicin
vulnerabilidad

Mitigacin

Utilice siempre contraseas seguras y

complejas. Para obtener ms informacin,
Las contraseas sencillas
vea Contraseas seguras. Tambin vea las
Contraseas no estn expuestas a los ataques
opciones CHECK_POLICY y
seguras
por fuerza bruta o de
CHECK_EXPIRATION en las instrucciones
diccionario.
CREATE LOGIN (Transact-SQL) y ALTER
LOGIN (Transact-SQL).

Cuentas de
usuario sin
auditar

Los usuarios (entidades de Las cuentas de usuario se deberan auditar

seguridad) a menudo
con frecuencia para asegurarse de que se
cambian de puesto o dejan la tiene habilitado el acceso adecuado a los
organizacin. Si no se
servidores y los objetos de las bases de
cambia el acceso a una
datos. Para obtener ms informacin acerca

cuenta de usuario, se puede

seguir teniendo acceso al
de cmo auditar el acceso a SQL Server, vea
sistema con el nivel de
Supervisar los registros de errores.
permisos anterior.

Amenazas y vulnerabilidades de programacin

Amenaza o
vulnerabilidad

Definicin

Inyeccin de
cdigo SQL

Para obtener ms informacin acerca de

Consiste en incrustar una
cmo actuar ante los ataques por inyeccin
consulta malintencionada en
de cdigo SQL, vea Inyeccin de cdigo
una legtima.
SQL.

Contraseas
incrustadas

No guarde las contraseas ni la

Algunas aplicaciones
informacin confidencial de conexin en
guardan las cadenas de
un programa, en el registro ni en un
conexin en el programa o en archivo de configuracin. Para obtener
archivos de configuracin. ms informacin, vea Directiva de
contraseas.

Mitigacin

Amenazas y vulnerabilidades de acceso a los datos

Amenaza o
vulnerabilidad

Definicin

Mitigacin

El cifrado ofusca los datos o la

informacin de conexin en SQL Conozca e implemente correctamente
Cifrado aplicado Server. No cifrar los datos cuando el cifrado en SQL Server. Para
incorrectamente es necesario o hacerlo cuando no obtener ms informacin, vea Cifrado
lo es, supone un riesgo y una
de SQL Server.
complejidad innecesarios.

Certificados
aplicados
incorrectamente

Los certificados son un

mecanismo para comprobar la
autenticacin. SQL Server puede
utilizar los certificados para
diversos propsitos, desde las
conexiones a los datos. El uso
inadecuado de los certificados
autofirmados y los perodos de
validacin extendidos reducen la
eficacia de la seguridad global.

Conozca e implemente correctamente

los certificados de SQL Server. Para
obtener ms informacin, vea
Certificados y claves asimtricas de
SQL Server.

Se deberan hacer copias de seguridad

de las claves del servidor (tambin
Una instancia de SQL Server y conocidas como claves maestras de
las bases de datos que contiene servicio) y de las claves de las bases
Claves de SQL
pueden tener claves que se
de datos, y guardarlas en lugar
Server sin copias
utilizan para distintos propsitos seguro. Tambin se deberan cambiar
de seguridad
de seguridad. Esto incluye el
peridicamente. Para obtener ms
cifrado.
informacin, vea SQL Server y claves
de cifrado de base de datos (motor de
base de datos).

Inyeccin de cdigo SQL

La inyeccin de cdigo SQL es un ataque en el cual se inserta cdigo malicioso en las
cadenas que posteriormente se pasan a una instancia de SQL Server para su anlisis y
ejecucin. Todos los procedimientos que generan instrucciones SQL deben revisarse en
busca de vulnerabilidades de inyeccin de cdigo, ya que SQL Server ejecutar todas las
consultas recibidas que sean vlidas desde el punto de vista sintctico. Un atacante
cualificado y con determinacin puede manipular incluso os datos con parmetros.
La forma principal de inyeccin de cdigo SQL consiste en la insercin directa de cdigo
en variables especificadas por el usuario que se concatenan con comandos SQL y se

ejecutan. Existe un ataque menos directo que inyecta cdigo daino en cadenas que estn
destinadas a almacenarse en una tabla o como metadatos. Cuando las cadenas almacenadas
se concatenan posteriormente en un comando SQL dinmico, se ejecuta el cdigo daino.
El proceso de inyeccin consiste en finalizar prematuramente una cadena de texto y anexar
un nuevo comando. Como el comando insertado puede contener cadenas adicionales que se
hayan anexado al mismo antes de su ejecucin, el atacante pone fin a la cadena inyectada
con una marca de comentario "--". El texto situado a continuacin se omite en tiempo de
ejecucin.
En el siguiente script se muestra una sencilla inyeccin de cdigo SQL. El script crea una
consulta SQL concatenando cadenas no modificables con una cadena especificada por el
usuario:
var Shipcity;
ShipCity = Request.form ("ShipCity");
var sql = "select * from OrdersTable where ShipCity = '" + ShipCity +
"'";

Se le pide al usuario que escriba el nombre de una ciudad. Si el usuario especifica

Redmond, la consulta ensamblada por el script presenta un aspecto similar al siguiente:
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond'
Sin embargo, suponga que el usuario especificase lo siguiente:
Redmond'; drop table OrdersTable-En este caso, la siguiente consulta la ensambla el script:
SELECT * FROM OrdersTable WHERE ShipCity = 'Redmond';drop table OrdersTable--'
El punto y coma (;) denota el final de una consulta y el principio de otra. El guin doble (--)
indica que el resto de la lnea actual es un comentario y debe omitirse. Si el cdigo
modificado es sintcticamente correcto, el servidor lo ejecutar. Cuando SQL Server
procese esta instruccin, SQL Server seleccionar en primer lugar todos los registros de
OrdersTable donde ShipCity sea Redmond. A continuacin, SQL Server quitar
OrdersTable.
Siempre y cuando el cdigo SQL inyectado sea sintcticamente correcto, no ser posible
detectar alteraciones mediante programacin. Por ello, debe validar todos los datos
especificados por el usuario y revisar cuidadosamente el cdigo que ejecute comandos SQL
construidos en el servidor que utilice. Las prcticas recomendadas de codificacin se
describen en las siguientes secciones de este tema.

4.- Identidad y control de acceso (motor de

base de datos)
SQL Server incluye varios mtodos y herramientas que permiten
configurar la seguridad para que los usuarios, los servicios y las otras
cuentas puedan tener acceso al sistema. Esta pgina contiene vnculos
que le ayudarn a encontrar la informacin que necesita para trabajar
con entidades de seguridad (usuarios y cuentas de inicio de sesin),
funciones (grupos de entidades de seguridad), objetos que pueden
protegerse (protegibles) y permisos.

Entidades de seguridad (motor de base de

datos)
Las entidades de seguridad son entidades que pueden solicitar recursos
de SQL Server. Igual que otros componentes del modelo de autorizacin
de SQL Server, las entidades de seguridad se pueden organizar en
jerarquas. El mbito de influencia de una entidad de seguridad depende
del mbito de su definicin: Windows, servidor o base de datos; y de si
la entidad de seguridad es indivisible o es una coleccin. Un Inicio de
sesin de Windows es un ejemplo de entidad de seguridad indivisible y
un Grupo de Windows es un ejemplo de una del tipo coleccin. Toda
entidad de seguridad tiene un identificador de seguridad (SID).
Entidades de seguridad a nivel de Windows

Inicio de sesin del dominio de Windows

Inicio de sesin local de Windows

Entidad de seguridad deSQL Server

Inicio de sesin de SQL Server

Entidades de seguridad a nivel de bases de datos

Usuario de base de datos

Funcin de base de datos

Funcin de aplicacin

Inicio de sesin sa de SQL Server

El inicio de sesin sa de SQL Server es una entidad de seguridad del

servidor. Se crea de forma predeterminada cuando se instala una
instancia. En SQL Server 2005 y SQL Server 2008, la base de datos
predeterminada de sa es master. Es un cambio de comportamiento con
respecto a versiones anteriores de SQL Server.
Funcin public de base de datos

Todos los usuarios de una base de datos pertenecen a la funcin public

de la base de datos. Cuando a un usuario no se le han concedido ni
denegado permisos de un elemento que puede protegerse, el usuario
hereda los permisos de ese elemento concedidos a public.
INFORMATION_SCHEMA y sys

Todas las bases de datos incluyen dos entidades que aparecen como
usuarios en las vistas de catlogo: INFORMATION_SCHEMA y sys. SQL
Server necesita estas dos entidades. No son entidades de seguridad y no
se pueden modificar ni quitar.
Inicios de sesin de SQL Server basados en certificados

Las entidades de seguridad de servidor con nombres incluidos entre signos de nmero
dobles (##) son exclusivamente para uso interno del sistema. Las siguientes entidades de

seguridad se crean a partir de certificados cuando se instala SQL Server y no deben

eliminarse.

##MS_SQLResourceSigningCertificate##
##MS_SQLReplicationSigningCertificate##
##MS_SQLAuthenticatorCertificate##
##MS_AgentSigningCertificate##
##MS_PolicyEventProcessingLogin##
##MS_PolicySigningCertificate##
##MS_PolicyTsqlExecutionLogin##

Cliente y servidor de base de datos

Por definicin, un cliente y un servidor de base de datos son entidades de seguridad y se

pueden proteger. Estas entidades se pueden autenticar mutuamente antes de establecer una
conexin de red segura. SQL Server admite el protocolo de autenticacin Kerberos, que
define cmo interactan los clientes con un servicio de autenticacin de red.
Para obtener ms informacin acerca de la implementacin en SQL Server de la
compatibilidad con Kerberos, vea Autenticacin Kerberos y SQL Server.

Funciones de nivel de servidor

Para administrar con facilidad los permisos en el servidor, SQL Server proporciona varias
funciones, que son entidades de seguridad que agrupan a otras entidades de seguridad. Las
funciones son como los grupos del sistema operativo Microsoft Windows.
Las funciones fijas de servidor se proporcionan por comodidad y por motivos de
compatibilidad con versiones anteriores. Se recomienda asignar permisos ms concretos
siempre que sea posible.
Las funciones de nivel de servidor tambin se denominan funciones fijas de servidor
porque no se pueden crear nuevas funciones de nivel de servidor. Las funciones de nivel de
servidor se aplican a todo el servidor en lo que respecta a su mbito de permisos.
Puede agregar inicios de sesin de SQL Server, cuentas de Windows y grupos de Windows
a las funciones de nivel de servidor. Cada miembro de una funcin fija de servidor puede
agregar otros inicios de sesin a esa misma funcin.

En la tabla siguiente se muestran las funciones de nivel de servidor y sus capacidades.

Nombre de la
Descripcin
funcin de nivel de
servidor

sysadmin

Los miembros de la funcin fija de servidor sysadmin pueden realizar

cualquier actividad en el servidor.

serveradmin

Los miembros de la funcin fija de servidor serveradmin pueden

cambiar las opciones de configuracin en el servidor y cerrar el
servidor.

securityadmin

Los miembros de la funcin fija de servidor securityadmin

administran los inicios de sesin y sus propiedades. Administran los
permisos de servidor GRANT, DENY y REVOKE. Tambin
administran los permisos de base de datos GRANT, DENY y
REVOKE. Asimismo, pueden restablecer contraseas para inicios de
sesin de SQL Server.
Nota de seguridad
La capacidad de conceder acceso al Database Engine (Motor de base
de datos) y configurar permisos de usuario permite a la
administracin de seguridad asignar la mayora de los permisos de
servidor. La funcin securityadmin se debe tratar como equivalente a
la funcin sysadmin.

processadmin

Los miembros de la funcin fija de servidor processadmin pueden

finalizar los procesos que se ejecutan en una instancia de SQL Server.

Setupadmin

Los miembros de la funcin fija de servidor setupadmin pueden

agregar y quitar los servidores vinculados.

Bulkadmin

Los miembros de la funcin fija de servidor bulkadmin pueden

ejecutar la instruccin BULK INSERT.

Diskadmin

La funcin fija de servidor diskadmin se utiliza para administrar

archivos de disco.

Dbcreator

Los miembros de la funcin fija de servidor dbcreator pueden crear,

modificar, quitar y restaurar cualquier base de datos.

public

Cada inicio de sesin de SQL Server pertenece a la funcin de

servidor public. Cuando a una entidad de seguridad de servidor no se
le han concedido ni denegado permisos especficos en un objeto que
puede protegerse, el usuario hereda los permisos concedidos a la
funcin public en ese objeto. Asigne solamente permisos pblicos en
cualquier objeto cuando desee que el objeto est disponible para todos
los usuarios.

Para obtener informacin especfica sobre los permisos de las funciones de nivel de
servidor, vea Permisos de las funciones fijas de servidor (motor de base de datos).
Trabajar con funciones de nivel de servidor
En la tabla siguiente se explican los comandos, las vistas y las funciones que se utilizan
para trabajar con funciones de nivel de servidor.

Caracterstica

Tipo

Descripcin

sp_helpsrvrole (Transact-SQL) Metadatos

Devuelve una lista de funciones de nivel de

servidor.

sp_helpsrvrolemember
(Transact-SQL)

Metadatos

Devuelve informacin acerca de los

miembros de una funcin de nivel de
servidor.

sp_srvrolepermission
(Transact-SQL)

Metadatos

Muestra los permisos de una funcin de nivel

de servidor.

IS_SRVROLEMEMBER
(Transact-SQL)

Metadatos

Indica si un inicio de sesin de SQL Server

es miembro de la funcin de nivel de servidor

especificada.

sys.server_role_members
(Transact-SQL)

Metadatos

Devuelve una fila por cada miembro de cada

funcin de nivel de servidor.

sp_addsrvrolemember
(Transact-SQL)

Comando

Agrega un inicio de sesin como miembro de

una funcin de nivel de servidor.

Comando

Quita un inicio de sesin de SQL Server o un

usuario o grupo de Windows de una funcin
de nivel de servidor.

sp_dropsrvrolemember
(Transact-SQL)

Funciones en el nivel de base de datos

Para administrar con facilidad los permisos en las bases de datos, SQL Server proporciona
varias funciones, que son las entidades de seguridad que agrupan a otras entidades de
seguridad. Son como los grupos del sistema operativo Microsoft Windows. Las funciones
del nivel de base de datos se aplican a toda la base de datos en lo que respecta a su mbito
de permisos.
Existen dos tipos de funciones de nivel de base de datos en SQL Server: las funciones fijas
de base de datos, que estn predefinidas en la base de datos, y las funciones flexibles de
base de datos, que pueden crearse.
Las funciones de base de datos fijas se definen en el nivel de base de datos y existen en
cada una de ellas. Los miembros de las funciones de base de datos db_owner y
db_securityadmin pueden administrar los miembros de las funciones de base de datos
fijas. Sin embargo, slo los miembros de la funcin de base de datos db_owner pueden
agregar miembros a la funcin de base de datos fija db_owner. Hay tambin algunas
funciones fijas de base de datos con fines especiales en la base de datos msdb.

Puede agregar cualquier cuenta de la base de datos y otras funciones de SQL Server a las
funciones del nivel de base de datos. Cada miembro de una funcin de base de datos fija
puede agregar otros inicios de sesin a esa misma funcin.
Importante
No agregue funciones flexibles de la base de datos como miembros de funciones fijas. Esto
podra habilitar un aumento de privilegios no deseado.

En la tabla siguiente se muestran las funciones fijas del nivel de base de datos y sus
capacidades. Estas funciones existen en todas las bases de datos.

Nombre de funcin Descripcin

de nivel de base
de datos
db_owner

Los miembros de la funcin de base de datos fija

db_owner pueden realizar todas las actividades de
configuracin y mantenimiento en la base de datos y
tambin pueden quitar la base de datos.

db_securityadmin

Los miembros de la funcin de base de datos fija

db_securityadmin pueden modificar la pertenencia a
funciones y administrar permisos. Si se agregan entidades
de seguridad a esta funcin, podra habilitarse un aumento
de privilegios no deseado.

db_accessadmin

Los miembros de la funcin de base de datos fija

db_accessadmin pueden agregar o quitar el acceso a la
base de datos para inicios de sesin de Windows, grupos
de Windows e inicios de sesin de SQL Server.

db_backupoperato Los miembros de la funcin de base de datos fija

r
db_backupoperator pueden crear copias de seguridad
de la base de datos.
db_ddladmin

Los miembros de la funcin de base de datos fija

db_ddladmin pueden ejecutar cualquier comando del
lenguaje de definicin de datos (DDL) en una base de
datos.

db_datawriter

Los miembros de la funcin de base de datos fija

db_datawriter pueden agregar, eliminar o cambiar datos
en todas las tablas de usuario.

db_datareader

Los miembros de la funcin de base de datos fija

db_datareader pueden leer todos los datos de todas las
tablas de usuario.

db_denydatawriter Los miembros de la funcin de base de datos fija

db_denydatawriter no pueden agregar, modificar ni
eliminar datos de tablas de usuario de una base de datos.
db_denydatareade Los miembros de la funcin de base de datos fija
r
db_denydatareader no pueden leer datos de las tablas
de usuario dentro de una base de

Funciones de msdb

La base de datos msdb contiene las funciones con fines especiales que se
muestran en la tabla siguiente.
Nombre de funcin de Descripcin
msdb

db_ssisadmin
db_ssisoperator
db_ssisltduser

dc_admin
dc_operator
dc_proxy

Los miembros de estas funciones de base de datos

pueden administrar y utilizar SSIS. Las instancias de
SQL Server que se actualizan desde una versin
anterior podran contener una versin anterior de la
funcin cuya denominacin se realizaba utilizando
Servicios de transformacin de datos (DTS) en lugar
de SSIS. Para obtener ms informacin, vea Usar
funciones de Integration Services.
Los miembros de estas funciones de base de datos
pueden administrar y utilizar el recopilador de datos.
Para obtener ms informacin, vea Seguridad del
recoleccin de datos.

PolicyAdministratorRol Los miembros de la funcin de base de datos

e
db_PolicyAdministratorRole pueden realizar todas
las actividades de mantenimiento y configuracin en
las condiciones y directivas de Administracin basada
en directiva. Para obtener ms informacin, vea
Administrar servidores mediante administracin
basada en directivas.
ServerGroupAdministr Los miembros de estas funciones de la base de datos
atorRole
pueden administrar y utilizar grupos de servidores
registrados. Para obtener ms informacin, vea Crear
ServerGroupReaderRol grupos de servidores.
e

Trabajar con funciones del nivel de base de datos

En la tabla siguiente se explican los comandos, las vistas y las funciones que se
utilizan para trabajar con funciones del nivel de base de datos.
Caracterstica

Tipo

Descripcin

sp_helpdbfixedrole
(Transact-SQL)

Metadat Devuelve la lista de las funciones de base

os
de datos fijas.

sp_dbfixedrolepermission Metadat Muestra los permisos de una funcin de

(Transact-SQL)
os
base de datos fija.
sp_helprole (TransactSQL)

Metadat Devuelve informacin acerca de las

os
funciones de la base de datos actual.

sp_helprolemember
(Transact-SQL)

Devuelve informacin acerca de los

Metadat
miembros de una funcin de base de datos
os
actual.

sys.database_role_memb Metadat Devuelve una fila por cada miembro de

ers (Transact-SQL)
os
cada funcin de base de datos.
IS_MEMBER (TransactSQL)

Indica si el usuario actual es miembro del

Metadat grupo de Microsoft Windows o de la funcin
os
de base de datos de SQL Server
especificados.

CREATE ROLE (TransactSQL)

Comand Crea una nueva funcin de base de datos

o
en la base de datos actual.

ALTER ROLE (TransactSQL)

Comand Cambia el nombre de una funcin de base

o
de datos.

DROP ROLE (TransactSQL)

Comand
Quita una funcin de base de datos.
o

sp_addrole (Transact-SQL)

Comand Crea una nueva funcin de base de datos

o
en la base de datos actual.

sp_droprole (TransactSQL)

Comand Quita una funcin de base de datos de la

o
base de datos actual.

sp_addrolemember
(Transact-SQL)

Agrega un usuario de base de datos, una

funcin de base de datos, un inicio de
Comand
sesin de Windows o un grupo de Windows
o
a una funcin de base de datos en la base
de datos actual.

sp_droprolemember
(Transact-SQL)

Quita una cuenta de seguridad de una

Comand
funcin de SQL Server de la base de datos
o
actual.

Funcin pblica de la base de datos

Todos los usuarios de una base de datos pertenecen a la funcin pblica de la

base de datos. Cuando a un usuario no se le han concedido ni denegado
permisos especficos para un objeto que puede protegerse, el usuario hereda
los permisos concedidos a la funcin pblica para ese objeto.

Credenciales (motor de base de datos)

Una credencial es un registro que contiene la informacin de autenticacin (credenciales)
necesaria para conectarse a un recurso situado fuera de SQL Server. Esta informacin la
utiliza SQL Server internamente. La mayora de las credenciales incluyen un nombre de
usuario y una contrasea de Windows.
La informacin almacenada en una credencial permite al usuario que se ha conectado a
SQL Server mediante la autenticacin de SQL Server obtener acceso a recursos situados
fuera de la instancia del servidor. Cuando el recurso externo es Windows, el usuario se
autentica como el usuario de Windows especificado en la credencial. Se puede asignar una
nica credencial a varios inicios de sesin de SQL Server. Sin embargo, un inicio de sesin
de SQL Server slo se puede asignar a una credencial.
Las credenciales del sistema se crean de forma automtica y se asocian a extremos
especficos. Los nombres de las credenciales del sistema comienzan por dos signos de
nmero (##).

Sintaxis
CREATE CREDENTIAL credential_name WITH IDENTITY = 'identity_name'
[ , SECRET = 'secret' ]
[ FOR CRYPTOGRAPHIC PROVIDER cryptographic_provider_name ]
/*credential_name
Especifica el nombre de la credencial que se va a crear.
credential_name no
puede comenzar por el signo de nmero (#). Las credenciales del
sistema comienzan por ##.
IDENTITY ='identity_name'
Especifica el nombre de la cuenta que se utilizar para conectarse
fuera del servidor.
SECRET ='secret'
Especifica el secreto necesario para la autenticacin de salida. Esta
clusula es opcional.

FOR CRYPTOGRAPHIC PROVIDER cryptographic_provider_name*/

Ejemplos
--En el ejemplo siguiente se crea la credencial denominada AlterEgo.
-- La credencial contiene el usuario de Windows JoelPC y una contrasea.
CREATE CREDENTIAL AlterEgo WITH IDENTITY = 'Mary5',
SECRET = '<EnterStrongPasswordHere>';
GO

--En el ejemplo siguiente se utiliza una cuenta creada previamente

denominada
--User1OnEKM en un mdulo EKM a travs de las herramientas de
administracin
--de EKM, con un tipo de cuenta y una contrasea bsicos. La cuenta
sysadmin
--del servidor crea una credencial que se utiliza para conectar a la
cuenta
--de EKM y la asigna a la cuenta User1 de SQL Server:
CREATE CREDENTIAL CredentialForEKM
WITH IDENTITY='User1OnEKM'
, SECRET='<EnterStrongPasswordHere>'
FOR CRYPTOGRAPHIC PROVIDER MyEKMProvider;
GO
/* Modify the login to assign the cryptographic provider credential */
ALTER LOGIN User1
ADD CREDENTIAL CredentialForEKM;
/* Modify the login to assign a non cryptographic provider credential */
ALTER LOGIN User1
WITH CREDENTIAL = AlterEgo;
GO

ALTER CREDENTIAL (Transact-SQL)

Sintaxis
ALTER CREDENTIAL credential_name WITH IDENTITY = 'identity_name'
[ , SECRET = 'secret' ]
/*Argumentos
credential_name
Especifica el nombre de la credencial que se va a modificar.*/
IDENTITY ='identity_name'

-- Especifica el nombre de la cuenta que se va a usar al conectarse

fuera del servidor.
SECRET ='secret'
-- Especifica el secreto requerido para la autenticacin de salida.
secret es opcional.

Ejemplos
/*A. Cambiar la contrasea de una credencial
En el siguiente ejemplo se cambia el secreto almacenado en una
credencial denominada Saddles. La credencial contiene el inicio
de sesin de Windows RettigB y su contrasea. La nueva contrasea
se agrega a la credencial mediante la clusula SECRET.*/
ALTER CREDENTIAL Saddles WITH IDENTITY = 'RettigB',
SECRET = 'sdrlk8$40-dksli87nNN8';
GO
/*B. Quitar la contrasea de una credencial
En el ejemplo siguiente se quita la contrasea de una credencial
denominada Frames. La credencial contiene el inicio de sesin de
Windows Aboulrus8 y una contrasea. Despus de ejecutar la instruccin,
la credencial tendr una contrasea NULL porque no se especifica la
opcin
SECRET.*/
ALTER CREDENTIAL Frames WITH IDENTITY = 'Aboulrus8';
GO

DROP CREDENTIAL (Transact-SQL)

Sintaxis

DROP CREDENTIAL credential_name

/*Argumentos
credential_name
Se trata del nombre de la credencial que se va a quitar del
servidor.*/

Ejemplos
--En el ejemplo siguiente se quita la credencial denominada Saddles.
DROP CREDENTIAL Saddles;
GO

Asegurables

Los asegurables son los recursos cuyo acceso es regulado por el sistema de autorizacin del
SQL Server Database Engine (Motor de base de datos de SQL Server). Algunos asegurables
pueden estar incluidos en otros, con lo que se crean jerarquas anidadas denominadas
"mbitos" que a su vez se pueden asegurar. Los mbitos asegurables son servidor, base de
datos y esquema.
Servidor

Incluye los asegurables siguientes:

Extremo

Inicio de sesin

Base de datos

mbito de Securable: Base de datos

Incluye los asegurables siguientes:

Usuario

Funcin

Funcin de aplicacin

Ensamblado

Tipo del mensaje

Ruta

Servicio

Enlace de servicio remoto

Catlogo de texto

Certificado

Clave asimtrica

Clave simtrica

Contrato

Esquema

mbito de Securable: Esquema

Incluye los asegurables siguientes:

Tipo

Coleccin de esquemas XML

Objeto

Objetos

Los elementos siguientes son miembros de la clase de objeto:

Agregado

Restriccin

Funcin

Procedimiento

Cola

Estadstica

Sinnimo

Tabla

Vista

Esquemas (motor de base de datos)

Un esquema es un contenedor que contiene tablas, vistas, procedimientos, etc. Se
encuentra dentro de una base de datos, que a su vez est dentro de un servidor. Estas
entidades se acomodan como cajas anidadas. El servidor es la caja ms externa y el
esquema la ms interna. Contiene todos los asegurables que se mencionan a
continuacin. Pero no puede contener otra caja.

Asegurable que debe estar dentro de un esquema

Clase

Tipo

TYPE

Coleccin de esquemas XML

XML SCHEMA COLLECTION

Tabla

OBJECT

Vista

OBJECT

Procedimiento

OBJECT

Funcin

OBJECT

Agregado

OBJECT

Restriccin

OBJECT

Sinnimo

OBJECT

Cola

OBJECT

Estadstica

OBJECT

Todos los asegurables de un esquema especfico deben tener un nombre exclusivo. El

nombre completo de un asegurable contenido por un esquema incluye el nombre del
esquema que lo contiene. Por lo tanto, un esquema es tambin un espacio de nombres.
Proteger archivos de datos y de registro

El SQL Server establece los permisos de acceso a archivos en los archivos de datos fsicos
y de registro de cada base de datos en cuentas especficas. Estos permisos impiden que se
alteren los archivos si se encuentran en un directorio con permisos abiertos. Por ejemplo, si
no se han establecido los permisos y para los permisos del sistema operativo en el
directorio de la base de datos se ha seleccionado Control total para todos, cualquier cuenta
que tenga acceso a ese directorio podr eliminar o modificar los archivos de la base de
datos aunque no tenga permisos de SQL Server para modificar la base de datos.
Los permisos de acceso a archivos se establecen durante cualquiera de las siguientes
operaciones de base de datos: crear, adjuntar, separar, modificar para agregar un nuevo
archivo, realizar copias de seguridad o restaurar.

Cadenas de propiedad

Cuando varios objetos de base de datos obtienen acceso unos a otros de forma secuencial,
la secuencia se denomina cadena. Aunque estas cadenas no existen de manera
independiente, cuando SQL Server recorre los eslabones de una cadena, SQL Server evala
los permisos de los objetos que la componen de manera distinta a si se estuviese obteniendo
acceso a los objetos por separado. Estas diferencias tienen implicaciones importantes en lo
que se refiere a administrar la seguridad.

Las cadenas de propiedad permiten administrar el acceso a varios objetos, por ejemplo, a
varias tablas, estableciendo permisos en un objeto, como una vista. El encadenamiento de
propiedad tambin ofrece una pequea mejora en el rendimiento en los escenarios que
permiten la omisin de comprobaciones de permisos.
Cmo se comprueban los permisos en una cadena

Cuando se obtiene acceso a un objeto mediante una cadena, SQL Server

primero compara al propietario del objeto con el propietario del objeto de
llamada. Este es el eslabn anterior de la cadena. Si ambos objetos tienen el
mismo propietario, los permisos del objeto de referencia no se evalan.
Ejemplo de encadenamiento de propiedad

En la siguiente ilustracin, la vista July2003 es propiedad de Mary. Ella le ha

concedido a Alex permisos en la vista. l no tiene ningn otro permiso en los
objetos de base de datos de esta instancia. Qu ocurre cuando Alex
selecciona la vista?

Fojura 11111111111111111

1. Alex ejecuta SELECT * en la vista July2003. SQL Server comprueba los

permisos de la vista y confirma que Alex tiene permiso para
seleccionarla.
2. La vista July2003 requiere informacin de la vista SalesXZ. SQL Server
comprueba la propiedad de la vista SalesXZ. Debido a que esta vista
tiene el mismo propietario (Mary) que la vista que la llama, los permisos
de la vista SalesXZ no se comprueban. Se devuelve la informacin
requerida.

3. La vista SalesXZ requiere informacin de la vista InvoicesXZ. SQL

Server comprueba la propiedad de la vista InvoicesXZ. Debido a que
esta vista tiene el mismo propietario que el objeto anterior, los permisos
de la vista InvoicesXZ no se comprueban. Se devuelve la informacin
requerida. Hasta este momento, todos los elementos de la secuencia
tienen un nico propietario (Mary). Esto se denomina cadena de
propiedad continua.
4. La vista InvoicesXZ requiere informacin de la vista AcctAgeXZ. SQL
Server comprueba la propiedad de la vista AcctAgeXZ. Como el
propietario de esta vista es diferente del propietario del objeto anterior
(Sam, y no Mary), se recupera toda la informacin sobre permisos de
esta vista. Si la vista AcctAgeXZ tiene permisos que permiten que Alex
tenga acceso, se devolver informacin.
5. La vista AcctAgeXZ requiere informacin de la tabla ExpenseXZ. SQL
Server comprueba la propiedad de la tabla ExpenseXZ. Como el
propietario de esta tabla es diferente del propietario del objeto anterior
(Joe, y no Sam), se recupera toda la informacin sobre permisos de esta
tabla. Si la tabla ExpenseXZ tiene permisos que permiten que Alex
tenga acceso, se devuelve informacin.
6. Cuando la vista July2003 intenta recuperar informacin de la tabla
ProjectionsXZ, el servidor primero hace comprobaciones para ver si
est habilitado el encadenamiento entre las bases de datos Database 1
y Database 2. Si el encadenamiento entre bases de datos est
habilitado, el servidor comprobar la propiedad de la tabla
ProjectionsXZ. Debido a que esta vista tiene el mismo propietario que
la vista de llamada (Mary), los permisos de esta tabla no se
comprueban. Se devuelve la informacin solicitada

Encadenamiento de propiedad entre bases de datos

SQL Server se puede configurar para permitir el encadenamiento de propiedad entre
bases de datos especficas o entre todas las bases de datos de una nica instancia de
SQL Server. De manera predeterminada, el encadenamiento de propiedad entre
bases de datos est deshabilitado y no se debe habilitar a menos que sea
especficamente necesario.
Posibles amenazas
Las cadenas de propiedad resultan muy tiles a la hora de administrar los permisos de una
base de datos, pero asumen que los propietarios de objetos prevern todas las consecuencias
de las decisiones que tomen para conceder permisos de un elemento protegible. En la

ilustracin anterior, Mary es la propietaria de la mayora de los objetos subyacentes de la

vista July 2003. Debido a que Mary tiene el derecho de hacer que los objetos de los que es
propietaria se encuentren accesibles para otros usuarios, SQL Server asume que, si Mary
concede el acceso a la primera vista de una cadena, ha tomado la decisin consciente de
compartir las vistas y las tablas a las que hace referencia. En la vida real, es posible que
esto no sea una suposicin vlida. Las bases de datos de produccin son mucho ms
complejas que la de la ilustracin, y los permisos que regulan el acceso a las mismas en
muy pocas ocasiones se asignan correctamente a las estructuras administrativas de las
organizaciones que las utilizan.
Es importante comprender que los miembros de funciones de la base de datos con amplios
privilegios pueden utilizar el encadenamiento de propiedad entre bases de datos para
obtener acceso a objetos de bases de datos externas a las suyas. Por ejemplo, si el
encadenamiento de propiedad entre bases de datos se habilita entre la base de datos A y la
B, un miembro de la funcin fija de base de datos db_owner de cualquiera de las dos bases
de datos puede suplantar su identidad y entrar en la otra. El proceso es simple: Diane (un
miembro de db_owner en la base de datos A) crea un usuario Stuart en la base de datos A.
Stuart ya existe como usuario en la base de datos B. A continuacin, Diane crea un objeto
(propiedad de Stuart) en la base de datos A que llama a cualquier objeto propiedad de
Stuart de la base de datos B. Como ambos objetos (el que llama y al que llama) pertenecen
al mismo usuario, los permisos del objeto de la base de datos B no se comprobarn cuando
Diane obtenga acceso a la misma mediante el objeto que ella ha creado.

Permisos (motor de base de datos)

Todos los protegibles de SQL Server tienen permisos asociados que se

pueden conceder a una entidad de seguridad. Este tema proporciona la
siguiente informacin:

Convenciones de nomenclatura de permisos

Permisos relacionados con elementos protegibles especficos

Permisos de SQL Server

Algoritmo de comprobacin de permiso

Resumen del algoritmo de comprobacin de permiso

Comprobar los permisos puede ser complejo. El algoritmo de comprobacin de permiso
incluye la superposicin de la pertenencia a grupos y el encadenamiento de propiedad, tanto
el permiso explcito como el implcito, y puede ser afectado por los permisos en las clases
protegibles y que contienen la entidad que se puede proteger. El proceso general del
algoritmo es reunir todos los permisos pertinentes. Si no se encuentra ningn bloqueo
DENY, el algoritmo busca un permiso GRANT que proporcione el acceso suficiente. El
algoritmo contiene tres elementos esenciales, el contexto de seguridad, el espacio del
permiso y el permiso requerido.

Contexto de seguridad
Es el grupo de entidades de seguridad al que contribuyen los permisos para la
comprobacin de acceso. Son los permisos que estn relacionados con el inicio de
sesin actual o el usuario, a menos que el contexto de seguridad se cambiara a otro
inicio de sesin o usuario utilizando la instruccin EXECUTE AS. El contexto de
seguridad incluye las entidades de seguridad siguientes:
o El inicio de sesin
o El usuario
o Pertenecientes a la funcin
o Pertenecientes al grupo Windows
o Si se utiliza la firma de mdulo, cualquier cuenta de inicio de sesin o de
usuario da cuenta del certificado utilizado para firmar el mdulo que el
usuario est ejecutando actualmente, as como de los pertenecientes a la
funcin asociados de ese entidad de seguridad.

Espacio del permiso

Es la entidad que hay que proteger y todas las clases a proteger que contiene la
entidad a proteger. Por ejemplo, una tabla (una entidad a proteger) est contenida en
la clase de esquema a proteger y en la clase de base de datos a proteger. El acceso
puede verse afectado por permisos de nivel de tabla, esquema, base de datos y
servidor. Para obtener ms informacin, vea Jerarqua de permisos (motor de base
de datos).

Permiso necesario
El tipo de permiso que se necesita. Por ejemplo, INSERT, UPDATE, DELETE,
SELECT, EXECUTE, ALTER, CONTROL, etc.

El acceso puede requerir varios permisos, como en los ejemplos siguientes:

o Un procedimiento almacenado puede requerir el permiso EXECUTE sobre
el procedimiento almacenado y el permiso INSERT sobre varias tablas a las
que hace referencia el procedimiento almacenado.
o Una vista de administracin dinmica puede requerir los permisos VIEW
SERVER STATE y SELECT sobre la vista.

Ejemplos
/*Los siguientes ejemplos muestran cmo recuperar la informacin sobre
permisos.
A. Devolviendo la lista completa de los permisos que pueden concederse.
La instruccin siguiente devuelve todo los permisos de Database Engine
(Motor de base de datos) utilizando la funcin fn_builtin_permissions.
Para obtener ms informacin, vea sys.fn_builtin_permissions (TransactSQL).
*/
SELECT * FROM fn_builtin_permissions(default);
GO
/*B. Devolviendo los permisos de una clase de objetos concreta
Tambin puede utilizar la funcin fn_builtin_permissions para ver todos
los
permisos que estn disponibles para una categora protegible. El ejemplo
siguiente devuelve permisos de ensamblados.
*/
SELECT * FROM fn_builtin_permissions('assembly');
GO
/*C. Devolviendo los permisos de un objeto concedidos a la entidad de
seguridad que se ejecuta
Puede utilizar fn_my_permissions para devolver una lista de los permisos
efectivos que son retenidos por el entidad de seguridad de la llamada
sobre un elemento especfico que se puede proteger. Para obtener ms
informacin, vea fn_my_permissions (Transact-SQL). El ejemplo siguiente
devuelve los permisos de un objeto denominado Orders55.
*/
SELECT * FROM fn_my_permissions('Orders55', 'object');
GO

/*D. Devolviendo los permisos aplicables a un objeto especificado

El ejemplo siguiente devuelve los permisos aplicables a un objeto
denominado Yttrium. Observe que la funcin integrada OBJECT_ID se
utiliza para recuperar el identificador del objeto Yttrium.
*/
SELECT * FROM sys.database_permissions
WHERE major_id = OBJECT_ID('Yttrium');
GO

5.- Desarrollo seguro (motor de base de datos)

SQL Server tiene varios mecanismos para mejorar la seguridad del

cdigo. Estos mecanismos ayudan a los administradores y los
programadores a implementar un entorno seguro para el cdigo.
Firma de mdulos (Motor de base de datos)
SQL Server 2008 introdujo la capacidad de firmar mdulos en la base de datos como, por
ejemplo, procedimientos almacenados, funciones, desencadenadores o ensamblados. Tenga
en cuenta que no se pueden firmar los desencadenadores del lenguaje de definicin de datos
(DDL). Una firma digital es un resumen de datos cifrados con una clave privada del
firmante. La clave privada garantiza que la firma digital sea nica para su portador o
propietario.
Para firmar datos, el firmante resume los datos, los cifra con una clave privada y adjunta el
valor resumido y cifrado a los datos. Para verificar la firma, el comprobador utiliza la clave
pblica del firmante para descifrar el valor resumido y cifrado que se adjunta a los datos. A
continuacin, el comprobador compara el valor resumido y descifrado con el valor
resumido que se ha calculado en los datos complementarios. Es importante que tanto el
firmante como el comprobador usen la misma funcin hash para resumir los datos.
Advertencia
La firma de mdulos slo se debe utilizar para conceder permisos, nunca para denegarlos o
revocarlos.

Escenario

Suponga que el acceso a la vista sys.sysprocesses debe controlarse a travs del

procedimiento almacenado usp_sysprocesses. Los usuarios slo pueden tener acceso a la
informacin de sys.sysprocesses cuando pasan por el procedimiento usp_sysprocesses.
Dado que los objetos de usp_sysprocesses y sys.sysprocesses tienen diferentes propietarios,
no se aplica el encadenamiento de propiedad.
Ejemplo
La siguiente script se crea un certificado a partir de un par de claves y se
asigna a un nuevo inicio de sesin. Primero se debe crear un par de claves de
prueba mediante la herramienta MakeCert que se incluye con el SDK de .NET
Framework. A continuacin, se conceden los permisos de seleccin para la
vista sys.sysproceses al inicio de sesin asociado al certificado. Se crea el
procedimiento almacenado administrado usp_sysprocesses en la nueva base
de datos y se firma con el certificado. Se crea la funcin SysProcRole y se le
concede permisos de ejecucin en el procedimiento almacenado
usp_sysprocesses. Se crea un usuario de prueba y se agrega a la funcin
SysProcRole. El usuario de prueba realiza una instruccin SELECT en
sys.sysprocess y, a continuacin, ejecuta el procedimiento almacenado
usp_sysprocesses para comparacin. Despus, la script limpia el entorno de
prueba.

use master
go
-- Create a test database.
CREATE DATABASE db_Demo
go
-- Create a certificate on the server. A test key pair can be created
-- using the MakeCert tool that ships with the .NET Framework SDK.
CREATE CERTIFICATE SysProcCert FROM FILE = 'e:\programming\testCert.cer'
go
-- Create a login and map it to the certificate.
CREATE LOGIN login_SysProcCert FROM CERTIFICATE SysProcCert
Go
-- Revoke the connect permission.
REVOKE CONNECT SQL FROM login_SysProcCert ;
go
-- Grant the certificate, through the login, permission to select from
sys.sysprocesses view.
GRANT VIEW SERVER STATE TO login_SysProcCert
go
-- Create a test login.
CREATE LOGIN bob WITH PASSWORD = '<enterStrongPasswordHere>'
go

-- Connect to the test database.

use db_Demo
go
-- Create the master key for the test database (used to protect
-- private keys and certificates in the database).
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<enterStrongPasswordHere>'
-- Create a certificate from a private key.
CREATE CERTIFICATE SysProcCert FROM FILE = 'e:\programming\testCert.cer'
WITH PRIVATE KEY
(FILE = 'e:\programming\testCert.pvk',
DECRYPTION BY PASSWORD= '<enterStrongPasswordHere>',
ENCRYPTION BY PASSWORD='<enterStrongPasswordHere>')
go
-- Create the assembly on the server. The assembly DLL must be signed.
CREATE ASSEMBLY SysStoredProcedures
FROM 'E:\programming\SysStoredProcs.dll'
WITH PERMISSION_SET = SAFE
go
-- Create the managed stored procedure on the server.
CREATE PROCEDURE usp_sysprocesses
AS EXTERNAL NAME SysStoredProcedures.StoredProcedures.usp_sysprocesses
go
-- Add the signature to the stored procedure.
ADD SIGNATURE TO [dbo].[usp_sysprocesses]
BY CERTIFICATE SysProcCert WITH PASSWORD = '<enterStrongPasswordHere>'
go
-- Create a role.
CREATE ROLE SysProcRole
go
-- Create a test user
CREATE USER bob
go
-- Add the test user to the role.
EXEC sp_addrolemember 'SysProcRole', 'bob'
go
-- Grant execute permissions on the stored procedure to the new role.
GRANT EXECUTE ON [dbo].[usp_sysprocesses] TO SysProcRole
go
-- Connect as the test user.
EXECUTE AS LOGIN = 'bob'
use db_Demo
go
-- User only has permission to see their own processes.
SELECT * FROM sys.sysprocesses
go

-- Execute the stored procedure, which has been signed.

exec usp_sysprocesses
go
-- REVERT
REVERT
----------------------------------------------------------------------- Cleanup
use db_Demo
go
use master
go
DROP DATABASE db_Demo
go
DROP login login_SysProcCert
DROP login bob
go
DROP CERTIFICATE SysProcCert
go

A continuacin se muestra el cdigo fuente para el procedimiento almacenado

usp_sysprocesses, que realiza una instruccin SELECT en la vista
sys.sysprocesses. El ensamblado debe firmarse cuando se genera.
Imports System
Imports System.Data.SqlClient
Imports Microsoft.SqlServer.Server
Partial Public Class StoredProcedures<Microsoft.SqlServer.Server.SqlProcedure()>_
Public Shared Sub usp_sysprocesses()
Using connection As New SqlConnection("context connection=true")
connection.Open()
Dim command As New SqlCommand("SELECT * FROM sys.sysprocesses",
connection)
SqlContext.Pipe.ExecuteAndSend(command)
End Using
End Sub
End Class

Descripcin del cambio de contexto

El contexto de ejecucin est determinado por el usuario o el inicio de sesin conectado a la
sesin o que ejecuta (llama) un mdulo. Este contexto establece la identidad con la que se
comprueban los permisos para ejecutar instrucciones o realizar acciones. En SQL Server, el
contexto de ejecucin se puede cambiar a otro usuario o inicio de sesin si se ejecuta la
instruccin EXECUTE AS, o bien si se especifica la clusula EXECUTE AS en un mdulo.
Despus del cambio de contexto, SQL Server comprueba los permisos con el inicio de

sesin y el usuario de dicha cuenta, en lugar de hacerlo con la persona que llama al mdulo
o a la instruccin EXECUTE AS. El inicio de sesin de SQL Server o del usuario de la base
de datos se suplanta durante el resto de la sesin o de la ejecucin del mdulo, o bien hasta
que el cambio de contexto se revierta de forma explcita.

Cambio explcito de contexto en el servidor

Para cambiar el contexto de ejecucin en el servidor, utilice la instruccin EXECUTE AS

LOGIN = 'login_name'. El nombre de inicio de sesin debe ser visible como entidad de
seguridad principal en sys.server_principals y el usuario que llama a la instruccin debe
contar con el permiso IMPERSONATE en el nombre de inicio de sesin especificado.
El mbito de la suplantacin, cuando el contexto de ejecucin se establece en el servidor, es
el siguiente:

El token de inicio de sesin de login_name se autentica en la instancia de SQL

Server y es vlido en dicha instancia.

Se aplican los permisos de servidor y la pertenencia a funciones de login_name.

Utilice la instruccin REVERT para volver al contexto anterior. El usuario que llama a la
instruccin REVERT debe estar incluido en la misma base de datos donde se ha producido
la suplantacin.

Ejemplo

En el ejemplo siguiente, Peter Connelly, un administrador de red de AdventureWorks ,

desea crear una cuenta de inicio de sesin de SQL Server para un nuevo empleado, Jinghao
Liuhas. El inicio de sesin de SQL Server de Peter no necesita el mismo permiso en el
servidor necesario para crear inicios de sesin de SQL Server, pero tiene el permiso
IMPERSONATE para adventure-works\dan1, un inicio de sesin de SQL Server que
dispone del permiso de servidor requerido. Cuando Peter se conecta a SQL Server, el
contexto de ejecucin de la sesin se deriva de su inicio de sesin de SQL Server. Para
crear un inicio de sesin de SQL Server, Peter asume temporalmente el contexto de
ejecucin de adventure-works\dan1. Despus crea el inicio de sesin. Finalmente, renuncia
a los permisos que ha asumido.

-- Switch execution context to the adventure-works\dan1 login account.

EXECUTE AS LOGIN = 'adventure-works\dan1';
-- Create the new login account.
CREATE LOGIN Jinghao1 WITH PASSWORD = '3KHJ6dhx(0xVYsdf';
-- Revert to the previous execution context.
REVERT;

Cambio explcito de contexto en la base de datos

Para cambiar el contexto en la base de datos, utilice la instruccin EXECUTE AS USER =

'user_name'. El nombre del usuario debe existir como entidad de seguridad en
sys.database_principals y el usuario que llama a la instruccin debe contar con permisos
IMPERSONATE en el nombre de usuario especificado.
El mbito de la suplantacin, cuando el contexto de ejecucin se establece en las bases de
datos, es el siguiente:

El token de usuario de user_name se autentica en la instancia de SQL Server y es

vlido en la base de datos actual. Para obtener informacin sobre la ampliacin de la
suplantacin de usuarios ms all del mbito de la base de datos actual, vea
Extender la suplantacin de la base de datos mediante EXECUTE AS.

Se aplican los permisos de base de datos y la pertenencia a funciones de user_name

de la base de datos actual. No se aplican los permisos de servidor concedidos de
forma explcita a identidades del token de usuario ni mediante pertenencia a
funciones.

Utilice la instruccin REVERT para volver al contexto anterior. El usuario que llama a la
instruccin REVERT debe estar incluido en la misma base de datos donde se ha producido
la suplantacin.
Ejemplo

En el siguiente ejemplo, Franois Ajenstat, administrador de bases de datos de Adventure

Works Cycles, desea ejecutar la instruccin DBCC CHECKDB en la base de datos
AdventureWorksDW, pero no dispone de permisos en el nivel de base de datos para
realizar la operacin. Sin embargo, s dispone de permisos IMPERSONATE en el usuario
dan1, una cuenta que incluye el permiso necesario.
Cuando Franois se conecta a la base de datos AdventureWorksDW, el contexto de
ejecucin se asigna a su token de seguridad de usuario. Los permisos para ejecutar
instrucciones se comprueban en las entidades de seguridad principales y secundarias del
token del usuario. Puesto que no dispone de los permisos necesarios para ejecutar la
instruccin DBCC CHECKDB, ejecuta las instrucciones siguientes.

-- EXECUTE AS USER = 'dan1';

-- Create a table in dan1's default schema
CREATE TABLE t_NewTable( data nvarchar(100) );
go
-- Revert to the previous execution context.
REVERT
go;

Cambio implcito de contexto

El contexto de ejecucin de un mdulo, como un procedimiento almacenado, un

desencadenador, un cola o un funcin definida por el usuario, se puede cambiar de forma
implcita mediante la especificacin de un nombre de usuario o de inicio de sesin en una
clusula EXECUTE AS de la definicin del mdulo.
Si se especifica el contexto en que se ejecuta el mdulo, se puede controlar la cuenta de
usuario que utiliza SQL Server para validar permisos en los objetos a los que hace
referencia el mdulo. As se consigue una flexibilidad y un control adicionales en la
administracin de permisos de la cadena de objetos que existe entre los mdulos definidos
por el usuario y los objetos a los que hacen referencia estos mdulos. Los permisos pueden
concederse a usuarios nicamente para el propio mdulo, sin tener que concederles
permisos explcitos para los objetos a los que se hace referencia. Slo el usuario al que
suplanta el mdulo necesita disponer de permisos para los objetos a los que dicho mdulo
tiene acceso.
El nivel de suplantacin se determina segn el tipo de mdulo en que se define la
suplantacin.
La suplantacin en el servidor se puede definir en el siguiente elemento:

Desencadenadores DDL

El mbito de suplantacin en el servidor es el mismo que el definido anteriormente en

"Cambio explcito de contexto en el servidor".
La suplantacin en la base de datos se puede definir en los siguiente elementos:

Desencadenadores DML

Colas

Procedimientos almacenados

Funciones definidas por el usuario

El mbito de suplantacin en la base de datos es el mismo que el definido

anteriormente en "Cambio explcito de contexto en la base de datos".

Para obtener ms informacin sobre el cambio implcito de contexto, vea Usar

EXECUTE AS en mdulos.

Ejemplo

En el siguiente ejemplo, Mary es la propietaria de la tabla MyTable. Desea que el usuario

Scott pueda truncar la tabla, pero Scott no dispone de permisos directos para ella. Por tanto,
Mary crea el procedimiento almacenado dbo.usp_TruncateMyTable y concede a Scott
permisos EXECUTE para el procedimiento. Cuando Scott ejecuta el procedimiento
almacenado, Database Engine (Motor de base de datos) comprueba los permisos para
truncar la tabla como si fuera la propia Mary la que estuviera ejecutando el procedimiento
almacenado. Puesto que ella es la propietaria de la tabla, la instruccin se realiza
correctamente a pesar de que Scott no dispone de permisos directos en la propia tabla.

CREATE PROCEDURE dbo.usp_TruncateMyTable

WITH EXECUTE AS SELF
AS TRUNCATE TABLE MyDB..MyTable;

Ejemplo de Cadenas de propiedad y cambio de contexto

Para ejecutar el cdigo que se deja mas abajo, la seguridad de modo

mixto debe estar configurada y la base de datos AdventureWorks
debe estar instalada.

Escenario

En este escenario, dos usuarios necesitan cuentas para obtener acceso a los datos de los
pedidos de compra almacenados en la base de datos AdventureWorks. Los requisitos son
los siguientes:

La primera cuenta (TestManagerUser) debe poder ver todos los detalles de cada
pedido de compra.

La segunda cuenta (TestEmployeeUser) debe poder ver el nmero de los pedidos de

compra, la fecha de los pedidos, la fecha de envo, los nmeros de identificacin de
los productos y los elementos pedidos y recibidos en cada pedido de compra,
ordenados por nmero de pedido de compra, correspondientes a los elementos para
los que se han recibido envos parciales.

El resto de cuentas deben conservar sus permisos.

Para cumplir los requisitos de este escenario, el ejemplo se ha dividido en cuatro partes que
describen los conceptos de cadenas de propiedad y cambio de contexto:
1. Configuracin del entorno.
2. Creacin de un procedimiento almacenado para obtener acceso a datos por pedido
de compra.
3. Acceso a los datos mediante un procedimiento almacenado.
4. Restablecimiento del entorno.

1. Configurar el entorno
Use SQL Server Management Studio y el cdigo siguiente para
abrir la base de datos AdventureWorks y use la instruccin
CURRENT_USER de Transact-SQL para comprobar que el usuario
dbo se muestra como contexto.
USE AdventureWorks;
GO
SELECT CURRENT_USER AS 'Current User Name';
GO

2222222222222222

Use este cdigo como usuario dbo para crear dos usuarios en el servidor y en la base de
datos AdventureWorks.
CREATE LOGIN TestManagerUser
WITH PASSWORD = '340$Uuxwp7Mcxo7Khx';
GO
CREATE USER TestManagerUser
FOR LOGIN TestManagerUser
WITH DEFAULT_SCHEMA = Purchasing;
GO
CREATE LOGIN TestEmployeeUser
WITH PASSWORD = '340$Uuxwp7Mcxo7Khy';
GO
CREATE USER TestEmployeeUser
FOR LOGIN TestEmployeeUser;
GO
333333333333333333333333333

Use el cdigo siguiente para cambiar la propiedad del esquema

Purchasing a la cuenta TestManagerUser. Esto permite que dicha cuenta
use todo el acceso a las instrucciones del lenguaje de manipulacin de
datos (DML) (por ejemplo, los permisos SELECT y INSERT) en los objetos
que contiene. Puesto que no se incluyen los permisos de lenguaje de
definicin de datos (DDL), a TestManagerUser se le conceden
explcitamente derechos en las tablas PurchaseOrderHeader y
PurchaseOrderDetail adems de la capacidad de crear procedimientos
almacenados.

/* Change owner of the Purchasing Schema to TestManagerUser */

ALTER AUTHORIZATION
ON SCHEMA::Purchasing
TO TestManagerUser;
GO
/* Grant permissions to TestManagerUser on these objects with GRANT
option */
GRANT ALL
ON OBJECT::AdventureWorks.Purchasing.PurchaseOrderHeader
TO TestManagerUser

WITH GRANT OPTION;

GO
GRANT ALL
ON OBJECT::AdventureWorks.Purchasing.PurchaseOrderDetail
TO TestManagerUser WITH GRANT OPTION;
GO
/* Note: DML works fine with Schema owner, but not DDL. */
GRANT CREATE PROCEDURE
TO TestManagerUser
WITH GRANT OPTION;
GO

2. Crear un procedimiento almacenado para obtener acceso a los datos

Existen dos modos de permitir a un usuario que cambie los contextos en
una base de datos: mediante SETUSER o EXECUTE AS. Para usar la
instruccin SETUSER, el autor de la llamada debe ser miembro de la
funcin fija de servidor sysadmin o ser la cuenta dbo. EXECUTE AS
requiere permisos IMPERSONATE.
Use la instruccin EXECUTE AS en el cdigo siguiente para cambiar el
contexto a TestManagerUser y crear un procedimiento almacenado que
muestre nicamente los datos exigidos por TestEmployeeUser. Para
cumplir los requisitos, el procedimiento almacenado acepta una variable
para el nmero del pedido de compra y no muestra la informacin
financiera, y la clusula WHERE limita los resultados a los envos
parciales.

EXECUTE AS LOGIN = 'TestManagerUser'

GO
SELECT CURRENT_USER AS 'Current User Name';
GO
444444444444444444444444444444444444444
/* Note: The user that calls the EXECUTE AS statement must have
IMPERSONATE permissions on the target principal */
CREATE PROCEDURE usp_ShowWaitingItems @ProductID int
AS
BEGIN
SELECT a.PurchaseOrderID, a.OrderDate, a.ShipDate
, b.ProductID, b.OrderQty, b.ReceivedQty
FROM Purchasing.PurchaseOrderHeader a
INNER JOIN Purchasing.PurchaseOrderDetail b

ON a.PurchaseOrderID = b.PurchaseOrderID
WHERE b.OrderQty > b.ReceivedQty
AND @ProductID = b.ProductID
ORDER BY b.ProductID ASC

END
GO

5555555555555555555555555555555555555555555555555555

En estos momentos, TestEmployeeUser no tiene acceso a ningn objeto

de la base de datos. El cdigo siguiente (todava en el contexto de
TestManagerUser) permite que la cuenta de usuario consulte la
informacin de tabla base mediante el procedimiento almacenado.
GRANT EXECUTE
ON OBJECT::Purchasing.usp_ShowWaitingItems
TO TestEmployeeUser;
GO

El procedimiento almacenado forma parte del esquema de Purchasing,

aunque no se especifica explcitamente ningn esquema, porque
TestManagerUser se asigna de forma predeterminada al esquema
Purchasing. La informacin del catlogo del sistema se puede utilizar
para buscar objetos, tal y como se muestra en el cdigo siguiente.

SELECT a.name AS 'Schema'

, b.name AS 'Object Name'
, b.type AS 'Object Type'
FROM sys.schemas a
INNER JOIN sys.objects b
ON a.schema_id = b.schema_id
WHERE b.name = 'usp_ShowWaitingItems';
GO

77777777

Una vez finalizada esta seccin del ejemplo, el cdigo vuelve a cambiar
el contexto a dbo mediante la instruccin REVERT.
REVERT;
GO

88888888

3. Obtener acceso a los datos mediante el procedimiento almacenado

TestEmployeeUser no tiene ningn permiso en los objetos de la base de
datos AdventureWorks aparte del inicio de sesin y los derechos
asignados a la funcin de base de datos public. El cdigo siguiente
devuelve un error cuando TestEmployeeUser intenta obtener acceso a
las tablas base.
EXECUTE AS LOGIN = 'TestEmployeeUser'
GO
SELECT CURRENT_USER AS 'Current User Name';
GO

99999
/* This won't work */
SELECT *
FROM Purchasing.PurchaseOrderHeader;
GO
SELECT *
FROM Purchasing.PurchaseOrderDetail;
GO

Puesto que los objetos a los que hace referencia el procedimiento

almacenado, creados en la ltima seccin, pertenecen a
TestManagerUser en virtud de la propiedad de esquema Purchasing,
TestEmployeeUser puede tener acceso a las tablas base mediante el
procedimiento almacenado. El cdigo siguiente, que todava usa el

contexto TestEmployeeUser, pasa el pedido de compra 952 como un

parmetro.
EXEC Purchasing.usp_ShowWaitingItems 952
GO

1010101010101010101

4. Restablecer el entorno
El cdigo siguiente usa el comando REVERT para devolver el contexto de
la cuenta actual a dbo y, a continuacin, restablece el entorno.
REVERT;
GO
ALTER AUTHORIZATION
ON SCHEMA::Purchasing TO dbo;
GO
DROP PROCEDURE Purchasing.usp_ShowWaitingItems
GO
DROP USER TestEmployeeUser;
GO
DROP USER TestManagerUser;
GO
DROP LOGIN TestEmployeeUser;
GO
DROP LOGIN TestManagerUser;
GO

1111111111