У оглядах баз даних два речення вживаються як взаємозамінні, але означають зовсім різне. Одне каже, що конкретному робочому навантаженню потрібен конкретний виняток; інше — що хосту більше не потрібен захист кінцевої точки. Перше — це обмежене інженерне рішення, а друге — ризик без власника. Розділити їх — і є все завдання, і воно починається з того, що сервер насправді робить.

Два речення, які звучать однаково

Виняток називає шлях, процес або тип файлу й наводить для цього причину. А відмова знімає контроль із машини й натомість наводить причину для цього. Обидва можуть дати схожі показники продуктивності й цілком різні позиції щодо безпеки.

Сервер бази даних — поганий кандидат на відмову, бо він зберігає дані, від яких залежить усе інше. Він також поганий кандидат для політики рівня робочого столу, бо сканування файлів, які база даних тримає відкритими, створює проблеми, яких робочий стіл ніколи не бачить. Чесна позиція посередині, і її треба обґрунтовувати, а не припускати. Саме це обґрунтування огляд і має зафіксувати.

Порівняйте виняток і відмову

Поставте два варіанти поруч за чотирма пунктами: що лишається захищеним, що стає відкритим, кому належить рішення і які докази його підкріплюють.

Обмежений виняток залишає решту хоста під тим самим захистом, що й раніше, зберігає рішення за названим власником і спирається на відтворений симптом. Відмова знімає захист з усього й зазвичай спирається на твердження, що машина не відкрита. Це твердження має витримати реальні ролі сервера, бо спільні папки, пов'язані сервери, завдання агента й адміністративні передавання файлів створюють відкритість, якої міжмережевий екран ніколи не бачить. Зміну власника переживає лише один стовпець наведеного нижче порівняння, бо він фіксує, що було вирішено і чому.

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

Обмежте виняток доведеною взаємодією

Починайте із симптому, а не зі списку. Конфлікт доступу до файлів, тиск на ресурси й повільний запит виглядають у журналах по-різному та ведуть до різних виправлень. Відтворіть симптом із увімкненим захистом, потім визначте точний шлях або процес, який задіяно.

Типові кандидати — файли бази даних, файли журналів, резервні копії та файли каталогу повнотекстового пошуку, а настанови 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

Збережіть підтримуваний шлях відкату й власника, який переглядає виняток після оновлень компонентів або продукту, бо виняток, написаний для однієї збірки, може пережити причину свого існування. Записуйте обсяг, причину й дату перегляду там само, де зберігається запис про збірку сервера. Без цього наступний перевіряльник успадковує список без обґрунтування. Виняток можна захистити лише доти, доки його причина ще правдива.

Схожі статті