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

47. Роли в процедурах управления доступа в ВС

управление доступом (access control) — предотвращение неавторизован-ного использования ресурса, включая предотвращение использования ресурса нерегламентированным способом;

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

48. DNS-имена и RR-записи

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

Каждый узел имеет свой маркер, который имеет длину 0…63 октета. “Узлы-братья” не могут иметь один и тот же маркер, несмотря на то, что один и тот же маркер может использоваться для узлов, которые не являются “братьями”. Одно значение маркера является резервным, и это значение равно “0” (то есть, маркер нулевой длины), а сам маркер нулевой длины используется для обозначения корня древовидной структуры.

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

Каждый маркер представлен как поле размером в один октет, за которым следуют еще несколько октетов. Так как каждое DNS-имя заканчивается пустым маркером корневого узла, DNS-имя заканчивается нулевым байтом. Два бита высшего порядка каждого октета должны быть нулевыми, а оставшиеся шесть битов ограничены максимальным размером маркера: 63 октета или меньше.

В целях упрощения прикладных реализаций, общий размер DNS-имени (то есть, октеты маркера и октеты, определяющие размер маркера) ограничивается 255 октетами или меньшим числом октетов. Несмотря на то, что маркеры могут иметь любые значения из 8 битов в октетах, из которых формируется маркер, данный стандарт рекомендует строго придерживаться представленных в нем правил, определяющих синтаксис маркеров, который максимально согласован с существующими правилами синтаксиса. DNS-серверы и DNS-клиенты должны сравнивать маркеры в независящем от буквенного регистра режиме (то есть, “А=а”), исключая какие-либо аналогии с ASCII-кодом. Если используются неалфавитные коды, то тогда сравнение должно быть абсолютно точным.

Определение RR-записей. Все RR-записи имеют одинаковый формат, который представлен на рис.18.10.

DNS-имя (NAME)

ТИП (TYPE)

КЛАСС (CLASS)

“Время жизни”

(TTL)

“Размер поля “RDATA” (RDLENGTH)

“Данные” (RDATA)

Поля формата RR-записей (рис.18.10) имеют следующее назначение:

“NAME” — DNS-имя владельца записи, то есть имя сервера (IP-узла), которому принадлежит данная запись;

“TYPE” — два октета, содержащие один из кодов, который определяет тип записи;

“CLASS” — два октета, содержащие один из кодов, который определяет класс записи;

“TTL” — 32 бита представляют собой целое число без знака, определяющее временной интервал, в течение которого данная запись может храниться в кэш-

памяти перед тем как начнется следующая процедура обновления этой записи

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

Нулевое значение может также использоваться для быстро изменяющихся

данных;

“RDLENGTH” — 16-битовое целое положительное число, которое определяет размер поля “RDATA” в октетах;

“RDATA” — переменной длины последовательность октетов, которая представляет собой информационный ресурс (данные), за обновление которого отвечает его владелец. Формат данных в этом поле зависит от типа и класса

записи.

Существуют стандартные и специальные RR-записи.

49. Основные понятия аудита ИБ и системы оповещения об опасности в ВС

https://drive.google.com/file/d/0B9slrcaxomX3RER2M0FQZjM4QkE/view?usp=sharing

Аудит безопасности (АДБ) представляет собой независимые ревизию и анализ системных записей и основных направлений деятельности.

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

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

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

Фазы процедур АДБ и оповещения об опасности

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

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

3.фаза обработки сигнала оповещения (alarm processing phase), в которой может быть подан СОП или отправлено сообщение АДБ;

4.фаза анализа (analysis phase), в которой событие, тем или иным образом затрагивающее обеспечение (состояние) безопасности, анализируется и сравнивается, исходя из контекста, с ранее обнаруженными событиями, зарегистрированными в БДРА, а также с планом ранее предпринятых действий;

5.фаза объединения (aggregation phase), в которой записи из различных БДРА собираются в одну БДРА;

6.фаза формирования отчѐта (report generation phase), в которой из записей БДРА формируются отчѐты по результатам АДБ;

7.фаза архивирования (archiving phase), в которой записи из БДРА доставляются на архивное хранение (в архив результатов АДБ).

50. Политики обеспечения конфиденциальности в ВС

Политика обеспечения конфиденциальности (ПЛКН) является частью общей ПЛБ (политики обеспечения безопасности) и связана с обеспечением и использованием СЛКН (служба обеспечение конфиденциальности).

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

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

Описание информации

1. Политика может идентифицировать информацию различными способами, путём идентификации субъекта, который сформировал эту информацию;

2.путём идентификации группы субъектов, каждый из которых может читать эту информацию;

3.путём её размещения;

4.путём идентификации контекста, в соответствие с которым представлены данные (например, их функциональное предназначение).

Описание объектов/субъектов - Существует много способов описания объектов/субъектов включаемых в правила ПЛКН. Тем не менее существуют два наиболее общих альтернативных способа: на основе персональной и уникальной идентификации объектов/субъектов, и на основе привязки атрибутов к каждому объекту/субъекту. Также существуют две формы описания объектов/субъектов, которые в итоге и определяют два типа политик обеспечения безопасности: политики, основанные на параметрах подлинности, и политики, основанные на правилах. Эти политики рассматриваются в Главе 3.

