Безопасность СУБД

1. Безопасность СУБД

2.

Безопасность СУБД

3.

Комплекс средств защиты СУБД

4.

Три основных аспекта
информационной безопасности СУБД
Конфиденциальность
(защита от несанкционированного
доступа)
Доступность
(защита от
несанкционированного
удержания информации и
ресурсов, защита от
разрушения, защита
работоспособности)
Целостность
(защита от
несанкционированного
изменения информации)
Конфиденциальность информации – это обязательное
для выполнения лицом, получившим доступ к
определенной информации, требование не передавать
такую информацию третьим лицам без согласия ее
обладателя.
Целостность информации – это состояние информации,
при котором отсутствует любое ее изменение или
изменение осуществляется только преднамеренно
субъектами, имеющими необходимые права.
Доступность информации – это состояние информации,
при котором лицу, обладающему правом доступа к
информации и выполнившему все необходимые условия
для получения доступа к информации и ее
использованию, не может быть отказано в доступе.

5.

Три основных аспекта информационной
безопасности СУБД
Качественное описание комплекса организационно-технологических и
программно-технических мер по обеспечению защищенности
информации в компьютерной системе называют политикой
безопасности.
Формальное (математическое, алгоритмическое, схемотехническое)
выражение и формулирование политики безопасности называют
моделью безопасности.

6.

Cубъектно-объектная модель
Субъект доступа – лицо или процесс, действия которого регламентируются правилами разграничения доступа.
Объект доступа – информационная единица АС, доступ к которой регламентируется правилами разграничения
доступа. (объектом может быть все что угодно, содержащее конечную информацию: база данных, таблица,
строка, столбец и т.д.)
Правила разграничения доступа - совокупность правил, регламентирующих права субъектов доступа к объектам
доступа.
Санкционированный доступ - доступ к информации в соответствии с правилами разграничения доступа.
Несанкционированный доступ - доступ к информации, нарушающий правила разграничения доступа в любом
проявлении или реализации.

7.

Cубъектно-объектная модель
Идентифика́ция в информационных системах — процедура, в результате выполнения
которой для субъекта/объекта идентификации выявляется его идентификатор,
однозначно идентифицирующий его в информационной системе. Для выполнения
процедуры
идентификации
в
информационной
системе
субъекту/объекту
предварительно должен быть назначен соответствующий идентификатор (то
есть проведена регистрация в информационной системе).
Процедура идентификации напрямую связана с аутентификацией: подтверждение
подлинности чего-либо или кого-либо. Субъект проходит процедуру аутентификации, и
если аутентификация успешна, то информационная система на основе факторов
аутентификации определяет идентификатор субъекта. При этом достоверность
идентификации полностью определяется уровнем достоверности выполненной
процедуры аутентификации.

8.

Cубъектно-объектная модель

9.

Cубъектно-объектная модель
Авториза́ция — предоставление определённому лицу или группе лиц прав на
выполнение определённых действий; а также процесс проверки данных прав
при попытке выполнения этих действий

10.

Процесс получения доступа пользователя к БД в
СУБД
Подключение к БД
Идентификация
Аутентификация
Пользователь должен
подключиться к БД
Авторизация
Разрыв
соединения
В случае разрыва соединения: транзакция
откатывается, пользователь
переподключается.
Работа с БД

11.

Cубъектно-объектная модель
В структуре ядра СУБД выделяется дополнительный компонент,
называемый монитором (сервером, менеджером, ядром) безопасности (Trusted
Computing Base- ТСВ), который реализует определенную политику безопасности во
всех процессах обработки данных.

12. Пользователи СУБД

Администраторы
Прикладные
программисты
Конечные
пользователи

13.

Модели управления доступом
Избирательное управление доступом
( Discretionary access control, DAC)
Мандатное управление доступом
( Mandatory access control, MAC)
Управление доступом на основе ролей
(Role Based Access Control, RBAC)
Разграничение доступа на основе атрибутов
(Attribute-Based Access Control, ABAC)

14.

Избирательное управление доступом
Discretionary access control, DAC
Также используются названия дискреционное управление доступом,
контролируемое управление доступом и разграничительное управление доступом.
Для каждой пары (субъект — объект) должно быть задано явное и недвусмысленное
перечисление допустимых типов доступа (читать, писать и т. д.), то есть тех типов доступа, которые
являются санкционированными для данного субъекта (индивида или группы индивидов) к
данному ресурсу (объекту)

