Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

Выпускная квалификационная работа

Управление доступом к ресурсам баз данных Microsoft Structured Query Language Server



Оглавление

Введение

1. Управление доступом к данным

1.1 Идентификация и аутентификация пользователей

1.2 Авторизация пользователей

1.3 Дискреционное разграничение доступа

1.4 Мандатное разграничение доступа

1.5 Ролевое разграничение доступа

2. Архитектура системы безопасности SQL Server

2.1 Система безопасности уровня сервера

2.1.1 Аутентификация Windows

2.1.2 Аутентификация SQL Server

2.2 Система безопасности уровня базы данных

3. Реализация базы данных

3.1 Инструментарий разработки БД

3.2 Создание базы данных

3.2.1 Описание предметной области

3.2.2 Проектирование реляционной базы данных

3.2.3 Инфологическая модель базы данных

3.2.4 Описание связей

3.2.5 Даталогичеcкое проектирование БД

3.2.6 Запроcы к БД



Введение

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

База данных - это, прежде всего, хранилище объектов данных, т.е. набора возможных понятий или событий, описываемых базой данных. Вместе с этим основными функциями БД являются систематизация информации (знаний) и возможность взаимосвязи объектов между собой.

Современные СУБД, в основном, являются приложениями Windows, так как данная среда позволяет более полно использовать возможности персональной ЭВМ, нежели среда DOS. Снижение стоимости высокопроизводительных ПК обусловило не только широкий переход к среде Windows, где разработчик программного обеспечения может в меньше степени заботиться о распределении ресурсов, но также сделало программное обеспечение ПК в целом, и СУБД в частности, менее критичными к аппаратным ресурсам ЭВМ. Среди наиболее ярких представителей систем управления базами данных можно отметить: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а также баз данных Microsoft SQL Server и Oracle, используемые в приложениях, построенных по технологии "клиент-сервер".

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

В связи с этим была определена цель данной выпускной квалификационной работы - реализация и настройка доступа к базе данных.

Для достижения поставленной цели требуется выполнить такие задачи как:

- физическая реализация базы данных;

- создание различных профилей входа при помощи проверки подлинности SQL Server;

- сравнение типов соединения с сервером БД (проверка подлинности SQL Server/проверка подлинности Windows);

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



1. Управление доступом к данным

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

· предприятие является собственником всей служебной информации, полученной его подразделениями или служащими;

· подразделение или служащий является владельцем полученной им информации и может использовать её в интересах предприятия без ограничений;

· служащий имеет право доступа к тем и только тем сведениям, которые необходимы для исполнения его служебных обязанностей;

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

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

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

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

Исходя из вышесказанного, сформулируем термин «управление доступом» более детально. Управление доступом есть метод защиты информации путем регулирования использования ресурсов системы (элементов БД, программных и технических средств). Включает следующие функции защиты:

· идентификация пользователей и ресурсов системы;

· установление подлинности объекта или субъекта по предъявленному им идентификатору (аутентификация);

· разграничение и проверка полномочий (авторизация). Создание условий работы в пределах установленного регламента;

· регистрация обращений к защищаемым ресурсам (протоколирование и аудит);

· реагирование при попытках несанкционированного доступа.

1.1 Идентификация и аутентификация пользователей

Для того чтобы получить доступ к БД, пользователь должен указать свой идентификатор (ID) и подтвердить право на его использование. Опознав пользователя, система готова выполнять операции над данными от его имени. В зависимости от требуемой степени защищённости системы могут использоваться различные процедуры установления личности пользователя. Приведем простейшие и наиболее часто используемые программные процедуры аутентификации, не связанные с анализом «почерка» пользователя:

Парольная защита. В простейшем варианте с ID связывается пароль - известный только владельцу ID и системе набор символов (секрет). Минимальный набор полномочий владельца ID в этом варианте включает права входа в систему и изменения своего пароля. Ни один пользователь (включая администратора системы) не имеет права просмотра паролей. Пароли хранятся в виде хэш-кода или в зашифрованном виде.

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

Защита "вопрос-ответ". Более сложный вариант защиты входа может быть таким. Владелец ID вводит при регистрации серию вопросов вместе с ответами. Вопросы имеют личный характер, поэтому правильные ответы на них невозможно угадать. Например: "Кличка вашей первой собаки?", "Где родилась Ваша мама?" и т.п. Для установления личности пользователя при попытке входа система предъявляет ему случайно выбранный вопрос(ы) из этой серии.

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

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

