Відповідь одразу: Коли звільняється людина, яка адмініструвала корпоративне ІТ, вам треба ще протягом строку попередження прийняти й головне перевірити: адміністраторські облікові записи та паролі, доступ до домену, DNS і пошти, ліцензії та договори, оформлені на її ім’я, документацію мережі й робочі резервні копії разом із ключами шифрування — перевірені пробним відновленням. Кожен доступ протестуйте входом, доки є в кого запитати; список паролів в екселі — це не передавання. А якщо внутрішньої заміни немає, безпечніше довірити роботу зовнішньому ІТ-адмініструванню, ніж лишити фірму рухатися за інерцією.
Звільнення айтішника підступне тим, що спершу нічого не стається. Сервер працює, пошта ходить, принтери друкують. ІТ після відходу адміністратора не падає одразу — воно деградує поступово. Перша проблема з’являється за тижні або місяці: прострочений сертифікат, заповнений диск, зламана резервна копія. І аж тоді стає видно, що було в документації, а що лише в голові людини, якої у фірмі вже немає.
Цей текст — практична інструкція для керівника й офісу: що вимагати, як організувати передавання, що робити, коли вже пізно, і коли має сенс віддати адміністрування зовнішній фірмі.
Що стається, коли ІТ живе в голові однієї людини
Типові сценарії, на які натрапляють фірми — і які можна вчасно виявити під час передавання:
- Домен зареєстрований на його особисту пошту. Нагадування про продовження приходить у скриньку, яку вже ніхто не читає. Домен спливає, а разом із ним одразу зникає сайт і вся корпоративна пошта. Відновлення через реєстратора потім доводиться робити в цейтноті й з доведенням права власності.
- Пароля до фаєрвола чи роутера ніхто не знає. Пристрій роками працював без втручання. Під час першого збою інтернету не лишається нічого, крім скидання до заводських налаштувань — а з ним зникають VPN, правила, резервування адрес і поділ мережі. Конфігурацію доводиться будувати заново, по пам’яті.
- Резервні копії «працювали», але ніхто не пробував відновлення. Аж після аварії сервера з’ясовується, що завдання місяцями завершувалося помилкою, цільовий диск переповнений або що копія зашифрована ключем, який пішов разом з адміністратором.
- Ліцензії та сервіси оформлені на його акаунт. Microsoft 365, антивірус чи хостинг він оплачував карткою й перевиставляв фірмі. Після звільнення платіж не проходить і сервіс вимикається — часто без жодного попередження для фірми.
- Автоматизація працює на його комп’ютері. Нічний експорт у бухгалтерію, перенесення замовлень з інтернет-магазину, сторожові скрипти. Після деактивації його облікового запису вони тихо зупиняються, і ніхто не знає, що саме перестало працювати.
Спільний знаменник: жодну з цих проблем не видно в день звільнення. Тому передавання ІТ — це насамперед інвентаризація, і саме тому його не можна відбути останнім робочим пообіддям.
Чекліст передавання ІТ: що вимагати
Пройдіть пункти по групах. Для кожного діє те саме правило: ви приймаєте не список, а робочий доступ — перевірений входом у присутності адміністратора, який іде.
1. Адміністраторські облікові записи та паролі
- локальні паролі адміністратора до комп’ютерів і серверів;
- доменний адміністратор (Active Directory), за потреби Microsoft 365 Global Administrator або Google Workspace super admin;
- роутер, фаєрвол, комутатори, Wi-Fi (контролер і окремі точки доступу);
- NAS і сервери разом із віддаленим керуванням (iLO, iDRAC) та гіпервізором (Proxmox, VMware, Hyper-V);
- VPN — конфігурація сервера й перелік того, хто має доступ ззовні;
- система відеоспостереження, облік робочого часу, телефонна станція, сервер друку;
- бази даних, застосункові та службові облікові записи, ключі API, використані у скриптах;
- паролі до BIOS/UEFI та ключі відновлення BitLocker корпоративних ноутбуків — де вони зберігаються, пояснює стаття про BitLocker і ключ відновлення.
Паролі приймайте у корпоративний менеджер паролів, до якого має доступ більш ніж одна людина. Таблиця в екселі на спільному диску — це проблема безпеки, а не рішення.
2. Домен, DNS і пошта
Тут виникають найдорожчі простої, тому особливо ретельно:
- обліковий запис у реєстратора домену — на чиє ім’я та пошту він оформлений, куди приходять рахунки за продовження;
- хто адмініструє DNS-записи (реєстратор, хостинг, Cloudflare) і доступ до них;
- вебхостинг і сам сайт — адміністрування системи керування вмістом, FTP/SSH;
- адміністрування пошти: Microsoft 365 / Google Workspace або поштовий сервер хостингу;
- записи SPF, DKIM і DMARC — хто їх налаштовував і де;
- SSL-сертифікати: де вони поновлюються, чи автоматично, і коли спливають.
Мета — не лише знати паролі, а перевести право власності на фірму: реєстратор, хостинг і адміністраторські облікові записи мають бути прив’язані до корпоративної пошти й корпоративних платіжних даних, а не до особистої адреси колишнього працівника.
3. Резервні копії — і їхній тест
- що саме резервується (сервери, бази даних, спільні диски, пошта, конфігурації мережевих пристроїв), куди і як часто;
- доступ до програми резервного копіювання й до сховищ копій;
- паролі та ключі шифрування копій — без них резервна копія нічого не варта;
- куди приходять сповіщення про збої завдань — якщо на його адресу, перенаправити;
- наявність копії поза фірмою й поза досяжністю шифрувальників — принцип розбирає текст про правило 3-2-1 і резервну копію на зовнішній диск.
І головне: зробіть пробне відновлення ще за його присутності. Один файл, одну базу даних, в ідеалі одну цілу систему. Резервна копія, яку ніхто ніколи не відновлював, — це лише припущення.
4. Ліцензії, договори й сервісні відносини
- договір із провайдером інтернету і прямий контакт на його підтримку;
- ліцензії: Microsoft 365 / Google Workspace, антивірус чи EDR, бухгалтерське й галузеве програмне забезпечення, CAD, програма резервного копіювання;
- хмарні сервіси: віртуальні сервери, сховища, платформа інтернет-магазину;
- сервісні договори й гарантії на сервери, NAS і мережеві пристрої;
- до кожного пункту: на кого він зареєстрований, як оплачується і коли спливає.
Окремо попросіть показати все, що оплачується його карткою або з його рахунків — це майбутні тихі збої.
5. Документація мережі та систем
- план мережі: діапазони адрес, VLAN, схема підключення, перелік пристроїв із розташуванням;
- експорти конфігурацій фаєрвола й комутаторів (і куди вони зберігаються);
- огляд «що де працює»: фізичні сервери, віртуальні машини, служби та їхні залежності;
- відомі проблеми й тимчасові рішення — вони є в кожній мережі, і краще про них знати.
Якщо документації ніколи не існувало, немає сенсу вимагати її останнього тижня. Реалістичний шлях — дати змапувати поточний стан; що охоплює аудит комп’ютерної мережі та кабельної системи, ми описали окремо.
Як організувати передавання, доки айтішник ще у фірмі
Починайте першого тижня строку попередження, а не останнього. Інвентаризація доступів завжди триває довше, ніж очікується, а наприкінці людина, яка йде, зазвичай уже думками деінде.
Перевірений порядок дій:
- Акт передавання. Перелік усіх пунктів із чекліста вище, до кожного статус: передано / перевірено / відсутнє. Наприкінці підпис обох сторін. Це не цькування — це захищає й того, хто йде, бо за півроку ніхто не зможе вимагати від нього «пароль, який він не передав».
- Перевірка входом. Кожен доступ протестуйте в його присутності. Саме тут знаходяться облікові записи, до яких пароль давно не діє.
- Операційне коло. Попросіть пояснити, що він робить щодня, а що раз на місяць: перевірка резервних копій, оновлення, заміна стрічок чи дисків, поновлення сертифікатів. З цього постане операційний календар для наступника.
- Інструкції до повторюваних дій. Створення й видалення користувача, відновлення файлу з резервної копії, заміна диска в NAS, що робити під час збою інтернету. Досить стислих записів, можна й запису екрана.
- Після передавання змінити паролі. Усі адміністраторські облікові записи, до яких він мав доступ, отримають нові паролі й багатофакторну автентифікацію, прив’язану до корпоративних контактів. Його облікові записи в останній день деактивуйте — але не видаляйте, доки не перенесете скриньку, файли та заплановані завдання.
Коли він уже пішов, а передавання не було
Це трапляється частіше, ніж мало б — домовленість закінчилася швидко або на поганій ноті. Системи зазвичай працюють далі, але без нагляду. Дійте за розміром можливих збитків, а не за тим, що найбільше впадає в око:
- Домен і пошта. Перевірте, на кого зареєстровано домен і коли він спливає, те саме із сертифікатами. Це збої, які зупиняють усю фірму одномоментно.
- Резервні копії. З’ясуйте, чи вони взагалі працюють і чи можна з них відновитися. Доти поводьтеся з фірмою так, ніби резервної копії не існує — жодних експериментів на сервері.
- Доступи. Те, чого бракує, здобувайте легальним шляхом: скидання паролів через реєстратора, хостинг або виробника з доведенням права власності (договір, рахунки, реєстраційні дані). З мережевими пристроями без пароля розраховуйте на скидання до заводських налаштувань і нову конфігурацію.
- Віддалені доступи колишнього адміністратора. Облікові записи VPN, TeamViewer/AnyDesk, його адміністраторські акаунти в хмарі. Деактивувати — не зі злої волі, а з принципу: доступу до корпоративної мережі не повинен мати ніхто, хто у фірмі не працює.
Якщо у фірмі немає нікого, хто здатен це пройти, це саме та ситуація для передавання ІТ зовнішній адмініструвальній фірмі — перший крок завжди мапування стану й убезпечення доступів і резервних копій, і аж потім усе інше. Варто також зателефонувати колишньому адміністратору й домовитися про платну консультацію, щоб довести передавання до кінця: більшість людей не звільняються з наміром шкодити, і домовленістю ви отримаєте більше, ніж докорами.
Коли має сенс віддати ІТ зовнішній фірмі
Питання після звільнення єдиного айтішника звучить не лише «кого замість нього», а й «чи хочемо ми знову той самий ризик?». Якщо заміните одну людину іншою однією людиною, за рік будете в тій самій ситуації — а між тим відпустки, лікарняні та вихідні, коли ІТ ніхто не наглядає.
Зовнішнє адміністрування має сенс, коли:
- фірма не має для ІТ-спеціаліста роботи на цілий рік і роль однаково була «айтішник на пів ставки на додачу до іншої роботи»;
- вам потрібна взаємозамінність — в адмініструвальній фірмі ноу-хау не йде разом з однією людиною;
- ви хочете документацію й моніторинг як стандарт послуги, а не як добру волю працівника.
На що звернути увагу в договорі, щоб сьогоднішня ситуація не повторилася лише в іншій обгортці: документація й доступи є власністю фірми і ви маєте їх постійно, а не аж після завершення співпраці; адміністраторські облікові записи оформлені на фірму; і договір описує, як відбудеться можлива передача далі. Добре працює й комбінація — зовнішнє адміністрування плюс внутрішній «навчений користувач», який упорається з першою допомогою на місці.
Звільнення айтішника не мусить бути кризою. З чеклістом, актом і перевіреними резервними копіями це керована зміна. Кризою воно стає лише тоді, коли передавання відкладають на потім.
FAQ
Адміністратор пішов зі скандалом і відмовляється віддати паролі. Що тепер?
Доступи здебільшого можна відновити й без нього: реєстратор домену, хостинг і виробники обладнання мають процедури для доведення права власності фірмою (договори, рахунки, витяг із реєстру). Для мережевих пристроїв лишається скидання до заводських налаштувань і нова конфігурація. Перебіг документуйте, а доступ колишнього адміністратора до корпоративних систем деактивуйте якнайшвидше.
Чи достатньо, якщо він залишить нам таблицю з паролями?
Недостатньо. Частина паролів зазвичай уже не діє, частина облікових записів веде на його особисту пошту, а таблиця нічого не каже про те, чого бракує. Передавання — це перевірка: увійти до кожного пункту, перевести облікові записи на корпоративні контакти, увімкнути багатофакторну автентифікацію й зберегти паролі у спільному корпоративному менеджері паролів.
Чи маємо видалити його облікові записи одразу в день звільнення?
Деактивувати — так, видаляти — ні. На обліковому записі можуть висіти ліцензії, спільні документи, заплановані завдання або скринька, до якої й далі приходить важлива пошта. Спершу передача наступнику, і аж потім видалення.
Скільки триває прийняття ІТ?
Залежить від розміру мережі й стану документації. Саме передавання доступів — питання днів; перевірка резервних копій пробним відновленням, переоформлення облікових записів у реєстратора й постачальників та опис операційних процедур розтягуються на тижні. Тому важливо починати на початку строку попередження, а не наприкінці.
Чи переживемо ми період без адміністратора, доки знайдемо заміну?
Короткостроково так — якщо маєте перевірені резервні копії, під наглядом строки дії домену й сертифікатів і робочі адміністраторські доступи. Довгостроково зростає тихий ризик: ніхто не перевіряє ні резервні копії, ні оновлення, ні попередження безпеки. Що довше триває тимчасовий стан, то дорожчим зазвичай виявляється перший інцидент.