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

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

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

10.1. Матрица доступа

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

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

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

К монитору обращений предъявляются требования, сформулированные еще в начале 1970-х:

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

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

Простейшей и самой общей формой записи политики служит матрица доступа (таблица 10.1). Ее строки соответствуют субъектам, столбцы объектам, а в клетке на пересечении записано множество прав, которыми соответствующий субъект обладает в отношении объекта.

Таблица 10.1. Матрица доступа

Субъект	Договор.docx	Ведомость.xlsx	Принтер	Матрица доступа
Иванов	чтение, запись, владение	—	печать	—
Петров	чтение	чтение, запись	печать	—
Служба отчетности	—	чтение	—	—
Администратор	—	—	управление	чтение, запись

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

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

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

Для преодоления первой сложности разреженная матрица заменяется некоторым ее неявным представлением.

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

Список полномочий (capability list) – хранение по строкам. Аналогично ACL с той разницей, что для каждого субъекта задан список объектов, доступ к которым разрешен (с указанием полномочий доступа). Такое представление называется профилем субъекта. Если ACL похож на перечень приглашенных у охраны, полномочие – это ключ, лежащий в кармане.

Ни один из способов не лучше другого, каждый делает дешевыми одни операции и дорогими другие:

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

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

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

Первый способ сократить описание состоит в том, чтобы не составлять его централизованно. В дискреционной модели (DAC, Discretionary Access Control) для каждого объекта существует владелец, который сам определяет тех, кто имеет доступ к объекту, а также разрешенные операции доступа. Матрица нигде не хранится целиком и никем целиком не составляется.

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

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

Классическая система дискреционного контроля доступа является «закрытой» в том смысле, что изначально объект не доступен никому, и в списке прав доступа описывается набор разрешений. Существуют и «открытые» системы, в которых по умолчанию все имеют полный доступ к объектам, а в списке доступа описывается набор ограничений.

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

Дискреционная модель реализована в операционных системах Windows и Linux.

В Linux для каждого файла (все ресурсы в этой ОС представимы в виде файлов, в том числе устройства ввода-вывода) устанавливаются разрешения доступа для трех категорий субъектов: владелец файла, члены той же группы, что и владелец, и все остальные пользователи. Для каждой из этих категорий устанавливаются права на чтение (r), запись (w) и выполнение (x). Набор прав доступа объекта может быть представлен в виде символьной строки. Например, запись «rwxr-xr--» означает, что владелец файла может делать с ним все, что угодно; члены его группы могут читать и исполнять файл, но не могут записывать; а прочим пользователям доступно только чтение.

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

Рис. 10.1. Дискреционная модель доступа в Windows

В Windows каждый именованный объект (файлы, именованные каналы, именованные блоки памяти и т. д.) защищается дескриптором безопасности, который содержит список DACL (Discretionary Access Control List). Список состоит из записей ACE (Access Control Entry), каждая из которых содержит субъекта доступа (пользователя или группу) и разрешенные ему действия (рис. 10.1). Список DACL для некоторого файла может выглядеть, например, так:

Администраторы: разрешен полный доступ.

Пользователи: разрешено чтение.

Иванов: разрешено чтение, запись, удаление.

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

Ограничения модели обусловлены ее распределенностью.

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

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

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

Так устроено мандатное разграничение доступа (Mandatory Access Control). Каждому объекту приписывается гриф, то есть уровень секретности содержащихся в нем сведений, а каждому субъекту допуск, то есть уровень, до которого ему позволено знать. Ни то, ни другое не выбирается участниками: метки назначаются извне, по правилам организации, и владелец файла гриф своего файла изменить не может. Слово «мандатное» означает здесь обязательность, в противоположность усмотрению.

Метка приписана сведениям и переносится вместе с ними. Копия секретного файла секретна, вывод программы, читавшей секретный файл, секретен, содержимое буфера обмена после копирования из секретного документа секретно. Этим и закрывается расхождение между объектом и сведениями.

Наиболее известна модель Белла-ЛаПадулы, предложенная в 1973 году.

Пусть в системе имеются данные двух видов, секретные и несекретные, а пользователи этой системы также относятся к двум категориям: с допуском к несекретным данным и с допуском к секретным. Модель формулирует два правила.

Свойство простой безопасности: несекретный пользователь (или процесс, запущенный от его имени) не может читать данные из секретного файла (рис. 10.2).

*-свойство: пользователь с допуском к секретным данным не может записывать данные в несекретный файл.

Рис. 10.2. Модель безопасности Белла-ЛаПадулы

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

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

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

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

Цена этого известна заранее: выразимы только политики, сводимые к сравнению меток. Двух пользователей с одинаковым допуском модель не различает никак, и правило «этот отчет видит Иванов, но не Петров, хотя допуск у них один» в ней не записывается.