· получатель должен быть уверен в подлинности источника данных;

· получатель должен быть уверен в подлинности передаваемых данных;

· отправитель должен быть уверен в доставке данных получателю;

· отправитель должен быть уверен в подлинности доставленных данных.

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

Информация о зарегистрированных пользователях БД хранится в ее системном каталоге. Современные СУБД не имеют общего синтаксиса SQL-предложения соединения с базой данных, так как их собственный синтаксис сложился раньше, чем стандарт ISO. Наиболее часто употребляется предложение CONNECT.

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

1.2 Авторизация пользователей

Авторизация пользователей заключается в предоставлении определенных прав, позволяющих их владельцу иметь законный доступ как к самой системе, так и к ее отдельным объектам. Все субъекты доступа могут быть разделены для системы на ряд категорий, например: CONNECT, RESOURCE и DBA. Набор таких категорий определяется производителем СУБД. Нарастание возможностей (полномочий) для каждого отдельного вида подключения происходит в указанном порядке:

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

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

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

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

Администратор каждой БД занимается созданием списка возможных пользователей БД и разграничением полномочий этих пользователей.

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

В настоящее время наиболее часто используется три основных подхода к разграничению доступа: избирательный, обязательный и ролевой. Избирательный подход описывается дискреционной моделью разграничения доступа, Discretionary Access Control (DAC), обязательный или полномочный - мандатной моделью разграничения доступа, Mandatory Access Control (MAC). Оба обеспечивают создание системы безопасности как для БД в целом, так и для отдельных её объектов - таблиц, представлений, кортежей и т.д. вплоть до конкретного значения некоторого атрибута в определенном кортеже определенного отношения. Ролевая модель разграничения доступа, Role Based Access Control (RBAC) является в некотором смысле комбинацией вышеуказанных моделей. Следует упомянуть также и модель Китайской стены, заключающаяся в возведении физического барьера между БД и группой авторизованных лиц, и остальным миром.

1.3 Дискреционное разграничение доступа

Избирательный подход, описываемый дискреционной моделью разграничения доступа, является наиболее простым одноуровневым подходом к обеспечению безопасности. Основными его понятиями являются:

· субъект - системный идентификатор, от имени которого СУБД выполняет определенные действия над определенными объектами. Понятие субъекта отличается от понятия пользователь компьютерной системы, поскольку инициировать изменение информации могут также и системные процессы;

· объект защиты - часть БД, на которую распространяется действие конкретного правила безопасности; это может быть группа отношений, отдельное отношение, подмножества атрибутов и т.д.;

· привилегия - действие над объектом защиты, которое может быть совершено от имени конкретного идентификатора.

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

1. Системные привилегии - права на создание и модификацию объектов БД (пользователей, именованных отношений, правил и т.п.);

2. Объектные привилегии - права на использование объектов в операциях манипулирования данными.

Дискреционная модель разграничения доступа основывается на следующих основных положениях:

1. Все субъекты и объекты должны быть однозначно идентифицированы;

2. Для любого объекта должен быть определен пользователь- владелец;

3. Владелец объекта обладает правом определения прав доступа к объекту со стороны любых субъектов;

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

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

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

Дискреционное разграничение доступа реализуется на основе множества разрешенных отношений доступа в виде троек - «субъект доступа - тип доступа - объект доступа». Наглядным и распространенным способом формализованного представления дискреционного доступа является матрица доступа, устанавливающая перечень пользователей и перечень разрешенных операций (процессов) по отношению к каждому объекту базы данных (таблицы, запросы, формы, отчеты). В таблице 1 приведен пример, иллюстрирующий матрицу доступа. Данное представление является схематичным, поскольку в реляционных БД вследствие требования первой нормальной формы для каждого типа доступа некоторого субъекта к некоторому объекту отводится отдельная запись.

Таблица 1. Модель безопасности на основе матрицы доступа

Объекты Субъекты	Клиенты	Товары	Заказы
Хурсинов	чтение, вставка, модификация	чтение, вставка, модификация	чтение, вставка, модификация
Барсагов	чтение, вставка	чтение	чтение
Кештов	чтение	чтение

В рамках дискреционной модели существует два подхода управления доступом:

· добровольное управление доступом;

· принудительное управление доступом.

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

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

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

