Модели управления доступом.
Модели управления доступом определяют правила управления доступом к информации, разрешениями в системе, таким образом, чтобы система всегда была безопасна. При создании механизмов контроля доступа необходимо определить множество субъектов и объектов доступа.
Субъекты - те кто активно воздействуют на процесс, могут быть: пользователи, процессы и процедуры.
Объекты: файлы, программы, каналы связи, директории - всё, на что направленно действие, всё, что подвержено воздействию.
Некоторые субъекты могут рассматриваться как объекты, поэтому у субъекта могут быть права на доступ к другому субъекту.
В конкретном процессе в данный момент времени субъекты являются активными элементами, объекты - пассивными.
Для осуществления доступа к объекту субъект должен владеть соответствующими полномочиями, для качественного функционирования системы, необходимо иметь возможность создавать новые субъекты и объекты.
При создании объекта одновременно создаются и полномочия субъектов по использованию этого объекта.
При разработке современных АСУ используется один из двух методов:
Нисходящий:
Сначала составляется общее описание системы, далее выделяются компоненты системы, поэтапно увеличивается степень детализации системы до момента окончания разработки.
Восходящий
Сначала формируются задачи системы, затем разрабатывается некоторый набор элементарных функций, на базе которых разрабатываются более крупные компоненты и так поэтапно до момента объединения отдельных компонентов в единую систему.
В настоящее время наибольшее распространение получил компромиссный вариант, при котором разработка системы в целом ведется нисходящим методом , а разработка отдельных (элементарных) компонентов системы - восходящим.
Для рассмотрения с точки зрения ИБ интереснее нисходящий метод. Позволяет задавать требования безопасности ко всей системе в целом.
Нисходящий метод разработки системы обеспечения безопасности может быть неформальным и формальным.
Неформальная разработка
Требования безопасности |
\/ (Демонстрация) |
Функциональная спецификация |
\/ (Тестирование) |
Реализация |
Для построения монитора обращения необходимо выполнить следующие требования:
Монитор обращений должен быть защищен от постороннего вмешательство в его работу, включая несанкционированную подмену и модификацию.
Он должен всегда присутствовать и работать надлежащим образом - постоянное качество защиты.
Монитор обращений должен быть компактен и удобен для проведения анализа и тестирования.
Формальная разработка
Требования безопасности |
\/ |
Абстрактная модель |
\/ (Доказательство) |
Функциональная специфмкацмя |
\/ (Тестирование) |
Требования безопасности |
\/ |
…. |
Метод неформальной разработки применяется при создании относительно простых систем с небольшим числом компонентов и очевидными алгоритмами взаимодействия . По мере усложнения системы взаимосвязи компонентов становятся менее очевидны и описание этих взаимосвязей с достаточной степенью точности некоторым неформальным образом становится сложно.
При разработке систем обеспечение безопасности точность в описании компонентов и их взаимосвязей является одним из решающих условий достижения успеха.
Поэтому для обеспечения надлежащей степени точности применяется строгий аппарат формальной математики.
Основная роль в методе формальной разработке системы отводится модели управления доступом. Эта модель определяет правила управления доступом к информации и потоки информации, разрешенные в системе таким образом, чтобы система всегда была безопасной.
Целью модели управления доступом является выражение сути требований по безопасности к данной системы .
Для этой модели (чтобы она выражала суть требований по безопасности) свойственны следующие свойства:
Быть адекватной к моделируемой системе и не избыточной;
Быть простой и абстрактной (нацеленной на безопасность), и поэтому несложной для понимания.
Модель позволяет производить анализ свойств системы, но не накладывает ограничения на реализацию тех или иных механизмов защиты.
Модель формальная, поэтому позволяет осуществлять доказательство для различных свойств безопасности всей системы.
Моделирование требует значительных усилий и дает хорошие результаты, только при наличии времени и материальных ресурсов.
Если система создана и имеется возможность сделать изменения лишь в отдельных местах, моделирование - нецелесообразно, т.к. маловероятно значительное улучшение безопасности системы.