Профили защиты, разработанные на основе "Общих критериев". Часть 2. Частные требования к сервисам безопасности

Анонимизаторы

Анонимизаторы предназначены для выполнения функциональных требований приватности (класс FPR "Общих критериев"). В данном разделе, основываясь на статье [ 74 ] и профиле защиты [ 48 ] , мы рассмотрим одну из разновидностей анонимизаторов - сеть серверов пересылки, обеспечивающую приватность пользователей электронной почты.

Вероятно, приватность - это единственный класс функциональных требований ОК, направленных не на обеспечение безопасности иерархически организованных, жестко администрируемых систем, а на защиту специфических интересов пользователей информационных сервисов. В "Оранжевой книге" Министерства обороны США и Руководящих документах Гостехкомиссии России подобных требований не было, поэтому необходимо накапливать опыт по их применению, что придает работам [ 74 ] и [ 48 ] особую ценность. Происходит становление так называемой многоаспектной информационной безопасности, когда делается попытка учесть весь спектр интересов (порой конфликтующих между собой) всех субъектов информационных отношений, а также все виды конфигураций ИС, в том числе децентрализованные, не имеющие единого центра управления.

Напомним, что класс FPR содержит четыре семейства: FPR_ANO ( анонимность - возможность совершать действия, не раскрывая идентификационных данных пользователя ), FPR_PSE ( псевдонимность - анонимность с сохранением подотчетности ), FPR_UNL ( невозможность ассоциации - анонимность с сокрытием связи между действиями одного пользователя ), FPR_UNO (скрытность, или ненаблюдаемость - сокрытие самого факта использования ресурса или услуги). Псевдонимность полезна, например, когда за многократное обращение к каким-то специфическим платным услугам полагаются скидки. Невозможность ассоциации позволяет защититься от раскрытия личности пользователя путем анализа профиля его поведения. Назначение семейств FPR_ANO и FPR_UNO очевидно.

Сеть серверов пересылки почты состоит из независимо администрируемых узлов. Отправитель определяет в ней путь сообщения, которое шифруется таким образом, что каждому серверу известны только предыдущий и следующий узлы. В результате достигается невозможность установления ассоциации между отправителем и получателем. Если в сообщении отсутствуют идентификационные данные отправителя, то обеспечиваются анонимность, невозможность ассоциации и, отчасти, скрытность. Псевдонимность может быть реализована путем применения особым образом заданных обратных адресов. Отметим, что на тех же принципах организуется работа анонимизаторов для других информационных сервисов, в частности, для Web-доступа. Существуют свободно распространяемые (Mixmaster) и коммерческие (компании Zero Knowledge Systems) реализации сетей серверов пересылки.

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

Для сети серверов пересылки сообщений выделяются следующие специфические угрозы безопасности:

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

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

Формулируются два специфических положения политики безопасности:

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

Перечислим специфические цели безопасности:

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

Специфические цели безопасности для среды:

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

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

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

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

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

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

Специфические функциональные требования состоят в следующем.

• полное управление доступом (FDP_ACC.2). Политика принудительного управления доступом должна распространяться на всех субъектов (серверы пересылки, клиентское ПО, пользователи, администраторы), все объекты (в том числе на содержание и маршрутную информацию сообщений) и все операции;
• ограниченное управление информационными потоками (FDP_IFC.1). Должна проводиться в жизнь политика борьбы со скрытыми каналами применительно к серверам пересылки, клиентскому ПО, сообщениям, передаче и приему сообщений (FDP_IFC.1.1);
• частичное устранение неразрешенных информационных потоков (FDP_IFF.4). Политику борьбы со скрытыми каналами необходимо внедрять, чтобы уменьшить до заданных пределов утечку информации о работе пользователей с сетью пересылки, возникающую за счет анализа периферийных потоков данных (FDP_IFF.4.1). Получение профилей поведения компонентов сети пересылки путем анализа периферийных потоков данных должно быть невозможным (FDP_IFF.4.2);
• полное управление временем хранения данных (FDP_IRC.2). Все объекты, нужные для нормальной работы сети пересылки, удаляются сразу после завершения операций с ними. Отметим, что это не просто специфическое, но новое функциональное требование, предложенное автором профиля защиты;
• управление атрибутами безопасности (FMT_MSA.1). Согласно политике принудительного управления доступом, только пользователь, сгенерировавший данные, может выполнять операции над их атрибутами безопасности, в число которых входят маршрут сообщения и его рандомизация, минимальное число пересылок, число отправляемых избыточных сообщений, параметры потоков данных и криптографических алгоритмов и т.п. (FMT_MSA.1.1);
• анонимность без запроса информации (FPR_ANO.2). Должны обеспечиваться невозможность определения подлинного имени отправителя сообщения, обрабатываемого сетью серверов пересылки (FPR_ANO.2.1), а также невозможность отслеживания и анонимность пересылки сообщений для всех пользователей без запроса какой-либо ссылки на подлинное имя пользователя (FPR_ANO.2.2);
• размещение информационных ресурсов (FPR_TRD.2). Сеть пересылки должна состоять из отдельных взаимодействующих частей, в каждой из которых реализуются свои правила аутентификации и управления доступом (FPR_TRD.2.1). Доступ к данным другой части предоставляется только по явному запросу (FPR_TRD.2.2). Данные, критичные для невозможности ассоциации (маршрут, время и т.п.), должны храниться в виде, исключающем их полное чтение одной частью сети, чтобы обеспечить невозможность прослеживания всей цепочки между отправителем и получателем сообщения (FPR_TRD.2.3). Этот и два последующих компонента предложены автором профиля защиты;
• распределение обработки сообщений (FPR_TRD.3). По своей сути этот компонент аналогичен предыдущему с точностью до замены слова "храниться" на "обрабатываться";
• невозможность ассоциации пользователей (FPR_UNL.2). Должна обеспечиваться невозможность установления факта отправки сообщений одним и тем же пользователем.

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

Рассмотренный профиль защиты, на наш взгляд, весьма поучителен. Он демонстрирует как достоинства, так и недостатки "Общих критериев". К числу достоинств можно отнести богатый набор современных функциональных требований, особо выделив требования приватности. К сожалению, как мы уже отмечали, они носят "точечный", а не концептуальный или архитектурный характер. Для требования распределенности архитектуры пришлось вводить новое семейство - FPR_TRD. Отметим, в свою очередь, что отнесение его к классу приватности не кажется нам оправданным. Распределенность принципиально важна для целого ряда систем, но если в системах электронных платежей, как и в сети серверов пересылки, это необходимое условие приватности (в профиле новое семейство получило наименование "распределения доверия" ), то во многих других случаях она играет инфраструктурную роль, обеспечивая живучесть (устойчивость к отказам) и/или масштабируемость (в сочетании с архитектурой менеджер / агент ). Очевидно, архитектурные требования заслуживают отдельного класса.

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

Авторы работ [ 74 ] , [ 48 ] справедливо замечают, что введение новых функциональных требований имеет свои оборотные стороны. Конкретные профили получаются проще, естественнее, однако их сравнение с нестандартными компонентами усложняется. Возможный выход подсказывает технология программирования, предусматривающая проблемно-ориентированные расширения базовых интерфейсов, как это выполнено, например, в Java-системах. Подобные расширения можно разработать и стандартизовать быстрее, чем полный набор требований, поскольку они затрагивают более узкий круг специалистов, объединенных к тому же общностью интересов.