15.

Избирательное управление доступом
Discretionary access control, DAC
Возможны несколько подходов к построению дискреционного управления доступом:
1. Добровольное управление доступом
Каждый объект системы имеет привязанного к нему субъекта, называемого владельцем. Именно владелец
устанавливает права доступа к объекту.
2. Принудительное управление доступом
Система имеет одного выделенного субъекта — суперпользователя, который имеет право устанавливать
права владения для всех остальных субъектов системы.
3. Комбинированный способ
Субъект с определённым правом доступа может передать это право любому другому субъекту

16. Управление привилегиями

• GRANT привилегия [ON объект] TO субъект [WITH GRANT OPTION]
• REVOKE привилегия [ON объект] FROM субъект
• DENY привилегия [ON объект] FROM субъект [CASCADE]
• SELECT — привилегия на выборку данных;
INSERT — привилегия на добавление данных;
DELETE — привилегия на удаление данных;
UPDATE — привилегия на обновление данных;
ALL — все возможные действия над таблицей.
• ALTER — изменение физической/логической структуры базовой таблицы
• CREATE— создание/удаление объектов базы данных;
• CONTROL — все возможные действия над объектами базы данных.

17. Модель Take-Grant

18. Мандатное управление доступом Mandatory access control, MAC

Все пользователи делятся на уровни и группы в соответствии с уровнем доверия к ним, а
так же в соответствии с принадлежностью их к той или иной группе субъектов.
Совершенно секретно
Секретно
Для служебного пользования
Общедоступная информация
ГРУППЫ
Информация отдела №28
…
…
Информация отдела №21
Информация отдела №7
УРОВНИ
…

19. Мандатный принцип состоит в сопоставлении меток доступа субъектов и объектов БД – вплоть до отдельных полей записи

Строка (снабжена меткой)
Мандатный принцип состоит в сопоставлении меток доступа
субъектов и объектов БД – вплоть до отдельных полей записи
Столбец (снабжен меткой)
Поле (снабжено меткой)

20.

Модель Белла — ЛаПадулы
Модель контроля и управления доступом, основанная на мандатной модели управления доступом. В
модели анализируются условия, при которых невозможно создание информационных потоков от субъектов
с более высоким уровнем доступа к субъектам с более низким уровнем доступа.
В модели Белла - ЛаПадулы объекты и субъекты категорируются
по иерархическому мандатному принципу доступы.
Субъект, имеющий допуск 1-й (высшей) степени, получает доступ к объектам 1-го (высшего)
уровня конфиденциальности и автоматически ко всем объектам более низких уровней
конфиденциальности (т. е. к объектам 2-го и 3-го уровней). Соответственно, субъект со 2-й
степенью допуска имеет доступ ко всем объектам 2-го и 3-го уровней конфиденциальности, и т.
д.

21.

Модель Белла — ЛаПадулы
В модели Белла - ЛаПадулы устанавливаются и поддерживаются два основных ограничения политики
безопасности:
• запрет чтения вверх (no read up - NRU);
• запрет записи вниз (no write down - NWD).

22.

Мандатное управление доступом
Mandatory access control, MAC

23.

Мандатное управление доступом
Mandatory access control, MAC

24. Ролевая модель ограничения доступа Role Based Access Control, RBAC

Представляет собой развитие политики дискреционного разграничения
доступа, при этом права доступа субъектов системы на объекты
группируются с учетом их специфики их применения, образуя задание
ролей. Метод позволяет определить более четкие и понятные для
пользователей компьютерной системы правила разграничения доступа. При
этом такой подход часто используется в системах, для пользователей
которых четко определен круг их должностных полномочий и обязанностей.

25. Ролевая модель ограничения доступа Role Based Access Control, RBAC

Роль является совокупностью прав доступа на объекты компьютерной
системы, однако ролевое разграничение отнюдь не является
частным случаем дискреционного разграничения, так как ее правила
определяют порядок предоставления прав доступа субъектам
компьютерной системы в зависимости от сессии его работы и от
имеющихся (или отсутствующих) у него ролей в каждый момент
времени, что является характерным для систем мандатного
разграничения доступа.
С другой стороны, правила ролевого разграничения доступа являются
более гибкими, чем при мандатном подходе к разграничению.

26.

