Seguridad

Problemas comunes de seguridad de SQL Server y soluciones

Paul S. Randal

En resumen:

• Física y de seguridad de red
• Atacar superficie, las cuentas de servicio y privilegios mínimos
• Inserción de autenticación, autorización y SQL
• Recuperación ante desastres y auditoría

Contenido

Seguridad física
Seguridad de red
Minimization superficie de ataque
Cuentas de servicio
Restringir el uso de privilegios de administrador
Autenticación
Autorización
Inserción de SQL
Recuperación ante desastres
Auditoría
Resumen

Cualquier persona que ha sido alrededor de la industria de TI sabe que la seguridad es un tema activo. Después de todo, datos de una compañía es uno de los activos más valiosos tiene y protección de los datos es fundamental. Como ha planear cómo escribir para este problema de seguridad, intentó determina qué característica de seguridad debería tener un artículo completo dedicado a ella. Pero, a continuación, inicia a pensar en el número creciente de los "Administradores involuntarias" (los profesionales de TI que sin darse cuenta Asimismo hasta responsable de una instancia de SQL Server) y la respuesta gran tuvimos que el Principales sugerencias para mantenimiento de bases de datos eficazartículo del problema de 2008 agosto. Me trazo que lo que debe hacer es escribir un artículo que trata problemas comunes de seguridad de SQL Server, una especie de hicieron a la mejor seguridad de sus instancias de SQL Server.

Un artículo que describe todos los problemas de seguridad que debe buscar en sería una revista toda en sí, por lo que canvassed mi tipo MVP de SQL Server (y mi esposa) para la entrada como para lo que debe incluir. Liquidado en proporcionar las áreas de seguridad 10 superior que cree que debe preocuparse si no es administrador prácticos de seguridad y de repente encuentra usted responsable de una instancia de SQL Server y asociados de aplicación. Recuerde que esto no es una lista exhaustiva. Para cada problema ha proporcionado una breve introducción del problema, consejos sobre cómo mitigar y un vínculo a información más detallada.

Todos los vínculos a los libros en pantalla son para las versiones de SQL Server 2008, pero cada página Web se vincula a la versión de SQL Server 2005 así. Se ajuste hasta el artículo, proporcionan vínculos a las secciones de los libros en pantalla y notas del producto principales de seguridad para SQL Server 2005 y SQL Server 2008.

Seguridad física

Es imprescindible que no sólo considere seguridad de SQL Server Sí, pero todos los niveles que se deben recorrer para llegar a SQL Server en primer lugar. Este concepto de seguridad en niveles, a menudo denominada "defensa en profundidad," no sólo segura una capa, pero tener en cuenta todo el sistema.

La consideración más obvia primera es la seguridad física del equipo que ejecuta SQL Server, este nivel, sin embargo, se pasa por a menudo alto o es el asunto de complacencia. No me hace referencia sólo si se puede robar el equipo o no, sino también el acceso físico a cosas como el sistema de almacenamiento alojamiento de los archivos de base de datos, las cintas de copia de seguridad y los servidores que alojan copias redundantes de la base de datos. Únicamente las personas con una necesidad real físicamente táctil estos objetos deben tener acceso a ellos; usuarios que necesiten acceso temporal se deben acompañado y supervisar.

Una consideración menos obvia es la seguridad de los escritorios de las personas que tienen acceso con privilegios alta a SQL Server. Si alguien tiene acceso de sysadmin a SQL Server pero dejar su escritorio de Windows sin bloquear, a continuación, toda la seguridad en el mundo no será para evitar que alguien análisis más allá del sistema desatendido potencialmente tenga acceso a datos confidenciales. Un problema más insidioso si alguien recorre tengan y sería cambiado algunos datos, por ejemplo, un empleado dishonest que conozca el esquema de la base de datos de recursos humanos y intenta undetectably cambie un salario.

Hay un muy interesante TechNet documento titulada (incluidos un lote de la diapositiva y webcasts) " Seguridad física de Microsoft" que describen cómo Microsoft administra la seguridad física de sus muchos servidores.

Seguridad de red

