ڈیٹا بیس کے جائزوں میں دو جملے ایک دوسرے کی جگہ استعمال ہوتے ہیں، حالانکہ ان کا مطلب بہت مختلف ہے۔ ایک کہتا ہے کہ مخصوص ورک لوڈ کو مخصوص استثنا درکار ہے؛ دوسرا کہتا ہے کہ ہوسٹ کو اب اینڈ پوائنٹ تحفظ کی ضرورت نہیں۔ پہلا محدود انجینئرنگ فیصلہ ہے، اور دوسرا بے مالک خطرہ۔ انہیں الگ کرنا ہی پورا کام ہے، اور یہ اس بات سے شروع ہوتا ہے کہ سرور واقعی کیا کرتا ہے۔

ایک جیسے سنائی دینے والے دو جملے

استثنا کسی راستے، عمل یا فائل کی قسم کا نام لیتا ہے اور اس کی وجہ بتاتا ہے۔ جبکہ ترک کرنا مشین سے ایک کنٹرول ہٹاتا ہے اور اس کے بجائے اس کی وجہ بتاتا ہے۔ دونوں ایک جیسے کارکردگی کے اعداد اور بالکل مختلف حفاظتی رویے پیدا کر سکتے ہیں۔

ڈیٹا بیس سرور ترک کرنے کے لیے ناقص امیدوار ہے کیونکہ یہ وہ ڈیٹا رکھتا ہے جس پر باقی سب انحصار کرتا ہے۔ یہ ڈیسک ٹاپ سطح کی پالیسی کے لیے بھی ناقص امیدوار ہے، کیونکہ ڈیٹا بیس کی کھلی رکھی گئی فائلوں کو اسکین کرنا ایسے مسائل پیدا کرتا ہے جو ڈیسک ٹاپ کبھی نہیں دیکھتا۔ دیانت دار موقف درمیان میں ہے، اور اسے فرض کرنے کے بجائے دلیل سے ثابت کرنا ہوتا ہے۔ جائزے کو وہی دلیل ریکارڈ کرنی چاہیے۔

استثنا اور ترک کرنے کا موازنہ کریں

دونوں آپشنز کو چار نکات پر ساتھ رکھیں: کیا محفوظ رہتا ہے، کیا بے نقاب ہوتا ہے، فیصلہ کس کا ہے، اور کون سے شواہد اس کی تائید کرتے ہیں۔

محدود استثنا ہوسٹ کے باقی حصے کو پہلے کی طرح اسی تحفظ کے تحت رکھتا ہے، فیصلہ نامزد مالک کے پاس رکھتا ہے اور دوبارہ پیدا شدہ علامت پر ٹکتا ہے۔ ترک کرنا ہر چیز سے تحفظ ہٹا دیتا ہے اور عام طور پر اس دعوے پر ٹکتا ہے کہ مشین بے نقاب نہیں۔ اس دعوے کو سرور کے حقیقی کرداروں کے سامنے ٹکنا ہوگا، کیونکہ فائل شیئرنگ، منسلک سرورز، ایجنٹ جابز اور انتظامی فائل منتقلی سب ایسی بے نقابی پیدا کرتے ہیں جو فائر وال کبھی نہیں دیکھتا۔ نیچے دیے گئے موازنے کا صرف ایک کالم ملکیت بدلنے پر بھی برقرار رہتا ہے، کیونکہ یہ ریکارڈ کرتا ہے کہ کیا طے ہوا اور کیوں۔

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

استثنا کو ثابت شدہ تعامل تک محدود رکھیں

فہرست سے نہیں، علامت سے شروع کریں۔ فائل تک رسائی کا تصادم، وسائل کا دباؤ اور سست استفسار لاگز میں مختلف نظر آتے ہیں اور مختلف اصلاحات کی طرف لے جاتے ہیں۔ تحفظ فعال رکھتے ہوئے علامت دوبارہ پیدا کریں، پھر متعلقہ درست راستہ یا عمل کی نشاندہی کریں۔

عام امیدوار ڈیٹا بیس فائلیں، لاگ فائلیں، بیک اپ اور مکمل متن کیٹلاگ فائلیں ہیں، اور اینٹی وائرس سافٹ ویئر اور 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

جزو یا مصنوعات کی تازہ کاری کے بعد استثنا کا جائزہ لینے والا مالک اور معاون رول بیک راستہ برقرار رکھیں، کیونکہ ایک بلڈ کے لیے لکھا گیا استثنا اپنے وجود کی وجہ سے زیادہ عرصہ رہ سکتا ہے۔ دائرہ، وجہ اور جائزے کی تاریخ سرور کے بلڈ ریکارڈ والی جگہ ہی درج کریں۔ اس کے بغیر اگلا جائزہ لینے والا پیچھے دلیل کے بغیر فہرست ورثے میں پاتا ہے۔ استثنا صرف اس وقت تک جائز ہے جب تک اس کی وجہ درست ہے۔

متعلقہ مضامین