Короткие ответы:
1) Нет — деплой от root в production не считается нормальной практикой и повышает риск инцидентов.
2) Да — в нормальной организации настройка пользователей/gid/прав и SSH‑ключей обычно входит в обязанности системного администратора или платформенной/DevOps‑команды (в зависимости от структуры).
3) Не обязательно уходить сразу, но это серьёзный сигнал: попробуйте сначала действовать по процедуре (риск‑оценка, документирование, эскалация). Если руководство полностью игнорирует риски и отказывается вводить минимальные меры защиты — можно и нужно задуматься о смене места.
Развернуто и по шагам.
Почему деплой от root — плохо
- root имеет неограниченные права: одна опечатка в пути или скрипте может стереть системные каталоги или данные.
- повышается поверхность атаки: если ключ/аккаунт с root‑доступом скомпрометирован — злоумышленник получает полный контроль.
- сложнее контролировать аудит/разграничение и минимизировать blast radius (область ущерба).
Лучше минимальные привилегии: отдельный deploy‑пользователь или ограниченный sudo, сервисные аккаунты с нужными правами.
Кто должен настраивать права и SSH‑ключи
- В большинстве команд это задача администратора/DevOps/platform‑engineer: создание пользователей, групп, назначение владельцев файлов, настройка прав, запрет входа по паролю, развёртывание SSH‑ключей, базовые политики безопасности.
- В небольших проектах обязанности могут пересекаться; но отказ админа выполнять эти базовые безопасные операции — это не обычная «мелочь», а повод для обсуждения с руководством. Руководство обязано управлять рисками.
Практические меры и компромиссы, которые можно предложить прямо сейчас
1) Предложите безопасную минимальную схему, которую можно реализовать быстро:
- отключить root SSH‑логин (PermitRootLogin no) и запретить вход по паролю, оставить только ключи и/или bastion;
- создать пользователя deploy, группу deploy:www-data; код — deploy:deploy или deploy:www-data, runtime (storage, uploads) — www-data:www-data;
- деплой по rsync/ssh от deploy; перезапуск сервисов — через sudo с ограничением (в sudoers — конкретные команды, например systemctl restart myapp).
2) Технические защитники от случайных удалений при rsync:
- rsync --delete-after вместо --delete (меньше риска промежуточных удалений);
- использовать --exclude для runtime/локальных директорий, чтобы их не трогать;
- использовать --backup --backup-dir=... и/или --suffix=.bak для безопасного хранения удалённых файлов;
- перед реальным запуском запускать rsync --dry-run; автоматизировать проверку переменных окружения;
- держать runtime директории вне репозитория (лучше вынести storage на отдельный том или симлинк вне кода);
- хранить регулярные бэкапы и/или снапшоты диска;
- рассмотреть atomic deploy (директории с релизами + symlink current), тогда rsync обновляет новый релиз, а switch — атомарный.
3) Ограниченный sudo вместо root:
- дать deploy право только на нужные команды (правка владельцев/перезапуск сервисов) через /etc/sudoers; не давать полноценный root.
4) Логи, контроль и документирование:
- фиксируйте все запросы и решения письменно (с e‑mail или тикетом), чтобы ответственность и согласования были задокументированы;
- требуйте процедур change management для production‑изменений (временной окно, бэкап, тесты, откатный план).
Если админ отказывается
- Эскалация: покажите руководству риски в терминах бизнеса (потеря данных, время простоя, безопасность). Попросите формально принять риск или изменить практику.
- Если руководство на стороне админа и не хочет мер безопасности — зафиксируйте своё несогласие письменно и сохраните копии инструкций/предложений. Это снизит вашу личную юридическую/профессиональную ответственность.
- Решение о смене работы — личное. Если вы не хотите работать в среде с заведомо повышенным риском или этика работы противоречит вашим стандартам — стоит искать другое место. Но перед уходом попробуйте пройти все шаги: предложить решения, зафиксировать риски, попросить внешнюю ревизию или аудит.
Небольшой чек‑лист, который можно предъявить администратору/руководству
- Запретить root SSH‑логин, оставить только ключи.
- Создать deploy пользователя + группу, назначить владельцев для кода и runtime.
- Вынести runtime папки из репозитория/использовать симлинки.
- Наладить бэкапы и тестовый (dry‑run) деплой.
- Ограничить sudo для необходимых команд.
- Ввести процедуру change control в production.
- Оформить согласование рисков в письменном виде.
Если хотите, могу:
- составить конкретный план действий и команды для Ubuntu 16 (создание пользователя, права, sudoers, безопасные rsync‑параметры),
- подготовить текст письма/тикета для руководства с описанием рисков и предложенными мерами.