Перейти к основному содержимому

Бастион

SSH-сервер с ролевой мандатной моделью доступа, использующий принципы нулевого доверия (Zero Trust). В отличие от классических SSH-серверов, бастион делает акцент на идентификацию пользователей, временные сертификаты и ролевую модель доступа, обеспечивая повышенную безопасность доступа к вашим серверам в купе с простой настройки.

bastion-main

Обзор​

к сведению

В настоящий момент функционал находится в стадии открытого тестирования. Это доступно всем пользователям с подпиской на тариф Команда. В будущем формат и монетизация может существенно измениться.

Что такое бастион в контексте SSH-доступа?​

Вместо традиционного SSH-доступа ssh user@host на основе паролей или RSA ключей, пользователи аутентифицируются через наш клиент tuna у нас на портале. Далее на бастион сервере работает аутентификация на основе сертификатов, это штатный функционал OpenSSH, но является самым безопасном из всех, но исторически был самым сложным в настройке. Всю сложность мы берём на себя, вам же остаётся только безопасность. После авторизации на портале, клиент генерирует RSA ключи и публичную часть передаёт в API, для доставки на бастион серверы. Клиент также генерирует временный PKI сертификат и он подписывается CA в портале Tuna. C RSA ключом и сертификатом вы подключаетесь к серверу, сервер проверяет, что сертификат действителен, подписан верным CA и у пользователя на которого выписан сертификат достаточно прав на доступ с учётом ролей и политик. Бастион серверы в свою очередь тоже имеют временные сертификаты пописанные CA и при установке соединения клиент также проверяют валидность в CA но сервера, так вы уверены, что ваш сервер, это ваш сервер, а не что-то подставное. В итоге мы ничего не знаем про приватные ключи серверов и клиентов, они генерируются и хранятся локально, а значит у нас нет возможности подключиться к вашей инфраструктуре, как и злоумышленникам в случае утечек у нас, но мы выступаем 3й стороной хранителем CA, что подписывает сертификаты и аутентифицирует пользователя.

Основные принципы:

  • Мандатная (Role-Based Access Control, RBAC) модель — доступ к SSH-серверам управляется через роли и политики, а не вручную через файлы authorized_keys
  • Zero Trust — проверяет не только учетные данные пользователя, но и контекст - Кто запрашивает доступ? Какой сервер и с какой целью? Какие параметры у сессии (время, источник, политика MFA)?
  • Аутентификация без паролей (Passwordless) — вместо статических паролей, в дополнение к SSH-ключам используются PKI-сертификаты, которые автоматически истекают.
  • (скоро) Аудит и наблюдаемость — каждая SSH-сессия записывается, что позволяет просматривать действия пользователей в реальном времени.
  • (скоро) Интеграция с SSO (OAuth, OpenID, SAML, LDAP) — пользователи могут аутентифицироваться через корпоративные сервисы, такие как Google Workspace или Okta.

Как это выглядит на практике?​

main-scheme

  1. Вы запускаете tuna-bastion на своём сервере и регистрируете его в API Tuna. Генерируется пара RSA ключей, и сертификат на 30 дней, который подписывает CA выделенный на команду в API Tuna. Приватный ключ хранится локально и никуда не передаётся, API Tuna его не знает, т.е. у нас нет доступа к вашим северам.
  2. В панели управления my.tuna.am создаёте роль описывающую модель доступа и применяете к нужному пользователю.
  3. Пользователь запускает у себя команду tuna bastion login username. Генерируется пара RSA ключей, и сертификат на 12 часов, который подписывает CA выделенный на команду в API Tuna, по аналогии с сервером. Но это происходит только если у пользователя достаточно прав на подключения с таким логином.
  4. Пользователь запускает команду tuna bastion ssh username@hostname и если его сертификат валидный, сертификат сервера валидный, у пользователя достаточно прав и не наложено ограничений, то тогда сессия устанавливается.