Предоставляя разрешения для определенной схемы в SQL Server, я хочу запретить некоторые операции определенным пользователям. Должен ли я явно отрицать это, или это так, что когда пользователь получает разрешение на эту схему, права на эту схему автоматически запрещаются для других пользователей?
По умолчанию права на объекты в схеме пользователю не предоставляются. Однако есть несколько способов, которыми пользователь может получить права на объект. Например, права могут быть явно предоставлены пользователю и / или группе, членом которой является пользователь.
В DENY команда отказывает в правах пользователю или группе, даже если пользователю были предоставлены права на объект. Например, предположим, что пользователь A является членом группы MyGroup и этой группе предоставлено право доступа к таблице MyTable. Все пользователи в MyGroup могут запрашивать MyTable. Теперь вы можете запретить доступ к MyTable для пользователя A. Пользователь A не сможет запрашивать MyTable, но остальные члены группы по-прежнему могут запрашивать таблицу.
Поэтому, вероятно, лучше явно запретить права пользователям, которые не должны иметь доступ к схеме.
Думайте о схеме в SQL как о дереве. Чем дальше назад к корню схемы у пользователя есть разрешенное право, тем дальше по стволу и ветвям пользователь будет поддерживать это разрешение, пока вы не откажетесь от него. Если у пользователя A есть разрешения на выполнение сохраненных процессов в базе данных, тогда у него есть права на доступ ко всем сохраненным процессам в этой БД, и если вы не хотите, чтобы у них были права на запуск одного, вам придется пометить его как Отрицать. То же самое и с правами на чтение, запись, обновление и т.д. Если у пользователя есть эти права на более высоком уровне, тогда да, вам нужно неявно отказать. Я не могу придумать ничего (включая вход в систему), что пользователь имеет права делать, если вы не предоставите ему этот доступ в первую очередь. Имея в виду, конечно, некоторые из них могут быть предоставлены при создании пользователя.
Последнее, что я скажу, это то, что никогда не помешает убедиться. Я часто указываю разрешить или запретить элементы, которые более важны для безопасности, хотя я знаю, что это уже должно быть так.