Насколько безопасна эта архитектура?

Я не думаю, что смогу дать правильный ответ, потому что не уверен, что цель вашей системы ясна. Хотя я ценю, что вы получаете отзывы о дизайне, это немного сложно без цели.

Я бы посоветовал вам вот что:

Сначала тщательно задокументируйте и проанализируйте свою модель угроз

Вам необходимо составить фиксированный и четко сформулированный список всех возможных сценариев атаки. Местные злоумышленники и т. Д., От кого вы пытаетесь защититься? Вы также говорите такие вещи, как «с правильным управлением ключами»; тем не менее, это одна из самых сложных задач. Так что не просто предполагайте, что вы все поняли правильно; полностью спланируйте, как вы это сделаете, с конкретной ссылкой на то, кто будет предотвращать атаки.

Причина, по которой вам нужно создать модель угроз, заключается в том, что вам нужно будет определить, под какими углами вы будете уязвимы; потому что так и будет.

Я также предполагаю, что пока теория хороша; в криптографии реализация тоже очень важна. Не просто предполагайте, что вы будете все делать правильно, вам действительно нужно позаботиться о том, откуда берутся случайные числа и о других подобных вещах.

Я знаю, что это немного расплывчато, но я действительно думаю, что, по крайней мере, создание формальной и сильной модели угроз будет для вас очень полезным.

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

Я бы не рекомендовал использовать какие-либо формы открытого ключа для связи с вашего веб-сервера на сервер приложений. Если вы контролируете обе системы, просто обычная секретная система шифрования. Вы знаете идентификатор своего сервера приложений, поэтому обеспечение безопасности ключа не является проблемой. Если вам когда-либо понадобится изменить или обновить секретный ключ, просто сделайте это вручную, чтобы предотвратить его утечку через соединение.

В чем я бы был наиболее осторожен, так это в направлении передачи данных с вашего сервера в DMZ, который должен быть только вашим веб-сервером, к тем ящикам, которые находятся внутри вашей сети. Все чаще взламываются легитимные домены для распространения вредоносных программ среди посещающих пользователей. Это плохо, но если бы вредоносная программа обратилась к вашей сети, а не только к вашим пользователям, то ваш бизнес был бы полностью закрыт.

Я также ничего не видел о предотвращении внедрения sql или упрочнения / исправления системы для предотвращения распространения вредоносных программ. Это должно быть вашим первым и самым важным соображением. Если бы безопасность была важна для вас, ваша архитектура была бы гибкой для незначительных настроек межсерверной связи и частой установки исправлений. Большинство веб-сайтов, даже крупные легальные предприятия, никогда не исправляют свои дыры в безопасности, даже если они скомпрометированы. Вы должны постоянно исправлять дыры в безопасности и что-то менять, чтобы предотвратить возникновение дыр, если вы вообще хотите избежать компрометации.

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