Aunque los servidores pueden ser inaccesibles físicamente, lo más probable es que está conectados a una red de algún tipo. Esto podría ser sólo una aislado compañía LAN con no fuera de las conexiones, o puede ser una conexión directa a Internet. Independientemente de que la situación, hay algunas cosas que debe tener en cuenta:

• Asegúrese de que el servidor de Windows tiene seguridad de red correcta configurada.
• Decidir qué protocolos de red para permitir y deshabilitar cualquiera que no sean necesarios.
• Asegúrese de que hay un conjunto de servidor de seguridad copia (por ejemplo, Firewall de Windows) y configurarlo para permitir el acceso a SQL Server (como se muestra en La figura 1 ).
• Decida si desea cifrar las conexiones a SQL Server y configurar correctamente.
• Si se va a utilizar Kerberos, registrar un nombre principal del servidor. Kerberos es un mecanismo de autenticación que underpins autenticación de Windows (que describen más adelante en este artículo), pero se entiende mal. Una explicación clara y concisa proporcionó Greene, un ingeniero de escalado de soporte técnico, en la entrada de blog de Rob" Kerberos para el administrador de disponibilidad." SE recomienda desprotegerlo.
• Decida si desea utilizar el servicio de SQL Server Browser para ayudar a los clientes buscar instancias de SQL Server instaladas y decida si desea ocultar algunos casos. Ocultar una instancia significa que las aplicaciones cliente y los usuarios se necesitan conocer los detalles de conexión de la instancia de SQL Server, pero impide que las personas trawling la red para buscar instancias de SQL Server.

Figura 1 configurar Firewall de Windows para permitir el acceso TCP a SQL Server

Todas estas tareas y más se explican en SQL Server 2008 Books Online, comenzando por el tema Configuración de red de servidor. También hay una sección buena en Configuración de red de cliente.

Minimization superficie de ataque

Los servicios más y características que estén habilitadas, más área de superficie o superficie hay malos a un ataque de ataque. SQL Server 2005 tardó el "desactivado de forma predeterminada" estrategia, las características con las implicaciones de seguridad están deshabilitadas de forma predeterminada y sólo se habilitan por el administrador cuando sea necesario. (Este proceso de habilitación y deshabilitación de servicios normalmente se denomina configuración de área de superficie).

Un ejemplo de principal de una característica que desea deshabilitada es xp_cmdshell, que proporciona una forma de ejecutar comandos en el sistema de Windows desde dentro del contexto de una instancia SQL Server de host. Si un compromisos intruso la instancia de SQL Server y la cuenta de servicio de SQL Server tiene elevados privilegios de Windows, xp_cmdshell pueden utilizarse para obtener acceso al sistema de Windows, demasiado.

Hay una gran variedad de métodos de configuración de área de superficie. SQL Server 2005 y SQL Server 2008 admiten el Administrador de configuración de SQL Server para configurar servicios y protocolos de red. Ambos también admiten el procedimiento almacenado sp_configure para configurar características del motor de base de datos y opciones. Por ejemplo, este código deshabilitar la característica xp_cmdshell:

-- To allow advanced options to be changed
EXEC sp_configure 'show advanced options', 1;
GO
-- To update the currently configured value for -- advanced options
RECONFIGURE;
GO
-- To disable xp_cmdshell
EXEC sp_configure 'xp_cmdshell', 0;
GO
-- To update the currently configured value for this -- feature
RECONFIGURE;
GO

Los métodos gráficos de configurar las opciones del motor de base de datos y las características son muy diferentes entre las dos versiones. SQL Server 2005 se abrieron la herramienta SQL Server superficie área Configuration (SAC). Esto permite fácilmente realizar cambios. la figura 2 , por ejemplo, se muestra cómo se puede deshabilitar xp_cmdshell mediante SAC.

La Figura 2 xp_cmdshell deshabilitar mediante SAC en SQL Server 2005

En SQL Server 2008, SAC se ha quitado por completo y la funcionalidad incluida por la característica de administración basada en directivas. Puede encontrar más información sobre esto en el tema de Libros en pantalla de SQL Server 2008" Administrar los servidores mediante la administración basada en directivas." la figura 3 ilustra la creación de una condición para comprobar que xp_cmdshell está deshabilitado. Una vez configurado, las directivas pueden dirigir instancias de SQL Server 2005 y SQL Server 2008 y incluso se pueden "aplicar," lo que permite básicamente, cambiar la configuración con un solo clic.