Отчасти трудность снимается категориями. Наряду с уровнем метка содержит набор тем: «секретно {кадры}», «секретно {кадры, финансы}». Доступ разрешается, когда уровень субъекта не ниже уровня объекта и набор категорий субъекта включает набор категорий объекта. Метки при этом перестают выстраиваться в линию: «секретно {кадры}» и «секретно {финансы}» несравнимы, и ни одна не дает доступа к другой. Выразительность возрастает, компактность сохраняется, а платой становится администрирование самих категорий, которых в больших системах заводят сотни.

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

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

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

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

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

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

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

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

Ролевая модель (RBAC, Role-Based Access Control) разрывает связь между субъектом и объектом, вставляя между ними промежуточное понятие. Под ролью понимается совокупность действий и обязанностей, связанных с определенным видом деятельности: администратор базы данных, менеджер, начальник отдела. С каждым объектом сопоставлен набор разрешенных операций для каждой роли, а не для каждого пользователя. В свою очередь, каждому пользователю сопоставлены роли, которые он может выполнять.

Вместо одной матрицы «субъект-объект» система хранит две: «пользователь-роль» и «роль-разрешение». Перевод сотрудника в другой отдел сводится к замене его роли, а изменение порядка работы бухгалтерии – к правке одной строки, действующей сразу на всех бухгалтеров.

Для формального определения модели RBAC используются следующие соглашения:

S – субъект, человек или автоматизированный агент;

R – роль, рабочая функция, определяемая на уровне авторизации;

P – разрешение, утверждение режима доступа к ресурсу;

SE – сессия, набор ролей, активированных субъектом в текущий момент;

SA – назначение субъекта (Subject Assignment), SA ⊆ S × R. Субъекты и роли связаны отношением «многие ко многим»: один субъект может иметь несколько ролей, а одну роль могут иметь несколько субъектов;

PA – назначение разрешения (Permission Assignment), PA ⊆ P × R, также отношение «многие ко многим»;

RH – частично упорядоченная иерархия ролей (Role Hierarchy), RH ⊆ R × R.

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

Рис. 10.3. Схема ролевой модели контроля доступа (RBAC)

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

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

1. Простота администрирования. Отпадает необходимость прописывать разрешения для каждой пары «объект-пользователь». Вместо этого прописываются разрешения для пар «объект-роль» и определяются роли каждого пользователя.
2. Наименьшая привилегия. Пользователь регистрируется в системе с ролью, минимально необходимой для выполнения требуемых задач. Отсутствие полномочий, не требуемых для текущей задачи, уменьшает цену ошибки или захвата учетной записи.
3. Разделение полномочий. Операции, требующие участия двух лиц, обеспечиваются запретом совмещать несовместимые роли и не зависят от добросовестности исполнителей.

Средствами RBAC могут быть смоделированы и дискреционные, и мандатные системы управления доступом.

Цена такого сжатия обнаруживается там, где доступ зависит не от должности, а от конкретного дела. Правило «менеджер видит документы своих клиентов» в модели не выражается: у всех менеджеров одна роль, а клиенты у каждого разные. Единственный способ записать его средствами RBAC состоит в том, чтобы завести отдельную роль на каждого менеджера, после чего число ролей сравнивается с числом пользователей и промежуточное понятие теряет смысл. Это явление известно как разрастание ролей.

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

10.5. Атрибутное разграничение доступа

Перечисления удается избежать, если клетку матрицы не хранить, а вычислять.

Атрибутное разграничение доступа (ABAC, Attribute-Based Access Control) основано на присвоении субъектам и объектам меток, содержащих значения атрибутов. Элементы матрицы доступа не хранятся в явном виде, а динамически вычисляются при каждой попытке доступа для конкретной пары «субъект-объект» на основе их атрибутов. Политика записывается набором правил, каждое из которых представляет собой условие на эти значения.

Атрибуты разделяются на четыре группы:

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

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

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

В реализациях политика отделена от механизма явным образом. Обращение перехватывает точка применения (PEP, Policy Enforcement Point), решение вычисляет точка принятия решения (PDP, Policy Decision Point), значения атрибутов поставляет точка выдачи атрибутов (PIP, Policy Information Point), а сами правила хранятся отдельно и редактируются администратором. Так же устроено управление доступом в облачных платформах: вместо списка допущенных учетных записей администратор задает условие на теги ресурса и свойства запроса. Тег – произвольная пара «имя: значение», навешиваемая на ресурс при создании (Отдел: бухгалтерия, Среда: production, Проект: складской-учет), и правило вида «сотрудник отдела распоряжается машинами с тегом своего отдела» действует на все машины сразу, включая заведенные завтра.

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

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

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

Таблица 10.2. Сопоставление моделей разграничения доступа

Модель	Кто принимает решение	Размер описания	Что не выражается
Дискреционная	владелец объекта	произведение числа субъектов на число объектов	запрет на дальнейшее распространение сведений
Мандатная	назначающий метки, вне системы	сумма числа субъектов и числа объектов	различия между субъектами одного уровня
Ролевая	администратор ролей	число ролей, умноженное на число объектов	зависимость доступа от конкретной пары
Атрибутная	автор правил	число правил	отдельное разрешение и отдельный запрет

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