Recientemente escribí un post que habla de cómo transferir los Logins entre instancias de SQL Server utilizando scripts documentados en la base de conocimiento de Microsoft.  Pueden encontrar este post en:

Cómo transferir los inicios de sesión y las contraseñas entre instancias de SQL Server

Además de transferir la contraseña, normalmente queremos que el nuevo Login tenga el mismo SID para evitar que los usuarios queden huérfanos dentro de las bases de datos migradas o transferidas. Esto lo realizan los script  documentados en la base de conocimiento que hago referencia en el post.

Sin embargo uno de los lectores me hizo notar que no había explicado que los scripts generados por estos documentos no generan los scripts correspondientes a los roles (funciones) de servidor que tenían en la instancia de origen.  Solo el método 2 del documento en inglés que transfiere los Logins desde el SQL Server 2000 al SQL Server 2005/2008 tiene la posibilidad de generar el script para transferir los roles de servidor entre las instancias. Las otras versiones del script no lo hacen.

Si ya hemos creado los Login con el script de estos documentos de la base de conocimiento y debemos  además, transferir los roles de servidor a esta nueva instancia, y nuestro origen es un SQL Server 2005 o un SQL Server 2008, podemos usar el siguiente script para generar el script de transferencia:

-- Genera el script con los Roles para los Logins
Select 
 'exec master.dbo.sp_addsrvrolemember @loginame=''' 
 + sp.name + ''', @rolename='''+sp2.name +''';' 
from 
master.sys.server_principals as sp 
join master.sys.server_role_members as srm 
on sp.principal_id = srm.member_principal_id 
join master.sys.server_principals as sp2 
on srm.role_principal_id=sp2.principal_id
where sp.type in ('S','U','G')


-- Genera el script con la base de datos por default (omision) para los Logins
Select 
 'ALTER LOGIN ['+ sp.name 
 +'] WITH DEFAULT_DATABASE = [' 
 + sp.default_database_name +'];'
from 
master.sys.server_principals as sp 
where sp.type in ('S','U','G')
and sp.default_database_name is not null

Los algoritmos de cifrado y la seguridad nacional.

Hace unos años hubo una gran controversia acerca de la exportación de software y hardware que contenía algoritmos de cifrado “duros” debido a que los “enemigos” los podían usar para intercambiar información.

La controversia del AES y la seguridad nacional

Lo mismo ocurrió acerca de la selección del sucesor del DES como el algoritmo de cifrado, el cual iban a utilizar las agencias no militares y los contratistas del gobierno. La elección del AES como el algoritmo estándar de cifrado, una variación limitada en cuanto a sus prestaciones del algoritmo original Rijndael, fue anunciada por el Instituto Nacional de Estándares y Tecnología (NIST) como el estándar federal de procesamiento de la información. Esta controversia se basaba en el hecho de que se temía, de que los cambios introducidos al algoritmo ganador del concurso, permitían realizar un criptoanálisis a la información cifrada. Esto era algo que se sospechaba pero que oficialmente no se discutía, por temas de seguridad nacional.

Blackberry y la seguridad nacional

Recientemente dos países anunciaron restricciones a los servicios de e-mail y mensajería instantánea del Blackberry, utilizando como pretexto el que los servicios centralizan el manejo de los datos en servidores alojados en el extranjero. Esto puede ser verdad, pero sin embargo a veces puede haber sospechas de que en realidad son escusas que utilizan los gobiernos para prohibir la utilización de la tecnología por otros motivos, como por ejemplo los culturales, políticos o religiosos. Hay quienes dicen que la iniciativa más que buscar la protección de la seguridad nacional esconde un intento por controlar la información de la población.

Research In Motion (RIM), la creadora del Blackberry, hace que cierta información pase por sus servidores que están ubicados principalmente en Canadá. Si bien los datos viajan cifrados, el algoritmo usado no es conocido lo cual aumenta las sospechas.

Otro detalle no menor para los gobiernos es que puede alegarse que la información intercambiada constituye un peligro para la seguridad nacional, porque puede ser de terroristas y otros criminales y de esta forma puede ser intercambiada sin que puedan ser supervisadas por las autoridades.

Si bien las razones exactas del impedimento no están muy claras, el número de usuarios afectados podría ser mucho mayor si la represión se aplica también a extranjeros en viaje. Otro detalle no menor es que como la mayoría de los equipos pertenecen a empleados de áreas de las finanzas, y los bancos que los emplean dicen que están más preocupados por la seguridad de los datos frente a sus rivales que por la censura estatal.

El regulador de telecomunicaciones dice que el impedimento es el resultado del fracaso de que RIM se ajuste a las normas locales desde el año 2007. La prohibición se parece más un paso táctico para negociar con la empresa. En India pasó algo similar y alcanzaron un acuerdo.

Cloud Computing y seguridad nacional

La idea de Cloud Computing (informática en nube) ha ido ganando impulso en los últimos tiempos. La globalización ha llegado también a los servicios ofrecidos en internet. Sus promesas de reducción de costos y de mejora de la flexibilidad de TI han conseguido despertar el interés de las empresas. Pero el uso de modelos Cloud Computing también conlleva algunos riesgos relacionados con la conformidad, la disponibilidad y la integridad de los datos corporativos que deben superarse.

Debe tenerse en cuenta sobre todo que en última instancia, frente a las autoridades y clientes, el consumidor de los servicios es el responsable de mantener la confidencialidad, integridad y disponibilidad de los datos.

Esta nueva ola tecnológica trae también controversias de seguridad, que si bien son diferentes, en algunos aspectos pueden parecerse a lo que le está ocurriendo al Blackberry. El almacenamiento de la información fuera de las fronteras, o fuera del alcance de la justicia local, pero si al alcance de la justicia o medidas de los gobiernos extranjeros donde residen los Datacenters, pueden ser vistas como riesgos a la seguridad nacional.

Conclusión

Si no se elabora un acuerdo internacional en cuanto a la gestión global de la información, equivalente a lo que ocurre en el área de las transacciones comerciales con los acuerdos de la Organización Mundial de Comercio (OMC), esto puede retrasar el avance de la nube principalmente en países que no son económicamente “convenientes” para tener los Datacenters locales.

Pequeño aumento de I/O en el Log de Transacciones.

En primer lugar, debemos tener en cuenta que, existe un pequeño aumento del I/O en los archivos del Log de Transacciones si la captura de datos modificados o Change Data Capture (CDC)  está habilitado en la base de datos. Esto ocurre debido a que se deben leer los datos de los cambios desde estos archivos del log de transacciones para poder identificar los cambios e incorporarlos en las tablas de captura. Además cuando corre el proceso o job de limpieza, se eliminan registros de las tablas de captura relacionadas y el log de transacciones también debe ser actualizado para respetar las reglas de las transacciones de las bases de datos.

Consecuencias de la captura de datos modificados o Change Data Capture en la reutilización de las entradas en el log de transacciones.

Cuando usamos una base de datos, una de las cosas que debiéramos tomar en cuenta es el tamaño que va a tener nuestro  registro o log de transacciones (Transaction Log). Para el correcto control del tamaño de los archivos que lo componen, si el modelo de recuperación es full, se realizan periódicamente tareas administrativas como el backup (o copia de seguridad) del log de transacciones. Esta tarea permite que en condiciones normales el mismo no crezca sin control ya que al completar la copia se pueden reutilizar las entradas y no hace falta que siga creciendo. Otra de las alternativas usadas es el modelo de recuperación simple que marca las transacciones completadas y grabadas en los archivos de datos como reutilizables lo que minimiza el uso del mismo a expensas de tener más posibilidades de recuperar datos en caso de una falla.

Es importante señalar que la captura de datos modificados o Change Data Capture (CDC) funciona correctamente en todos los modelos de recuperación. Cuando el CDC está habilitado en los modelos de recuperación simple o bulk-logged, los cambios realizados por las operaciones que normalmente se registran mínimamente, pasan a ser totalmente registrados en el log de transacciones para permitir la captura de todos los datos modificados. Además, cuando usamos la Captura de Datos Modificados o Change Data Capture se producen cambios en cómo se marcan las entradas que pueden reutilizarse en el log de transacciones. 

Si vemos con más detalle lo que ocurre, veremos que  los registros del log de transacciones permanecen activos hasta que el CDC los ha procesado. Esto significa, que en entornos en los que hay una gran tasa de cambios o la latencia de captura es grande, cuando el CDC no procesa frecuentemente las entradas de log de transacciones,  se acumulan entradas no reutilizables en el archivo del log de transacciones y por lo tanto este debe crecer porque el espacio no se puede reutilizar . Esto puede ocurrir tanto en el modelo de recuperación simple como después de un backuo o copia de seguridad de log de transacciones en el modelo de recuperación full (completa).

Consecuencias del log de transacciones lleno

Cuando un disco donde está el registro de transacciones se llena, no se puede reducir el tamaño del archivo del log de transacciones usando el comando shrink, hasta que la Captura de Datos Modificados o Change Data Capture (CDC) ha procesado todas las transacciones involucradas.  El problema es que el CDC no puede procesar las transacciones cuando los discos donde está el log de transacciones está lleno (o no puede crecer), porque el CDC inserta registros en las tablas de captura y estas operaciones también deben registrarse en el LOG de transacciones.

Si el problema es el espacio en el disco, la forma más fácil de recuperarse de esta situación es añadir otro archivo al log de transacciones,al menos de manera temporal, en un disco diferente donde haya espacio.

Si se realiza una migración o actualización de un reporte que hace referencia a un origen de datos compartido de Reporting Services 2005 a Reporting Services 2008, el informe dejará de funcionar después de la migración, ya que este proceso actualiza el nombre del data source compartido.

Quienes diseñaron reportes en el Business Intelligence Development Studio de SQL Server Reporting Services 2005 pueden utilizar nombres de data source compartidos con espacios en blanco. Sin embargo en la versión del 2008 ya no se pueden utilizar más. Por lo tanto no es posible crear nuevos data source con espacios en blanco.

En el IDE de Visual Studio 2005 si se puede utilizar fuentes de datos (data source) con espacios en blanco en el nombre.

Como puede verse en la siguiente imagen, en el IDE de Visual Studio 2008 no se puede usar fuentes de datos compartidas con nombres que contengan espacios en blanco en el nombre.

El problema es que si le cambiamos desde el sitio del Report Manager de Reporting Services el data source al que hace referencia el reporte que se encuentra en el servidor este cambio no tiene efecto a pesar que desde la interface el cambio queda impactado.

Existe una solución alternativa y consiste en editar el nombre del data source compartido del reporte para eliminar los espacios en blanco. Esto se realiza editando el contenido dentro del TAG <DataSourceReference> que se encuantra dentro del tag <DataSources>  en el archvo RDL del reporte como puede verse en la siguiente Imagen.

El almacenamiento en el entorno de desarrollo

El entorno de desarrollo SDK de Windows Azure incluye el “Development Storage”, que es una herramienta que simula los servicios Blob, Queue y Table disponibles en la nube. Además ofrece una interfaz de usuario para ver el estado y para iniciar o detener estos servicios de almacenamiento local.

El servicio “Development Storage” se basa en una instancia de SQL Server para simular los servidores de almacenamiento de la nube. De forma predeterminada, el almacenamiento de desarrollo está configurado para utilizar una versión “Express“ del SQL Server 2005 o 2008 como base de datos.

Cambiando la instancia

Cuando ya tenemos un entorno de desarrollo con el SQL Server instalado y este no es la edición “Express” generalmente ocurre que la instancia es una instancia DEFAULT o es una instancia con nombre pero no se llama “express”. Por ejemplo es muy común tener la edición SQL Server 2008 Developer edition en el entorno de desarrollo. Si queremos utilizar esta instancia SQL Server previamente instalada y que no se llama “express” tenemos que reconfigurar nuestro entorno de desarrollo.

Para poder configurar el “development storage”, se debe tener privilegios de administrador del equipo. El programa de línea de comandos DSInit.exe inicializa el “development storage” en el entorno de desarrollo local. Esta herramienta se ejecuta automáticamente la primera vez que se inicia el “development storage” mediante la ejecución del programa DevelopmentStorage.exe y no es necesario ejecutarla a menos que queramos reinicializarlo o cambiarlo como es en nuestro caso. La herramienta DSInit.exe se instala en el directorio C: \ Archivos de programa \ Windows Azure SDK \ v1.0 \ bin \.

Para que el servicio “development storage” utilice otra instancia local del SQL Server tenemos que ejecutar el DSInit con el parámetro /SQLInstance, pasándole el nombre de la instancia del SQL Server de destino. Se puede llamar a DsInit.exe /SQLInstance en cualquier momento para configurar el “development storage” para que apunte a una instancia diferente de SQL Server.

Hay que utilizar el nombre de la instancia de SQL Server sin el calificativo de servidor o “.” para indicar la instancia “Default”

Si disponemos de una instancia local con nombre, por ejemplo la instancia es SQLTotalJMA\SQL2008 como es en mi caso, debemos ejecutar “DSInit.exe /sqlinstance:SQL2008” como muestra la imagen.

Esto nos configura el entorno de desarrollo como muestra la siguiente imagen

El procedimiento almacenado xp_cmdshell es esencialmente un mecanismo para ejecutar llamadas en el sistema operativo utilizando el contexto de SQL Server (es decir, la cuenta de Windows utilizada para iniciar el servicio del SQL Server) o una cuenta proxy que puede ser configurada para ejecutar xp_cmdshell con diferentes credenciales. Si bien habilitar y utilizar este procedimiento almacenado no es una buena práctica, ciertas aplicaciones usan esta técnica y a veces puede ser necesario acceder a la línea de comandos del sistema operativo para ejecutar algún programa fuera del SQL Server. En estos casos tenemos que tener mucho cuidado en como habilitamos y damos permisos para que el usuario pueda acceder a los recursos del sistema operativo con mínimos permisos. En este artículo analizaremos algunos detalles y de cómo habilitarlo con menos permisos que los indicado en la ayuda.

El procedimiento almacenado xp_cmdshell

Para ejecutar un programa fuera del contexto del SQL Server se utiliza el procedimiento almacenado extendido xp_cmdshell, Con este procedimiento almacenado extendido podemos ejecutar cualquier proceso de línea de comandos, por lo que no solo se pueden ejecutar programas EXE sino que se puede ejecutar un archivo de lotes (BAT o CMD).

Debemos tener sumo cuidado en cómo se utiliza este procedimiento almacenado ya que si el contexto de ejecución tiene permisos de administrador local del equipo por ejemplo el programa o un código inyectado pueden agregar un usuario administrador del equipo (del WIndows) utilizando NET USER y NET GROUP.

En SQL Server 2000, por los riesgos de seguridad que implica y para limitar el acceso al xp_cmdshell , su uso está restringido por defecto o en forma predeterminada solo a los miembros de la función de servidor o rol sysadmin. Para extender los derechos a otros usuarios se puede utilizar el comando GRANT.

En SQL Server 2005 el uso de xp_cmdshell está desactivado por defecto como mecanismo de protección para minimizar los riesgos de seguridad de código no deseado en ejecución dentro o fuera de SQL Server de SQL Server. Por ello, si no se habilita la ejecución del xp_cmdshell ni siquiera los administradores del SQL Server (grupo de servidor sysadmin) podrán ejecutarlo.

Por ejemplo si ejecutamos como administradores:

exec xp_cmdshell 'dir c:\*.*'

El resultado es:

Para poder ejecutar el procedimiento almacenado extendido xp_cmdshell debemos habilitarlo haciendo:

--Habilito la ejecucion del xp_cmdshell

EXEC sp_configure 'show advanced options', 1
GO

RECONFIGURE
GO

EXEC sp_configure 'xp_cmdshell', 1
GO

RECONFIGURE
GO

Ahora vemos que si volvemos a ejecutar el scrip T-SQL anterior como administrador del SQL Server vemos que nos responde cuando estamos autenticados como administradores. El proceso de Windows creado por xp_cmdshell dispone de los mismos derechos de seguridad que la cuenta de servicio de SQL Server la cual tenía los permisos adecuados en la raíz del disco.

Cuenta proxy para el xp_cmdshell

Cuando es llamada por un usuario que no pertenece al rol (función de servidor) sysadmin, el xp_cmdshell se conecta a Windows con el nombre de la cuenta y la contraseña almacenados en la credencial con el nombre ##xp_cmdshell_proxy_account## en lugar de usar la cuenta de servicio por lo que habrá que indicarla previamente o sino dará error.

Vamos a probar ahora con un login que solo tiene permisos mínimos

--Creamos el login 
CREATE LOGIN [Prueba]
WITH PASSWORD=N'<la contraseña del usuario>',
DEFAULT_DATABASE=[master],
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

Para crear la credencial de la cuenta de proxy hay que ejecutar sp_xp_cmdshell_proxy_account y como parámetros el nombre del usuario y la contraseña de Windows.

-- Asigno la proxy account
EXEC sp_xp_cmdshell_proxy_account
N'sqltotal\mariano',
N'<la contraseña del usuario>'

El resultado es:

Aquí nos encontramos con un nuevo problema si estamos usando Windows Vista como es mi caso. No podemos asignar esta contraseña por más que el usuario usado sea administrador del SQL Server debido al UAC. Por lo tanto debemos ejecutar este comando en una nueva instancia del SQL Server Management Studio como administrador usando la opción “RUN AS ADMINISTRATOR” (ejecutar como administrador).

Luego de asignar la cuanta proxy como administrador local y del SQL Server abrimos una nueva ventana con el usuario prueba y verificamos que pasa:

exec xp_cmdshell 'dir c:\*.*'

Y el resultado es:

En este punto si revisamos la ayuda en el link siguiente podemos verificar que nos dice que se requiere el permiso CONTROL SERVER, para poder ejecutar xp_cmdshell el cual no es adecuado ya que posibilita tomar el control total del SQL Server.

xp_cmdshell en la ayuda del SQL Server

Por lo tanto vamos a crear el usuario dentro de la base de datos master relacionado con el login y asignar solo el permiso de ejecución del procedimiento almacenado:

-- Creo el usuario en la base de datos
-- master para el login anterior
USE [master]
GO

CREATE USER [Prueba] FOR LOGIN [Prueba]
GO

-- Asigno el permiso de ejecucion al usuario
use [master]
GO

GRANT EXECUTE ON [sys].[xp_cmdshell]
TO [Prueba]
GO

Si ahora probamos veremos que es posible ejecutar el procedimiento almacenado xp_cmdshell sin ser administrador sin asignar permisos de CONTROL SERVER.

Veamos qué pasa si tenemos asignado solo el permiso de ejecución del procedimiento almacenado pero no existe la credencial.

Como administradores eliminamos la cuenta proxy:

EXEC sp_xp_cmdshell_proxy_account null

Probamos la ejecucion del procediemiento almacenado nuevamente con el usuario prueba

exec xp_cmdshell 'dir c:\*.*'

El resultado es:

Conclusiones

• No es recomendable utilizar el procedimiento almacenado xp_cmdshell.
• Para poder ejecutarlo se requiere habilitar su ejecución en la configuración del SQL Server utilizando el procedimiento almacenado sp_configure.
• Si somos administradores podemos ejecutar el procedimiento xp_cmdshell el cual utiliza la cuenta de servicio del SQL Server
• Si no somos administradores utiliza la cuenta proxy que debe estar definida.
• Si no somos administradores solo debemos tener permiso de ejecución en el procedimiento almacenado xp_cmdshell y no hace falta asignar el permiso CONTROL SERVER como dice la ayuda.

La ejecución del SQL Server Profiler requiere al menos del permiso de servidor ALTER TRACE. Este es el mismo permiso que se requiere para poder ejecutar los procedimientos almacenados de T-SQL que se utilizan para crear las trazas.

Veamos un ejemplo.

Creamos un usuario con mínimos permisos :

USE [master]

GO

-- creamos el Login 

CREATE LOGIN [prueba] 

WITH PASSWORD=N'pruebaPass', 

DEFAULT_DATABASE=[master], 

CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

Luego podemos verificar que no se puede acceder mediante el profiler:

Hacer click en la imagen para agrandarla.

Asignamos el permiso de servidor ALTER TRACE con lo cual le concedemos el permiso de hacer trazas y conectar el Profiler para realizar un seguimiento.

GRANT ALTER TRACE 

TO [Prueba]

GO

Luego nos conectamos desde el Profiler y verificamos que ahora si se puede conectar.

Entonces ejecutamos :

CREATE LOGIN [prueba2] 

WITH PASSWORD=N'pruebaPass', 

DEFAULT_DATABASE=[master], 

CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF

GO

exec sp_help 'sys.indexes'

Como puede verse en la próxima imagen siguiente, el Profiler funciona y como seleccionamos el evento SQL:BatchStarting nos muestra las sentencias que ejecutamos.

Hacer click en la imagen para agrandarla.

Consideraciones de seguridad importantes al asignar el permiso ALTER TRACE

Es importante ver que en el caso del CREATE LOGIN nos oculta los datos del usuario y la contraseña. Sin embargo nos muestra el parámetro del procedimiento almacenado sp_help.

Como los usuarios que tienen el permiso ALTER TRACE pueden ver las consultas capturadas, se debe tener cuidado ya que las mismas pueden contener datos confidenciales, como contraseñas que se pasan como parámetros en los procedimientos almacenados. El caso mas común es cuando se utilizan mecanismos propietarios de autenticación. Por lo tanto, es importante conceder estos permisos solo a los usuarios que tengan autorización para ver información confidencial.