Лекция 6. Модель безопасности СУБД

**Принципы обеспечения безопасности баз данных. Определения элементов безопасности.** Безопасность многопользовательских баз данных, это не только обеспечение непрерывности работы серверов баз данных и доступа к ним, это еще и процедуры, связанные с обеспечением защиты данных и баз данных от несанкционированного доступа. Приведем общие принципы обеспечения безопасности СУБД. 1. Настройка брандмауэра (сетевого экрана). При настройке такого программного обеспечения, стоит особое внимание уделить его выбору, а также документации по настройке как самого брандмауэра, так и по настройке СУБД для наиболее корректной и эффективной работы связки. При этом заранее следует планировать меры безопасности в предположении, что брандмауэр был обойден злоумышленником. 2. Самая важная мера безопасности по мнению большинства специалистов по информационной безопасности, это своевременные обновления и установка пакетов исправлений операционной системы, в среде которой работает СУБД и ее компоненты, и пакеты обновлений самой СУБД. Выход нового пакета обновлений – это сигнал для злоумышленника, что компания-производитель ОС или СУБД выявила и закрыла одну или несколько критических уязвимостей, которые злоумышленник будет пытаться искать в не обновлённых версиях программного обеспечения. 3. Использовать только необходимый набор функций операционной системы и СУБД. Неиспользованные функции при возможности удалить или выключить: - свести к минимуму число поддерживаемых сетевых протоколов; - удалить системные хранимые процедуры, которые не нужны или не используются; - по возможности запретить вход в систему по умолчанию и с гостевыми правами; - не позволять пользователям работать с СУБД в интерактивном режиме (если в этом нет насущной необходимости). К мероприятиям, которые реализуются в ходе укрепления защиты сервера баз данных относятся: - меры по разработке политики безопасности организации и донесения ключевых позиций политики до всех сотрудников (в контексте дисциплины не рассматривается); - меры по обеспечению безопасности сетевого окружения организации, включающие установку, настройку и мониторинг программного и аппаратного обеспечения организации (в контексте дисциплины не рассматривается); - меры по защите сервера базы данных (определены в соответствии со стандартом безопасности серии NIST): - не позволять никому из пользователей работать за компьютером, на котором работает СУБД; - компьютер, на котором располагается СУБД, должен находиться в помещении, запираемом на замок; - все визиты в помещение, где находится компьютер с работающей СУБД, должны записываться в журнал; - меры, связанные с управлением учетными записями и ролями пользователей баз данных (будут рассмотрены подробно). ***Пользователем базы данных*** считается человек или программное средство, успешно прошедшие проверку по логину, сертификату, ассиметричному ключу или любому иному способу аутентификации, наделяемые соответствующими правами работы с данными (процедура авторизации). Политика управления пользователями баз данных также регламентируется рядом требований: - использовать для СУБД учетную запись операционной системы с наименьшими возможными привилегиями (учетные записи операционных систем, как правило, защищены значительно сильнее, чем учетные записи программного обеспечения, в том числе и СУБД); - защищать учетные записи базы данных сильными паролями (сильными паролями считается произвольный набор прописных и заглавных букв, цифр и разрешенных символов, длиной не менее 12-ти знаков, изменяемые и обновляемые с периодичностью 2-3 недели); - отслеживать неудачные попытки входа в систему; - регулярно проверять членство в группах и роли (информация о ролях и группах сохраняется в системных представлениях СУБД); - проверять учетные записи без паролей (если это возможно – вообще избавиться от них); - назначать учетным записям наименьшие возможные привилегии (доступ только к тому, что реально требуется этой учетной записи для работы); - ограничивать привилегии учетной записи администратора базы данных (в случае наличия в организации нескольких администраторов баз данных – четкая дифференциация их функций: управление файлами данных, управление пользователями, управление структурой хранения данных и т. д.). **Документация и скрипты модели безопасности баз данных.** Далее, рассмотрим базовые процессы создания модели безопасности в организации. Ключевыми являются два документа – непосредственно Модель безопасности и Таблица требований к ролям и пользователям. Модель безопасности базы данных – документ, классифицирующий и связывающий актуальных пользователей и роли, в которых они участвуют, с объектами базы данных, к которым они имеют доступ в рамках требуемых им для работы полномочий. Записи в модели приводятся в виде бизнес-требований к модели, слабо формализованным языком. Образец модели безопасности показан на рис. 1.  Таблица требований к ролям и пользователям – двухмерная таблица, написанная формальным языком. По одной оси откладываются роли и пользователи базы данных, по другой оси – элементы базы данных. На пересечениях фиксируется наличие или отсутствие прав доступа пользователя к объекту. При наличии этих прав, они конкретизируются, рис. 2.  После составления Модели и Таблицы, администратор создает и настраивает учетные записи пользователей базы данных (в примерах ниже рассмотрена структура учетных записей пользователей СУБД MS SQL Server 2018). Для Учетной записи пользователя, администратору необходимо создать два элемента базы данных – логин (LOGIN, для процедуры аутентификации) и пользователя (USER, для процедуры авторизации). Логин пользователя (LOGIN) – элемент базы данных, который используется СУБД при процедуре определения “является ли пользователь действительно тем, кем он представляется”. Эта процедура называется аутентификацией, и, в случае успешного ее прохождения, пользователь получает возможность соединиться с сервером баз данных. Логин может быть создан как для пользователя операционной системы MS Windows, так и для пользователя самой СУБД. Скрипты для двух вариантов: CREATE LOGIN [база данных\имя пользователя в ОС] FROM WINDOWS; CREATE LOGIN /Имя пользователя/ WITH PASSWORD = '/пароль пользователя/'; Пользователь базы данных (USER) – элемент базы данных, добавляется к существующему LOGIN. Наделяет пользователя, успешно прошедшего аутентификацию соответствующими ему правами доступа к другим элементам базы данных. Эта процедура называется авторизацией. CREATE USER /Имя пользователя/ [FOR {LOGIN…}, {CERTIFICATE…}, {ASSYMETRIC_KEY}] [WITH DEFAULT_SCHEMA = schema_name] В контексте пользователя упоминается еще один важный элемент модели безопасности СУБД. Схема – группа логически объединенных элементов базы данных, принадлежащих одному из пользователей или ролей базы данных. Схемы делятся на системные (схемы по умолчанию) и пользовательские. Перечислим системные схемы MS SQL Server: • guest, минимально возможные права доступа к элементам базы данных, для обеспечения работы в базе данных администратор должен выдать дополнительные разрешения; • dbo, владелец базы данных, полный доступ ко всем элементам ядра базы данных. Пользователь, осуществивший релиз СУБД получает эти права по умолчанию; • INFORMATION_SCHEMA, доступ к метаданным всех объектов баз данных; • Sys, доступ к системным представлениям (например, просмотр системных каталогов). Пользовательские схемы базы данных создаются администратором в случае необходимости. Скрипт создания схемы – это атомарная процедура, состоящая из инструкций создания таблиц, представлений и определения прав доступа к ним. CREATE SCHEMA /Имя схемы/ AUTORIZATION [/Имя пользователя/] Сгруппированные вследствие одинаковых прав доступа к одинаковым элементам или схемам базы данных пользователи формируют Роли. ***Роль*** - фиксированная системная или пользовательская группа пользователей или приложений, имеющих одинаковые права на действия в рамках схем баз данных. Выделяют серверные роли (права на уровне сервера) и роли баз данных (права на уровне баз данных). Описание серверных ролей приведено в табл. 1, описание ролей баз данных приведено в табл. 2.   Создание пользовательской серверной роли в случае необходимости осуществляется выполнением инструкции: CREATE SERVER ROLE /Имя роли/; Для добавления и удаления пользователя в роли используется инструкция: ALTER SERVER ROLE /Имя роли/ ADD (DROP) MEMBER /Имя пользователя/; После успешного прохождения авторизации, пользователь получает права доступа к объектам базы данных, в соответствии с определением требований (рис. 30). Для предоставления полномочий доступа пользователям используется инструкция GRANT: GRANT [ALL или /перечисление полномочий через запятую/] ON /Имя объекта базы данных, к которому дается доступ/ TO /имя или имена пользователей, наделяемых полномочиями, через запятую/. Ниже разберем наиболее часто определяемые полномочия. - SELECT, возможность считывать строки, можно ограничить это полномочие задав список выводимых столбцов; применяется к таблицам, представлениям, функциям; - INSERT, возможность добавлять строки; применяется к таблицам и представлениям; - UPDATE, возможность изменять значения столбцов, можно указать список столбцов через запятую; применяется к таблицам и представлениям; - DELETE, возможность удалять строки; применяется к таблицам и представлениям; - EXECUTE, возможность запустить на исполнение пользователем хранимую процедуру или функцию; применяется к хранимым процедурам и функциям; - ALTER, возможность изменять свойства объекта базы данных; применяется к таблицам, представлениям, хранимым процедурам, функциям. Для блокировки доступа пользователя к объекту (включая ранее выданные полномочия) используется инструкция DENY. DENY [ALL или /перечисление полномочий через запятую/] ON /Имя объекта базы данных, к которому блокируется доступ/ TO /имя или имена пользователей, для которых блокируются полномочия, через запятую/. Для удаления ранее выданных полномочий пользователя к объекту используется инструкция REVOKE. REVOKE снимает как «положительные» полномочия GRANT, так и “отрицательные” полномочия DENY. REVOKE [ALL или /перечисление полномочий через запятую/] ON /Имя объекта базы данных, для которого удаляются полномочия/ TO /имя или имена пользователей, для которых удаляются полномочия, через запятую/. Более подробно инструкции управления полномочиями и документация, сопровождающая процесс будут рассмотрены в практических работах в рамках данного курса. **Элементы безопасности и скрипты MongoDB.** Рассмотрим основы процедуры создания пользователей в noSQL СУБД на примере MongoDB. В отличие от реляционных СУБД, создание LOGIN, как инструмента аутентификации не требуется, так как аутентификации и авторизация будет происходить на уровне Пользователя (USER). В общем случае, пользователи создаются для конкретной базы данных, этот факт необходимо учитывать в контексте того, что в системе могут находиться разные пользователи с одинаковыми именами (созданные для разных баз данных). Новый пользователь создается следующим типовым скриптом: {user: “<имя пользователя>”, pwd: “<пароль пользователя>”, customData: {любая дополнительная информация о пользователе}, roles: {role: “<имя роли>”, db: “<название базы данных>”} } Как и все инструкции MongoDB, скрипт написан на языке JSON. Произвольная информация из customData необязательна, но очень желательна. Учитывая специфику применения noSQL модели хранения данных, пользователей у базы может быть очень много, и дополнительная поясняющая информация может существенно облегчить труд администратора. Далее, приведем встроенные (built-in) роли, которые можно использовать в скрипте создания пользователя. read – дает возможность считывать данные из всех несистемных коллекций и коллекции system.js (содержит специальный Java Script код, используемый в приложениях баз данных); readWrite – все полномочия роли read, а также возможность изменения данных во всех несистемных коллекциях и коллекциях system.js; dbAdmin – дает возможность выполнения задач администрирования, таких как: перепроектирование схем базы данных, индексирование, мониторинг статистики. У этой роли нет полномочия управлять пользователями; userAdmin – дает возможность создавать и изменять роли и пользователей для указанной базы данных; dbOwner – комбинация полномочий readWrite, dbAdmin, userAdmin; Для указания распространения полномочий на все базы данных сервера используются роли: readAnyDatabase, readWriteAnyDatabase, userAdminAnyDatabase, dbAdminAnyDatabase. backup – привилегии, необходимые для осуществления резервного копирования баз данных; restore – привилегии, необходимые для осуществления восстановления баз данных из резервной копии; root – привилегии суперпользователя, доступ ко всем процедурам со всеми объектами сервера. На практике, с процедурой создания, изменения пользователей noSQL СУБД MongoDB можно ознакомиться в ходе выполнения самостоятельной работы по практическим материалам данного курса. **Вопросы для самостоятельного изучения по итогам лекции.** 1. Перечислите все возможные полномочия пользователя MS SQL Server (таблица требований к ролям). 2. Что такое CERTIFICATE и ASSYMETRIC_KEY в системе безопасности MS SQL SERVER? 3. Чем USER отличается от LOGIN в MS SQL Server? 4. Чем оператор REVOKE отличается от оператора DENY? 6.5. Тестовые задания для самопроверки. 1. Для задания предоставления разрешений пользователю в языке Transact-SQL применяются следующий оператор: А) ALLOW Б) GRANT В) REVOKE Г) DENY 2. В типовые задачи автоматизации функций администрирования не входит: А) управление репликацией данных Б) управление резервным копированием В) управление оптимизацией выполнения инструкций Г) входит все перечисленное 3. Критическими для процесса функционирования СУБД являются ошибки: А) группы 0-10 Б) группы 11-16 В) группы 17-18 Г) группы 19+ 4. Что не входит в сообщение об ошибке MS SQL SERVER? А) информация о способе решения проблемы Б) текст описания ошибки В) номер сообщения об ошибке Г) все перечисленное является частью сообщения 5. За фиксирование критических ошибок в работе СУБД MS SQL SERVER отвечает… А) журнал событий приложений Windows Б) приложение баз данных В) служба MSSQLSERVER 6. Какой из перечисленных методов не используется при аутентификации MS SQL Server А) сертификат Б) ассиметричный ключ В) цифровая подпись Г) логин Д) используются все перечисленные 7. Наивысшим из перечисленных инструкций приоритетом обладает инструкция… А) GRANT Б) DENY В) REVOKE 8. Что из перечисленного не относится к фиксированной роли БД? А) db_user Б) db_owner В) public Г) db_datereader Д) относятся все перечисленные 9. Что из перечисленного не относится к серверным ролям БД? А) sysadmin Б) setupadmin В) dbcreator Г) user Д) относятся все перечисленные