Comments 19
ну вы изобрели очередной велосипед, чем славен Яндекс. Дальше нормальная СБ вас попросит расширить на бастионе поддержку протоколов с ssh до rdp/vnc, включить запись экранов, сделать модерируемую сессию админов с красной кнопкой у ИБ "отключить его нафиг", прикрутить к сессии DLP... И все это перерастет наконец-то в нормальный PAM (Privileged Access Management) коих на рынке - десятки.
Как-то вы намешали, кажется.
Претензия к сервису бастион? К сервису TACACS? Откуда RDP/VNC в устройствах без UI?
Модерируемая сессия с красной кнопкой уже есть.
коих на рынке - десятки.
И это почти принципиальная позиция Яндекса - не использовать рыночные решения, поскольку у нас есть ресурсы для того, чтобы не зависеть от вендора там, где это возможно. И как показали два последние года, не самое плохое решение.
Ну и важная ремарка - вся статья о сетевом оборудовании, где нет возможности поставить и настроить ничего за пределами интерфейса и синтаксиса, предоставляемого вендора.
Кстати, линуксы тоже умеют аутентифицироваться по такаксу. Если все хосты за бастионом используют такакс, система как-будто будет попроще
Почему пароли? Почему TACACS а не RADIUS/DIAMETER? RADIUS гораздо более поддерживаемый протокол, DIAMETER (RADIUS поверх TLS/DTLS) - гораздо более безопасный и умеет и UDP и TCP. И проблем с EAP них обычно не возникает (в TACACS+ нет стандартной поддержки EAP), можно авторизоваться не только паролями.
DIAMETER не поддерживается практически никаких сетевым оборудованием. Голый RADIUS не только не даёт преимуществ перед TACACS, так к тому же и плейн-текстом передаёт пароли?
К тому же в TACACS поддерживает не только парольную аутентификацию - просто для нас это наиболее простой и в то же время подходящий способ.
Плейн-текстом пароли не передает, но шифрование еще хуже чем в TACACS. Я имею ввиду, что упирать именно на TACACS не стоит, потому что все зависит от используемого зоопарка - если поддерживается DIAMETER лучше использовать его, если у вас все на Cisco - то будет TACACS, но как правило есть еще и что-то, что поддерживает только RADIUS.
У схемы с TOTP есть моменты, которые делает ее хуже варианта с одноразовым OTP привязанным к конечному устройству, по крайней мере если они изначально не предусмотрены:
TOTP на самом деле не одноразовый
Если используется общий ключ, а не генерируется отдельный ключ на каждый девайс, то пароль можно переиспользовать, т.е. если потроянлено одно конечное устройство - на нем можно получить TOTP в момент входа и через него доступ к другому девайсу
Если генерируется ключ на каждый девайс - то они все равно где-то хранятся между бастионом и tacacs и это делает схему хуже, чем хранение одноразовых кодов привязанных к устройcтву
Да, про пароль я не прав. Имел в виду сообщение.
все зависит от используемого зоопарка - если поддерживается DIAMETER лучше использовать его, если у вас все на Cisco - то будет TACACS, но как правило есть еще и что-то, что поддерживает только RADIUS
И да, и нет. Если ты выбираешь отдельный механизм под условно каждого вендора (пусть и из соображений абстрактной безопасности), ты должен поддерживать их все. И ломаться они будут не одновременно и непредсказуемо.
Почему "абстрактной безопасности" - потому что реализации TACACS с этой точки зрения нам более чем достаточно - TOTP, ротация секретов, разные секреты для разных окружений, основная аутентификация на бастионе по сертификатам - позволяют снять или сильно снизить все риски.
TOTP на самом деле не одноразовый
Технически, ничто не мешает сделать его одноразовым. Например, после использования пароля менять соль. Но это в некотором смысле дуть на воду, учитывая короткий срок жизни пароля.
Если используется общий ключ, а не генерируется отдельный ключ на каждый девайс, то пароль можно переиспользовать, т.е. если потроянлено одно конечное устройство - на нем можно получить TOTP в момент входа и через него доступ к другому девайсу
Сделать это через Bastion - практически невозможно. Нужно ломать систему в нескольких местах.
Чтобы сделать это в обход бастиона, нужно завладеть актуальным секретом TACACS, знать механизм генерации TOTP, знать соль и попасть в нужный момент времени.
При этом, мы этот факт заметим, потому что мониторим логи подключения и поднимаем аварии, когда оно произошло в обход бастиона. Плюс мы мониторим дрейф конфигурации сети и снуляем его автоматически, если изменения безопасны (ААА - безопасны).
Имел в виду сообщение
Ну в радиусе ничего кроме пароля, конечно, не шифруется вообще никак, но там уже ничего прям секретного-тайного нет. А подменить содержимое на лету просто так не выйдет т.к. в радиусе предусмотрена контрольная сумма пейлоада, которая считается с учетом значения PSK (короче говоря, простейшая, но подпись).
Ну и радиус, навскидку, при желании прикрутить не так сложно должно быть. По-сути можно взять прямо ванильный freeradius и к нему дописать только TOTP модуль (ну, возможно, ещё модуль для IAM если у вас сейчас TACACS сначала проверяет есть ли у данного юзернейма вообще права на железку ходить)
Сложно спорить) Всё в целом так. Но всё ещё никакого весомого аргумента в пользу RADIUS нет (кроме того, что микротики не поддерживают TACACS)).
А если историю брать не с самого начала, а с момента, когда мы в Облаке решили делать централизованную авторизацию, что такакс уже был, а радиус - нет. Выбор очевиден)
Отличная статья, Марат!
Все по полочкам,
все очень логично, когда сценарий линеен, шаги вправо-влево - отстреливаем.
Теперь переходим к самому интересному,
q1: Есть докер\vm со всем настроенным барахлом пощупать по-быстрому?
q2 больной: а что делать с 300-400 Mikrotik, дай хоть направление?
q3: когда анонс мск линкмиапа?
Схема интересная, но как будто бы сущность, вынесенная в название - TACACS - выглядит здесь самой лишней. Можно к бастиону подключаться личной учеткой, а сам бастион будет подключаться к сетевым коробкам одной общей учеткой. Задача ротации пароля этой учетки равна задаче ротации секрета tacacs. Логи команд пишет бастион, поэтому он знает из-под какой реальной учетки какая команда введена.
Это осознанное решение - нам важно, чтобы на конечном хосте - неважно сетевом или серверном операции были персонифицированными, чтобы в аудит-логах видеть конкретного пользователя. Иначе корреляция между событиями на бастионе и на конечном хосте неявная - нет чёткого критерия для сопоставления - и это точно полуручная работа.
И даже глазами зайти посмотреть на свитч, посмотреть, кто коммиты делал последние :)
При этом он принципиально не усложняет схему, поскольку аутентификацию всё равно нужно делать, управлять ротациями паролей/секретов.
Меня смутило вот что.
мониторинг работоспособности пользователя breakglass
Ведь это пользователь с самыми высокими привилегиями? Получается, что он его пароль лежит не только в секретном бумажном конверте, но и где-то в системе мониторинга? Можно поподробнее, как он защищен?
Получается, что он его пароль лежит не только в секретном бумажном конверте, но и где-то в системе мониторинга?
Пароль лежит в секретнице (типа vault) - и при каждом запуске крона забирает его оттуда без локального хранения. Это, соответственно, позволяет нам не думать о его смене при ротации пароля - крон просто работает.
Секретница - manged сервис с контролем доступа. А так - да, пароль breakglass ещё записан на бумажке и лежит в "сейфе" (в Новосибисрке).
Хммм...
А у вас для всех пользователей и железок один и тот же TOTP seed используется? Он просто где-то, условно говоря, в конфиге всех инстансов Бастиона и всех инстансов TACACS раскатан? Или каждый Бастион пользуется своим личным TOTP seed (одним для всех пользователей и железок, тут я городить разные смысла не вижу), а каждый TACACS знает все seed от всех существующих бастионов и просто проверяют чтобы пришедший в запросе аутентификации OTP пароль совпал хотя бы с одним из них?
TACACS in da Сloud