Уволился системный администратор. Первые 48 часов

Приветствую вас, коллеги!

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

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

Сразу две оговорки

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

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

Почему это больно

Дело не в паролях. Пароли меняются.

Дело в том, что вместе с человеком уходит карта местности. Где лежат бэкапы и работают ли они. Какие сервисы оплачены и когда кончаются. Кто регистратор домена. Под какой учетной записью крутится обмен с банком. Почему на сервере стоит вот эта служба и что будет, если ее выключить.

Все это обычно нигде не записано. Оно жило в голове.

И вторая часть боли - временная. Доступы надо закрыть быстро, а разобраться в устройстве - медленно. Эти две задачи конфликтуют: закроете быстро и бездумно - остановите работу компании. Будете разбираться неделю - оставите открытым то, что стоило закрыть в первый день.

Поэтому порядок действий и важен.

Первый час: не блокировать, а составить список

Главный совет всей статьи, и он контринтуитивный.

Не бросайтесь менять пароли. Сначала составьте список того, что вообще есть.

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

Что должно попасть в список за первый час:

• сервер или серверы - физические и виртуальные, где стоят, кто хостинг;
• базы 1С - какие есть, где лежат, файловые или серверные;
• домен и почта - у какого регистратора, на каком хостинге;
• сетевое оборудование - роутер, межсетевой экран, пробросы портов;
• удаленный доступ - VPN, RDP, программы удаленного управления;
• банк-клиенты и электронные подписи - у кого физически токены;
• государственные системы - ОФД, Честный знак, ЭДО, госпорталы, налоговая;
• облачные сервисы и подписки - что оплачено и с какой карты;
• бэкапы - где, как часто, кто проверял в последний раз.

Список пишется даже если он неполный. Дальше он будет дополняться, но начинать надо с него, а не с паники.

Что закрывать и в каком порядке

Теперь по приоритетам. Порядок именно такой, от самого опасного к менее.

Первое - все, что связано с деньгами. Банк-клиенты, платежные сервисы, доступ к личному кабинету в банке. Здесь не думаем, здесь закрываем сразу. Если у человека был доступ к банку - меняем все и сообщаем в банк об отзыве.

Второе - внешний доступ снаружи. VPN, проброшенные наружу порты RDP, программы удаленного управления, доступ к серверу через интернет. Это ворота, через которые можно зайти из дома, и закрываются они в первую очередь после денег.

Третье - почта и корпоративные аккаунты. Личная рабочая почта, общие ящики, доступ к почтовому серверу. Через почту восстанавливаются пароли от всего остального - поэтому она важнее, чем кажется.

Четвертое - домен и регистратор. Самое неприятное, что может случиться, - потеря контроля над доменом. Проверьте, на кого он оформлен, и получите доступ в личный кабинет регистратора.

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

Шестое - административные учетные записи на серверах и в 1С. Вот тут - осторожно, и следующий раздел именно об этом.

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

Главная ошибка: удалить учетную запись

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

Не удаляйте учетную запись администратора. Отключите ее.

Разница принципиальная. При удалении вы теряете информацию о том, где эта учетка использовалась, а использоваться она может в самых неожиданных местах:

• под ней работают службы на сервере;
• от ее имени выполняются регламентные задания в 1С;
• ей подписаны запланированные задачи в планировщике;
• под ней настроен обмен с банком или с сайтом;
• ей принадлежат права на папки и сетевые ресурсы;
• от нее работает задание резервного копирования.

Отключенная учетка ломает то же самое, но обратимо: включили обратно, посмотрели, что заработало, аккуратно перевели на служебную запись. Удаленная - это уже расследование с нуля.

Правильный порядок такой:

1. Отключаем учетную запись.
2. Ждем сутки и смотрим, что перестало работать.
3. Каждый найденный случай переводим на отдельную служебную учетку с минимально нужными правами.
4. И только потом, через пару недель, удаляем - если вообще понадобится.

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

Что искать, а не блокировать

Параллельно с закрытием доступов идет вторая задача - собрать карту местности. На нее у вас как раз вторые сутки.

Бэкапы - самое главное. Где они лежат, с какой периодичностью делаются, кто и когда в последний раз проверял восстановление. По моему опыту, в половине случаев после ухода админа выясняется, что бэкап либо не делается уже несколько месяцев, либо делается на тот же сервер, что и база. Это стоит проверить в первые же двое суток, а не через полгода.

Лицензии. Программные лицензии 1С, ключи HASP, лицензии Windows, антивирус. Где физически лежат ключи, где записаны пин-коды, на кого оформлены. Программная лицензия 1С привязана к железу, и резервные пин-коды должны быть у вас. Их несколько, но число их конечно, и часть могла быть уже потрачена при прошлых переустановках - так что проверьте заодно, сколько осталось. Если пин-коды только у ушедшего человека, это отдельная проблема.

Договоры и подписки. Хостинг, домен, ОФД, оператор ЭДО, интернет-провайдер, антивирус. С кем договор, когда продление, с какой карты списывается. Карта, кстати, иногда оказывается личной картой админа - и это обнаруживается, когда платеж не прошел.

