Мы продолжаем развивать нашу платформу для разработчиков и их команд. В этот раз мы снова наступили на грабли безопасности но уже в части SSH доступа к серверам с Zero Trust и аудитом.
Что такое Tuna бастион?
На текущий момент это SSH-сервер с ролевой мандатной моделью доступа, использующий принципы нулевого доверия (Zero Trust). В отличие от классических SSH-серверов, бастион делает акцент на идентификацию пользователей, временные сертификаты и ролевую модель доступа, обеспечивая повышенную безопасность доступа к вашим серверам в купе с простой настройки.
Если вы когда либо слышали о teleport или hashicorp boundary, то да, это прямой аналог и конкурент. Только наша цель сделать подобный функционал доступным всем, а не самым дорогим в мире 
Немного теории
Вместо традиционного SSH-доступа ssh user@host на основе паролей или RSA ключей, пользователи аутентифицируются через наш клиент tuna у нас на портале. Далее на бастион сервере работает аутентификация на основе сертификатов, это штатный функционал OpenSSH, но является самым безопасном из всех, но исторически был самым сложным в настройке.
Но всю сложность мы берём на себя, вам же остаётся только безопасность! После авторизации на портале, клиент генерирует RSA ключи и публичную часть передаёт в API Tuna, для последующей доставки на бастион серверы. Клиент также генерирует временный PKI сертификат и он подписывается CA в портале Tuna. C RSA ключом и сертификатом вы подключаетесь к серверу, сервер проверяет, что сертификат действителен, подписан верным CA и у пользователя на которого выписан сертификат достаточно прав на доступ с учётом ролей и политик. Бастион серверы в свою очередь тоже имеют временные сертификаты подписанные CA и при установке соединения клиент также проверяют валидность в CA но сервера, так вы уверены, что ваш сервер, это ваш сервер, а не что-то подставное. В итоге мы ничего не знаем про приватные ключи серверов и клиентов, они генерируются и хранятся локально, а значит у нас нет возможности подключиться к вашей инфраструктуре, как и злоумышленникам в случае утечек у нас, но мы выступаем 3й стороной хранителем CA, что подписывает сертификаты и аутентифицирует пользователя.
Сложновато выглядит, не правда ли? Но на самом деле использование сводится к простым шагам.
Как это выглядит на практике?
-
Вы запускаете tuna-bastion на своём сервере и регистрируете его в API Tuna.
-
В панели управления my.tuna.am создаёте роль описывающую модель доступа и применяете к нужному пользователю, либо пользователь запрашивает доступ к нужному узлу и роль создаётся автоматически при подтверждении запроса.
-
Пользователь запускает у себя команду
tuna bastion login username. Генерируется пара RSA ключей, и происходит подпись сертификата на 12 часов, но это происходит только если у пользователя достаточно прав на подключения с таким логином. -
Пользователь запускает команду
tuna bastion ssh username@hostnameи если его сертификат валидный, сертификат сервера валидный, у пользователя достаточно прав и не наложено ограничений, то тогда сессия устанавливается.
1. Добавляем сервер
На странице с серверами в разделе бастион команды, нажмите Добавить сервер, вы увидите короткую инструкцию по установке бастион сервера на ваш хост с помощью скрипта, а также регистрацию и запуск сервера.
Регистрация и запуск, если у вас нет специфических сетевых настроек, то это просто ДА, ДА, Далее… , разве что нужно будет переопределить леблы на свои.
2. Создание роли доступа
И так после регистрации хотя бы одного бастион сервера в команде, члены команды будут видеть его в разделе бастион серверов и смогут запросить доступ.
Нужно будет указать username пользователя на сервере и причину которую увидит администратор команды.
Администратор команды увидит этот запрос и сможет его одобрить или отклонить.
В ролях будет создана уникальная роль с разрешением доступа к определённому username и узлу, эта роль также будет автоматически назначена пользователю, что спрашивал доступ.
Естественно вы можете и заранее создать все роли относительно лейблов и username и тогда пользователю не нужно будет ничего запрашивать.
Роль нужно будет назначить на пользователя, чтобы это работало
Вероятнее всего в будущем появятся и группы пользователей, но не будем загадывать 
.
3. Авторизация пользователя в cli
Теперь пользователь может авторизоваться, получить сертификаты и далее подключаться, для этого ему нужно установить клиент tuna и выполнить команду:
tuna bastion login rootЕстественно, у вас username может отличаться, root я использую исключительно для примера в этой статье, в реальных конфигурациях мы рекомендуем делать выделенного пользователя с ограниченными sudo правами.
По ссылке пользователь увидит примерно вот такой банер:
4. Подключение клиента и другие фичи команды tuna bastion
Это финал, теперь клиент может просто подключаться:
tuna bastion ssh username@hostnameНа самом деле для подключения используется системный openssh клиент, и полную команду вы можете увидеть добавив флаг --log-level=debug
$ tuna bastion ssh root@debian-4gb-hel1-2 --log-level=debug DEBU[09:53:19] $ ssh -i /home/jidckii/.tuna/bastion/keys/id_rsa -o CertificateFile=/home/jidckii/.tuna/bastion/keys/root-cert.pub -o UserKnownHostsFile=/home/jidckii/.tuna/bastion/keys/known_hosts -p 993 root@157.180.40.63 Можно даже сгенерировать стандартный ssh config с помощью tuna bastion ssh_config и не использовать tuna bastion обёртку:
$ tuna bastion ssh_config root@debian-4gb-hel1-2 Host debian-4gb-hel1-2 Hostname 157.180.40.63 Port 993 User root CertificateFile /home/jidckii/.tuna/bastion/keys/root-cert.pub UserKnownHostsFile /home/jidckii/.tuna/bastion/keys/known_hosts IdentityFile /home/jidckii/.tuna/bastion/keys/id_rsa Сохранить config tuna bastion ssh_config username@hostname > ~/.ssh/hostname.ssh_config и подключаться примерно так ssh -F ~/.ssh/hostname.ssh_config hostname. Но это просто пример, а не призыв к действию. Вы можете использовать любой удобный вам метод .
Единственный момент в том, что сертификат клиента выпускается на 12 часов, и при любых условиях раз в 12 часов клиенту придётся проходить повторную авторизацию tuna bastion login username. Но если у вас долгие сессии и подключение запущено через обёртку tuna bastion ssh username@hostname, то тогда сертификат автоматически ротируется в фоне и заново авторизовываться и переходить по ссылке не нужно.
Вы также можете посмотреть информацию о сертификате и назначенных пользователю ролях с tuna bastion status:
$ tuna bastion status INFO[10:14:17] root [root, request-1] - Valid until 2025-03-31 19:47:23 +0000 UTC Ну и посмотреть список доступных серверов с tuna bastion ls:
$ tuna bastion ls INFO[10:16:35] debian-4gb-hel1-2 (service=ssh, env=testing, region=am) Цены и монетизация
В настоящий момент функционал находится в стадии открытого тестирования. Это доступно всем пользователям с подпиской на тариф Команда. В будущем формат и монетизация может существенно измениться.
Если вы ещё не наш клиент и хотите попробовать и протестировать работу сервиса Бастион, мы с радостью предоставим вам бесплатный пробный доступ на ограниченный период, просто напишите по почте info@tuna.am или нашем чате в telegram и попросите об этом.
Итоги и выводы
Естественно это лишь базовый функционал но мы планируем имплементацию и других функций, вроде доступа к базам данных и kubernetes, с полным аудитом, нулевым доверим и прочими прелестями.
Основные принципы что есть или планируются:
-
Мандатная (Role-Based Access Control, RBAC) модель — доступ управляется через роли и политики, а не вручную через файлы authorized_keys (в контексте SSH доступа)
-
Zero Trust — проверяет не только учетные данные пользователя, но и контекст — Кто запрашивает доступ? Какой сервер и с какой целью? Какие параметры у сессии (время, источник, политика MFA)?
-
Аутентификация без паролей (Passwordless) — вместо статических паролей, в дополнение к SSH-ключам используются PKI-сертификаты, которые автоматически истекают.
-
(скоро) Аудит и наблюдаемость — каждая SSH-сессия записывается, что позволяет просматривать действия пользователей в реальном времени.
-
(скоро) Интеграция с SSO (OAuth, OpenID, SAML, LDAP) — пользователи могут аутентифицироваться через корпоративные сервисы, такие как Google Workspace или Okta.
На этом у меня всё, спасибо что дочитали до конца
Тут я хочу напомнить, что Tuna — это платформа для разработчиков и их команд, нацеленная на ускорение разработки, упрощение командного взаимодействия и безопасностью. И бастион это не единственный наш сервис:
Туннели — мы также предоставляем сервис обратных реверс-прокси HTTP, TCP и SSHd туннелей, аналогично ngrok.
Шлюзы — это всегда доступный облачный балансировщик или WEB сервер с гибкими политиками обработки трафика и простой и мгновенной настройкой в веб интерфейсе.
Пароли — абсолютно бесплатный облачный менеджер паролей. Работает в web интерфейсе личного кабинета, создан для безопасного хранения и удобного обмена паролями внутри рабочих команд и не только. Мы не храним пароли в открытом виде, согласно модели нулевого знания, только пользователь обладает ключами, которые могут расшифровать данные.
Бастион — этому функционалу посвящена данная статья.
Контакты
Подробнее можете посмотреть всё на сайте tuna, в документации и блоге надеюсь вам понравится работать с tuna.
Если возникли вопросы, можете задать их нам по почте info@tuna.am, тут в коментариях или нашем чате в telegram.
ссылка на оригинал статьи https://habr.com/ru/articles/895068/
Добавить комментарий