← вся теориятеория к собесу · Безопасность инфраструктуры

Доступы: SSH, бастион, минимальные права

Доступы и минимальные права

Проверил, что может обычный контейнер по умолчанию. Работает он от root - пользователя системы с максимальными правами, - и ему выдано четырнадцать отдельных прав, включая смену владельца файлов, повышение до любого пользователя и создание устройств. Смена владельца чужого файла проходит успешно. Тот же контейнер с отобранными правами отвечает «Operation not permitted», и точно так же отвечает контейнер, запущенный от обычного пользователя.

Стержень: права выдаются по умолчанию щедро, а минимальные права - это то, что настраивают руками и проверяют.

// Формулировки: «зачем запускать не от root?», «что такое минимальные права?», «как выдавать доступы людям?»

Не от root и без лишних прав

Права root в Linux разложены на отдельные разрешения: менять владельца файла, обходить проверку прав, поднимать сетевой сокет на маленьком порту, создавать устройства и так далее. Контейнеру по умолчанию выдают четырнадцать таких разрешений - я их перечислил на стенде.

Практика минимальных прав состоит из трёх шагов, и все три я проверил. Первый: запускать от обычного пользователя, а не от root - тогда чужие файлы не тронуть. Второй: отобрать все разрешения и вернуть только нужные - у меня после отбора та же операция стала невозможна. Третий: запретить повышение прав, потому что внутри образа остаются программы, работающие от владельца файла. В базовом образе debian я насчитал восемь таких программ, среди них смена пароля и переключение пользователя; в alpine их ноль.

// Четвёртый шаг - файловая система только на чтение. Обычный контейнер спокойно пишет прямо в системные файлы: я записал произвольный текст в файл пользователей. С запретом записи попытка даёт «Read-only file system», а для временных файлов отдельно подключают кусок памяти.

разрешения root: права root, разложенные на отдельные кусочки; выдаются по одному
программа с правами владельца: запускается от владельца файла, обычно от root, кем бы её ни запустили
только на чтение: режим, при котором контейнер не может писать в свою файловую систему

Доступы людей

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

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

// Отдельно - права на прод. Постоянный доступ туда не нужен почти никому: обычные задачи решаются через выкатку и через готовые кнопки. Доступ по запросу с обоснованием и на срок покрывает остальное. Хороший вопрос для проверки схемы: сколько человек прямо сейчас могут зайти на боевую базу и удалить таблицу? Если ответ больше двух-трёх, схемы нет.

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

Права машин и долгие токены

У сервисов проблема та же, что у людей, но хуже: их доступы никто не пересматривает. Классика - один токен (строка-пропуск, по которой сервис получает доступ) с полными правами, который знает половина команды, лежит в трёх местах и заведён пять лет назад.

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

// Проверка, которая быстро находит дыры: взять любой сервис и спросить, что он может СВЕРХ своей задачи. Сервис отправки писем с правами на запись в основную базу, сборочный агент с ключами от прода, читающий отчёт с правом удаления - это находится за полчаса и чинится сужением прав. И второе: сколько времени живёт токен и кто заметит, если он утечёт.

личность сервиса: отдельная учётная запись под каждый сервис, а не общий токен
короткий срок жизни: токен протухает сам; продление делает автоматика

Как отвечать: «Почему нельзя запускать контейнер от root?»

Потому что root внутри контейнера - это тот же root машины, просто с урезанным набором разрешений. Я проверял на стенде: обычному контейнеру по умолчанию выдают четырнадцать отдельных прав, включая смену владельца файлов и создание устройств, и смена владельца чужого файла проходит успешно. Тот же контейнер от обычного пользователя отвечает «операция не разрешена». Второе: файл, созданный контейнером в примонтированном каталоге, принадлежит root на самой машине, и это ежедневная боль с правами. Третье: внутри образа остаются программы, работающие от владельца файла, - в debian их восемь, включая смену пароля, а в alpine ноль. Поэтому минимальный набор такой: запуск от обычного пользователя, отобрать все разрешения и вернуть только нужные, запретить повышение прав и сделать файловую систему только на чтение с отдельным куском памяти под временные файлы.

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

На чём валятся

−Запускают контейнеры от root и потом разбираются с правами на примонтированных каталогах.
−Оставляют выданными все разрешения, хотя сервису нужно ноль из них.
−Раздают постоянный доступ на прод вместо доступа по запросу и на срок.
−Заводят один общий токен с полными правами на все сервисы.
−Не пересматривают права машин: они живут годами и растут только вверх.

