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

Права доступа сотрудников: кто ещё может зайти в ваши системы

Суммы в разборе пересчитаны на условную компанию — пропорции, механика и выводы реальные.

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

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

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

Аудит начинается не с паролей, а с денег

Считайте не риски в абстракции, а конкретно: что произойдёт с вашим бизнесом, если завтра эти данные окажутся у конкурента.

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

Руководитель отдела, доверенное лицо, заключил договор на консультационные услуги с клиентом компании на 500 000 ₽ — около 6% месячного оборота условной компании (9 млн ₽/мес при отделе из 8 менеджеров). Клиенту такие услуги компания не оказывает — их не должно было существовать. Деньги получены, чек не выписан, договор подписан на ИП сотрудника. Руководство прямо запрещало такую деятельность на совещаниях. Прецедент всё равно случился.

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

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

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

Идите по списку и отмечайте. Три места, где дыры находятся почти всегда. Я ни разу не видел компанию, где не сработало бы хотя бы одно, — и ваша вряд ли исключение.

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

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

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

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

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

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

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

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

Ваше правило: доступ выдаётся под задачу и на срок задачи. Расширить проще, чем потом разбираться.

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

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

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

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

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

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

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

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

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

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

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

Ручная сверка «кто уволен — у кого остались права» работает, пока в компании небольшая команда и несколько сервисов. На полусотне людей и полутора десятках систем (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 не съезжают.

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

Цифры в диаграмме — оценка по типовым трудозатратам, не хронометраж.

Во сколько раз автоматическая сверка выгоднее

Прикиньте на своей численности: сколько человеко-часов уходит у вас на одну ручную сверку и сколько раз в год вы её делаете.

Настройка автоматической сверки — около 8–10 часов, эксплуатация — около 300 ₽/мес на токены модели плюс около 35 минут в неделю ответственного, а эффект — окно, в котором доступ уволенного сотрудника или таблица «по ссылке» остаются незамеченными, сокращается с трёх месяцев при квартальной ручной сверке до одной недели (оценка).

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

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

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

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

Что мы не считаем эффектом: сами ~10 000 ₽/год экономии на трудозатратах — не главная выгода автоматизации, это фон. Мы также не считаем эффектом аудита сам разовый случай на 500 000 ₽, разобранный ниже, — это иллюстрация масштаба риска, а не гарантированная ежемесячная экономия.

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

Куда уходят ваши данные

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

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

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

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

Один час, один список, одно решение по каждой строке.

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

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

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

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

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

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

И ещё одно: заведите отдельную строку в вашем процессе увольнения — «доступы отозваны, проверил такой-то». Одна строка, а закрывает целый класс рисков.

Как это было у нас

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

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

Сделайте сверку на этой неделе — и заведите следующую на квартал вперёд прямо в календаре. Как автоматизировать — в бесплатном курсе.

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

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

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

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

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

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

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

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

Права доступа сотрудников — это то же самое, что аудит информационной безопасности?

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

Это то же самое, что настроить права доступа в CRM или на облачном диске?

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

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