В политике безопасности должны быть описаны уровни полномочий, присваиваемые различным группам пользователей, уровни конфиденциальности обрабатываемой информации, порядок включения новых пользователей в те или иные группы и наделения их полномочиями (авторизация), изменение полномочий, удаление пользователей из системы. Можно выделить в политике безопасности организационную и техническую составляющие. К организационным аспектам отнесем, например, права и обязанности должностных лиц в отношении безопасности, порядок учета и обращения с отторгаемыми носителями информации и т.п. Далее рассмотрим только техническую сторону политики безопасности, которая может быть отображена на механизмы безопасности, реализованные в программном обеспечении АС.
Политика безопасности может быть выражена формальным и неформальным образом. Неформальное описание политики безопасности реализуется обычно в виде таблиц, наглядно представляющих ПРД. Преимущество подобного описания состоит в простоте его восприятия пользователями и контролирующими органами. Основной недостаток неформального описания политики безопасности — возможность допуска логических ошибок при ее формировании, что может привести к появлению уязвимостей в проектируемой системе.
|
|
Преимущество формального описания заключается в строгом обосновании политики безопасности и (иногда) возможности теоретического доказательства безопасности системы. Приведем вначале неформальные ПРД политики безопасности, а затем формализуем их для построения модели.
Рассмотрим возможные правила управления доступом к ресурсам в рассматриваемой АС. Предположим, что функции администраторов ограничены задачами управления защитой информации, а как обычные пользователи они не работают. Вначале допустим, что внутренних нарушителей нет.
Правило 1. Администратор сети может создать пользователя и наделить его атрибутами безопасности, а также удалить пользователя и изменить его атрибуты безопасности.
Правило 2. Каждый пользователь до предоставления ему доступа должен быть идентифицирован.
Правило 3. Пользователь не может создать пользователя.
Правило 4. Пользователь может создать субъект и наделить его атрибутами безопасности.
Правило 5. Пользователь порождает только те процессы, которые разрешены администратором (так как внутреннего нарушителя нет, то эта необходимость вызвана обеспечением целостности системы).
Правило 6. Пользователь имеет доступ только к тем ресурсам, которые ему разрешены администратором (дискреционный доступ).
|
|
Теперь предположим, что имеются внутренние нарушители, но не администраторы. Появляются новые правила управления доступом.
Правило 7. Каждый пользователь до предоставления ему доступа должен быть аутентифицирован. Доступ должен предоставляться только при успешном прохождении аутентификации.
Правило 8. Пользователь, находящийся на определенном уровне секретности, может создавать информационные ресурсы уровня секретности не меньше его собственного.
Правило 9. Пользователь, находящийся на определенном уровне секретности, может читать информационные ресурсы уровня секретности не выше его собственного.
Последние два правила задают политику мандатного доступа.
Если допустить, что нарушителями могут быть и администраторы, то добавляются, например, следующие правила.
Правило 10. Администраторы сети не могут изменить свои собственные права. Права администраторов сети может менять администратор системы. Права администратора системы по доступу к ресурсам настраиваются на этапе настройки системы и не изменяются.
Правило 11. Администраторы сети имеют доступ к информации аудита только по чтению.
Правило 12. Администраторы не имеют доступа к пользовательской информации (либо к какой-то части пользовательской информации).
Конечно, приведенный выше перечень правил далеко неполон. Необходимо указать конкретно, кто и каким образом допущен к выводу документов на печать и сменные носители информации, кто допущен и к каким сетевым сервисам, кто обладает правом подписи исходящей информации, какие рабочие группы организуются и каковы их права и т.д.