Доступы, которые никто не отзывал: учётки бывших сотрудников и подрядчиков в ваших системах

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

Интересен не сам случай, а механика, которая делает такие случаи закономерными.

Почему доступы только расширяются

Доступ выдаётся в момент, когда он нужен. У выдачи есть всё, чтобы она состоялась:

заказчик — «мне нужно для работы»;
исполнитель, который выдаёт право;
срочность.

Это событие: оно происходит, фиксируется, о нём помнят.

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

При уходе человека закрывают очевидное — учётную запись и почту. Автоматические выгрузки, интеграции, подключённые сервисы, правила пересылки в чек-лист увольнения не попадают: о них помнит только тот, кто их настраивал.

Отсюда единственное направление, в котором контур доступов меняется сам по себе, — расширение. Через несколько лет фактическая карта доступов не совпадает ни с чьими представлениями о ней. Не потому, что кто-то так задумал, а потому, что эту карту никто не ведёт.

Учётка подрядчика внутри интеграции

Отдельный и очень частый вариант той же истории — интеграция, построенная на личной учётной записи.

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

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

Главное свойство этой истории: снаружи «работает» и «правильно устроено» неотличимы. Обе версии интеграции ведут себя одинаково, день за днём, без сбоев. Разница между временным и несущим видна только тогда, когда конструкцию пробуют разобрать — обычно в самый неудобный момент, при смене подрядчика или сотрудника.

Что проверить в своих системах

Небольшой список, с которого удобно начать ревизию портала Битрикс24 и связанных систем:

Активные пользователи. Нет ли среди них уволенных сотрудников и бывших подрядчиков, у которых остался вход.
Ответственные в роботах и бизнес-процессах. Не назначаются ли задачи, сделки и уведомления на неактивных сотрудников. Такие процессы не падают с ошибкой — они молча работают вхолостую.
Вебхуки и приложения. Кто их создал, под чьими правами они работают и используются ли сейчас.
Интеграции с 1С, почтой, телефонией, сайтом. Под какими учётными записями они работают: технической или личной.
Правила пересылки и рассылки. Не уходят ли письма и документы на зашитые адреса, которые давно никому не принадлежат.
Хранение доступов. Где лежат пароли от сервисов: в защищённом хранилище или в переписке.

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

Вывод

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

Мы регулярно проводим аудит порталов Битрикс24, в том числе настроенных другими подрядчиками: собираем карту роботов, бизнес-процессов и интеграций и показываем, где что держится на чужих учётках и неактивных сотрудниках. Доступы клиентов при этом храним в собственном защищённом сейфе, а не в переписке. Если хотите проверить свой портал — напишите, начнём с короткого разговора.