Root-доступ нужен для администрирования VPS, но запускать от root все процессы подряд - плохая практика. Если веб-приложение, worker, deployment script или backup-процесс работает с полными привилегиями, одна ошибка или компрометация процесса получает слишком большой радиус воздействия.
Практический риск: одна ошибка, слишком большие последствия
Представьте Node.js или PHP-процесс с ошибкой удаления файлов. Под отдельным service user ущерб ограничится каталогами, к которым у этого пользователя есть доступ. Если тот же процесс работает от root, естественные границы почти исчезают.
Три роли, которые лучше разделять
| Роль | Для чего использовать | Чего избегать |
|---|---|---|
| root | OS, пакеты, firewall, users | постоянный запуск приложения |
| deploy user | release и контролируемый deploy | полное администрирование системы |
| service user | PHP, Node, workers, queues | доступ к файлам других проектов |
обзор уровней безопасности хостинга показывает, почему одного защитного механизма недостаточно. Для практических server-side инструментов полезен и материал об инструментах управления сервером.
Зачем нужен sudo
Администратору лучше работать под персональной учётной записью и повышать привилегии только для конкретных системных команд. У каждого члена команды должен быть свой SSH key. Общий root-пароль усложняет аудит, offboarding и расследование инцидентов.
Во время deployment
- владельцем application files должен быть deploy или service user;
- secret-файлы должны иметь минимальные permissions;
- web process должен иметь write access только к нужным каталогам;
- system configuration должна оставаться под admin/root ownership.
root должен быть привилегией, которую вы используете при необходимости, а не default identity для каждого процесса.
Если Linux administration остаётся внутри вашей команды, SERVER1 Unmanaged VPS даёт полный контроль. Если OS-level операции хотите передать провайдеру, сравните с Managed VPS. Дополнительно полезен материал про управление сервером и экономию времени.
Как перейти от модели «всё работает от root» к более безопасной
На production-сервере не стоит начинать с массового `chown`. Сначала составьте карту зависимостей: какой процесс от какого пользователя работает, куда пишет, какие socket и secrets читает, какие cron-задачи незаметно зависят от root.
- Инвентаризация процессов: найдите долгоживущие процессы с UID 0 и обоснуйте каждый.
- Разделение ownership: application code, uploads, cache и logs должны иметь осмысленных владельцев.
- Граница привилегий: создайте service accounts и узкие sudo rules только для нужных административных команд.
- Безопасная проверка: не закрывайте текущую SSH session, пока новый login и sudo не проверены.
- Наблюдение: дайте deployment, cron и backup пройти полный цикл до удаления старых разрешений.
Практический privilege audit
| Область | Красный флаг | Лучшее состояние |
|---|---|---|
| Long-running services | необъяснимые UID 0 процессы | root только там, где он технически нужен |
| Application files | весь deploy tree принадлежит root | отдельные deploy/service owners |
| Scheduled jobs | все cron-задачи выполняет root | минимальный user для конкретной задачи |
| sudoers | слишком широкие права | персональные accounts и осознанные privileges |
| Secrets | слишком широкое чтение config | минимальные read permissions |
Это особенно важно, когда один VPS обслуживает несколько приложений или клиентских проектов. Компрометация одного проекта не должна автоматически означать компрометацию всей VM.
Чего least privilege не решает
Отдельный service user не исправит unpatched vulnerability, украденный administrator key или database, открытый в Интернет. Его задача - уменьшить blast radius, то есть ограничить ущерб после уже произошедшей ошибки или компрометации.