Некоторыми объектами в среде СУБД владеет сама СУБД. Обычно это владение организуется посредством использования специального идентификатора особого суперпользователя - например, с именем system administrator (sa).

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

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

Модель Харрисона-Руззо-Ульмана:

Математической формализацией дискреционной модели является разработанная в 1971 г. модель Харрисона-Руззо-Ульмана. В данной модели дополнительно к субъектам S, объектам O (причем для того, чтобы включить в область действия модели и отношения между субъектами, принято считать, что все субъекты одновременно являются и объектами, S ? O ) и правами доступа R, определяющим матрицу доступа M, вводится также пространство состояний системы Q. Пространство состояний системы образуется декартовым произведением множеств составляющих ее объектов, субъектов и прав S ґ O ґ R. Любая ячейка матрицы M содержит набор прав субъекта S к объекту O, принадлежащих множеству прав доступа R. Поведение системы во времени моделируется переходами между различными её состояниями. Для заданной системы начальное состояние Q0 = {S0, O0, M0}, где M0 - текущее состояние матрицы доступа, называется безопасным относительно права r, если не существует применимой к Q0 последовательности команд, в результате выполнения которых право r будет занесено в ячейку матрицы M, в которой оно отсутствовало в состоянии Q0. Другими словами это означает, что субъект никогда не получит право доступа r к объекту, если он не имел его изначально. Если же право r оказалось в ячейке матрицы M, в которой оно изначально отсутствовало, то говорят, что произошла утечка права r.

Очевидно, что для каждого субъекта S, активизированного в момент времени t, существует единственный субъект S', который активировал (создал) некоторое право доступа r для субъекта S. Поэтому посредством анализа графа отношений между субъектами и объектами можно выявить единственного пользователя, от имени которого активизировано исследуемое право субъекта S. Соответственно, для любого объекта существует единственный пользователь, создавший данный объект и сформировавший для него список прав доступа. В этом случае схематичное изображение канала утечки в виде разрешенного доступа от имени разных пользователей к одному и тому же объекту будет выглядеть следующим образом: S_i -> (Запись в момент времени t₁) -> O и S_j -> (Чтение в момент времени t₂) -> O, где i?j и t₁ < t_2. Фактически это означает, что ничто не мешает легальному пользователю (например, вследствие программной ошибки) перебросить секретную информацию во вновь созданный объект, доступ к которому открыт всем желающим, или организовать скрытый канал утечки при помощи «троянского» коня. Главным недостатком модели является то, что в ней контролируются только операции доступа субъектов к объектам, а не потоки информации между ними. Поэтому, когда «троянская» программа переносит информацию из доступного некоторому пользователю объекта в объект, доступный нарушителю, то формально никакое правило дискреционной политики безопасности не нарушается, но утечка информации происходит.

Рассмотрим еще один пример утечки права. Пусть в начальном состоянии в системе имеются объект O и два субъекта: S и T; S не обладает никаким правом по отношению к O, а T обладает некоторым правом a по отношению к O. Сформулируем последовательность шагов, показывающих, как субъект S может получить право доступа a по отношению к субъекту O:

1) Начальное состояние;

2) Субъект S создаёт новый объект X, по отношению к которому автоматически получает права чтения и записи (потому что при создании объекта он становиться владельцем объекта);

3) Субъект S передаёт субъекту T права чтения и записи по отношению к X;

4) Субъект T копирует часть или все записи объекта O в объект X;

5) Субъект S, имея полные права доступа к X, получает право доступа к скопированным данным, что означает фактический перенос права a по отношению к O от субъекта T к субъекту S.

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

Теорема 1. Проблема безопасности разрешима для моно-условных систем, т.е. запросы которых содержат одну примитивную операцию во фразе WHERE;

Теорема 2. Проблема безопасности не разрешима в общем случае.

В 1976 году Харрисон, Руззо и Ульман доказали, что в самом общем случае вопрос определения безопасности компьютерной системы неразрешим. Иными словами, не существует алгоритма, позволяющего определить, будет ли компьютерная система безопасна или небезопасна в общем случае (т.е. задача определения того, является ли исходное состояние системы безопасным для данного права r, является вычислительно неразрешимой). Однако в частных случаях проблема безопасности решается, а именно, авторы показали, что безопасными являются монотонные системы (не содержащие операции DROP и DELETE), системы, не содержащие операций CREATE, и моно-условные системы (запрос к которым содержит только одно условие).