51. Формы вспомогательной информации для обеспечения безопасности ВС.

Информация, необходимая для обеспечения ИБ, представляет собой вспомогательную информацию (ВИ), которая востребована СЛБ и используется ею. К ВИ относятся:

правила политики обеспечения безопасности (ПЛБ);

информация, необходимая для функционирования определенных СЛБ, например, ВИ для процедуры аутентификации (аутентификационная информация, authentication information) и ВИ для процедуры управления;

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

Существуют следующие 4 формы ВИ, которую используют СПБ:

метки безопасности, используемые при описании ПЛБ, которая применяется к взаимодействующему объекту/субъекту, каналу связи (соединению) или некоторой совокупности данных;

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

СЕРТ безопасности(СЕРТ|Б), применяемые для защиты ВИ, получаемой из ЦБ или ДТС и используемой одной или несколькими взаимодействующими сторонами;

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

52. Формат заголовка IPv6-пакета. Заголовки расширения в IPv6-пакете

Формат заголовка IPv6-пакета

Заголовок IPv6-пакета включает следующие поля:

“Версия IP-протокола” (Version) — 4-битовое поле, содержащее значение “6”;

“Класс трафика” (Traffic Class) — 8-битовое поле, которое указывает на класс трафика;

“Маркер потока” (Flow Label) — 20-битовое поле, которое содержит маркер потока;

“Размер поля полезной нагрузки” (Payload Length) — 16-битовое беззнаковое целое число, которое указывает на размер поля полезной нагрузки в октетах, следующего сразу после заголовка (включая заголовки расширения);

“Следующий заголовок” (Next Header) — 8-битовый определитель, который указывает на тип заголовка, следующего сразу за этим заголовком;

“Число ретрансляций” (Hop Limit) — 8-битовое беззнаковое целое число, которое указывает на максимальное число ретрансляционных участков. Это число уменьшается на единицу каждым IP-узлом, через который проследовал IPv6-пакет. Если это поле содержит нулевое значение, то тогда IPv6-пакет уничтожается;

“Адрес отправителя пакета” (Source Address) — 128-битовый адрес отправителя пакета;

“Адрес получателя пакета” (Destination Address) — 128-битовый адрес конечного получателя пакета, то есть которому предназначен данный пакет. (Однако, возможно это

— не самый последний получатель, если в IPv6-пакете представлен заголовок маршрутизации.)

Заголовки расширения в IPv6-пакете

В IPv6-протоколе предусмотрена доставка дополнительной (служебной) закодированной информации сетевого уровня, которая может быть размещена в IPv6-пакете между IPv6заголовоком и заголовком верхнего уровня. Для такой доставки существует несколько так называемых заголовков расширения, причём каждый из них идентифицируется собственным значением в поле “Следующий заголовок”. На рис.12.12 приведены примеры нескольких заголовков расширения в IPv6пакетах. За одним исключением, заголовки расширения не

проверяются или не обрабатываются ни одним IP-узлом на протяжении всего маршрута доставки IPv6-пакета, причѐм до тех пор, пока последний не достигнет IP-узла (или каждого IPузла из группы IP-узлов, в случае групповой рассылки пакета), адрес которого содержится поле “Адрес получателя пакета” IPv6-заголовка.

Полная (с точки зрения функциональной совместимости) программная реализация IPv6протокола включает следующие заголовки расширения:

“Hop-by-Hop Options” — “Дополнительные функции: ретрансляция”;

“Routing” (Type 0) — “Маршрутизация”;

“Fragment” — “Фрагментация”;

“Destination Options” — “Дополнительные функции: узел-получатель”;

“Authentication” — “Аутентификация” (определен в стандарте RFC-4302);

“Encapsulating Security Payload” — “Повторное обрамление поля полезной нагрузки с целью ее защиты” (определён в стандарте RFC-4303)

53. Информация, необходимая для обеспечения неотказуемости в ВС

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

Неотказуемость источника (non-repudiation of origin) Доказательство должно включать следующие данные (которые могут быть подписаны или нотариально заверены):

УИД источника (отправителя);

переданные данные или цифровой отпечаток данных.

Кроме того, доказательство может включать следующие данные:

УИД получателя;

дата и время передачи данных.

Неотказуемость доставки (non-repudiation of delivery) Доказательство должно включать следующие данные (которые могут быть подписаны или нотариально заверены):

Кроме того, доказательство может включать следующие данные:

УИД источника (отправителя);

дата и время получения данных.

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

УИД центра доставки;

дата и время, когда было получено сообщение от получателя о его готовности к приёму;

дата и время, когда была завершена доставка центром доставки;

дата и время, когда центр доставки был не способен осуществить доставку;

возможные причины не доставки (например, разрыв соединения);

описание требований к управлению, которые были выполнены при доставке сообщения.

54. Организация СОИБ в ВС