Управление доступом на основе ролей
Role Based Access Control, RBAC
Ролевое управление доступом оперирует следующими основными понятиями:
пользователь (человек, интеллектуальный автономный агент и т.п.);
сеанс работы пользователя;
роль (обычно определяется в соответствии с организационной структурой);
объект (сущность, доступ к которой разграничивается; например, файл ОС или
таблица СУБД);
операция (зависит от объекта; для файлов ОС – чтение, запись, выполнение и
т.п.; для таблиц СУБД – вставка, удаление
и т.п., для прикладных объектов
операции могут быть более сложными);
право доступа (разрешение
выполнять определенные операции
над определенными объектами).

27.

Управление доступом на основе ролей
Role Based Access Control, RBAC
Можно считать, что они роли именуют отношения "многие ко многим" между пользователями и
правами. Во время сеанса работы пользователя активизируется подмножество ролей, которым он
приписан, в результате чего он становится обладателем объединения прав, приписанных
активным ролям. Одновременно пользователь может открыть несколько сеансов.
Между ролями может быть определено отношение частичного порядка, называемое
наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все
пользователи r2 приписываются r1.
Отношение наследования является иерархическим, причем права доступа и пользователи
распространяются по уровням иерархии навстречу друг другу. В общем случае наследование
является множественным, то есть у одной роли может быть несколько предшественниц (и,
естественно, несколько наследниц, которых мы будем называть также преемницами).

28.

Управление доступом на основе ролей
Role Based Access Control, RBAC
Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В
простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному
множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей –
число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что
никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного
множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает
членство не более чем в двух таких ролях (здесь число=3).
При наличии наследования ролей ограничение приобретает несколько более сложный вид, но суть
остается простой: при проверке членства в ролях нужно учитывать приписывание пользователей ролямнаследницам.
Динамическое разделение обязанностей отличается от статического только тем, что рассматриваются
роли, одновременно активные (быть может, в разных сеансах) для данного пользователя (а не те, которым
пользователь статически приписан). Например, один пользователь может играть роль и кассира, и
контролера, но не одновременно; чтобы стать контролером, он должен сначала закрыть кассу. Тем самым
реализуется так называемое временное ограничение доверия, являющееся аспектом минимизации
привилегий.

29.

Управление доступом на основе ролей
Role Based Access Control, RBAC

30.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC

31.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC
• Одно бизнес-правило «размазывается» среди множества ролей и становится неочевидным,
что усложняет понимание такого правила и его поддержку;
• Начинается взрывной рост числа ролей, что значительно усложняет управление ими.

32.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC
Существуют Бизнес-правила, в которых используются атрибуты, значения которых заранее не известны
и вычисляются в процессе работы, вообще невозможно выразить с помощью ролевой модели.
Существуют также бизнес-правила, которые ограничивают доступ не к действиям, а к данным. Такие
бизнес-правила также невозможно выразить с помощью ролевой модели.

33.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC
Основное отличие этого подхода в том, что каждая ситуация оценивается не с точки зрения роли пользователя
и действия, которое он хочет совершить, а с точки зрения атрибутов, которые к ним относятся.
Бизнес-правило, по сути, представляет собой набор условий, в которых различные атрибуты должны
удовлетворять предъявляемым к ним требованиям.
Можно явно выделить несколько категорий атрибутов.

34.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC
Для выполнения авторизации значения всех атрибутов берутся в момент проверки прав и
сравниваются с ожидаемыми значениями. Выполнение всех условий обеспечивает доступ к ресурсу.

35.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC

36.

Управление доступом на основе атрибутов
Attribute-Based Access Control, ABAC
Центральным элементом является правило, которые содержит в себе цель, действие , условия, обязательства и
рекомендации (двух последних может не быть) .
Цель — это то, как субъект ожидает подействовать на объект (читать, редактировать, удалять и т. д.).
Эффект(действие), который на основе вычислений логического выражения определяется системой контроля
доступа, может быть или разрешением ( permit), или отказом ( deny), или «не применимо» (not applicable), или
«не определено» ( indeterminate). Решение системы о неприменимости принимается в случае, когда логическое
условие оказывается «ложью». При возникновении ошибки во время вычисления выражения система выдаёт «не
определено».

37.

Сравнение ABAC и RBAC
На сегодняшний день для ABAC существует стандарт XACML, который активно развивается и используется.

