Пример отчета

1. Исходные данные:

Рассмотрим систему, содержащую два субъекта и два объекта:

• S₁, с уровнем безопасности «секретно»;

• S₂ с уровнем безопасности «несекретно»;

• О₁ с уровнем секретности «несекретно»;

• О₂ с уровнем секретности «секретно».

Таким образом, мы можем построить решетку уровней:

1 ------------S_l------------O₂-------- «секретно»

0-----------S₂-----------О₁----------«несекретно»

Очевидно, что S₁ может читать O₁ и О₂ а S₂ – только O₁. Записывать информацию разрешено S₁ в О₂, а S₂ в О₁ и О₂. Тогда файл описания модели будет выглядеть следующим образом:

// листинг файла инициализации b_l_m.ini

//1 - секретно; 0 - несекретно

S(1, 1, 0,0,0,0,0,0,0);

S(2, 0, 0, 0, 0, 0, 0, 0, 0);

O(1, 0, 0, 0, 0,0, 0, 0,0);

О(2, 1, 0, 0,0,0, 0, 0, 0);

ATTRNAME seclevelS IS ATTRS(1);

ATTRNAME seclevelO IS ATTRO(1);

RULES

READO IF(seclevelS[THISS]>=seclevelO[THISO])

WRITEO IF(seclevelO[THISO]>=seclevelS[THISS])

ENDRULES

Prefile и postfiie не используются.

2. В ходе работы с реализованной в п.(1) данного отчета моделью Белла-ЛаПадула была проведена проверка на доступ к объектам по чтению и записи. Данные операции выполнялись в соответствии с правилами NRU и NWD: S₁ смог читать О₁ и О₂ а S₂ - только О₁. Записывать информацию было разреше­но S₁ в O_2, , a S₂ в О₁ и O₂. Операция, не определенная в модели Белла-ЛаПадула (например, смена атрибутов объекта), разрешена, что нарушает за­щищенность информации в системе.

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

// новый вид файла инициализации - b_I_m-z.ini

S(1, 1, 0,0,0,0,0,0,0);

S(2, 0, 0,0,0,0,0,0,0);

O(1, 0, 0,0,0,0,0,0,0);

O(2, 1, 0,0,0,0,0,0,0);

ATTRNAME seclevelS IS ATTRS(1);

ATTRNAME seclevelO IS ATTRO(1);

RULES

READO

// если второй субъект хочет прочитать второй объект, то его уровень повышается до необходимого

if(THISS==2 && THISO==2)

{

make_secret(); // прописываем новые атрибуты субъекта

seclevelS[THISS]=AS(1,2), // заносим изменения в массив первого атрибута. Это разрешает чтение второго объекта

}

IF(seclevelS[THISS]>=seclevelO[THISO])

WRITEO

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

if(THISS==2)

{

make_nonsecret();

seclevelS[THISS]=AS(1,2);

}

IF(seclevelO[THISO]>=seclevelS[THISS])

ENDRULES

Содержимое файла prefile:

void make_secret(void)

{

S(2, 1, 0,0,0,0,0,0,0);

}

void make_nonsecret(void)

{

S(2, 0, 0,0,0,0,0,0,0);

}

Заполнение массива первых атрибутов субъектов seclevelS[] происходит в файле b_l_m-z.ini, т.к. данный массив не является глобальной переменной. Его изменения допустимы только в файле описания модели. Дополнительный файл postfile ничего не содержит.

После внесенных изменений была произведена проверка работы опре­деленной таким образом Z-системы. Второй субъект повысил свой уровень секретности, ему было разрешено читать информацию, хранящуюся во втором объекте, затем он понизил степень доверия, и ему было разрешено произвести запись в объект №1. Такая последовательность действий не противоречит правилам модели Белла-ЛаПадула, но приводит к утечке информации.

4. Далее, чтобы избежать проблему Z-системы, файл описания был изменен следующим образом:

S(1, 1, 0,0,0,0,0,0,0);

S(2, 0, 0,0,0,0,0,0,0);

O(1, 0, 0,0,0,0,0,0,0);

O(2, 1, 0,0,0,0,0,0,0);

ATTRNAME secievelS IS ATTRS(1);

ATTRNAME seclevelO IS ATTRO(1);

RULES

READO

if(THISS==2 && THISO==2) // для чтения секретного объекта субъект №2 повышает степень доверия

{

make_secret();

seclevelS[THISS]=AS(1,2);

}

IF(seclevelS[THISS]>=seclevelO[THISO])

WRITEO

// субъект №2 понижает уровень секретности для записи в несекретный

// объект №1

if(THISS==2)

{

make_nonsecret();

seclevelS[THISS]=AS(1,2);

}

// правило слабого спокойствия: если запись в несекретный объект №1, то вернуть субъект на уровень «секретно» и т.о. не разрешить запись

if(THISS==2 &&THISO==1)

{

rnake_secret();

seclevelS[THISS]=AS(1,2);

}

IF(seclevelO[THISO]>=seclevelS[THISS])

