директор и машина · право и риски · запись № 011 · 28 июня 2026 · Давид Герштейн

Доступы сотрудников: аудит, который находит уволенных с ключами

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

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

Доступы сотрудников: аудит начинается не с паролей, а с денег

Первая ошибка — считать, что аудит доступов это ИТ-задача. На практике это в первую очередь вопрос контроля над деньгами и обязательствами компании.

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

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

Оба случая — не про пароли. Но именно доступ к клиентской базе, к контактам, к переписке с клиентом делает такую схему возможной. Аудит доступов отвечает на вопрос: кто физически может дотянуться до клиента и данных, минуя систему учёта. Если ответ — «почти любой сотрудник, у кого есть логин», проблема уже создана, осталось дождаться, когда ей воспользуются.

Где чаще всего находят дыры

Личные аккаунты вместо служебных

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

Таблицы и документы с доступом «по ссылке»

В одной компании обнаружили: множество таблиц с финансовой информацией и данными клиентов открыты для всех, у кого есть ссылка. Не для конкретных людей — для любого, кто ссылку получил. Собственница запросила аудит всех таблиц и удаление посторонних адресов из совместных документов. В другом случае конфиденциальная информация — кошельки, данные менеджеров, сведения о компаниях — оказалась в открытом JavaScript-файле на публичном сервере. Файл индексировали поисковики. То есть данные не украли — их выложили сами, по невнимательности при настройке.

Доступ третьих лиц через внешний портал

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

Права доступа к данным: минимум, а не «на всякий случай»

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

Похожий принцип сформулировали для совместных документов: «один человек — одна таблица». Это разграничение прав, которое предотвращает конфликт между автоматическим обновлением и ручным редактированием — и заодно снимает вопрос, кто именно испортил данные, если что-то пошло не так. Когда за таблицу отвечает один человек, аудит доступов превращается в простую сверку: у кого есть права редактирования, должно совпадать со списком тех, кто реально должен туда писать.

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

Закрыть доступы после увольнения — не разовая акция

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

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

Вторая часть регламента — чек-лист на день увольнения. Не «через неделю кто-нибудь вспомнит», а список: какие сервисы, какие таблицы, какие мессенджеры, какие общие ящики. Без такого списка отзыв доступа держится на памяти руководителя, а память подводит именно в конфликтных увольнениях — когда цена ошибки выше всего.

Отдельно стоит вопрос блокировки самой платформы, а не человека. При внедрении бота в мессенджер обнаружили: платформа может заблокировать номер при нестандартном использовании. Решение — завести отдельный тестовый номер для проверки, прежде чем выводить бота на рабочий канал. Логику продолжает подход, который использовали в другой команде: «мы работаем в коде, потому что единственный способ устоять при блокировке — это чтобы все файлы были у тебя, и ты не зависела от доступа к учётной записи». Аудит доступов должен отвечать и на этот вопрос: что случится с операционкой, если один сервис исчезнет или заблокирует конкретный аккаунт.

ИИ-связка: как автоматизировать сверку доступов

Ручная сверка «кто уволен — у кого остались права» работает, пока в компании небольшая команда и несколько сервисов. На полусотне людей и полутора десятках систем (CRM, облачные таблицы, боты, порталы) это уже задача для регулярного скрипта, а не для памяти HR-менеджера. Собирать всё вручную каждый квартал — дорого по времени и ненадёжно: список из полутора десятков вкладок никто не сверяет построчно два раза подряд.

Конвейер простой: раз в неделю скрипт выгружает список активных сотрудников (из HR-таблицы или через API CRM — например, список пользователей amoCRM) и список выданных доступов (ведётся отделом в отдельном листе Google Sheets), сводит их в один JSON и отправляет дешёвой модели на классификацию расхождений. Результат падает в лист «Аномалии», критичные случаи — сразу уведомлением ответственному.

Схема: HR-таблица + список доступов → Google Apps Script собирает JSON → запрос к LLM API → ответ пишется в лист «Аномалии» → high-risk строки триггерят уведомление в Telegram. Модель нужна дешёвая — задача не творческая, а классификационная: сопоставить статус сотрудника с датой последнего доступа и вернуть структурированный список. Гонять её на дорогой модели — переплата без пользы.

Ты — ассистент по аудиту доступов сотрудников. На входе — список записей о доступах в формате JSON.

Формат одной записи:
{
  "email": "...",
  "service": "...",
  "access_level": "...",
  "granted_date": "YYYY-MM-DD",
  "last_active_date": "YYYY-MM-DD или пусто",
  "employee_status": "active" | "fired" | "unknown",
  "fired_date": "YYYY-MM-DD или пусто"
}

Задача:
1. Найди записи, где employee_status = "fired", но доступ не отозван
   (last_active_date позже fired_date или запись вообще не помечена как отозванная).
2. Найди записи, где service привязан к личному email (домен не совпадает
   с корпоративным doman company.ru).
3. Найди дубли: один и тот же service с одинаковым access_level у разных
   email без явного указания, кто из них ответственный.
