Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Ответы на вопросы Мельникова в с пятого курса

.pdf
Скачиваний:
56
Добавлен:
03.02.2018
Размер:
4.49 Mб
Скачать

39. Основные понятия аутентификации

Аутентификация источника данных (data origin authentication) — подтверждение того, что источник полученных данных в действительности является тем, за кого себя выдаѐт:

1.аутентификация взаимодействующего субъекта (peer-entity authentication). Эта услуга обеспечивается n-ым уровнем архитектуры ЭМВОС и тем самым подтверждает субъекту (n+1)-го уровня, что субъект на противоположенной стороне соединения является тем субъектом (n+1)-го уровня, с которым необходимо провести ПИнО;

2.аутентификация источника данных (data origin authentication). Эта услуга обеспечивается n- ым уровнем архитектуры ЭМВОС и тем самым подтверждает субъекту (n+1)-го уровня, что источником поступивших данных является запрашиваемый субъект (n+1)-го уровня;

Аутентификация взаимодействующего субъекта (peer-entity authentication) — подтверждение того, что субъект на противоположенной стороне соединения является тем, с кем необходимо провести процедуру информационного обмена (ПИнО).

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

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

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

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

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

Вопрос 40.Сертификаты открытых ключей.

Когда открытый ключ сертифицирован, то, как правило, СЕРТ содержит открытый ключ (СЕРТ|ОК), сформированный УЦ, что гарантирует подлинность и принадлежность открытого ключа.

СЕРТ|ОК может быть помещѐн в репозитарий (БДК) Службы единого каталога (Directory) или другую аналогичную службу для распространения, или может быть отправлен назад владельцу при выполнении процедуры распределения.

Служба формирования СЕРТ ключа гарантирует связь открытого ключа с субъектом, которая обеспечивается УЦ. Если УЦ получает запрос на сертификацию ключа, то он формирует СЕРТ ключа. Такой ЦБ может предоставлять услуги по обеспечению ключами, например, доставка ключей. Когда взаимодействующие стороны используют асимметричный метод для безопасного обмена данными, то можно выделить следующие случаи:

при обеспечении целостности данных или аутентификации источника даны получатель требует СЕРТ соответствующего открытого ключа отправителя;

при обеспечении конфиденциальности отправитель требует от получателя, действующего СЕРТ открытого ключа;

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

Получатели подписанного сообщения, не взаимодействующие с УЦ, который выпустил СЕРТ|ОК для отправителя сообщения, могут также проверить подлинность СЕРТ|ОК отправителя путём поиска маршрута между УЦ, обслуживающим получателя подписанного сообщения, и УЦ, выдавший сертификат отправителю.

41. Стандарт MIME (Multipurpose Internet Mail Extensions)

Стандарт MIME (RFC-2045 и RFC-2046) предназначен для описания тела почтового сообщения в Internet. Он определяет расширение форматов данных тела сообщения (рис.15.8) по сравнению с RFC-822, допускающим только строки в ASCII-коде. MIME реализуется только на пользовательских частях системы (UA), оставаясь полностью прозрачным для всех существующих программ МТА.

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

IANA.

42. Системы оповещения об опасности в ВС

Служба оповещения об опасности (о нарушении безопасности)

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

-оповещение о реальных или очевидных попытках нарушения безопасности;

-оповещение о различных событиях безопасности, включая «штатные» события;

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

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

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

-определение (классификация) события (event discriminator), которая обеспечивает предварительный анализ события и определяет, куда следует направлять данные о событии: либо средству регистрации, либо средству обработки СОП;

-обработка СОП (alarm processor), которая заключается в реагировании на поступивший СОП.

Выделяются следующие фазы работы СЛОО:

-фаза обнаружения (detection phase), в которой происходит обнаружение события безопасности;

-фаза определения (классификации; discrimination phase), в которой осуществляется предварительная классификация события, которая устанавливает необходимость подачи СОП;

-фаза обработки сигнала оповещения (alarm processing phase), в которой будет подан СОП;

-фаза анализа (analysis phase), в которой событие, тем или иным образом затрагивающее обеспечение (состояние) безопасности, анализируется

исравнивается;

43. Протокол TFTP (Trivial File Transfer Protocol)

Для функционирования службы передачи файлов с использованием транспортного UDP-протокола применяется TFTP-протокол (протокол простой доставки файлов).

В соответствии с этим протоколом все файлы передаются блоками по

512 байтов (рис.14.9). Первые два байта (октета) каждого блока содержат код операции. Для установления соединения используются два сообщения: “Запрос на чтение файла” и “Запрос на запись файла”. После приема запроса начинается передача данных. Каждое сообщение “Доставка данных

