Ի՞նչ թղթապանակներ կարելի է բացառել հակավիրուսից 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 |
Սահմանափակեք բացառումը ապացուցված փոխազդեցությամբ
Սկսեք ախտանիշից, ոչ թե ցանկից։ Ֆայլերի հասանելիության կոնֆլիկտը, ռեսուրսների ճնշումը և դանդաղ հարցումը մատյաններում տարբեր են երևում և տանում են տարբեր ուղղումների։ Վերարտադրեք ախտանիշը միացված պաշտպանությամբ, ապա որոշեք ներգրավված ճշգրիտ ուղին կամ գործընթացը։
Տիպիկ թեկնածուներն են տվյալների բազայի ֆայլերը, մատյանի ֆայլերը, պահուստային պատճենները և ամբողջական տեքստի կատալոգի ֆայլերը, և Microsoft-ի ուղեցույցը հակավիրուսային ծրագրերի և SQL Server-ի վերաբերյալ մնում է հղում տեղակայված տարբերակի և անվտանգության արտադրանքի համար։ Մի պատճենեք ցանկ այլ սերվերից և մի ենթադրեք, որ մեկ ծառայության անունը ծածկում է յուրաքանչյուր տեղադրված բաղադրիչ։ Առաջարկելի է ամենափոքր բացառումը, որն անդրադառնում է ապացուցված փոխազդեցությանը։ Ամեն ինչ ավելի լայն պահանջում է իր փաստարկը։
Get-MpPreference | Select-Object -ExpandProperty ExclusionPath
Get-MpComputerStatus | Select-Object AntivirusEnabled, RealTimeProtectionEnabledՎերանայեք այդ ցանկը սերվերի դերի համեմատ, որովհետև մեկ միջադեպի համար ավելացված բացառումը սովորաբար մնում է ընդմիշտ։ Յուրաքանչյուր գրառման կողքին կարճ նշումը բավական է, որպեսզի հնարավոր լինի հաջորդ աուդիտը։
Պահպանեք ցանցային և ինքնության վերահսկիչները
Վերջնակետային բացառումը ոչինչ չի ասում այն մասին, թե ով կարող է հասնել տվյալների բազային։ Ֆայրվոլի քաղաքականությունը դեռ պետք է սահմանափակի, թե որ աղբյուրները կարող են բացել SQL կամ կառավարման նստաշրջան, և հավելվածների հաշիվները դեռ պետք է սահմանափակեն, թե այդ նստաշրջանները ինչ կարող են անել։
VPN-ը նույն խոսակցության մասն է և հաճախ սխալ է օգտագործվում որպես փաստարկ։ Մուտքի ուղին սահմանափակելը չի վավերացնում դրա միջով եկող ֆայլերը, սկրիպտները կամ հարցումները։ Գաղտնագրված թունելը նաև անթափանց է ցանցային սենսորի համար, ուստի սենսորի տված տեսանելիությունը սեփականատիրոջ գործակալի տված տեսանելիությունը չէ։ Դրանք տարբեր ապացույցային հոսքեր են, և ոչ մեկը չի փոխարինում մյուսին։ Կարկատանների կառավարումը, վստահելի վարչական գործիքները և փորձարկված վերականգնման ուղին մնում են առանձին պատասխանատվություններ իրենց սեփականատերերով։ Դերերի հիգիենան նույնպես այստեղ է. անկապ զննարկումը, ներբեռնումները և ֆայլերի համօգտագործման պարտականությունները պետք է հեռու մնան տվյալների բազայի հոսթից, եթե դրա սեփականատերը բացահայտ չի ընդունել դրանք։
Փորձարկեք փոփոխությունը, ապա ստանձնեք այն
Փորձարկեք ներկայացուցչական ծանրաբեռնվածությամբ և կարևոր անվտանգության ստուգումներով, ապա համեմատեք կայունությունը, թողունակությունը և շարունակական պաշտպանությունը, այլ ոչ միայն սկզբնական սխալը։
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5
Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 20Պահպանեք աջակցվող հետադարձ ուղի և սեփականատեր, որը վերանայում է բացառումը բաղադրիչի կամ արտադրանքի թարմացումներից հետո, որովհետև մեկ կառուցման համար գրված բացառումը կարող է ապրել ավելի երկար, քան իր գոյության պատճառը։ Արձանագրեք շրջանակը, պատճառը և վերանայման ամսաթիվը նույն տեղում, որտեղ սերվերի կառուցման գրառումն է։ Առանց դրա հաջորդ վերանայողը ժառանգում է ցանկ առանց դրա հետևում եղած փաստարկի։ Բացառումը պաշտպանելի է միայն այնքան ժամանակ, քանի դեռ դրա պատճառը դեռ ճիշտ է։