Какова наилучшая практика обеспечения безопасности ролей в среде Intratnet ASP.NET/SQL2K5? - PullRequest
3 голосов
/ 03 апреля 2009

Наша текущая интранет-среда немного устарела. Текущий стек имеет приложения ASP.NET 1.1 / 2.0, которые выполняют запросы к базе данных SQL 2000.

Для обеспечения безопасности ролей на серверах есть группы пользователей, в которые добавляются пользователи (поэтому необходимо добавить их в группу на тестовом и производственном компьютере). Эти группы пользователей синхронизируются в роли пользователя на самом SQL 2000. Роли получают разрешения на выполнение хранимых процедур по мере необходимости для предотвращения любых нарушений доступа.

На уровне веб-приложений мы используем базовую аутентификацию (которая аутентифицируется в нашей Active Directory) и включаем олицетворение личности. Строка подключения к базе данных использует встроенную безопасность. Это создает среду, в которой веб-приложение подключается к базе данных при входе пользователя в систему, что обеспечивает безопасность базы данных при вызове хранимых процедур. Это также позволяет нам использовать типичный метод User.IsInRole () для выполнения авторизации внутри самого приложения.

Есть несколько проблем с этим. Во-первых, только наши администраторы сервера имеют доступ к группам пользователей на компьютере, поэтому обновление безопасности ролей или добавление дополнительных пользователей не в руках администраторов приложений. Кроме того, единственный способ получить роль - это вызвать процедуру SQL под названием «xp_logininfo», которая заблокирована в SQL 2005. Хотя я не знаю всех подробностей, наш администратор БД говорит, что эта общая модель не играет хорошо с SQL 2005, учитывая характер схем в более новой версии.

Мы находимся сейчас в точке, когда мы готовы обновить нашу среду. Мы пишем приложения .NET 3.5 для более эффективного использования AJAX, а SQL Server 2005 является основной средой для нашей базы данных. Мы также стремимся обновить модель безопасности, чтобы сделать ее более гибкой для администраторов приложений и потенциально использовать больше Active Directory.

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

Что считается наилучшей практикой для поддержания безопасности ролей в такой среде?

Ответы [ 3 ]

2 голосов
/ 03 апреля 2009
0 голосов
/ 13 апреля 2009

Попробуйте реорганизовать ваш дизайн таким образом, чтобы ваш репозиторий был LDAP. Таким образом, по существу ваши объекты пользователей и ролей отображают объекты AD. После этого вы можете получить полный контроль, а не проходить через различных системных администраторов. Конечно, это не легко в зависимости от состояния кода. Но лучший способ для начала - создать небольшое доказательство концепции, чтобы выполнить это сопоставление ваших бизнес-объектов с AD.

0 голосов
/ 03 апреля 2009

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

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

Решения о том, следует ли передавать идентификационные данные на SQL Server вместо использования модели доверенных подсистем, в значительной степени зависят от конкретного сценария. Тем не менее, я не люблю передавать идентичность таким образом, потому что обычно в приложении все еще применяется логика, что означает, что sp, вероятно, применяют частичные правила. По этой причине такой подход также требует большей логики в хранимых процедурах.

О тех администраторах, которые имеют доступ к группам пользователей на машине, рассмотрим ADAM (режим приложения с активным каталогом). Я не знаю, поддерживает ли он его интеграцию с SQL Server, поэтому я не уверен, будет ли это работать с этой архитектурой. Хотя стоит проверить.

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

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

...