Модель безопасности: неформальное описание

Неформальное описание правил разграничений доступа

В политике безопасности должны быть описаны уровни полномочий, присваиваемые различным группам пользователей', уровни конфиденциальности обрабатываемой информации, порядок включения новых пользователей в те или иные группы, и наделения их полномочиями (авторизация), изменение полномочий, удаление пользователей из системы. Можно выделить в политике безопасности организационную и техническую составляющие. К организационным аспектам отнесем, например, права и обязанности должностных лиц в отношении безопасности, порядок учета и обращения с отторгаемыми носителями информации и т.п. Далее рассмотрим только техническую сторону политики безопасности, которая может быть отображена на механизмы безопасности, реализованные в программном обеспечении АС.

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

Преимущество формального описания заключается в строгом обосновании политики безопасности и (иногда) возможности теоретического доказательства безопасности системы. Приведем вначале неформальные ПРД политики безопасности, а затем формализуем их для построения модели.

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

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

Правило 2. Каждый пользователь до предоставления ему доступа должен быть идентифицирован.

Правило 3. Пользователь не может создать пользователя.

Правило 4. Пользователь может создать субъект и наделить его атрибутами безопасности.

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

Правило 6. Пользователь имеет доступ только к тем ресурсам, которые ему разрешены администратором (дискреционный доступ).

Теперь предположим, что имеются внутренние нарушители, но не администраторы. Появляются новые правила управления доступом.

Правило 7. Каждый пользователь до предоставления ему доступа должен быть аутентифицирован. Доступ должен предоставляться только при успешном прохождении аутентификации.

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

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

Последние два правила задают политику мандатного доступа.

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

Правило 10. Администраторы сети не могут изменить свои собственные права. Права администраторов сети может менять администратор системы. Права администратора системы по доступу к ресурсам настраиваются на этапе настройки системы и не изменяются.

Правило 11. Администраторы сети имеют доступ к информации аудита только по чтению.

Правило 12. Администраторы не имеют доступа к пользовательской информации (либо к какой-то части пользовательской информации).

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

Идентификация активов и определение их ценности

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

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

Кроме того, существуют несекретные активы, для которых исключительно важно обеспечить целостность и доступность данных. Это — конфигурационные, настроечные данные программ, да и сами программы.

Таким образом, можно оценивать активы в плане важности обеспечения их свойств безопасности «по отдельности»: конфиденциальности, целостности, доступности. В некоторых случаях можно также ввести кумулятивный показатель важности, присвоив отдельным свойствам безопасности веса и выполнив свертку.

Некоторые особенности определения правил разграничения доступа

В определении ПРД к ресурсам имеются определенные нюансы, которые, как правило, остаются за рамками рассмотрения в, известной литературе. Рассмотрим эти нюансы.

1. В отношении пользовательских данных предлагается следующий подход: наделить пользователя (пользователей) правами по управлению ими, т.е. пользователь имеет возможность при создании файла ограничить доступ к нему для всех других пользователей, включая администратора. Это может быть сделано путём, шифрования файла либо установкой на него определенного пароля. Пользователь должен иметь возможность гибкой настройки соответствующих ПРД: кому-то (пользователям, группе) разрешить доступ только по чтению, кому-то — разрешить полный доступ, кому-то вообще его запретить. Таким образом, пользователь выступает в качестве администратора по отношению к создаваемой им информации.

2. Достаточно часто возникает необходимость в коллективной работе над документами. В настоящее время существует ряд программных средств, позволяющих выполнять такую деятельность. Предлагаются следующие ПРД для коллективных документов: доступ по чтению имеют все члены группы; корректировка пользователями осуществляется путем создания каждым из них временной копии файла и работе над ним; запись окончательных изменений должна осуществляться при получении согласия от всех пользователей группы (или, например, большинства). Таким образом, в качестве администратора для коллективных документов выступает множество (или подмножество) пользователей группы.

3. Информация справочных баз данных доступна по чтению в соответствии с уровнем полномочий пользователей. По записи она доступна только уполномоченным пользователям, которые выступают в качестве администраторов баз данных. Вносимые этими пользователями изменения должны обязательно заверяться, например ЭЦП.

4. Для назначения ПРД на конфигурационную информацию программных средств целесообразно разбить ее на три категории:

• недоступная для настройки;

• доступная для настройки только соответствующим администраторам;

• доступная для свободной настройки (например, вид рабочего окна той или иной программы).

В каждом программном средстве имеются, как правило, все три категории конфигурационной информации.

5. Целесообразно назначать ПРД не только на программные средства (возможность/невозможность их запуска пользователями), но и на опции, с которыми они запускаются. Например, кому-то может быть разрешен запуск: редактора языка Visual Basic в MS Word, а кому-то запрещен.

Таким образом, субъекты и объекты рассматриваемой АС и назначенные ПРД могут быть представлены в виде, показанном на рис. 11.3. Необходимо формализовать подобные правила для построения системы защиты и полного определения политики безопасности. Использование такого подхода позволяет создать описание взаимодействия субъектов и объектов в соответствии с прохождением информационных потоков, а также выработать требования, необходимые для контроля доступа.

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

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