La figura 3 crear una condición de administración basada en directivas en SQL Server 2008

Cuentas de servicio

SQL Server se ejecuta como uno o varios servicios en Windows y cada uno de los servicios necesita tener una cuenta de Windows que se utiliza para ejecutar el servicio. La cuenta debe tener acceso a diversos recursos en el sistema de Windows (como la red y distintos directorios de sistema de archivos). Se recomienda para que la cuenta que el mínimo posibles privilegios necesarios para permitir que SQL Server funcionar correctamente. Esto forma parte de lo que se denomina el principio de privilegio mínimo, los estados que un sistema se puede realizar más proteger mediante la concesión de un usuario o proceso sólo los privilegios necesarios y nada más.

Como una cuenta de servicio de SQL Server debe no ser una cuenta de alta con privilegios (como sistema local o administrador local) porque si SQL Server se ve comprometida, existe la posibilidad de que el sistema de Windows también estar en peligro. Los servicios normalmente se ejecutan bajo una cuenta integrada denominada Servicio de red, pero si SQL Server requiere acceso a otros recursos del dominio, una nueva cuenta de usuario de dominio debe crearse con los privilegios mínimos y recurso acceso requerido. Los libros en pantalla de SQL Server 2008 topic" Configuración de cuentas de servicio de Windows"proporciona una lista completa de las cuentas de servicio, los privilegios necesarios y recursos. Tenga en cuenta que si debe cambiar una cuenta de servicio (o nada sobre ella), debe utilizar el Administrador de configuración de SQL Server siempre para asegurarse de que todos los cambios necesarios de configuración se hacen correctamente.

Restringir el uso de privilegios de administrador

El inicio de sesión de exposición de la asociación de seguridad más o la función fija de servidor sysadmin tiene, el potencial de más que hay una infracción de seguridad, o un accidente. Hay algunas recomendaciones para seguir.

Reducir el número de personas que tienen acceso a la cuenta de administrador del sistema y restringir la pertenencia a la función sysadmin (y otras funciones con privilegios) por lo que únicamente las personas que realmente necesitan privilegios de sysadmin tienen ellos. No dar salida la contraseña de SA cualquier persona que desea tener acceso temporal a SQL Server o a un usuario SQL que desea realizar alguna tarea rápido. En estas situaciones, cree un nuevo inicio de sesión SQL y conceda el privilegio es necesario.

Es mejor que personas como miembros de la función sysadmin en lugar de utilizar la cuenta de administrador del sistema. De este modo, puede quitar de inicio de sesión un usuario sin tener que cambiar la contraseña de cuenta de SA. Si tomar el control un servidor antiguo y no tiene idea que tenían acceso a ella antes, cambiar la contraseña de SA por lo que es de control.

Un problema que provokes debate es si se debe quitar el grupo de Windows Builtin/Administradores de la función sysadmin (se agrega de forma predeterminada). ¿Un administrador de Windows debe poder consultar la base de datos HR? ¿O su compañía confiar explícitamente todos los administradores tener integridad y honesty? Si decide quitar, continúe con cuidado. Esto es especialmente cierto en un entorno agrupado donde si no realice los pasos correctos, el servidor SQL Server es posible que no iniciará. Para obtener más información sobre este y otros problemas de organización por clústeres, vea el artículo de Knowledge Base" Dos clústeres de servidor SQL, Don'ts y advertencias básicas."

Anime a para quienes tienen acceso de administrador del sistema, no para iniciar sesión con privilegios de altos, a menos que sea absolutamente necesario, dar a cada uno de estos inicios de sesión de usuarios dos, uno con privilegios y uno no. Con la cuenta sin privilegios de forma predeterminada ayuda a minimizar la posibilidad de errores costosos y también reduce la probabilidad de que un desbloqueada Windows Terminal Server tendrán una ventana con privilegios de sysadmin abrir en el. Recuerde: defensa en profundidad.

