Единый сервер доступа ssh, возможно ли?

Question

[metalforge]

Администрируем большую vpn сеть (больше 1000 устройств) по ssh. Каждое устройство имеет уникальный пароль. Имеется кастыль KeePass, сотрудникам формируем базу с паролями от тех устройств, к которым они должны иметь доступ и выдаем. Безопасность хромает на все ноги и руки. Условно сотрудник имеет базу с паролями и может её слить, но неавтоматизированный доступ к консоли управления такого количества железок это ад! По обращениям клиентов ты просто висишь на трубке 3-5 минут пока не подключишься к нужному серверу.

Постановка задачи: выделенный сервер "авторизации" с базой паролей ssh соединений.

Чего хотим добиться:
1. Скрыть от сотрудников пароли от конечных устройств.
2. Исключить возможность прямого неконтролируемого удаленного достука к Конечным устройствам (в обход сервера "авторизации").
3. Ведение журнала подключений и журнала действий сотрудников на Конечным устройствам.

Требования:
1. Мандатное управление доступом к конечным устройствам.
2. Никакого стороннего ПО на Конечных устройствах (Железки сертифицырованные).
3. Бесплатное ПО.

Собственно вопрос\просьба: Есть ли подобные решения, внедрял ли кто-нибудь на практике либо проектировал ли сам? Буду рад любым советам\статьям\литературе по теме.

Comments

[Никита Павлов]

А вот это смотрели ? www.opennet.ru/opennews/art.shtml?num=44659

[metalforge]

Тонкость в том, что наши сервера это Сертифицированные по ФСБ и ФСТЭК межсетевые экраны и поддерживают только аутинтификацию по паролю и логину. Процедура компрометации в случае утери пароля или увольнения сотрудника штука очень накладная и болезненная(нужно менять все парные ключи связей на остальных серверах в случае утери пароля или утраты доверия серверу). В случае модификации ПО мы теряем сертификаты наших доблестных Госорганов. Вот и возникла необходимость с одной стороны Не сообщать сотрудникам учетные записи от серверов, с другой стороны обеспечить доступ для администрирования через общий интерфейс с возможностью если не контроля, то хотябы логирования их действий.

[athacker]

Что за межсетевые экраны? Модель напишите хотя бы. Как правило, во всех системах используется SSH на базе OpenSSH. А там есть возможность залить ключи. Мне как-то не попадались ещё системы с SSH и без возможности сделать вход по ключу, а не по паролю.

Answer 1

[athacker]

Очередной пример того, что сертификация -- это просто процесс получения глупой бумажки, и никакого отношения к реальной безопасности не имеет :(

Проблема входа решается генерацией запароленых SSH-ключей для КАЖДОГО сотрудника. За утерю ключа и/или пароля от ключа -- анальная кара в виде трёх лет расстрела без права переписки. Учётные записи сотрудником можете создавать с автоматически сгенерированными паролями, для входа по ключу он не нужен.

Если у вас железо -- юзайте системы управления типа chef/puppet/ansible для централизованного управления процессами разливки/удаления/замены ключей. Либо кастомные скрипты, которые будут подключаться по SSH и управлять ключами командами в shell. Если у вас сервера -- можно юзать те же системы управления (puppet etc), но есть другие системы, типа OpenSSH в связке с LDAP.

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

Answer 2

[Николай Корабельников]

Знаю как решить эту и подобную задачу средствами платного ПО. Поэтому опишу просто подход.
Сервер доступа и аутентификации предоставляет интерфейс многофакторной (не обязательно) аутентификации, после прохождения которой пользователю становятся доступны ресурсы. Веб ресурсы доступны в браузере, а для классических ресурсов строится VPN-туннель(в вашем случае 22 порта) от клиента до сервера доступа.
Доступ к бэкэнд-ресурсам (в вашем случае SSH-серверам) есть только с сервера доступа, напрямую клиенты не должны иметь возможность подключиться к этим серверам.
Дополнительно можно настроить SSO таким образом, что при выборе SSH-сервера у пользователя автоматически запустится putty с указанными учетными записями. По сути сервер доступа и аутентификации будет менеджером паролей к SSH-серверам.

Comments

[metalforge]

Понравился подход. От хранения учеток на ПК пользователя пока не ушел, но уже облегчило жизнь, спасибо.

Пользуемся KeePass базой паролей в тандеме с ГОСТ-плагином и RuTocken для запуска. Пароли пользователю недоступны, только автонабор. Кастыль конечно, но надежней чем Excel док с кучей учетных данных ;).

Готовим решение на c# для централизованного сервера доступа.

Answer 3

[index0h]

э... а чего ssh ключи не подходят?

Answer 4

[Андрей Корытов]

NIS, YP не подойдет для ваших целей?

Answer 5

[Anton_Shevtsov]

thycotic secret server.

Answer 6

[astashov]

А почему бы не OTPW? Нельзя из за сертификации?
У нас просто несколько сотен серверов через отпв и нормально. пароль получается с портала. Обновляется каждые 6 часов. Т.е. взять набор ответов, то через 6 часов они будут не актуальны.

Ну это в частности наш опыт и у нас нет сертификации.