응용 프로그램 로그인 과정에서 여러 쿼리가 실행되어 로그인 유효성이 검사됩니다. 그들을 평가할 때 나는 질의 중 하나가 NOLOCK 힌트없이 실행된다는 것을 알아 차렸다.쿼리에 대한 SQL Server NOLOCK이 승인을 위해 실행됩니다.
데이터가 거의 변경되지 않기 때문에 더티 읽기의 특별한 위험은없는 것처럼 보입니다.
실패한 로그인 시도를 반복해서 시도한 시도 된 DOS 유형 공격에서 생각하면 NOLOCK이 부족하여 실패 임계 값이 낮아 졌음을 제안합니다.
도스 공격으로 인한 결과는 거의 없다고 생각합니다. (웹 서버가 먼저 나올 것이라고 생각합니다.)하지만 NOLOCK을 추가하면 불가능할 것 같지 않습니다.
그래서 나는 과도하거나 사소한 것입니까?
NOLOCK을 가지고 있거나 없으면 서버에 대한 DoS 시도에 대해 걱정할 필요가 없습니다.
나는 그것을 땀 나지 않을 것이다.
NOLOCK을 사용하면 데이터가 거의 변하지 않을 가능성이 있습니다.
매우 드문 경우이지만 여전히 : 사용자가 로그인하지 못하도록 차단하는 순간 NOLOCK이 허용됩니다. 즉시 잠글 필요가있는 불량 사용자/해커/직원 일 수 있습니까?
NOLOCK의 성능상의 이점을 피하려면이 특정 시나리오에 대해 걱정해야합니다.
특히 광범위한 트랜잭션에서 쿼리를 자주 호출하면 NOLOCK이 성능을 향상시킬 수 있습니다.
더티 읽기의 성격을 고려해보십시오. 시간 창문이 발생할 수있는 곳이 정말로 중요할까요? 예 : 승인 된 역할에서 누군가를 추가하거나 제거 할 수 있습니다.
추가 시나리오에서 더티 읽기는 해당 시도에서 실패합니다. (액세스가 거부 됨)
제거 시나리오에서 더티 읽기는 해당 시도에서 작동합니다. (액세스 권한 부여)
예를 들어 수동 조작으로 데이터가 변경된 경우. 인간과의 상호 작용 - 대기 시간 (latency)에 대한 마진은 일반적으로 데이터베이스보다 훨씬 높습니다.
예, 지나치게 과장합니다.
DOS 공격에 노출 된 경우 SQL 인증 호출에 대한 NOLOCK이 가장 걱정할 필요가 없습니다. 일부 DOS 탐지, 실패 추적 + 스로틀, 심지어는 사용자에게 영향을 미치지 않지만 공격 속도가 느려지는 일부 계획된 일시 중지를 구현하십시오.
당신은 당신의 테이블을 훨씬 더 잘 보호 할 수 있습니다. 이와 같은 테이블은 어떤 직접적인 접근도 허락해서는 안되며, 모든 접근은 저장된 procs와 그것들에 설정된 권한들로부터 이루어져야한다.
나는 그러한 것들이 제 자리에 있어야하지만 제 경우에는 제 통제를 넘어서는 것에 동의합니다. 소프트웨어 자체의 보안 만 통제 할 수 있습니다. – Flory