содержит номер блока данных и сами данные (512 байтов). На каждый блок данных принимающая сторона отвечает квитанцией “Подтверждение принятого блока”. При возникновении ошибки генерируется специальная квитанция “Сообщение об ошибке”. Принимающая и передающая стороны устанавливают тайм-аут на ожидание следующего блока. Если блок данных или квитанция теряется, то передающая сторона по истечении тайм-аута повторяет передачу блока, а принимающая — передачу квитанции.

Сообщение

2 октета

N октетов

1 октет

M октетов

1 октет

 

 

 

 

 

 

“Запрос на

 

Название

 

Тип передаваемых

 

Заголовок

 

 

 

данных

 

чтение

запрашиваемого

 

 

 

00000000

 

00000000

 

 

файла

 

 

(Read Req.)

 

(двоичный или код

 

файла”

 

 

 

 

 

(File Name)

 

ASCII; Mode)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

“Запрос на

 

Название

 

Тип передаваемых

 

Заголовок

 

 

 

данных

 

запись

запрашиваемого

 

 

 

00000000

 

00000000

 

 

файла

 

 

(Write Req.)

 

(двоичный или код

 

файла”

 

 

 

 

 

(File Name)

 

ASCII; Mode)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

“Доставка

2 октета

2 октета

 

 

до 512 октетов

 

 

 

 

 

 

 

данных”

 

Номер

 

 

Заголовок

передаваемого

Данные

 

 

блока

 

(Data)

 

 

 

 

 

 

(Block)

 

 

 

 

 

“Подтверждение принятого блока - квитанция”

“Сообщение

об ошибке”

2 октета

2 октета

 

 

 

 

 

 

 

 

 

 

 

 

 

Заголовок

Номер приня-

 

 

 

того блока

 

 

 

 

 

 

 

(Ack)

(Block)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2 октета

2 октета

Q бит

1 октет

 

 

 

 

 

 

 

 

 

 

 

Заголовок

Код ошибки

 

 

 

 

 

Текст сообщения об ошибке

00000000

 

(Error)

(Err. Code)

 

 

 

 

 

 

 

 

Рис.14.9. Форматы сообщений TFTP-протокола

Этот протокол выполняет очень важную функцию: восстанавливает по-

следовательность фрагментов исходного файла, переданного с помощью

UDP-протокола.

44. Основные понятия обеспечения неотказуемости в ВС

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

Служба может использоваться для формирования данных, хранения данных или передачи данных. Она предусматривает формирование доказательства, которое может использоваться для доказательства того, что имел место некоторый вид события или действия, причем в дальнейшем невозможно отказаться от участия в этом событии или этого действия. В открытых системах ЭМВОС или Интернет-архитектуры СЛНТ может быть реализована в двух формах:

неотказуемостъ с доказательством источника, которое используется для защиты от ложного отказа отправителя от факта передачи им данных или составных элементов этих данных;

неотказуемостъ с доказательством доставки, которое используется для защиты от ложного

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

Политика обеспечения неотказуемости (ПЛНТ) может включать:

правила формирования доказательства, например, описание классов направлений деятельности, для которых целесообразно сформировать доказательство неотказуемости, описания ДТС(доверенная третья сторона), которые будут использоваться при формировании доказательства, роли ДТС, которые они могут исполнять, процедуры, которые должны выполнять объекты при формировании доказательства;

правила проверки (подтверждения подлинности) доказательства, например, описание ДТС, чьи доказательства приемлемы, для каждой ДТС, формы доказательства, которые будут приниматься от конкретной ДТС;

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

правила использования доказательства, например, описание целей, для достижения которых может использоваться доказательство;

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

45. Роли в процедурах аутентификации в ВС

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

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

Субъект аутентификации обладает функциями, которые необходимо инициализировать в течение процедуры аутентификации.

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

Термин доверенная третья сторона (ДТС, trusted third party) используется для определения ЦБ или его представителя, которому доверяют обе взаимодействующие стороны, относительно его деятельности по обеспечению безопасности. В данном случае ДТС обеспечивает проведение процедуры аутентификации.

ПРИМЕЧАНИЕ. Претендент и проверяющая сторона могут уточняться в нескольких функциональных компонентах, возможно принадлежащим различным системам.

46. Пятиуровневая архитектура управления в сетях Internet.

Протокол IP осуществляет передачу информации от узла к узлу сети в виде дискретных блоков-пакетов. TCP и UDP реализуют различные режимы доставки данных. ТСР — протокол с установлением соединения, а UDP — дейтаграммный протокол (без установления соединения). Над ними находятся прикладные службы (например, FTP)

Рис. Архитектура и совокупность протоколов ТСР/IP узла связи сети Internet.

Физический уровень – среда передачи данных.

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

Сетевой уровень - IP-протокол. Транспортный уровень – TCP, UDP. Прикладной уровень – прикладные задачи.