Динамическим можно назвать правило отказывать в доступе, если в системе активен некоторый привилегированный субъект, или механизм "жетонов" для одноразового доступа к объекту. Когда используется статический механизм, говорят о правах доступа, когда динамический или смешанный - о сеансах доступа. Правила организации сеансов доступа могут быть весьма запутанными, потому что решение, которое примет система, зависит от состояния любой ее части. Такие правила привязаны к внутреннему устройству системы и реализации ее объектов. Пример динамических механизмов предоставления доступа см. в [20] и [12].
Организация прав доступа может быть целиком отдана на откуп самой системе, точнее, доверенному субъекту, на действия которого распространяются не все правила, определяющие доступ к объектам. В этом случае доверенный субъект (как правило, администратор системы) составляет некий свод правил, с которыми система и будет сообразовываться в дальнейшем. Назовем это централизованной ответственностью за потоки информации.
Другая возможность - так называемая доменная ответственность. Вводится понятие хозяина объекта. Хозяин объекта - это субъект, определяющий права доступа других субъектов к данному объекту. Таким образом, любой объект системы попадает в зону ответственности (домен) некоторого субъекта. Другой субъект, имеющий право читать данные из этого объекта, возможно, поместит их в другой объект, уже в своем домене. Тогда к этим данным, возможно, получит доступ третий субъект; так информация перетекает из домена в домен, направляемая хозяевами объектов.
Как система определяет хозяина объекта? Самый естественный способ - снабдить объект ярлыком, в котором будет написано имя хозяина. Субъект, чьим ярлыком подписан объект, устанавливает права доступа к нему всех нехозяев. При этом соблюдается принцип собственности: есть моя вещь, что хочу с ней, то и делаю; а есть чужая вещь, с ней можно делать только то, что позволит хозяин. Назовем такую стратегию субъект-субъектной моделью прав доступа. В самом деле, объект в этой модели не имеет самостоятельного места, все вопросы о доступе решаются на уровне двух субъектов: хозяина и пользователя.
Простая субъект-субъектная модель вполне работоспособна, особенно если считать, что у объекта может быть несколько хозяев - действительных субъектов, объединенных одним ярлыком. С точки зрения подсистемы, разделяющей доступ, им должен соответствовать один номинальный субъект - группа. Если же действительный субъект системы может принадлежать более чем одной группе, говорят о модели со множественным субъектом. Это более гибкий способ организовать права доступа на субъект-субъектном уровне. Невыполнимая в случае простой модели задача "запретить доступ конкретного субъекта к конкретному объекту" с помощью групп решается в три приема. Надо завести новую группу и добавить в нее всех субъектов-хозяев из старой группы, которой принадлежит объект. Всех, кроме одного: он-то и будет ущемлен в правах, когда мы пометим объект как принадлежащий новой группе.
С одной стороны, субъект-субъектная модель со множественным субъектом замечательно выражает общепринятое представление о правах собственности. С другой стороны, некоторые более или менее понятные изменения прав доступа к отдельному объекту выполняются непросто и, строго говоря, необратимо: изменив описанным в примере способом права доступа пользователя к объекту, мы теряем исходный ярлык этого объекта (теперь он принадлежит вновь созданной группе). Если запрет на доступ - временный, то когда-нибудь придется "все вернуть на место", а сделать это простым удалением новой группы и возвратом старого ярлыка нельзя еще и потому, что за время действия запрета объект мог еще раз поменять ярлык (например, еще кому-то запретили им пользоваться). Поэтому для обратного действия все равно придется создавать новую группу и включать в нее всех хозяев объекта плюс восстановленного в правах пользователя.
Такая ситуация (как и любая, когда речь идет о доступе к объекту независимо от того, кому он принадлежит) воспринимается как исключение из правил - не такое уж редкое, впрочем. Здесь требуется иной подход к организации прав доступа, субъект-объектная модель, которая описывает взаимоотношения между субъектом и объектом.
Простая субъект-объектная модель подразумевает нечто вроде таблицы, в которой по горизонтали перечислены субъекты системы, а по вертикали - объекты; на пересечении горизонтали и вертикали вписаны права доступа соответствующего субъекта к соответствующему объекту. Такая таблица хороша, только если количество субъектов, объектов и способов доступа к ним в системе невелико и редко меняется (хотя сами права доступа могут изменяться часто). В самом деле, количество записей в таблице равно произведению этих трех системных величин, при этом, чтобы добавить туда новый объект, нужно определить права доступа к нему каждого субъекта. Это, во-первых, может потребовать немало системных ресурсов, а во-вторых, требует от того, кто добавляет, знания всего списка пользователей и их полномочий.
Введение прав доступа к объекту по умолчанию может спасти от второй напасти, но упомянутая таблица рассредоточивается, а зачастую становится лишь воображаемой. В таком варианте каждый объект носит за собой неопределенной длины "хвост", в котором заданы права доступа некоторых субъектов и отдельные - "для остальных". Такой "хвост" носит название таблицы управления доступом (Access Control List, ACL). Однако от первой напасти - несоразмерности служебных и полезных данных - механизм ACL спасает лишь отчасти: дублированной информации становится меньше, но в любом случае максимальный объем служебных данных при каждом объекте пропорционален количеству субъектов. Значит, ограничивать максимальный объем служебных данных в системе вообще нельзя, ведь при добавлении каждого нового субъекта этот объем будет - теоретически - возрастать на несколько процентов.
Не помогает и введение в модель множественного субъекта, хотя опять-таки сокращается объем дублированной информации. Введение в модель множественных объектов, групповых операций по изменению ACL или механизма наследования, когда дочерний объект подчиняется ACL родительского (например, файл наследует ACL каталога, в котором находится), только запутывает дело. Во-первых, как в случае субъект-субъектной модели, начинают возникать ситуации, когда разрешить (или запретить) доступ невозможно без пересмотра всей структуры прав доступа. Во-вторых, процедура определения фактических прав доступа (можно-таки пользователю читать файл или нет?) начинает зависеть от структуры хранилища объектов (файловой системы) и становится донельзя сложной и непонятной.
Между тем основные потребности в ограничении доступа покрываются именно субъект-субъектной моделью. В ней объем служебной информации об объектах не зависит от количества субъектов (к каждому объекту добавляется ярлык и фиксированный список прав доступа). Поэтому довольно удачной представляется субъект-субъектная модель прав доступа, дополненная ACL в качестве механизма обработки исключений. Скорее всего, случаи, для которых необходим ACL, будут редкими и особенного разрастания системной области не произойдет. Если, паче чаяния, объем ACL при разнообразных объектах системы станет слишком велик, это будет сигналом того, что само разбиение на группы доступа сделано администратором нерационально.