Тоже вариант, но на мой взгляд все же проще заставить всех (и своих и чужих) работать через фронтенд, в чем я, собственно, уже убедил коллег. Этот способ как минимум не требует дополнительных компонент, таких как OpenVPN с его серверной и клиентской частью и к тому же более прост и очевиден. Согласовать изменение архитектуры будет позатратнее, чем организовать принудиловку через фронтенд в рабочем порядке, придется коллегам смириться с дополнительной задержкой при тестировании новых билдов в угоду безопасности.<br>
Спасибо всем за помощь!<br>P.S.: посмотрел я F5, в даташите не нашел описания такой фишки, только загадочное "advanced client auth."<br><br><div class="gmail_quote">7 сентября 2009 г. 10:39 пользователь Pavel Labushev <span dir="ltr"><<a href="mailto:p.labushev@gmail.com">p.labushev@gmail.com</a>></span> написал:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Бондарец Иван пишет:<br>
<div class="im">> Тут не в технике проблема. Проблема в людях.<br>
> Пример: разработчики (некий аутсорс) выпустили новый релиз<br>
> веб-приложения, передали нашим тестировщикам. Тестировщики быстренько<br>
> согласовали с админами тест-бекенда, залили апдейт, погоняли тесты,<br>
> потом уже спокойненько согласовали план работ на внедрение в бой и в<br>
> течение какого-то времени все это безобразие внедряется в бой, с<br>
> балансировщиками, фронтендами, файерволами, айпиэсами и т.п.<br>
> Так вот, если мы внедрим аутентификацию на фронтенде и жестко всех<br>
> заставим работать через него, то в цепочку согласований-настроек войдет<br>
> еще одно подразделение, чего хотелось бы избежать.<br>
<br>
</div>Ваша задача решаема на более низких уровнях. Например, с помощью OpenVPN<br>
и редиректа портов.<br>
<br>
1. Клиент устанавливает OpenVPN-туннель с фронтендом. Аутентификация -<br>
SSL/TLS, двухсторонняя, на базе уже имеющихся HTTPS-сертификатов. Можно<br>
выбрать шифр NULL, чтобы не шифровать трафик дважды.<br>
2. Клиент прописывает маршруты до внешних IP-адресов фронтенда через<br>
VPN-гейт.<br>
3. Фронтенд по признаку адреса источника перенаправляет HTTPS-трафик<br>
клиента на адрес и порт бэкенда.<br>
4. Бэкенд и клиент связываются по HTTPS напрямую. Задача решена.<br>
<br>
Телодвижения по п.1 и 2 легко автоматизируются. С позиции ИБ риски<br>
практически те же: в OpenVPN на pre-auth стадиях работает тот же код из<br>
OpenSSL, что и в nginx с апачем, без привилегий root. Решение не<br>
универсальное, но для "своих" вполне сгодится.<br>
<br>
</blockquote></div><br>