Como dicen las mejores prácticas de SQL Server , " el modo de autenticación de Windows es más seguro que la autenticación de SQL ". Y ahora quiero saber: ¿hay alguna manera de proteger SQL Server del usuario con derechos de administrador de Windows?
Como dicen las mejores prácticas de SQL Server , " el modo de autenticación de Windows es más seguro que la autenticación de SQL ". Y ahora quiero saber: ¿hay alguna manera de proteger SQL Server del usuario con derechos de administrador de Windows?
Respuestas:
No.
Si un usuario es un administrador de Windows de un cuadro, suponga que posee todo lo que contiene (incluido SQL Server). Con los derechos de administrador de Windows, es trivial eludir cualquier protección específica que aplique (como un desencadenador de inicio de sesión que identifique su nombre de usuario), al hacerse pasarNT AUTHORITY\SYSTEM
por otra persona (incluido , que obtiene derechos de administrador de facto en todas las instancias locales de SQL Server ). La auditoría tampoco ayudará mucho, porque pueden desactivarlo fácilmente, pero debe tenerlo por si acaso.
Si no confías en alguien, no le des derechos de administrador de Windows, punto.
No, no es posible evitar por completo que los administradores locales obtengan sysadmin
acceso a una instancia de SQL Server.
Si la instancia se reinicia en modo de usuario único , SQL Server está codificado para permitir sysadmin
privilegios de administradores locales , aunque no haya un inicio de sesión explícito. La razón por la que esto existe es para fines de recuperación porque es posible bloquear una instancia.
Dicho esto, restringir el acceso mientras la instancia se ejecuta en modo multiusuario (sin interrupciones del servicio) no es tan difícil. Como Aaron mencionó, los administradores locales pueden suplantar NT AUTHORITY\SYSTEM
, que por defecto tiene un sysadmin
inicio de sesión de nivel creado en SQL Server 2008. Esto se puede aprovechar para recuperar el sysadmin
acceso mientras el servidor está en ejecución. (Nota: en SQL Server 2012, este inicio de sesión ya no es a sysadmin
.) No sé exactamente para qué se utiliza este inicio de sesión (actualizaciones / correcciones urgentes / etc., presumiblemente), pero creo que es seguro deshabilitarlo excepto durante esos eventos Si no hay otros inicios de sesión suplantables, eso debería ser suficiente para denegar el acceso. Nuevamente, solo si la instancia se está ejecutando, sin interrupciones .
De manera predeterminada en SQL 2008 y 2012, no hay acceso predeterminado para los administradores de Windows a un servidor SQL. Para que un administrador de Windows (es decir, alguien que sea un Administrador de dominio o un Administrador local) tenga acceso, se debe otorgar acceso explícito a su inicio de sesión o al grupo al que pertenecen se les ha otorgado acceso junto con los derechos dentro del propio SQL Server. Al configurar la instancia, debe especificar un inicio de sesión o grupo de Active Directory como administrador, pero ese inicio de sesión / grupo puede ser cualquier persona en su dominio.
En SQL 2005, había un BUILTIN\Administrators
grupo con derechos de acceso de administrador del sistema. Este grupo permitiría a los administradores locales el acceso del administrador del sistema a SQL Server. Este grupo se puede eliminar de SQL Server y se consideró las mejores prácticas para hacerlo.
Dicho esto, no hay forma de evitar que Windows (local o de dominio) afecte al servidor en el que vive SQL Server. Esto significa que los administradores aún pueden afectar los servicios y las configuraciones a nivel del sistema operativo, cambiar la seguridad del directorio y otras tareas a nivel del sistema operativo. Esto es, después de todo, por qué son administradores de Windows.
En general, debe confiar en sus administradores, tanto SQL Server como Windows. Si bien los administradores de Windows no pueden realizar tareas o acceder a los datos (de manera predeterminada) dentro del propio SQL Server, aún controlan el entorno en el que vive su SQL Server. Debe tener cuidado con quién asigna a esos roles.