Следствие 2. Диалог машины и пользователя в процедурной системе строится на активности машины. Это и всевозможные "мастера", и всплывающие подсказки, и венец творения - скрепка, что бьется головой об экран и провоцирует пользователя на всевозможные действия, о которых он без нее и не подумал бы. Дело в том, что процедурная организация человеко-машинной системы подавляет инициативу. Во-первых, согласно принципу делегирования ответственности, если в предписании сказано, что для получения нужных свойств объекта нужно выполнить 18 команд, то их и следует выполнять, а не те три, которые кажутся подходящими, но нигде не сказано, что так тоже можно. Вспомним и о неуверенности, в которой следует пребывать пользователю. Во-вторых, никто, за исключением, быть может, разработчиков, не знает, что на самом деле произойдет с объектом от воздействия этих трех команд. Согласно принципу ограниченной осведомленности, пользователю неизвестно ничего, кроме легенды, и ее стоит придерживаться в любом случае. В-третьих, система, состоящая почти сплошь из готовых решений, не предполагает, что перед ней будут ставить нерешенные вопросы.
Каковы достоинства процедурной системы? Во-первых, быстрота и однозначность реакции на предусмотренные ситуации. Если возникает задача, решение которой известно (а таких много), то дальнейшее - дело техники. Если задача нетиповая, то есть не имеет готового решения, ее либо можно разбить на последовательность типовых подзадач, либо скрепя сердце подогнать под существующую типовую и признать получившееся решение решением исходной задачи. Во-вторых, как только появляется возможность формализовать предписание, управляющее работой системы, человека можно бестрепетно заменять автоматом (как, например, автоматическая проверка диска в Windows). В-третьих, ускоренная программа обучения пользователя процедурной системы требует в основном заучивания и практически никаких знаний ни об устройстве машины, ни даже о самой системе. Наконец, ответственность за применение системы можно легко переложить на разработчика или на начальника, который приказал потянуть за рычаг; а это непременное требование в сферах деятельности, где высокая цена риска сочетается с информационными или должностными ограничениями.
Недостатки процедурной системы. Один из них уже упоминался в следствии 2: подавление инициативы. Кроме всего прочего, человеку может быть чрезвычайно некомфортно работать в условиях, когда по своей воле он ничего ровным счетом сделать не в состоянии. К тому же подмена знаний о внутреннем устройстве системы легендой влечет за собой необратимость всякого воздействия: даже если в наборе процедур к "прямому" изменению объекта предусмотрено "обратное" (к примеру, вставка и удаление), после их поочередного применения исходный объект уже не получится. Скорее всего, он будет нести в себе следы прежнего объекта, а также и "прямого", и "обратного" изменений. Тут-то и приходит на помощь кнопочка Undo, которая не оперирует обратным воздействием, а работает с архивом версий объекта, выбирая оттуда предыдущую его копию. Кроме того, как неизвестно, каким образом система работает, так неизвестно и то, каким образом она не работает, то есть отчего происходят ошибки, отчего именно это сочетание процедур приводит к сбою и т. п. Словом, невозможно предсказать, когда и как именно произойдет следующий сбой системы, а когда он произошел - понять, что его вызвало, и как с этим бороться. Наконец, чем дальше задача от типовой (для которой имеется готовое решение), тем сложнее ее такой системе решить и тем сложнее предсказать качество продукта, который получится в результате использования не вполне подходящих процедур.
Процедурные системы незаменимы там, где в основе взаимодействия человека с машиной лежит один из перечисленных выше принципов: если сложность устройства системы не соответствует выполняемым функциям (телевизор, стиральная машина), если необходима мгновенная отдача от неквалифицированного пользователя (системы продажи билетов, компьютерные игры), если оператор системы не может брать на себя ответственность за качество ее работы (рабочее место оператора банковской системы, консоль ракетной установки ПВО).
Идеальной была бы такая процедурная система, в которой процедуры перекрывались бы не более двух раз, интерфейс был бы нагляден, набор готовых решений охватывал бы все мыслимые задачи и не было бы понятно, как на самом деле все реализовано. Словом, система должна быть очень большой, у всех ее частей должен быть один разработчик и она сама должна "понимать", что человеку нужно, предлагая в разных ситуациях воспользоваться той или иной своей частью.
Объектом системы мы будем называть любой ее идентифицируемый ресурс (например, файл или устройство). Доступом к объекту системы - некоторую заданную в ней операцию над этим объектом (скажем, чтение или запись). Действительным субъектом системы назовем любую сущность, способную выполнять действия над объектами (имеющую к ним доступ). Действительному субъекту системы соответствует некоторая абстракция, на основании которой принимается решение о предоставлении доступа к объекту или об отказе в доступе. Такая абстракция называется номинальным субъектом. Например, действительным субъектом будет шпион, входящий в секретную лабораторию, а номинальным - украденная им пластиковая карта-пропуск (точнее, заложенный в нее код доступа).
Свойство операционной среды разделять ресурсы предусматривает ситуацию, когда некий субъект системы не может иметь доступ к определенному ее объекту. Основания для отказа в доступе могут быть разными. Например, двум пользователям нельзя одновременно записывать данные в один и тот же файл. Но еще чаще бывает, что пользователь вообще не имеет права записывать данные в этот файл - неважно, по распоряжению начальства или по соображениям системной безопасности. Сотрудник фирмы, которому не разрешено читать личные дела других сотрудников, не должен иметь доступа к ним и в электронном виде. Ограничения доступа субъектов (пользователей) к объектам (информации) должны строго соответствовать положению дел за пределами системы.
Свод правил, управляющих разграничением доступа, называется политикой безопасности системы. Идеальная политика безопасности должна быть полной, непротиворечивой и рассматривать все возможности доступа субъектов системы к ее объектам. Только соблюдение всех трех принципов гарантирует, что нарушить установленные правила (например, получить несанкционированный доступ к объекту) системными средствами невозможно. Если же предполагаемый злоумышленник воспользовался каким-нибудь внесистемным средством и смог получить статус номинального субъекта, к которому он не имеет отношения (например, подглядел чужой пароль и работает под чужим именем), никаких гарантий быть не может.
Полнота политики безопасности означает, что в ней должны быть отражены все существующие ограничения доступа. Непротиворечивость заключается в том, что решение об отказе или предоставлении доступа конкретного субъекта к конкретному объекту не должно зависеть от того, какими путями система к нему приходит. Третье требование, называемое также отсутствием недокументированных возможностей, должно гарантировать нам, что доступ не может быть осуществлен иначе как описанным в политике безопасности способом.
Из этого третьего требования сразу же следует, что в политике безопасности необходимо учитывать также и случаи косвенного доступа, например когда пользователю не разрешено открывать файл, но разрешено запускать программу, которая имеет право открывать этот файл. К тому же выясняется, что любая ошибка в реализации правил доступа (например, при написании программ) тоже может отразиться на безопасности системы.
Вертикальные информационные потоки
Если данные в системе неравнозначны (например, есть секретная и несекретная информация или информация более и менее достоверная), придется определить еще и правила, помогающие соблюдать секретность и достоверность, т. е. отрабатывать политику безопасности. Как показано в [31], к самому понятию безопасности можно подходить по-разному. Остановимся на двух популярных моделях безопасности: так называемые "модели секретности" и "модели надежности". Эти две модели - часть практического результата теории информационных потоков, описывающего вертикальные информационные потоки.
Согласно общему предположению, данные в системе считаются неравнозначными: некоторая информация имеет высокую значимость, некоторая - низкую, возможно введение нескольких уровней значимости. Потоком информации при этом считается перемещение данных с уровня на уровень (понижение и повышение значимости), а политика безопасности регулирует такие потоки с целью сохранить некоторое основное свойство информации.
В модели секретности таким свойством считается конфиденциальность информации. Модель повторяет общепринятое отношение к секретам: каждому объекту системы присваивается определенный уровень секретности, и чем выше уровень, тем меньше субъектов системы имеют к этому объекту доступ.
Обычно предполагается, что доступ организован строго иерархически: субъект имеет доступ к данным определенного уровня секретностии ниже. Для этого каждому субъекту присваивается единственный уровень доступа (для простоты будем заменять словосочетания "уровень секретности объекта" и "уровень доступа субъекта" на "уровень объекта" и "уровень субъекта"). Получившаяся схема напоминает пирамиду, откуда пользователь может "увидеть" только нижнюю ее часть, а все, что выше его уровня, становится "невидимым". Такое понимание секретности даже формально не может гарантировать неразглашение конфиденциальной информации.