Implicaciones de seguridad y rendimiento de "Ver estado del servidor"

Esta pregunta señala que se requiere el permiso "Ver estado del servidor" para varios DMV (vistas de administración dinámica), pero no puedo encontrar nada sobre a quién se dirige y no desea otorgarle el permiso.

Ahora, por supuesto, entiendo los "permisos mínimos" y por qué no querrías otorgarlo a nadie, pero no puedo encontrar ninguna guía sobre cómo evaluar si DEBERÍA otorgarse o no.

Entonces, mi pregunta: ¿Cuáles son las implicaciones de seguridad y rendimiento de otorgar a un usuario el permiso "Ver estado del servidor". ¿Qué pueden hacer que tal vez no se les debería permitir hacer ...

Actualización : una de las implicaciones es que el usuario podrá usar DMV para ver consultas. Si las consultas o los parámetros de consulta pueden contener información confidencial que el usuario no podría ver de otra manera, permitir VIEW SERVER STATE les permitiría hacerlo (es decir, dob = o ssn =).

No se me ocurren problemas de rendimiento significativos al otorgar este permiso. Desde una perspectiva de seguridad, corre el riesgo de permitir que un usuario vea lo que más detalles acerca de sus puntos débiles, por ejemplo, un usuario malintencionado podría ver sus estadísticas de espera más comunes, lo que podría ayudarlo a atacar un ataque DoS contra su servidor .

es posible? Seguro. ¿Es esto probable? Me veo obligado a decir que no, pero recuerde que se estima que el 90 por ciento de los ataques contra empresas son de atacantes internos.

Como administrador, vería esta información como perteneciente a su dominio (rendimiento / uso del índice / etc.), pero existen razones potencialmente convincentes por las que una organización de desarrollo desearía esta información para un gran sistema heredado que admiten, identificando tablas de zombies que solo se tocan por procesos de mantenimiento, por ejemplo.

Al final, siempre termina siendo una cuestión de "suerte y generosidad", ya que la pregunta sobre si una solicitud en particular está justificada termina siendo una elección suave y no una fórmula crujiente. El uso de patrones de mejores prácticas sin mirar el contexto es en sí mismo un antipatrón bastante desagradable y la realidad es que muchos abordan sus posiciones con "hablar con la mano" como punto de partida.

Con respecto a las implicaciones de rendimiento, no conozco ninguna para este o cualquier otro permiso.

Respecto a:

¿Qué pueden hacer que tal vez no se les debería permitir hacer?

En pocas palabras, pueden ver cosas que tal vez no deberían estar viendo. Y no piense en esto en términos de solo SQL Server. Este permiso particular también rige los DMV como sys.dm_os_sys_info y muchos otros que proporcionan información sobre la máquina host (hardware, servicios, etc.). No siempre sabes qué información se puede usar en tu contra. E, incluso si está de acuerdo con que alguien vea todo lo permitido por este permiso ahora, a veces se agregan DMV en Service Packs / Actualizaciones acumulativas, por lo que tal vez se exponga una nueva información que no conoce.

No puedo encontrar ninguna guía sobre cómo evaluar si DEBERÍA otorgarse o no.

Como ya mencionó que debe otorgar a las personas los permisos mínimos necesarios, lo que realmente se reduce a esto es: ¿alguien necesita este permiso para el uso ad hoc ? Es decir, ¿alguien necesita la flexibilidad de formular sus propias consultas? ¿Funcionaría la creación de uno o más procedimientos almacenados y / o TVF de múltiples declaraciones? Si es así, no necesita otorgar permisos a ningún usuario (que luego es libre de cualquier cosa permitida por ese permiso), y en su lugar otorga los permisos al código (que solo hace lo que está codificado). La firma del módulo es cómo lograr esto. El concepto general es:

1. Cree los procedimientos almacenados y / o los TVF de varias instrucciones para realizar las acciones deseadas.
2. Otorgue EXECUTEen estos módulos a cualquier usuario y / o roles que necesite realizar estas acciones
3. Crear un certificado
4. Firme los módulos con ese certificado (usando ADD SIGNATURE)
5. Copie el certificado a la [master]base de datos (es decir, cree un certificado [master]utilizando la clave pública del certificado utilizado para firmar los módulos).
6. Cree un inicio de sesión desde el certificado copiado en [master]
7. Otorgue los permisos de nivel de instancia necesarios para ese inicio de sesión basado en certificado (que puede incluir agregarlo a roles de nivel de instancia).

Para algunos ejemplos, consulte:

• ¿Cómo mantener la restauración de la propiedad de la base de datos en todos los dominios?

• Use permisos de alto nivel de manera segura y fácil sin otorgarlos a nadie: nivel de servidor

Es un problema de seguridad. Nunca puedes equivocarte si sigues el Principio de los menos privilegiados . En otras palabras, si un principal de autenticación no necesita un permiso en particular, entonces no se lo dé. ¿Da información sobre el tipo de cerraduras en su puerta a otras personas que no necesitan saber eso sobre su casa? Espero que no. Probablemente no harían nada, pero todavía no es prudente.

Si basáramos los principios de datos en la suerte y la generosidad, estaríamos en problemas más grandes con bastante frecuencia. La seguridad es un aspecto en el que solo debe otorgar cuando puede defender por qué otorgó. Simplemente le está dando a alguien más información de la que necesita saber . No lo hagas El estado del servidor sigue siendo sensible.