Я бы не рекомендовал использовать любую форму открытого ключа для связи с вашего веб-сервера на сервер приложений. Если вы контролируете обе системы, просто обычная секретная система шифрования. Вы знаете личность своего сервера приложений, поэтому сохранение ключа в безопасности не является проблемой. Если вам когда-либо понадобится изменить или обновить секретный ключ, просто сделайте это вручную, чтобы предотвратить утечку через соединение.
Что бы я был наиболее осторожен, так это направление передачи данных с вашего сервера в вашей DMZ, которая должна быть только вашим веб-сервером, в те блоки, которые находятся внутри вашей сети. Все более распространенными являются случаи, когда законные домены подвергаются риску для распространения вредоносного ПО среди посещающих пользователей. Это плохо, но если бы вредоносная программа обратилась в вашу сеть, а не только наружу для ваших пользователей, тогда ваш бизнес был бы полностью скрыт.
Я также не видел ничего о предотвращении внедрения SQL-кода или усиления / исправления системы для предотвращения распространения вредоносных программ. Это должно быть вашим первым и самым важным соображением. Если бы безопасность была важна для вас, ваша архитектура была бы гибкой для незначительных настроек межсерверного взаимодействия и частых исправлений. Большинство веб-сайтов, даже крупные законные компании, никогда не исправляют свои дыры в безопасности, даже если они скомпрометированы. Вы должны постоянно исправлять дыры в безопасности и менять вещи, чтобы предотвратить возникновение дыр, если вы хотите избежать компрометации.
Чтобы не стать распространителем вредоносного ПО, я бы предложил установить жесткие и быстрые правила, касающиеся обслуживания мультимедиа, содержащего любые виды сценариев на стороне клиента. Сценарии на стороне клиента можно найти в JavaScript, ActiveX, Flash, Acrobat, Silverlight и других кодах или плагинах, которые выполняются в клиентской системе. Должны существовать политики для обслуживания этого контента, чтобы можно было сразу идентифицировать аномальные фрагменты кода. Я рекомендую НИКОГДА не вставлять код на стороне клиента непосредственно в браузер, но всегда ссылаться на какой-нибудь внешний файл. Я бы также предложил использовать единомышленники для лучшего управления активами и экономии трафика, например, обслуживать один большой файл JavaScript вместо 8 маленьких. Я бы также порекомендовал форсировать все такие носители во внешней системе распространения контента, которая ссылается на ваш домен в своей структуре каталогов. Таким образом, мультимедиа не доставляется напрямую с ваших серверов, и если оно доставляется напрямую от вас, вы можете быстро идентифицировать его как потенциально вредоносное и требующее проверки безопасности.