Глава 4. Механизмы реализации безопасности

4.1. Источники угроз информационной безопасности

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

Фактически, реализация защиты имеет две части: код и настройку (setup). Код – это программы в доверенной вычислительной базе (в комплексе средств защиты). Настройка – это все данные, которые управляют операциями этих программ: списки контроля доступа, членства группы, пользовательские пароли, ключи шифрования, и т.д.

Задача реализации защиты должна защитить против уязвимостей. Они встречаются в трех основных формах:

1. Плохие (ошибочные или враждебные) программы.

2. Плохие (небрежные или враждебные) агенты – программы или пользователи, которые дают плохие команды хорошим, но легковерным программам.

3. Плохие агенты, подключающиеся к коммуникациям, или заполняющие их своими сообщениями.

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

В общем случае имеются четыре стратегии защиты:

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

2. Не впускать нарушителей. Программам внутри этой защиты можно позволить быть легковерными. Это позволяют сделать электронные цифровые подписи программ и межсетевые экраны (МЭ).

3. Впустить нарушителей, но воспрепятствовать им в причинении вреда. Традиционным способом служит динамическое ПО типа sandboxing на основе процессов операционной системы, или в современном виде, в виртуальной машине Java. Динамическое ПО типа sandboxing создает в компьютере защищенное пространство (sandbox), в котором может выполняться подозрительный код, и в типичном случае использует контроль доступа к ресурсам, чтобы определить нарушения. Программы, доступные из указанного защищенного пространства, должны иметь повышенную стойкость; трудно написать их правильно.

4. Захватить нарушителей и преследовать их. Это делают аудит и силовые структуры.

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

Работа диспетчера доступа заключается в том, чтобы решить: может ли источник запроса, называемый принципалом, получить доступ к объекту. Чтобы решить это, используют два вида информации: аутентификационная информация, которая идентифицирует принципала, сделавшего запрос, и авторизационная информация, которая говорит, кому разрешено сделать что-то на объекте.

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

1. Иметь отдельные методы для того, чтобы писать с квотами и без, и не разрешать новым пользователям записывать без квот.

2. Иметь отдельный объект «квота», который файловая система вызывает по запросу пользователя.

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

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

В каждой модели, существуют три основных механизма для осуществления защиты. Вместе, они формируют «золотой» стандарт:

• Аутентификация принципалов, отвечает на вопрос: «Кто это сказал?» или «Кто получает данную информацию?». Обычно принципалы – это пользователи, но могут также быть группы, машины или программы.

• Авторизация доступа, отвечает на вопрос, «Кому разрешено делать такие операции на этом объекте?»

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