Системный администратор ушёл, а пароли остались у него: что делать компании

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

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

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

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

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

За словами «сисадмин ушёл и не отдал пароли» скрываются три разных случая, и действия в них разные.

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

Первые часы: координатор, фиксация, резервные копии

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

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

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

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

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

Три ветки: что реально можно сделать

Дальнейший план зависит от того, есть ли контакт с человеком.

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

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

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

Если штатной процедуры нет вообще — ИТ-специалист готовит отдельный план: что допустимо потерять, какие копии конфигураций есть, какое окно остановки согласовано, как откатиться. Сброс оборудования к заводским настройкам и переустановка сервера — крайняя мера в конце этого плана, а не первый шаг.

Карта доступа: что проверить и где смотреть

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

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

Термины из этой таблицы, если они звучат незнакомо, разобраны в отдельных материалах: что такое Active Directory, зачем бизнесу VPN и что вообще входит в системное администрирование.

Чего не делать сгоряча

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

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

Не делать заводской сброс сетевого оборудования как первый шаг. Вместе с паролем вы потеряете конфигурацию, которую восстанавливать будет некому.

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

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

Правовая часть: что можно сказать честно

Здесь важно не перепутать ожидания с нормой.

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

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

Отдельная норма — статья 272.1 УК РФ, введённая Федеральным законом от 30.11.2024 № 421-ФЗ и действующая с 11 декабря 2024 года. Она про незаконный оборот компьютерной информации, содержащей персональные данные: использование, передачу, сбор и хранение таких данных, заведомо полученных незаконным путём. К удержанию паролей она отношения не имеет, но становится актуальной, если речь идёт об уносе клиентской базы.

Мы не юристы, и этот раздел — не юридическая консультация. Если ситуация конфликтная, оценивать её должен юрист по вашим документам и вашим фактам.

Как понять, что управление вернулось

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

1. У компании есть независимый вход под корпоративной учётной записью, и им кто-то воспользовался — с указанием даты и имени проверившего.
2. Известен ответственный от бизнеса и известно, на кого оформлен договор с поставщиком.
3. Работает процедура восстановления доступа, которую компания может запустить сама.
4. Лишние доступы отозваны, а те, что оставлены осознанно, записаны как исключения с ответственным.

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

Чтобы это не повторилось

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

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

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

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

И одна проверка, которую стоит сделать до того, как что-то случится: спросите у своего системного администратора или ИТ-подрядчика, на кого оформлены домен, почта и хостинг и что произойдёт, если он завтра будет недоступен. Набор таких вопросов собран в материале «10 вопросов системному администратору».

Что дальше

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

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