Тут на Хабре уже десятки статей, повествующих, как люди переживали переход на удалёнку, как переживали первые дни удалёнки, потом – как прошла первая неделя, и всё такое прочее. Иногда между описанием эмоций проскакивали какие-то дельные советы. Мы как люди с 12-летним опытом удалённого администрирования серверов решили рассказать про инструмент, без которого удалёнка превращается в довольно опасное для вашего бизнеса мероприятие. Почему? — Потому что народ думает о чём угодно (в первую очередь, конечно, о проклятых бесплатных 40 минутах в «зуме»), но не о безопасности. Точнее, разумеется, вы задумывались об этом вопросе — но поспорим, что он не был первым в очереди?
И встречный вопрос: интересно, к чему привели ваши думы? Ведь ваши коллеги, рассевшись по уютным квартирам и домам, ходят с незащищённого оборудования по незащищённым каналам и буквально трогают всем этим серверы компании…
Мы хотим поделиться с вами open-source версией инструмента, используемого в нашей компании в роли бастионного сервера. Называется он «Сервер аутентификации DevOpsProdigy Isolate».
1. Isolate добавляет одноразовый пароль и двухфакторную аутентификацию в SSH-логин. Для этого можно использовать оборудование YubiKey или приложение Google Authenticator. Даже если пользователь утерял пароль от своего аккаунта, без OTP-ключа злоумышленник не может его использовать и попасть на сервер Isolate. Для реализации двухфакторной авторизации мы используем pam-модуль. Подробнее об этом можно прочитать вот в этой старой статье.
2. Пользователи не получают прямого доступа к конечным серверам — соединение проходит через сервер Isolate, и система отслеживает и фиксирует всю их активность.
Все действия пользователей сводятся к использованию двух команд:
3. Легко управлять доступами к серверу аутентификации — добавлять\удалять пользователей и т.п. В readme вы сможете найти большое количество примеров по использованию команд
Технически вам необходимо сгенерировать и поместить ключ сервера Isolate на конечные серверы, а ваши пользователи должны получить доступ регулярного уровня на сервер Isolate с sudo на ssh.
И когда они захотят соединиться с конечным сервером, система выполнит ssh-команду. Далее ssh-клиент, запущенный от привилегированного пользователя, получит ключ, используя который, система, в свою очередь, получит доступ к нужному серверу.
Вот и всё. Работает Isolate на CentOS 7 / Ubuntu 16.04 / Debian 9 setup. Нужен также Ansible 2.3+.
Не могу не отметить, что DevOpsProdigy Isolate пригодится и в «мирное время»: с ним вы можете быть спокойны за свои сервера, даже если кто-то потеряет ноутбук с SSH-ключом. А когда сотрудник, имевший доступы, покидает компанию, вам не придётся спешно менять все пароли и ключи. Сейчас мы готовим список доработок и фич для текущей версии этого инструмента, которые реализованы в нашей внутренней системе. Ждем пожеланий, issue’s, PR в нашем github-репозитории. Для обсуждений и вопросов есть также telegram-чат и чат в Slack.
Так что теперь удалённая работа в вашей компании, возможно, станет немного проще. И точно — много безопаснее. Удачи!
И встречный вопрос: интересно, к чему привели ваши думы? Ведь ваши коллеги, рассевшись по уютным квартирам и домам, ходят с незащищённого оборудования по незащищённым каналам и буквально трогают всем этим серверы компании…
Мы хотим поделиться с вами open-source версией инструмента, используемого в нашей компании в роли бастионного сервера. Называется он «Сервер аутентификации DevOpsProdigy Isolate».
Как это работает
1. Isolate добавляет одноразовый пароль и двухфакторную аутентификацию в SSH-логин. Для этого можно использовать оборудование YubiKey или приложение Google Authenticator. Даже если пользователь утерял пароль от своего аккаунта, без OTP-ключа злоумышленник не может его использовать и попасть на сервер Isolate. Для реализации двухфакторной авторизации мы используем pam-модуль. Подробнее об этом можно прочитать вот в этой старой статье.
2. Пользователи не получают прямого доступа к конечным серверам — соединение проходит через сервер Isolate, и система отслеживает и фиксирует всю их активность.
Все действия пользователей сводятся к использованию двух команд:
s <search-str>
— для поиска информации по имени проекта или имени сервера, информация хранится в встроенной базе Redis, закрытой авторизацией.g <ip-address> / g <project-name> <server-name>
— вызов данной команды запускает /usd/bin/ssh
. Аргументы для вызова (например, имя пользователя, ip-адрес, порт, прокси) берутся из БД.3. Легко управлять доступами к серверу аутентификации — добавлять\удалять пользователей и т.п. В readme вы сможете найти большое количество примеров по использованию команд
auth-add-user
, auth-add-host
и т. д.Технически вам необходимо сгенерировать и поместить ключ сервера Isolate на конечные серверы, а ваши пользователи должны получить доступ регулярного уровня на сервер Isolate с sudo на ssh.
И когда они захотят соединиться с конечным сервером, система выполнит ssh-команду. Далее ssh-клиент, запущенный от привилегированного пользователя, получит ключ, используя который, система, в свою очередь, получит доступ к нужному серверу.
Вот и всё. Работает Isolate на CentOS 7 / Ubuntu 16.04 / Debian 9 setup. Нужен также Ansible 2.3+.
Не могу не отметить, что DevOpsProdigy Isolate пригодится и в «мирное время»: с ним вы можете быть спокойны за свои сервера, даже если кто-то потеряет ноутбук с SSH-ключом. А когда сотрудник, имевший доступы, покидает компанию, вам не придётся спешно менять все пароли и ключи. Сейчас мы готовим список доработок и фич для текущей версии этого инструмента, которые реализованы в нашей внутренней системе. Ждем пожеланий, issue’s, PR в нашем github-репозитории. Для обсуждений и вопросов есть также telegram-чат и чат в Slack.
Так что теперь удалённая работа в вашей компании, возможно, станет немного проще. И точно — много безопаснее. Удачи!
bofh666
При всем уважении, похоже на изобретенный заново велосипед, причем с не совсем круглыми колесами.
Проблема доступа к приватным SSH ключам на потерянном ноутбуке закрывается шифрованием диска (неужели кто-то этого до сих пор не делает?).
Отзыв доступов покинувших компанию сотрудников решается через централизованную систему AAA, например, FreeIPA.
Хотя, в вашем случае, когда много разных проектов и клиентов, которые не захотят подключаться в ваш Kerberos-домен, может и имеет право на жизнь.
Интересно, что бы сказали про эту штуку аудиторы по всяким стандартам безопасности.
DuD
А чего тут сказать, типичный бастион/голденхост сервер.