Мнения об аутентификации между уровнями приложения и базы данных

Question

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

Новое поле выглядит следующим образом: у нас есть веб-приложение asp.net, общение с бизнес-уровнем, общение с базой данных.

* Одно из требований состоит в том, чтобы пользователи более высокого уровня могли делегировать права бизнес-уровня другим пользователям.

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

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

Это может быть потому, что я пришел изфон Java-оракула, где в большинстве случаев вы используете пул соединений, который обеспечивает соединения, которыеch был уже аутентифицирован с использованием учетной записи типа сервиса.У нашей интернет-клиентки никогда не было реальных учетных записей базы данных .

Не ошибаюсь ли я, что управление делегируемой безопасностью (пользователями Интернета) внутри встроенного внутреннего хранилища учетных данных, предоставляемого сервером mssql, кажется чреватымОпасность безопасности?

У кого-нибудь есть какие-либо рекомендации?

Answer 1

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

Например, моя способность редактировать пост в переполнении стека не контролируется моей способностью чтения / записи в таблицу «posts» - фактически, вы, вероятно, даже не могли бы разработать схему базы данных, которая позволила бы вам реализовать безопасность на уровне базы данных на этом уровне. Вместо этого есть слой бизнес-логики, который сравнивает мои привилегии с действием, которое я пытаюсь предпринять (я полагаю); Безопасность реализована на уровне бизнес-логики.

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

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

Answer 2

Каким образом у вас могут быть потенциальные пользователи и как могут эти пользователи быть активными одновременно?

Например, если у вас есть 100 000 пользователей, и тысячи могут быть в сети одновременно, то вам потребуется 1000 открытых соединений с базой данных, чтобы обслуживать их всех, поскольку каждый пользователь может использовать только свое собственное соединение. Установка и разрыв соединения для каждой транзакции очень дороги и замедляют работу приложения.

Лично я бы пошел за пул соединений, и не было бы учетной записи пользователя базы данных на пользователя Интернета. Так обычно создаются веб-приложения.

Что-то вроде Oracle Fine Grained Access Control может дать вам средний уровень безопасности, при котором вы устанавливаете «интернет-пользователя» в сеансе, а затем база данных гарантирует, что интернет-пользователь может получить доступ только к тому, что ему разрешено, на основе правил в база данных.