Мой вопрос был "бамп или просто неинспектим?"

Не, у меня все проще.
TLS терминируется на gateway (или вообще на прокси перед ним, с mod_security и прочими радостями).
На основе его содержимого уже gateway определяет необходимые права/разрешения, формирует правильные токены и отдает клиентам обратно.
Когда те приходят с токенами опять на шлюз - по токенам все проверяется и формируются внутренние вызовы (в защищенном контуре, без допзащиты).

Для отдельных специфик (типа платежи с мобильного) вообще поднимается свой транспорт поверх TLS (так как андроид весь дырявый но там можно с этим бороться, а эппл дырявый и не дает бороться)

Пароли и прочее хэшируем на клиенте (и потом еще раз при хранении в БД)
Секреты типа карточных данных - шифруем на клиенте и еще раз в БД

Я бы и внутренний трафик шифровал, но клиенты не хотят, слишком накладно (

Это можно делать пока у вас есть возможность сделать защищённый контур.

Интереснее становится когда ваше железо ставится на чужую площадку, а в модели угроз есть техперсонал этой площадки и физический доступ к железу.

Ну, для этого нужны одноразовые пароли на доступ к сертификатам TLS (при этом даже доступ к железу ничего не дает) или вообще хитрые схемы криптографии типа тех, что нужны для сертификации на мобильные платежи....

Т.е. я такое умею делать, но заказчикам обычно не надо. У нас у клиентов обычно PCI DSS совместимые датацентры, что упрощает жизнь.

А что даст шифрование внутри контура?

В смысле какие риски снимает. У товарища @pragus  я понял в чём штука.

При его рисках действительно имеет смысл ставить что-то вроде митм. Вроде бы. Но да, согласен с тем, что можно что-то получше придумать.

резко снизит возможности злоумышленника при физическом доступе

Защита от своего сисадмина.

от своего сисадмина никак нельзя защититься) Только позлить его

Чужого же: свое оборудование в чужом дц.

Как пример, ggc(google global cache), который гугл рассылает isp для установки.

Сначала вы попросите своего сисадмина поднять всю эту радость, а потом начнёте от него этой же радостью защищаться? :) ну такое :)

Можно, можно. Сложно, но реально.

Угу. Но при правильных процессах он все равно не имеет доступа к важному (например СУБД).
Основная проблема - как сертификаты скрыть.

Ну он же сам ставить настраивать это будет, как уже писали выше. Тут только двоемыслие )

Не, просто правильные процессы.
Стандартаная виртуальная машина (список пакетов и прочее фиксировано, проверено СБшником, размножается из образа).
Софтинка, которая отслеживает изменение всех существенных настроек (и вход по руту) и жалуется в СБ.
Схема шамира (или одноразовые пароли) на расшифровку пароля от ключницы с сертификатом (сам сертификат генерится СБ)
В БД все данные шифруются или используются одноразовые пользователи, credentials которых передаются через TLS зашифрованный как выше написано.
И все )

Там есть тонкости в организации перезапуска системы в отсутствии СБ, но они тоже решаются...
Но сложно в поддержке, конечно, так что по хорошему используется только для хранения карточных данных (да и то не всегда).