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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Субъекты

Назначающие правила разграничения доступа

АС АР АУ АП Пользователи Процессы

Ппаяиня пя"»гпяииирниа ппгтт/пя

1

1

1

1

Чтение

Дозапись

Модификация

Удаление

Запуск

Создание субъектов

Удаление субъектов

Наделение атрибутами безопасности, их модификация

Объекты

ОПО, СПО в разных режимах запуска

Конфигурационная информация

Пользовательские данные

Справочная информация

Данные групп пользователей

Рис. 11.3. Детализация понятий субъектов и объектов

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