SQL Server용 백신에서 어떤 폴더를 제외할 수 있나요?
워크로드 예외와 보호되지 않은 호스트는 서로 다른 결정입니다. 예외를 입증된 상호 작용으로 한정하고 나머지 통제는 유지하십시오.
데이터베이스 검토에서 두 문장이 서로 바꿔 쓰이지만, 그 의미는 전혀 다릅니다. 하나는 특정 워크로드에 특정 예외가 필요하다고 말하고, 다른 하나는 호스트에 더 이상 엔드포인트 보호가 필요 없다고 말합니다. 전자는 범위가 정해진 엔지니어링 결정이고, 후자는 주인이 없는 위험입니다. 이 둘을 분리하는 것이 전체 작업이며, 서버가 실제로 무엇을 하는지에서 시작합니다.
같게 들리는 두 문장
예외는 경로, 프로세스 또는 파일 형식을 지목하고 그에 대한 이유를 제시합니다. 반면 포기는 머신에서 통제를 제거하고 그 대신 그 이유를 제시합니다. 둘 다 비슷한 성능 수치와 전혀 다른 보안 태세를 낼 수 있습니다.
데이터베이스 서버는 다른 모든 것이 의존하는 데이터를 보관하기 때문에 포기에 부적합한 후보입니다. 데이터베이스가 열어 둔 파일을 검사하면 데스크톱에서는 결코 보지 못하는 문제가 생기기 때문에 데스크톱 수준 정책에도 부적합합니다. 정직한 입장은 중간에 있으며, 가정이 아니라 논증으로 세워야 합니다. 검토가 기록해야 할 것은 바로 그 논증입니다.
예외와 포기를 비교하십시오
두 선택지를 무엇이 보호된 채 남는지, 무엇이 노출되는지, 결정을 누가 소유하는지, 어떤 증거가 그것을 뒷받침하는지라는 네 가지 지점에서 나란히 놓으십시오.
범위가 정해진 예외는 호스트의 나머지를 이전과 같은 보호 아래 두고, 결정을 이름이 있는 소유자에게 남기며, 재현된 증상에 근거합니다. 포기는 모든 것에서 보호를 제거하며, 보통 머신이 노출되지 않았다는 주장에 근거합니다. 그 주장은 파일 공유, 연결된 서버, 에이전트 작업, 관리용 파일 전송이 모두 방화벽이 결코 보지 못하는 노출을 만들기 때문에 서버의 실제 역할을 견뎌야 합니다. 아래 비교에서 소유자가 바뀌어도 살아남는 것은 무엇이 결정되었고 왜 그런지 기록하는 한 열뿐입니다.
| Point | Scoped exception | Blanket exclusion |
|---|---|---|
| Coverage | Only the named paths or processes | The whole host |
| Evidence needed | A reproduced interaction | An argument about exposure |
| Owner | A named reviewer with a date | Usually nobody |
| Behaviour after an update | Reviewed again | Silently inherited |
예외를 입증된 상호 작용으로 한정하십시오
목록이 아니라 증상에서 시작하십시오. 파일 접근 충돌, 리소스 압박, 느린 쿼리는 로그에서 다르게 보이고 서로 다른 수정으로 이어집니다. 보호를 켠 상태에서 증상을 재현한 다음, 관련된 정확한 경로나 프로세스를 식별하십시오.
일반적인 후보는 데이터베이스 파일, 로그 파일, 백업, 전체 텍스트 카탈로그 파일이며, 백신 소프트웨어와 SQL Server에 관한 Microsoft의 지침은 배포된 버전과 보안 제품에 대한 참조로 남습니다. 다른 서버에서 목록을 복사하지 말고, 하나의 서비스 이름이 설치된 모든 구성 요소를 포괄한다고 가정하지 마십시오. 입증된 상호 작용을 다루는 가장 작은 예외가 제안해야 할 것입니다. 더 넓은 것은 무엇이든 자기 논증이 필요합니다.
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled
그 목록을 한 사건 때문에 추가한 예외는 보통 영원히 남기 때문에 서버의 역할에 비추어 다시 검토하십시오. 각 항목 옆의 짧은 메모만으로도 다음 감사는 가능해집니다.
네트워크와 ID 통제를 유지하십시오
엔드포인트 예외는 누가 데이터베이스에 도달할 수 있는지에 대해 아무 말도 하지 않습니다. 방화벽 정책은 어떤 출처가 SQL 또는 관리 세션을 열 수 있는지 여전히 제한해야 하고, 애플리케이션 계정은 그 세션들이 무엇을 할 수 있는지 여전히 제한해야 합니다.
VPN도 같은 대화에 속하며 근거로 자주 오용됩니다. 접근 경로를 제한해도 그 경로로 들어오는 파일, 스크립트, 쿼리가 검증되지는 않습니다. 암호화된 터널은 네트워크 센서에 불투명하기도 하므로, 센서가 주는 가시성은 호스트 에이전트가 주는 가시성이 아닙니다. 이들은 서로 다른 증거 흐름이며 어느 쪽도 다른 쪽을 대체하지 않습니다. 패치 관리, 신뢰할 수 있는 관리 도구, 검증된 복구 경로는 각자의 소유자를 가진 별도의 책임으로 남습니다. 역할 위생도 여기에 해당합니다: 무관한 브라우징, 다운로드, 파일 공유 업무는 소유자가 명시적으로 수용하지 않는 한 데이터베이스 호스트에서 멀리해야 합니다.
변경을 테스트한 다음 책임을 지십시오
대표적인 워크로드와 중요한 보안 점검으로 테스트한 다음, 원래 오류만이 아니라 안정성, 처리량, 지속적인 보호를 비교하십시오.
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20
한 빌드를 위해 작성한 예외가 존재 이유보다 오래 살 수 있기 때문에 지원되는 롤백 경로와 구성 요소나 제품 업데이트 후 예외를 검토하는 소유자를 유지하십시오. 범위, 이유, 검토 날짜를 서버의 빌드 기록과 같은 곳에 기록하십시오. 그것이 없으면 다음 검토자는 근거 없는 목록을 물려받습니다. 예외는 그 이유가 여전히 참인 동안에만 정당화됩니다.