Принципы разработки доверенного программного обеспечения

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

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

Существуют две технологии проектирования сложных программных систем – "вертикальная" (иерархическая) и "горизонтальная" (модульная).

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

1. Упрощается структура доверенного программного обеспечения.

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

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

В качестве примера можно привести типичную структуру системы, состоящую из четырех уровней:

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

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

3. Уровень операционной системы. На данном уровне располагаются компоненты операционной системы (например, управление памятью, управление файловой системой, подсистема ввода-вывода, управление процессами и т. д.).

4. Уровень аппаратного обеспечения. На данном уровне помещается программ­ное обеспечение, встроенное в аппаратное обеспечение.

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

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

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

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

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

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

2. Принцип безопасных умолчаний. Данный принцип говорит о том, что по умол­чанию доступа к объектам системы быть не должно. Все права доступа должны быть определены явно.

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

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

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

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

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

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

Контрольные вопросы

1. Какие функции выполняет TCB?

2. Какой уровень абстракции необходимо выбрать при моделировании системы?

3. Можно ли верифицировать безопасность системы на основании доверенного программного обеспечения? Почему?

4. Как определяется периметр защиты системы?

5. Какие принципы используются при разработке механизмов безопасности?

Лекция 5.

БАЗОВЫЕ МЕХАНИЗМЫ БЕЗОПАСНОСТИ
ОС СЕМЕЙСТВА WINDOWS

Поиск по сайту: