Пожелания и предложения. Делігування аккаунту

Доброго дня!

Я хотів би звернутися з важливим питанням щодо безпеки делегованого доступу на хостингу.

На даний момент власник акаунта, передаючи делегований доступ програмісту, не може обмежити його права. Зокрема, немає можливості закрити доступ до файлового менеджера або окремих розділів акаунта. Це створює серйозну загрозу безпеці, оскільки були випадки, коли програмісти використовували файловий менеджер для завантаження шкідливих PHP-скриптів, що дозволяли їм редагувати базу даних, отримувати доступ до конфіденційної інформації або завантажувати віруси. На фрілансі більшість программістів потребують саме делігованний доступ, тому що це швидше, та не потребує власника якихось знань ФТП.

Чому це важливо?

• Більшість власників хостинг-акаунтів не усвідомлюють небезпеку делегованого доступу.
• Делегований доступ часто використовується шахраями, які вмовляють власників надати їм права та завантажують шкідливі файли.
• ФТП-акаунти не завжди є альтернативою. Наприклад, при налаштуванні сервера для покращення швидкості роботи сайту FTP не допоможе, і програмісту потрібен доступ до панелі керування.

Що я пропоную?

• Впровадити можливість обмеження прав делегованого користувача
• Додати опцію вибору рівня доступу при наданні делегованих прав.

• Зробити можливість відключення файлового менеджера для делегованих користувачів.

  За замовчуванням закрити доступ до файлового менеджера
  Якщо програмісту він потрібен, власник акаунта повинен явно увімкнути цей доступ або дати ФТП.
  Це допоможе запобігти випадкам, коли користувачі навіть не підозрюють про можливі ризики.

  Додати журнал дій у файловому менеджері
  Власник акаунта повинен мати змогу бачити, які файли було додано або змінено через файловий менеджер делегованим користувачем.

Я знаю як мінімум три випадки, коли власників сайтів обманювали (так як 90% незнають що таке ФТП, а по делігувати це 1хв, тільки вписати пошту і все можуть), отримували делегований доступ та завантажували віруси або шкідливі PHP-файли. А потім або шантажувати, або щє щось. Це дуже серйозна проблема, яка може загрожувати безпеці не лише окремих сайтів, а й усього сервера.

Буду вдячний за вашу допомогу або рекомендації щодо того, як можна додатково захистити файловий менеджер від зловмисників.

Дякую за увагу! Чекаю на вашу відповідь.

Перш за все не ясно навіщо доступ програмісту якщо він не може нічого виправити в файлах...

Рекомендації:

1. Не давати доступ до чутливих ресурсів третім особам або людям яким не довіряєте.
2. Користуватися системами контролю версій(git). Всі зміни логуються і в будь який момент можна відкатити.
3. Перед будь-якими змінами робити резервні копії
4. Не надавати доступ до продакшена. Розвернути копію сайта(на тестовому домені/піддомені). Якщо на тесті все добре переносити файли на прод.
5. Якщо потрібен доступ лише до одного сайту - розмістити його в рамках окремого хостинг акаунту, а не надавати доступ до акаунту у якому є інші сайти.
6. Не шукати "спеціалістів" які працюють за пачку сухарів)

Дуже дякую за відповідь. Доступ програмісту дається не ФТП, а делігуванням у випадку якщо потрібно налаштувати хостінг (Мемкеш і все таке для швидкості загрузки). Тільки для файлів кращє давати ФТП - це звичайно. Але ж багато хто з клієнтів які незнають про ФТП просто розшарюють делігування аккаунту і все. так швидше. Файл менеджер не логірується ніяк :( навіщо він взагалі потрібен у делігованному доступі незрозуміло, для файлів є ФТП

навіщо він взагалі потрібен у делігованному доступі незрозуміло, для файлів є ФТП

Тоді потім ще потрідно буде заборонити доступ до налаштування FTP, а також до SSH.

Через SSH я так розумію теж можна багато чого зробити. Тоді і його прибирати у делігованному доступу :) Може ще багато чого є, за що я в не вкурсі. Але було взломано саме так через делігованний доступ, коли про це незнав (А незнають думаю майже всі) . Залили файл доступу mysql, зайшли до БД і видалили інфу. Потім файл видалил, що я навіть не дізнався, так як немає логів файл менеджеру.

Повинен бути власник аккаунту з усіма правами, а делігований доступ з обмеженними правами, або повним його контролем. Делігованним доступом зловмисники і користуються на фрілансі. Вмовити замовника дати делігування, це дуже легко, майже ніхто невкурсах про шкоду. А далі вже є випадки що шантажують, або просять гроші за повернення сайту. Так - давати делігування - це відповідальність власника. Але можна ж подбати про незнаючих власників, котрим був і я.

Делегуванням ви добровільно надали повний доступ. Слово "взлом" в даному контексті точно недоречне.

Стосовно знання чи незнання можна відповісти відомою фразою: "Незнання законів не звільняє від юридичної відповідальності."
Відповідальність за свої дії не варто перекладати на хостинг провайдера. Хостинг провайдер надає інструменти, а вам уже вирішувати чи користуватися і як користуватися цими інструментами.

