Теорема 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 Мандатное разграничение доступа
К основным характеристикам мандатного (обязательного) подхода разграничения доступа относятся следующие положения: