Hace un tiempo recibi en un newsletter de Microsoft esta nota, y me parecio muy importante como para compartirla. Es vital para todos aquellos que estan planificando implementar Windows Server 2008, SQL y clientes Windows Vista. La misma habla del impacto de UAC (User Account Control). Se las recomiendo, el material original se encuentra publicado en el site de Microsoft (link).
Saludos, Roberto Di’Lello.
Control de Cuentas de Usuarios y SQL Server
Publicado: Agosto 15, 2007
Por Devendra Tiwari, Equipo de Productos de Microsoft SQL Server
Consultar otras columnas con Consejos del Mes sobre Seguridad
Windows Vista incluye un Control de Cuenta de Usuarios –User Account Control (UAC)– en inglés, nueva función que los administradores pueden utilizar para administrar el uso de privilegios elevados. En Windows Vista, los administradores y otros usuarios privilegiados no utilizan sus privilegios por default. En cambio, ejecutan la mayoría de las acciones como usuarios estándar; de hecho asumen sus privilegios de administrador sólo cuando es necesario. La elevación de privilegios ocurre en determinado nivel del proceso, lo cual significa que se eleva una única instancia de la aplicación. Por ejemplo, elevar el uso de CMD.exe no corre todos los procesos de CMD.exe en el mismo nivel de privilegios, aún cuando estos procesos se inicien al mismo tiempo.
El UAC proporciona una serie de mecanismos mediante los cuales un programa ejecutable puede ser elevado para que se ejecute con un privilegio de administrador, desde el mismo momento en que es iniciado. Esto incluye la posibilidad de listar el nombre de la aplicación en la base de datos de Windows (AppCompat), asociando un archivo manifiesto con el ejecutable, y haciendo clic derecho en el ejecutable para concretar la elevación única.
Impacto en SQL Server
El Control de Cuenta de Usuarios afecta a Microsoft SQL Server en términos de conectividad (log-in de SQL Server), y porque limita el acceso a recursos en la lista de control de accesos –Access Control List (ACL)– del administrador.
Conectividad de SQL Server
En versiones anteriores a Windows Vista y Windows Server 2008, los miembros del grupo de administradores locales no necesitan sus propios log-ins de SQL Server, así como tampoco necesitan contar con privilegios de administración dentro de SQL Server. Se conectan a SQL Server como el servidor principal BUILTIN\Administrators (B\A), y adquieren privilegios de administración porque B\A es miembro del rol de servidor fijo sysadmin. Los derechos de administrador son restringidos en Windows Vista y Windows Server 2008, de tal manera que los usuarios administradores no pueden conectarse a una instancia de SQL Server simplemente por ser B\A, a menos que se conecten desde una aplicación de cliente elevada.
Considere la siguiente situación anterior a Windows Vista:
1.Abby ejecuta Windows NT con un privilegio de administración (desafortunadamente muy frecuente).
2.Abby solicita conectarse a una instancia SQL Server, cosa que logra sin problemas, y por lo tanto ahora puede tomar cualquier decisión relativa a esta instancia.
Siendo o no conciente de ello, Abby obtuvo acceso a una instancia SQL desde que el grupo de Windows “BUILTIN\Administrators” es miembro del rol de servidor SQL Server, sysadmin. Cuando se ejecuta en Windows Vista y en Windows Server 2008, el intento de conexión falla. El símbolo de Abby no incluye privilegios de administrador; por lo tanto la instancia de SQL Server no reconoce su log-in como válido.
ACLs del Administrador
En las versiones anteriores a Windows Vista, los administradores tiene por default acceso irrestricto a los recursos locales de Windows, por ejemplo archivos, carpetas y el registro. Desde que en Windows Vista y en Windows Server 2008 los administradores ejecutan la mayoría de las acciones como usuarios estándar, su acceso a los recursos es limitado. Cualquier aplicación de SQL Server que accede a archivos y carpetas, a valores y clave de registro, a servicios de sistema, a procesos del sistema operativo, o logs de eventos, depende de que B\A no opere en Windows Vista y Windows Server 2008.
El propósito de SQL Server consiste en permitir que los clientes trabajen en el nivel más bajo de privilegios, e igualmente obtengan una buena experiencia como usuarios finales en Windows Vista y Windows Server 2008 con el UAC habilitado. Microsoft SQL Server 2005 Service Pack 2 (SP2) enfrenta los siguientes problemas:
•SQL Server 2005 SP2 incluye una herramienta que puede ejecutarse desde Instalar o desde la herramienta SQL Server, Surface Area Configuration, y que permite agregar un usuario al rol de servidor fijo sysadmin para que pueda ejecutar acciones de administrador en SQL Server.
•SQL Server 2005 SP2 también cuenta con ejecutables de SQL Server electivamente elevados que ejecutan acciones de administrador en Windows.
•Para Microsoft SQL Server 2008, pensamos mejorar la adjudicación de cuentas y toda la experiencia UAC. Durante el proceso de instalación, usted podrá disponer de más de una cuenta en el rol de servidor fijo sysadmin y ejecutar acciones de administrador en SQL Server. También existirá una mejor separación entre la administración de Windows y la de SQL Server.
El impacto del UAC en SQL Server se encuentra documentado en http://msdn2.microsoft.com/en-us/library/bb326612.aspx.
Cómo Ejecutar Aplicaciones de SQL Server en Forma Segura en Windows Vista y en Windows Server 2008
La versión admitida de SQL Server para Windows Vista y Windows Server 2008 es SQL Server 2005 SP2. Para ejecutar aplicaciones de SQL Server de manera segura, por favor tenga en cuenta los siguientes puntos:
•No eleve las aplicaciones SQL Server 2005 SP2 por default. Entre las aplicaciones elevadas en SP2 se encuentran las siguientes, cuyos nombres se mantienen en inglés: Surface Area Configuration, SQL Diagnostics, SQL Configuration Manager, Reporting Services Configuration, Reporting Services Key Management, SQL Watson Error Reporting, and Hotfix.exe. Estas aplicaciones exigen acciones por parte de administradores de Windows NT y deben ser elevadas.
•Noeleve las aplicaciones cliente de SQL Server como SQL Server Management Studio (SSMS).
•Una vez finalizada la instalación de SP2, se ejecuta la herramienta de aprovisionamiento de SQL Server. Es importante especificar el usuario en esta herramienta. A este usuario se le adjudica un log-in dentro de SQL Server con derechos de sysadmin, para que evite cualquier conflicto de conectividad después de la instalación de SP2, desde un cliente no-elevado de SQL Server. Si usted no especifica un usuario en la herramienta de aprovisionamiento, la instalación de SP2 se dispondrá como un log-in con privilegios de sysadmin. Este log-in puede entonces conectarse a la instancia SP2 después de la instalación, y les asigna a otros usuarios los roles apropiados.
•Para las aplicaciones de consola que requieren elevación para la función Ex Reporting Services Key Management (RSKeyMgmt.exe), ejecútelas desde un comando elevado.
El documento SQL Server Security Best Practices –Mejores Prácticas de Seguridad para SQL Server– cubre algunas de las tareas operativas y administrativas asociadas con la seguridad de SQL Server 2005, y enumera las mejores prácticas y las tareas operativas y administrativas que desembocan en un sistema SQL Server más seguro. Esta documentación es una guía de seguridad sobre reducción de superficie, modo de autentificación, consideración de cuenta de servicios, política de claves, privilegios administrativos, autorización, encriptación, auditoría y parches. Se encuentra disponible en http://www.microsoft.com/technet/prodtechnol/sql/2005/sql2005secbestpract.mspx.
Oros Recursos
•Contenido sobre el UAC de SQL Server 2005 SP2: http://msdn2.microsoft.com/en-us/library/bb326612.aspx
•UAC de Windows Vista: http://www.microsoft.com/technet/windowsvista/security/uac.mspx