38.

Варианты организации системы безопасности MS SQL Server.
Защищаемые объекты: сервер, база данных, схема
38

39.

Защищаемые объекты уровня сервера
39

40.

Защищаемые объекты уровня базы данных
40

41.

Защищаемые объекты уровня схемы
41

42.

Участники в
SQL Server
42

43.

Разрешения в SQL Server
Управление доступом к защищаемым объектам осуществляется путем предоставления или
отзыва разрешений, либо путем добавления имен входа и пользователей к ролям, имеющим
доступ.
GRANT < permissions > ON < securables > TO < principals >
DENY < permissions > ON < securables > TO < principals >
REVOKE < permissions > ON < securables > FROM < principals >
43

44.

Модель безопасности доверенного сервера приложений
Модель безопасности олицетворения или делегирования
полномочий

45.

Параметры проверки подлинности SQL Server
Необходимо определить, каким образом имена входа будут проходить
проверку подлинности.
SQL Server поддерживает два режима проверки подлинности:
Режим проверки подлинности Windows : является режимом по
умолчанию. Поскольку эта модель безопасности SQL Server тесно
интегрирована с Windows, часто ее называют встроенной функцией
безопасности. Только пользователи с логинами Windows могут
подключаться к SQL Server. Пользователи Windows, прошедшие проверку
подлинности, не должны предъявлять дополнительные учетные данные.
Режим смешанной аутентификации : поддерживает проверку
подлинности как средствами Windows, так и средствами SQL Server. Пары
имен пользователей и паролей ведутся в SQL Server.
45

46.

Стандартный режим обеспечения безопасности.
Преимущества
Для получения доступа к системе пользователь не обязательно должен быть
пользователем домена.
Упрощается задача получения контроля над пользовательской информацией
программным путем.
Недостатки.
Пользователи могут быть вынуждены регистрироваться два раза или больше — один раз
для получения доступа к сети и хотя бы еще один раз в СУБД SQL Server, поскольку
регистрация требуется для доступа к каждому соединению, создаваемому из отдельного
приложения.
В связи с необходимостью создавать по крайней мере по две учетные записи для каждого
пользователя объем работ по сопровождению, выполняемых администратором базы
данных, существенно увеличивается.
Если приходится применять несколько паролей, то в них можно легко запутаться, что
приводит к значительному возрастанию количества неудачных попыток регистрации или
забытых паролей.
46

47.

Сценарии проверки подлинности.
Обычно проверка подлинности Windows является наилучшим вариантом в
следующих ситуациях.
Имеется контроллер домена.
Приложение и база данных находятся на одном компьютере.
Используется экземпляр SQL Server Express или LocalDB.
Имена входа SQL Server часто используются в следующих ситуациях.
При наличии рабочей группы.
Пользователи подключаются из разных, не доверенных доменов.
Интернет-приложения, например ASP.NET.
47

48.

Сценарии проверки подлинности.

49.

Создание учетных записей и управление ими
Имя входа — это субъект безопасности, с помощью которого система безопасности может проверить
подлинность лица или сущности. Имя входа необходимо пользователю для соединения с SQL Server. Вы
можете создать имя входа на основе участника Windows (например, пользователя или группы домена
Windows), либо на основе пользователя, не являющегося участником Windows (например, имени входа
SQL Server).
Пользователь является субъектом безопасности уровня базы данных. Для соединения с базой данных
имя входа должно быть сопоставлено с пользователем базы данных. Имя входа может быть
сопоставлено с различными базами данных в качестве разных пользователей, но в каждой базе данных
ему может быть сопоставлен только один пользователь. При создании пользователя базы данных ему
назначается идентификатор (principal_id) и идентификатор безопасности (SID).
Схема представляет собой именованный контейнер для объектов базы данных, позволяющий
группировать объекты по отдельным пространствам имен.
С использованием команд Transact-Sql.
С использованием программы Management Studio.
49

50.

Создание учетных записей и управление ими
50

51.

