2. Изолированная программная среда. Изолированная или замкнутаяпрограммная среда представляет собой расширение модели избирательного разграничения доступа. Здесь правила разграничения доступа формулируются следующим образом.

1. Для любого объекта операционной системы существует владелец.

2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.

3. Для каждой четверки субъект-объект-метод-процесс возможность доступа определена однозначно.

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

5. Для каждого субъекта определен список программ, которые этот субъект может запускать.

При использовании изолированной программной среды права субъекта на доступ к объекту определяются не только правами и привилегиями субъекта, но и процессом, с помощью которого субъект обращается к объекту. Можно, например, разрешить обращаться к файлам с расширением .doc только программам Word, Word Viewer и WPview.

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

3. Полномочное разграничение доступа без контроля информационных потоков. Полномочное или мандатное разграничение доступа (mandatory access control) обычно применяется в совокупности с избирательным. При этом правила разграничения доступа формулируются следующим образом.

1. Для любого объекта операционной системы существует владелец.

2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.

3. Для каждой тройки субъект-объект-метод возможность доступа определена однозначно.

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

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

6. Каждый субъект доступа имеет уровень допуска. Чем выше числовое значение уровня допуска, тем больший допуск имеет субъект. Нулевое значение уровня допуска означает, что субъект не имеет допуска. Обычно ненулевое значение допуска назначается только субъектам-пользователям и не назначается субъектам, от имени которых выполняются системные процессы.

7. Если:

- объект является объектом полномочного разграничения доступа,

- гриф секретности объекта строго выше уровня допуска субъекта, обращающегося к нему,

- субъект открывает объект в режиме, допускающем чтение информации, то доступ субъекта к объекту запрещен независимо от состояния матрицы доступа.

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

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

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

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

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

1. Для любого объекта операционной системы существует владелец.

2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.

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

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

5. В множестве объектов выделяется множество объектов полномочного разграничения доступа. Каждый объект полномочного разграничения доступа имеет гриф секретности. Чем выше числовое значение грифа секретности, тем секретнее объект. Нулевое значение грифа секретности означает, что объект несекретен. Если объект не является объектом полномочного разграничения доступа или если объект несекретен, администратор может обратиться к нему по любому методу, как и в предыдущей модели разграничения доступа.

6. Каждый субъект доступа имеет уровень допуска. Чем выше числовое значение уровня допуска, тем больший допуск имеет субъект. Нулевое значение уровня допуска означает, что субъект не имеет допуска. Обычно ненулевое значение допуска назначается только субъектам-пользователям и не назначается субъектам, от имени которых выполняются системные процессы.

7. Если:

• объект является объектом полномочного разграничения доступа,

• гриф секретности объекта строго выше уровня допуска субъекта, обращающегося к нему,

• субъект открывает объект в режиме, допускающем чтение информации, то доступ субъекта к объекту должен быть запрещен независимо от состояния матрицы доступа. Это - так называемое правило NRU (Not Read Up-не читать выше).

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

9. Если:

• объект является объектом полномочного разграничения доступа,

• гриф секретности объекта строго ниже уровня конфиденциальности процесса, обращающегося к нему,

• субъект собирается записывать в объект информацию, то доступ субъекта к объекту должен быть запрещен независимо от состояния матрицы доступа. Это правило разграничения доступа предотвращает утечку секретной информации. Это - так называемое правило NWD (Not Write Down - не записывать ниже).

10. Понизить гриф секретности объекта полномочного разграничения доступа может только субъект, который:

- имеет доступ к объекту согласно правилу 7;

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

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

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

Пользователи операционных систем, реализующих данную модель разграничения доступа, вынуждены использовать программное обеспечение, разработанное с учетом этой модели В противном случае пользователи будут испытывать серьезные проблемы в процессе работы с объектами операционной системы, имеющими ненулевой гриф секретности. Пусть, например, пользователь работает в среде Windows c установленным дополнительным пакетом защиты, реализующим данную модель разграничения доступа. Пользователь открывает с помощью Microsoft Word два документа, один из которых является секретным. Уровень конфиденциальности процесса winword.exe повышается, и пользователь теряет возможность сохранить изменения, внесенные им в данном сеансе работы в несекретный документ.

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

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

---

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

1.4. Идентификация, аутентификация и авторизация субъектов доступа
Основные определения

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

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

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

Авторизация субъекта доступа происходит после успешной идентификации и аутентификации. При авторизации субъекта операционная система выполняет действия, необходимые для того, чтобы субъект мог начать работу в системе. Например, авторизация пользователя в операционной системе UNIX включает в себя порождение процесса, являющегося операционной оболочкой, с которой в дальнейшем будет работать пользователь. В операционной системе Windows NT авторизация пользователя включает в себя создание маркера доступа пользователя, создание рабочего стола и запуск на нем от имени авторизуемого пользователя процесса Userlnit, инициализирующего индивидуальную программную среду пользователя. Авторизация субъекта не относится напрямую к подсистеме защиты операционной системы. В процессе авторизации решаются чисто технические задачи, связанные с организацией начала работы в системе уже идентифицированного и аутентифицированного субъекта доступа.

---

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

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

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

---

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

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

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

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

---

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

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

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

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

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

- пароль, вводимый пользователем, не отображается на экране компьютера;

- ввод пароля из командной строки недопустим.

Кроме того, пользователи операционной системы должны быть проинструктированы о:

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

- необходимости немедленной смены пароля после его компрометации;

- необходимости регулярной смены пароля;

---

Смотрите также файлы

• Контрольно измерительные материалы по русскому языку.docx

• Белорусский государственный университет г. Г. Головенчик цифровая мировая экономика.pdf

• Образующая линия направляющая линия.ppt

• білім алушыларды білімін толытыру.docx

• Module 1 Lifestyles Вводный раздел.doc