Субъект-объектная модель

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

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

Введение прав доступа к объекту по умолчанию может спасти от второй напасти, но упомянутая таблица рассредоточивается, а зачастую становится лишь воображаемой. В таком варианте каждый объект носит за собой неопределенной длины "хвост", в котором заданы права доступа некоторых субъектов и отдельные - "для остальных". Такой "хвост" носит название таблицы управления доступом (Access Control List, ACL). Однако от первой напасти - несоразмерности служебных и полезных данных - механизм ACL спасает лишь отчасти: дублированной информации становится меньше, но в любом случае максимальный объем служебных данных при каждом объекте пропорционален количеству субъектов. Значит, ограничивать максимальный объем служебных данных в системе вообще нельзя, ведь при добавлении каждого нового субъекта этот объем будет - теоретически - возрастать на несколько процентов.

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

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