Есть БД (MS SQL Server 2000), а также Windows-клиент (C# 2.0) в Internet и Web-приложение(ASP.NET), которые работают с этой БД. Необходимо достаточно хорошо защитить эту БД. Какие наиболее распространенный подходы для решения задач подобного рода существуют?

Я вижу следующую возможность:
1) – Для функционирования Windows-клиента: Реализация на стороне БД (на той же машине или на другой, но находящейся в той же локальной сети) шлюза, который одновременно выполняет функции и клиента и сервера: получает запросы от клиента (которые м/б зашифрованы) и транслирует их в запросы по БД(SQL, хранимые процедуры и т.д.) – получает ответы – шифрует все это дело и отправляет обратно клиенту.
2) – Для функционирования Web-приложения: Ставим отдельный сервер с IIS. Тут вроде все ясно.

Насколько предложенная схема оптимальна?
Что еще может усилить безопасность БД?
Особо интересует информация по Windows-клиенту – насколько идея шлюза целесообразна и полезна?

Заранее спасибо!

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

W>Есть БД (MS SQL Server 2000), а также Windows-клиент (C# 2.0) в Internet и Web-приложение(ASP.NET), которые работают с этой БД. Необходимо достаточно хорошо защитить эту БД. Какие наиболее распространенный подходы для решения задач подобного рода существуют?

W>Я вижу следующую возможность:
W>1) – Для функционирования Windows-клиента: Реализация на стороне БД (на той же машине или на другой, но находящейся в той же локальной сети) шлюза, который одновременно выполняет функции и клиента и сервера: получает запросы от клиента (которые м/б зашифрованы) и транслирует их в запросы по БД(SQL, хранимые процедуры и т.д.) – получает ответы – шифрует все это дело и отправляет обратно клиенту.
W>2) – Для функционирования Web-приложения: Ставим отдельный сервер с IIS. Тут вроде все ясно.

W>Насколько предложенная схема оптимальна?
W>Что еще может усилить безопасность БД?
W>Особо интересует информация по Windows-клиенту – насколько идея шлюза целесообразна и полезна?

W>Заранее спасибо!

Создание отдельного слоя логики приложения в виде web-сервиса, или пула com+ applications — тогда клиент вообще не будет иметь представления о базе данных, работая только с отдельным звеном бизнес-логики приложения, дополнительно windows based authentication//

По доставке данных с Windows-клиента в БД: необходимо реализация расширяемой структуры, то есть конечный пользователь сам вправе выбирать как ему общаться с БД: .Web-сервис, наш электронный документооборот, .NET Remoting, CORBA (каждый из способа должен поддерживаться шлюзом)

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

W>По доставке данных с Windows-клиента в БД: необходимо реализация расширяемой структуры, то есть "конечный пользователь сам вправе выбирать как ему общаться с БД: .Web-сервис, наш электронный документооборот, .NET Remoting, CORBA" (каждый из способа должен поддерживаться шлюзом)

..простите, как Вы сказали?
У вас пользователь знает разницу между CORBA и .NET Remoting?
Тогда все проще — клиент им не нужен. Нужен command-line тул для исполнения прямых SQL-запросов.

А если по сути — нет смысла из клиента обращаться напрямую в базу. Обычно, рано или поздно клиенты хотят "ходить в базу, работая из дому через диалуп". То есть, желателен инзачально какой-либо промежуточный уровень, доступ к которому будет производится по уже готовому протоколу. Например — web-services + HTTPS. Здесь важно не на выборе между корбой и .нет для юзера стопориться, а существующие подходы посмотреть да грамотный server-side API продумать, чтоб потом, реализовав его кучей способов (см.выше ), не кусать локти из-за его неоптимальности.

IMHO.

А>Здравствуйте, welaribo, Вы писали:
...

Еще вопрос — если изначально предполагается веб-приложение, то зачем еще и windows-клиент? с клиентами же всегда морока — апдейтить их нужно как-то централизованноe у всех юзеров, тестить на куче различных конфигураций (ОС, фреймворк, возможно офис, и д.т.).

ika>Еще вопрос — если изначально предполагается веб-приложение, то зачем еще и windows-клиент? с клиентами же всегда морока — апдейтить их нужно как-то централизованноe у всех юзеров, тестить на куче различных конфигураций (ОС, фреймворк, возможно офис, и д.т.).

Я бы скорее задал вопрос наоборот — если есть windows-клиент, зачеме еще и геморроиться с веб-приложением?
Но все-таки я не буду задавать аткой вопрос, потому что понимаю, что причины могут быть.

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

J>Я бы скорее задал вопрос наоборот — если есть windows-клиент, зачеме еще и геморроиться с веб-приложением?
J>Но все-таки я не буду задавать аткой вопрос, потому что понимаю, что причины могут быть.