El último punto que se realice aquí es evitar que las aplicaciones que requieren privilegios de sysadmin. Desgraciadamente, esto es una práctica errónea común y inevitable con algunas aplicaciones, pero debe evitar en este ejercicio en aplicaciones propios y se quejan de los desarrolladores de aplicaciones que requieren privilegios de sysadmin.

Autenticación

Hay dos modos de autenticación disponibles: autenticación de Windows y el modo mixto (que es la autenticación de Windows combinada con autenticación de SQL Server).

Autenticación de Windows utiliza cuentas de red y dominio para validar la cuenta de Windows que se utiliza para conectarse a SQL Server. Si está seleccionada esta opción durante la instalación, la cuenta de administrador del sistema es creada con una contraseña generada aleatoriamente pero se deshabilitado de forma eficaz. Inmediatamente después de la instalación, se debe cambiar la contraseña de asociación de seguridad a una contraseña segura y segura pero seguir dejar la cuenta deshabilitada a menos que sea absolutamente necesario.

Autenticación de SQL Server se basa en cada usuario con una cuenta de SQL Server y la contraseña almacenada en SQL Server definido. Y, por supuesto, esto significa que la cuenta de administrador del sistema está habilitada y debe tener definida una contraseña. Con la autenticación de SQL Server, los usuarios tienen al menos dos nombres de usuario y contraseñas (una para la red) y otra para SQL Server. Generalmente se recomienda que sólo utilice la autenticación de Windows cuando sea posible, ya que es una solución más segura. El tema de libros en línea" Elegir un modo de autenticación"explica Esto detalladamente, junto con cómo cambiar el modo de autenticación.

Si se utiliza la autenticación de SQL, a continuación, todos los usuarios deben tener una contraseña segura, que es bastante compleja para ser resistente a la que se va a adivinarse con un programa de averiguación de contraseñas. Esto es especialmente importante para las cuentas con privilegios alta, como asociación de seguridad y miembros de la función sysadmin. (Uno de los más comunes aún peor prácticas se utiliza para poder tener una contraseña SA en blanco. Afortunadamente, como de SQL Server 2000 SP3, no es posible.)

Las contraseñas también se deben cambiar regularmente y su compañía debe publicar las directivas corporativas para ayudar a los empleados a utilizar contraseñas seguras y seguras recomendaciones. Para obtener información general de prácticas recomendadas para crear y protección de contraseña segura, vea el artículo" Las contraseñas seguras: cómo crear y utilizar ellos." Puede incorporar estas directivas en una directiva corporativa.

Si SQL Server 2005 o SQL Server 2008 se ejecuta en Windows Server 2003 o posterior, puede hacer uso de Windows mecanismos de directiva de contraseña para aplicar directivas de complejidad y caducidad. La sección de libros en pantalla de SQL Server 2008 se denomina" Directiva de contraseñas"tiene información sobre la compatibilidad con contraseñas seguras y varias directivas de contraseñas en SQL Server.

Autorización

Como ya he mencionado, uno de los principios de proteger los sistemas es utilizar el principio de privilegio mínimo. Mientras se aplica directamente a privilegios de nivel de administración, también se aplica a los permisos para usuarios de base de datos normal. Un usuario en una base de datos (probablemente) no debe poder obtener acceso a los datos de otra base de datos. El propietario de un conjunto de tablas no debe ser capaz de estropear con las tablas de otra persona. Los usuarios deben sólo poder tener acceso a los datos que se supone para tener acceso a, y incluso entonces debe sólo ser capaz de realizar las acciones necesarias en los datos (por ejemplo, SELECT, pero no UPDATE o DELETE).

Todo esto puede realizarse dentro de SQL Server mediante un sistema de permisos jerárquico, completa donde los usuarios o funciones (denominadas entidades) se concede o deniega determinados permisos específicos de ciertos recursos (denominadas entidades asegurables) como un objeto, esquema o base de datos. En la figura 4 se muestra una visión general de la jerarquía de permisos de SQL Server. Esto también implica que siga el principio de privilegio mínimo. Por ejemplo, no hacer que todos los miembros de los desarrolladores de la función db_owner de base de datos. Restringir permisos a la función pública y sólo conceder permisos al nivel más bajo (usuario o función) para reducir el acceso directo. Una explicación completa de prácticas recomendadas de permisos se sale del ámbito de este artículo, pero los libros en pantalla de SQL Server 2008 incluye una sección denominada" Identidad y control de acceso (motor de base de datos)"que ofrece niveles explorar en profundidad en los conceptos.