Команда CREATE LOGIN (ИМЯ ВХОДА)
CREATE LOGIN login_name { WITH <option_list1> | FROM <sources> }
<option_list1> ::= PASSWORD = { 'password' | hashed_password HASHED } [
MUST_CHANGE ] [ , <option_list2> [ ,... ] ]
<option_list2> ::= SID = sid
| DEFAULT_DATABASE =database
| DEFAULT_LANGUAGE =language
| CHECK_EXPIRATION = { ON | OFF}
| CHECK_POLICY = { ON | OFF}
| CREDENTIAL =credential_name
<sources> ::= WINDOWS [ WITH <windows_options>[ ,... ] ]
| CERTIFICATE certname
| ASYMMETRIC KEY asym_key_name
<windows_options> ::= DEFAULT_DATABASE =database
| DEFAULT_LANGUAGE =language
51

52.

Команда CREATE USER (ПОЛЬЗОВАТЕЛЬ)
52

53.

Команда CREATE USER (ПОЛЬЗОВАТЕЛЬ)
CREATE USER user_name
[ { FOR | FROM } LOGIN login_name ]
[ WITH DEFAULT_SCHEMA = schema_name ]
USE Test
GO
CREATE USER [TestLogin] FOR LOGIN [TestLogin]
WITH DEFAULT_SCHEMA=[dbo]
53

54.

Схема
Основным принципом безопасности SQL Server является то, что владельцы объектов имеют неотзываемые
разрешения на их администрирование. Нельзя удалять права доступа у владельцев объектов. Также нельзя
удалять пользователей из базы данных, если они владеют в ней объектами.
Схема представляет собой именованный контейнер для объектов базы данных, позволяющий группировать
объекты по отдельным пространствам имен.
Четырехкомпонентный синтаксис ссылок на объекты указывает имя схемы.
Server.Database.DatabaseSchema.DatabaseObject
Создаем схему Accounting с владельцем Peter.
CREATE SCHEMA Accounting AUTHORIZATION Peter;
54

55.

Учетная запись пользователя dbo
Пользователь dbo – это специальный пользователь (или владелец базы данных) – представляет собой
учетную запись пользователя, которая имеет неявно заданные разрешения на выполнение любых
действий с базой данных. Он всегда присутствует в каждой базе данных, его невозможно удалить.
Любой член фиксированной серверной роли sysadmin (включая пользователя sa при использовании
смешанного режима проверки подлинности), который использует базу данных, сопоставляется с этим
пользователем.
Владелец базы данных может быть изменен. Любой пользователь (имя входа SQL Server или Microsoft
Windows), имеющий возможность соединения с SQL Server, может стать владельцем базы данных. В
следующем примере показано, как изменить владельца базы данных с помощью инструкции ALTER
AUTHORIZATION:
ALTER AUTHORIZATION ON DATABASE::salesdb
TO [ADVENTUREWORKS\Database_Managers];
Учетную запись пользователя dbo часто путают с предопределенной ролью базы данных db_owner.
Членство в роли db_owner не дает доступа к пользовательским привилегиям роли dbo.
55

56.

Предоставление прав доступа к объектам базы данных.
Права можно разделить на три категории:
• права на доступ к объектам;
<привилегия>::= {SELECT | DELETE | INSERT | UPDATE | EXECUTE |
REFERENCES|CONTROL|ALTER|VIEW DEFINITION }
•права на выполнение команд;
<команда>::= {CREATE DATABASE | CREATE TABLE | CREATE VIEW | CREATE
DEFAULT | CREATE RULE | CREATE PROCEDURE | BACKUP DATABASE | BACKUP LOG
| ALL }
• неявные права.
Неявные права не предоставляются пользователю непосредственно, он получает их лишь при определенных
обстоятельствах. Например, пользователь может стать владельцем объекта базы данных, только если сам
создаст объект либо если кто-то другой передаст ему право владения своим объектом. Таким
образом владелец объекта автоматически получит права на выполнение любых действий с объектом, в том
числе и на предоставление доступа к объекту другим пользователям. Эти права нигде не указываются,
выполнять любые действия позволяет только факт владения объектом.
56

57.

Предоставление прав доступа к объектам базы данных.
57

58.

Предоставление прав доступа к объектам базы данных.
CONTROL
Предоставляет возможности, подобные возможностям владельца; получатель имеет
практически все разрешения, определенные для защищаемого объекта. Принципал,
которому было предоставлено разрешение CONTROL, также имеет возможность
предоставлять разрешения на данный защищаемый объект. Разрешение CONTROL на
определенной области видимости неявно включает разрешение CONTROL для всех
защищаемых объектов в этой области видимости.
ALTER
Предоставляет возможность изменять свойства (за исключением владения)
защищаемых объектов. Когда это право предоставляется применимо к области, оно
также предоставляет права на выполнение инструкций ALTER, CREATE и DROP на
любых защищаемых объектах в данной области
VIEW DEFINITION
Предоставляет получателю возможность просматривать метаданные защищаемого
объекта
58