А могут и не быть. Иногда некоторые вещи хотят просто для галочки. От кастомера зависит. Но с одним сервер-сайд приложением, что ни говори, будет проще, чем с тучей клиентов.

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

W>Есть БД (MS SQL Server 2000), а также Windows-клиент (C# 2.0) в Internet и Web-приложение(ASP.NET), которые работают с этой БД. Необходимо достаточно хорошо защитить эту БД. Какие наиболее распространенный подходы для решения задач подобного рода существуют?

1. я бы заюзал какой-нибудь ORMapper. Создал бы ограничение какие классы какую строку подключения должны юзать.

2. использование ORMapping'a дало бы мне возможность реализовать security для классов на основе Aspect Oriented Programming (копай в сторону AOP.NET). Это целесообразно, если у тебя существует механизм ролей в приложении.

3. Модель домена (domain model, см. Фаулер) помогла бы тебе стереть разницу между web и winforms

Ну и несколько слов. Защита БД осуществляется несколькими способами. Но для начала нужно знать, есть у тебя в приложении механизм ролей. Если нет, то стандартные права на чтение/запись через консоль управления SQL сервером. Если есть, то целесообразнее всего создать отдельный слой логики. Еще отдельная защита БД — хранимые процедуры. Создаешь одного пользователя, который может запускать только ему отведенные хранимые процедуры и ничего более (чувствуешь логику? сначала deny all, потом allow). Хранимая процедура запускается от имени пользователя, который ее создал. Поэтому это тебе может дать, на мой взгляд, максимальную security.

Я бы советовал исходить из того предположения, что механизм ролей есть, даже если его нет.

Вообще в твоем случае довольно сложно что-то сказать, мало информации. Давай подробнее, помогу чем смогу.

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

G>Вообще в твоем случае довольно сложно что-то сказать, мало информации. Давай подробнее, помогу чем смогу.

Опишу более подробно решаемую задачу.

Разрабатывается услуга “Интернет-банкинг”, пользователями которой будут являться организации, предоставляющие услуги, и банки, которые при приобретении данных услуг покупателями будут предоставлять на эти услуги кредиты. То есть, приходит покупатель в магазин по продаже бытовой техники, выбирает себе телевизор и хочет купить его в кредит. Сам продавец не предоставляет кридитов на свои услуги, но у него заключен договор по кредитованию с банком. Продавец-консультант и покупатель садятся за компьютер и составляют электронную-заявку на предоставление кредита, причем данную заявку заполняет продавец-консультант, покупатель лишь предоставляет ему необходимые данные (потому что продавец-консультант несет юридическую ответственность по предоставленным данным в банк). После того, как заявку заполнена, наживается кнопка ОТПРАВИТЬ и заявка пошла в банк. Минут через 10-15 из банка приходит ответ – предоставляет банк данному лицу кредит или нет.

Некоторые требования:
1) — Приложения по оформлению заявок на кредит д/б 2-ух видов: Windows-приложение и Web-приложение. Первостепенным будет разрабатываться Windows-приложение, Web-приложение будет дорабатываться позже, а может и не будет, но учитывать возможную разработку данного приложения все же стоит;
2) – Вся информация по заявками может сохраняться либо в БД MS SQL SERVER 2000 либо в нашем документообороте (Titanium). Отсюда – для клиентов д/б реализован независисый уровень работы с данными: меням сборку по работе с данными на стороне клиента и клиент работает через документооборот, меняем опять – уже все записывается в MS SQL SERVER. Решение что и как хранится принимает банк – сможем мы его убедить что наш документооборот штука классная – все будет на документообороте – не сможем – на БД MS SQL SERVER.
3) – Планируется реализовать компонент доступа к БД, который “будет уметь”, через который и будет построено все обращение к БД (по сути дела, это будет сервер приложений: на него будут поступать запросы от Win-клиентов и IIS Server (сервер Web-приложений) тоже будет работать через него);

Теперь конкретные вопросы:
1) – Работаем с БД MS SQL SERVER. На стороне БД реализовываем шлюз, который выполняет одновременно роль сервера и клиента – получает запросы с клиентов — транслирует их в БД – получает ответ из БД и опять отправляет клиенту. Наскольок идея шлюза целесообразна (более подробное описание функциональности шлюза в моих более ранних потсах)? Какие еще способы возможно применить для доступа клиентов к БД?;
2) – Методы пердачи инофрмации с клиентов на сервер (в БД):.NET Remoting, Web-сервисы. Плюсы и минусы предлагаемых способов? Какие траблы м/б в каждом из случаев?;
3) – Учитывая строгую шаблонность разработки, интересует возможность использования Microsoft Application Block. Что скажете по этому?;
4) – Разграниечение прав доступа на работу с БД. Тут возможно 2 варианта: либо на уровне приложение либо на уровне БД. Плюсы-минусы каждого способо в данном случае. Накидайте ссылок на обсуждение и описания данных способов;