4. Для каждой найденной аномалии укажи риск: "низкий", "средний" или "высокий"
   и короткую причину на русском.

Верни СТРОГО JSON-массив, без пояснений вокруг:
[{"email": "...", "service": "...", "issue": "...", "risk": "..."}]

Входные данные:
{{ДАННЫЕ_ИЗ_GOOGLE_SHEETS}}

Пример ответа модели:

[
  {"email": "ivanov@gmail.com", "service": "Telegram-бот CRM", "issue": "уволен 3 месяца назад, доступ активен", "risk": "высокий"},
  {"email": "petrova@company.ru", "service": "Google Sheets: Финансы Q2", "issue": "доступ по ссылке, не именной", "risk": "средний"},
  {"email": "sidorov@company.ru", "service": "Портал клиентов", "issue": "дубль прав с уволенным аккаунтом", "risk": "низкий"}
]

Так это выглядит уже не в JSON, а в самом рабочем листе, куда падает результат:

Инженерная обвязка: скрипт крутится на Google Apps Script с триггером по расписанию раз в неделю, читает два листа (сотрудники, доступы), формирует JSON и обращается к LLM через HTTP-запрос. Результат пишется в третий лист «Аномалии» с меткой времени. Если сервис недоступен — три повторные попытки с паузой, при неудаче запись падает в лист «Ошибки» и уходит уведомление ответственному за доступы, а не молча теряется. Ключ к LLM API и токены к CRM хранятся в свойствах скрипта, а не в самом коде таблицы — тот же принцип «минимально необходимые права», что и в истории с API-токенами выше. Если данные о пользователях идут из Bitrix24 через вебхук, тот же принцип разбирал я в статье про то, как CRM врёт с датами — прежде чем строить на вебхуке аудит доступов, стоит убедиться, что сами даты и статусы в CRM не съезжают.

Разница в трудозатратах между ручным и автоматическим вариантом наглядно видна на диаграмме ниже.

Экономика: во сколько раз автоматическая сверка выгоднее ручной

Формула для ручной сверки простая: число сервисов × среднее время проверки одного сервиса = трудозатраты одного цикла. На сбор списка активных сотрудников, проход по сервису и сверку прав обычно уходит 30–40 минут на сервис (оценка). Для 15 сервисов это 15 × 40 минут ≈ 10 часов — отсюда и берётся цифра на графике выше. Один квартальный проход стоит компании как 10 часов работы ответственного, а за год из четырёх проходов — около 40 часов той же работы (оценка). Если у вас 5 сервисов и меньше сотрудников, время пропорционально меньше — например, около 3 часов на проход: подставьте своё число сервисов в ту же формулу.

Внедрение автоматической сверки: настройка скрипта, промпта и тестового прогона на реальных данных — оценочно 8–10 часов работы одного человека, разовые вложения на старте, сопоставимые с одним ручным квартальным проходом. Дальше скрипт бегает сам раз в неделю, но кто-то должен поддерживать актуальность двух исходных листов (около 20 минут в неделю, оценка) и просматривать лист «Аномалии» (около 15 минут в неделю, оценка) — вместе это порядка 30 часов в год, то есть заметно меньше, чем 40 часов на четыре ручных прохода. Расход на токены дешёвой модели для компании среднего размера с полутора десятками сервисов — величина существенно ниже одной часовой ставки специалиста в месяц, то есть фоновая статья расходов, а не значимая.

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

Было — ручная сверка раз в квартал, 4 прохода в год. Стало — автоматический прогон раз в неделю, 52 прохода в год.

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

Куда уходят данные: облака, ИИ и юридические риски

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

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

С чего начать в понедельник

1. Выгрузить список всех сервисов, где хранятся данные клиентов, финансов или переписка с клиентом.
2. По каждому сервису проверить: аккаунт служебный или личный. Личные — в план перевода на служебные, с датой.
3. Пройтись по облачным таблицам и документам, найти доступ «по ссылке» вместо именного и закрыть.
4. Составить чек-лист отзыва доступов на день увольнения: сервисы, таблицы, мессенджеры, общие ящики — списком, а не по памяти.
5. Назначить одного ответственного за квартальную ревизию доступов — с датой в календаре, а не «когда-нибудь».
6. Если сервисов больше десяти — запланировать автоматическую сверку по модели из этой статьи вместо ручной раз в квартал.

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

Частые вопросы

Как закрыть доступы после увольнения сотрудника?

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

Что проверять при аудите прав доступа к данным?

Кто имеет доступ к таблицам с финансами и клиентскими данными, открыт ли доступ «по ссылке» вместо именного, используются ли личные аккаунты вместо служебных, и куда уходят чувствительные ссылки — в код или в открытые каналы.

Почему открытая таблица с доступом «по ссылке» — это риск?

Такую таблицу может проиндексировать поисковик или найти любой, у кого оказалась ссылка — без пароля и без записи, кто именно смотрел данные.

#контроль и надёжность #инструменты #ошибки и провалы