Проверьте себя

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

#dvo_access1 / 5
Инженер уволился. Учётку в почте и SSO заблокировали. Что остаётся незакрытым?
A)Личные ключи и токены, заведённые им в CI, кластере и облаке
B)Права в системе контроля версий: они привязаны к коммитам
C)Сессии в браузере: их отзыв возможен только через сутки
D)Резервные копии, где сохранены его домашние каталоги
показать ответ и разбор
+A)Личные ключи и токены, заведённые им в CI, кластере и облаке
// разбор: Блокировка входа не трогает то, что живёт само по себе: персональные токены доступа к репозиториям, ключи развёртывания, сервисные учётки, заведённые «на время», записи в authorized_keys, ключи облака в переменных пайплайна. Потому в чек-лист увольнения входит инвентаризация долгоживущих ключей и их отзыв, а системно проблему решают короткие токены и выдача доступа через SSO, а не персональные секреты.
#dvo_access2 / 5
Учётки администраторов защищены только логином и паролем. Какой базовой защиты не хватает?
A)Более длинного пароля с обязательной сменой каждый месяц
B)Ограничения входа рабочими часами по расписанию
C)Запрета одинаковых паролей у разных админов
D)Второго фактора (MFA) — пароль в одиночку слишком слаб
показать ответ и разбор
+D)Второго фактора (MFA) — пароль в одиночку слишком слаб
// разбор: Пароль как единственный фактор уязвим: фишинг, утечки, повторное использование, подбор. Базовая защита привилегированных учёток — MFA (второй фактор: аппаратный ключ/TOTP, лучше устойчивый к фишингу WebAuthn). Тогда украденного пароля недостаточно для входа. Принудительная частая смена пароля, наоборот, снижает качество паролей; ставку делают на MFA и менеджеры паролей.
#dvo_access3 / 5
У инженеров постоянно висят админ-права на прод «на случай инцидента». Как снизить риск, не мешая работе?
A)Повышенный доступ по запросу на время (JIT)
B)Раздать всем чуть меньше прав, но тоже постоянные
C)Записывать сессии, оставив права постоянными
D)Сменить пароли админов на более длинные раз в квартал
показать ответ и разбор
+A)Повышенный доступ по запросу на время (JIT)
// разбор: Постоянные (standing) админ-права — большой риск: их могут украсть или использовать по ошибке в любой момент. Just-in-time доступ переворачивает модель: по умолчанию повышенных прав нет, инженер запрашивает их под конкретную задачу/инцидент, получает на ограниченное время (с апрувом/логом), и они автоматически отзываются. Плюс запись сессий на бастионе. Так окно возможной атаки сжимается до момента реальной работы.
#dvo_access4 / 5
На прод-серверах у инженеров лежат личные долгоживущие SSH-ключи. Уволенных отозвать трудно. Что зрелее?
A)Раздать всем один общий ключ, его проще менять
B)Складывать публичные ключи в один большой authorized_keys
C)Короткоживущие SSH-сертификаты от своего CA вместо постоянных ключей
D)Пускать по паролю вместо ключей для простоты отзыва
показать ответ и разбор
+C)Короткоживущие SSH-сертификаты от своего CA вместо постоянных ключей
// разбор: Долгоживущие персональные ключи в authorized_keys плохо отзываются: при увольнении/ротации надо руками вычищать их со всех хостов, и легко что-то забыть. Зрелее — SSH-сертификаты: свой центр сертификации (CA) подписывает пользователю короткоживущий сертификат (часы), хосты доверяют CA. Доступ отзывается тем, что человеку просто перестают выдавать новый сертификат, а старый истекает сам. Плюс — привязка к личности и централизованная политика.
#dvo_access5 / 5
Что требует принцип наименьших привилегий?
A)Выдавать ровно те права, что нужны для работы, и не больше
B)Раздавать всем одинаковый набор прав для простоты
C)Ограничивать число сотрудников с доступом к системе
D)Менять пароли по расписанию каждый месяц
показать ответ и разбор
+A)Выдавать ровно те права, что нужны для работы, и не больше
// разбор: Смысл в ограничении ущерба: взломали сервис с правами только на чтение одной таблицы — этим потери и ограничатся. Права выдают под задачу и по возможности на время, а не «админа на всякий случай».

дальше

Теорию прочитали. Навык ставится повторением

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

Открыть тренажёр Вся тема: Безопасность инфраструктуры