Коли лягає сайт, треба перенести проєкт або підкрутити налаштування, перше, що просить розробник – це доступи. І тут легко наступити на класичні граблі: скинути головний пароль від усього під гаслом «на, розбирайся, тільки швидше». Але доступ до VPS чи виділеного сервера – це не просто вхід у панельку. Це пряма можливість переписати файли, знести бази даних, зламати пошту чи взагалі випадково загасити весь проєкт.
Адекватна передача доступу ніяк не заважає адміну чи розробнику робити свою роботу. Вона просто тримає його в межах того завдання, заради якого його взагалі покликали.
Якщо це Linux VPS
Для Linux-серверів стандарт – це SSH. Тобто керування машиною через термінал за допомогою команд. Якщо людині потрібно просто оновити код, глянути логи чи змінити конфіг додатка, їй зазвичай взагалі не здався root. Root у Linux – це абсолютна влада: можна правити будь-які системні файли, видаляти служби й крутити сервером як завгодно.
Правильний підхід – створити окремого користувача і замкнути його в межах потрібної директорії, наприклад, у папці конкретного сайту. Якщо вже зовсім ніяк без адміністрування, краще налаштувати права через sudo. Так підрядник зможе виконувати конкретні команди з підвищеними привілеями, але основний root-пароль залишиться при вас.
Замість паролів краще відразу використовувати SSH-ключі. Роботу зроблено – ключ видалили, і доступ закрився. Це набагато простіше, ніж потім гарячково згадувати, у який чат і кому ви колись пересилали пароль.
Якщо це Windows VPS
У середовищі Windows усе зазвичай крутиться навколо RDP – віддаленого робочого стола, де адмін бачить звичний інтерфейс Windows Server. І тут знову ж таки не треба з порогу віддавати обліковий запис вбудованого Administrator.
Створіть окремого локального юзера. Якщо завдання вимагає розгортання софту, переналаштування служб чи колупання в IIS – так, права адміна, скоріш за все, знадобляться. Але коли вся задача зводиться до оновлення бази в CRM, бухгалтерського софту чи простої правки скриптів, повні права будуть зайвими.
Коли підрядник закінчив роботу, цей обліковий запис треба як мінімум вимкнути, а краще видалити. Заодно перевірте, чи не «зависли» активні RDP-сесії та чи не з’явилися нові обличчя у групі Administrators. Для серверів, де одночасно працюють кілька співробітників або зберігаються персональні дані клієнтів, це критично.
Якщо це виділений сервер
З виділеним сервером ставки вищі, бо підрядник отримує контроль не над ізольованим віртуальним середовищем, а над «залізом». На такій машині зазвичай крутиться купа всього: кілька великих сайтів, важкі бази, внутрішня пошта й бекапи. Тому пускати туди з максимальними правами варто лише тоді, коли по-іншому задачу просто не вирішити.
Для Linux і Windows на «залізі» правила ті самі: окремі облікові записи, SSH-ключі, мінімум прав і sudo суворо за призначенням.
Але з’являється ще один нюанс – IPMI, iDRAC та інші інтерфейси віддаленого керування залізом. Це не просто чергова адмінка сайту. Через ці штуки можна перезавантажити сервер по живленню, змінити черговість завантаження дисків, підмонтувати свій образ системи й отримати повний доступ в обхід будь-яких паролів ОС. Їх розробникам віддавати не можна майже ніколи, хіба що виникає якась зовсім екстремальна проблема з ядром чи залізом.
Що перевірити перед передачею доступу
Спочатку чітко сформулюйте задачу. Що саме робимо? Оновлюємо CMS, переносимо базу, накочуємо SSL-сертифікат, розбираємося, чому вилітає 500 помилка, чи міняємо конфіг вебсервера? Від цього залежить рівень доступу.
Для банальної правки шаблонів сайту вистачить SFTP або доступу до звичайної хостинг-панелі. Для бази даних правильніше зробити окремого користувача в MySQL або PostgreSQL з правами лише на одну конкретну базу. А якщо треба просто налаштувати плагін умовного WordPress, то створіть адміна всередині самої CMS – сервер тут взагалі ні до чого.
І головне – зробіть бекап перед тим, як пустити людину на сервер. Особливо якщо планується оновлення системи, переналаштування Nginx, Apache, IIS чи PHP. Бекап не скасовує людський фактор, але чудово рятує, якщо щось піде не так.
Що зробити після завершення робіт
Роботу прийняли – доступи закриваємо. Одразу.
- На Linux VPS: видаляємо тимчасового юзера або його ключ, чистимо sudo-сертифікати, міняємо пароль, якщо довелося його засвітити.
- На Windows VPS: гасимо або видаляємо RDP-користувача, перевіряємо список групи Administrators.
- На виділеному сервері: додатково ревізуємо доступи до IPMI/iDRAC, баз даних та внутрішніх адмінок.
Логіка тут проста для будь-якої інфраструктури: не давати root/administrator без крайньої потреби, під кожну задачу створювати окрему точку входу, обмежувати права по максимуму, тримати під рукою свіжий бекап і закривати за собою двері відразу після фіналу робіт. Інструменти всюди різні, але підрядник завжди має бачити лише той шматок системи, за який йому заплатили.