La figura 4 jerarquía de permisos del servidor de SQL

Para permitir permisos más granulares y mejor separación de funciones dentro de una base de datos, SQL Server 2005 se abrieron separación de usuario y esquema, donde los esquemas son independientes de los usuarios de la base de datos y son simplemente contenedores de objetos. Esto permite muchos cambios comportamientos, incluida más precisión específicos para la administración de permisos. (Cuatro nombres sigue la server.database.schema.object formato en SQL Server 2005 y SQL Server 2008, el formato era anteriormente server.database.owner.object.)

Por ejemplo, se puede crear un esquema con desarrolladores de base de datos dados permisos de CONTROL. Puede CREATE, ALTER y DROP cualquiera objetos dentro de los esquemas controlan pero no tienen permisos implícitos para los otros esquemas dentro de la base de datos y ya no necesitan derechos de db_owner para bases de datos desarrollo. Además, separación de usuario y esquema permite a los usuarios de base de datos eliminarse sin necesidad de recode todos los objetos relacionados o la aplicación con un nuevo nombre de usuario, los objetos son miembros de un esquema y ya no están vinculados al creador del objeto.

Es una práctica recomendada utilizar esquemas para la propiedad del objeto debido a estas razones. Puede encontrar más información en los libros en pantalla de SQL Server 2008 en el tema" Separación de esquema de usuario."

Otra manera de impide que los usuarios hacer las cosas que no se supone que para hacer es impedir el acceso directo a las tablas base. Esto puede realizarse mediante procedimientos almacenados y funciones que se utilizan para encapsular, control y aislar operaciones al igual que las actualizaciones y eliminaciones y al proporcionar vistas que permiten controlada y óptimo selecciona.

Inserción de SQL

Uno de los métodos más comunes de obtener acceso no autorizado a los datos es utilizar un ataque de inserción de SQL. Inserción de SQL puede adoptar muchas formas, pero aprovecha el enfoque principal de código que usa cadenas dinámicamente construidas y "inserta" código inesperado en la construcción. Por ejemplo, el ataque de inserción siguiente aprovecha lógica mal escrita para validar la entrada del usuario a SQL Server truco en acepta entrada mediante la inclusión de caracteres de escape en la cadena de entrada. Aunque contrived, en este ejemplo se resalta lo que puede ocurrir cuando código dinámicamente crea cadenas utilizando la entrada que no se valida minuciosamente:

DECLARE @password VARCHAR (20);
DECLARE @input    VARCHAR (20);
DECLARE @ExecStr  VARCHAR (1000);

SELECT @password = 'SecretSecret';

-- assume application gets input 'OR''='
SELECT @input = '''OR''''=''';

SELECT @ExecStr = 'IF ''' + @password + ''' LIKE ''' + @input + ''' PRINT ''Password Accepted''';

EXEC (@ExecStr);
GO

Si ejecuta este código, imprimirá la frase "contraseña aceptado" incluso si la entrada del usuario claramente no coincide con la cadena de contraseña. La entrada del usuario contiene una secuencia de escape que cambiar la lógica Transact-SQL, ya que la entrada se analiza y protegida no correctamente.

Inyección de SQL no debe ser un problema de una aplicación bien escrito y hay algunos trucos específicos (como usar QUOTENAME para identificadores delimitados). Pero si se hereda una aplicación antigua (o quizás un proyecto de homebrew que pasaron al estado una aplicación de empresa), debe probar específicamente para comprobar si es vulnerable a los ataques de inyección de SQL. Hay una gran variedad de técnicas disponibles para mitigar los ataques de inserción de SQL. Los libros en pantalla de SQL Server 2008 tiene una sección completa, comenzando por el tema acertadamente con nombre" Inserción de SQL."

Recuperación ante desastres

¿Cuánto se necesita preocuparse por esto depende de ¿cuáles son los requisitos de pérdida de tiempo de inactividad y datos. (Si ya no ha definido estos requisitos, deberá!) Pueden producirse problemas de seguridad en muchos niveles. Hay algunos problemas de recuperación ante desastres implica la conmutación por error a otro servidor SQL Server o la necesidad de restaurar una base de datos que contiene datos cifrados.

