Мельников Д. А. - Информационная безопасность открытых систем - 2013
.pdfнеобходима для проведения нескольких аудиторских проверок с целью точного определения, какие запросы доступа отправля лись инициатором и каким инициатором.
Политика аудита может потребовать, чтобы некоторые или все попытки получения доступа были зарегистрированы (за писаны). Следовательно, могут потребоваться надежные сред ства записи, которые должны быть доступны для реализуемого способа УД. Политика аудита также может затребовать инфор мацию о процедуре способа УД, которая подлежит записи (на пример обстоятельства, на основании которых в доступе было отказано). ПЛУД может потребовать, чтобы все процедуры до ступа проходили аудиторскую проверку, и в каждом таком слу чае способ УД будет функционально зависеть от доверенной службы регистрации (записи).
В тех случаях, когда необходима идентифицируемость инициатора, перед началом процедуры предоставления до ступа инициатор всегда должен проходить процедуру аутен тификации. Важно понимать, что аутентификация и УД, даже несмотря на то что они очень часто взаимосвязаны между со бой, не всегда реализуются и контролируются одними и теми же ЦБ, т.е. нет -необходимости совмещения этих функций. Информация, которая используется при аутентификации, может понадобиться для получения ВИУД, привязанной к инициатору.
Идентифицируемость процедуры доступа в условиях ано нимности может быть обеспечена следующим образом:
•инициатор получает из ЦБ ССБ ВИУД, которая содер жит соответствующий идентификатор аудита. Приобре тение ВИУД регистрируется (записывается): параметр подлинности инициатора и идентификатор аудита со храняются в файле результатов аудиторской проверки ВИУД, выданной в рамках ССБ;
•инициатор использует ВИУД, привязанную к нему, для получения доступа к целевому объекту. ФПРР-модуль ССБ, в котором расположен целевой объект, получает
234
ВИУД, привязанную к инициатору, и сохраняет иденти фикатор аудита и запрос доступа в своем файле результа тов аудиторской проверки;
•на основании аудиторской информации, полученной из ССБ, в котором расположен целевой объект, и ВИУД, привязанной к инициатору, и выданной в рамках ССБ, ЦБ ССБ может идентифицировать инициатор, также ис пользуя идентификатор аудита. С помощью этих средств инициатор может стать идентифицируемым при запросе им соответствующего доступа.
Если имеет место конфликт между желанием инициатора оставаться анонимным и требованием ССБ, в котором располо жен целевой объект, знать параметр подлинности инициатора, то в доступе может быть отказано. Решение в такой конфликт ной ситуации зависит от ПЛУД ССБ, в котором расположен це левой объект.
4 .5 .5 . Д р у ги е С Л Б . связанны е с У Д
При проведении процедуры запроса доступа привлекается не только служба УД, но могут привлекаться и другие СЛБ:
•служба аудита регистрирует (записывает) произвольную информацию о запросе доступа;
•служба идентификации дополнительно осуществляет контрольную проверку имени или наименований объек тов, которые формально отвечают за активизацию про цедуры запроса доступа;
•служба взимания платы гарантирует, что на счет посту пит соответствующая сумма, необходимая для использо вания доступного ресурса.
Информация, которая необходима для обеспечения каждой из рассмотренных служб при проведении процедуры запроса до ступа, если рассуждать логически, различна. ВИПР, необходи мая для УД, наименование счета для оплаты и идентификатор ответственного объекта для обеспечения идентифицируемости
235
являются данными, которые M O iy r быть различны. Однако в некоторых прикладных системах требуется использовать одну и ту же информацию (например параметр подлинности для УД) в каждом из указанных случаев. Это может привести к нештат ной ситуации, особенно в случае ретрансляции запросов досту па. Предпочтительнее хранить различные типы информации отдельно.
4.6. Обмен СЕРТ|УД между компонентами
4 .6 .1 . Р етрансляци я н е с ко л ь ки х С Е Р Т |У Д
В некоторых случаях может понадобиться несколько СЕРТ|УД для обеспечения сложной ПИнО.
4.6.1.1. Пример
Предположим (рис. 4.5), что пользователь U обращается к прикладной системе А 1, чтобы последнее запросило доступ к прикладной системе А2. Каждый запрос доступа формируется А1 и направляется А2. Однако А2 может использовать службы другой прикладной системы АЗ с целью удовлетворения запроса. В свою очередй, АЗ для решения этой задачи могут понадобить ся службы прикладной системы А4.
Рассмотрим взаимосвязь между А 1 и А2, а также СЕРТ|УД, которые могут быть использованы при запросе доступа А 1 к А2. Очевидно, что могут потребоваться два СЕРТ|УД: для пользова теля U и для прикладной системы Л У.
Существуют три класса сертификатов, которые могут потре боваться пользователю U и прикладной системе А 1:
U ---- - А1 ---- ► А 2 ---- ► АЗ ---- ► А4
Рис. 4.5. Ретрансляция нескольких СЕРТ|УД
•СЕРТ|УД, необходимые для доступа к А2 и действитель ные для всех процедур (операций);
236
•СЕРТ|УД, необходимые для доступа к А2 и действитель ные для группы (совокупности) процедур (операций);
•СЕРТ|УД, необходимые для доступа к А2 и действитель ные для одной процедуры (операции).
В принципе, каждый СЕРТ|УД можно получить в разных ЦБ ССБ.
СЕРТ|УД, действительные для всех процедур (операций), доставляются в фазе установления соединения или начальной фазе процедуры информационного обмена.
Когда СЕРТ|УД определяют набор допустимых процедур (операций), то они остаются неизменными до тех пор, пока не будут доставлены другие СЕРТ|УД этого класса.
СЕРТ|УД, действительные для одной процедуры (опера ции), ограничиваются только этой процедурой (операцией).
4.6.1.2. Обобщение
Далее рассмотрим взаимосвязь между А2 и А2, а также СЕРТ|УД, которые могут быть использованы при запросе досту па А2 к АЗ. Очевидно, что могут потребоваться три СЕРТ|УД: для пользователя U, для прикладной системы А 1 и для приклад ной системы А2.
СЕРТ|УД для пользователя U и прикладной системы А1, предназначенные для использования при доступе к А2, могут или не могут быть применимы и при доступе к АЗ. Если они примени мы, то каждый из этих сертификатов может быть любым серти фикатом из трех классов, рассмотренных выше. Если же они не применимы, то пользователь U или прикладная система Л У(или оба) при запросе доступа к А2 должны получить дополнительный СЕРТ|УД для доступа к АЗ, который также может быть любым сертификатом из трех классов, рассмотренных выше.
Схема может быть обобщена и для взаимодействия между АЗ и А4, при этом могут понадобиться дополнительные сертифика ты для U, А 1 или А2.
4.6.1.3. Упрощения
Обычно необходим только СЕРТ|УД от пользователя U или от прикладной системы А1. СЕРТ|УД, действительные только
237
для одной процедуры (операции), используются крайне редко. СЕРТ|УД от U, предназначенный для доступа к А2, может ре транслироваться системой А 1, даже если последняя его не ис пользует.
4.7. Управление доступом в ЭМВОС и Интернет-архитектуре
4 .7 .1 . О б щ и е п о л о ж ен и я
УД может использоваться в фазе доставки данных виртуаль ного соединения или время от времени в течение функциониро вания виртуального соединения. Эта служба применима к про токолам с установлением или без установления соединений.
4 .7 .2 . И споль зов ание У Д внутри уровней Э М В О С и И н тер н ет-ар хи тектуры
УД касается только следующих уровней ЭМ ВОС и Интернетархитектуры:
•сетевой (3-й) уровень;
•транспортный (4-й) уровень;
•прикладной (7-й) уровень (5-й уровень для Интернетархитектуры).
4.7.2.1. Использование УД на сетевом уровне
УД, применяемое на сетевом уровне, позволяет управлять доступом к сетевым узлам и/или из них, к узлам подсетей и / или из них и к ретрансляционным узлам и/или из них. УД на сетевом уровне может иметь многоцелевое применение. Напри мер, оно позволяет оконечным системам контролировать фор мирование сетевых соединений или отклонять нежелательные вызовы. Кроме того, оно позволяет одной или нескольким под сетям контролировать использование ресурсов сетевого уровня. В отдельных случаях контроль использования ресурсов сетево го уровня связан с оплатой за пользование сетью.
238
Способы УД, используемые на сетевом уровне, не выходят за пределы одного и того же уровня.
4.7.2.2. Использование УД на транспортном уровне
УД, применяемое на транспортном уровне, позволяет управ лять доступом к объектам сеанса связи и/или из них. Различные прикладные процессы (системы), обеспечиваемые одной и той же оконечной системой, не могут контролироваться раздельно, если они используют соединение на транспортном уровне со вместно.
Способы УД, используемые на транспортном уровне, не вы ходят за пределы одного и того же уровня.
4.7.2.3. Использование УД на прикладном уровне
Модель обеспечения безопасности верхних уровней пред ставлена в стандарте ISO/IEC 10745:1995.
4.8. Проблема уникальности (неединственность) параметров подлинности для УД
Рассмотрим следующие два примера, демонстрирующие проблемы назначения и использования параметров подлинно сти для УД:
•если пользователь именуется Иван Петров, и в рамках прикладной системы ему было присвоено это весьма рас пространенное имя, то в соответствующем ССБ будет существовать конкретная последовательность символов «Иван Петров» в качестве его индивидуального параме тра подлинности для УД. Затем одна и та же последова тельность символов может быть перемещена в атрибут управления с целью предоставления ему некоторых ви дов доступа. В дальнейшем Иван Петров может покинуть этот ССБ, а другой пользователь, также именуемый Иван Петров, может войти в этот же ССБ, и которому также может быть присвоен индивидуальный параметр подлин ности «Иван Петров». Если последовательность симво-
239
лов «Иван Петров» по-прежнему остается в атрибуте управления, то впоследствии новый Иван Петров будет иметь возможность получить те виды доступа, которые были разрешены предыдущему Ивану Петрову;
•если целевой объект обозначен с помощью последователь ности символов, которая в ССБ является его параметром подлинности для УД, то такая же последовательность символов может использоваться в привилегированном атрибуте с целью предоставления пользователю некото рых видов доступа. Позднее целевой объект может быть удален из этого ССБ, а еще позднее может быть сфор мирован новый целевой объект с таким же параметром подлинности для УД. Если привилегированный атрибут, предоставленный пользователю, не был изменен, то у пользователя появится возможность получения доступа к новому целевому объекту.
Предполагается, что в рамках ССБ параметры подлинности для УД являются уникальными. Однако параметр подлинности может быть действителен только в течение определенных пе риодов времени или, фактически, может быть назначен навсег да. Когда параметр подлинности действителен только в течение определенных периодов времени, то в любой момент времени данный типа атрибута, в котором представлен параметр под линности для УД в качестве значения атрибута, имеет вполне определенный смысл. Однако, если этому не уделять соответ ствующего внимания, то один и тот же тип и значение атрибута могут использоваться повторно. Если в ССБ по-прежнему имеет место любой из ранее используемых типов атрибута или значе ний атрибута, то может появиться брешь (уязвимость) в системе обеспечения безопасности.
Существуют два способа решения этой проблемы. Перед тем как определить новый тип атрибута или новое значение атрибу та для УД, ЦБ ССБ должен гарантировать, что этот тип атрибу та или это значение атрибута для УД:
•в настоящее время не назначены;
•раньше никогда не использовались.
240
В первом случае ЦБ ССБ необходимо гарантировать, что каждый раз тип атрибута или значение атрибута для УД будет удалено, а инициатор или целевой объект еще не обладают дан ным типом атрибута или значением атрибута для УД. Когда это невозможно, то должен быть определен период действия (выра женный явно или не явно) для каждого типа атрибута или зна чения атрибута для УД. В течение периода действия необходимо хранить запись обо всех удаленных типах атрибута или значени ях атрибута для УД.
Во втором случае должен быть определен уникальный па раметр подлинности для УД (также именуемый постоянным идентификатором), значение которого было присвоено толь ко один раз и которое никогда не будет повторно использо ваться.
4.9. Распределение компонентов УД
Основные ФПРИ, ФПРР и УД могут быть реализованы с помощью одного или нескольких ФПРИ- и ФПРР-модулей, которые могут, соответственно, комбинироваться. Реализация этих функций зависит от условий размещения ФПРИ- и ФПРРмодулей, связей между ними или их возможного распреде ления.
| ф п р и -модуль|
|фПРИ-1модуль|
1
Рис. 4.6. Внутреннее и внешнее размещение Ф ПРИ-модуля
241
Рис. 4.7. Варианты размещения Ф ПРИ - и ФПРР-модулей
4 .9 .1 . Р еал изационны е аспекты
Наибольший практический интерес представляют следую щие вопросы:
•число и размещение ФПРИ- и ФПРР-модулей;
•процедуры информационного обмена между инициа торами, ФПРИ- и ФПРР-модулями и целевыми объ ектами.
Влюбом ССБ один или несколько ФПРИ-модулей могут располагаться между каждым инициатором и целевым объек том, причем так, чтобы инициатор мог запрашивать доступ к целевому объекту только через ФПРИ-модуль. Существует не сколько возможных вариантов размещения ФПРИ- и ФПРРмодулей. А именно:
•ФПРИ-модули могут быть распределены различными способами, как это показано на рис. 4.6,4.7 и 4.8;
242
•ФПРР-модули могут быть совмещены (жестко связаны) с ФПРИ-модулями (а могут быть и не совмещены);
•ФПРР-модуль может обслуживать один или несколько ФПРИ-модулей;
•ФПРИ-модуль может использовать один или несколько ФПРР-модулей.
Существует несколько возможных вариантов организации соединений между представленными компонентами.
4 .9 .2 . Р азм ещ ен и е Ф П Р И - и Ф П Р Р -м о д ул ей
ФПРИ-модули могут быть встроены (внутри) в оконечную систему или размещаться (вне системы) между оконечной си стемой и сетью, используемой для связи с другими оконечными системами (рис. 4.6). Некоторые реальные системы могут иметь встроенные и внешние ФПРИ-модули одновременно, что связа но с различными аспектами процедуры УД. Преимущества и не достатки встроенных и внешних ФПРИ-модулей определяются ПЛБ и связаны с их надежным внедрением в систему, а также другими условиями, которые здесь не рассматриваются.
Таким же образом и ФПРР-модули быть встроены (внутри) в оконечную систему или могут размещаться вне нее (рис. 4.7). При обслуживании ФПРР-модулями одного внешнего ФПРИмодуля желательно, но не обязательно, чтобы ФПРР-модуль также размещался вне системы. При обслуживании ФПРРмодулями нескольких ФПРИ-модулей, расположенных в раз ных оконечных системах, ФПРР-модуль будет, как правило, размещаться вне системы. Как было отмечено ранее, оконечная система может применять несколько ФПРИ-модулей, что свя зано с различными аспектами процедуры УД. В таких случаях указанные ФПРИ-модули могли бы обслуживаться одиночным внутренним или внешним ФПРР-модулем, или могло бы ис пользоваться несколько специализированных ФПРР-модулей. Совмещение (жесткая связка) ФПРИ- и ФПРР-модулей может иметь преимущества, связанные с повышением эффективности функционирования и быстродействия (снижение задержки).
243