Коротка відповідь: Почніть із домену, поштового тенанта та резервних копій, а не з комп’ютерів в офісі. У перші години забезпечте корпоративний адміністраторський доступ до домену, Microsoft 365 або Google Workspace та сховища резервних копій, припиніть віддалений доступ колишнього адміністратора й лише після цього проводьте інвентаризацію. Протягом семи днів у вас мають бути власні адміністраторські облікові записи, перелік залежностей і перевірене відновлення даних, а не лише список паролів.
Звільнення корпоративного IT-фахівця зазвичай не спричиняє негайного збою. Проблема проявляється під час звичайного запиту: додати нового працівника до пошти, продовжити домен або змінити номер телефону на сайті. Тоді й з’ясовується, що домен зареєстрований на особисту електронну адресу фахівця, другий фактор Microsoft надходить на телефон, якого компанія вже не має, а завдання резервного копіювання на NAS протягом останніх двох місяців надсилає повідомлення про помилку на адресу, яку ніхто не читає.
Кероване передавання, під час якого адміністратор, що йде, співпрацює, описано у статті Ваш IT-фахівець пішов? Як прийняти та передати корпоративне IT без перебоїв. Цей текст починається з гіршої ситуації: передавання або взагалі не відбулося, або ви не можете йому довіряти.
Мета першого тижня — не перебудувати мережу й не придбати новий сервер. Потрібно зробити п’ять речей:
- припинити доступ колишнього адміністратора раніше, ніж ним хтось скористається,
- зберегти корпоративні дані та конфігурації, які можуть зникнути разом із його обліковим записом,
- отримати адміністраторські права, оформлені на компанію,
- з’ясувати, від чого компанія насправді залежить,
- довести, що дані з резервних копій можна відновити.
І лише шостий пункт — документація. Вона є єдиним результатом, який залишиться у вас, навіть якщо наступного разу піде новий адміністратор.
Перші дві години: хто ухвалює рішення та які доступи закрити
Призначте одну людину з керівництва, яка затверджуватиме приймання. Їй не обов’язково розумітися на VLAN. Вона має вирішувати, хто отримає адміністраторський доступ і які зміни дозволено проводити під час роботи систем, адже найближчими днями обидва ці питання виникатимуть в умовах дефіциту часу.
Якщо існує ризик зловживання обліковими записами, почніть із блокування доступу. Змінити головний пароль недостатньо: у Microsoft 365 виданий токен доступу зазвичай залишається чинним до завершення строку дії, тобто протягом кількох годин. Авторизований сеанс працюватиме далі, доки ви явно його не відкличете — в Entra ID через «Revoke sessions» або за допомогою Revoke-MgUserSignInSession у PowerShell. Та сама логіка діє для Google Workspace і більшості хмарних сервісів.
Перевірте способи доступу, які взагалі обходять пароль:
- облікові записи VPN і клієнтські сертифікати — в OpenVPN потрібно також відкликати сертифікат, а не лише видалити обліковий запис,
- засоби віддаленого адміністрування — AnyDesk, TeamViewer, RustDesk або RMM-агент, який має постійний доступ до робочих станцій,
- SSH-ключі в
~/.ssh/authorized_keysна серверах, а також у DSM чи QTS на NAS, - особисті облікові записи колишнього адміністратора, додані як адміністраторські до Microsoft 365, Google Workspace, Cloudflare, хостингу або реєстратора,
- API-токени, паролі програм — app passwords обходять MFA — і доступ до менеджера паролів,
- автоматичне пересилання пошти та делегований доступ до поштових скриньок.
Однак не видаляйте обліковий запис одразу. Спочатку захистіть його пошту, OneDrive або Диск, документацію та історію спілкування з постачальниками — саме там нерідко міститься єдина підказка про те, в кого зареєстровано домен. Перевірте, що відбувається на конкретній платформі після вилучення ліцензії: вміст поштової скриньки не зникає миттєво, але строки залежать від сервісу й налаштувань. Експортуйте дані раніше, ніж покладатися на ці строки.
Не змінюйте масово всі паролі. Від імені облікового запису адміністратора можуть виконуватися завдання резервного копіювання, надсилання сканів із багатофункціонального пристрою електронною поштою, синхронізація NAS і заплановані сценарії. Некерована зміна пароля зупинить сервіс, про існування якого ви ще не знаєте. Ніхто не пов’яже збій із цією зміною, адже він може проявитися лише за тиждень під час місячного закриття.
Семиденний план приймання управління IT компанії
| Строк | Що має бути завершено | Результат |
|---|---|---|
| День 1 | Захист домену, поштового тенанта, адміністраторських облікових записів і віддалених доступів | Компанія має власний адміністраторський доступ |
| День 2 | Перелік пристроїв, серверів, хмарних сервісів, ліцензій і постачальників | Зрозуміло, що існує та хто за це платить |
| День 3 | Карта мережі та залежностей між сервісами | Зміни можна планувати без зайвих перебоїв |
| День 4 | Перевірка резервних копій, ключів шифрування та історії помилок | Зрозуміло, що можна відновити |
| День 5 | Практична перевірка відновлення вибраних даних | Резервну копію перевірено, а не лише позначено «зеленою» |
| День 6 | Перелік ризиків за рівнем серйозності | Керівництво знає, що потрібно вирішити негайно, а що може зачекати |
| День 7 | Документація, план виправлень і правила адміністрування | Робота систем не залежить від однієї людини |
Порядок може змінюватися залежно від ситуації. Несправна резервна копія бухгалтерії важливіша за інвентаризацію принтерів. Невідомий пароль від гостьової Wi-Fi, навпаки, не є приводом зупиняти мережу.
Чекліст облікових записів, які має контролювати компанія
Список паролів в Excel — це ще не приймання. Компанія має володіти обліковим записом, адресою для відновлення, другим фактором і договором із постачальником. Це чотири різні речі, і бракувати може будь-якої з них.
| Сфера | Що прийняти та перевірити |
|---|---|
| Домен | Обліковий запис у реєстратора, зареєстрований власник, платіжний контакт, адреса для відновлення, багатофакторна автентифікація, блокування перенесення |
| DNS | Авторитетні сервери імен, експорт зони, доступ до Cloudflare або DNS-хостингу, DNSSEC |
| Електронна пошта | Глобальний адміністратор Microsoft 365 або суперадміністратор Google Workspace, ліцензії, оплата, MX, SPF, DKIM, DMARC |
| Ідентифікація | Microsoft Entra ID, групи, адміністраторські ролі, умовний доступ, підключені програми та надані дозволи OAuth |
| Інтернет і мережа | Обліковий запис у провайдера, маршрутизатор, брандмауер, комутатори, контролер Wi-Fi, VLAN, DHCP, VPN, публічні IP-адреси |
| Сервери | Windows Server, Linux, Hyper-V, VMware або Proxmox, сервісні облікові записи, консолі, ключі шифрування |
| NAS і резервні копії | Synology DSM, QNAP QTS, Veeam, Hyper Backup, Active Backup for Business або HBS 3, цільові сховища та ключі до зашифрованих резервних копій |
| Комп’ютери | Локальний адміністратор, ключі відновлення BitLocker, Intune або інша MDM, антивірус, RMM |
| Вебсайти та хмара | Хостинг, SSL-сертифікати, GitHub або GitLab, Azure, AWS, бухгалтерські та CRM-системи |
| Інші робочі системи | VoIP-АТС, система відеоспостереження, облік відвідуваності, контролер UniFi або Omada, принтери та надсилання сканів електронною поштою |
Для кожного пункту зазначте власника сервісу, адміністраторів, спосіб відновлення доступу, дату наступного платежу та залежності. Паролі мають зберігатися в корпоративному менеджері паролів — Bitwarden, 1Password або Keeper, — а не у спільній таблиці на диску й тим більше не в електронній пошті.
На особливу увагу заслуговують ключі відновлення BitLocker. Якщо робочі станції приєднували до домену або Entra ID, ключі, найімовірніше, автоматично зберігалися там, і їх можна отримати з консолі. Якщо комп’ютери працювали автономно з локальним обліковим записом, ключі можуть бути в обліковому записі Microsoft технічного спеціаліста або на папері — і більше ніде. Докладно це розглянуто в матеріалі про те, що робити, коли BitLocker після оновлення Windows раптово вимагає ключ відновлення.
У якому порядку змінювати доступи
Починайте з облікових записів, через які можна відновити всі інші, і поступово переходьте до кінцевих:
- Корпоративний домен і обліковий запис у реєстратора.
- Головний поштовий тенант і система ідентифікації — Entra ID або Google Workspace.
- Менеджер паролів і облікові записи резервного копіювання.
- Хмарні сервіси, хостинг, сервери, брандмауер і віддалений доступ.
- Робочі програми та звичайні кінцеві пристрої.
Логіка проста: той, хто контролює домен, може перенаправити пошту; той, хто контролює пошту, може скинути доступ майже до всього іншого. Якщо почати з переналаштування ноутбуків, ви впорядковуватимете листя дерева, тоді як його коріння залишатиметься в чужих руках.
Для Microsoft 365 і Google Workspace створіть щонайменше два адміністраторські облікові записи, що належать компанії. Вони не мають бути прив’язані до особистої адреси технічного спеціаліста або використовуватися для щоденного листування. У Microsoft 365 також перевірте наявність облікового запису аварійного доступу, виключеного з умовного доступу. Без нього неправильно налаштоване правило може заблокувати весь тенант.
Перш ніж змінювати пароль сервісного облікового запису, з’ясуйте, де саме його збережено. Один обліковий запис часто обслуговує резервне копіювання, принтер, вебзастосунок і запланований сценарій. Зміна без карти залежностей спричинить низку начебто не пов’язаних між собою несправностей, які знайти набагато важче, ніж усунути наслідки одного запланованого перебою.
Домен і DNS важливіші за офісні комп’ютери
Той, хто контролює домен і DNS, може перенаправити вебсайт, змінити доставлення пошти, підтвердити право власності на домен перед хмарним сервісом і створити в ньому доступ. Попри це, домен нерідко оформлений на людину, яка колись його «організувала».
Перевірте безпосередньо в реєстратора, що зареєстрованим власником є компанія, а контактні дані актуальні. Для чеських доменів власника можна знайти в публічному реєстрі CZ.NIC, але змінити запис можна лише через обліковий запис у реєстратора або після підтвердження особи. Самої можливості редагувати записи DNS недостатньо — це право доступу, а не право власності.
Перед будь-якою зміною експортуйте зону. Зафіксуйте MX для пошти, TXT для перевірки сервісів, SPF, DKIM — у Microsoft 365 селекторами зазвичай є selector1 і selector2, у Workspace — google, — DMARC, субдомени та записи, які використовує VPN або віддалений доступ. Не переписуйте зону лише на підставі того, що видно на вебсайті: перевірочний TXT-запис або CNAME для autodiscover не мають очевидного для стороннього спостерігача призначення, а наслідки їх видалення можуть проявитися лише за кілька тижнів.
Резервну копію не можна вважати прийнятою, доки ви не відновили з неї дані
Зелена піктограма в Synology DSM, QNAP QTS або консолі Veeam підтверджує лише одне: завдання завершилося. Вона нічого не говорить про те, чи копіюються правильні дані, чи відомий вам ключ шифрування та чи можливе відновлення з технічного погляду.
Протягом першого тижня перевірте:
- що саме копіюється та що виключено із завдання — винятки часто створювалися багато років тому, і відтоді їх ніхто не переглядав,
- куди зберігаються копії та чи є копія за межами будівлі,
- чи постійно підключене сховище резервних копій із тим самим обліковим записом, що й робоче середовище, — у такому разі програма-вимагач зашифрує його разом із ним,
- як довго зберігаються старіші версії та чи пережили б вони помилку, непомічену протягом місяця,
- хто володіє паролем і ключем шифрування резервної копії,
- чи справді повідомлення про помилки надходять на адресу, яку хтось читає.
Потім виконайте ізольоване відновлення: кількох файлів і принаймні однієї важливої системи або її репрезентативної частини. Відкрийте відновлений файл. Для бази даних недостатньо, що було створено файл правильного розміру, — його має прийняти програма, яка працює з цією базою.
RAID — не резервна копія, як і другий диск у тому самому NAS. Обидва варіанти захищають від відмови диска, але не від видалення, програми-вимагача або прихованого пошкодження даних. Детальніше це пояснюють матеріали про практичне застосування рівнів RAID та про зовнішній диск як резервну копію за правилом 3-2-1. Під час приймання вам насамперед потрібен доказ існування незалежної та придатної до використання копії.
Якщо перевірка відновлення завершилася невдало — масив деградований, ключ нікому не відомий або завдання не виконувалося місяцями, — не намагайтеся розв’язати проблему методом спроб і помилок на єдиній копії даних. Надішліть нам запит на відновлення даних, і спочатку ми узгодимо, що можна врятувати та за яких умов. Відновлення деградованого масиву, запущене за принципом «аби працювало», може остаточно знищити решту даних.
Де приховуються незадокументовані залежності
Сам технічний перелік не виявить, що бухгалтер експортує дані через мережеву папку на старому сервері, склад друкує етикетки з єдиного комп’ютера зі встановленим драйвером, а резервне копіювання запускає сценарій від імені особистого облікового запису колишнього адміністратора. Запитайте працівників, що перестане працювати в разі відмови інтернету, сервера або конкретної робочої станції. Так ви отримаєте карту, якої не створить жодне сканування мережі.
Додатково перевірте:
- автоматичне поновлення SSL-сертифікатів — сертифікат Let’s Encrypt діє 90 днів, тому збій завдання cron проявиться лише через три місяці,
- заплановані завдання та сценарії на серверах і робочих станціях,
- SMTP-облікові записи принтерів, вебсайтів і камер — часто це app password, який залишається чинним навіть після зміни основного пароля,
- спільні поштові скриньки та пересилання пошти,
- локальні бази даних бухгалтерських програм — Pohoda та подібні системи зазвичай працюють із файловою базою даних на спільному диску,
- ліцензії, прив’язані до електронної адреси, обладнання або платіжної картки колишнього адміністратора,
- UPS і спосіб керованого вимкнення сервера або NAS у разі зникнення електроенергії.
Спочатку задокументуйте залежність і лише після цього переносьте її на новий сервісний обліковий запис. Зворотний порядок — найпоширеніша причина перебоїв під час приймання.
Що має отримати компанія після приймання
Результатом не повинна бути фраза «тепер ми маємо доступ до всього». Вимагайте конкретний пакет:
- інвентаризацію пристроїв, сервісів і ліцензій,
- перелік адміністраторських і сервісних облікових записів із зазначенням власника,
- просту схему мережі,
- експорт важливих конфігурацій — брандмауера, зони DNS і завдань резервного копіювання,
- огляд доменів, DNS і сертифікатів із датами завершення строку дії,
- опис резервних копій, зокрема результат перевірки відновлення,
- перелік постачальників, договорів і строків платежів,
- ризики, розподілені на критичні, високі та відкладені,
- план усунення проблем із відповідальним і строком для кожного завдання.
Документація має зберігатися в корпоративному просторі та бути доступною щонайменше двом уповноваженим людям. Інакше ви лише заміните стару залежність новою.
Скільки коштує приймання та що має містити пропозиція
Визначити справедливу ціну приймання лише за кількістю комп’ютерів неможливо. Обсяг залежить від кількості філій, серверів і хмарних сервісів, стану документації, готовності попереднього адміністратора співпрацювати, а також від того, чи доведеться підтверджувати постачальникам право власності на облікові записи.
Розділіть пропозицію на три частини:
- захист критично важливих доступів,
- аудит і документація,
- усунення виявлених проблем.
Перші дві частини можуть мати фіксований обсяг або погоджений ліміт годин. Вартість виправлень визначається лише після з’ясування фактичного стану. Той, хто оцінює їх наперед, або вгадує, або додає резерв на найгірший сценарій. Пропозиція «повного приймання» без переліку результатів — прямий шлях до суперечки про те, що саме було замовлено.
Не поєднуйте вартість подальшого адміністрування з прийманням в одній позиції. Різницю між абонентською та погодинною оплатою пояснено у статті Скільки коштує управління IT для малої компанії. Одноразове відновлення контролю над занедбаним середовищем і регулярне адміністрування — це дві різні послуги з різною структурою витрат.
Як розпізнати якісно виконане приймання
Хороший адміністратор у перший день картографує залежності та створює резервні копії конфігурацій. Він не змінює брандмауер лише тому, що звик до іншого бренду.
Тривожні ознаки:
- облікові записи залишаються оформленими на особисту електронну адресу технічного спеціаліста,
- компанія не має власного адміністраторського доступу, а лише обіцянку його надати,
- ніхто не перевіряв відновлення,
- паролі надсилають звичайною електронною поштою,
- немає переліку виконаних змін,
- усе працює від імені одного облікового запису й неможливо з’ясувати, хто що зробив,
- придбати обладнання рекомендують ще до завершення інвентаризації,
- немає процедури майбутнього передавання іншому постачальнику.
Перевірка проста: якби новий адміністратор завтра перестав виходити на зв’язок, чи зберегла б компанія контроль над своїми обліковими записами, чи знала б, де містяться дані, і чи мала б придатну до використання документацію? Якщо так, приймання виконано добре. Якщо ні, ви лише змінили ім’я на єдиному ключі.
Якщо ви хочете закрити це питання та отримати результат, який зможете обґрунтувати перед керівництвом і наступним постачальником, зв’яжіться з нами. Ми виконуємо приймання IT, аудит доступів і перевірку відновлення резервних копій як одне замовлення із заздалегідь визначеним переліком результатів.
Що робити, якщо попередній адміністратор не співпрацює
Почніть із документів, які підтверджують право власності: договорів, рахунків, даних зареєстрованого власника домену та корпоративних контактів у постачальників. Реєстратор, хостингова компанія та хмарний провайдер зазвичай мають власну процедуру відновлення доступу, що ґрунтується на підтвердженні особи компанії, а не на знанні пароля. Прийняти сервіс, оформлений на приватну особу, складніше, і простим скиданням пароля проблему не розв’язати.
Не намагайтеся навмання обійти захист. Для зашифрованого тому на NAS, BitLocker або зашифрованої резервної копії можна отримати адміністраторський обліковий запис, але так і не одержати доступ до даних. Ключ шифрування не є частиною адміністраторських прав, і без нього вміст неможливо прочитати.
Постійно фіксуйте, яких доступів бракує, з ким зв’язувалися, коли це відбулося та які документи ви надали. Згодом цей запис стане єдиною придатною основою для переговорів із постачальниками та можливого договірного спору.
Найчастіші запитання
Чи потрібно негайно заблокувати обліковий запис колишнього IT-фахівця?
Якщо є ризик для безпеки — так, але в правильному порядку. Спочатку створіть другий адміністраторський обліковий запис, оформлений на компанію, та експортуйте дані з поштової скриньки й хмарного сховища колишнього фахівця. Лише після цього заблокуйте вхід, відкличте активні сеанси та видаліть VPN-доступ, SSH-ключі, API-токени, паролі програм і засоби віддаленого адміністрування. Зворотний порядок може позбавити вас доступу до власного тенанта.
Чи повинні ми знати всі старі паролі?
Ні. Важливі підтверджене право власності на сервіс і можливість безпечно створити або відновити адміністраторський обліковий запис. Паролі, відомі лише вам і колишньому адміністратору, у будь-якому разі потрібно змінити. Винятком є сервісні облікові записи: спочатку з’ясуйте, які системи їх використовують, і лише потім змінюйте паролі.
Скільки часу триває приймання управління IT?
За належної співпраці критично важливі облікові записи можна захистити протягом першого дня. Повна інвентаризація, перевірка резервних копій і картографування залежностей зазвичай займають кілька робочих днів. Недоступність попереднього адміністратора або сервіси, оформлені на приватну особу, подовжують процес на строк, визначений процедурою постачальника, а не вашим темпом роботи.
Чи можна прийняти домен, якщо ніхто не знає даних доступу?
Часто так, якщо зареєстрованим власником є компанія й вона може підтвердити реєстратору свою особу. Якщо домен зареєстрований на колишнього працівника або зовнішнього підрядника як на фізичну особу, потрібно діяти за правилами реєстратора, а вирішальне значення матиме договірна документація. Саме тому інформація про власника домену важливіша за те, хто вміє увійти до панелі адміністрування.
Як перевірити, що резервні копії справді працюють?
Відновіть дані в окреме розташування та перевірте їх на практиці: відкрийте документ, підключіть базу даних до програми. Також переконайтеся, що доступні старіші версії, у вас є ключ шифрування та задокументована процедура відновлення всієї важливої системи, а не лише окремих файлів. Перевірка відновлення, яку ніхто не повторював протягом року, має таку саму доказову цінність, як і повна відсутність перевірки.
Де нас знайти
ITHOPE — компанія з Брно, Чехія: ми робимо відновлення даних з дисків, RAID і NAS, сервіс ПК та ноутбуків та IT для бізнесу, усе у власній лабораторії за адресою Viniční 3587/216, 615 00 Brno.
Телефон +420 775 556 063 (цілодобово). Пристрій можна привезти особисто або надіслати курʼєром (Zásilkovna, PPL).