Управление доступом к базе данных: Приложение или регулятор уровня Базы данных?

По моему мнению

1. Да, это плохая практика, так как пользователь может использовать учетные данные для доступа к базе данных другим способом, обойти контроль доступа ваших приложений и выполнить действия, на которые он не должен иметь права. Если вы работаете в домене windows, вы можете создать группу в AD для каждой роли и назначить пользователей в эту группу, а затем применить разрешения на основе этой группы, чтобы вам не пришлось добавлять новых пользователей в SQL.

Если вы пойдете по пути активного каталога, вы можете использовать LDAP запрос, чтобы увидеть, к каким группам принадлежит пользователь, и решить, должен ли он иметь доступ.

Будет интересно почитать другие ответы на этот вопрос.

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

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

Для приложений на уровне «отделов», то есть где доступ ограничен полдюжиной или около того пользователей, данные не являются критически важными для бизнеса, и никогда не будет необходимости использовать данные вне исходного приложения, а затем приложения- уровень безопасности обычно более удобен, а риски часто приемлемы. У меня есть клиенты, которые продают индивидуальное вертикальное прикладное программное обеспечение малым предприятиям, используя этот подход, и, поскольку нет внутренней ИТ, трудно представить, как еще можно было бы удобно делать это без больших накладных расходов на поддержку.

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

1. Это плохая практика, но, как вы видели, именно так большинство приложений «развиваются», начиная с открытых для нескольких пользователей и сужаясь по мере того, как все больше людей (ИТ / администраторы баз данных) становятся вовлеченный.

2. Ваш администратор баз данных должен быть в состоянии помочь - почти во всех общих книгах по SQL Server есть глава или две о пользователях, ролях и безопасности. Они также смогут объяснить нюансы различных вариантов безопасности и объяснить, что лучше всего работает в вашей среде.

Многие настройки будут зависеть от среды и приложения. Например, если все ваши пользователи подключены к Windows (на основе), вы захотите использовать проверку подлинности Windows вместо проверки подлинности SQL. Если у вас много различных ролей, вы захотите использовать роли SQL Server. Вы можете захотеть включить группы AD, а также роли (или вместо них). Ваш администратор базы данных может помочь вам принять эти решения или даже принять их за вас, когда вы объясните им больше о своем приложении.

Люди в SO, безусловно, также могут высказать свое мнение, если вы опубликуете дополнительную информацию о среде, приложении и использовании.