Здравствуйте.
Столкнулся со следующей задачей:
Есть MS SQL Server 2000 EE, на котором лежит несколько корпоративных баз (~ 40 GB) + внутрекорпоративный сайт, представляющий содержимое БД для сотрудников.
Также есть кодированный внешний сайт (рассчитанный на сотрудников филиалов), он выбирает информацию из того же сервера.
Необходимо построить еще один сервер, на котором будет работать корпоративный сайт + старый сайт для филиалов.
Проблема: Если открыть второй сервер для всеобщего обозрения, то существует опасность атак основного корпоративного сервера, либо утечка информации. Поэтому необходимо построить такую архитектуру, чтобы внешние пользователи получали именно ту информацию с основного сервера, которую мы разрешаем получать. Обратная связь не нужна.
В голову приходит два варианта решения:
1. Размещать на втором сервере копию оперативных данных основного сервера для филиальных пользователей. Причем организовать все так, чтобы у внешнего сервера не было прав на основной сервер (в идеале — он основной не видит), а заливку оперативных данных осуществлял бы сам основной сервер (напр. по расписанию). Но в таком случае прийдется переписывать интерфейс сайта для филиальных пользователей, и я упераюсь в свежесть получаемых ими данными.
2. Разрешить пользователям, зарегистрированным на внешнем сервере доступ на чтение основного сервера. Но тут сразу же возникает очень много но...
Мне бы хотелось на начальном этапе максимально защититься как от атак на низком уровне, так и от высокоуровневых атак. На низком уровне — не такая большая проблема, а вот с точки зрения SQL безопасности — мне не все понятно.
Может быть стоит все организовать совсем подругому...
Пожалуйста, помогите выбать правильное решение.
Здравствуйте, kazkar, Вы писали:
K>Проблема: Если открыть второй сервер для всеобщего обозрения, то существует опасность атак основного корпоративного сервера, либо утечка информации. Поэтому необходимо построить такую архитектуру, чтобы внешние пользователи получали именно ту информацию с основного сервера, которую мы разрешаем получать. Обратная связь не нужна.
K>В голову приходит два варианта решения:
K>1. Размещать на втором сервере копию оперативных данных основного сервера для филиальных пользователей. Причем организовать все так, чтобы у внешнего сервера не было прав на основной сервер (в идеале — он основной не видит), а заливку оперативных данных осуществлял бы сам основной сервер (напр. по расписанию). Но в таком случае прийдется переписывать интерфейс сайта для филиальных пользователей, и я упераюсь в свежесть получаемых ими данными.
K>2. Разрешить пользователям, зарегистрированным на внешнем сервере доступ на чтение основного сервера. Но тут сразу же возникает очень много но...
K>Мне бы хотелось на начальном этапе максимально защититься как от атак на низком уровне, так и от высокоуровневых атак. На низком уровне — не такая большая проблема, а вот с точки зрения SQL безопасности — мне не все понятно.
K>Может быть стоит все организовать совсем подругому...
K>Пожалуйста, помогите выбать правильное решение.
Попробуйте покопать в сторону транзакционной репликации: основной сервер — издатель, сайт — подписчик.