59.

Предоставление прав доступа к объектам базы данных.
GRANT { ALL [ PRIVILEGES ] } | permission [ ( column [ ,...n ] ) ] [ ,...n
]
[ ON [ class :: ] securable ]
TO principal [ ,...n ]
[ WITH GRANT OPTION ]
[ AS role_name ]
GRANT CREATE TABLE, CREATE PROCEDURE TO Vasya, [ProfessorWeb\Alexandr];
GRANT UPDATE ON Works_on (EmpId, EnterDate) TO Vasya;
GRANT VIEW DEFINITION ON OBJECT::Employee TO Vasya;
GRANT VIEW DEFINITION ON SCHEMA::dbo TO Vasya;
GRANT SELECT ON Works_on TO Vasya WITH GRANT OPTION;
59

60.

DENY, явный запрет разрешений на объект
DENY { ALL [ PRIVILEGES ] } | permission [ ( column [ ,...n ] ) ] [ ,...n ]
[ ON [ class :: ] securable ]
TO principal [ ,...n ]
[ CASCADE]
[ AS principal ]
GRANT SELECT ON Project TO PUBLIC;
DENY SELECT ON Project TO Vasya;
60

61.

REVOKE, отмена разрешения выданного ранее операторам
GRANT
REVOKE [ GRANT OPTION FOR ] <permission> [ ,...n ]
ON [ OBJECT :: ][ schema_name ]. object_name [ ( column [ ,...n ] ) ]
{ FROM | TO } <database_principal> [ ,...n ] [ CASCADE ]
[ AS <database_principal> ]
REVOKE SELECT ON Project FROM public;
61

62.

SET @SQLString ='Create schema ['+@login+'] AUTHORIZATION dbo;';
EXECUTE sp_executesql @SQLString
SET @SQLString ='Create user ['+@login+'] FOR LOGIN ['+@login+'] WITH
DEFAULT_SCHEMA=['+@login+'];';
EXECUTE sp_executesql @SQLString
SET @SQLString ='GRANT Control ON SCHEMA ::['+@login+'] TO
['+@login+'];';
EXECUTE sp_executesql @SQLString
SET @SQLString ='GRANT Create table TO ['+@login+'];';
EXECUTE sp_executesql @SQLString
SET @SQLString ='GRANT Create view TO ['+@login+'];';
EXECUTE sp_executesql @SQLString
SET @SQLString ='GRANT Create procedure TO ['+@login+'];';
EXECUTE sp_executesql @SQLString
SET @SQLString ='GRANT Create function TO ['+@login+'];';
62

63.

Роли сервера
Sysadmin
Данная
роль позволяет выполнять в СУБД SQL Server любые
действия.
Serveгadmin
Позволяет задавать опции конфигурации, относящиеся ко
всему серверу, или останавливать работу сервера.
Setupadmin
Ограничивается управлением связанными серверами и
процедурами запуска
Securityadmin
Используется для управления учетными записями, чтения
журналов регистрации ошибок и назначения прав доступа на уровне
оператора CREATE DATABASE.
Processadmin
Предоставляет
возможность
управлять
процессами,
выполняющимися в СУБД SQL Server; именно эта роль позволяет в случае
необходимости уничтожать процессы, которые функционируют в течение
слишком продолжительного времени
Dbcreator
Ограничивается созданием и модификацией баз данных
Diskadmin
Позволяет управлять файлами на диске (указывать, какие
файлы назначены в те или иные файловые группы, присоединять и отсоединять
базы данных и т.д.)
Bulkadmin
Она позволяет явно предоставить пользователю права на
выполнение оператора BULK INSERT
63

64.

