IT-доступы при приёме и увольнении сотрудников

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

Почему этот процесс проваливается именно в малых компаниях

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

Onboarding: что готовится до первого рабочего дня

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

Принцип минимальных прав, а не «как у того, кто сидел на этом месте раньше»

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

Временные пароли и двухфакторная аутентификация с первого дня

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

Offboarding: что происходит в день увольнения сотрудника

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

Общие учётные записи забывают чаще всего

Отключение рабочей почты — как правило, первое, о чём думает ответственный, и именно поэтому оно почти всегда происходит. Чаще всего забывают про учётные записи, не привязанные к одному конкретному человеку: панель управления хостингом и доменом сайта, аккаунты компании в соцсетях, рекламные аккаунты (Google Ads, Meta Ads), доступ к онлайн-банкингу с правом просмотра, или общий пароль к сервису, которым пользуется вся команда. Ни один из них не попадает в список «учётные записи сотрудника Х», потому что формально они принадлежат не ему — они принадлежат компании, но он знал пароль. Без письменного списка всех таких общих учётных записей и того, кто знает к ним пароль, offboarding фактически останавливается на почте и оставляет всё остальное открытым.

Отключай, а не удаляй сразу

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

Один документ вместо распределённой памяти

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

Частые ошибки

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

С чего начать на практике

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

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