En el primer caso, problemas se producen cuando los inicios de sesión debe tener acceso a la base de datos no ha duplicado en el servidor de conmutación por error, por ejemplo, cuando uso trasvase de registros o creación de reflejos de bases de datos. Si la base de datos conmuta a la instancia reflejada y la aplicación intenta conectarse mediante un inicio de sesión específico que no existe en el servidor reflejado, la aplicación recibirá el error 18456 inicio de "sesión error". Los inicios de sesión forman parte de la ecosistema de aplicaciones y deben definirse en la instancia de la base de datos. Artículo de Knowledge Base 918992" Cómo transferir los inicios de sesión y las contraseñas entre instancias de SQL Server 2005" se explica cómo hacer esto, y se describa error solución de problemas 18456 en un momento.

En el segundo caso, problemas se producen cuando la copia de seguridad de la base de datos contiene datos cifrados y el cifrado de clave (o claves) utiliza para cifrar los datos no se realizó o no disponibles en la instancia de SQL Server en la base de datos se haya restaurado. El mejor caso aquí es que sólo algunos de los datos de la base de datos está cifrada y no se puede obtener acceso a tan sólo ese subconjunto de datos. El peor escenario de caso es que toda la base de datos se se cifran utilizando cifrado transparente de datos (TDE) en SQL Server 2008. En ese caso, si el certificado de servidor utilizado para proteger la clave de cifrado de base de datos no se realizó una copia de seguridad o no está disponible, no se puede restaurar toda la base de datos y se devolverán los siguientes errores:

Msg 33111, Level 16, State 3, Line 1
Cannot find server certificate with thumbprint
'0xFBFF1103AF133C22231AE2DD1D0CC6777366AAF1'.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.

Por supuesto, que es el punto de TDE, que alguien sucede a través de una copia de seguridad queden de la base de datos cifrado no se puede restaurarla y obtener acceso a los datos confidenciales. Pero si los datos están suya y necesite tener acceso a él, a continuación, debe tener el certificado de servidor disponible o los datos se pierden.

Cifrado es un tema enorme en sí y tiene cobertura completa en 2008 los libros en pantalla de SQL Server, comenzando por la " Cifrado de SQL Server"sección. También puede ver mi Demuestre TDE y restaurar correctamente a una instancia de segunda en un screencast de vídeo que lo acompaña disponible en .com y sugerencias.

Auditoría

Una de las cosas más importantes que debe hacer para mejorar la seguridad de un sistema es implementar la auditoría. Con esto, sabrá que realiza lo. Incluso puede ser obligatoria, según la naturaleza de su negocio.

Como mínimo, debería auditar los inicios de sesión con errores y correcta que le puede saber si, por ejemplo, cinco intentos de inicio de sesión se han seguido una correcta. Sabrá cuándo alguien está intentando salto en la instancia de SQL Server (y con el inicio de sesión). la figura 5 muestra la configuración de auditoría de inicio de sesión mediante el cuadro de diálogo Propiedades de servidor en SQL Server 2005 Management Studio. Se auditan los inicios de sesión con errores como mensaje 18456 en el registro de errores y el estado de error proporciona el motivo del error. La descripción mejor que encontró de los distintos estados, así como una explicación mucho acerca de la solución, es de una entrada de il-sung lee en el blog de SQL protocolos titulado" Mensajes de error de conocimiento 'conexión que no se Pudo' (error 18456) en SQL Server 2005."

La figura 5 Confi inicio de sesión de guring auditoría en SQL Server 2005 Management Studio

Auditoría completa de todas las acciones es difícil en SQL Server 2005 (y allá del ámbito de este artículo). Implica varios desencadenadores y rastreo de SQL. En SQL Server 2008, auditoría se enormemente simplificó con la introducción de una nueva característica: auditoría de SQL Server. Esto se trata en un reciente y muy detallada documento titulada" Auditoría de SQL Server 2008." En el vídeo screencast adjunta, muestran auditoría de SQL Server. Puede obtener detalles acerca de las otras herramientas de auditoría en los libros en pantalla de SQL Server 2008" Auditoría (motor de base de datos)"sección.

