کدام پوشه‌ها را می‌توانید از آنتی‌ویروس برای 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یک مسیر بازگشت پشتیبان‌ی‌شده و مالکی نگه دارید که استثنا را پس از به‌روزرسانی اجزا یا محصول بازبینی کند، چون استثنایی که برای یک ساخت نوشته شده می‌تواند از دلیلی که وجود داشت بیشتر بماند. دامنه، دلیل و تاریخ بازبینی را همان‌جا که سابقه ساخت سرور است ثبت کنید. بدون آن، بازبین بعدی فهرستی را به ارث می‌برد که هیچ استدلالی پشتش نیست. استثنا فقط تا زمانی قابل دفاع است که دلیلش هنوز درست باشد.