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

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

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

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