Аутентификация базы данных для приложений интрасети
Я ищу передовой метод сквозной аутентификации для внутренних веб-приложений на уровне базы данных.
Наиболее распространенный сценарий, который я видел, - это использование одной учетной записи SQL с разрешениями, установленными в соответствии с требованиями приложения. Эта учетная запись используется для всех вызовов приложений. Затем, когда людям требуется доступ к базе данных с помощью инструментов запросов или создается отдельная группа с доступом для запросов, и людям предоставляется доступ к этой группе.
Другой сценарий, который я видел, - это использование полной проверки подлинности Windows от начала до конца. Таким образом, сами пользователи добавляются в группы, у которых установлены все разрешения, поэтому пользователь может обновлять и изменять вне параметров приложения. Обычно это включает в себя защиту людей до соответствующих хранимых процедур, чтобы они не обновляли таблицы напрямую.
Первый сценарий кажется относительно простым в обслуживании, но вызывает опасения, что если в приложении есть дыра в безопасности, то вся база данных будет скомпрометирована.
Второй сценарий кажется более безопасным, но имеет противоположную озабоченность по поводу наличия большого количества бизнес-логики в хранимых процедурах в базе данных. Похоже, это ограничивает использование некоторых действительно крутых технологий, таких как Nhibernate и LINQ. Однако в наши дни, когда люди могут использовать данные по-разному, мы не предвидим, например мэшапы и т. д. - это лучший подход.
Ответы 5
Лично мне не нужны обычные конечные пользователи в базе данных. Для приложения интрасети (особенно того, которое находится в домене) я бы предоставил одну учетную запись для доступа приложения к базе данных, которая имеет только те права, которые необходимы для работы приложения.
Затем доступ к приложению будет контролироваться через учетную запись домена пользователя (отключите анонимный доступ в IIS и т. д.).
ЕСЛИ пользователю необходим и может быть оправдан прямой доступ к базе данных, тогда его учетная запись домена получит доступ к базе данных, и он сможет войти в СУБД с помощью соответствующих инструментов.
За последний год я отвечал за разработку нескольких внутренних веб-приложений.
В нашем решении использовалась проверка подлинности Windows (Active Directory или LDAP).
Наша цель состояла в том, чтобы просто разрешить простой вход с использованием существующего идентификатора компании / пароля. Мы также хотели убедиться, что существующий отдел по-прежнему будет нести ответственность за проверку и управление разрешениями доступа.
Хотя я не могу ответить на аргумент, касающийся Nhibernate или LINQ, если у вас нет особой функции-убийцы, которую эти вещи могут реализовать, Active Directory или LDAP достаточно просты для реализации и поддержки, поэтому стоит попробовать.
Стивен. Не допускать доступа обычных конечных пользователей к базе данных - это хорошо, но мне интересно, верен ли этот путь в наши дни, когда так много опытных пользователей компьютеров выходит из университета / колледжа. Если кто-то хочет автоматизировать часть своей работы, которая включает обновление VBA для базы данных, которое я разрешаю им делать через обычное приложение, мы теряем прибыль, ограничивая их доступ таким образом.
Я предполагаю, что здесь подразумевается другой путь: вы можете открыть приложение через службы, а затем защитить эти службы через группы и при этом сохранить пользователей отдельно от базы данных.
Затем с помощью делегирования вы можете разрешить отделам контролировать доступ к своим учетным записям через группы, как указано в сообщении Джонатана.
Я согласен со Стивеном Райтоном. Безопасность домена - лучший выбор. Если вы хотите использовать гибридные приложения и тому подобное, вы можете предоставить доступ к частям базы данных через машиночитаемый интерфейс RESTful. SubSonic имеет один встроенный.
Дейл - Именно так. Если вы хотите предоставить этим пользователям доступ к базовому хранилищу данных, сделайте это через службы. По моему опыту, больше всего вредят именно те опытные пользователи компьютеров, которые выпускаются из Университета / Колледжа. Как говорится, они знают достаточно, чтобы быть опасными.
Если они хотят автоматизировать часть своей работы и могут показать, что обладают необходимыми знаниями, тогда давайте, предоставьте их учетная запись домена доступ к бэкэнду. Таким образом, все, что они делают с помощью своей маленькой автоматизации VBA, привязано к их учетной записи, и вы точно знаете, к кому обратиться, когда данные будут переданы.
Я считаю, что база данных - это пресловутый Святой Грааль приложения. Вы хотите, чтобы в этом пироге было как можно меньше пальцев.
Как консультант, всякий раз, когда я слышу, что кто-то разрешил обычным пользователям доступ к базе данных, мои глаза загораются, потому что я знаю, что это будет для меня большой зарплатой, когда меня вызовут, чтобы исправить это.