რომელი საქაღალდეები შეიძლება გამოვრიცხოთ ანტივირუსიდან 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შეინარჩუნეთ მხარდაჭერილი უკან დაბრუნების ბილიკი და მფლობელი, რომელიც კომპონენტის ან პროდუქტის განახლების შემდეგ გადახედავს გამონაკლისს, რადგან ერთი build-ისთვის დაწერილი გამონაკლისი შეიძლება გადარჩეს მისი არსებობის მიზეზს. ჩაწერეთ ფარგლები, მიზეზი და გადახედვის თარიღი იმავე ადგილას, სადაც სერვერის build-ის ჩანაწერია. ამის გარეშე შემდეგი მიმომხილველი მემკვიდრეობით მიიღებს სიას ყოველგვარი დასაბუთების გარეშე. გამონაკლისი დასაცავია მხოლოდ მანამ, სანამ მისი მიზეზი ჯერ კიდევ მართალია.