Документация, если она есть. Схема сети, список серверов, описание доработок в 1С. Если ее нет - значит, ее предстоит написать, и это нормальная часть работы после такой ситуации.

Электронная подпись - отдельная история

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

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

Что делать:

Если токен вернули - хорошо, но смените пин-код и заберите его к себе. Подпись руководителя должна лежать у руководителя, это не формальность.

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

И на будущее: если сотруднику нужно работать в госсистемах от имени компании, для этого есть машиночитаемая доверенность. Именно для этого она и придумана - чтобы человек действовал от своего имени в рамках выданных полномочий, а не носил в кармане подпись директора. Я разбирал это отдельно в статье про подписи и МЧД.

Юридическая часть, коротко

По верхам, и повторю - я не юрист.

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

Удерживать расчет при увольнении из-за непереданных доступов нельзя. Все причитающиеся суммы выплачиваются в день увольнения - это прямо написано в статье 140 ТК, а порядок оформления - в статье 84.1. Попытка «придержать до передачи паролей» создаст вам проблему, а не решит ее.

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

И важный момент в обратную сторону. Если бывший сотрудник после увольнения заходит в вашу систему, это уже не трудовой спор. Неправомерный доступ к охраняемой законом компьютерной информации, повлекший ее уничтожение, блокирование, модификацию либо копирование, - статья 272 УК, и по первой части санкция до двух лет лишения свободы. Поэтому логи доступа имеет смысл сохранить, а не затирать.

Но начинать с уголовного кодекса не надо. Начинать надо со списка доступов.

Чего делать не надо

Короткий список ошибок, которые я наблюдал.

Не паниковать и не менять все разом. Массовая смена паролей за один вечер, без понимания, где что используется, - это гарантированная остановка работы на следующее утро.

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

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

Не тянуть с бэкапами. Все остальное может подождать день. Проверка бэкапа - нет.

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

Случай из практики

Ситуация типовая, повторялась у разных компаний почти дословно.

Звонят: ушел админ, работал шесть лет, ушел без скандала, но и без передачи дел - просто в один день написал заявление и отработал две недели, за которые никто не догадался ничего у него спросить.

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

Сервер один, стоит в подсобке, кондиционера нет. Бэкап 1С делается - на тот же самый сервер, в соседнюю папку. Копии где-то еще нет. Восстановление никто никогда не проверял.

Учетная запись админа - доменный администратор, и под ней же работает служба сервера 1С, задание бэкапа и обмен с сайтом. То есть просто удалить ее означало остановить магазин.

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

Токен с подписью директора - в ящике стола, хорошо хоть не унесен.

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

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

Как не попасть в это снова

Раздел, ради которого в том числе писалась статья.

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

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

Служебные учетки для служб. Ни одна служба, ни одно регламентное задание, ни один обмен не должны работать от имени живого человека.

Бэкап в два места, одно из которых недоступно с сервера. Это универсальный совет, который спасает и от ухода админа, и от шифровальщика, и от сгоревшего диска.

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

И процедура передачи дел, записанная заранее. Чек-лист на увольнение: что передается, кому, под роспись. Составляется один раз и лежит до нужного момента.

Отдельно для небольших компаний. Если у вас один человек на все ИТ, у вас по определению единая точка отказа. Самый дешевый способ ее подстраховать - чтобы кто-то снаружи хотя бы раз в год смотрел на инфраструктуру свежим взглядом и знал, как она устроена. Это не про замену вашего сотрудника, а про то, чтобы его уход не был катастрофой.

Если делать некому

Как вы помните, я айти-специалист: веду 1С для организаций, собираю и держу серверы. У нас команда из десяти программистов, и ситуацию «остались без админа» мы проходили много раз - она типовая, и порядок действий у нас отработан.

Чем помогаем:

• подхватываем инфраструктуру - разбираемся, что есть, где лежит и как работает;
• закрываем доступы в правильном порядке, не останавливая работу компании;
• проверяем бэкапы и настраиваем нормальную схему, если ее нет;
• разбираем учетные записи - переводим службы и задания с личных на служебные;
• приводим в порядок домен, подписки и лицензии - чтобы все было оформлено на компанию;
• описываем инфраструктуру на понятных двух страницах;
• берем на сопровождение - в том числе как страховку рядом со штатным специалистом.

Подробнее про обслуживание: обслуживание компьютеров и серверов

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

А если вы не в этой ситуации - тем лучше. Пройдитесь по разделу «как не попасть в это снова» и проверьте пять пунктов. Час времени сейчас против двух суток аврала потом)

Читайте также: Ваш бэкап 1С точно рабочий?, Электронная подпись и МЧД, Как выбрать подрядчика по 1С и Фишинг для бухгалтеров.

Правовые вопросы в материале даны для ориентира - при конфликтном расставании консультируйтесь с юристом. Упомянуты статьи 84.1 и 140 ТК РФ, статья 272 УК РФ.