Меры противодействия угрозам безопасности. Основные механизмы защиты компьютерных систем от проникновения

 

  Разумная достаточность

 

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

 

  Гибкость системы защиты

 

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

 

  Открытость алгоритмов и механизмов защиты

 

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

 

  Принцип простоты применения средств защиты

 

Механизмы защиты должны быть интуитивно понятны и просты в использовании. Применение средств защиты не должно быть связано со знанием специальных языков или с выполнением действий, требующих значительных дополнительных трудозатрат при обычной работе законных пользователей, а также не должно требовать от пользователя выполнения рутинных малопонятных ему операций (ввод нескольких паролей и имен и т.д.). 
2. Основные механизмы защиты компьютерных систем от проникновения

 

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

 

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

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

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

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

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

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

1. Нисходящий  метод (метод "сверху-вниз"): сначала составляется общее описание системы; выделяются компоненты системы; поэтапно увеличивается степень детализации компонентов системы (выделение компонентов в компонентах и т.д.) - до момента окончания разработки.

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

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

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

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

 

Неформальная разработка    Формальная разработка

 

 

(демонстрация)

              (доказательство) 

 

(тестирование)        (тестирование)

 

 

Рис.2.1.

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

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

Основную роль в методе формальной разработки системы играет так называемая модель управления доступом. В англоязычной литературе для обозначения сходного понятия используются термины "security model" (модель безопасности) и "security policy model" (модель политики безопасности).

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

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

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

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

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

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

 

2.2 Типы моделей управления доступом

 

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

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

Модель матрицы доступа (Harrison, Ruzo и Ullman 1976) это частный случай реализации модели машины состояний. Состояния безопасности системы представлены в виде таблицы, содержащей по одной строке для каждого субъекта системы и по одной колонке для каждого субъекта и объекта (таблица 1). Каждое пересечение в массиве определяет режим доступа данного субъекта к каждому объекту или другому субъекту системы.

 

 

Таблица 1

 

Субъекты	Объекты			Субъекты
	1	2	3	1	2	3
1	Чтение Запись	Чтение		---------	Запись	Пересылка
2	Чтение	Чтение Исполне-ние	Чтение Запись	Пересылка	---------
3		Чтение Запись	Исполне-ние	Пересылка	Запись	---------

 

Второй составляющей модели матрицы доступа является набор функций перехода, описывающих способ изменения матрицы доступа.

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

Другим способом описания управления доступом является модель, выраженная в терминах меток безопасности, приписываемых субъектам и объектам системы. Режим доступа, которым обладает субъект по отношению к объекту, определяется при сравнении их меток безопасности, вместо того, чтобы искать соответствующее пересечение строки и столбца в матрице доступа. Модель может использовать как матрицу доступа, так и атрибуты безопасности. Все подобные модели, рассматривающие доступ субъекта к объекту, могут быть названы моделями управления доступом.

Вариантом модели управления доступом является модель информационных потоков (Denning, 1983), которая предназначена для анализа потоков информации из одного объекта в другой на основании их меток безопасности

Еще одним типом модели является модель интерференции, в которой субъекты, работающие в различных доменах, защищены от взаимовлияния друг на друга любым способом, нарушающим свойства безопасности системы (Goguen и Meseguer, 1982).

 

2.3 Характеристики модели безопасности

 

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

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

 

2.4 Описание модели управления доступом в системе

как конечного автомата

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

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

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

Таким образом в разработке модели управления доступом можно выделить следующие шаги:

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

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

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

Можно выделить несколько характерных черт функций перехода:

• назначение функции - определение взаимосвязи между переменными в предыдущем и новом состояниях;
• функция не задает какого-либо конкретного порядка в выполнении алгоритма операции. Иными словами, функция может рассматриваться как определение того, что произойдет с состоянием по завершении операции;
• функция элементарна. Это значит, что ее эффект не разделяем на более мелкие действия и не прерываем. Указанное изменение состояния происходит моментально, т.е. какого-либо промежутка времени, "в течение" которого происходил бы переход состояния, определить невозможно.

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

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