Для оценки безопасности системы также широко используется модель Take-Grant. В качестве основных элементов модели используются граф доступа и правила его преобразования. В модели доминируют два правила: "давать" и "брать". Они играют в ней особую роль, переписывая правила, описывающие допустимые пути изменения графа. В общей сложности существует 4 правила преобразования: правило «брать», правило «давать», правило «создать» и правило «удалить». Используя эти правила, можно воспроизвести состояния, в которых будет находиться система в зависимости от распределения и изменения прав доступа. Следовательно, можно проанализировать возможные угрозы для данной системы.

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

1. Ни один запрос на доступ субъекта к объекту не должен выполняться в обход монитора;

2. Работа монитора должна быть защищена от постороннего вмешательства;

3. Представление монитора должно быть достаточно простым для возможности верификации корректности его работы.

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

Операторы SQL предоставления и отмены привилегий:

В стандарте SQL определены два оператора GRANT и REVOKE для предоставления и отмены привилегий соответственно.

Оператор предоставления привилегий имеет следующий формат:

GRANT {<список действий>|ALL PRIVILEGES} ON <имя объекта> TO {<список пользователей>|PUBLIC} [WITH GRANT OPTION]

где <список действий> определяет набор действий из доступного списка действий над объектом данного типа (параметр ALL PRIVILEGES указывает, что разрешены все действия, допустимые для объектов данного типа), <имя объекта> определяет имя объекта защиты: таблицы, представления, хранимой процедуры или триггера, <список пользователей> определяет список идентификаторов пользователей, кому предоставляются данные привилегии. Вместо списка идентификаторов можно воспользоваться параметром PUBLIC. Параметр WITH GRANT OPTION является необязательным и определяет режим, при котором передаются не только права на указанные действия, но и право передавать эти права другим пользователям. Передавать права в этом случае пользователь может только в рамках разрешенных ему действий. В общем случае набор привилегий зависит от реализации СУБД (определяется производителем). Выделяются привилегии манипулирования данными:

SELECT - просматривать данные;

INSERT [(<список полей>)] - добавлять данные; UPDATE [(<список полей>)] - обновлять данные; DELETE - удалять данные;

REFERENCES [(<список полей>)] - ссылаться на указанные поля при определении ссылочной целостности;

USAGE - использовать домены и ограничители целостности; EXECUTE - выполнять сохраненные процедуры и функции.

Среди привилегии создания/изменения объектов БД выделим наиболее часто используемые:

CREATE <тип объекта> - создание объекта некоторого типа; ALTER <тип объекта> - изменение структуры объекта; DROP <тип объекта> - удаление объекта;

ALL - все возможные действия над объектом.

В реализациях могут присутствовать и другие разновидности привилегий:

CONTROL (IBM DB2) - комплексная привилегия управления структурой таблицы;

RUNSTAT -- выполнение сбора статистической информации по таблице и другие.

Рассмотрим пример: пусть у нас существуют три пользователя с уникальными именами User1, User2 и User3. Все они являются пользователями одной БД. User1 создал объект Tab1, он является владельцем этого объекта и может передать права на работу с этим объектом другим пользователям. Допустим, что пользователь User2 является оператором, который должен вводить данные в Tab1 (например, таблицу новых заказов), а пользователь User3 является менеджером отдела, который должен регулярно просматривать введенные данные. Тогда логично будет выполнить следующие назначения:

GRANT INSERT ON Tab1 TO User2

(или GRANT INSERT, DELETE, UPDATE ON Tab1 TO User2) GRANT SELECT ON Tab1 TO User3

Эти назначения означают, что пользователь User2 имеет право только вводить новые строки в отношение Tab1, а пользователь User3 имеет право просматривать все строки в таблице Tab1. При назначении прав доступа на операцию модификации можно уточнить, значение каких полей может изменять пользователь. Допустим, что менеджер отдела имеет право изменять цену на предоставляемые услуги, задаваемую в поле COST отношения Tab1. Тогда операция назначения привилегий пользователю User3 может измениться и выглядеть следующим образом:

GRANT SELECT, UPDATE(COST) ON Tab1 TO User3

Если пользователь User1 предполагает, что пользователь User4 может его замещать в случае его отсутствия, то он может предоставить этому пользователю все права по работе с созданной таблицей Tab1.

