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

Бондарец Иван bondarets at gmail.com
Mon Sep 7 11:13:00 MSD 2009


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

7 сентября 2009 г. 10:39 пользователь Pavel Labushev
<p.labushev at gmail.com>написал:

> Бондарец Иван пишет:
> > Тут не в технике проблема. Проблема в людях.
> > Пример: разработчики (некий аутсорс) выпустили новый релиз
> > веб-приложения, передали нашим тестировщикам. Тестировщики быстренько
> > согласовали с админами тест-бекенда, залили апдейт, погоняли тесты,
> > потом уже спокойненько согласовали план работ на внедрение в бой и в
> > течение какого-то времени все это безобразие внедряется в бой, с
> > балансировщиками, фронтендами, файерволами, айпиэсами  и т.п.
> > Так вот, если мы внедрим аутентификацию на фронтенде и жестко всех
> > заставим работать через него, то в цепочку согласований-настроек войдет
> > еще одно подразделение, чего хотелось бы избежать.
>
> Ваша задача решаема на более низких уровнях. Например, с помощью OpenVPN
> и редиректа портов.
>
> 1. Клиент устанавливает OpenVPN-туннель с фронтендом. Аутентификация -
> SSL/TLS, двухсторонняя, на базе уже имеющихся HTTPS-сертификатов. Можно
> выбрать шифр NULL, чтобы не шифровать трафик дважды.
> 2. Клиент прописывает маршруты до внешних IP-адресов фронтенда через
> VPN-гейт.
> 3. Фронтенд по признаку адреса источника перенаправляет HTTPS-трафик
> клиента на адрес и порт бэкенда.
> 4. Бэкенд и клиент связываются по HTTPS напрямую. Задача решена.
>
> Телодвижения по п.1 и 2 легко автоматизируются. С позиции ИБ риски
> практически те же: в OpenVPN на pre-auth стадиях работает тот же код из
> OpenSSL, что и в nginx с апачем, без привилегий root. Решение не
> универсальное, но для "своих" вполне сгодится.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20090907/d979c113/attachment.html>


More information about the nginx-ru mailing list