Implicaciones de seguridad y rendimiento de “ Ver el estado del servidor ”

No hay problemas de rendimiento importantes en los que pueda pensar al otorgar este permiso. Desde una perspectiva de seguridad, corre el riesgo de permitir que un usuario vea lo que la mayoría de los detalles sobre 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 apuntar a un ataque DoS contra su servidor.

¿Es esto posible? Definitivamente. ¿Probablemente? Me veo obligado a decir No, pero recuerde que se estima que el 90 por ciento de los ataques contra empresas provienen de atacantes internos.

Como administrador, vería esta información como si estuviera en su dominio (rendimiento / uso de índices / etc.) pero existen razones potencialmente convincentes por las que un desarrollador La organización de servicios querría esta información para un gran sistema heredado que admiten; por ejemplo, identificar tablas zombies que solo son tocadas por procesos de mantenimiento.

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 clara. 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 se acercan a sus posiciones con «hablar con la mano» como punto de partida.

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

Con respecto a:

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

En pocas palabras, pueden ver cosas que tal vez no deberían estar viendo. Y no piense en esto solo en términos de SQL Server. Este permiso en particular también rige DMV como sys.dm_os_sys_info y algunos otros que brindan información sobre la máquina host (hardware, servicios, etc.). No siempre sabes qué información se puede usar en tu contra. Y, 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 orientación sobre cómo evaluar si DEBE otorgarse o no.

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

1. Cree los procedimientos almacenados y / o los TVF de declaraciones múltiples para realizar las acciones deseadas.
2. Otorgue EXECUTE en estos módulos a cualquier usuario y / o roles que necesiten realizar estas acciones
3. Crear un certificado
4. Firmar los módulos usando ese certificado (usando ADD SIGNATURE)
5. Copie el certificado a la [master] base de datos (es decir, cree un certificado en [master] usando 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 cualquier instancia- nivel de permiso ns son necesarios para ese inicio de sesión basado en certificado (que puede incluir agregarlo a roles de nivel de instancia).

Para ver algunos ejemplos, consulte:

• Cómo mantener la propiedad de la base de datos restaurando ¿dominios?

• Utilice permisos de alto nivel de forma fácil y segura sin concederlos a nadie: nivel de servidor

Es un problema de seguridad. Nunca puedes equivocarte si sigue el Principio de menos privilegios . En otras palabras, si un principal de autenticación no « necesita un permiso en particular, entonces no» No se los dé. ¿Les da información sobre el tipo de cerraduras de su puerta a otras personas que no necesitan saber eso sobre su casa? Espero que no. Probablemente no harían nada, pero aún así no es prudente.

Si basáramos los principios de los datos en la suerte y la generosidad, estaríamos en problemas mucho más a menudo. La seguridad es un factor importante. aspecto en el que solo debes conceder cuando puedas defender por qué concediste. Simplemente le estás dando a alguien más información de la que necesita saber . No lo haga. El estado del servidor sigue siendo sensible.

Comentarios

• ¿Quién dice que lo está regalando innecesariamente? El OP podría necesitar otorgar que alguien investigue un problema específico (p. ej., para mirar sys.dm_db_missing_index_details) y que quieran saber cuáles son exactamente los riesgos de hacerlo.
• Supongo que ' Me falta la marca con esta pregunta, no ' no veo nada en la pregunta que indique la necesidad del permiso.
• @ThomasStringer: la pregunta no es ' t sobre necesidad, ' sobre riesgo . Para decirlo en términos monetarios, es posible que sepa a qué riesgos adicionales esto expondría sus servidores y, por lo tanto, podrá decir no a un centavo y sí a un millón de dólares. Yo no ' t, pero quiero hacerlo.