Модели управления доступом.

Модели управления доступом определяют правила управления доступом к информации, разрешениями в системе таким образом, чтобы система всегда была безопасна.

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

Субъектами могут быть пользователи, процессы и процедуры.

Объекты: файлы, программы, директории, терминалы, каналы связи, устройства и т.д.

Субъекты могут одновременно рассматриваться и как объекты, поэтому у субъекта могут быть права на доступ к другому субъекту.

В конкретном процессе в данный момент времени субъекты являются активными элементами, а объекты пассивными. Для осуществления доступа к объекту, субъект должен владеть соответствующими полномочиями.

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

При функционировании системы необходимо иметь возможность создавать новые субъекты и объекты.

При создании объекта одновременно создается и полномочие субъектов по использованию этого объекта.

Субъект, что создал такое полномочие может воспользоваться им для осуществления доступа к объекту, или же может создать несколько копий привилегий, для передачи их другим субъектам.

Успех достижения высокой степени безопасности АС зависит от тщательности разработки и реализации управления имеющимися в системе механизмами безопасности.

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

В таком случае разрабатываемая система может быть небезопасной в силу одной из двух причин:

1. Есть ошибки в реализации механизмов защиты или механизмов управления ими.
2. Ошибочно, не достаточно полно или не верно понято само определение того, что значит в отношении системы выражение "быть безопасным".

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

1. Нисходящий метод (сверху вниз). Сначала составляется общее описание системы, выделяются компоненты системы, поэтапно увеличивается степень детализации компонентов системы (выделение компонентов в компонентах) до момента окончания разработки.
2. Восходящий метод (снизу вверх). Сначала формируется задача системы, затем разрабатывается некоторый набор элементарных функций. На базе элементарных функций разрабатываются более крупные компоненты системы, и так, поэтапно разработка ведется до момента объединения отдельных компонентов в единую систему.

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

Для нас большой интерес представляет нисходящий метод создания систем, т.к. этот метод позволяет задавать требования безопасности ко всей системе в целом, и затем их детализировать, применительно к каждой подсистеме.

Нисходящий метод разработки системы обеспечения безопасности может быть неформальным и формальным.

Метод неформальной разработки применяется при создании относительно простых систем с небольшим числом компонентов и очевидными алгоритмами их взаимодействия.

По мере увеличения сложности системы, взаимосвязи ее компонентов становятся все менее очевидными. Становится сложно описать эти взаимосвязи с достаточной степенью точности некоторым неформальным образом.

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

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

• быть адекватной моделируемой системе и неизбыточной
• быть простой и абстрактной и поэтому несложной для понимания

Модель позволяет провести анализ свойств системы, но не накладывает ограничений на реализацию тех или иных механизмов защиты.

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

Моделирование требует значительных усилий и дает хорошие результаты только при наличии времени и ресурсов. Если система уже создана и имеется возможность сделать лишь отдельные изменения в отдельных местах существующей системы, в любом случае маловероятно значительное улучшение состояния безопасности системы и моделирование будет непродуктивным занятием.