Здравствуйте, kazkar, Вы писали:

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

K>В голову приходит два варианта решения:
K>1. Размещать на втором сервере копию оперативных данных основного сервера для филиальных пользователей. Причем организовать все так, чтобы у внешнего сервера не было прав на основной сервер (в идеале — он основной не видит), а заливку оперативных данных осуществлял бы сам основной сервер (напр. по расписанию). Но в таком случае прийдется переписывать интерфейс сайта для филиальных пользователей, и я упераюсь в свежесть получаемых ими данными.

K>2. Разрешить пользователям, зарегистрированным на внешнем сервере доступ на чтение основного сервера. Но тут сразу же возникает очень много но...

K>Мне бы хотелось на начальном этапе максимально защититься как от атак на низком уровне, так и от высокоуровневых атак. На низком уровне — не такая большая проблема, а вот с точки зрения SQL безопасности — мне не все понятно.

K>Может быть стоит все организовать совсем подругому...

K>Пожалуйста, помогите выбать правильное решение.

Попробуйте покопать в сторону транзакционной репликации: основной сервер — издатель, сайт — подписчик.