Недостатком модели DAC является то, что каждый объект должен иметь владельца, который может делать с ним все, что угодно, а также возможность передать право на чтение другим субъектам, не уведомляя при этом владельца. Данная модель уязвима перед атаками «троянским конем». В модели MAC основной упор делается на конфиденциальность, но не решена проблема изменения идентификации: уровень секретности остается неизменным. Применение данной модели ограничено тем, она основывается на уровнях безопасности, которые должны существовать в предметной области. Модель RBAC является наиболее оптимальной в использовании с базами данных, так как в ней контроль доступа осуществляется на основании выполняемых ролей. Под ролью понимается совокупность действий и обязанностей, связанных с определенным видом деятельности. Роли позволяют получить конкретным лицам доступ к ресурсам в той степени, в какой это необходимо для выполнения определенных работ.
Привилегия — минимально возможное атомарное действие пользователя, которое подпадает под действие механизма разграничения доступа. Роль — набор прав, определяющих, какими привилегиями и над какими объектами будет обладать пользователь, которому присваивается данная роль. Операция — составная часть роли, определяющая привилегию, подмножество объектов, обладающих данной привилегией, и разрешение или запрет на выполнение данного действия. Сессия — множество ролей данного пользователя в определенный промежуток времени. Одновременно может выполняться несколько сессий одного и того же пользователя. Процесс доступа состоит из следующих шагов [15, 180]: Пользователь запрашивает доступ к ресурсу посредством интерфейса. Служба аутентификации проверяет его учетные данные.
В случае отсутствия прав пользователю отправляется сообщение и доступ предоставляется. Дальше происходит проверка прав запрошенного доступа к объекту на основании присвоенной пользователю роли. В случае успеха происходит предоставление права на доступ к ресурсу, в противном случае отказ. Ролевая модель управления позволяет настроить её в том виде, в каком это требуется. Таким образом, настройка системы безопасности на основе ролевой модели контроля за доступом должна производиться в две стадии: настройка политики безопасности системы и определение прав доступа для субъектов и объектов в системе. Данное различие позволяет построить на основе ролевой модели и дискреционную модель безопасности, и модель обязательного контроля.
3.6. Языковые средства разграничения доступом
В перечне базовых инструкций языка SQL представлены инструкции GRANT и REVOKE, предоставляющие или отменяющие привилегии пользователям. В большинстве случаев право подачи команд GRANTи REVOKEпоконкретному объекту автоматически имеют пользователи, создавшие данный объект, т. е. их владельцы. В других подходах этим правом наделяются доверенные субъекты, т. е. администраторы. Использование техники представленийявляется распространенным технологическим приемом формирования для конкретного пользователя своего «видения» базы. «Представлением» называется глобальный авторизованный запрос на выборку данных, формирующий для пользователя «свое» представление определенного объекта (объектов), совокупность которых формирует некую виртуальную базу данных, со своей схемой (объектами) и данными (отобранными или специально преобразованными). При входе пользователя в систему в процессе его идентификации и аутентификации ядро безопасности отыскивает для пользователя соответствующие представления-запросы и передает запрос основному ядру СУБД для выполнения. В результате выполнения запроса пользователь «видит» и имеет доступ только к тем объектам, которые соответствуют его полномочиям и функциям. Такой подход является более грубым по сравнению с применением инструкции GRANT непосредственно к объектам базы данных, т.к. не обеспечивает расщепления установок доступа к объектам на уровне отдельных операций (SELECT, INSERT, UPDAТЕ, DELETE).Поэтому другим подходом являются специальные расширения языка SQL, основанные на событийно-процедурной идеологии с введением специальных правил (RULE) безопасности.
Введение
правил безопасности обеспечивает более широкие и гибкие возможности реализации различных политик безопасности с большей степенью контроля и управляемости. Привилегии предоставляются с помощью предложения GRANT (предоставить)Общий формат: GRANT привилегии ON объект TO пользователи;" привилегии" - список, состоящий из одной или нескольких привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все привилегии); «объект» — имя и тип объекта (база данных, таблица, представление, индекс и т. п.);" пользователи" - список, включающий один или более идентификаторов санкционирования, разделенных запятыми, либо специальное ключевое слово PUBLIC (общедоступный).К таблицам (представлениям) относятся привилегии SELECT, DELETE, INSERT и UPDATE [(столбцы)], позволяющие соответственно считывать (выполнять любые операции, в которых используется SELECT), удалять, добавлять или изменять строки указанной таблицы (изменение можно ограничить конкретными столбцами). Например, предложениеGRANTSELECT, UPDATE (Столбец) ONТаблицаTOvvv; позволяет пользователю, который представился системе идентификатором vvv, использовать информацию из таблицы Таблица, но изменять в ней он может только значения столбца Столбец.
3.7. Протоколирование и аудит событий безопасности
Протоколирование и аудит являются важным средством обеспечения управляемости состоянием и процессами безопасности, создают условия для расследования фактов нарушения информационной безопасности, анализа и исключения их причин, снижения отрицательных последствий и ущерба от них. Документированиюподлежат все события, критичные с точки зрения безопасности в системе:
вход/выход пользователей;
регистрация новых пользователей, смена привилегий и назначений доступа (все обращения к массивам учетных записей);все операции с файлами (создание, удаление, переименование, копирование, открытие, закрытие);обращения к удаленной системе. Аудит безопасностизаключается в контроле и отслеживании событий в системе с целью выявления, своевременного обнаружения проблем или нарушений безопасности и сигнализации об этом. 3.
8. Решение задачи администрирования и безопасности на примере СУБДMSSQLServerMS SQL Server хранит данные в базах данных с реляционной моделью. На физическом уровне БД состоит из двух или более файлов. Физическая структура видна администраторам БД. На логическом уровне БД состоит изследующих компонентов — таблиц, представлений и хранимых процедур. Прирешение вопроса о разворачивании сервера БД необходимо решить вопросы защиты данных и установить определенную политику безопасности доступа к объектам базы данных для пользователей и администраторов системы. MS SQL Server позволяет обеспечить защиту информации в БД и разграничить доступ на основе ролевой политики безопасности. SQL Server поддерживает два режима проверки подлинности:
проверка подлинности средствами Windows. Если пользователь прошел проверку подлинности вдомене и является зарегистрированнымпользователем, то операционная система предлагает экземпляру SQL Server доверять результатам этойпроверки и предоставлять доступ на основании иуказанных имени и пароля. Для подтверждения подлинности в операционную систему передается билет Kerberos. SQL Server проверяет полученный билет ипредоставляет или отказывает в доступе.
проверка подлинности средствами SQL Server. При использовании проверки подлинности средствами SQL Server пользователь передает серверу свои имя и пароль. При проверке имени SQL Server сравнивает переданное имя со списком зарегистрированных пользователей, далее зашифровывает пароль и сравнивает с зашифрованным паролем в таблице. Выбор проверки подлинности выбирается при установке SQLServer/ Смена режима проверки может быть выполнена при помощи SQLServerManagementStudio (рисунок 8) .Рисунок 8 — Установка режима подлинности
Пользователь может выполнять операции с данными или административные задачи только с теми БД, для которых ему предоставлены соответствующие разрешения доступа (permissions).Для группового управления доступом пользователей к объектам сервера БД или отдельной БД применяется ролевая модель. Пользователь входит в число участников одной илинескольких ролей. Для участников роли устанавливается наборразрешений на уровне сервера или отдельной БД. SQL Server имеет несколько предопределенныхролей уровня сервера, обладающих правамиадминистрирования. Данные роли не могут быть удалены или изменены ихправа. Чтобы предоставить данные права пользователю, необходимо добивать его учетную запись в составроли сервера. На рисунке 9 приведены роли уровня сервера. Рисунок 9 — Роли уровня сервера
Создадим тестовую БД. Создать БД можно либо через SQLManagementStudio, либо через SQL. Чтобысоздатьновуюбазу переходим
Пуск>Программы>MS SQL Server>Среда SQL Server Management Studio. Далее становимся на «Базы данных», щелкаем правой кнопкой мыши и выбираем «Создать базу данных» (рисунок 10). Рисунок 10 — Создание базы данных в MSSQLServerManagementStudioБД будет называться Test_adm. В поле «Путь» указывается местоположение БД, отличное от стандартного (рисунок 11).Рисунок 11 — Указание месторасположения файлов БДДалее жмем «ОК» и видим в списке созданную БД (рисунок 12).Рисунок 12 — Созданная БДБД можно также создать используя язык T-SQL.CREATEDATABASE [Test_adm] CONTAINMENT =NONEONPRIMARY (NAME =N'Test_adm', FILENAME=N'C:Program FilesMicrosoftSQL ServerMSSQL12. SQLEXPRESS14MSSQLDATATest_adm.mdf', SIZE = 5120KB, MAXSIZE =UNLIMITED, FILEGROWTH = 1024KB) LOGON (NAME=N'Test_adm_log', FILENAME=N'C:Program FilesMicrosoft SQL ServerMSSQL12. SQLEXPRESS14MSSQLDATATest_adm_log.ldf', SIZE = 1024KB, MAXSIZE = 2048GB, FILEGROWTH = 10%)GOДалее создадим две связанные таблицы: Sotrudnikи Dolzhnost (рисунок 13).Рисунок 13 — Создание таблиц
Для сохранения введённой информации о структуре таблицы щелкаем правой кнопкой по ярлыку с именем таблицы по умолчанию и вводим имя таблицы. Аналогично вводим таблицу должностей. Рисунок 13 — Создание таблиц (продолжение)Создадим связь между таблицами по полю JobId, используя T-SQL.ALTER table dbo. SotrudnikiADD CONSTRAINT FK_Temp_SotrudnikiJob FOREIGN KEY (JobId) REFERENCES dbo. Job_Title (JobId) ON DELETE CASCADEONUPDATECASCADE;GOПосле создания таблиц и БД сохраним созданную БД (рисунок 14).Рисунок 14 — Создание резервной копии БДРисунок 14 — Создание резервной копии БД (продолжение)Для получения сведений об участникахсерверной роли используется системное представление: sys. server_role_membersДля добавления существующего логина в число участников роли используется системная хранимая процедура:▫ EXECUTE sp_addsrvrolemember login, fix_server_role.Для удаления пользователя из числа участниковроли: EXECUTE sp_dropsrvrolemember login, fix_server_role.При подключении к SQL Server автоматически непредоставляется право доступа к БД. Кроме участников роли sysadmin никто не имеет прав на уровне БД. Для работы с БД необходимо предоставление специальных прав (разрешений) на уровне БД. Разрешение можно предоставлять (grant), блокировать (deny) и отзывать (revoke).К разрешениям уровня БД относятся:
разрешение на создание объектов;
администрирование БД;выполнение операторов T-SQL;вставка и изменение данных в таблицы;
просмотр данных. Для предоставления доступа к БД необходимо создать учетную записьпользователя БД и связать с логином на уровне сервера БД: CREATE USER user_name FOR LOGIN login_nameДля создания учетной записи можно воспользоваться мастером средствами ManagementStudioилиоператорамиT-SQL. На рисунке 15 показан процесс создания учетной записи. Рисунок 15 — Создание новой учетной записи
Для создания пользовательской роли необходимо выбрать БД, раскрыть список объектов и выбрать объект Roles (рисунок 16).Рисунок 16 — Создание роли
Для создания пользовательской роли базы данных, указываем базу данных и используемуюсхему. USE TSQLDB;CREATE USER NewUser FOR LOGIN NewLogin WITH DEFAULT_SCHEMA=db_datawriter; GOНа рисунке 17 показана установка разрешений на объекты БД. Рисунок 17 — Установка разрешений на объекты
Для установки разрешений можно воспользоваться оператором T-SQLGRANT SELECT ON OBJECT: dbo. CustomerAddress TO NewUser;Для отзыва доступа применяется операторREVOKE SELECT ON OBJECT: dbo. CustomerAddress TO NewUser;В главе исследованы источники угроз безопасности БД, определены составляющие, определяющие качество защиты данных. Исследованы механизмы, которые применяются в СУБД для обеспечения безопасности хранимых данных, показаны преимущества использования ролевого управления доступом, приведены примеры практического решения задач администрирования и обеспечения безопасности данных.
ЗАКЛЮЧЕНИЕ
Проведенное исследование, посвященное вопросам администрирования и обеспечения безопасности БД позволило решить все поставленные задачи. Для этого:
Был проведен анализ структуры современных СУБД, концепции построения, приведена классификация БД по основным признакам. Проанализированы задачи, стоящие перед администраторами баз данных, выявлены узкие места, влияющие на эксплуатационные характеристики систем управления базами данных, проведено исследование средств мониторинга и аудита. Рассмотрены механизмы обеспечения безопасности баз данных, модели управления доступом по отношению к базам данных, показаны достоинства выбора именно ролевой модели. На практическом примере показан механизм обеспечения процессов администрирования и обеспечения безопасности в БД. В условиях повсеместного применения информационных технологий, роста компьютерных преступлений обеспечение безопасности конфиденциальной информации становится критически важным. Исходя из проведенного исследования, можно рекомендовать назначить отдельного сотрудника, занимающегося исключительно обеспечением безопасности баз данных, так как у администратора БД может не хватить времени для выполнения работ по обеспечению безопасности. Также следует максимально ограничить использование настроек по умолчанию и обеспечить надежное хранение протоколов работы. При передаче информации по сети рекомендуется шифровать передаваемую информацию. Для эффективного построения системы защиты администратору, отвечающему за безопасность необходимо:
выделить уязвимые элементы системы;
выявить угрозы для выделенных элементов;
сформировать требования к системе защиты; выбрать методы и средства удовлетворения предъявленным требованиям. СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫКонституция Российской Федерации (с изменениями от 21.
07.2014). [Электронный документ]. URL:
http://dogovor-urist.ru/законы/конституция_рф/Гражданский кодекс РФ//Справочно-поисковая система «Гарант». [Электронный документ]. URL:
http://base.garant.ru/10 164 072/Уголовный кодекс РФ (редакция 02.
03.2015) // Справочно-поисковая система «Консультант Плюс». [Электронный документ]. URL:
http://www.consultant.ru/document/cons_doc_LAW_174 910/Федеральный закон от 27 июля 2006 г. N 152-ФЗ «О персональных данных» (с изменениями и дополнениями)// //Справочно-поисковая система «Гарант». [Электронный документ]. URL:
http://base.garant.ru/12 148 567/#ixzz3VlKQniskФедеральный закон от 27 июля 2006 г. N 149-ФЗ «Об информации, информационных технологиях и о защите информации» (с изменениями и дополнениями)// //Справочно-поисковая система «Гарант». [Электронный документ]. URL:
http://base.garant.ru/12 148 555/#helpЛитература на русском языке
Полякова Л. Н. Основы SQL. М.: Интуит. — 2008. — 161 с. Хомоненко
А.Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учебник для высших учебных заведений./ под ред. проф. Хоменко А. Д. — 6-е изд. -C Пб.: КОРОНА-Век, 2009. — 736 сПрограммы для ЭВМ: базы данных топологии интегральных микросхем: официальный бюллетень Федеральной службы по интеллектуальной собственности, патентам и товарным знакам;[отв.
ред. И.В. Коробко]. — М.: ФГУ ФИПС, 2009. — 267 с. Тиори Т., Фрай Дж. Проектирование структур баз данных: в 2 кн. Кн.
1. Пер. с англ. — Мир, 1985. -
287 с., ил. Кириллов В. В.
Введение
в реляционные базы данных. СПб.: БХВ-Петербург, 2009. — 464 с.: ил. + CD-ROM Тарасов С.
СУБД для программиста. Базы данных изнутри. Солон-пресс, -2015. — 320 с. Фуфае Э. В. Базы данных: учеб. пособие для студ.
Учреждений. — 7-е изд., М.: издательский центр «Академия», 2012. — 320 с. Беленькая М. Н., Малиновский С. Т. Администрирование в информационных системах. Учебное пособие для вузов. — М.: Горячая линия — Телеком., 2011.
— 400 с., ил. Конолли, Брег Т., Каролин. Базы данных. Проектирования, реализация и сопровождение. Теория и практика. 3-е изд.
— М.: Вильямс, 2003. — 1440 с., ил.
Иртегов Д.В.
Введение
в операционные системы: учеб.
пособие для студ. высш. учебн. заведений. СПб.: БХВ-Петербург, 2008
Голиков С.Е., Серова-Нашева Н. В. Выбор модели управления доступом систем автоматизации банковской деятельности.// Сборник научных трудов Севастопольского национального университета ядерной энергии и промышленности. № 4(48). Севастополь, 2013. — с. 177 — 185.
Литература
на иностранном языкеJack Show.
D igital Jungle, and doing business in the Information Age. Электронныйресурс]. Режим доступа:
http://wowspeakers.com/2014/02/jack-shaw/ (дата обращения 28марта 2015 г.).Электронные ресурсы
Информационные системы и базы данных. [Электронныйресурс]. URL:
http://www.myshared.ru/slide/529 370/ (дата обращения 28марта 2015 г.).Словарь терминов. [Электронныйресурс]. URL:
http://articles.org.ru/cn/showdetail.php?cid=6820(дата обращения 28марта 2015 г.).Основные концепции СУБД. [Электронныйресурс]. URL:
http://www.myshared.ru/slide/666 372/(дата обращения 28марта 2015 г.).Трехуровневая архитектура. [Электронныйресурс]. URL:
http://www.myshared.ru/slide/166 052/(дата обращения 28марта 2015 г.).Классификация баз данных: [Электронныйресурс]. URL:
http://www.myshared.ru/slide/339 051/(дата обращения 28марта 2015 г.).Администрирование баз данных. [Электронныйресурс]. URL:
http://edu.mmcs.sfedu.ru/pluginfile.php/13 142/mod_resource/content/Лекция8.pdf (дата обращения 28марта 2015 г.).Амелин Р. В. Информационная безопасность. [Электронныйресурс]. URL:
http://nto.immpu.sgu.ru/sites/default/files/3/__77 037.pdf (дата обращения 28марта 2015 г.).Приложение 1Связь программ и данных при использовании СУБД