Роли базы данных
public
Роль public содержится в каждой базе данных, включая системные базы данных. Ее
нельзя удалить, а также нельзя добавлять и удалять пользователей из нее. Разрешения,
предоставленные роли public, наследуются всеми остальными пользователями и
ролями, поскольку они принадлежат к роли public по умолчанию. Следует предоставлять
роли public только разрешения, необходимые для всех пользователей.
db_owner
Члены предопределенной роли базы данных db_owner могут выполнять все действия по
настройке и обслуживанию базы данных, а также удалять базу данных.
db_securityadmin
Элементы предопределенной роли базы данных db_securityadmin могут изменять
членство в роли и управлять разрешениями. Добавление участников к этой роли может
привести к непреднамеренному повышению прав доступа.
db_accessadmin
Члены предопределенной роли базы данных db_accessadmin могут добавлять или
удалять права удаленного доступа к базе данных для имен входа и групп Windows, а
также имен входа SQL Server.
db_backupoperator
Члены предопределенной роли базы данных db_backupoperator могут создавать
резервные копии базы данных.
64

65.

Роли базы данных
db_ddladmin
Члены предопределенной роли базы данных db_ddladmin могут выполнять
любые команды языка определения данных (DDL) в базе данных.
db_datawriter
Члены предопределенной роли базы данных db_datawriter могут добавлять,
удалять или изменять данные во всех пользовательских таблицах.
db_datareader
Элементы предопределенной роли базы данных db_datareader могут считывать
все данные из всех пользовательских таблиц.
db_denydatawriter
Члены предопределенной роли базы данных db_denydatawriter не могут
добавлять, изменять или удалять данные в пользовательских таблицах базы
данных.
db_denydatareader
Члены предопределенной роли базы данных db_denydatareader не могут
считывать данные из пользовательских таблиц базы данных.
65

66.

Роли
CREATE ROLE role_name [ AUTHORIZATION owner_name ]
Аргументы
role_name
Имя создаваемой роли.
AUTHORIZATION owner_name
Пользователь (или роль) базы данных, который
станет владельцем новой роли. Если пользователь не указан, владельцем роли
станет пользователь, выполнивший инструкцию CREATE ROLE.
CREATE ROLE marketing AUTHORIZATION Vasya;
GO
ALTER ROLE marketing ADD MEMBER 'Vasya';
ALTER ROLE marketing ADD MEMBER 'ProfessorWeb\Alexandr';
66

67.

Роли
sp_addrolemember [ @rolename = ] 'role', [ @membername = ]
'security_account'
Аргументы
[ @rolename= ] 'role‘ Имя роли базы данных в текущей базе
данных. Аргумент role имеет тип sysname и не имеет значения по
умолчанию.
[ @membername= ] 'security_account‘
Учетная запись
безопасности, добавляемая к роли. Аргумент security_account имеет
тип sysname и не имеет значения по умолчанию.
Аргумент security_account может быть пользователем базы данных,
ролью базы данных, именем входа Windows или группой Windows.
67

68.

Конфликты доступа
Разрешения, предоставленные роли или группе, наследуются их членами.
Хотя пользователю может быть предоставлен доступ через членство в
одной роли, роль другого уровня может иметь запрещение на действие с объектом.
В таком случае возникает конфликт доступа .
При разрешении конфликтов доступа SQL Server руководствуется следующим
принципом:
разрешение на предоставление доступа имеет самый низкий приоритет, а
на запрещение доступа – самый высокий.
Это значит, что доступ к данным может быть получен только явным
его предоставлением при отсутствии запрещения доступа на любом другом
уровне иерархии системы безопасности.
Если доступ явно не предоставлен, пользователь не сможет работать с данными.
68

69.

Управление контекстом выполнения кода
SQL Server позволяет указать контекст безопасности, в котором будут выполняться те или иные операторы
программного модуля, а именно учетной записи, использующейся при проверке разрешений на объекты,
на которые ссылается процедура или функция. Это может быть, например, учетная запись пользователя,
вызвавшего процедуру, или учетная запись пользователя, создавшего процедуру, или же другая учетная
запись.
Так, решение такой часто встречающейся задачи, как предоставление доступа к процедуре без
предоставления доступа к таблице, которую использует данная процедура, решается с помощью
оператора EXECUTE AS без необходимости предоставления пользователям процедуры дополнительных
привилегий. Конструкция EXECUTE AS, указываемая при создании соответствующего объекта базы данных,
задает пользовательскую учетную запись, которую SQL Server будет использовать для проверки прав доступа
к объектам, используемым в коде хранимой процедуры или пользовательской функции. В результате код,
выполнение которого инициировано пользователем, выполняется так, как если бы пользователь
зарегистрировался под другой учетной записью.
Использование конструкции EXECUTE AS позволяет исключить цикличное назначение и проверку прав
доступа при выполнении конструкций SELECT, INSERT, UPDATE, DELETE и EXECUTE, а также открытия
непосредственного доступа к ряду объектов базы данных.
69

