Придумать инфраструктуру для авторизации

межсетевым экраном ограничить доступ к филиалу диапазоном ip адресов ?

Извини, я не понял. Фаервол на сервере установить нельзя. Нужно что-то независимое-своё. Фильтровать подключения самому и не пускать даже к авторизации на удалённом сервере.

Есть доступ к управлению доменом, на котором крутится «удалённый сервер».

Проблема в том, что некоторые операторы узнали пароли (филиальные) от других филиалов и стали туда заходить (вводя филиальный логин+пароль и свой личный логин+пароль).

Где-то регламентировано что так делать нельзя? Если да - показательно выпорите провинившихся или выгоните нафиг, и никто больше так делать не будет. Если документов нет - напишите, ознакомьте с ним, и дальше см п.1 в случае новых нарушений.

Единственное, что мне пришло на ум, - это сделать базу данных, в которой будет прописано, какой оператор работает в каком филиале. И потом, когда оператор пытается подключиться к удалённому серверу, проверять по связке (MAC-адрес компа + логин-пароль филиала + личный логин-пароль). И, если эта связка корректна, пустить оператора к удалённому серверу. Технически сделать так: Сначала на своём сервере проверять всю эту троицу данных, а потом уже пускать юзера к удалённому серверу.

Так вы говорите что на сервере ничего менять нельзя, как вы тогда планируете сделать "если эта связка корректна, пустить оператора к удалённому серверу"?

Сперва я подумал что пользователи из одного филиала подключаются к другому филиалу.
Вроде бы проще сделать привязку пользователя к филиалу.
Какую проблему решает ввод логина и пароль от филиала, принадлежность пользователя к филиалу ?
Может проще на стороне удаленного сервера (в домене разрулить эту ситуацию) решать какой пользователь принадлежит какому филиалу ?

К большому сожалению, разрешить проблему на стороне удаленного сервера нельзя, поэтому я планирую перенаправить с помощью DNS-записей пользователей на свою прослойку, в которой решить, пускать их дальше или нет. :( То есть решить проблему привязки «оператор-филиал» своими силами.

Проблема в том, что удалённый сервер под управлением «партнёров по бизнесу» - это с точки зрения инфраструктуры закрытая тема.

Надо эту привязку «оператор-филиал» делать своими силами. Первое - наверное, проверять, числится ли мак-адрес подключающейся машины в базе, а потом уже чекать, какой оператор к какому филиалу хочется подключиться.

Вы пытаетесь решить организационную проблему техническими средствами.

Про DNS - что там с ssl, вы сможете утащить сертификаты? Что будете делать если коллега из филиала пойдет на сервер с личного ПК? (У вас же там все через интернеты работает как я понял, проблем с этим быть не должно) Как вообще будете перенаправлять на сервер? Редиректнуть не получится, адрес то вы поменяли, заведете еще домен для сервера? Как решите проблему с жестко забитым именем домена в линках на сервере? Или ваш сервер будет как прокси?

удалённый сервер под управлением «партнёров по бизнесу»

Готовы к тому что в случае факапа придут именно к вам и никто не будет слушать про какие-то там филиалы?

Рабочее место оператора - жёсткое. Он не может забирать домой компьютер. На операторских компьютерах установлен CentOS. Квалификация оператора в принципе не позволяет узнать МАК-адрес машины, подделать его. Операторы вообще не знают, что есть привязка к МАК-адресу его операторской машины.

Может тогда на этой прослойке и соотнести принадлежность оператора к филиалу, ее и проверять. Белыми и/или черными списками ip (MAC сетевухи при смене может поменяться, а вот ip врятле) адресов фильтровать принадлежность к филиалу.
Если принадлежность оператора к филиалу не совпадает то присылать уведомление и виновных наказывать административными методами если есть возможность, как предложили выше.

а нормально LDAP прикрутить там нельзя?

Возможно, какой-то прокси (nginx/httpd), которіе будут привязані к конкретной группе в LDAP?

То есть, если на филиал1 надо пойти по url, то закріть єтот URL basic auth, которая будет смотреть, есть ли пользователь в группе филиал1. Если нет - нафиг. Если есть - далее пусть вводит пароль филиала.

Придется:

1. Поднять LDAP + наконфижить группі (только для авторизации оператора к филиалу, аутентификацию оставить на существующую инфру)

2. Наконфижить проксю

АП:

• придется как-то синхронизировать пароли з базі, иначе придется третью пару кредов заводить.

Готовы к тому что в случае факапа придут именно к вам и никто не будет слушать про какие-то там филиалы?

Никакого факапа не может быть, бизнес - белый, всё по закону и с уплаченными налогами.

Возможно, какой-то прокси (nginx/httpd), которіе будут привязані к конкретной группе в LDAP?

Вот, наверное, это и нужно. С сервером у меня нет проблем.

Может тогда на этой прослойке и соотнести принадлежность оператора к филиалу, ее и проверять. Белыми и/или черными списками ip (MAC сетевухи при смене может поменяться, а вот ip врятле) адресов фильтровать принадлежность к филиалу.

Да, вот, это и имел в виду и спрашиваю, как лучше это сделать. Вот, допустим, пользователь вводит два логина и пароля, жмёт кнопку, я на другом своём сервере проверяю привязку и уже дальше - пускаю или не пускаю пользователя на удалённый сервер. Наверное, тут программист нужен, потому что я сам не сумею взять логин+пасс, а потом эти хеши отдать удаленному серверу да ещё так, чтобы он сессии выдал опять же не мне, а оператору.

Вы бы ответы разделяли. Прокомментирую только свою часть.

Никакого факапа не может быть, бизнес - белый, всё по закону и с уплаченными налогами.

В чем тогда проблема с тем что кто-то подключается под учеткой другого филиала? Если у него таким образом появляется доступ к той информации, к которой доступа быть не должно - это и есть предпосылки к факапу. Если появляются какие-то чужие полномочия - то же самое.

Ждём следующую тему «Сделать инфраструктуру для авторизации».

BTW, перехват трафика к конечному серверу как должен осуществляться? Для того, чтобы перед нужным сервером поставить прокси – нужны не совсем тривиальные телодвижения, если доступа к конечному серверу нет.

Да я ещё раз убеждаюсь в своей правоте, судя по вашим здесь ответам (всех) и что надо просто надавить на начальство, перестать заставлять выдумать дикие костыли и просто заставить этих партнёров просто тупо у себя на сервере сделать привязку «оператор-филиал» и проверять мак-адрес конкретного компа. Изначально же я предложил просто сделать VPN-сеть и вообще бы никаких проблем не было.

Вопрос вообще политический: две стороны, называющие себя партнёрами, стараются застраховаться. Одни держат сервер, другие - домен, поэтому это всё выглядит, как цирк.

Пожалуйста, только не смейтесь. Да, ребята, держащие сервер, не могут накодить логгинг так, чтобы было видно, кто под какой учёткой делает какие-то действия. Если бы это было сделано, то вопрос решён: кто совершает плохие деяния, тому по голове, а они даже это сказать не могут, хотя по мне это вообще базовая штука, тем более в системе, где идёт работа с деньгами.

Вы ещё конопля-адрес проверять начните. Подсказываю – конечный сервер не обязательно имеет возможность видеть MAC-адрес клиента.

Сама идея привязки оператора к филиалу и проверка соответствия на конечном сервере – правильная.

А то, что на сервере не могут «накодить» эту проверку – я так понимаю, не ваша проблема уже.