GRANT ALL PRIVILEGES ON Tab1 TO User4 WITH GRANT OPTION

В этом случае пользователь User4 может сам назначать привилегии по работе с таблицей Tab1 в отсутствие владельца объекта пользователя User1. Поэтому в случае появления нового оператора пользователя User5 он может назначить ему права на ввод новых строк в таблицу командой

GRANT INSERT ON Tab1 TO User5

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

GRANT SELECT, UPDATE, DELETE ON Tab1 TO user4 WITH GRANT OPTION

то пользователь User4 не сможет передать полномочия на ввод данных пользователю User5, потому что эта операция не входит в список разрешенных для него самого.

Для отмены ранее назначенных привилегий в стандарте SQL определен оператор REVOKE. Оператор отмены привилегий имеет следующий синтаксис:

REVOKE {<список действий>|ALL PRIVILEGES} ON <имя объекта> FROM {<список пользователей>|PUBLIC} {CASCADE|RESTRICT}

Параметры CASCADE или RESTRICT определяют, каким образом должна производиться отмена привилегий. Параметр CASCADE отменяет привилегии не только пользователя, который непосредственно упоминался в операторе GRANT при предоставлении ему привилегий, но и всем пользователям, которым этот пользователь присвоил привилегии, воспользовавшись параметром WITH GRANT OPTION. Например, при использовании операции:

REVOKE ALL PRIVILEGES ON Tab1 FROM User4 CASCADE

будут отменены привилегии и пользователя User5, которому пользователь User4 успел присвоить привилегии. Параметр RESTRICT ограничивает отмену привилегий только пользователю, непосредственно упомянутому в операторе REVOKE. Но при наличии делегированных привилегий при выполнении инструкции REVOKE возникнет ошибка. Так, например, операция:

REVOKE ALL PRIVILEGES ON Tab1 FROM User4 RESTRICT

не будет выполнена, потому что пользователь User4 передал часть своих полномочий пользователю User5.

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

REVOKE INSERT ON Tab1 FROM User2, User4 CASCADE

При работе с другими объектами (например, с хранимыми процедурами) изменяется список операций, которые используются в операторах GRANT и REVOKE. По умолчанию, действие, соответствующее запуску (исполнению) хранимой процедуры, назначается всем членам группы PUBLIC. Если требуется изменить это условие, то после создания хранимой процедуры необходимо записать оператор REVOKE

REVOKE EXECUTE ON COUNT_EX FROM PUBLIC CASCADE

а затем назначить новые права определенным пользователям

GRANT EXECUTE ON COUNT_EX FROM User4

Объектные привилегии назначает администратор или владелец БД. Например, (в SQL Server):

GRANT CREATE DATABASE ON SERVER_0 TO main_user

По принципу иерархии пользователь main_user, создав свою БД, теперь может предоставить права на создание или изменение любых объектов в этой БД другим пользователям, например:

GRANT CREATE TABLE, ALTER TABLE, DROP TABLE ON MyDB TO

User1

В этом случае пользователь User1 может создавать, изменять или удалять таблицы в БД MyDB, однако он не может разрешить создавать или изменять таблицы в этой БД другим пользователям, потому что ему дано разрешение без права делегирования своих возможностей.

Достоинства и недостатки дискреционного разграничения доступа. К достоинствам дискреционного разграничения доступа относятся относительно простая реализация (проверка прав доступа субъекта к объекту производится в момент открытия этого объекта в процессе субъекта), хорошая изученность, универсальность, наглядность и гибкость. Однако дискреционная защита является довольно слабой, так как привилегии существуют отдельно от данных и доступ ограничивается только к именованным объектам, а не собственно к хранящимся данным. В случае реляционной БД объектом будет, например, именованное отношение (таблица). В этом случае нельзя в полном объеме ограничить доступ только к части информации, хранящейся в таблице. Это связано с тем, что даже если ввести отдельный атрибут, который будет хранить информацию о метке конфиденциальности документа, то средствами SQL можно будет получить выборку данных без учета атрибута данной метки. Фактически это означает, что либо сам сервер баз данных должен предоставить более высокий уровень защиты информации, либо придется реализовать данный уровень защиты информации с помощью жесткого ограничения операций, которые пользователь может выполнить посредством SQL. На некотором уровне такое разграничение можно реализовать с помощью хранимых процедур, но не полностью - в том смысле, что само ядро СУБД позволяет разорвать связь «защищаемый объект - метка конфиденциальности». Дискреционное разграничение доступа имеет ряд и других недостатков. Перечислим все недостатки дискреционной модели в виде списка:

