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