ENDRULES

Файлы prefile и postfile остались прежними.

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

Контрольные вопросы по лабораторной работе

1. На основе каких идей построена модель Белла-ЛаПадула?

2. Какое правило позволяет решить проблему троянских коней?

3. Приведите примеры критики модели Белла-ЛаПадула.

4. В чем заключается проблема системы Z?

5. Как можно избежать недостатков Z-системы?

Лабораторная работа № 3.

Ролевое управление доступом

Цель работы: овладеть методикой формирования моделей безопасности, в основу которых положено ролевое управление доступом. Исследовать возможности моделей безопасности, в основу которых положено ролевое управление доступом.

Средства: методика проведения лабораторной работы, теоретический материал, персональный компьютер.

Время: 4 часа

Теоретические сведения

Ролевое управление доступом

Ролевое управление доступом (Role Based Access Control) было пред­ложено в качестве альтернативы и дополнения к дискреционному и мандатно­му.

Природа разрешений, выделенных роли, существенно отличается от обычных операций чтения, записи, выполнения и т.д., поддерживаемых типич­ными операционными системами. В модели рассматривается авторизованная операция - выполнение программы на множестве связанных элементов дан­ных. Это очень важное понятие позволяет осуществлять авторизацию в терми­нах абстрактных операций, встроенных в процедуры преобразования. Напри­мер, роли кассира в банке могут быть выделены скорее кредитные и дебитные операции с бюджетами, чем более общие операции чтения и записи. Это дает возможность RBAC рассматривать безопасность приложений в терминах опе­раций этих приложений в противоположность универсальным операциям чте­ния и записи в операционных системах общего назначения.

Роли были использованы в некоторых продуктах управления доступом 70-80х гг., например, в RACF фирмы IBM. Для подобных продуктов характерно использование ролей в административных целях. Например, в RACF имеется роль Operator с правом доступа ко всем ресурсам, но без возможности изме­нить разрешения доступа, роль Special с возможностью изменить разрешения доступа, но без права доступа к ресурсам, и роль Auditor с правом доступа к контрольным журналам (содержащая, помимо всего прочего, события, сгенерированные ролями Operator и Special, не имеющими доступа к контрольному журналу).

С основной концепцией роли связано два аспекта:

• ролям назначаются пользователи и

• ролям назначаются привилегии и разрешения.

Пользователь, назначенный роли, таким образом, приобретает привиле­гии и разрешения этой роли.

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

Под термином «разрешение» будем понимать права доступа к конкрет­ным объектам данных, например, файлам. Большинство операционных систем предоставляют такие разрешения как чтение, запись, исполнение и т.д. Для контроля на прикладном уровне хотелось бы иметь разрешения, связанные с прикладной областью. Например, те же дебитные и кредитные операции над бюджетным объектом. Пользователь, уполномоченный выполнять кредитную операцию над бюджетом, не должен иметь права произвольного доступа чте­ния и записи к бюджетному балансу. Следовательно, очень важно, чтобы RBAC, ориентированное на приложение, каким-либо образом удовлетворяло этому требованию.

Существует два подхода к контролированию разрешений при ориента­ции на приложения:

• Первый, менее детализированный, - предоставить разрешения, пол­ностью основанные на том, какие операции или процедуры преобра­зования может выполнять данная роль. Так, например, кассира в бан­ке можно уполномочить выполнять кредитные и дебитные операции. Если эти операции разрешены для всех бюджетов, то кредитные и де­битные операции могут быть авторизованы на выполнение операций чтения и записи бюджетов.

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

Такая детализация может быть обеспечена непосредственно систе­мой управления доступом.

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

Преимуществом централизованного подхода является обеспечиваемый им строгий контроль и централизация ответственности. Недостатком является увеличение затрат, когда система становится слишком большой. Кроме того, запросы на добавление пользователей ролям идут со стороны пользователей, и хорошая система должна позволять соответствующим пользователям осуще­ствлять это непосредственно с центрального пункта управления. Заметим, что наиболее выгодно использовать здесь RBAC. Можно создавать роли админи­стрирования назначения пользователей и выдавать право на включение в роль новых пользователей, но только для некоторого подмножества ролей в систе­ме.

Недостатки ролевого управления доступом

Среди недостатков ролевого управления доступом необходимо отме­тить;

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

• возможность продолжительного или частого использования роли.

Вопрос использования ролей связан с тем, как пользователь может акти­визировать различные роли в системе. Одна из возникающих при этом очевид­ных проблем: может ли пользователь исполнять несколько ролей одновремен­но? Так, пользователь, имеющий роль врача первой помощи, должен автома­тически и одновременно быть в роли врача.

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

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

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

С целью решения подобных проблем предлагаются следующие правила назначения пользователей ролям:

• во многих приложениях некоторые роли считаются взаимоисключаю­щими;

Например, роли руководителя отдела и руководителя проекта не должны одновременно принадлежать одному и тому же субъекту;

• по возможности использовать иерархический принцип.

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

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

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