Под моим надзором примерно 1000 железных серверов, даже не начинаю считать. Пару десятков из них обладают весьма критичными данными. И банальный ssh с ключами в стандартной ситуации не достаточно безопасен. Не все «кожаные люди» берегут ключи, поговорим как защититься от возможности потери ключа пользователем.
Кого защищаем
«Стандартная» компания. Наибольшее количество персонала в службе заботы клиентов и поддержке. Честный SSH доступ к серверам есть только у поддержки 3 линии, порядка 12 человек. Завершает набор технический авангард компании — «отдел обслуживания» человек на 8.
Массовый пользователь
Для отдела поддержки и частично отдела обслуживания настроен сервер авторизации SSH. Это сервер который имеет ключ для авторизации почти куда угодно. Всемогущий ключ одна из самых ценных информаций, которую нельзя упустить. Напрямую читать его могут 4 человека в конторе. Резервная копия на бумаге лежит в сейфе. Так же на этот сервер получают временный доступ разработчики которым надо воочию увидеть где и как сломалось.
Сотрудник может через сервер авторизации получить ssh доступ с использованием всемогущего ключа. Технически эти сотрудники могут позвать только одну команду — ssh, ssh в свою очередь использует приватный ключ для подключения к удаленному серверу. Как правило сотрудники используют локальный скрипт для быстрого использования сервера авторизации. Исторически сложилось что он называется go. Вот его содержимое:
Еще один плюс общего сервера авторизации это возможность логировать и считать статистику для всех сотрудников. Мы знаем какой сотрудник сколько времени провел на каком сервере. На случае внештатных ситуаций знаем что сотрудник там вводил и что ему отвечало, так как копируется весь ввод и вывод ssh-сессии.
Полубоги
Второй серьезной уязвимостью являются всемогущие ключи нескольких сотрудников. Такие ключи разрешается прописывать на сервера только с параметром from=””. В authorized_keys это выглядит вот так:
Указанные всемогущие 4 человека осознают свою значимость и шифруют диск ноутбука не забывая о пароле на приватную часть ключа.
Работа вне офиса возможна только с использованием VPN до офиса. Если в офисе нет электричества у нас есть резервный VPN сервер который так же умеет анонсировать нашу офисную сеть.
Всемогущий сервер
Последним серьезным пунктом является большой служебный сервер. Сервер осуществляет мониторинг почти всего и знает обо всех железяках и зачем они нужны, кроме этого на нем запускаются все ansible задачи. На сервере лежит свой приватный ключ под паролем. После входа на сервер магия с ssh-agent в bashrc предлагает ввести пароль от ключа. Дальше можно работать в полную силу. Прямого ssh на этот сервер нет, «два притопа, три прихлопа» и ты на сервере.
Эти правила не отменяют нормальную настройку файрвола на серверах. Но файрвол как правило настраивается чуть шире и пускает ssh из офисной сети, далее через sshd_config прижимаем список ip которые могут стать root:
А если все это не сработает
Последним бастионом проверки на каждом сервере выступает .bashrc файл, при инициализации shell по ssh стартует bash, и он проверяет источник подключения:
Такое количество вариантов ограничения используется чтобы скомпоновать нужный уровень защиты, не заблокировав работу сотрудника. Но при этом сохранить уверенность что сервер прикрыт. По мере роста компании я все меньше уверен в программах запускаемых в офисе. Я доверяю всем сотрудникам, но сплю с трудом.
Планы на доделку
Расширить функционал сервера авторизации, чтобы можно было указывать список или маску серверов для каждого пользователя. Возможно дописать bashrc чтобы он в момент подключения скидывал информацию о пользователе и ip. Далее поднимать флажки если у пользователя новый ip или что-то в этом духе. Не уверен что это работающая схема, но попробовать на досуге можно будет.
Автор: Артем Артемьев
