Перейти к содержимому
BXWiki

Доступ к серверу - учётные записи, ключи, права, отзыв

Раздаём доступ к серверу сайта правильно: именные учётные записи, вход по ключу, ограниченные права, права на файлы и своевременный отзыв.

Что нужно знать заранее

Общая учётная запись на всю команду сводит на нет любой разбор. Когда все ходят под одним именем, вопрос «кто удалил каталог» остаётся без ответа навсегда.

Вход по паролю роботы подбирают круглосуточно и без всякого повода с вашей стороны. Ключ снимает этот класс проблем целиком, а вход по паролю после раздачи ключей отключают совсем.

Файлы сайта принадлежат пользователю веб-сервера, а вовсе не человеку за клавиатурой. Скрипт, запущенный из-под полных прав, оставляет за собой файлы, которые сайт потом не может ни прочитать, ни перезаписать.

Шаги

  1. Завести именную учётную запись каждому человеку, который работает с этим сервером.
  2. Положить в неё открытый ключ человека и проверить вход по нему.
  3. Отключить вход по паролю и прямой вход под полными правами системы.
  4. Выдать ограниченный список команд вместо полных прав всем, кроме администратора.
  5. Отзывать доступ в день ухода человека или в день окончания работ подрядчика.

Решение

Заводим именную запись и кладём ключ:

Окно терминала
useradd -m -s /bin/bash ivanov
usermod -aG bitrix ivanov                        # доступ к файлам сайта на чтение
install -d -m 700 -o ivanov -g ivanov /home/ivanov/.ssh
echo 'ssh-ed25519 AAAA... ivanov@laptop' > /home/ivanov/.ssh/authorized_keys
chown ivanov:ivanov /home/ivanov/.ssh/authorized_keys && chmod 600 $_

Права на каталог ключей проверяются службой входа строго. Слишком открытые права на каталоге или файле ключей молча отключают вход, и это первое, что стоит проверить при отказе.

Отключаем вход по паролю:

Окно терминала
sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sshd -t && systemctl reload sshd                 # проверка конфигурации до перезапуска
# вторую сессию не закрывают, пока не проверят вход в новой

Открытая вторая сессия на время правки настроек - обязательная страховка администратора. Ошибка в настройке входа при закрытой сессии означает поездку в дата-центр или обращение в поддержку хостинга.

Ограничиваем полные права списком команд:

Окно терминала
# /etc/sudoers.d/deploy, правится только через visudo
ivanov ALL=(root) NOPASSWD: /bin/systemctl reload nginx, /bin/systemctl reload php-fpm
# полные права оставляют администратору сервера, а не всей команде разработки

Смотрим, кто и когда заходил:

Окно терминала
last -n 20
grep -iE 'Accepted|Failed' /var/log/secure 2>/dev/null | tail -20
# журнал показывает и успешные входы, и попытки подбора

Отзываем доступ:

Окно терминала
usermod -L ivanov && usermod -s /sbin/nologin ivanov   # блокируем вход
rm -f /home/ivanov/.ssh/authorized_keys                # убираем ключ
pkill -u ivanov                                        # закрываем текущие сессии

Отзыв доступа делают в день ухода, а не в конце месяца. Забытый ключ подрядчика живёт на сервере годами и всплывает при разборе очередного инцидента.

Типичные проблемы

Непонятно, кто именно поменял файлы на сервере.

Вся команда работает под одной общей учётной записью без всякого разделения. Каждому человеку заводят именную запись, и тогда журнал входов становится осмысленным.

В журнале входов тысячи попыток подбора пароля.

Вход по паролю оставлен включённым и доступен из любой сети мира. После раздачи ключей всей команде вход по паролю на сервере отключают совсем.

Сайт перестал писать в каталог после работы скрипта.

Скрипт запускали из-под полных прав, и созданные файлы достались другому владельцу. Скрипты сайта запускают под пользователем сайта, а владельца проверяют после.

У подрядчика остался доступ после окончания работ.

Ключ и учётная запись не удалялись, потому что об этом никто не вспомнил. Отзыв доступа включают отдельным обязательным пунктом в чек-лист приёмки работ.

Разработчик случайно перезапустил не ту службу.

Полные права выданы всей команде разработки вместо короткого списка разрешённых команд. Полный доступ оставляют только администратору сервера, а остальным выдают перечень разрешённых команд.

Частые вопросы

Ключ или пароль?

Ключ: пароль подбирают автоматически круглосуточно. После перехода на ключи вход по паролю отключают, иначе смысла в переходе нет.

Можно ли работать под пользователем сайта?

Для запуска скриптов сайта - да, это правильный пользователь. Для входа людей лучше именные записи с добавлением в нужную группу.

Как дать доступ подрядчику на время?

Именной записью с его ключом и записью в чек-лист об отзыве. Общий доступ «на всех подрядчиков» превращается в бессрочный.

Нужно ли менять порт входа?

Это уменьшает шум в журналах, но защитой не является. Реальную защиту дают ключи, отключённый пароль и ограничение доступа по сетям.

Что проверять после инцидента?

Список учётных записей, содержимое файлов ключей и журнал входов за период. Незнакомый ключ - повод считать сервер скомпрометированным.

Смежное

Первоисточник