учебники, программирование, основы, введение в,

 

Информационные потоки и права доступа

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

Вертикальные информационные потоки

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

Модель секретности

В модели секретности таким свойством считается конфиденциальность информации. Модель повторяет общепринятое отношение к секретам: каждому объекту системы присваивается определенный уровень секретности, и чем выше уровень, тем меньше субъектов системы имеют к этому объекту доступ.
Обычно предполагается, что доступ организован строго иерархически: субъект имеет доступ к данным определенного уровня секретности и ниже. Для этого каждому субъекту присваивается единственный уровень доступа (для простоты будем заменять словосочетания "уровень секретности объекта" и "уровень доступа субъекта" на "уровень объекта" и "уровень субъекта"). Получившаяся схема напоминает пирамиду, откуда пользователь может "увидеть" только нижнюю ее часть, а все, что выше его уровня, становится "невидимым". Такое понимание секретности даже формально не может гарантировать неразглашение конфиденциальной информации.
В модели рассматривается два метода доступа к данным: чтение и запись. Если субъект перемещает некоторый объект системы на свой уровень - это операция чтения. Доступ по чтению не требует изменения уровня объекта, но предполагает, что в результате операции данные одного уровня будут доступны на другом. Принято считать, что конфиденциальность информации сохранится, если запретить доступ к данным более высокого уровня. Для чтения это верно.
Если субъект перемещает некоторый объект системы своего уровня на какой-нибудь другой - это операция записи. В результате операции записи может не произойти передачи данных, однако изменение уровня объекта (в обычном понимании - засекречивание или рассекречивание) позволит субъектам других уровней в дальнейшем иметь доступ к нему по чтению. Поскольку рассекречивание объекта нарушает конфиденциальность информации, эту операцию надо запретить, что означает запрет записывать данные на более низкий уровень секретности. Этот запрет (как и предыдущий) должен быть реализован на системном уровне, чтобы исключить саму возможность разглашения данных одними только системными средствами (без помощи взяток, шпионажа, шантажа и прочих внесистемных воздействий на субъекта).
Таким образом, правила нечтения верхнего уровня (No Read Up, NoRU) и незаписи на нижний уровень (No Write Down, NoWD) в модели секретности запрещают нисходящие информационные потоки. Заметим, что запись на верхний уровень (WU) правилами не запрещена: любой нижестоящий субъект вправе информировать вышестоящие инстанции о том, что происходит на его уровне.
Главный недостаток полностью реализованной модели секретности заключается в том, что вся информация - если она вообще куда-то движется - будет в конце концов засекречена. Некоторые субъекты совсем ничего не будут знать, прочие же станут "невыездными" и будут под страхом неминуемого наказания угрюмо молчать на вечеринках или в одиночку пить горькую по домам. Если такое положение дел не устраивает, есть три способа его преодоления.
Во-первых, можно ввести наивысший уровень секретности (с номером, допустим, -1), попадая на который объекты становятся недоступны ни одному субъекту системы. С ролью наивысшего уровня секретности хорошо справляются спецслужбы или машина для уничтожения бумаг. Если при этом в системе имеется приток объектов невысокого уровня секретности, можно добиться баланса.
Во-вторых, можно ввести автоматическую процедуру рассекречивания, основанную на свойствах объекта: его актуальности, времени жизни, связях с другими объектами и т. п. Говорят, что британские спецслужбы понижают секретность документов, если к ним не было обращений последние 50 лет.
В-третьих, в системе можно предусмотреть доверенного субъекта - выделенного субъекта системы, которому разрешено нарушать политику безопасности. Он-то и будет рассекречивать некоторые документы, руководствуясь не системными, а личными правилами. Доверенных субъектов может быть несколько, каждый с правом нарушать только некоторые правила политики безопасности, они могут образовывать собственную иерархию и подчиняться собственной политике безопасности. Здесь возникает извечный вопрос: "Кто проверяет того, кто проверяет?", на который мы отвечать не беремся.

Модель надежности

Другой подход к пониманию безопасности описывает модель надежности. В этом подходе значимость объекта понимается как степень доверия к нему: например, может оцениваться качество содержащейся в нем информации, ее актуальность, достоверность и т. п. Надежность объекта сама собой повышаться не может, а может только падать: со временем информация теряет актуальность, да и степень доверия к ней не может быть выше степени доверия к ее источнику. Можно предположить, что эта модель будет зеркальна модели секретности, в которой значимость объекта, наоборот, никогда не понижается.
Как и в случае модели секретности к очевидному правилу, запрещающему запись на верхний уровень (субъект не в состоянии подтвердить, что его объект надежнее его самого), добавляется чуть менее очевидное, запрещающее чтение нижнего уровня (с какой это стати мы будем доверять объекту больше, чем какому бы то ни было породившему его субъекту?). Стало быть, налицо запрет на восходящие информационные потоки, который выражается в правилах NoWU и NoRD.
Естественно, в модели надежности возникает все та же ситуация "стекания" объектов на один уровень - на этот раз на самый нижний. Действительно, если нет повода повысить уровень доверия к объекту, а повод понизить этот уровень нет-нет да и появляется, то в конце концов все объекты вместо доверия начнут внушать одни подозрения.
Преодолеть вырождение уровней можно все теми же способами. Во-первых, можно организовать внесистемный приток и отток информации (т. е. пополнять систему новыми объектами достаточно высокого уровня и уничтожать потерявшие актуальность объекты при выбывании с нижнего уровня). Во-вторых, придумать алгоритм автоматического повышения уровня объекта (например, вести статистику успешного использования или что-нибудь подобное). В-третьих, привлечь эксперта (доверенного субъекта), который, исходя из внесистемных критериев, будет регулярно повышать уровень разных объектов системы (нарушая тем самым правило NoWU).
Рискнем предположить, что система, полностью обеспечивающая оба требования к информации (надежность и секретность), невозможна. Свод правил, учитывающий положение субъектов и объектов сразу в двух иерархиях, наверняка будет чрезвычайно сложным. Непонятно до конца, как обрабатывать ситуации вроде той, когда с точки зрения секретности один сотрудник имеет право передавать некий документ другому, а с точки зрения надежности - нет. Любой компромисс между двумя требованиями приведет к нарушению какого-нибудь из них. Поэтому запрет обычно считается важнее разрешения, но тогда ограничение допустимых в каждой модели потоков сильно снижает гибкость системы. Видимо, надежности и секретности одновременно можно достигнуть только несистемными средствами. Даже система, последовательно реализующая одну политику безопасности, для продолжительной работы требует некоторых внесистемных средств балансировки уровней.

