Вторник, утро: половина склада не может попасть в систему. Туннель отвалился ночью. Никто не заметил: ночью никто и не работал, а утром решили, что «само пройдёт». Второй сценарий хуже, и мне он попадался чаще, чем хотелось бы: через два месяца после ухода сотрудника выясняется, что его учётка исправно подключалась всё это время, а откуда и что делала — непонятно, журналы либо не велись, либо перезаписались. Дальше идёт фантазия «а вдруг ничего страшного». Обычно страшное было. Доказать нечем.
Оба случая лечатся мониторингом — не в смысле «следить за людьми», а в смысле просто знать, что в каждый момент происходит с вашей инфраструктурой и кто в ней есть. Граница тут принципиальная, ей я посвятил отдельный раздел: на ней ломается половина внедрений.
Зачем вообще мониторить VPN
Доступность. Туннель падает: авария у провайдера, перезагрузка сервера, протухший сертификат. Без мониторинга вы узнаёте об этом от людей, в формулировке «у нас ничего не работает, сделайте что-нибудь», и уже виноваты. С мониторингом — от системы, минут за пятнадцать до первого звонка. Заметить обрыв раньше, чем о нём сообщат сотрудники, — по-моему, достаточная причина всё это настраивать. Остальное бонусом.
Безопасность. Компрометация учётки выглядит в журналах как совершенно обычная работа, если не смотреть на контекст, и именно контекст её в итоге выдаёт: подключение из региона, где у вас никого нет, или вход в четыре утра у человека с графиком с девяти.
Порядок в хозяйстве. Журнал подключений отвечает на вопросы, на которые иначе не ответит никто: кем реально пользуется доступ, нужен ли он ещё, кто подключался в ту ночь, когда всё сломалось. Мне этот пункт нравится больше предыдущих. Плюс это фактура для ревизии прав из материала про политику доступа к VPN.
Что можно и стоит фиксировать
Полезный минимум по сессии умещается, если честно, в несколько полей, и собрать их умеет почти любой сервер — вопрос лишь в том, чтобы кто-то включил запись и потом заглянул.
- Кто — учётная запись. Поэтому персональные доступы важнее общего конфига: с общим все строчки одинаковы.
- Когда — время начала и конца сессии.
- Откуда — внешний адрес, страна и регион.
- Сколько — длительность и объём данных.
- Как — устройство, версия клиента, протокол.
- Неудачи — отклонённые попытки с причиной: пароль, второй фактор, отозванный сертификат.
- Администрирование — выдача и отзыв доступа, сброс 2FA, смена группы.
Последняя строка, кстати, самая недооценённая: административные записи ценнее всего при разборе инцидента, а ведут их реже всего, и я не знаю, почему так.
Объёмы трафика — тоже метрика полезная, но не в смысле «кто много качает», а в смысле «почему у бухгалтера за ночь ушло сорок гигабайт наружу». Разница, скажем так, принципиальная.
[Изображение: макет дашборда мониторинга]
Что фиксировать не нужно и почему
Этот раздел я считаю самым важным в статье, хотя настроек в нём нет ни одной. Технически со шлюза можно снять очень много: список посещённых сайтов, содержимое незашифрованных сессий, при желании и расшифрованных. Соблазн понятен. Раз уж строим контроль — давайте контролировать всё. Не надо. Причин три, и все практические.
Юридическая. Данные о том, что человек делал в интернете, — чувствительная информация, и чем больше вы её собираете, тем тяжелее последствия, если она утечёт. Закон разграничивает контроль за рабочими ресурсами и вторжение в личную переписку. Вторая территория для работодателя закрыта. Сразу оговорюсь: это не юридическая консультация, с конкретикой к юристу.
Практическая. Тотальная слежка производит терабайты, в которых, думаю, никто и не разберётся, полезный сигнал тонет там первым, а мониторинг, который никто не читает, — уже не мониторинг, а склад.
Человеческая. Люди чувствуют, когда за ними следят сверх меры, и обходят систему: личный телефон вместо ноутбука, рабочие файлы в личном облаке. Контроля становится меньше, чем было до внедрения. Я видел этот разворот сам.
Камера на входе в офис — нормально, все понимают зачем. Камера, направленная в экран сотрудника, — другая история, и работает она наоборот. Так что не трогайте содержимое трафика и переписки, историю сайтов, кейлоггеры, скриншоты, геопозицию и всё, что происходит вне туннеля. И организационный момент, закрывающий половину вопросов: зафиксируйте в политике, что собираете и на какой срок, ознакомьте людей под подпись. Прозрачный мониторинг воспринимают спокойно. Тайный отравляет атмосферу, и повторять этот опыт я не хочу.
Метрики доступности
Доступность точки входа. Проверка снаружи, раз в минуту, лучше из нескольких мест. Изнутри сети проверять бессмысленно, и я на этом обжёгся: точка бывает доступна вам и совершенно недоступна половине страны.
Состояние постоянных туннелей. Если офисы связаны между собой, каждый канал мониторится отдельно, с задержкой и потерями: обрыв между офисом и складом замечают не сразу и не те, кто чинит. Подробнее — в статье про объединение офисов.
Частота переподключений. Метрика недооценённая, а я к ней отношусь с нежностью. Если сессия рвётся сорок раз за день, то у человека не «иногда тупит интернет», а конкретная проблема, которую он молча терпит и о которой вы узнаете последним.
Задержка и потери. Критично, если внутри туннеля работают с 1С или рабочим столом, потому что отзывчивость там упирается именно в задержку, а не в ширину канала. Разбор — в материале про удалённый доступ к серверу и 1С.
Нагрузка на сервер. Процессор, память, полоса. Скучно, не спорю, но именно здесь заранее видна деградация, которую иначе заметишь по жалобам.
Метрики безопасности
Тут работает не абсолютное значение, а отклонение от привычной картины. Сначала неделю-другую копите данные, потом настраивайте пороги — иначе, по моему опыту, получите шквал ложных срабатываний в первый день.
Нетипичная география. Базовый триггер. Сотрудник, всегда подключавшийся из одного города, вдруг заходит из другой страны — повод проверить учётку. Не паниковать, а позвонить: командировки существуют, и я в неловкое положение попадал.
Невозможные перемещения. Две сессии подряд из точек, между которыми физически не успеть переместиться, — признак сильный, и ложных срабатываний у него, скажем так, совсем мало.
Нерабочее время. Само по себе не значит ничего, люди задерживаются, но в сочетании с другими отклонениями признак заметно поднимает приоритет.
Всплеск неудачных попыток. Десятки отказов по одной учётке — подбор пароля, а отказы на втором факторе при верном пароле куда хуже: значит, пароль уже у кого-то есть.
Параллельные сессии и объём данных. Один логин с двух адресов сразу — иногда забытый дома ноутбук, иногда нет. Резкий рост исходящего трафика у того, кто живёт в почте, — тоже повод.
Оповещения: на что реагировать немедленно
Главная ошибка при настройке — включить оповещения на всё подряд: через неделю их начинают игнорировать, и я, честно говоря, не знаю ни одного исключения из этого правила ни в одной компании. Приоритеты нужны с самого начала.
| Событие | Приоритет | Действие |
|---|---|---|
| Успешный вход после серии неудачных попыток | Критический | Прервать сессию, связаться с сотрудником, сменить пароль и второй фактор |
| Активность учётки уволенного | Критический | Отозвать доступ, проверить, что ещё осталось активным |
| Невозможное перемещение между сессиями | Критический | Прервать сессию, подтвердить личность по телефону |
| Точка входа недоступна | Критический | Проверить сервер и канал, уведомить пользователей |
| Подключение из нетипичной страны | Высокий | Позвонить сотруднику и уточнить |
| Всплеск отказов на втором факторе | Высокий | Проверить, не утёк ли пароль, сменить |
| Обрыв туннеля между офисами | Высокий | Диагностика канала, переключение на резерв |
| Аномальный исходящий трафик | Средний | Разобраться в течение рабочего дня |
| Рост переподключений у пользователя | Средний | Проверить его канал и настройки |
| Учётка без активности больше двух месяцев | Низкий | В список на ближайшую ревизию |
Правило простое: критических оповещений должно быть мало. Больше двух-трёх в неделю — пороги неверны, и скоро их перестанут читать.
Как по журналам восстановить картину инцидента
Разберу на условном примере, собранном из тех, что я видел. Пятница, утро. Сработало оповещение: вход под учёткой менеджера в 03:40, адрес из страны, где у компании никого нет.
Сначала зафиксировать, не трогая. Выгрузить и сохранить журналы отдельно, до любых действий, потому что если начать с блокировки и перенастройки, то часть картины пропадёт безвозвратно и восстановить её будет уже нечем — я так терял след дважды.
Дальше размотать назад. Смотрим историю учётки: за два дня до этого серия неудачных попыток, около сорока за полчаса, потом тишина, потом успешный вход. Вывод напрашивается сам. Пароль подобрали или получили, а второй фактор либо не был включён, либо его обошли через восстановление. Проверяем административные события — не сбрасывал ли кто-то этому пользователю 2FA. Вот тут, к слову, и выясняется, вели вы такие записи или нет.
Потом смотрим, что делали внутри. Журнал VPN покажет объём и длительность сессии, а что именно трогали — это уже в журналах самих ресурсов: файлового сервера, 1С, почты, и хорошо, если они тоже ведутся.
Изоляция. Прервать сессии, заблокировать учётку, сменить пароль и перевыпустить второй фактор, заодно проверив системы с тем же паролем.
Взгляд шире. Один скомпрометированный аккаунт, по моему опыту, редко бывает один, так что посмотрите, не было ли похожих попыток по другим учёткам с тех же адресов.
И выводы на бумаге. Что именно позволило этому случиться. Ответ находится быстро и почти всегда один и тот же: второй фактор был не у всех, маршрут выдавал всю подсеть, а оповещение на серию отказов никто так и не настроил.
Ключевой момент, ради которого всё и строится: без журналов на втором шаге пустота, вы знаете только, что что-то случилось, и больше ничего.
[Изображение: схема расследования инцидента по журналам]
Хранение журналов: сроки, объём и защита
Журналы подключений — сами по себе чувствительные данные: по ним видно, кто где был и когда работал, так что утечка такого архива это отдельный инцидент, неприятный вдвойне.
Отдельно от источника. Логи, лежащие только на описываемом ими сервере, при проникновении бесполезны: чистка журналов — стандартный шаг, так что копия должна уходить в отдельное хранилище.
Ограниченный доступ. Смотреть журналы должны не все администраторы подряд, а конкретные названные люди, и доступ к самим журналам тоже логируется — иначе выходит охрана, которую не охраняют.
Разумные сроки. Точные требования зависят от того, под какое регулирование попадает ваша отрасль, — снова к юристу. Мой ориентир: подключения и аутентификацию держать от полугода до года, детальные метрики — месяца три. Хранить вечно — впрочем, тут я повторяюсь — не осторожность, а накопление риска.
Чек-лист построения мониторинга
- Доступы персональные, в журналах видно людей.
- Фиксируются подключения, отключения, отказы и действия админов.
- В политике записано, что собирается и на какой срок.
- Есть внешняя проверка доступности точки входа.
- Постоянные туннели мониторятся отдельно.
- Оповещения расставлены по приоритетам, критических мало.
- Журналы уходят в отдельное хранилище.
- Сроки хранения определены, удаление реально происходит.
- Есть написанный порядок действий при инциденте.
Что сделать в первую очередь
Если строить всё сразу, не построите ничего, и говорю я это как человек, который дважды начинал с красивых дашбордов и заканчивал ничем. Сначала журнал подключений с персональными учётками и внешняя проверка доступности — две вещи, закрывающие большинство сценариев. Потом три-четыре оповещения на критичные события. Не двадцать. И только затем дашборды: без первых двух пунктов они бесполезны, хотя выглядят, что скрывать, эффектнее всего.
Собирать руками необязательно: мониторинг VPN идёт готовым — журнал подключений, метрики доступности, оповещения по правилам. Подключается к корпоративному VPN и к выделенному серверу, две недели теста без карты. За это время накопится база для порогов.
Частые вопросы
Что можно отслеживать в корпоративном VPN?
Факты подключений: учётную запись, время начала и конца, внешний адрес и регион, длительность, объём трафика, устройство. Плюс неудачные попытки и административные действия — выдачу и отзыв доступа, сброс 2FA. Содержимое трафика и переписки в этот список, по моему убеждению, входить не должно.
Законно ли мониторить подключения сотрудников?
Контроль корпоративных ресурсов допустим, если он прозрачен: собираемые данные описаны во внутреннем документе, сотрудники с ним ознакомлены. Личная переписка — территория, куда работодателю нельзя. Это не юридическая консультация: формулировку лучше согласовать с юристом.
Как долго хранить логи VPN?
Зависит от требований к вашей отрасли. Ориентир: журналы подключений и аутентификации — от полугода до года, детальные метрики — около трёх месяцев. Меньше трёх месяцев смысла нет: инциденты часто обнаруживаются с задержкой.
Какие события требуют оповещения?
Критично: успешный вход после серии неудачных попыток, активность учётки уволенного, невозможное перемещение, недоступность точки входа. Высокий приоритет: нетипичная страна, всплеск отказов на втором факторе, обрыв туннеля. Остальное разбирается в рабочем порядке, иначе оповещения перестают читать.