Resumen

Es una gran cantidad de los temas y de un lote de los vínculos, pero que es el punto de este artículo. Deseaba ofrecer una visión general de los temas de seguridad importantes que debe tener en cuenta cuando se encuentre un DBA que no se utiliza para tratar con la seguridad.

Hay algunas herramientas que pueden ayudarle a proteger el sistema para vulnerabilidades de seguridad frecuentes. El primero es la utilidad Microsoft Baseline Security Analyzer (MBSA) que se comprueban para Windows, red, sistema de archivos y incluso algunos problemas de seguridad de SQL Server 2000 y SQL Server 2005. La versión más reciente es Microsoft Baseline Security Analyzer 2.1. Nuevo para SQL Server 2000 y SQL Server 2005 sólo, hay una herramienta SQL Server–specific denominada el Best Practices Analyzer(BPA). Esto utiliza una lista predefinida de reglas para comprobar la configuración de SQL Server y marca los problemas (por ejemplo, una contraseña de SA en blanco).

Ninguna de estas herramientas funciona con SQL Server 2008. De hecho, BPA, no se libera para SQL Server 2008 en absoluto y se ha reemplazado, junto con la herramienta de configuración del área de superficie de SQL Server 2005 efímeras, por la nueva característica de administración basada en directivas que se explicó anteriormente. Parte de la razón de este reemplazo es que BPA y SAC eran herramientas de sólo lectura para ayudarle a encontrar problemas, no puede corregir los problemas. Administración basada en directivas ofrece muchas opciones de corrección y incluso puede utilizarse para servidores de SQL Server 2000 y SQL Server 2005 de destino.

Por supuesto, debería siempre utilizar Windows Update para asegurarse de que las nuevas revisiones de seguridad y service packs se descargan para que pueda instalar en un momento adecuado, ésta es la mejor forma para mantenerse al día con las actualizaciones más recientes. Instalar estos sin tomar tiempo de inactividad es fuera del alcance de este artículo, pero algunas ideas se presentaron en la Columna de preguntas y respuestas de SQL de diciembre de 2006.

Si está tratando de encontrar los recursos generales de Microsoft en seguridad, hay varios destinos que aparecerán en el motor de búsqueda favorito. Para guardar, haciendo clic alguna vez en alrededor, le sugiero dos documentos claves del producto que debe leer.

" SQL Server 2005 seguridad más Practices–Operational y tareas administrativas"y" SQL Server 2008: información general de sobre seguridad para administradores de bases de datos."

Para SQL Server 2005, el punto de entrada en la sección seguridad de los libros en pantalla es el tema" Consideraciones de seguridad para bases de datos y aplicaciones de bases de datos." Para SQL Server 2008, el punto de entrada de los libros en pantalla equivalente es la " Seguridad y protección (motor de base de datos)."

Lo que se respecta takeaways desde este artículo, me gustaría tener en cuenta que hay algunos pasos que debe pasar por para garantizar los datos que va a almacenar en SQL Server están tan seguro como sea necesario para que sea. Esto es especialmente importante cuando se hereda una instancia de SQL Server que alguien administrando. Es igual que comprar una casa de alguien, tiene que preguntar si la alarma funciona, si el metro es fenced en, y que tiene copias de las claves. Ejecución por la lista que ha proporcionado en este artículo es un buen comienzo, pero asegúrese de que cavar más profunda en áreas que son relevantes para el. Y como siempre, si tiene los comentarios o preguntas, colocar me una línea en Paul@SQLskills.com.

Paul S. Randal es el director de administración de SQLskills.com y un MVP de SQL Server. Trabajado en el equipo de motor de almacenamiento de SQL Server en Microsoft desde 1999 a 2007. Paul escribió DBCC CHECKDB y reparar para SQL Server 2005 y era responsable del motor de almacenamiento principal durante el desarrollo de SQL Server 2008. Paul es un experto en recuperación ante desastres, alta disponibilidad y mantenimiento de la base de datos y un moderador habitual en conferencias de todo el mundo. Blogs en SQLskills.com/blogs/paul.