Cilat dosje mund të përjashtoni nga antivirusi për SQL Server?
Një përjashtim për një ngarkesë pune dhe një host i pambrojtur janë dy vendime të ndryshme. Kufizoni përjashtimin te ndërveprimi i provuar dhe mbani kontrollet e tjera.
Dy fjali përdoren në mënyrë të ndërsjelltë në rishikimet e bazave të të dhënave, por kuptimi i tyre është shumë i ndryshëm. Njëra thotë se një ngarkesë pune e caktuar kërkon një përjashtim të caktuar; tjetra thotë se hosti nuk ka më nevojë për mbrojtje të pikës fundore. E para është një vendim inxhinierik i kufizuar, dhe e dyta është një rrezik pa pronar. Ndaria e tyre është e gjithë detyra, dhe ajo fillon me atë që serveri bën në të vërtetë.
Dy fjali që tingëllojnë njësoj
Një përjashtim emërton një shteg, një proces ose një lloj skedari dhe jep një arsye për të. Ndërsa një braktisje heq një kontroll nga një makinë dhe në vend të tij jep një arsye për këtë. Të dyja mund të japin shifra të ngjashme të performancës dhe qëndrime sigurie krejtësisht të ndryshme.
Serveri i bazës së të dhënave është një kandidat i dobët për braktisje, sepse ruan të dhënat nga të cilat varet gjithçka tjetër. Është gjithashtu kandidat i dobët për një politikë të nivelit të desktopit, sepse skanimi i skedarëve që një bazë të dhënash mban të hapura krijon probleme që një desktop nuk i sheh kurrë. Qëndrimi i ndershëm është në mes, dhe duhet argumentuar, jo supozuar. Pikërisht ky argument duhet të regjistrojë një rishikim.
Krahasoni përjashtimin dhe braktisjen
Vendosni dy opsionet krah për krah në katër pika: çfarë mbetet e mbrojtur, çfarë bëhet e ekspozuar, kush e zotëron vendimin dhe cilat prova e mbështesin.
Një përjashtim i kufizuar e lë pjesën tjetër të hostit nën të njëjtën mbrojtje si më parë, e mban vendimin te një pronar i emëruar dhe mbështetet në një simptomë të riprodhuar. Braktisja heq mbrojtjen nga gjithçka dhe zakonisht mbështetet në pohimin se makina nuk është e ekspozuar. Ky pohim duhet t'i bëjë ballë roleve reale të serverit, sepse ndarjet e skedarëve, serverët e lidhur, punët e agjentit dhe transferimet administrative të skedarëve krijojnë të gjitha ekspozim që një firewall nuk e sheh kurrë. Vetëm një kolonë e krahasimit më poshtë i mbijeton një ndryshimi pronësie, sepse regjistron çfarë u vendos dhe pse.
| 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 |
Kufizoni përjashtimin te ndërveprimi i provuar
Filloni nga simptoma, jo nga një listë. Një konflikt i aksesit në skedarë, presioni mbi burimet dhe një pyetës i ngadaltë duken ndryshe në regjistra dhe çojnë në rregullime të ndryshme. Riprodhoni simptomën me mbrojtjen aktive, më pas identifikoni shtegun ose procesin e saktë të përfshirë.
Kandidatët tipikë janë skedarët e bazës së të dhënave, skedarët e regjistrit, kopjet rezervë dhe skedarët e katalogut të tekstit të plotë, dhe udhëzimet e Microsoft për softuerin antivirus dhe SQL Server mbeten referenca për versionin e vendosur dhe produktin e sigurisë. Mos kopjoni një listë nga një server tjetër dhe mos supozoni se një emër shërbimi mbulon çdo komponent të instaluar. Përjashtimi më i vogël që trajton ndërveprimin e provuar është ai që duhet propozuar. Çdo gjë më e gjerë kërkon argumentin e vet.
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabled
Rishikoni atë listë kundrejt rolit të serverit, sepse një përjashtim i shtuar për një incident ka tendencë të mbetet përgjithmonë. Një shënim i shkurtër pranë çdo hyrjeje mjafton për të bërë të mundur auditimin e ardhshëm.
Mbani kontrollet e rrjetit dhe të identitetit
Një përjashtim i pikës fundore nuk thotë asgjë për atë se kush mund të arrijë bazën e të dhënave. Politika e firewall-it duhet ende të kufizojë cilat burime mund të hapin një sesion SQL ose menaxhimi, dhe llogaritë e aplikacioneve duhet ende të kufizojnë çfarë mund të bëjnë ato sesione.
Një VPN i përket të njëjtit bisedë dhe shpesh keqpërdoret si argument. Kufizimi i shtegut të aksesit nuk vërteton skedarët, skriptet ose pyetësit që vijnë përmes tij. Një tunel i enkriptuar është gjithashtu i errët për një sensor rrjeti, kështu që dukshmëria që jep një sensor nuk është dukshmëria që jep një agjent i hostit. Këto janë rryma të ndryshme provash, dhe asnjëra nuk e zëvendëson tjetrën. Menaxhimi i patch-eve, mjetet administrative të besuara dhe një shteg rikuperimi i testuar mbeten përgjegjësi të veçanta me pronarët e tyre. Higjiena e roleve gjithashtu hyn këtu: shfletimi, shkarkimet dhe detyrat e ndarjes së skedarëve të palidhura duhet të qëndrojnë larg hostit të bazës së të dhënave, përveç nëse pronari i tij i ka pranuar ato në mënyrë eksplicite.
Testoni ndryshimin dhe më pas merrni përsipër
Testoni me një ngarkesë pune përfaqësuese dhe kontrollet e sigurisë që kanë rëndësi, më pas krahasoni qëndrueshmërinë, qarkullimin dhe mbrojtjen e vazhdueshme, jo vetëm gabimin origjinal.
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20
Mbani një shteg kthimi të mbështetur dhe një pronar që rishikon përjashtimin pas përditësimeve të komponentëve ose të produktit, sepse një përjashtim i shkruar për një build mund t'i mbijetojë arsyes së ekzistencës së tij. Regjistroni shtrirjen, arsyen dhe datën e rishikimit në të njëjtin vend me regjistrin e build-it të serverit. Pa këtë, rishikuesi tjetër trashëgon një listë pa argument pas saj. Një përjashtim është i mbrojtshëm vetëm përderisa arsyeja e tij është ende e vërtetë.