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

Две фразы, которые звучат одинаково

Исключение называет путь, процесс или тип файла и приводит для этого причину. А отказ снимает контроль с машины и вместо этого приводит причину для этого. Оба варианта могут дать похожие показатели производительности и совершенно разные позиции по безопасности.

Сервер базы данных — плохой кандидат на отказ, потому что он хранит данные, от которых зависит всё остальное. Он также плохой кандидат для политики уровня рабочего стола, потому что сканирование файлов, которые база данных держит открытыми, создаёт проблемы, которых рабочий стол никогда не видит. Честная позиция находится посередине, и её нужно обосновывать, а не предполагать. Именно это обоснование обзор и должен зафиксировать.

Сравните исключение и отказ

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

Ограниченное исключение оставляет остальную часть хоста под той же защитой, что и раньше, сохраняет решение за названным владельцем и опирается на воспроизведённый симптом. Отказ снимает защиту со всего и обычно опирается на утверждение, что машина не открыта. Это утверждение должно выдержать фактические роли сервера, потому что общие папки, связанные серверы, задания агента и административная передача файлов создают открытость, которую межсетевой экран никогда не видит. Только один столбец сравнения ниже переживает смену владельца, потому что он фиксирует, что было решено и почему.

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

Сохраните поддерживаемый путь отката и владельца, который пересматривает исключение после обновлений компонентов или продукта, потому что исключение, написанное для одной сборки, может пережить причину своего существования. Записывайте область, причину и дату пересмотра там же, где хранится запись о сборке сервера. Без этого следующий проверяющий наследует список без обоснования. Исключение защитимо только до тех пор, пока его причина остаётся верной.

Похожие статьи