Небольшая предыстория
После лекции на HighLoad++ 2017. Я посмотрел этот доклад, “Как мы админа увольняли”, в записи. Докладчик сказал, что все web компании испытывает проблемы с паролями, и у меня появилась идея как это решить. Скорее всего кто-то уже сделал, но, если честно, я не знаю просто хочу описать, потом может, кто-то сделает или я как-нибудь сам сделаю. Надеюсь, если кто-то решит сделать, что-то подобное это будет opensource.
Собственно описание проблемы и способа её решения
В чём же проблема, как не странно в самих паролях, точнее с тем, чтобы недобросовестные сотрудники не увели их из компании.
Есть два варианта решения такой проблемы.
- Выкладывать все изменения на сайт лично руководителю компании.
- Что-то придумать и сделать.
В общем, действуем по второму варианту. Первый трудно затратный и подходит, если компания состоит их небольшого количества человек.
Что делать определились, теперь нужно определиться как это сделать.
Вот сразу самая простая идея, а почему не сделать proxy? Ну скорее всего супер-прокси. Схема работы в принципе проста и я её нарисовал ниже.
Рисунок 1 – общая схема работы системы
Как видно из схемы и самой идеи, главным элементом здесь будет прокси сервер.
Его задачи следующие:
- Соответственно принимать трафик, или даже стоит работать на уровне команд SSH и SFTP, для начала, и отправлять ответ от сервера клиента, специалисту.
- Аутентификация и авторизация специалиста
- Проверка легитимности команд, это можно сделать позже.
Структура самого прокси сервера будет следующей:
Рисунок 2 – Структурная схема компонента супер-прокси
Proxy – непосредственно проксирует трафик по протоколу SSH, (S)FTP, HTTP, HTTPS
CA (Control Access) – Контролирует доступ специалистов к ресурсам клиента.
SAP (Sever Admin Panel) – Непосредственно сервер с которым связывается администратор, через панель управления.
Core – Непосредственно ядро системе занимается менеджментом запросов между модулями и управлением моделями.
Я считаю, что на которое доступа стоит отдельно остановиться, т. к. из-за этого всё и затевалось.
Все пользователи входят в групповые политики, групповые политики определяют правила доступа к серверам клиента, а также правила, которым подчиняются администраторы системы. Групповые политики обладают иерархической структурой, каждый верхний уровень имеет свои и те же полномочия, что и нижней уровень. Из изначально существует политика ‘.’, в неё входят все разрешение для всего и в неё может входит один пользователь главный администратор. Затем существует две группы для политик, администраторы системы и проекты.
Сводная таблица — администраторы и их права
| Название роли | Права на доступ | |
|---|---|---|
| Администратор групповой политики | Редактирование пользователей в групповой политике | |
| Администратор групповых политик | Создание групповой политики | Создание удаление и редактирование пользователей в групповой политике |
| Администратор управления пользователями | Удаление пользователя из групповой политики | Создание удаление и редактирование пользователей |
| Администратор резервного копирования | Чтение информации о пользователях и администраторах | Чтение записей групповых политик |
| Главный администратор | Всё что и остальные, а также редактирование и удаление групповых политик | Принудительное изменение паролей на серверах клиента |
Сами же групповые политики содержит запись о сервере к какому эта политика применяется.
А пользователи имеют следующие правила, которые прописываются для каждого пользователя или группе отдельно, по сути, это булевы значения, которые определяет имеет ли объект доступ по HTTP/HTTPS к панели управления ресурсом (админке), доступ по SFTP/FTP, SSH.
Теперь осталось пара слов о панели управления и клиенте.
Панель управления или всё понятно, но нужно ещё раз написать, что бы было точно понятно.
Панель управления. Непосредственно нужна для управления групповыми политиками и в целом сервером, супер-прокси. Распространяется как отдельное приложение или web сервис.
Соответственно имеют доступ к панели управления администраторы.
Клиент прост с виду, сложен внутри.
Клиенту же необходимо приложение, в случае HTTP(S), чисто теоретически этим приложением может выступать браузер, непосредственно настроенный работать через прокси сервер, а нашему прокси серверу придётся вклиниваться в трафик. А вообще скорее, всего, необходимо будет разработать отдельное приложение, которое будет работать по SSH, (S)FTP, HTTP(S), с серверами клиента, через наш супер-прокси сервер, или даже будет проще, реально будет устанавливать и общаться с серверами клиента сам супер-прокси сервер, а в самом клиенте, установленном на ЭВМ у специалистов весь процесс будет просто эмулироваться.
Рассмотрим на примере HTTP(S).
- Клиент отправляет на прокси сервер запрос на связь с клиентом.
- Супер-прокси сервер разрешает это или нет, если разрешает, то сам супер-прокси сервер поднимает соединение и авторизуется в панели управления.
- Супер-прокси сервер получает непосредственно главную страницу панели администратора.
- Супер-прокси сервер передает эту страницу клиенту, подменяя адрес ресурса клиента, специальным маркером.
- Специалист переходит по ссылкам или заполняет поля в браузере и отправляет форму. Данные уходят на супер-прокси сервер.
- Супер-прокси сервер заменяет маркеры обратно на адрес ресурса клиента и соответственно отправляет непосредственно на сам ресурс клиента.
С работой по SSH можно передавать чисто текст. А непосредственно от супер-прокси сервера к ресурсу клиента поднимается нормальное SSH соединение.
Вот примерно как-то так. Жду вашей обратной связи в комментариях, и ссылок на репозитории, если кто-то решит сделать такую систему.
Автор: Aliksei