1. Хранение привилегий доступа отдельно от данных;

2. Ограничение доступа производится на уровне именованных объектов, а не самих хранящихся данных;

3. Уязвимость по отношению к вредоносным программам вида Троянских коней. Дискреционная модель позволяет пользователям без ограничений передавать свои права другим пользователям (что и используется Троянскими конями). Нет различия между пользователем и субъектом, т.е. между человеком, кому, в конечном счете, были назначены определенные права доступа к объектам и процессам, порожденным данным пользователем. Это также позволяет Троянским коням, запущенным от имени авторизованных пользователей, получать свободный доступ к данным.

4. Статичность разграничения доступа -- права доступа к уже открытому объекту в дальнейшем не изменяются независимо от изменения состояния компьютерной системы;

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

6. Средства защиты не позволяют отследить передачу секретных материалов;

7. Возможность множественного назначения и отзыва привилегий доступа к одному и тому же объекту может привести к неконтролируемому доступу к данным. Предположим, субъект s1 предоставил определенные права доступа к объекту o1 субъекту s2. Затем субъект s3 предоставил те же привилегии к o1 все тому же субъекту s2, будучи не поставленным в известность, что это уже было сделано субъектом s1. Позднее субъект s3 изменил свое мнение и отозвал предоставленные им привилегии. Но его действие не вызвало желаемый эффект, поскольку отозванные им привилегии по-прежнему остаются в матрице доступа, поскольку они были ранее назначены субъектом s1;

8. При большом количестве пользователей трудно отследить все пути доступа.

Отмеченных недостатков во многом лишено мандатное разграничение доступа, рассматриваемое в следующем пункте.

Дискреционная модель является очень популярной у разработчиков СУБД. Она реализована в практически всех SQL-совместимых СУБД.

Операторы SQL GRANT, REVOKE, DENY, реализующие дискреционную модель разграничения доступа, определены в стандарте языка SQL.

1.4 Мандатное разграничение доступа

К основным характеристикам мандатного (обязательного) подхода разграничения доступа относятся следующие положения:

· все субъекты и объекты должны быть однозначно идентифицированы;

· имеется линейно упорядоченный набор меток конфиденциальности (секретности) и соответствующих им уровней (степеней) допуска (нулевая метка или степень соответствуют общедоступному объекту и степени допуска к работе только с общедоступными объектами), например: U - Unclassified, SU - Sensitive but unclassi- fied, S - Secret, TS - Top secret;

· каждому объекту присвоена метка конфиденциальности;

· каждому субъекту присваивается степень допуска;

· право на чтение информации из объекта получает только тот субъект, чья степень допуска не меньше метки конфиденциальности данного объекта;

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

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

Мандатный подход используется специальными (trusted) системами, предназначенными для государственных, военных и других организаций с жёсткой структурой. Основной целью мандатного разграничения доступа к объектам является предотвращение утечки информации из объектов с высокой меткой конфиденциальности в объекты с низкой меткой конфиденциальности (противодействие созданию каналов передачи информации «сверху вниз»).

Для мандатного разграничения доступа к объектам компьютерной системы формально доказано следующее важное утверждение (принципиально отличающее MAC от DAC): если начальное состояние компьютерной системы безопасно и все переходы из одного состояния системы в другое не нарушают правил разграничения доступа, то любое последующее состояние компьютерной системы также безопасно. К другим достоинствам мандатного разграничения доступа относятся:

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

· большая простота определения правил разграничения доступа по сравнению с дискреционным разграничением.

Главное отличие MAC от DAC состоит в том, что в МАС метки конфиденциальности неизменны на всем протяжении существования объекта защиты (они создаются и уничтожаются только вместе с ним) и располагаются вместе с защищаемыми данными, а не в системном каталоге, как это происходит в DAC. Другим важным отличием является то, что в мандатной модели контролируются не операции, осуществляемые субъектом над объектом, а потоки информации, которые могут быть только двух видов: либо от субъекта к объекту (запись), либо от объекта к субъекту (чтение).

