SQL Server NOLOCK su query eseguite per l'autorizzazione
https://stackoverflow.com/questions/284163
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianDomanda
Nel corso dell'accesso alla nostra applicazione sono state eseguite diverse query, che convalidano il login. Nel valutarli ho notato che una delle query viene eseguita senza il suggerimento NOLOCK.
Non sembra esserci alcun pericolo particolare di lettura sporca perché i dati non cambieranno quasi mai.
Ripensandoci da un tentativo di attacco di tipo DOS da parte di qualcuno che tenta ripetutamente accessi non riusciti, sto suggerendo che la mancanza di NOLOCK abbassa la soglia di errore.
Credo che sia un risultato estremamente improbabile di un attacco DOS (penso che il server web andrebbe per primo) ma l'aggiunta di NOLOCK dovrebbe far passare da improbabile a impossibile.
Quindi, sono eccessivo o banale?
Soluzione
Avere NOLOCK o meno è l'ultima delle tue preoccupazioni con un tentativo DoS contro il tuo server.
Non vorrei sudare.
Se, come dici tu, i dati cambiano raramente, avere i NOLOCK lì probabilmente non fa male.
Altri suggerimenti
Sì, sei eccessivamente trivalente.
Se sei esposto ad attacchi DOS, NOLOCK nella chiamata di autorizzazione SQL è l'ultimo dei tuoi dubbi. Implementa un po 'di rilevamento DOS, tracking degli errori + acceleratore, anche alcune pause pianificate che non influirebbero sull'utente ma rallenterebbero un attacco ...
Il NOLOCK potrebbe potenzialmente migliorare le tue prestazioni se chiami quella query frequentemente specialmente nelle transazioni più ampie.
Considera la natura della lettura sporca - la finestra temporale in cui ciò può accadere sarebbe veramente critica? per esempio. dove aggiungi o rimuovi qualcuno da un ruolo autorizzato.
Nello scenario di aggiunta una lettura sporca fallirebbe in quel tentativo. (accesso negato)
Nello scenario di rimozione una lettura sporca avrebbe funzionato su quel tentativo. (accesso concesso)
Se i dati cambiano tramite l'operazione manuale, ad es. interazione umana - il loro margine per "latenza" è in genere molto più alto / indeterminato dei tuoi database!
Anche un caso molto raro, ma comunque: proprio nel momento in cui qualcuno disattiva l'utente per impedirgli di accedere, NOLOCK lo lascia entrare. Potrebbe essere un utente / hacker / dipendente disonesto che deve essere bloccato immediatamente?
Dovresti essere preoccupato per questo particolare scenario per rinunciare al vantaggio prestazionale di NOLOCK.
Proteggi il tuo tavolo molto meglio esaminando le autorizzazioni ad esso. Una tabella come questa non dovrebbe consentire alcun accesso diretto, tutti gli accessi dovrebbero provenire da processi memorizzati e le autorizzazioni impostate su di essi.
