3.3.7 Запросы к базе данных

В шестом подразделе практической части курсового проекта по дисциплине «Управление данными» следует привести не менее 10 запросов всех типов, реализуемых средствами СУБД и средствами языка SQL. Составить запросы с коррелированными и некоррелированными подзапросами. Предварительно они должны быть сформулированы на естественном языке и выражены в терминах реляционной алгебры или реляционного исчисления. Примеры возможных запросов к базе данных и способы их реализации приведены в приложении 3.

3.3.8 Разработка механизмов защиты данных от несанкционированного доступа

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

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

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

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

Для управления доступа к объектам дискреционный контроль доступа использует идентификационную информацию объекта и список доступа, который содержит субъекты и ассоциированные с ними типы доступа. Во время запроса доступа к объекту, система производит поиск субъекта в списке прав доступа объекта, и, в случае, если субъект там присутствует и разрешённый тип доступа включает требуемый тип, разрешает доступ. В противном случае запрещает доступ.

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

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

Различают закрытую и открытую систему дискреционного контроля. Под закрытой системой понимается такая система, в которой изначально объект никому не доступен и список разрешений описывается в списке прав доступа, а открытая – та, в которой к объектам все имеют полный доступ, а в списке доступа описывается список ограничений.

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

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

Однако в такой модели существуют два момента, ставящие под вопрос её непротиворечивость.

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

2. Пользователи с более высоким уровнем не могут изменять объекты с более низки уровнем. Этот недостаток можно устранить, позволив пользователю при доступе к объектам выступать от имени субъектов с различными уровнями.

Часто, кроме обеспечения безопасности, также требуется обеспечение её достоверности. Чем выше уровень доверия объекта, тем выше его достоверность. Чем выше уровень безопасности субъекта, тем достовернее информация, которую он вносит в систему. Для такой модели описанные выше правила должны быть изменены: доступ на запись даётся в случае, если уровень безопасности субъекта включает в себя уровень безопасности объекта, а доступ чтение даётся в случае, если уровень безопасности субъекта включается в уровень безопасности объекта. То есть критерии просто поменялись местами.

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

В классических моделях разграничения доступа права на выполнение определённых операций над объектом должны быть прописаны для каждого пользователя или группы пользователей. Благодаря разделению понятий «роль» и «пользователь», можно разбить задачу на две части: определение роли пользователя и определение прав доступа к объекту для роли. Такой подход позволяет упростить процесс администрирования, так как при изменении области ответственности пользователя, требуется лишь убрать у него старые роли и назначить новые, соответствующие его текущим обязанностям. Эта же процедура потребует массу усилий при переназначении новых прав, если права доступа определялись напрямую между пользователями и объектами.

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

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

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

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

Модель состоит из сущностей пользователя, роли и привилегии, где пользователь – человек либо программа запущенная им, роль – вид деятельности человека в организации, а привилегия – разрешение доступа к объектам системы. У пользователя может быть несколько ролей, а одна роль может принадлежать нескольким пользователям. Также и несколько привилегий могут принадлежать одной роли, а несколько ролей – иметь одну привилегию.

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

В проектируемой базе данных «Прокат» можно рассматривать следующие механизмы доступа как к базе данных целиком, так к ее компонентам:

- парольная защита:

- разграничение прав пользователей (ролевая защита).

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

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