Короткий ответ
Подрядчику выдавайте только тот минимум прав, который нужен для текущей задачи, привязывайте доступ к конкретному человеку и конечной дате, а отключение делайте автоматическим. Принцип минимальных привилегий, по определению NIST, ограничивает права пользователя ровно тем объёмом, который требуется для выполнения назначенных задач. Применяйте его одинаково к логическому доступу (диспетчеризация, серверы, сети) и к физическим пропускам, затем проверяйте результат регулярными аудитами и журналами событий.
Главные выводы
- Минимальные права задаются для каждой системы и зоны отдельно, а не один раз для всей фирмы-подрядчика; права на СКУД и на сервер не должны выдаваться автоматически вместе.
- Доступ подрядчика — временный по определению: конечная дата, имя конкретного исполнителя и перечень задач фиксируются при выдаче, а не задним числом.
- Отключение должно срабатывать автоматически по триггерам: окончание договора, уход ответственного сотрудника, смена объёма работ и сверка реестра действующих подрядов.
- Постоянный круглосуточный удалённый доступ, который требуют некоторые вендоры, по возможности заменяется разовыми сеансами или шлюзами с записью действий.
- Доверенные системы должны управлять менее доверенными (принцип browse-down); оборудование подрядчика не может администрировать вашу сеть более высокого уровня доверия.
- Без журналов входа/выхода, сессий и событий доступа расследование инцидента и контроль за подрядчиком практически невозможны.
Что понимать под «системами объекта» и где применять минимальные права
На объекте недвижимости «системами» оказываются не только серверы. Подрядчик по обслуживанию может работать с контроллером здания (BMS), отвечающим за отопление, вентиляцию и освещение, с панелями СКУД, с контроллером лифта, с портом пожарной сигнализации или с сетью Wi-Fi и камерами арендаторов. Каждый такой элемент — отдельный актив со своей моделью риска и своим способом выдать, ограничить и отозвать доступ.
Принцип минимально необходимых прав NIST формулирует как ограничение привилегий пользователя тем минимумом, который требуется для выполнения назначенных задач. На практике это означает: решения о доступе принимаются по каждому активу и каждой роли, а не по принципу «раз фирма аккредитована — пусть заходит всюду». Техник с пропуском в технический этаж не должен автоматически получать учётную запись на сервере диспетчеризации, и наоборот. Оба решения оформляются раздельно, даже если записаны в рамках одного договора.
Российские интеграторы, проектируя СКУД для гибридных офисов, исходят из той же модели: каждой категории (постоянные сотрудники, подрядчики, гости, курьеры, обслуживающий персонал) заранее назначается свой набор зон и временных окон. Такой ролевой подход — база и для логических систем здания.
- Типовые активы подрядчика: BMS/диспетчеризация, СКУД и двери, лифты и эскалаторы, пожарная и охранная сигнализация, инженерные сети (электроснабжение, отопление), IT-инфраструктура и видеонаблюдение.
- Для каждого актива фиксируются: кто запрашивает, какая зона/функция нужна, на какой срок и кто отвечает за выдачу.
- Физический пропуск и логическая учётная запись — это два независимых решения, даже если оформляются по одному заказу-наряду.
Почему доступ подрядчиков «расползается» и становится постоянным
Главная особенность подрядчика в том, что его учётная запись не проходит обычный жизненный цикл сотрудника: нет HR-увольнения, которое заставило бы закрыть доступ. Договор завершился, ответственный менеджер уволился или перешёл на другой проект — а пропуск и логин продолжают работать. NCSC прямо относит эту категорию к рискам цепочки поставок и рекомендует досконально знать, какой физический и логический доступ имеют подрядчики и их субподрядчики к вашим системам и помещениям.
Вторая типичная проблема — общие учётные записи и «служебные» доступы, которые вендор оставляет для себя. NCSC предупреждает: третья сторона, устанавливающая оборудование, может внести каналы связи, о которых вы не знаете, например 4G-модем внутри устройства, открывающий подрядчику постоянный удалённый доступ в вашу сеть. Такой «серый» канал не виден в ваших журналах и не управляется вашей политикой.
Итог — так называемый access creep: «временные» права незаметно превращаются в бессрочные, а доступ одного техника распространяется на субподрядчиков его компании. Любой из этих забытых каналов может стать точкой входа для атакующего.
- Проверяйте, какие субподрядчики и сервисные инженеры реально имеют доступ через вашего прямого подрядчика.
- Ищите и удаляйте обходные каналы: модемы, Wi-Fi для настройки, съёмные носители с конфигурацией, оставленные «на всякий случай» порты.
- Отделяйте доступ по текущему договору от исторических учётных записей той же фирмы, выданных в прошлых проектах.
Как проектировать ограниченный по времени доступ
Рабочая схема — выдавать права по готовым шаблонам ролей (например, «сервисный инженер BMS», «монтажник СКУД», «техник лифтов»), где заранее задан перечень зон и функций, а не по индивидуальному набору каждый раз. Внутри роли доступ ограничивается временным окном: подрядчик по уборке может входить в рабочие часы, а обслуживающий персонал — вечером. Такой же принцип применяется к логическим системам: доступ к серверу открывается на конкретный наряд и закрывается по его завершении.
Где возможно, используйте разовый (just-in-time) доступ вместо постоянного. NCSC в рекомендациях по операционным технологиям напоминает: требование вендора о круглосуточном удалённом доступе часто можно заменить плановыми сеансами; если требование неустранимо, обязательны компенсирующие меры — сегментация сети и запись действий третьей стороны.
Действует принцип browse-down: система более высокого уровня доверия управляет системой более низкого уровня, а не наоборот. Если подрядчик администрирует ваш контроллер здания, его сегмент сети должен быть ниже по уровню доверия и изолирован от остальных систем, чтобы техник не мог попасть в вашу основную сеть.
- Шаблон роли содержит: имя исполнителя, фирму, объект, зоны/функции, время действия и контакт ответственного заказчика.
- По умолчанию предпочтителен доступ на один наряд или одну смену с возможностью продления только по явному решению.
- Удалённый доступ — только через управляемый шлюз с многофакторной аутентификацией и записью сессии, а не через прямые порты оборудования.
- Разделение обязанностей: тот, кто выдаёт доступ, не должен быть единственным, кто его проверяет и отключает.
Автоматическое отключение: триггеры и сверка реестра
Автоматическое отключение должно срабатывать не только в дату окончания договора. Практичные триггеры: завершение срока действия пропуска, увольнение или перевод ответственного сотрудника-спонсора, изменение объёма работ, неявка исполнителя или расторжение договора. Каждый такой случай запускает отзыв прав в обеих областях — и в СКУД, и в учётных записях.
Надёжность схемы зависит от сверки. Раз в месяц (или чаще для крупных объектов) сопоставляйте фактически активные учётные записи и пропуски со списком действующих договоров и нарядов. Всё, чего нет в реестре, блокируется или помечается на проверку. Полезно измерять время отзыва — интервал между моментом, когда доступ перестал быть нужен, и моментом, когда он фактически закрыт; цель — часы, а не недели.
Продление не должно быть молчаливым продолжением старого доступа. После истечения срока права автоматически блокируются, и новый период открывается только после повторного запроса и одобрения. Так исключается ситуация, когда «временные» права живут годами просто потому, что никто не обратил на них внимание.
- Триггер 1: плановая дата окончания договора или наряда.
- Триггер 2: увольнение/перевод ответственного сотрудника заказчика.
- Триггер 3: расторжение или изменение договора, смена субподрядчика.
- Триггер 4: длительная неактивность или ночная активность вне графика работ.
- Сверка реестра доступов со списком активных договоров — на регулярной основе.
Наблюдение, журналы и проверка
Доступ, который не логируется, — это слепое пятно. Современная СКУД фиксирует каждое прохождение точки доступа: кто, когда и в какую зону вошёл, а также запрещает повторный вход без фиксации выхода (анти-пассбэк). Аналогично логические системы должны вести журнал сессий подрядчика: время подключения, выполненные команды, использованные учётные записи. Журналы особенно ценны при расследовании инцидента, когда нужно за минуты восстановить маршрут человека по объекту и его действия в системах.
Интеграция с видеонаблюдением усиливает контроль: событие доступа в зону можно сопоставить с видеокадром и действиями в системе. Регулярные проверки прав (не реже одного раза в квартал) показывают, не накопились ли лишние роли и не появились ли необъяснимые учётные записи. Любое изменение прав оформляется документированным запросом и одобрением, иначе у вас не будет основания ни выдать, ни отозвать доступ.
Если речь идёт об объектах, попадающих под отраслевое регулирование (например, о значимых объектах критической информационной инфраструктуры в РФ), требования к разграничению доступа заданы нормативными документами регулятора. Проверяйте действующую редакцию требований для своей отрасли и юрисдикции — перечисленные выше практики служат общей базой, но не заменяют обязательных норм.
- Журнал проходов СКУД и журнал логических сессий храните столько, сколько требует политика объекта и регулирование.
- Настройте оповещения о доступе вне графика работ и о попытках входа с неожиданных адресов.
- Ежеквартальная проверка прав: владелец каждой системы подтверждает, что роли актуальны.
- При увольнении техника или расторжении договора сверяйте и закрывайте и его, и корпоративные доступы фирмы-подрядчика.
Практический инструмент
Чек-лист управления доступом подрядчика к системам объекта
Чек-лист проходит по жизненному циклу доступа: до выдачи, при выдаче, во время работ и после завершения. Используйте его как основу регламента и как исходный список для аудита действующих доступов.
- До выдачи: определён перечень систем/зон, нужных для конкретного наряда, и отдельно перечислены системы, к которым доступ запрещён.
- До выдачи: зафиксированы имя исполнителя, фирма, субподрядчики и ответственный сотрудник заказчика (спонсор).
- До выдачи: согласованы конечная дата и временное окно работы, а также правило продления только по явному решению.
- Выдача: создана именная, а не общая учётная запись; пропуск и логический логин оформлены как два независимых решения.
- Выдача: удалённый доступ идёт только через управляемый шлюз с многофакторной аутентификацией и записью сессии.
- Выдача: проверено, что сегмент сети подрядчика ниже по уровню доверия и изолирован (принцип browse-down).
- Работа: включены журналы проходов, сессий и действий; настроены оповещения о доступе вне графика.
- Работа: проведена проверка на скрытые каналы связи, установленные вместе с оборудованием (модемы, Wi-Fi).
- Завершение: сработало автоматическое отключение по дате или триггеру; время отзыва зафиксировано и не превышает суток.
- Завершение: сверка реестра доступов со списком активных договоров выполнена; все лишние права закрыты.
- Аудит: ежеквартально владельцы систем подтверждают актуальность каждой роли подрядчика.
- Аудит: любой отказ в доступе, инцидент или подозрительная активность документирован и передан ответственному лицу.
Частые вопросы
Что такое «минимальные права» на практике для разового визита сервисного инженера?
Минимальные права означают, что инженер получает ровно те функции и зоны, которые нужны для конкретного наряда: например, доступ к конкретному контроллеру BMS или к техническому этажу, но не к серверной и не к данным арендаторов. Ничего «на всякий случай» и ничего на срок дольше наряда. NIST определяет этот принцип как ограничение привилегий минимумом, необходимым для выполнения назначенных задач.
Что должно автоматически отключать доступ, если подрядчик продлил договор или уволился ответственный сотрудник?
Отключение должны запускать несколько триггеров: истечение даты, увольнение или перевод спонсора, изменение договора, неявка исполнителя. Продление не должно автоматически продолжаться — после блокировки новый период открывается только по новому запросу. Регулярная сверка реестра доступов со списком активных договоров ловит те права, которые не затронул ни один триггер.
Можно ли подрядчику давать общую учётную запись вместо именной?
Не рекомендуется. Общая учётная запись не позволяет установить, кто именно выполнил действие, а после ухода одного техника доступ остаётся у всей группы. Именные учётные записи делают возможными контроль, отзыв прав конкретного человека и расследование инцидента. Принципы NCSC по цепочке поставок прямо требуют понимать, какой физический и логический доступ имеют конкретные исполнители.
Вендор требует круглосуточный удалённый доступ к диспетчеризации. Как быть?
Попробуйте заменить постоянный доступ плановыми сеансами через управляемый шлюз с записью действий и многофакторной аутентификацией. Если требование неустранимо, применяйте компенсирующие меры: изолируйте сегмент подрядчика, ограничьте его доступ только нужными активами и ведите полный журнал его действий. Убедитесь также, что оборудование вендора не добавило скрытых каналов вроде 4G-модема.
Как часто нужно пересматривать права доступа подрядчиков?
Практичный минимум — ежеквартальная проверка, при которой владелец каждой системы подтверждает актуальность ролей. Для критичных зон и крупных объектов сверку реестра со списком договоров стоит делать ежемесячно. Отдельные проверки запускаются событием: увольнение спонсора, расторжение договора, инцидент или выявленная аномальная активность.
Источники и дополнительные материалы
Источники проверены при подготовке страницы. Изменяемые даты, нормы и цены уточняйте у первоисточника.
- Least Privilege — Glossary | CSRC (NIST)National Institute of Standards and Technology (NIST)
- Zero Trust Maturity ModelCybersecurity and Infrastructure Security Agency (CISA)
- Cross-Sector Cybersecurity Performance GoalsCybersecurity and Infrastructure Security Agency (CISA)
- Supply Chain Security — Principle 1: Understand the RisksUK National Cyber Security Centre (NCSC)
- Operational Technology — Principle 5: Third-Party Risks to Your OT SystemUK National Cyber Security Centre (NCSC)
- СКУД для офисов с гибридным режимом: гости, курьеры, подрядчики, временные доступыАйПи Решения