Как системному администратору следить за безопасностью

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

Между этими путями и приходится выбирать. Посередине лежит третий вариант: готовая платформа, которая собирает события со всего парка машин и сама их сопоставляет. Ниже критерии выбора, сквозная таблица и разбор, кому подходит каждый подход.

Дальше идут три типовые ситуации с готовой рекомендацией и короткий список вещей, которые нужны при любом бюджете.

По каким критериям выбирают систему контроля безопасности?

Главное: решают четыре вещи. Сколько машин в парке, сколько часов в неделю администратор реально может отдать безопасности, какие требования предъявляет отраслевой регулятор или крупный заказчик, и какие навыки есть у команды. Дежурство ночью и в выходные идёт пятым вместе с бюджетом: они ограничивают выбор, но редко определяют его целиком.

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

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

Третий: требования снаружи. Аудит, договор с крупным клиентом или отраслевые нормы часто прямо обязывают хранить журналы и показывать, кто и когда получал доступ. Ручной режим тут отпадает сразу.

Четвёртый: компетенции команды. Связка из открытых инструментов требует навыков, которые набираются далеко не за выходные, и список этих навыков полезно посмотреть заранее: что изучать системному администратору. Соседний разбор отвечает на вопрос обучения, здесь речь про выбор инструментов.

Сравнение трёх подходов в одной таблице

Главное: ручной контроль дёшев, понятен и целиком зависит от дисциплины человека. Связка из открытых инструментов даёт круглосуточные оповещения и оплачивается рабочим временем на настройку и поддержку. Платформа класса SIEM сопоставляет события из разных источников и находит то, что по отдельности выглядит безобидно, зато требует денег и отдельного специалиста.

Таблица ниже собрана по тем же критериям, что перечислены выше.

Ни один столбец не отменяет соседний. Многие приходят к смеси: журналы уезжают в централизованное хранилище, простые правила режут перебор паролей автоматически, а глубокий разбор администратор делает руками раз в неделю.

Кому хватает ручного контроля?

Главное: ручного режима достаточно небольшому парку с одним администратором и без внешних требований к аудиту. Работает он на встроенных средствах: журнал событий Windows, системный журнал Linux, штатный фаервол; трафик разбирают бесплатным Wireshark. Условие одно: превратить проверки в жёсткий график, иначе они тихо исчезают из рабочей недели.

Минимальный недельный график выглядит примерно так:

1. Просмотр неудачных попыток входа на серверах и на пограничном оборудовании.
2. Проверка учётных записей: кто добавился, у кого выросли права, кто уволился месяц назад и всё ещё активен.
3. Контроль установленных обновлений на серверах и рабочих станциях.
4. Просмотр запущенных служб и процессов на предмет незнакомых имён.
5. Проверка того, что резервная копия сделалась и открывается.

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

Второе слабое место очевидно. Ночью никто не смотрит.

Когда собирать связку из открытых инструментов?

Главное: связку собирают, когда парк дорос до нескольких десятков машин, а оповещения нужны круглосуточно. Типичный набор: Zabbix или Nagios для метрик и доступности, Grafana для наглядных панелей, Graylog или ELK Stack для централизованного сбора журналов, Fail2Ban против перебора паролей, Ansible и PowerShell для регулярных проверок по расписанию.

Ценность связки в том, что события со всех машин съезжаются в одно место. Журналы, лежащие на самом взломанном сервере, злоумышленник вычистит первым делом. Копия в отдельном хранилище такую уборку переживает.

Часть инструментов мониторинга написана на Go, включая Grafana, поэтому администратору иногда быстрее заглянуть в исходный код, чем в документацию: где используется язык программирования Go.

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

Цена вопроса измеряется временем. Открытые инструменты не стоят денег на лицензии, но берут своё часами настройки, обновлений и разбора ложных тревог.

Кому нужна платформа класса SIEM?

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

Вместе с платформой в компанию приходят подходы, которые в маленьком парке избыточны: Zero Trust с проверкой каждого обращения, ловушки для злоумышленника, встроенный контроль безопасности в конвейере разработки.

Альтернатива своей платформе: отдать мониторинг внешней команде. Схема работает, когда людей в штате нет, а требования есть. Условия у таких услуг сильно разнятся, так что считайте под свой парк и свои риски.

Администратор на этом уровне двигается в сторону автоматизации и разработки, и вопрос про язык программирования встаёт всерьёз. Взвесить помогут плюсы и минусы языка Golang.

Что выбрать в трёх типовых ситуациях?

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

Ситуация первая: маленький офис, один администратор на всё. Включите блокировку перебора паролей, поставьте второй фактор на почту и удалённый доступ, заведите недельный график. Отдельно займитесь сотрудниками: письмо «от банка» открывает человек, и никакой фаервол ему не помешает. Базовую грамотность подтягивают в любом возрасте, тема разобрана здесь: обучение компьютеру для взрослых.

Ситуация вторая: растущая компания, несколько серверов, есть коллега. Централизуйте журналы, поднимите мониторинг метрик, автоматизируйте обновления. Разделите роли: у администратора, разработчика и бухгалтера общей учётной записи быть не должно.

Ситуация третья: инфраструктура под требованиями регулятора. Здесь решает доказуемость. Нужно уметь показать аудитору, кто и когда заходил в систему, где хранятся журналы, как проверяется восстановление данных. Недельный график в тетради такое не закрывает.

На чём нельзя экономить ни в одном варианте?

Главное: три вещи обязательны при любом бюджете. Резервные копии с реальной проверкой восстановления, минимально необходимые права у каждой учётной записи и второй фактор на критичных системах. Четвёртой строкой идут обновления: атаки часто заходят через уязвимость, для которой исправление вышло давно, просто его не поставили.

• Копии по правилу 3-2-1. Три копии данных, два разных носителя, одна копия вне офиса. Шифровальщик добирается до всего, что подключено к сети.
• Проверка восстановления. Копия, которую ни разу не разворачивали, остаётся предположением. Разверните и убедитесь.
• Минимальные права. Ревизию прав делают сразу после увольнения сотрудника, пока о нём помнят все причастные.
• Второй фактор. Удалённый доступ и корпоративная почта закрываются им в первую очередь.
• Журналы отдельно от сервера. Локальный журнал взломанной машины доверия уже не заслуживает.
• Обучение людей. Короткий разговор про фишинг раз в месяц обходится дешевле любого инструмента.

Проверка восстановления сближает работу администратора с работой тестировщика: там та же логика, сценарий прогоняют до того, как он понадобится в бою. Если смежная роль интересна, путь в неё описан отдельно: как стать тестировщиком ПО с нуля.

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

Ещё несколько вопросов

Сколько времени в неделю занимает контроль безопасности?

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

Нужен ли отдельный специалист по безопасности или справится администратор?

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

Что делать в первую очередь при подозрении на взлом?

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

Как понять, что мониторинг настроен впустую?

Верный признак: оповещения приходят десятками, и вы перестали их открывать. Второй признак: за последние месяцы система ни разу не сообщила о реальной проблеме, хотя проблемы были и вы узнали о них от пользователей. Оба случая лечатся пересмотром порогов и правил.

Мешает ли многофакторная аутентификация работе сотрудников?

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

Источники

• ГОСТ Р ИСО/МЭК 27001 «Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования».
• NIST SP 800-92 «Guide to Computer Security Log Management», Национальный институт стандартов и технологий США.
• CIS Benchmarks, рекомендации Center for Internet Security по базовой настройке операционных систем и сетевого оборудования.
• Официальная документация систем мониторинга и сбора журналов: Zabbix, Grafana, Graylog, Elastic, Ansible.