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.

PointScoped exceptionBlanket exclusion
CoverageOnly the named paths or processesThe whole host
Evidence neededA reproduced interactionAn argument about exposure
OwnerA named reviewer with a dateUsually nobody
Behaviour after an updateReviewed againSilently 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ë.

Artikuj të ngjashëm