SQL Server NOLOCK en consultas ejecutadas para autorización

Question

Durante el inicio de sesión de nuestra aplicación, se ejecutaron varias consultas para validar el inicio de sesión. Al evaluarlos, noté que una de las consultas se ejecuta sin la sugerencia NOLOCK.

No parece haber ningún peligro particular de lectura sucia porque los datos casi nunca cambiarían.

Pensando en ello desde un intento de ataque de tipo DOS por alguien que intentaba inicios de sesión fallidos una y otra vez, sugiero que la falta de NOLOCK reduce nuestro umbral de falla.

Creo que es un resultado extremadamente improbable de un ataque de DOS (creo que el servidor web sería el primero), pero agregar NOLOCK debería hacer que sea poco probable a imposible.

Entonces, ¿estoy siendo excesivo o trivial?

Answer 1

Tener NOLOCK o no es la menor de sus preocupaciones con un intento de DoS contra su servidor.

No lo sudaría.

Si, como usted dice, los datos rara vez cambian, tener los NOLOCK allí probablemente no duela.

Answer 2

Sí, estás siendo excesivamente trival.

Si está expuesto a ataques DOS, NOLOCK en la llamada de autorización SQL es la menor de sus preocupaciones. Implemente alguna detección de DOS, seguimiento de fallas + acelerador, incluso algunas pausas planificadas que no afectarían al usuario pero retrasarían un ataque ...

Answer 3

El NOLOCK podría potencialmente mejorar su rendimiento si llama a esa consulta con frecuencia, especialmente en transacciones más amplias.

Considere la naturaleza de la lectura sucia: ¿la ventana de tiempo donde eso puede ocurrir es realmente crítica? p.ej. donde agrega o elimina a alguien de un rol autorizado.

En el escenario de agregar, una lectura sucia fallaría en ese intento. (acceso denegado)

En el escenario de eliminación, una lectura sucia funcionaría en ese intento. (acceso concedido)

Si los datos cambian a través de la operación manual, p. interacción humana: su margen de "latencia" es típicamente mucho más alto / indeterminado que sus bases de datos!

Answer 4

También es un caso muy raro, pero aún así: justo en el momento en que alguien desactiva al usuario para evitar que inicien sesión, NOLOCK los deja entrar. ¿Podría ser un usuario / hacker / empleado deshonesto que necesita ser bloqueado inmediatamente?

Tendría que preocuparse por este escenario particular para renunciar a la ventaja de rendimiento de NOLOCK.

Answer 5

Protegería su tabla mucho mejor al ver los permisos que tiene. Una tabla como esta no debe permitir ningún acceso directo, todo el acceso debe ser de procesos almacenados y los permisos establecidos en ellos.