Как стать автором
Обновить

Идея, как можно предоставлять сотрудникам временный доступ к ресурсам клиента, не светя лишний раз пароли

Разработка веб-сайтов *Сетевые технологии *
Из песочницы

Небольшая предыстория


После лекции на HighLoad++ 2017. Я посмотрел этот доклад, “Как мы админа увольняли”, в записи. Докладчик сказал, что все web компании испытывает проблемы с паролями, и у меня появилась идея как это решить. Скорее всего кто-то уже сделал, но, если честно, я не знаю просто хочу описать, потом может, кто-то сделает или я как-нибудь сам сделаю. Надеюсь, если кто-то решит сделать, что-то подобное это будет opensource.

Собственно описание проблемы и способа её решения


В чём же проблема, как не странно в самих паролях, точнее с тем, чтобы недобросовестные сотрудники не увели их из компании.

Есть два варианта решения такой проблемы.

  1. Выкладывать все изменения на сайт лично руководителю компании.
  2. Что-то придумать и сделать.

В общем, действуем по второму варианту. Первый трудно затратный и подходит, если компания состоит их небольшого количества человек.

Что делать определились, теперь нужно определиться как это сделать.

Вот сразу самая простая идея, а почему не сделать 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).

  1. Клиент отправляет на прокси сервер запрос на связь с клиентом.
  2. Супер-прокси сервер разрешает это или нет, если разрешает, то сам супер-прокси сервер поднимает соединение и авторизуется в панели управления.
  3. Супер-прокси сервер получает непосредственно главную страницу панели администратора.
  4. Супер-прокси сервер передает эту страницу клиенту, подменяя адрес ресурса клиента, специальным маркером.
  5. Специалист переходит по ссылкам или заполняет поля в браузере и отправляет форму. Данные уходят на супер-прокси сервер.
  6. Супер-прокси сервер заменяет маркеры обратно на адрес ресурса клиента и соответственно отправляет непосредственно на сам ресурс клиента.

С работой по SSH можно передавать чисто текст. А непосредственно от супер-прокси сервера к ресурсу клиента поднимается нормальное SSH соединение.

Вот примерно как-то так. Жду вашей обратной связи в комментариях, и ссылок на репозитории, если кто-то решит сделать такую систему.
Теги:
Хабы:
Всего голосов 14: ↑11 и ↓3 +8
Просмотры 4.1K
Комментарии 10
Комментарии Комментарии 10