Горизонтальные информационные потоки

Предположим теперь, что объекты в системе невозможно распределить по уровням значимости. Это бывает довольно часто, если значимость данных определяется не самой системой, а конкретным человеком, который с ними работает. Тогда для одного субъекта системы некоторый объект будет значим, а для другого - нет. Более того, иногда единственным поводом открыть или запретить кому-то доступ к объекту становится мнение некоторого субъекта системы.
Операции чтения и записи определяются в этом случае по отношению к каждому отдельному объекту (классу объектов). Чтение - это копирование данных из объекта в некоторое личное информационное пространство субъекта (пользователь запоминает содержимое файла). Запись - это копирование данных из личного информационного пространства субъекта в объект (пользователь изменяет содержимое файла). Если множество объектов, которые субъекту разрешено читать, не совпадают с множеством объектов, доступных ему для записи, а некоторые из записываемых объектов разрешено читать другому субъекту, возникает очевидный горизонтальный информационный поток. Точнее было бы назвать его безуровневым, однако слово "горизонтальный" здесь подчеркивает равную с точки зрения системы значимость и объектов, и субъектов.
Для выявления всех возможных информационных потоков в системе составляется диаграмма достижимости. Диаграмма достижимости состоит из вершин двух видов: субъектов и объектов, соединенных стрелками: от объекта к субъекту - возможные операции чтения, от субъекта к объекту - записи. Достижимость (возможность пройти по диаграмме, следуя стрелкам) одной вершины-субъекта с другой вершины-субъекта означает потенциальную возможность передачи данных от одного к другому, хотя бы и не напрямую. Достижимость вершины-объекта с другой вершины-объекта как раз и отражает информационный поток от одного объекта (класса объектов) к другому.
На приведенном примере прямая передача информации из объекта "о1" в объект "о3" невозможна, однако существует информационный поток "о1--с1--о2--с3--о3", организуемый субъектами "с1" и "с3". Невозможна и прямая передача данных от субъекта "с3" субъекту "с1", однако через "третьи руки" это можно сделать: "с3--о3--с2--о1--с1". Алгоритмы выявления достижимости достаточно просты, однако они не дают рекомендации по тому, как изменить существующую модель, чтобы избежать нежелательных информационных потоков.
Механизм предоставления доступа может быть статическим, при котором решение о предоставлении доступа система принимает заранее, на основании свойств субъекта и объекта, или динамическим, когда на результат влияет текущее состояние субъекта, объекта, а также состояние всей системы. В частности, могут использоваться данные подсистемы учета ресурсов или состояния некоторых иных объектов и субъектов системы. Полная диаграмма достижимости при динамическом доступе может показывать ложные информационные потоки, опирающиеся на невозможные переходы в состояниях системы, но может и выявлять скрытые каналы переброски данных. Таким скрытым каналом может быть, например, отсроченная передача данных, когда один субъект записывает информацию, а другой, при определенном стечении обстоятельств, впоследствии получает доступ к ней.
Динамическим можно назвать правило отказывать в доступе, если в системе активен некоторый привилегированный субъект, или механизм "жетонов" для одноразового доступа к объекту. Когда используется статический механизм, говорят о правах доступа, когда динамический или смешанный - о сеансах доступа. Правила организации сеансов доступа могут быть весьма запутанными, потому что решение, которое примет система, зависит от состояния любой ее части. Такие правила привязаны к внутреннему устройству системы и реализации ее объектов. Пример динамических механизмов предоставления доступа.
Организация прав доступа может быть целиком отдана на откуп самой системе, точнее, доверенному субъекту, на действия которого распространяются не все правила, определяющие доступ к объектам. В этом случае доверенный субъект (как правило, администратор системы) составляет некий свод правил, с которыми система и будет сообразовываться в дальнейшем. Назовем это централизованной ответственностью за потоки информации.
Другая возможность - так называемая доменная ответственность. Вводится понятие хозяина объекта. Хозяин объекта - это субъект, определяющий права доступа других субъектов к данному объекту. Таким образом, любой объект системы попадает в зону ответственности (домен) некоторого субъекта. Другой субъект, имеющий право читать данные из этого объекта, возможно, поместит их в другой объект, уже в своем домене. Тогда к этим данным, возможно, получит доступ третий субъект; так информация перетекает из домена в домен, направляемая хозяевами объектов.

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

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

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

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

 

 
На главную | Содержание | < Назад....Вперёд >
С вопросами и предложениями можно обращаться по nicivas@bk.ru. 2013 г.Яндекс.Метрика