70.

Узнать права у логина на объекты MS SQL сервера
70

71. fn_my_permissions ( securable , 'securable_class' ) Аргументы Имя защищаемого объекта. Если защищаемый объект — сервер или база

данных, то это значение должно быть
установлено в NULL
Имя класса защищаемого объекта, для которого перечислены разрешенияАргумент securable_class принимает одно из
следующих значений: APPLICATION ROLE, ASSEMBLY, ASYMMETRIC KEY, CERTIFICATE, CONTRACT, DATABASE, FULLTEXT CATALOG,
MESSAGE TYPE, OBJECT, REMOTE SERVICE BINDING, ROLE, ROUTE, SCHEMA, SERVICE, SYMMETRIC KEY, TYPE, USER, XML SCHEMA
COLLECTION.

72.

Цепочки владения

73. Шифрование

• База данных в целях защиты целиком
подвергается математическому
преобразованию при помощи
современных алгоритмов
• Применение оптимизированных
алгоритмов преобразования и
управления буферным кэшем
обеспечивают минимальное падение
производительности
• Поддерживаются алгоритмы
SQL Server позволяет администраторам и разработчикам выбирать из
нескольких алгоритмов, в том числе DES, Triple DES, TRIPLE_DES_3KEY,
RC2, RC4, RC4 со 128-разрядным ключом, DESX, AES со 128-разрядным
ключом, AES со 192-разрядным ключом и AES с 256-разрядным ключом.

74. Шифрование

Для увеличения надежности криптозащиты и уменьшения нагрузки
на систему применяется специальная иерархия ключей.
1. Ключ каждой базы данных шифруется при помощи специального
ключа – Database Encryption Key.
2. Database Encryption Key шифруется сертификатом, который
создан в базе данных Master.
3. Сертификат базы данных Master шифруется ее главным ключом.
4. Главный ключ БД Master шифруется главным ключом службы
Service Master Key.
5. Главный ключ службы SMK шифруется службой защиты данных
операционной системы.

75.

SQL Server поддерживает
следующие механизмы
шифрования:
•Transact-SQL ;
•асимметричные ключи;
•симметричные ключи;
•сертификаты
•прозрачное шифрование
данных.

76. Криптографические функции

ENCRYPTBYKEY, использует симметричный ключ для
шифрования данных;
ENCRYPTBYCERT, использует открытый ключ сертификата для
шифрования данных;
ENCRYPTBYPASSPHRASE, использует парольную фразу для
шифрования данных;
ENCRYPTBYASYMKEY, использует асимметричный ключ для
шифрования данных.

77. Криптографические функции

• DECRYPTBYKEY, использует симметричный ключ для
расшифровки данных;
• DECRYPTBYCERT, использует открытый ключ сертификата для
расшифровки данных;
• DECRYPTBYPASSPHRASE, использует парольную фразу для
расшифровки данных;
• DECRYPTBYASYMKEY, использует асимметричный ключ для
расшифровки данных;
• DECRYPTBYKEYAUTOASYMKEY, использует асимметричный ключ,
который автоматически расшифровывает сертификат.

78.

Полный аудит действий в системе
Возможность отслеживать происходящие события и
регистрировать сведения о них, включая сведения о
пользователях, обращающихся к объектам, а также
времени и содержании вносимых изменений, помогает
администратору обеспечить соблюдение стандартов
соответствия нормативным или организационным
требованиям по безопасности. Кроме того, понимание
происходящих в среде событий также может помочь при
разработке плана по снижению рисков и
поддержания безопасности в среде.

79.

Полный аудит действий в системе
Входы
в систему
Запрос к
конкретной
таблице
Время
запроса
Адрес
станции
AUDIT-подсистема
(система протоколирования)
Изменение
схемы БД
Попытки
понижения
секретности
Изменение
подсистемы
доступа
Новый
пользователь

80. Резервное копирование и восстановление

• Восстановление БД — это процесс возвращения БД в
состояние, утраченное в результате сбоя или отказа.
• Восстановление БД — это защита от потерь методом
создания резервных копий и восстановления данных по
ним.