Que cartafoles pode excluír do antivirus para SQL Server?
Unha exclusión para unha carga de traballo e un servidor sen protección son decisións distintas. Limite a excepción á interacción demostrada e manteña os demais controis.
Dúas frases úsanse de forma intercambiable nas revisións de bases de datos, e significan cousas moi distintas. Unha di que unha carga de traballo concreta precisa unha excepción concreta; a outra di que o servidor xa non precisa protección de punto final. A primeira é unha decisión de enxeñaría acoutada, e a segunda é un risco sen propietario. Separalas é toda a tarefa, e comeza polo que o servidor fai en realidade.
Dúas frases que soan igual
Unha excepción nomea unha ruta, un proceso ou un tipo de ficheiro e dá unha razón para iso. Un abandono retira un control dunha máquina e, no seu lugar, dá unha razón para iso. Os dous poden producir cifras de rendemento parecidas e posturas de seguridade completamente distintas.
Un servidor de bases de datos é un mal candidato para o abandono porque garda os datos dos que depende todo o demais. Tamén é un mal candidato para unha política de nivel de escritorio, porque analizar ficheiros que unha base de datos mantén abertos causa problemas que un escritorio nunca ve. A postura honesta está no medio, e hai que argumentala en vez de supola. Ese argumento é o que unha revisión debe recoller.
Compare a excepción e o abandono
Pon as dúas opcións unha ao lado da outra en catro puntos: que segue protexido, que queda exposto, quen é dono da decisión e que probas a sustentan.
Unha excepción acoutada deixa o resto do servidor baixo a mesma protección que antes, mantén a decisión nun propietario nomeado e apóiase nun síntoma reproducido. Un abandono retira a protección de todo e adoita apoiarse na afirmación de que a máquina non está exposta. Esa afirmación ten que sobrevivir aos roles reais do servidor, porque os recursos compartidos, os servidores vinculados, os traballos do axente e as transferencias administrativas de ficheiros crean unha exposición que un cortafogos nunca ve. Só unha columna da comparación de abaixo sobrevive a un cambio de propietario, porque rexistra que se decidiu e por que.
| 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 |
Limite a excepción á interacción demostrada
Empece polo síntoma en lugar de por unha lista. Un conflito de acceso a ficheiros, a presión de recursos e unha consulta lenta vense distintos nos rexistros e levan a correccións distintas. Reproduza o síntoma coa protección activada e despois identifique a ruta ou o proceso exacto que interveñen.
Os candidatos típicos son os ficheiros da base de datos, os ficheiros de rexistro, as copias de seguridade e os ficheiros do catálogo de texto completo, e a guía de Microsoft sobre software antivirus e SQL Server segue a ser a referencia para a versión despregada e o produto de seguridade. Non copie unha lista doutro servidor nin supoña que un só nome de servizo cobre todos os compoñentes instalados. A excepción máis pequena que atende a interacción demostrada é a que hai que propoñer. Calquera cousa máis ampla necesita o seu propio argumento.
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabledRevise esa lista contra o rol do servidor, porque unha excepción engadida por un incidente tende a quedar para sempre. Unha nota breve xunto a cada entrada abonda para facer posible a próxima auditoría.
Manteña os controis de rede e de identidade
Unha excepción de punto final non di nada sobre quen pode chegar á base de datos. A política do cortafogos debería seguir limitando que fontes poden abrir unha sesión SQL ou de xestión, e as contas de aplicación deberían seguir limitando que poden facer esas sesións.
Unha VPN pertence a esa mesma conversa e a miúdo úsase mal como argumento. Restrinxir a ruta de acceso non valida os ficheiros, os scripts nin as consultas que chegan por ela. Un túnel cifrado tamén é opaco para un sensor de rede, así que a visibilidade que lle dá un sensor non é a visibilidade que lle dá un axente do servidor. Son fluxos de probas distintos e ningún substitúe o outro. A xestión de parches, as ferramentas administrativas de confianza e unha ruta de recuperación probada seguen sendo responsabilidades separadas cos seus propios donos. A hixiene de roles tamén corresponde aquí: a navegación, as descargas e as tarefas de compartir ficheiros non relacionadas deberían quedar fóra do servidor da base de datos agás que o seu propietario as aceptase explicitamente.
Probe o cambio e despois fágao seu
Probe cunha carga de traballo representativa e as comprobacións de seguridade que importan, e despois compare estabilidade, rendemento e protección continuada en lugar de só o erro orixinal.
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20Manteña unha ruta de reversión soportada e un propietario que revise a excepción tras actualizacións de compoñentes ou de produto, porque unha excepción escrita para unha compilación pode sobrevivir ao motivo polo que existía. Rexistre o alcance, o motivo e a data de revisión no mesmo sitio que o rexistro de compilación do servidor. Sen iso, o seguinte revisor herda unha lista sen argumento detrás. Unha excepción só é defendible mentres o seu motivo siga a ser certo.