Мандатный принцип построения системы разграничения доступа в СУБД реализует многоуровневую модель безопасности данных, называемую еще моделью Белл - ЛаПадула (по имени ее авторов - Д. Белла и Л. ЛаПадула), введенную в 1975 г. В модели Белл - ЛаПадула устанавливаются и поддерживаются два основных ограничения политики безопасности:

1. Простое правило безопасности (Simple Security), реализующее запрет чтения вверх (No Read Up -- NRU);

2. *-свойство (star-property), реализующее запрет записи вниз (No Write Down - NWD).

Ограничение NRU является логическим следствием мандатного принципа разграничения доступа, запрещая субъектам читать данные из объектов более высокой степени секретности, чем позволяет их допуск. Ограничение NWD предотвращает перенос (утечку) конфиденциальной информации путем ее копирования из объектов с высоким уровнем конфиденциальности в не конфиденциальные объекты или в объекты с меньшим уровнем конфиденциальности.

Ограничения NRU и NWD приводят к тому, что по разным типам доступа (чтение, запись, создание, удаление) в модели Белл - ЛаПадула устанавливается разный порядок доступа конкретного субъекта к объектам. В частности, по типу доступа «создание» субъект с низшим уровнем допуска имеет возможность создавать объекты (записи) в объектах более высокого уровня конфиденциальности. Такой подход, тем не менее, отражает реальные ситуации, когда служащий отдела кадров может порождать первичные документы личных дел новых сотрудников, но при этом не имеет собственно самого доступа к этим документам по другим типам операций (чтение, удаление, изменение).

Ключевым понятием в модели Белла и ЛаПадулла является понятие решетки безопасности (security lattice). Математически, решеткой безопасности называется алгебраическая система, состоящая из оператора, определяющего отношение порядка (dominance) для уровней секретности и операторов наименьшей верхней и наибольшей нижней границ. Отношение порядка обладает свойствами рефлективности (разрешены потоки информации между субъектами и объектами одного уровня секретности) и транзитивности (если информация может передаваться от субъектов и объектов уровня А к субъектам и объектам уровня В и от субъектов и объектов уровня В к субъектам и объектам уровня С, то она может передаваться от субъектов и объектов уровня А к субъектам и объектам уровня С). Операторы наименьшей и наибольшей границ определяются таким образом, чтобы для каждой пары уровней секретности существовал единственный элемент наименьшей верхней границы и единственный элемент наибольшей нижней границы.

Математическая формализация модели позволяет сформулировать основные положения безопасности системы и по возможности строго доказать их. Состояние системы называется безопасным по чтению (или simple-безопасным), если для каждого субъекта, осуществляющего в этом состоянии доступ по чтению к объекту, уровень доступа субъекта доминирует над уровнем секретности объекта. Состояние системы называется безопасным по записи (или *-безопасным), если для каждого субъекта, осуществляющего в этом состоянии доступ по записи к объекту, уровень секретности объекта доминирует над уровнем доступа субъекта. Состояние системы называется безопасным, если оно безопасно по чтению и по записи и наконец, система называется безопасной, если начальное и все последующие состояния безопасны. Как уже упоминалось, в рамках данной модели доказано важное утверждение, если начальное состояние системы безопасно и все переходы из одного состояния системы в другое не нарушают правил разграничения доступа, то любое последующее состояние системы также безопасно, что позволяет применять мандатную модель в системах с высоким уровнем секретности.

Отметим и недостатки мандатного разграничения доступа:

· невозможность автоматизации назначения уровней секретности и определения границ защищаемых данных, что в больших системах может приводить к практически бесконечному ручному процессу конфигурации системы;

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

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

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

Из-за отмеченных недостатков мандатного разграничения доступа в реальных СУБД множество объектов, к которым применяется мандатное разграничение, является подмножеством множества объектов, доступ к которым осуществляется на основе дискреционного разграничения. В целях уменьшения негативных последствий ограничения NWD в систему вводят привилегированного пользователя, имеющего специальные полномочия на удаление любого объекта системы и понижения метки конфиденциальности. Имеются также расширения мандатной модели, adapted mandatory access model и др., некоторым образом снимающие недостатки MAC.

Примером реализации мандатного подхода разграничения доступа можно считать компонент Oracle Label Security (OLS), реализованный в СУБД Oracle, начиная с 9i версии. Примером Российской СУБД, реализующей стандарт SQL является СУБД ЛИНТЕР.

1.5 Ролевое разграничение доступа

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