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

Question

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

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

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

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

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

Answer 1

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

Я бы не потел.

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

Answer 2

Да, вас чрезмерно обманывают.

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

Answer 3

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

Answer 4

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

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

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

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

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

Answer 5

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

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