ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Проброс SSL-аутентификации на backend



Тоже вариант, но на мой взгляд все же проще заставить всех (и своих и чужих) работать через фронтенд, в чем я, собственно, уже убедил коллег. Этот способ как минимум не требует дополнительных компонент, таких как OpenVPN с его серверной и клиентской частью и к тому же более прост и очевиден. Согласовать изменение архитектуры будет позатратнее, чем организовать принудиловку через фронтенд в рабочем порядке, придется коллегам смириться с дополнительной задержкой при тестировании новых билдов в угоду безопасности.
Спасибо всем за помощь!
P.S.: посмотрел я F5, в даташите не нашел описания такой фишки, только загадочное "advanced client auth."

7 сентября 2009 г. 10:39 пользователь Pavel Labushev <p.labushev@xxxxxxxxx> написал:
Бондарец Иван пишет:
> Тут не в технике проблема. Проблема в людях.
> Пример: разработчики (некий аутсорс) выпустили новый релиз
> веб-приложения, передали нашим тестировщикам. Тестировщики быстренько
> согласовали с админами тест-бекенда, залили апдейт, погоняли тесты,
> потом уже спокойненько согласовали план работ на внедрение в бой и в
> течение какого-то времени все это безобразие внедряется в бой, с
> балансировщиками, фронтендами, файерволами, айпиэсами  и т.п.
> Так вот, если мы внедрим аутентификацию на фронтенде и жестко всех
> заставим работать через него, то в цепочку согласований-настроек войдет
> еще одно подразделение, чего хотелось бы избежать.

Ваша задача решаема на более низких уровнях. Например, с помощью OpenVPN
и редиректа портов.

1. Клиент устанавливает OpenVPN-туннель с фронтендом. Аутентификация -
SSL/TLS, двухсторонняя, на базе уже имеющихся HTTPS-сертификатов. Можно
выбрать шифр NULL, чтобы не шифровать трафик дважды.
2. Клиент прописывает маршруты до внешних IP-адресов фронтенда через
VPN-гейт.
3. Фронтенд по признаку адреса источника перенаправляет HTTPS-трафик
клиента на адрес и порт бэкенда.
4. Бэкенд и клиент связываются по HTTPS напрямую. Задача решена.

Телодвижения по п.1 и 2 легко автоматизируются. С позиции ИБ риски
практически те же: в OpenVPN на pre-auth стадиях работает тот же код из
OpenSSL, что и в nginx с апачем, без привилегий root. Решение не
универсальное, но для "своих" вполне сгодится.




 




Copyright © Lexa Software, 1996-2009.