Ce foldere puteți exclude din antivirus pentru SQL Server?
O excepție pentru o sarcină de lucru și un host neprotejat sunt două decizii diferite. Limitați excepția la interacțiunea demonstrată și păstrați celelalte controale.
Două propoziții sunt folosite interschimbabil în revizuirile de baze de date, dar înseamnă lucruri foarte diferite. Una spune că o anumită sarcină de lucru are nevoie de o anumită excepție; cealaltă spune că hostul nu mai are nevoie de protecție la punctul final. Prima este o decizie de inginerie delimitată, iar a doua este un risc fără proprietar. Separarea lor este întreaga sarcină și începe cu ceea ce face de fapt serverul.
Două propoziții care sună la fel
O excepție numește o cale, un proces sau un tip de fișier și oferă un motiv pentru aceasta. O abandonare remove un control de pe o mașină și oferă în schimb un motiv pentru aceasta. Ambele pot produce cifre de performanță similare și poziții de securitate complet diferite.
Un server de baze de date este un candidat slab pentru abandonare, deoarece stochează datele de care depinde tot restul. Este și un candidat slab pentru o politică la nivel de desktop, deoarece scanarea fișierelor pe care o bază de date le ține deschise creează probleme pe care un desktop nu le vede niciodată. Poziția onestă se află la mijloc și trebuie argumentată, nu presupusă. Acesta este argumentul pe care o revizuire trebuie să îl consemneze.
Comparați excepția și abandonarea
Puneți cele două opțiuni una lângă alta pe patru puncte: ce rămâne protejat, ce devine expus, cine deține decizia și ce dovezi o susțin.
O excepție delimitată lasă restul hostului sub aceeași protecție ca înainte, păstrează decizia la un proprietar numit și se sprijină pe un simptom reprodus. O abandonare elimină protecția de la tot și se sprijină de obicei pe afirmația că mașina nu este expusă. Acea afirmație trebuie să reziste rolurilor reale ale serverului, deoarece partajările de fișiere, serverele conectate, sarcinile agentului și transferurile administrative de fișiere creează toate o expunere pe care un firewall nu o vede niciodată. Doar o coloană a comparației de mai jos supraviețuiește unei schimbări de proprietar, deoarece consemnează ce s-a decis și de ce.
| 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 |
Limitați o excepție la interacțiunea demonstrată
Începeți cu simptomul, nu cu o listă. Un conflict de acces la fișiere, presiunea pe resurse și o interogare lentă arată diferit în jurnale și duc la corecții diferite. Reproduceți simptomul cu protecția activă, apoi identificați calea sau procesul exact implicat.
Candidații tipici sunt fișierele bazei de date, fișierele de jurnal, copiile de siguranță și fișierele catalogului full-text, iar îndrumările Microsoft despre software antivirus și SQL Server rămân referința pentru versiunea implementată și produsul de securitate. Nu copiați o listă de pe alt server și nu presupuneți că un singur nume de serviciu acoperă fiecare componentă instalată. Cea mai mică excepție care tratează interacțiunea demonstrată este cea care trebuie propusă. Orice mai larg are nevoie de propriul argument.
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled
Revizuiți acea listă față de rolul serverului, deoarece o excepție adăugată pentru un incident tinde să rămână pentru totdeauna. O notă scurtă lângă fiecare intrare este suficientă pentru a face posibil următorul audit.
Păstrați controalele de rețea și de identitate
O excepție la punctul final nu spune nimic despre cine poate ajunge la baza de date. Politica firewallului ar trebui să limiteze în continuare ce surse pot deschide o sesiune SQL sau de administrare, iar conturile de aplicație ar trebui să limiteze în continuare ce pot face acele sesiuni.
Un VPN aparține aceleiași conversații și este adesea folosit greșit ca argument. Restrângerea căii de acces nu validează fișierele, scripturile sau interogările care sosesc prin ea. Un tunel criptat este și opac pentru un senzor de rețea, așa că vizibilitatea pe care ți-o dă un senzor nu este vizibilitatea pe care ți-o dă un agent de host. Acestea sunt fluxuri de dovezi diferite și niciunul nu îl înlocuiește pe celălalt. Gestionarea patch-urilor, instrumentele administrative de încredere și o cale de recuperare testată rămân responsabilități separate cu propriii proprietari. Igiena rolurilor se încadrează și aici: navigarea, descărcările și sarcinile de partajare a fișierelor fără legătură ar trebui să rămână în afara hostului bazei de date, dacă proprietarul acestuia nu le-a acceptat în mod explicit.
Testați schimbarea și apoi asumați-vă responsabilitatea
Testați cu o sarcină de lucru reprezentativă și cu verificările de securitate care contează, apoi comparați stabilitatea, debitul și protecția continuă, nu doar eroarea inițială.
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20
Păstrați o cale de revenire acceptată și un proprietar care revizuiește excepția după actualizări de componente sau de produs, deoarece o excepție scrisă pentru un build poate supraviețui motivului pentru care a existat. Înregistrați domeniul, motivul și data revizuirii în același loc cu înregistrarea build-ului serverului. Fără aceasta, următorul revizor moștenește o listă fără argument în spate. O excepție este justificabilă doar cât timp motivul ei este încă adevărat.