Компанія може роками нормально працювати й не помічати, що її сайт, домен і пошта фактично тримаються на одній людині. Домен колись зареєстрував знайомий розробник, хостинг оплачує бухгалтер, DNS залишився в акаунті агентства, а код 2FA приходить на телефон працівника, який уже давно звільнився. Поки нічого не потрібно змінювати, така схема здається цілком робочою.
Проблема проявляється в момент, коли треба продовжити домен, перенести сайт, змінити DNS, відновити пароль або отримати резервну копію. Якщо компанія не може самостійно відновити доступ до домену, хостингу та корпоративної пошти, вона фактично не контролює свою цифрову інфраструктуру — навіть якщо всі рахунки справно оплачуються з її коштів.
Найпростіший спосіб побачити слабкі місця — не починати з масової зміни паролів, а скласти карту цифрових активів і для кожного відповісти на три питання: де він знаходиться, хто має адміністративний доступ і як відновити цей доступ без конкретної людини.
Сайт компанії ще не означає, що компанія ним керує
Домен, DNS, хостинг, сайт і корпоративна пошта — це різні активи. Доступ до одного з них не гарантує контроль над іншими. Власник може бачити сайт у браузері й оплачувати рахунок за сервер, але не мати жодного доступу до доменного акаунта або DNS-зони.
Корисно одразу розділити поняття. Домен — це адреса на кшталт company.ua і право користуватися нею. DNS визначає, куди веде ця адреса та де працює пошта. Хостинг або VPS — середовище, де лежать файли сайту й база даних. CMS, наприклад WordPress, має власних адміністраторів. Пошта може працювати на тому самому сервері або в окремому сервісі. SSL-сертифікат теж має свій спосіб випуску й продовження.
У реальному бізнесі все це часто створювалося не в один день. Спочатку програміст зареєстрував домен, потім агентство перенесло DNS, згодом інший спеціаліст поставив сайт на новий сервер. Через кілька років ніхто вже не пам’ятає, у якому акаунті що знаходиться.
Тому для кожного активу потрібно знати постачальника, адміністративний акаунт і спосіб відновлення. Якщо хоча б на один пункт відповідь звучить як «це знає Сергій» або «треба спитати в агентства», аудит ще не завершений.
Спочатку треба намалювати карту доступів, а вже потім міняти паролі.
На кого насправді зареєстрований домен
Щоб перевірити реальний контроль над доменом, недостатньо знати дату оплати. Компанія повинна мати доступ до акаунта реєстратора, контактної пошти, другого фактора автентифікації та розуміти, як змінити DNS або nameservers.
Типовий сценарій: домен десять років тому зареєстрував знайомий розробник. Він оплачував його зі свого кабінету, а компанія просто компенсувала витрати. З часом старий email перестав використовуватися, номер телефону змінився, а контакти самого розробника загубилися. Домен при цьому продовжує працювати, тому проблема стає помітною лише тоді, коли потрібно щось змінити.
Найнеприємніший варіант — коли рахунок за домен бухгалтерія знаходить, а увійти до акаунта, з якого його продовжують, не може ніхто.
Перевіряти треба не лише «чий домен», а конкретний ланцюжок доступу:
- у якого реєстратора він обслуговується;
- який акаунт ним керує;
- яка email-адреса вказана для входу та відновлення;
- який номер телефону прив’язаний до акаунта;
- чи ввімкнена 2FA;
- хто отримує повідомлення про продовження;
- чи актуальний спосіб оплати;
- хто може змінити nameservers.
WHOIS або RDAP допомагає перевірити частину технічної інформації, але не варто робити з нього універсальний доказ права на домен: правила залежать від доменної зони та реєстратора. Набагато важливіше, щоб уповноважена особа компанії могла увійти до кабінету реєстратора, побачити потрібний домен і виконати адміністративну дію без допомоги колишнього підрядника.
Фраза «домен наш» мало що означає, якщо код відновлення приходить на чужу пошту.
Хостинг може оплачувати компанія, але керувати ним — інша людина
Платіжний контакт і технічний адміністратор — не одне й те саме. Бухгалтер може щороку оплачувати сервер, але це ще не означає, що хтось із компанії має логін до клієнтського кабінету, доступ до панелі керування або може отримати резервну копію.
Під час аудиту варто зафіксувати не лише адресу сервера, а й назву постачальника, номер клієнтського акаунта, контактну email-адресу та спосіб відновлення доступу. У внутрішньому реєстрі варто зазначити постачальника — наприклад, хостинг-провайдер UkrLine, номер клієнтського акаунта, контактну адресу та резервний спосіб відновлення. Цих даних має вистачити, щоб уповноважена людина могла знайти потрібний акаунт і передати керування іншому спеціалісту без участі попереднього адміністратора.
Власнику бізнесу не обов’язково вміти працювати через SSH або вручну відновлювати MySQL. Але має бути контрольований адміністративний доступ і зрозумілий шлях передачі його технічній людині. Перевірити варто:
- доступ до billing/client area;
- панель керування хостингом або VPS;
- FTP/SFTP/SSH;
- доступ до бази даних і phpMyAdmin, якщо він використовується;
- місце зберігання резервних копій;
- контактний email і 2FA;
- хто може скинути пароль або підтвердити відновлення.
Перевірка тут елементарна. Уявіть, що поточний адміністратор сьогодні не виходить на зв’язок. Чи може інша уповноважена людина увійти до панелі, отримати резервну копію та передати сайт новому спеціалісту? Якщо ні, доступ до сервера існує лише «десь у ноутбуці одного адміністратора», а це не резервування доступу.
Корпоративна пошта часто є головним ключем до решти акаунтів
Корпоративна пошта критична не лише через листування. Вона часто використовується для відновлення доступу до домену, хостингу, CRM, Google-сервісів, Meta, CMS, аналітики та інших систем. Тому втрата адміністративного контролю над поштою може заблокувати відновлення одразу кількох акаунтів.
Особливо небезпечна циклічна залежність. Наприклад, доступ до хостингу відновлюється через admin@company.ua, але сама скринька admin@company.ua працює на тому самому хостингу. Якщо компанія одночасно втратить доступ до панелі й пошти, стандартне «надіслати посилання для відновлення» вже не допоможе.
Де насправді працює корпоративна пошта
Потрібно з’ясувати, хто є поштовим провайдером, де знаходиться адміністративна консоль і хто має глобальні права. За DNS-записами MX можна побачити, куди спрямована пошта, а SPF, DKIM і DMARC допоможуть зрозуміти, які системи беруть участь у відправленні та перевірці листів. Але самі DNS-записи не замінюють доступ до поштової адмінпанелі.
Які сервіси відновлюються через неї
Окремо варто скласти список сервісів, де корпоративна адреса використовується як логін, резервна адреса або канал для кодів підтвердження. Тут іноді й знаходиться головна залежність: сайт працює, пошта ще ніби не потрібна, але щойно треба скинути пароль від реєстратора або CRM, лист із кодом відновлення вже нікуди не прийде.
Пошта — це часто ключ від ключів. Тому для неї потрібен не лише пароль, а й незалежний спосіб адміністративного відновлення, який не замикається на ту саму скриньку.
Один телефон для 2FA — теж єдина точка відмови
Другий фактор автентифікації не повинен бути прив’язаний лише до особистого телефона одного працівника. Для критичних бізнес-акаунтів потрібен резервний спосіб входу або recovery codes, доступні уповноваженим особам.
Сам по собі 2FA — правильний захист. Проблема виникає, коли всі коди входу фактично живуть в одному телефоні. У цей момент телефон стає частиною інфраструктури компанії, хоча формально належить працівникові. Його можна загубити, розбити, номер може бути заблокований, а працівник — звільнитися.
Для різних сервісів другий фактор може бути різним: SMS, TOTP-код з authenticator-додатка, push-підтвердження, hardware security key або одноразові recovery codes. Для бізнесу важливіше не сперечатися, який метод «найкращий», а перевірити, що в разі втрати основного пристрою залишається дозволений шлях відновлення.
У налаштуваннях Security або Two-factor authentication варто перевірити:
- які методи 2FA активні;
- на який номер або пристрій вони прив’язані;
- чи створені backup/recovery codes;
- де вони зберігаються;
- чи можна додати резервний ключ або інший метод;
- які пристрої підключені та які сесії залишаються активними.
Тут достатньо одного запитання: що станеться, якщо цей телефон сьогодні зникне? Якщо відповідь — «ніхто не увійде», проблема вже знайдена. 2FA має зменшувати ризик крадіжки пароля, а не створювати залежність від одного пристрою.
Паролі та recovery codes не повинні жити в Telegram одного працівника
Нормальна передача доступів — це не повідомлення з логінами й паролями. Після зміни відповідальної особи потрібно перевірити другі фактори, резервні адреси, активні сесії, API-токени, FTP-доступи та SSH-ключі.
Слабка, але дуже поширена схема виглядає так: пароль від домену збережений у браузері, recovery codes — у «Збережених повідомленнях», SSH-ключ лежить на особистому ноутбуці, а пароль від реєстратора — у приватній пошті адміністратора. Формально доступи існують. Практично компанія їх не контролює.
Де зберігати критичні доступи
Для робочих акаунтів краще використовувати корпоративний password manager або інше контрольоване сховище, де можна передавати доступ без копіювання паролів у чат. Якщо сервіс підтримує окремі облікові записи й ролі, краще створювати персональних адміністраторів замість одного спільного логіна на всіх.
Для критичних активів бажано мати щонайменше двох уповноважених людей або документовану резервну процедуру відновлення. Це не означає, що всі повинні мати root-доступ. Ролі можна розділяти: одна людина відповідає за технічну частину, інша має контрольований аварійний доступ.
Що змінювати після звільнення адміністратора
Змінити пароль — лише половина роботи. Старі сесії, токени та ключі можуть залишатися чинними навіть після того, як основний пароль уже інший.
- Заблокувати або видалити персональні облікові записи колишнього працівника.
- Змінити спільні паролі та інші секрети.
- Відкликати старі активні сесії.
- Перевірити 2FA та контакти для відновлення.
- Переглянути API keys і токени.
- Перевірити FTP/SFTP-доступи.
- Переглянути SSH-ключі в authorized_keys.
Спільний пароль — це не те саме, що спільний контроль. Якщо пароль змінили, але токени, ключі та активні сесії колишнього адміністратора залишилися чинними, передача доступів ще не завершена.
Backup.zip ще не означає, що сайт можна відновити
Резервна копія має цінність лише тоді, коли відомі її дата, склад, місце зберігання та процедура відновлення. Файл із назвою backup.zip сам по собі нічого не гарантує.
Коли резервування ніхто не перевіряє, проблеми спливають уже під час аварії: архів виявляється старим, усередині є лише файли без бази даних, архів пошкоджений, пароль до нього невідомий або ніхто не розуміє, на який сервер і в якій послідовності його розгортати.
Для типового CMS-сайту треба перевірити щонайменше:
- файли сайту;
- базу MySQL/MariaDB;
- конфігураційні файли;
- каталог із завантаженнями користувачів;
- дату створення копії;
- місце її зберігання;
- хто має доступ до сховища.
DNS, домен, SaaS-сервіси й стороння пошта не стають частиною бекапу сайту автоматично. Якщо конфігурація критична, її теж треба документувати окремо.
Єдиний надійний спосіб переконатися, що копія справді робоча, — спробувати відновити її в тестовому середовищі. Не обов’язково робити це щотижня, але процедура має бути відома й хоча б періодично перевірятися. Неперевірений бекап — це припущення, а не план відновлення.
Аудит цифрових активів: що має знати власник бізнесу
Власнику не потрібно особисто адмініструвати сервер або редагувати DNS. Але компанія повинна знати, де знаходиться кожен критичний актив, хто ним керує і як передати контроль іншій уповноваженій людині.
Для першої перевірки достатньо простої таблиці:
Актив | Що має бути відомо компанії | Що перевірити |
|---|---|---|
Домен | Реєстратор, акаунт, дата продовження, резервна email-адреса | Чи можна увійти та змінити DNS/nameservers |
DNS | Де розміщена зона | Хто може редагувати A, AAAA, CNAME, MX, TXT |
Хостинг/VPS | Провайдер, client account, сервер | Чи є адміністративний доступ і спосіб відновлення |
Сайт | CMS, admin URL, адміністратори | Чи є резервний контрольований доступ |
Пошта | Поштовий сервіс, admin-акаунт | Хто може створити скриньку та скинути пароль |
Backup | Місце, дата, склад | Коли востаннє перевіряли відновлення |
2FA | Метод і відповідальні | Чи є резервний фактор або recovery codes |
SSL | Спосіб випуску й продовження | Автоматичне чи ручне продовження |
API/SSH | Активні ключі й токени | Кому вони належать і чи потрібні ще |
Для кожного рядка зручно поставити один із трьох статусів: «контроль є», «контроль є лише через одну людину», «невідомо, хто контролює». Найціннішими часто виявляються саме рядки з відповіддю «не знаю» — вони показують залежність, яку раніше просто не помічали.
У результаті по кожному активу мають бути зафіксовані постачальник, відповідальна людина, резервний контакт, спосіб входу та відновлення доступу. Для малого бізнесу цього вже достатньо, щоб перестати покладатися на пам’ять однієї технічної людини.
Перевірка на один день без адміністратора
Найпростіший тест цифрової незалежності бізнесу — уявити, що основний адміністратор недоступний. Якщо компанія все одно може продовжити домен, змінити DNS, відновити пошту, отримати бекап і передати сайт іншому спеціалісту, базовий контроль над інфраструктурою збережено.
Не потрібно реально блокувати працівника або ламати робочу систему. Достатньо провести умовну «аварійну вправу» й пройти список дій без його участі:
- відомо, де зареєстрований домен;
- є контрольований доступ до акаунта реєстратора;
- резервна email-адреса належить компанії;
- 2FA не залежить від одного особистого телефона;
- відомо, де керується DNS;
- є доступ до хостингу або VPS;
- є адміністративний доступ до CMS;
- відомо, хто адмініструє корпоративну пошту;
- recovery codes зберігаються у контрольованому місці;
- є актуальна резервна копія сайту й бази;
- відомо, як цю копію відновити;
- особисті доступи колишніх працівників видалені;
- перевірені API keys, SSH keys та активні сесії;
- для критичних активів є резервна відповідальна особа або задокументована процедура відновлення.
Якщо на запит «потрібно змінити DNS» першою дією все ще є дзвінок конкретній людині, варто перевірити, чи не стала вона єдиною точкою доступу. Те саме стосується домену, пошти, хостингу й резервних копій.
Головне питання такого аудиту звучить просто: що компанія зможе зробити завтра, якщо людина, яка «знає всі паролі», не відповість? Якщо відповідь на нього є для кожного критичного активу, інфраструктура вже значно менше залежить від особистих акаунтів, телефонів і пам’яті окремого працівника.
