SQL Server NOLOCK для запросов, выполняемых для авторизации

Question

Во время входа в наше приложение было выполнено несколько запросов, все вокруг проверки имени входа. Оценивая их, я заметил, что один из запросов выполняется без подсказки NOLOCK.

Кажется, что нет особой опасности грязного чтения, потому что данные вряд ли когда-либо изменятся.

Думая об этом из-за попытки атаки типа DOS, предпринятой кем-то снова и снова при неудачных входах в систему, я предлагаю, чтобы отсутствие NOLOCK понизило наш порог неудачи.

Я считаю, что это крайне маловероятный результат атаки DOS (я думаю, что веб-сервер пойдет первым), но добавление NOLOCK должно сделать переход от маловероятного к невозможному.

Итак, я чрезмерный или банальный?

Answer 1

Наличие или отсутствие NOLOCK - это наименьшее беспокойство при попытке DoS на вашем сервере.

Я бы не стал потеть.

Если, как вы говорите, данные редко изменяются, то наличие там NOLOCK, вероятно, не повредит.

Answer 2

Да, вы чрезмерно притягательны.

Если вы подвержены атакам DOS, NOLOCK при вызове авторизации SQL - это наименьшее из ваших беспокойств. Реализовать некоторое обнаружение DOS, отслеживание ошибок + управление, даже некоторые запланированные паузы, которые не влияют на пользователя, но замедляют атаку ...

Answer 3

NOLOCK потенциально может улучшить вашу производительность, если вы часто вызываете этот запрос, особенно в более широких транзакциях.

Рассмотрите природу грязного чтения - действительно ли временное окно, в котором это может произойти, будет действительно критическим? например где вы добавляете или удаляете кого-то из авторизованной роли.

В сценарии добавления грязное чтение завершится неудачно при этой попытке. (доступ запрещен)

В сценарии удаления грязное чтение сработало бы при этой попытке. (доступ предоставлен)

Если данные изменяются в ручном режиме, например, человеческое взаимодействие - их запас для «латентности» обычно намного выше / неопределеннее, чем ваши базы данных!

Answer 4

Также очень редкий случай, но все же: как раз в тот момент, когда кто-то деактивирует пользователя, чтобы он не мог войти в систему, NOLOCK позволяет им войти. Может ли быть мошенником / хакером / сотрудником, которого необходимо немедленно заблокировать?

Вы должны быть обеспокоены этим конкретным сценарием, чтобы отказаться от повышения производительности NOLOCK.

Answer 5

Вы бы защитили свою таблицу намного лучше, посмотрев на разрешения для нее. Таблица, подобная этой, не должна разрешать прямой доступ, весь доступ должен осуществляться из хранимых процедур и вместо них должны быть установлены разрешения.