ITSumma corporate blog
Server Administration
System administration
Comments 15
0
The idea behind Isolate is that we should somehow manage how do people get access to our servers. How can we make this process more secure? How could we prevent a system from being compromised when someone lost the laptop with ssh key. What would we do in case someone quits the company — is there an alternative to just changing all passwords, keys, etc?

А ssh certificates не решают эту же проблему?

0
А вообще для всех тех кто только научился заходить на сервер по ssh после прочтения двух трех мануалов и сразу решил что «надо эту проблему решить», все уже давным давно решено за них: OpenLDAP, FreeIPA, SSSD и прочее. Целый зоопарк решений для управления авторизацией на больших группах серверов.
0
конечно :)
мы не претендуем на глобальное решение которое заменит все, но если есть телефон, есть желание защититься лучше, и при этом не постоянным паролем а дополнительно OTP кодами, можно просто склонить репозиторий и через пять минут получить решение, то есть да, другие решения конечно есть, но мы поделились простым, которое может быть кому то пригодиться (и люди вместо сложного внедрения будут использовать наше) :)
0
How could we prevent a system from being compromised when someone lost the laptop with ssh key. What would we do in case someone quits the company — is there an alternative to just changing all passwords, keys, etc?


Судя по вот этому ваше решение это велосипед который игнорирует уже существующие системы (которые к слову развивались не один год). Простейший OpenLDAP+SSSD позволит в одну минуту заблокировать пользователя на всех серверах + отозвать sudo привилегии + отозвать доступ к сервисам которые работают через PAM или напрямую через LDAP и т.д. и т.п. И все это сделано централизованно без необходимости использовать несуразный Ansible (его сейчас вообще очень модно использовать где попало). Опять же с банальным OpenLDAP и SSSD можно включить MFA на всех устройствах. А если идти более сложным путем (FreeIPA) то открывается еще больше возможностей.

Дисклеймер: Я не против Ansible, и сам его использую чтобы поддерживать примерно 1.5к серверов. Но я точно не хочу использовать его для вот таких вещей.
0
у нас немного другая задача: сервера не наши, а клиентские. Сейчас мы даем клиентам публичный ключ, что бы они его себе добавили. Осталось только придумать, как своим сотрудникам не давать приватный, а разрешать им пользоваться.
0
Ну у нас как бы тоже самое. Сервера не свои, а клиентские. Своих и клиентских пользователей мы добавляем в LDAP. Наши пользователи имеют доступ ко всем серверам, но только по определенному тикету, если нет тикета, нет и доступа. Клиентские пользователи имеют доступ только к своим серверам, но у них доступ не ограничен тикетом (может быть ограниченный sudo, например разработчики могут переключится на пользователя под которым работает приложение, или только могут управлять определенными процессами).

Пароли, ключи, MFA, время доступа, какие команды могут быть выполнены с sudo, на какие сервера можно залогиниться и откуда. Все это вполне себе управляется через LDAP.

Как я сказал выше этот продукт не добавляет ничего нового, а только является очень очень странным велосипедом в области где все уже вполне себе хорошо не первый год.
0
Если нет проблем с англ. очень советую прочитать вот эту статью про достоинства и недостатки FreeIPA+SSSD+MFA, но эта статья достаточно старая и многие указанные там недостатки уже были исправлены (в статье есть ссылки на соответствующие дискусси разработчиков)
0
Кажется вам подойдет смарт-карта. Ключ физически у пользователя, но он не может его получить в открытом виде, а может только использовать.

Другой вариант, вероятно более подходящий под ваше описание: облачный сервер подписи. Ключи пользователей могут храниться на нем + HSM. При прохождении строгой аутентификации(можно даже по OTP-паролям) на этом сервере, он позволит подписать аутентификационный запрос. Правда, насколько мне известно, пока облачные сервера подписи используются только для подписи. Но аутентификация по ключам подразумевает как раз подпись нонса, так что это тоже должно быть возможно.
0
А в чем преимущество по сравнению с аутентификацией по сертификату, который зашифрован паролем?
0
чуть ниже уже ответил
главный мой страх по сути: любой кейлоггер позволит утащив сертификат ввести пароль и работать с сервером, допускать такого не хочется ни по какой причине (поэтому и на почту делают не второй пароль а именно одноразовые коды — даже свиснутый код не сработает)
0
Немного не понимаю зачем нужна двухфакторная аутентификация для ssh если использовать вход по ключу и ключ можно зашифровать паролем, ну если только вы боитесь что кто-то ваш приватный ключ украдет + пароль он него, но если кто-то украл ваш приватный ключ то мне кажется стоит задуматься о том, а не делаете вы что-то неправильно и на сколько хорошо ваш спасет двух фактурная амортизация (если кто-то получил доступ к вашей машине)?

По мне так если париться, так сделать уведомления об подключения к серверу с нового ip или добавления нового публичного ключа на авторизацию.
+1
о, здесь очень просто
даже лично я, оставаясь параноиком боюсь компрометации лэптопа/компьютера где лежит ключ
как говорят — по настоящему система защищена тогда, когда ты понимаешь что даже в случае компрометации, важные данные не будут потеряны
условно говоря если хоть каким то образом мой компьютер будет скомпрометирован (кейлоггер, что угодно), зайти на серверы будет нельзя, так как 2FA не даст повторить попытку
0
Да, вы правы, это вполне себе неплохая дверь которую плохие программы скорее всего не рассчитаны открывать, но думаю преимущество это зашита от кейлогеров перед это как раз участие 2 устройств для авторизации.

Хотя, у меня есть вариант взлома (говорю уже с моменте когда злая программа силой магии попала на ваш компьютер):
Мы просто эмулируем подключения к вашему серверу для вас (такой странны консольный малварь).

И мне кажется повысить зашиты можно немного по другому. Это использовать 2 фактурную авторизацию при выполнении команд от root, и возможно даже написать отдельный протокол подтверждения команды с телефона.

Просто мне кажется вы не понимаете что хотите защитить, я не боюсь что кто-то подключить к серверу, я боюсь что кто-то получит доступам к файлам на этом сервере.
Only logged in users are able to leave comments. , please.