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

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

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

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

Почему учётная запись — это ещё не человек

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

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

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

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

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

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

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

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

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

Что ломается, когда человек меняет отдел

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

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

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

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

Отдельная ловушка — «выдать как у коллеги». Это кажется справедливым и быстрым, но копируется не роль, а весь набор, включая чужие исключения, которые коллеге выдали год назад под конкретную задачу. Через несколько таких копий в компании не остаётся типовых наборов, и восстановить логику прав невозможно. Правильный вопрос при выдаче — не «у кого похожая должность», а «какие действия нужны и на какой срок».

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

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

Почему увольнение не выключает доступ само по себе

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

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

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

Второй фактор от такой истории не спасает. Он защищает от чужого человека с украденным паролем, но не от того, у кого остались и пароль, и телефон. Для системы уволенный сотрудник по-прежнему тот, кем был.

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

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

Список сам себя не обновит, поэтому нужен регулярный обзор. Раз в квартал владелец ресурса — не айтишник, а тот, кто отвечает за данные, — смотрит, у кого есть доступ, и отвечает на два вопроса. Первый: что сломается, если снять этот доступ сегодня? Если ответ «ничего», доступ снимается. Второй: когда этот доступ последний раз использовался? Журналы дают на него честный ответ, в отличие от памяти сотрудника.

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

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

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

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

Почему администратор — это другая задача

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

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

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

Второй фактор, или MFA, для администраторов обязателен, но важно понимать, что именно он даёт. Он подтверждает, что за клавиатурой тот самый человек, и не подтверждает, что этому человеку всё ещё нужны права. Это две разные проверки, и вторая из первой не появляется.

Важно. Поток запросов на подтверждение приучает нажимать «разрешить» не глядя: человек устаёт и перестаёт читать. Поэтому ограничение числа попыток — часть второго фактора, а не дополнение к нему.

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

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

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

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

Главная мысль

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

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

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

Что делать дальше