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 |
छुटलाई प्रमाणित अन्तरक्रियामा सीमित राख्नुहोस्
सूचीबाट होइन, लक्षणबाट सुरु गर्नुहोस्। फाइल पहुँच द्वन्द्व, स्रोत दबाब र ढिलो क्वेरी लगमा फरक देखिन्छन् र फरक सुधारतर्फ लैजान्छन्। सुरक्षा खुला राखेर लक्षण पुनरुत्पादन गर्नुहोस्, त्यसपछि संलग्न ठ्याक्कै मार्ग वा प्रक्रिया पहिचान गर्नुहोस्।
सामान्य उम्मेदवारहरू डाटाबेस फाइल, लग फाइल, ब्याकअप र पूर्ण-पाठ क्याटलग फाइल हुन्, र एन्टिभाइरस सफ्टवेयर र SQL Server बारे Microsoft को मार्गदर्शन तैनाथ गरिएको संस्करण र सुरक्षा उत्पादनका लागि सन्दर्भ रहन्छ। अर्को सर्भरबाट सूची प्रतिलिपि नगर्नुहोस्, र एउटा सेवा नामले स्थापित प्रत्येक घटक ढाक्छ भनी नमान्नुहोस्। प्रमाणित अन्तरक्रियालाई सम्बोधन गर्ने सबैभन्दा सानो छुट नै प्रस्ताव गर्नुपर्ने हो। त्यसभन्दा फराकिलो जुनसुकैलाई आफ्नै तर्क चाहिन्छ।
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
घटक वा उत्पादन अद्यावधिकपछि छुटको समीक्षा गर्ने मालिक र समर्थित रोलब्याक मार्ग कायम राख्नुहोस्, किनकि एउटा बिल्डका लागि लेखिएको छुट त्यसको अस्तित्वको कारणभन्दा लामो समय टिक्न सक्छ। दायरा, कारण र समीक्षा मिति सर्भरको बिल्ड रेकर्ड भएकै ठाउँमा अभिलेख गर्नुहोस्। त्यो बिना अर्को समीक्षकले पछाडि तर्क नभएको सूची उत्तराधिकारमा पाउँछ। छुट त्यसको कारण अझै सत्य हुँदासम्म मात्र औचित्यपूर्ण हुन्छ।