Доступ и безопасность | База знаний Policast

Основа

Рабочие принципы

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

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

Полезное правило. Сначала наблюдение и проверка, затем изменение. Это снижает риск прервать рабочий сервис или потерять доступ к серверу.

Идентификация

Управление доступом

Инвентаризация учётных записей

Начните с понимания, кто может войти в систему и какие привилегии уже выданы. Команды ниже не изменяют конфигурацию.

# Обычные локальные пользователи (порог UID может отличаться в дистрибутиве)
awk -F: '$3 >= 1000 && $1 != "nobody" { print $1, $3, $7 }' /etc/passwd

# Кто входит сейчас и кто входил недавно
w
last -a | head -30
lastlog | head -30

# Права конкретного пользователя
id <user>
sudo -l -U <user>

Группы и sudo

Назначайте привилегии через группы, а не через персональные записи в нескольких файлах. Для изменения sudoers используйте проверяющий редактор: он не сохранит файл с синтаксической ошибкой.

# Создать административную группу и добавить в неё согласованного пользователя
sudo groupadd -f ops
sudo usermod -aG ops <user>

# Открыть отдельное правило с проверкой синтаксиса
sudo visudo -f /etc/sudoers.d/ops

# Пример содержимого файла: разрешение должно быть минимальным
%ops ALL=(ALL:ALL) ALL

sudo visudo -cf /etc/sudoers.d/ops

Не выдавайте доступ «на всякий случай». Не используйте NOPASSWD: ALL, если это не обоснованное исключение с владельцем и сроком пересмотра. После изменения попросите пользователя перелогиниться и проверьте фактические права через sudo -l.

Отзыв доступа

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

# Заблокировать пароль и завершить активные сеансы пользователя
sudo passwd -l <user>
sudo loginctl terminate-user <user>

# Проверить, что парольный вход заблокирован
sudo passwd -S <user>

# Позднее, после согласования: убрать из административной группы
sudo gpasswd -d <user> ops

Удалённый доступ

Защита SSH

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

Ключи и разрешения

# На рабочем компьютере: создать ключ с сильной парольной фразой
ssh-keygen -t ed25519 -a 64

# Передать только публичный ключ на сервер
ssh-copy-id <user>@<server>

# На сервере: проверить права каталога и файла ключей
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Безопасная конфигурация

На современных Debian/Ubuntu удобно разместить отдельный файл в /etc/ssh/sshd_config.d/. В других системах добавьте те же параметры в основной файл конфигурации. Значение AllowGroups должно ссылаться на реально используемую группу; перед перезагрузкой укажите фактическое имя SSH-службы вместо <служба_ssh>.

sudo install -d -m 755 /etc/ssh/sshd_config.d
sudo tee /etc/ssh/sshd_config.d/50-access-policy.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
AllowGroups ops
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2
EOF

# Сначала проверить синтаксис, затем перечитать конфигурацию
sudo sshd -t
sudo systemctl reload <служба_ssh>

Защита от потери доступа. Не закрывайте текущую SSH-сессию до успешного подключения по ключу из нового терминала. Если сервер доступен только через SSH, заранее убедитесь, что есть консольный доступ или понятный способ отката.

Проверка текущей поверхности доступа

sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|allowgroups|maxauthtries'
sudo ss -tulpn
sudo systemctl status <служба_ssh> --no-pager

Поддержка

Обновления

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

# Debian/Ubuntu: посмотреть доступные обновления без установки
sudo apt update
apt list --upgradable
sudo apt-get -s upgrade

# Запланированное обновление
sudo apt-get upgrade

# Проверить, нужен ли перезапуск, и состояние неуспешных служб
test -f /var/run/reboot-required && cat /var/run/reboot-required
sudo systemctl --failed

Перед окном	Во время	После
Проверьте актуальную резервную копию и план отката.	Сохраняйте вывод ошибок и отмечайте выполненные изменения.	Проверьте сервисы, доступность и основные пользовательские сценарии.
Уточните владельца сервиса и допустимое время простоя.	Не смешивайте обновление с несвязанными настройками.	Зафиксируйте версии и необходимость перезапуска.

Восстановление

Резервные копии

Минимальная цель — копия конфигураций и данных, независимая от защищаемого сервера. Для важных систем используйте правило 3-2-1: несколько копий, разные типы носителей и хотя бы одна копия вне основной площадки.

Перед созданием копии

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

# Указать отдельное смонтированное хранилище
backup_dir="/путь/к/резервному/хранилищу"
findmnt "$backup_dir"
df -h "$backup_dir"

# Создать архив конфигурации с временной меткой
backup_stamp=$(date +%F)
archive="$backup_dir/etc-$backup_stamp.tar.gz"
sudo tar --xattrs --acls -czf "$archive" /etc
sudo sha256sum "$archive"

# Посмотреть содержимое архива без восстановления
tar -tzf "$archive" | head -30

Тест восстановления

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

archive="/путь/к/созданному-архиву.tar.gz"
restore_dir=$(mktemp -d)
sudo tar -xzf "$archive" -C "$restore_dir"
sudo find "$restore_dir" -maxdepth 2 -type f | head -30
sudo rm -rf "$restore_dir"

Внимательно проверьте цель. Команда удаления выше допустима только для каталога, созданного mktemp -d в предыдущей строке. Для рабочих восстановлений подготовьте отдельный план: особенно для баз данных, виртуальных машин и каталогов с пользовательскими данными.

Наблюдаемость

Журналы и наблюдаемость

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

# Предупреждения и ошибки за текущую загрузку
sudo journalctl -p warning..alert -b --no-pager

# События SSH за сегодня
sudo journalctl -u <служба_ssh> -S today --no-pager

# Размер локального журнала
sudo journalctl --disk-usage

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

Реагирование

Первичная реакция на инцидент

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

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

# Сбор первичного контекста без изменения системы
date -Is
hostnamectl
w
last -a | head -50
ps aux --sort=-%cpu | head -25
sudo ss -tupn
sudo journalctl -S "2 hours ago" --no-pager > /tmp/journal-last-2h.txt

# Проверить недавно изменённые административные правила
sudo find /etc/sudoers.d -type f -printf '%TY-%Tm-%Td %TT %p\n' | sort

Эскалация. Не перезагружайте и не очищайте журналы до фиксации необходимых данных. Если есть признаки утечки персональных данных, компрометации ключей или распространения атаки, действуйте по внутреннему плану реагирования и немедленно подключайте ответственных.

Контроль

Регулярная проверка

Периодически пересматривайте пользователей, группы и правила sudo.
Подтверждайте вход по ключу и отсутствие root-входа по SSH.
Проверяйте доступные обновления и состояние критичных служб.
Контролируйте свежесть, целостность и тест восстановления резервных копий.
Следите за неуспешными входами, объёмом журналов и свободным местом.
После каждого инцидента обновляйте эту практику и назначайте владельца следующей проверки.

↑ Наверх