SQL Server NOLOCK sur les requêtes exécutées pour autorisation

Question

Au cours de la connexion à notre application, plusieurs requêtes ont été exécutées, tout autour de la validation de la connexion. En les évaluant, j'ai remarqué qu'une des requêtes est exécutée sans l'indice NOLOCK.

Il ne semble pas y avoir de danger particulier de lecture sale, car les données ne changeraient presque jamais.

En y pensant après une tentative d’attaque de type DOS par une personne tentant maintes fois d’identifier des connexions, je suggère que le manque de NOLOCK abaisse notre seuil d’échec.

Je pense que c’est un résultat extrêmement improbable d’une attaque par le DOS (je pense que le serveur Web passerait en premier), mais l’ajout de NOLOCK devrait permettre de passer de peu probable à impossible.

Alors, suis-je excessif ou trivial?

Answer 1

Avoir NOLOCK ou non est le moindre de vos soucis avec une tentative de DoS contre votre serveur.

Je ne voudrais pas transpirer.

Si, comme vous le dites, les données changent rarement, le fait d'avoir les NOLOCK là-bas ne fait probablement pas de mal.

Answer 2

Oui, vous êtes excessivement trival.

Si vous êtes exposé à des attaques par le DOS, NOLOCK lors de l’appel d’autorisation SQL est le moindre de vos soucis. Implémentez des fonctions de détection DOS, de suivi des pannes et d’accélération, voire des pauses planifiées qui n’affecteraient pas l’utilisateur mais ralentiraient une attaque ...

Answer 3

NOLOCK peut potentiellement améliorer vos performances si vous appelez cette requête fréquemment, en particulier dans les transactions plus larges.

Considérez la nature de la lecture sale - la fenêtre temporelle où cela peut-il se produire est-elle vraiment critique? par exemple. où vous ajoutez ou supprimez une personne d'un rôle autorisé.

Dans le scénario d'ajout, une lecture incorrecte échouerait lors de cette tentative. (accès refusé)

Dans le scénario de suppression, une lecture corrompue fonctionnerait avec cette tentative. (accès autorisé)

Si les données changent manuellement, par ex. interaction humaine - leur marge de " latence " est généralement beaucoup plus élevé / indéterminé que vos bases de données!

Answer 4

Également un cas très rare, mais toujours: au moment où quelqu'un désactive l'utilisateur pour l'empêcher de se connecter, NOLOCK le laisse entrer. Peut-être un utilisateur / pirate / employé voyou qui doit être immédiatement verrouillé? / p>

Vous devez vous préoccuper de ce scénario pour renoncer à l'avantage de performance de NOLOCK.

Answer 5

Vous protégeriez beaucoup mieux votre table en examinant ses autorisations. Une table comme celle-ci ne devrait autoriser aucun accès direct, tous les accès devraient provenir de procédures stockées et des autorisations définies à leur place.