Пользователь dbo не должен использоваться для нормальной работы службы

Question

Когда я просматриваю свою базу данных, он показывает один из результатов, например VA1143 'dbo' user не должен использоваться для нормальной работы службы в Сканирование оценки уязвимости «Создавайте пользователей с низкими привилегиями для доступа к БД и любым данным, хранящимся в ней, с соответствующим набором разрешений».

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

Answer 1

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

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

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

Например, ниже приведен код, который создает пользователя с доступом только для чтения для SQL базы данных:

--Create login in master DB
USE master
CREATE LOGIN reader WITH PASSWORD = '<enterStrongPasswordHere>';

--create user in user DB
USE Mydatabase
CREATE USER reader FOR LOGIN reader;  
GO
--set the user reader as readonly user
EXEC sp_addrolemember 'db_datareader', 'reader';

Для получения дополнительных сведений см. ссылку:

1. Авторизация доступа к базе данных для аутентифицированных пользователей к SQL базе данных и Azure Synapse Analytics с использованием логинов и учетных записей пользователей

Надеюсь, это поможет.

Answer 2

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

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