Мельников Д. А. - Информационная безопасность открытых систем - 2013

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

3. Управление доступом. При УД могут использоваться, либо аутентификация личности субъекта, либо информация о субъ­ екте (например, принадлежность к известной группе субъек­ тов), либо мандат доступа с целью определения и реализации прав доступа субъекта. Если же субъект пытается использовать неавторизованный ресурс или авторизованный ресурс недозво­ ленным способом, то функция УД будет блокировать попытку и дополнительно может оповещать об инциденте с целью вклю­ чения сигнала тревоги и/или записи об инциденте в исходные данные для проведения аудита СОИБ. При передаче данных в дейтаграммном режиме любое оповещение передающей сторо­ ны об отказе ей в доступе может быть объяснено только как об­ ман средств УД источником данных.

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

4. Целостность данных. Существуют два вида услуг по обе­ спечению целостности данных:

1)целостность одного сообщения или поля данных;

2)целостность потока сообщений или полей данных. Для реализации этих двух видов услуг используются разные способы обеспечения целостности, хотя реализация вто­ рой без реализации первой бессмысленна. Обеспечение целостности одиночного сообщения или поля предпола­ гает два процесса, один из которых осуществляется от­ правителем, а другой —получателем;

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

42

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

При использовании только одного такого способа невоз­ можно обеспечить защиту от атак типа «Повторная переда­ ча сообщения». На соответствующих уровнях архитектуры ЭМВОС обнаружение манипуляции с данными может при­ вести к процедуре восстановления (например с помощью по­ вторной передачи или исправления ошибки) на этом или более высоком уровне.

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

В дейтаграммном режиме доставки сообщений для защиты от некоторых подвидов атак типа «Повторная передача сообще­ ния» может использоваться процедура включения в сообщения меток времени.5*

5. Обмен аутентификационной информацией. Средства за­ щиты, реализующие данный способ, могут встраиваться на N-OM уровне архитектуры ЭМВОС с целью обеспечения аутентифи­ кации взаимодействующего субъекта. Если средство аутенти­ фикации субъекта не аутентифицировало последнего, то это приводит к удалению или прерыванию соединения и может по­ влечь за собой оповещение администрации СОИБ об инциден­ те и/или дополнение исходных данных для проведения аудита СОИБ записью о произошедшем инциденте.

Этот способ обеспечения ИБ может основываться на исполь­ зовании:

1)аутентификационной информации (например пароли), которая передается отправителем и проверяется получа­ телем;

43

2)криптографических алгоритмов;

3)особенностей и/или собственности субъекта.

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

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

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

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

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

44

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

К общесистемным СПБ (т.е. независимым от архитектуры ЭМВОС) относятся:

1 ) надежность (гарантированность) функционирования.

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

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

3)обнаружение событий, влияющих на безопасность;

4)накопление и использование исходных данных для аудита безопасности;

5)восстановление безопасности. Этот способ связан с за­ просами средств защиты, реализующих другие способы безопасности, на выполнение процедур восстановления на основе принятых правил.

Далее представлена табл. 1.1, иллюстрирующая связи между услугами и способами обеспечения безопасности.

45

Таблица 1.1

Связи между услугами и способами обеспечения ИБ ИТС

46

Таблица 1.1 (окончание)

1.4.3. П ринципы архитектуры безо п асн о сти Э М В О С

Архитектура безопасности ЭМВОС1 содержит следующие

принципы распределения услуг и способов обеспечения ИБ по уровням:

1)количество альтернативных вариантов реализации услу­ ги должно быть минимальным;

1Рекомендация ITU-T Х.800 предусматривает, что все открытые си­ стемы имеют оконечные системы, включающие семь уровней архитекту­ ры, и промежуточные системы (например узлы коммутации).

47

2)допускается создание защищенных систем путем встраи­ вания услуг по обеспечению безопасности в архитектуру ЭМВОС на нескольких уровнях;

3)целесообразно, чтобы дополнительные функции, востре­ бованные СОИБ, без необходимости не дублировали су­ ществующие функции ЭМВОС;

4)любые возможные нарушения функциональной незави­ симости уровня ЭМВОС должны быть исключены;

5)количество реализуемых надежных функций должно быть минимальным;

6)в тех случаях, когда субъект зависит от способа обеспече­ ния ИБ, реализуемого средством защиты, которое встро­ ено субъектом на нижнем уровне архитектуры, любые промежуточные уровни должны функционировать таким образом, чтобы всякое нарушение безопасности исклю­ чалось;

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

Кроме того, архитектура ЭМВОС включает модель запроса, управления и использования защищенных услуг информацион­ ного взаимодействия, которая состоит из описания:

1)особенностей защиты взаимодействующих процессов;

2)условий применения услуг безопасности;

3)функционирования защищенного информационного об­ мена в режиме с установлением соединения;

4)функционирования защищенного информационного об­ мена в режиме без установления соединения.

В табл. 1.2 и 1.3 представлено распределение услуг и спосо­ бов безопасности по уровням архитектуры ЭМВОС (архитекту­ ра безопасности ЭМВОС).

48

Таблица 1.2

Распределение услуг безопасности по уровням архитектуры ЭМВОС (архитектура безопасности ЭМВОС)1

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

49

Таблица 1.2 (окончание)

Защита от ложного от­ каза получателя

Таблица 13

Распределение способов обеспечения безопасности по уровням ЭМВОС

50

Таблица 1.3 (окончание)

Таблица 1.4

Распределение услуг по обеспечению безопасности по уровням Интернет-архитектуры (архитектура безопасности сети Интернет)

Конфиденциальность отдель­ ных полей

Конфиденциальность потока трафика

51