Логування дій в файлменеджері можливо була б корисна функція, але не панацея. Що заважає залити шелл і далі виконувати будь які дії через нього(і вони не будуть логуватися файлменеджером) або той же SSH і т.д.

Підбирайте правильних людей на довготривалу, стабільну співпрацю. Якщо є сумніви страхуйтеся за допомогою юридичних документів, в яких чітко прописуйте відповідальність сторін.

Так делігування це не взлом, а добровільне передавання всіх дозволів. Зловмисники цим і користуються, а багато власників про це не знають. Я так розумію що є багато способів наробити всещо завгодно. Але ж зв'язка делігування + файл менеджер зараз це самий легкий спосіб. Ви праві що потрібно підбирати программістів, але нікому неможна довіряти, навіть перевіренним.

Виберіть любого програміста на фрілансі, він якщо почує що це хостінг Юкрейн, одразу буде намагатись отримати делігованний доступ :) Буде казати що це на 5хв, потім закриєте і т.д. Я шукав, все так і було. Те що ви говорите не користуйтесь незнайомими людьми, а тільки перевіринними програмістами - правильно. Але ж багато хто незнає про це. З таким висновком можна сказати не варто взагалі онлайн бізнес робити, якщо не розумієшься на захисті :) Дякую за відповідь

Прочитав цей тред – це якийсь цирк :D

Людина абсолютно логічно звернула увагу на критичний недолік у механізмі делегованого доступу, запропонувала варіанти його виправлення, але замість конструктивного діалогу Сергій включає класичну тактику "винен сам користувач" і у традиційно хамській манері несе діч.

Причому, навіть не намагається розглянути проблему, натомість спочатку несе очевидні поради ("робіть бекапи", "користуйтеся git"(ага, стейджинг на шаред хостінгу дуже зручний)), а потім відверто перекладає відповідальність на власника акаунта, якого поставили в умови відсутності базових механізмів контролю доступу.

Розбираємо брєд по пунктах:

1. "Перш за все не ясно навіщо доступ програмісту якщо він не може нічого виправити в файлах..."
   Серйозно? Можливо, щоб налаштувати кешування, змінити конфігурацію PHP/Nginx, перевірити логи або створити крон-завдання? Те, що у вас делегування = повний root-доступ, це проблема вашого недолугого підходу до безпеки, а не користувача.

2. "Не давати доступ третім особам"
   Ну супер, закриваємо компанію, звільняємо всіх розробників, DevOps-ів і сапортів, бо будь-який доступ – це зло. Хостинг взагалі для чого? Щоб користувачі самі собі сайти руками правили?

3. "Незнання законів не звільняє від відповідальності"
   Якби ви хоч трохи розумілися на безпеці, то знали б, що принцип PoLP (Principle of Least Privilege) – це не "закон", а золоте правило доступів. Відповідальність за безпеку завжди лежить на провайдері, який повинен створити систему, що унеможливлює зловживання.

4. "Не шукати 'спеціалістів' за пачку сухарів"
   А що, у вас на хостингу є вбудований механізм перевірки, чи програміст бере оплату не "сухарями"?
   Це не порада, а відверте хамство. Якщо ваш сервіс дозволяє будь-кому знищити сайт через відсутність доступів із обмеженими правами – це не проблема користувача, це проблема ваших кривих налаштувань.

5. "Логування дій у файловому менеджері можливо була б корисна функція, але не панацея"
   Так давайте тоді взагалі приберемо будь-яке логування – навіщо нам історія дій у базі чи аудит дій у панелі? Геніальний підхід. Без логування немає ні розслідувань інцидентів, ні мінімального контролю.

Тобто користувач вказав на реальну проблему - йому почали розповідати очевидні банальності замість того, щоб визнати недолік і хоча б дати нормальну відповідь, чому не можна додати обмежені права і зробити як це вже є у нормальних провайдерів.
Сам хостинг не дає можливості контролювати доступи на рівні налаштувань, не логує дії та, схоже, не планує нічого покращувати.

🤡🤡🤡 Потужно, пане Сергій.

Є низка спірних моментів, для яких не так просто знайти рішення.

З приводу того, що власники хостинг-акаунтів не усвідомлюють наслідків надання делегованого доступу і що шахраї вмовляють їх надати такий доступ. Припустимо, буде не один, а два або більше рівнів доступу. Ті самі шахраї можуть так само вмовити власника надати доступ рівнем вище, придумавши для цього якусь причину, що звучить переконливо (наприклад, для роботи кешування потрібно внести зміни у файли).

З приводу вимкнення файл-менеджера. Якщо його вимкнути, залишається доступ по FTP і SSH. Якщо вимкнути і їх, то залишиться доступ до адмін-панелі сайту (складно уявити, що у розробника не буде доступу навіть до неї і разом з цим він просить доступ до налаштувань сайту на хостингу), а це вже дає теоретичну можливість завантажити на сайт якийсь код (наприклад, у вигляді плагіна або теми) і використати його в подальшому для шкідливих дій.

З приводу лога файл-менеджера. Знову ж таки, залишається доступ через FTP і SSH, а також адмін-панель сайту, що дасть можливість за бажання виконати дії в обхід лога.

Загалом, сама ідея ніби як здорова і зрозуміла, але є відчуття, що це створить лише ілюзію безпеки.