Защита инф. 1 раздел.

Раздел 1. Общие вопросы обеспечения информационной безопасности

Угрозы безопасности операционной системы

Прежде, чем начинать разговор об организации эффективной и надежной защиты информации в операционных системах, определим круг угроз, от которых необходимо защититься. Угрозы безопасности операционной системы существенно зависят от условий эксплуатации системы, от того, какая информация хранится и обрабатывается в системе, и т.д. Например, если операционная система используется главным образом для организации электронного документооборота, наиболее опасны угрозы, связанные с несанкционированным доступом (НСД) к файлам. Если же операционная система используется как платформа для провайдера Internet-услуг, очень опасны атаки на сетевое программное обеспечение операционной системы.
Все попытки взлома защиты компьютерных систем можно разделить на три группы:
- атаки на уровне операционной системы;
- атаки на уровне сетевого программного обеспечения;
- атаки на уровне систем управления базами данных.

Атаки на уровне систем управления базами данных

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

Атаки на уровне операционной системы

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

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

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

Классификация угроз по характеру воздействия на операционную систему:
- активное воздействие - несанкционированные действия злоумышленника в системе;
- пассивное воздействие - несанкционированное наблюдение злоумышленника за процессами, происходящими в системе.

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

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

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

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

Классификация угроз по используемым средствам атаки:
- штатные средства операционной системы без использования дополнительного программного обеспечения;
- программное обеспечение третьих фирм (к этому классу программного обеспечения относятся как компьютерные вирусы и другие вредоносные программы (exploits), которые можно легко найти в Internet, так и программное обеспечение, изначально разработанное для других целей: отладчики, сетевые мониторы и сканеры и т.д.);
- специально разработанное программное обеспечение.

Классификация угроз по состоянию атакуемого объекта операционной системы на момент атаки:
- хранение;
- передача;
- обработка.

Типичные атаки на операционную систему

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

Кража ключевой информации.
В простейшем случае эта атака заключается в том, что злоумышленник подсматривает пароль, набираемый пользователем. То, что все современные операционные системы не высвечивают на экране вводимый пользователем пароль, несколько затрудняет эту задачу, но не делает ее невыполнимой. Известно, что для того, чтобы восстановить набираемый пользователем пароль только по движениям рук на клавиатуре, достаточно всего несколько недель тренировок. Кроме того, достаточно часто встречается ситуация, когда пользователь ошибочно набирает пароль вместо своего имени, которое, в отличие от пароля, на экране высвечивается.
Некоторые программы входа в операционную систему удаленного сервера допускают ввод пароля из командной строки. К таким командам относится, например, команда nwlogin операционной системы UNIX, предназначенная для входа на сервер Novell NetWare. При использовании с ключом -р она позволяет вводить пароль в командной строке, например: nwlogin server user -ppassword
При вводе пароля в командной строке пароль, естественно, отображается на экране и может быть прочитан злоумышленником. Известны случаи, когда пользователи создавали командные файлы, состоящие из команд, подобных вышеприведенной, для автоматического входа на удаленные серверы. Если злоумышленник получает доступ к такому файлу, тем самым он получает доступ ко всем серверам, к которым имеет доступ данный пользователь, в пределах предоставленных ему полномочий.
Иногда пользователи, чтобы не забыть пароль, записывают его на бумагу, которую приклеивают к нижней части клавиатуры, к задней стенке системного блока или в какое-нибудь другое якобы укромное место. В этом случае пароль рано или поздно становится добычей злоумышленника. Особенно часто такие ситуации имеют место в случаях, когда политика безопасности требует от пользователей использовать длинные, трудные для запоминания пароли.
Наконец, потеря или кража внешнего носителя парольной информации (дискеты или электронного ключа, на которых хранится пароль пользователя, предназначенный для входа в операционную систему).

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

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

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

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

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

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

Атаки на уровне сетевого программного обеспечения

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

1.2. Понятие защищенной операционной системы

Основные определения
Мы будем называть операционную систему защищенной, если она предусматривает средства защиты от основных классов угроз, описанных в § 1.1. Защищенная операционная система обязательно должна содержать средства разграничения доступа пользователей к своим ресурсам, а также средства проверки подлинности пользователя, начинающего работу с операционной системой. Кроме того, защищенная операционная система должна содержать средства противодействия случайному или преднамеренному выводу операционной системы из строя.
Если операционная система предусматривает защиту не от всех основных классов угроз, а только от некоторых, такую операционную систему будем называть частично защищенной. Например, операционная система MS-DOS с установленным антивирусным пакетом является частично защищенной системой - она защищена от компьютерных вирусов.
Мы будем называть политикой безопасности набор норм, правил и практических приемов, регулирующих порядок хранения и обработки ценной информации. В применении к операционной системе политика безопасности определяет то, какие пользователи могут работать с операционной системой, какие пользователи имеют доступ к каким объектам операционной системы, какие события должны регистрироваться в системных журналах и т.д.
Адекватной политикой безопасности будем называть такую политику безопасности, которая обеспечивает достаточный уровень защищенности операционной системы. Следует особо отметить, что адекватная политика безопасности - это не обязательно та политика безопасности, при которой достигается максимально возможная защищенность системы.

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

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

Основные административные меры защиты.
1. Постоянный контроль корректности функционирования операционной системы, особенно ее подсистемы защиты. Такой контроль наиболее удобно организовать, если операционная система поддерживает регистрацию событий (event logging). В этом случае операционная система автоматически регистрирует в специальном журнале (или нескольких журналах) наиболее важные события, произошедшие в процессе функционирования системы.
2. Организация и поддержание адекватной политики безопасности. Политика безопасности должна постоянно корректироваться, оперативно реагируя на изменения в конфигурации операционной системы, установку, удаление и изменение конфигурации прикладных программных продуктов и расширений операционной системы, попытки злоумышленников преодолеть защиту операционной системы и т.д.
3. Инструктирование пользователей операционной системы о необходимости соблюдения мер безопасности при работе с операционной системой и контроль за соблюдением этих мер.
4. Регулярное создание и обновление резервных копий программ и данных операционной системы.
5. Постоянный контроль изменений в конфигурационных данных и политике безопасности операционной системы. Информацию об этих изменениях целесообразно хранить на неэлектронных носителях информации для того, чтобы злоумышленнику, преодолевшему защиту операционной системы, было труднее замаскировать свои несанкционированные действия.

Адекватная политика безопасности
Задача выбора и поддержания адекватной политики безопасности является одной из наиболее важных задач администратора операционной системы. Если принятая в операционной системе политика безопасности неадекватна, это может приводить к несанкционированному доступу пользователя-злоумышленника к ресурсам системы, а также к снижению надежности функционирования операционной системы. С другой стороны, не всякая адекватная политика безопасности применима на практике.
В общем случае верно следующее утверждение: чем лучше операционная система защищена, тем труднее с ней работать пользователям и администраторам. Это обусловлено следующими факторами.
1. Система защиты, не обладающая интеллектом, не всегда способна определить, является ли некоторое действие пользователя злонамеренным. Поэтому система защиты либо не пресекает некоторые виды несанкционированного доступа, либо запрещает некоторые вполне легальные действия пользователей. Чем выше защищенность системы, тем шире класс тех легальных действий пользователей, которые рассматриваются подсистемой защиты как несанкционированные. Например, если некоторому пользователю запрещено создавать файлы на жестком диске, этот пользователь не сможет запустить ни одну программу, которой для нормального функционирования необходимо создавать временные файлы. С точки зрения рассматриваемой политики безопасности создание временного файла является несанкционированным действием, и в том, что оно пресекается, нет ошибки. Просто в данной политике безопасности класс несанкционированных действий настолько широк, что это препятствует нормальной работе пользователей с операционной системой.
2. Любая система, в которой предусмотрены функции защиты информации, требует от администраторов определенных усилий, направленных на поддержание адекватной политики безопасности. Чем больше в операционной системе защитных функций, тем больше времени и средств нужно тратить на поддержание защиты.
3. Подсистема защиты операционной системы, как и любой другой программный пакет, потребляет аппаратные ресурсы компьютера. Чем сложнее устроены защитные функции операционной системы, тем больше процессорного времени, оперативной памяти и других аппаратных ресурсов компьютера затрачивается на поддержание функционирования подсистемы защиты и тем меньше ресурсов остается на долю прикладных программ. В отдельных случаях, например, если в операционной системе поддерживается полномочное разграничение доступа с контролем информационных потоков, подсистема защиты операционной системы может потреблять более половины аппаратных ресурсов компьютера.
4 Поддержание слишком жесткой политики безопасности может негативно сказаться на надежности функционирования операционной системы. Один из примеров такой политики безопасности описан в Windows NТ FAQ. Windows NT позволяет администраторам ограничивать права системных процессов на доступ к объектам операционной системы. Если запретить псевдопользователю SISTEM, от имени которого выполняются системные процессы, доступ к исполняемым файлам системных процессов, операционная система, как и следовало ожидать, не сможет загрузиться. В данном случае чрезмерно жесткая политика безопасности приводит к моментальному краху операционной системы, в других случая подобная политика безопасности может приводить к трудновыявляемым ошибкам и сбоям в процессе функционирования операционной системы, что еще более опасно.
Таким образом, при определении адекватной политики безопасности не следует пытаться достигнуть максимально возможного уровня защищенности операционной системы. Оптимальная адекватная политика безопасности – это такая политика безопасности, которая не только позволяет злоумышленникам выполнять несанкционированные действия, но и не приводит к вышеописанным негативным эффектам.
Не существует единой адекватной политики безопасности на все случаи жизни. То, какая политика безопасности будет адекватной, определяется не только архитектурой операционной системы, но и ее конфигурацией, установленными прикладными программами и т.д. Политика безопасности, адекватная для некоторой операционной системы, скорее всего, будет неадекватна для другого экземпляра той же операционной системы. Большинство современных операционных систем достаточно универсальны и могут применяться для решения самых различных задач. Одна и та же операционная система может использоваться для обеспечения функционирования и автоматизированной банковской системы, и Web-сервера, и системы электронного документооборота. Очевидно, что угрозы безопасности для всех трех применений операционной системы совершенно различны, и, следовательно, адекватная политика безопасности в каждом случае будет своя.

Определение и поддержание адекватной политики безопасности операционной системы в общем случае можно разделить на ряд этапов.
1. Анализ угроз. Администратор операционной системы рассматривает возможные угрозы безопасности данного экземпляра операционной системы. Среди возможных угроз выделяются наиболее опасные, защите от которых нужно уделять максимум сил и средств.
2. Формирование требований к политике безопасности. Администратор определяет, какие средства и методы будут применяться для защиты от тех или иных угроз. Например, защиту от несанкционированного доступа к некоторому объекту операционной системы можно решать средствами разграничения доступа, либо криптографическими средствами, либо используя некоторую комбинацию этих средств. Администратор должен сделать подобный выбор для каждой угрозы безопасности операционной системы, выбирая оптимальные средства защиты от каждой угрозы. Одновременно с этим администратор анализирует возможные побочные эффекты различных вариантов политики безопасности, оценивая, в какой мере в каждом варианте политики безопасности будут проявляться побочные негативные факторы. Как правило, администратору приходится идти на компромисс, смиряясь либо с недостаточной защищенностью операционной системы от отдельных угроз, либо с определенными трудностями пользователей при работе с системой.
3. Формальное определение политики безопасности. Администратор четко определяет, как конкретно должны выполняться требования, сформулированные на предыдущем этапе. Он решает, можно ли добиться выполнения этих требований только встроенными средствами операционной системы или необходима установка дополнительных пакетов защиты. В последнем случае выбирается требуемое программное обеспечение. Формулируются необходимые требования к конфигурации операционной системы, а также требования к конфигурации дополнительных пакетов защиты, если установка таких пакетов необходима. Кроме того, администратор должен предусмотреть порядок внесения необходимых изменений в политику безопасности в чрезвычайных ситуациях, например при обнаружении факта несанкционированного входа в систему пользователя-злоумышленника. Результатом данного этапа является развернутый перечень настроек конфигурации операционной системы и дополнительных пакетов защиты с указанием того, в каких ситуациях какие настройки должны быть выставлены.
4. Претворение в жизнь политики безопасности. К началу этого этапа у администратора операционной системы имеется четкое представление о том, какой должна быть адекватная политика безопасности. Задачей данного этапа является приведение конфигурации операционной системы и дополнительных пакетов защиты в соответствие с политикой безопасности, формально определенной на предыдущем этапе
5. Поддержание и коррекция политики безопасности. На данном этапе операционная система функционирует в соответствии с политикой безопасности, определенной на третьем этапе. В задачу администратора входит контроль соблюдения политики безопасности и внесение в нее необходимых изменений по мере появления изменений в функционировании операционной системы. Например, если в операционной системе устанавливается новый программный продукт, может потребоваться коррекция политики безопасности таким образом, чтобы этот программный продукт мог нормально функционировать.

Cтандарты защищенности операционных систем

Специальных стандартов защищенности операционных систем не существует. Для оценки защищенности операционных систем используются стандарты, разработанные для компьютерных систем вообще.
Наиболее известным стандартом безопасности компьютерных систем является документ под названием "Критерии безопасности компьютерных систем" (Trusted computer system evaluatii criteria), разработанный Министерством обороны США в 1983 г. Этот документ более известен под неформальным названием "Оранжевая книга». Согласно "Оранжевой книге" все защищенные компьютерные системы делятся на семь классов от D1 (минимальная защита, фактически отсутствие всякой защиты) до А1 (максимальная защита). Основные требования "Оранжевой книги" в применении к операционным системам можно сформулировать следующим образом (очень упрощенно).
Класс D1. Никаких требований. К этому классу относятся все операционные системы, не удовлетворяющие требованиям высших классов
Класс С1. В операционной системе поддерживается избирательное (дискреционное) разграничение доступа. Пользователь, начинающий работать с системой, должен подтвердить свою подлинность (аутентифицироваться).
Класс С2. Выполняются все требования класса С1. Все субъекты и объекты операционной системы имеют уникальные идентификаторы. Все действия всех субъектов доступа, не разрешенные явно, запрещены. События, потенциально опасные для поддержания защищенности операционной системы, регистрируются в специальном журнале (журнале аудита), работать с которым могут только привилегированные пользователи. Вся информация, удаляемая из оперативной памяти компьютера или с внешних носителей информации, удаляется физически и не может быть в дальнейшем доступна ни одному субъекту доступа.
Класс В1. Выполняются все требования класса С2. Поддерживается полномочное (мандатное) разграничение доступа к объектам операционной системы. Поддерживается маркировка экспортируемой информации.
Класс В2. Выполняются все требования класса В1. Подсистема защиты операционной системы реализует формально определенную и четко документированную модель безопасности. Осуществляется контроль скрытых каналов утечки информации. Интерфейс подсистемы защиты четко и формально определен, его архитектура и реализация полностью документированы. Выдвигаются более жесткие требования к идентификации, аутентификации и разграничению доступа.
Требованиям класса С2 удовлетворяют многие известные операционные системы: ряд версий UNIX, Wndows NT, OS/400, VAX/VMS и IBM MVS с пакетом RACF. Операционных систем для персональных компьютеров, удовлетворяющих требованиям более высоких классов защиты, очень мало. Это объясняется, с одной стороны, большой "ресурсоемкостью" подсистем защиты, соответствующих требованиям класса В1 и выше, и, с другой стороны, трудностями обеспечения нормального функционирования распространенного программного обеспечения в таких операционных системах. Если требования класса С2 позволяют применять в защищенной операционной системе программное обеспечение, разработанное для других программных сред (например, в Windows NT можно запускать Microsoft Office для Windows 95), то требования более высоких классов защиты настолько жестки, что заметно мешают функционированию прикладных программ, разработанных без учета этих требований. Например, текстовый редактор Microsoft Word, будучи запущен в операционной системе, удовлетворяющей требованиям класса В1, будет некорректно функционировать при одновременном открытии документов с различным грифом секретности.
К основным недостаткам "Оранжевой книги" относятся следующие:
- совершенно не рассматриваются криптографические средства защиты информации;
- практически не рассматриваются вопросы обеспечения защиты системы от атак, направленных на временный вывод системы из строя (атаки класса "отказ в обслуживании");
- не уделяется должного внимания вопросам защиты защищаемой системы от негативных воздействий программных закладок и компьютерных вирусов;
- недостаточно подробно рассматриваются вопросы взаимодействия нескольких экземпляров защищенных систем в локальной или глобальной вычислительной сети;
- требования к средствам защиты от утечки конфиденциальной информации из защищенной системы ориентированы на хранение конфиденциальной информации в базах данных и мало приемлемы для защиты электронного документооборота.

Стандарты защищенности и адекватная политика безопасности
Если операционная система сертифицирована по какому-либо классу защищенности некоторой системы стандартов, это вовсе не означает, что информация, хранящаяся и обрабатывающаяся в этой системе, защищена согласно соответствующему классу. Защищенность операционной системы определяется не только ее архитектурой, но и текущей политикой безопасности.
Как правило, сертификация операционной системы по некоторому классу защиты сопровождается составлением требований к адекватной политике безопасности, при неукоснительном выполнении которой защищенность конкретного экземпляра операционной системы будет соответствовать требованиям соответствующего класса защиты.
Для примера рассмотрим некоторые требования к конфигурации операционной системы Windows NT, которые должны выполняться для соответствия защищенности операционной системы классу С2 "Оранжевой книги":
- загрузка компьютера невозможна без ввода пароля;
- на жестких дисках используется только файловая система NTFS;
- запрещено использование паролей короче шести символов;
- запрещена эмуляция OS/2 и POS1X;
- запрещен анонимный и гостевой доступ;
- запрещен запуск любых отладчиков;
- тумблер питания и кнопка RESET недоступны пользователям;
- запрещено завершение работы операционной системы без входа пользователя в систему;
- политика безопасности в отношении аудита построена таким образом, что при переполнении журнала безопасности операционная система прекращает работу (зависает). После этого восстановление работоспособности системы может быть произведено только администратором;
- запрещено разделение между пользователями ресурсов сменных носителей информации (флоппи-дисков, CD-ROM и т.д.);
- запись в системную директорию и файлы инициализации операционной системы разрешена только администраторам и системным процессам.
Определяя адекватную политику безопасности, администратор операционной системы должен в первую очередь ориентироваться на защиту операционной системы от конкретных угроз ее безопасности. К сожалению, в настоящее время часто встречается ситуация, когда администратор формирует требования к политике безопасности исходя не из комплекса угроз, защиту от которых нужно реализовать, а из некоторых абстрактных рекомендаций по поддержанию безопасности той или иной операционной системы. Наиболее часто в качестве таких рекомендаций берут требования различных стандартов безопасности компьютерных систем - наиболее "популярными" являются стандарты "Оранжевой книги". В результате не исключена ситуация, когда операционная система, сертифицированная по очень высокому классу защиты, оказывается уязвимой для некоторых угроз даже при соответствии политики безопасности требованиям соответствующего класса защиты.

1.3.Типовая архитектура подсистемы защиты операционной системы

Основные функции подсистемы защиты операционной системы

Основные функции, выполняемые подсистемой защиты операционной системы.
1. Разграничение доступа. Каждый пользователь системы имеет доступ только к тем объектам операционной системы, к которым ему предоставлен доступ в соответствии с текущей политикой безопасности.
2. Идентификация и аутентификация. Ни один пользователь не может начать работу с операционной системой, не идентифицировав себя и не предоставив системе аутентифицирующую информацию, подтверждающую, что пользователь действительно является тем, за кого он себя выдает.
3. Аудит. Операционная система регистрирует в специальном журнале события, потенциально опасные для поддержания безопасности системы. Записи об этих событиях могут просматривать в дальнейшем только администраторы операционной системы.
4. Управление политикой безопасности. Политика безопасности должна постоянно поддерживаться в адекватном состоянии, т.е. должна гибко реагировать на изменения условий функционирования операционной системы, требований к защите информации, хранимой и обрабатываемой в системе, и т.д. Управление политикой безопасности осуществляется администраторами системы с использованием соответствующих средств, встроенных в операционную систему.
5. Криптографические функции. В настоящее время защита информации немыслима без использования криптографических средств защиты. В операционных системах шифрование используется при хранении и передаче по каналам связи паролей пользователей и некоторых других данных, критичных для безопасности системы.
6. Сетевые функции. Современные операционные системы, как правило, работают не изолированно, а в составе локальных и/или глобальных компьютерных сетей. Операционные системы компьютеров, входящих в одну сеть, взаимодействуют между собой для решения различных задач, в том числе и задач, имеющих прямое отношение к защите информации. Подсистема защиты практически никогда не представляет собой единый программный модуль. Как правило, каждая из перечисленных функций подсистемы защиты решается одним или несколькими программными модулями. Некоторые функции встраиваются непосредственно в ядро операционной системы. Тем не менее должен существовать четко определенный интерфейс между различными модулями подсистемы защиты, используемый при взаимодействии модулей для решения общих задач.
В одних операционных системах, как в Windows NT, подсистема защиты четко выделяется в общей архитектуре операционной системы, в других, как в UNIX, защитные функции "размазаны" практически по всем элементам операционной системы. Но, однако, любая операционная система, удовлетворяющая стандарту защищенности С2 "Оранжевой книги", должна содержать подсистему защиты, выполняющую все вышеперечисленные функции.
Обычно подсистема защиты операционной системы допускает свое расширение дополнительными программными модулями.

Разграничение доступа к объектам операционной системы

Основные определения
Объектом доступа (или просто объектом) будем называть любой элемент операционной системы, доступ к которому пользователей и других субъектов доступа может быть произвольно ограничен. Ключевым словом в данном определении является слово "произвольно". Если правила, ограничивающие доступ субъектов к некоторому элементу операционной системы, определены жестко и не допускают изменения с течением времени, этот элемент операционной системы мы не будем считать объектом. Другими словами, возможность доступа к объектам операционной системы определяется не только архитектурой операционной системы, но и текущей политикой безопасности.
Методом доступа к объекту называется операция, определенная для некоторого объекта. Например, для файлов могут быть определены методы доступа "чтение", "запись" и "добавление" (дописывание информации в конец файла).
Субъектом доступа (или просто субъектом) будем называть любую сущность, способную инициировать выполнение операций над объектами (обращаться к объектам по некоторым методам доступа). Например, пользователи являются субъектами доступа.
В литературе, посвященной компьютерной безопасности, до сих пор не сформировалось единое представление, что же такое субъект доступа. Часто множество субъектов доступа считают подмножеством множества объектов защищенной системы. Такой подход эффективен при описании формальных моделей политики безопасности, но при рассмотрении конкретных систем защиты более удобно считать, что множество субъектов доступа и множество объектов доступа не пересекаются. Мы будем придерживаться второго подхода.
Иногда к субъектам доступа относят процессы, выполняющиеся в системе. Но, поскольку процессы в операционной системе выполняются не сами по себе, а от имени и под управлением пользователей (прямым или косвенным), логичнее считать субъектом доступа именно пользователя, от имени которого выполняется процесс. Естественно, под субъектом доступа мы будем подразумевать не физического пользователя, работающего с компьютером, а "логического" пользователя, от имени которого выполняются процессы операционной системы. Другими словами, если один физический пользователь может входить в операционную систему под двумя различными именами, мы будем считать, что этим именам соответствуют два различных субъекта доступа.
Итак, объект доступа - это то, к чему осуществляется доступ, субъект доступа - это тот, кто осуществляет доступ, и метод доступа - это то, как осуществляется доступ.
Для объекта доступа может быть определен владелец - субъект, которому принадлежит данный объект и который несет ответственность за конфиденциальность содержащейся в объекте информации, а также за целостность и доступность объекта. Обычно владельцем объекта автоматически назначается субъект, создавший данный объект, в дальнейшем владелец объекта может быть изменен с использованием соответствующего метода доступа к объекту. Владелец объекта не может быть лишен некоторых прав на доступ к этому объекту. На владельца, как правило, возлагается ответственность за корректное ограничение прав доступа к данному объекту других субъектов.
Правом доступа к объекту будем называть право на выполнение доступа к объекту по некоторому методу или группе методов. В последнем случае право доступа дает субъекту возможность осуществлять доступ к объекту по любому методу из данной группы. Говорят, что субъект имеет некоторое право на доступ к объекту (или "субъект имеет некоторое право на объект"), если он имеет возможность осуществлять доступ к объекту по соответствующему методу или группе методов. Например, если пользователь имеет возможность читать файл, говорят, что он имеет право на чтение этого файла.
Понятие метода доступа и понятие права доступа не идентичны. Например, в операционной системе UNIX право на запись в файл дает возможность субъекту обращаться к файлу как по методу "запись", так и по методу "добавление", при этом, поскольку право доступа "добавление" в UNIX отсутствует, невозможно разрешить субъекту операцию добавления, одновременно запретив операцию записи.
Говорят, что субъект имеет некоторую привилегию, если он имеет право на доступ по некоторому методу или группе методов ко всем объектам операционной системы, поддерживающим данный метод доступа. Например, если субъект операционной системы Windows NT имеет привилегию отлаживать программы, он имеет право доступа ко всем объектам типа "процесс" и "поток" по группе методов, используемых отладчиками при отладке программ.
Разграничением доступа субъектов к объектам является совокупность правил, определяющая для каждой тройки субъект-объект-метод, разрешен ли доступ данного субъекта к данному объекту по данному методу. При избирательном разграничении доступа возможность доступа определена однозначно для каждой тройки субъект-объект-метод, при полномочном разграничении доступа ситуация несколько сложнее.
Мы будем называть субъекта доступа суперпользователем, если он имеет возможность игнорировать правила разграничения доступа к объектам.

Правила разграничения доступа

Правила разграничения доступа, действующие в операционной системе, устанавливаются администраторами системы при определении текущей политики безопасности. За соблюдением этих правил субъектами доступа следит монитор ссылок - часть подсистемы защиты операционной системы.
Правила разграничения доступа должны удовлетворять следующим требованиям.
1. Правила разграничения доступа, принятые в операционной системе, должны соответствовать аналогичным правилам, принятым в организации, в которой установлена операционная система. Другими словами, если согласно правилам организации доступ пользователя к некоторой информации считается несанкционированным, этот доступ должен быть ему запрещен. Под несанкционированным доступом здесь подразумевается не только несанкционированное чтение информации, но и несанкционированные изменения, копирование и уничтожение информации.
2. Правила разграничения доступа не должны допускать разрушающие воздействия субъектов доступа, не обладающих соответствующими привилегиями, на операционную систему, выражающиеся в несанкционированном изменении, удалении или другом воздействии на объекты, жизненно важные для обеспечения нормального функционирования операционной системы.
3. Любой объект доступа должен иметь владельца. Присутствие объектов, не имеющих владельца, недопустимо.
4. Присутствие недоступных объектов - объектов, к которым не может обратиться ни один субъект доступа ни по одному методу доступа, непозволительно. Недоступные объекты фактически бесполезно растрачивают аппаратные ресурсы компьютера.
5. Утечка конфиденциальной информации недопустима. Поскольку защита от этой угрозы труднореализуема, данное требование предъявляется согласно "Оранжевой книге" только к системам класса защищенности В1 и выше.

Типичные модели разграничения доступа

1. Избирательное разграничение доступа. Система правил избирательного или дискреционного разграничения доступа (discretionary access control) формулируется следующим образом.
1. Для любого объекта операционной системы существует владелец.
2. Владелец объекта может произвольно ограничивать доступ других субъектов к данному объекту.
3. Для каждой тройки субъект-объект-метод возможность доступа определена однозначно.
4. Существует хотя бы один привилегированный пользователь (администратор), имеющий возможность обратиться к любому объекту по любому методу доступа. Это не означает, что этот пользователь может игнорировать разграничение доступа к объектам и поэтому является суперпользователем. Не всегда для реализации возможности доступа к объекту операционной системы администратору достаточно просто обратиться к объекту. Например, в Windows NT администратор для обращения к чужому (принадлежащему другому субъекту) объекту должен вначале объявить себя владельцем этого объекта, использовав привилегию администратора объявлять себя владельцем любого объекта, затем дать себе необходимые права, и только после этого администратор может обратиться к объекту. При этом использование администратором своей привилегии не остается незамеченным для прежнего владельца объекта.
Последнее требование введено для реализации механизма удаления потенциально недоступных объектов.
При создании объекта его владельцем назначается субъект, создавший данный объект. В дальнейшем субъект, обладающий необходимыми правами, может назначить объекту нового владельца. Обычно при изменении владельца объекта допускается назначать новым владельцем объекта только субъекта, изменяющего владельца объекта. Другими словами, субъект, изменяющий владельца объекта, может назначить новым владельцем объекта только себя. Такое ограничение вводится для того, чтобы владелец объекта не мог отдать "владение" объектом другому субъекту и тем самым снять с себя ответственность за некорректные действия с объектом.
Дли определения прав доступа субъектов к объектам при избирательном разграничении доступа используется матрица доступа. Строки этой матрицы представляют собой объекты, столбцы - субъекты (или наоборот). В каждой ячейке матрицы хранится совокупность прав доступа, предоставленных данному субъекту на данный объект.
Поскольку матрица доступа очень велика (типичный объем для современной операционной системы составляет несколько десятков мегабайтов), матрица доступа никогда не хранится в системе в явном виде. Для сокращения объема матрицы доступа используется объединение субъектов доступа в группы. Права, предоставленные группе субъектов для доступа к данному объекту, предоставляются каждому субъекту группы.
Вместе с каждым объектом доступа хранятся его атрибуты защиты, описывающие, кто является владельцем объекта и каковы права доступа к данному объекту различных субъектов. Атрибуты защиты фактически представляют собой совокупность идентификатора владельца объекта и строку матрицы доступа в кодированном виде.
На практике используются два способа кодирования строки матрицы доступа.
1. Вектор доступа (UNIX) - вектор фиксированной длины, разбитый на несколько подвекторов. Каждый подвектор описывает права доступа к данному объекту некоторого субъекта. С помощью вектора доступа можно описать права доступа к объекту только фиксированного числа субъектов, что накладывает существенные ограничения на систему разграничения доступа.
2. Список доступа (VAX/VMS, Windows NT) - список переменной длины, элементами которого являются структуры, содержащие:
идентификатор субъекта;
права, предоставленные этому субъекту на данный объект;
различные флаги и атрибуты.
Фактически вектор доступа представляет собой список доступа фиксированной длины и является частным случаем списка доступа.
Кодирование матрицы доступа в виде совокупности списков доступа позволяет реализовать более мощный и гибкий механизм разграничения доступа, однако требует гораздо больше оперативной и дисковой памяти для хранения атрибутов защиты объекта, усложняет техническую реализацию правил разграничения доступа и создает проблему, связанную с тем, что значения элементов списка доступа могут противоречить друг другу. Предположим, один элемент списка доступа разрешает некоторому пользователю доступ к объекту, а другой элемент списка запрещает доступ к объекту группе, в которую входит этот пользователь. При использовании списков доступа правила разграничения доступа должны включать в себя правила разрешения этих противоречий.
При создании нового объекта владелец объекта должен определить права доступа различных субъектов к этому объекту. Если владелец объекта не сделал этого, то либо новому объекту назначаются атрибуты защиты по умолчанию, либо новый объект наследует атрибуты защиты от родительского объекта (каталога, контейнера и т.д.).
Избирательное разграничение доступа является наиболее распространенным механизмом разграничения доступа. Это обусловлено сравнительной простотой реализации избирательного разграничения доступа и сравнительной необременительностью правил избирательного разграничения доступа для пользователей. Вместе с тем защищенность операционной системы, подсистема защиты которой реализует только избирательное разграничение доступа, во многих случаях недостаточна
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. Общие сведения. Для идентификации и аутентификации пользователей в подавляющем большинстве операционных систем используются имя и пароль. Для идентификации пользователь должен ввести свое имя, а для аутентификации ввести пароль - текстовую строку, известную только ему. Имя пользователя, как правило, назначается ему администратором системы.
Процедура идентификации и аутентификации с использованием имени и пароля предельно проста. Пользователь вводит с клавиатуры имя и пароль, операционная система ищет в списке пользователей запись, относящуюся к этому пользователю, и сравнивает пароль, хранящийся в списке пользователей, с паролем, введенным пользователем. Если запись, относящаяся к входящему в систему пользователю, присутствует в списке пользователей и содержащийся в этой записи пароль совпадает с введенным, считается, что идентификация и аутентификация прошли успешно и начинается авторизация пользователя. В противном случае пользователь получает отказ в доступе и не может работать с операционной системой до тех пор, пока он не будет успешно идентифицирован и аутентифицирован. Если идентификация и аутентификация пользователя происходят в процессе входа пользователя на удаленный сервер, имя и пароль пользователя пересылаются по сети (как правило, в зашифрованном виде).
Для обеспечения надежной защиты операционной системы пароль каждого пользователя должен быть известен только этому пользователю и никому другому, в том числе и администраторам системы. На первый взгляд то, что администратор знает пароль некоторого пользователя, не отражается негативно на безопасности системы, поскольку администратор, войдя в систему от имени обычного пользователя, получает права, меньшие, чем те, которые он получит, зайдя в систему от своего имени. Однако, входя в систему от имени другого пользователя, администратор получает возможность обходить систему аудита, а также совершать действия, компрометирующие этого пользователя, что недопустимо в защищенной системе.
Из вышеизложенного следует, что пароли пользователей не должны храниться в операционной системе в открытом виде. Поскольку администратор системы для выполнения своих обязанностей должен иметь доступ к списку пользователей (это необходимо, например, для регистрации новых пользователей), то, если пароли хранятся там открыто, администратор получает к ним доступ. Тем самым администратор получает возможность входить в систему от имени любого зарегистрированного пользователя.
Обычно для шифрования паролей в списке пользователей используют одну из известных криптографически стойких хеш-функций ~ легко-вычислимую функцию 13 EMBED Equation.3 1415, для которой функция 13 EMBED Equation.3 1415 (возможно, неоднозначная) не может быть вычислена за приемлемое время. В списке пользователей хранится не сам пароль, а образ пароля, являющийся результатом применения к паролю хеш-функции. Однонаправленность хеш-функции не позволяет восстановить пароль по образу пароля, но позволяет, вычислив хеш-функцию, получить образ введенного пользователем пароля и таким образом проверить правильность введенного пароля. В простейшем случае в качестве хеш-функции используется результат шифрования некоторой константы на пароле.
Хеш-функция, используемая при генерации образов паролей, обязательно должна быть криптографически стойкой. Дело в том, что обеспечить хранение образов паролей в тайне от всех пользователей системы практически невозможно. Администратор операционной системы, используя свои привилегии, легко может прочитать образы паролей из файла или базы данных, в которой они хранятся. При сетевой аутентификации пользователя на сервере образ пароля передается по открытым каналам связи и может быть перехвачен любым сетевым монитором. Если злоумышленник, зная значение хеш-функции (образ пароля пользователя), может за приемлемое время подобрать аргумент функции, соответствующий этому значению (пароль пользователя или эквивалентный ему пароль), ни о какой защите информации в операционной системе не может быть и речи. Это не означает, что образы паролей должны быть общедоступны. Хранение образов паролей в файле или базе данных, к которой имеют доступ только системные процессы, создает дополнительный эшелон защиты.
В процедуре генерации образа пароля обязательно должен участвовать маркант - число или строка, генерируемая случайным образом и хранящаяся в открытом виде вместе с образом пароля. Это необходимо для того, чтобы одинаковым паролям соответствовали разные образы. В противном случае злоумышленник может осуществить ряд атак на операционную систему, наиболее опасная из которых заключается в следующем.
Злоумышленник берет какой-либо электронный словарь и для каждого слова из этого словаря генерирует в точности такую же хеш-функцию, которая используется при генерации образа пароля. Слова и соответствующие им хеш-функции сохраняются в базе данных. Перехватив образ пароля некоторого пользователя, злоумышленник ищет в этой базе данных слово, соответствующее перехваченному образу пароля. Это и есть искомый пароль (или пароль, эквивалентный искомому). Вероятность успешного получения пароля по образу может быть сделана сколь угодно высокой - для этого нужно всего лишь иметь достаточно большой словарь. При этом для пополнения словаря злоумышленнику совсем не обязательно иметь доступ к атакуемой операционной системе. Более того, злоумышленник может хранить словарь вне атакуемой системы, например на своем домашнем компьютере. Эта атака может быть реализована только в том случае, когда одинаковым паролям соответствуют одинаковые образы паролей. Если при генерации образа пароля используется маркант, данная атака нереализуема.
Если пользователь, входящий в систему, неправильно ввел свое имя или пароль, операционная система должна выдать ему сообщение об ошибке, не указывая, какая именно информация некорректна. В противном случае подбор пароля существенно упрощается.
Если для аутентификации пользователей используются пароли, существуют две основные угрозы для подсистемы аутентификации операционной системы - кража пароля и подбор пароля.
Для обеспечения надежной защиты от кражи паролей подсистема защиты операционной системы должна удовлетворять следующим требованиям:
- пароль, вводимый пользователем, не отображается на экране компьютера;
- ввод пароля из командной строки недопустим.
Кроме того, пользователи операционной системы должны быть проинструктированы о:
- необходимости хранения пароля в тайне от других пользователей, включая администраторов операционной системы;
- необходимости немедленной смены пароля после его компрометации;
- необходимости регулярной смены пароля;
- недопустимости записи пароля на бумагу или в файл.

2. Методы подбора паролей. Существуют следующие методы подбора паролей пользователей.
1. Тотальный перебор. В этом случае злоумышленник последовательно опробует все возможные варианты пароля. Если пароль длиннее четырех - шести символов, данный метод абсолютно неэффективен.
2. Тотальный перебор, оптимизированный по статистике встречаемости символов. Разные символы встречаются в паролях пользователей с разной вероятностью. Например, вероятность того, что в пароле пользователя встретится буква "а", гораздо выше вероятности того, что в пароле присутствует символ "л". Согласно различным исследованиям статистика встречаемости символов в алфавите паролей близка к статистике встречаемости символов в естественном языке.
При практическом применении данного метода злоумышленник вначале опробует пароли, состоящие из наиболее часто встречающихся символов, за счет чего время перебора существенно сокращается. Иногда при подборе паролей используется не только статистика встречаемости символов, но и статистика встречаемости биграмм и триграмм - комбинаций двух и трех последовательных символов соответственно.
Для подбора паролей по данному методу в разное время было написано множество программ. Одни из них поочередно подают на вход подсистемы аутентификации операционной системы различные варианты пароля, другие опробуют варианты пароля путем генерации хеш-функции и ее последующего сравнения с известным образом пароля. В первом случае скорость подбора пароля определяется производительностью операционной системы. Во втором случае среднее время подбора пароля из 6 -8 символов, не включающего ни цифр, ни знаков препинания, варьируется от нескольких десятков секунд до нескольких часов в зависимости от вычислительной мощности компьютера и эффективности реализации алгоритма генерации хеш-функции в программе, подбирающей пароли.
3. Тотальный перебор, оптимизированный с помощью словарей. В большинстве случаев пароли пользователей представляют собой слова английского или русского языка. Поскольку пользователю гораздо легче запомнить осмысленное слово, чем бессмысленную последовательность символов, пользователи предпочитают применять в качестве паролей осмысленные слова. При этом количество возможных вариантов пароля резко сокращается. Действительно, английский язык содержит всего около 100000 слов (не считая научных, технических, медицинских и других терминов), что в 6,5 раз меньше количества всех комбинаций из четырех английских букв.
При использовании данного метода подбора паролей злоумышленник вначале опробует в качестве паролей все слова из словаря, содержащего наиболее вероятные пароли. Такой словарь злоумышленник может составить сам, а может взять, например, в Internet, где имеется огромное количество подобных словарей, адаптированных для различных стран мира. Если подбираемый пароль отсутствует в словаре, злоумышленник опробует всевозможные комбинации слов из словаря, слова из словаря с добавленными к началу и/или к концу одной или несколькими буквами, цифрами и знаками препинания и т.д.
Обычно данный метод используется в комбинации с предыдущим.
4. Подбор пароля с использованием знаний о пользователе. Выше уже говорилось, что пользователи стараются использовать легко запоминаемые пароли. Многие пользователи, чтобы не забыть пароль, выбирают в качестве пароля свое имя, фамилию, дату рождения, номер телефона, номер автомобиля и т.д. В этом случае, если злоумышленник хорошо знает пользователя, ему, как правило, достаточно провести всего 10-20 опробований.
5. Подбор образа пароля. Если подсистема аутентификации операционной системы устроена так, что образ пароля существенно короче самого пароля, злоумышленник может подбирать не пароль, а его образ. Однако в этом случае злоумышленник, подобрав образ пароля, должен получить сам пароль, соответствующий подобранному образу, а это возможно только в том случае, если хеш-функция, применяемая в системе, не обладает достаточной стойкостью.
3. Защита от компрометации паролей. Мы будем говорить, что произошла компрометация пароля, если пароль пользователя стал известен некоторому другому пользователю. Компрометация может происходить в результате либо неосторожности пользователя, либо кражи или подбора пароля злоумышленником. Существует целый ряд методов, позволяющих несколько уменьшить угрозу компрометации паролей пользователей.
1. Ограничение срока действия пароля. При применении данного метода каждый пользователь операционной системы обязан менять пароль через определенные интервалы времени. Максимальный срок действия пароля целесообразно ограничить 30 - 60 днями. Менее сильные ограничения не дают желаемого эффекта, а при использовании более сильных ограничений резко повышается вероятность того, что пользователь забудет свой пароль. После того как срок действия пароля истек, пользователь должен сменить свой пароль в течение некоторого времени (обычно 1 - 2 дня) после первого входа в систему по истечении этого срока. Если пользователь не сменил пароль за отведенное время, операционная система запрещает ему входить в систему до тех пор, пока это явно не разрешит администратор системы.
Срок действия пароля должен ограничиваться не только сверху, но и снизу. В противном случае пользователь, сменив пароль, может немедленно вернуться к старому паролю, сменив пароль еще раз.
Также целесообразно проверять при каждой смене пароля уникальность нового пароля. Для этого операционная система должна хранить не только образ текущего пароля пользователя, но и образы последних 5-10 паролей, им применявшихся.
2. Ограничения на содержание пароля. Данный метод заключается в том, что пользователь может выбрать себе в качестве пароля не произвольную строку символов, а только строку, удовлетворяющую определенным условиям. Обычно используются следующие условия:
- длина пароля не должна быть меньше некоторого количества символов; в литературе по компьютерной безопасности и в документации по операционным системам обычно рекомендуется запрещать использование паролей короче 6-8 символов, но с учетом быстрого прогресса вычислительной техники, в настоящее время целесообразно ограничивать длину паролей уже 10-14 символами;
- в пароль должно входить по крайней мере 5-7 различных символов;
- в пароль должны входить как строчные, так и заглавные буквы;
- пароль пользователя не должен совпадать с его именем;
- пароль не должен присутствовать в списке "плохих" паролей, хранимом в системе.
Как правило, администраторы операционной системы, могут варьировать эти ограничения как в пределах всей операционной системы, так и для отдельных пользователей. Например, если некоторое имя пользователя используется для гостевого входа, устанавливать ограничения на используемый пароль нецелесообразно.
При выборе ограничений на пароли следует учитывать, что, если ограничения на пароли слишком сильны, пользователям будет трудно запоминать свои пароли.
3. Блокировка терминала. При использовании данного метода, если пользователь несколько раз подряд ошибся при вводе имени и пароля, терминал, с которого пользователь входит в систему, блокируется, и пользователь не может продолжать дальнейшие попытки входа в систему. Параметрами данного метода являются:
- максимально допустимое количество неудачных попыток входа в систему с одного терминала;
- интервал времени, после которого счетчик неудачных попыток входа обнуляется;
- длительность блокировки терминала (может быть сделана неограниченной - в этом случае блокировка терминала может быть снята только администратором системы).
4. Блокировка пользователя. Этот метод отличается от предыдущего только тем, что блокируется не терминал, с которого пользователь входит в систему, а учетная запись пользователя.
5. Генерация паролей операционной системой. В этом случае пользователи не могут самостоятельно придумывать себе пароли - это за них делает операционная система. Когда пользователю нужно сменить пароль, он вводит соответствующую команду и получает новый пароль от операционной системы. Если предложенный вариант пароля пользователя не устраивает, он может потребовать у операционной системы другой вариант. Основным преимуществом данного метода является то, что операционная система генерирует пароли случайным образом, и подобрать такие пароли практически невозможно. С другой стороны, такие пароли обычно трудны для запоминания, что вынуждает пользователей записывать их на бумаге. Если это не является угрозой безопасности системы (например, если пользователь входит в систему только через Internet со своего домашнего компьютера), данная модель аутентификации близка к идеальной. В противном случае применять ее нецелесообразно.
6. Пароль и отзыв. При использовании этой схемы аутентификации при входе пользователя в систему операционная система выдает ему случайное число или строку, на которую пользователь должен дать правильный отзыв. Фактически паролем являются параметры алгоритма преобразования запроса операционной системы в корректный ответ пользователя. Эти параметры выбираются операционной системой случайным образом для каждого пользователя, что фактически сводит данную схему аутентификации к предыдущей.
7. Разовый пароль. В этом случае пароль пользователя автоматически меняется после каждого успешного входа в систему. Эта схема аутентификации надежно защищает от подбора паролей, поскольку, даже если злоумышленник и подобрал некоторый пароль, он сможет им воспользоваться только один раз. Кроме того, пользователь, пароль которого скомпрометирован, не сможет войти в систему в следующий раз, так как он будет пытаться вводить предыдущий пароль, уже использованный злоумышленником. Недостатком этой схемы является то, что запомнить множество постоянно меняющихся паролей практически невозможно. Кроме того, пользователи часто "сбиваются со счета", пытаясь при входе в систему вводить пароль, который уже устарел или еще не начал действовать. Из-за этих и некоторых других недостатков на практике данная схема практически не применяется. Некоторые из перечисленных методов могут применяться в совокупности.

Идентификация и аутентификация с помощью внешних носителей ключевой информации
В этом случае информация, идентифицирующая и аутентифицирующая пользователя, хранится на внешнем носителе информации, который может представлять собой обычную дискету, электронный ключ, пластиковую карту и т.д. При входе в систему пользователь подключает к компьютеру носитель ключевой информации, и операционная система считывает с него идентификатор пользователя и соответствующий ему ключ. Далее аутентификация осуществляется, как было описано выше, при этом идентификатор пользователя используется в качестве имени, а ключ - в качестве пароля.
Поскольку ключ, хранящийся на внешнем носителе, может быть сделан гораздо более длинным, чем пароль, подобрать такой ключ практически невозможно. Однако угроза утери или кражи ключевой информации по-прежнему остается актуальной. Если процедура аутентификации не предусматривает дополнительных мер защиты, любой обладатель носителя ключевой информации, в том числе и злоумышленник, укравший этот носитель у легального пользователя системы, может войти в систему с правами пользователя, которому принадлежит носитель.
Поэтому данный механизм аутентификации, как правило, используется в совокупности с предыдущим. При этом пользователь, входя в систему, должен не только "предъявить" компьютеру носитель ключевой информации, но и ввести соответствующий этому носителю пароль. Ключевая информация на носителе информации хранится зашифрованной на этом пароле, что не позволяет случайному обладателю ключа воспользоваться им.
Основной угрозой при использовании описываемого механизма аутентификации является угроза кражи носителя ключевой информации с последующим его копированием и подбором пароля на доступ к ключу. Если этот ключ выбирается случайно и не содержит проверочных полей (контрольных сумм и т.д.), подбор пароля на доступ к ключу вне атакуемой операционной системы невозможен - злоумышленник просто не сможет сформулировать критерий, позволяющий отличать правильно расшифрованный ключ от неправильно расшифрованного и, следовательно, правильный пароль от неправильного. А если злоумышленник станет опробовать этот пароль, делая попытки использовать ключевой носитель для аутентификации, от этой угрозы надежно защищают процедуры блокировки
Однако во многих случаях без проверочных полей ключа обойтись невозможно. В этой ситуации пароль на доступ к ключу может быть подобран с помощью методов подбора паролей. Для затруднения такого подбора используются следующие меры защиты:
- защита ключевого носителя от копирования;
- блокировка или уничтожение ключевой информации после определенного количества неудачных попыток ввода пароля на доступ к ключу.
Если в качестве носителя ключевой информации применяются ключевые дискеты, электронные ключи Touch Memory или пластиковые карты Memory Card, эти меры защиты неприменимы. Хотя существующие средства защиты от копирования и позволяют несколько затруднить копирование носителя информации, любой из перечисленных носителей может быть скопирован за несколько минут, в отдельных случаях - за несколько часов. Поскольку проверку правильности пароля на доступ к ключу осуществляет операционная система, то, если злоумышленник подбирает пароль с помощью специальной программы, подсчитывать количество неудачных попыток также невозможно.
В отличие от перечисленных носителей информации интеллектуальные пластиковые карты Smart Card помимо энергонезависимой памяти содержат микропроцессор, способный выполнять криптографические преобразования информации. Поэтому интеллектуальные карты способны самостоятельно проверять правильность пароля на доступ к ключевой информации, и при аутентификации пользователя с использованием интеллектуальной карты проверку пароля на доступ к карте производит не операционная система, а сама карта. Интеллектуальная карта может быть запрограммирована на стирание хранимой информации после превышения максимально допустимого количества неправильных попыток ввода пароля, что не позволяет подбирать пароль без частого копирования карты, а это весьма дорого.
В целом использование для аутентификации пользователей не только паролей, но еще и внешних носителей информации позволяет заметно повысить защищенность операционной системы. В наибольшей мере защищенность системы повышается при использовании интеллектуальных карт. Учитывая постоянное удешевление как самих интеллектуальных карт, так и устройств для их считывания, можно ожидать, что в ближайшие 5-10 лет интеллектуальные карты станут основным средством аутентификации в операционных системах, используемых для хранения и обработки конфиденциальной информации.

Идентификация и аутентификация с помощью биометрических характеристик пользователей
Каждый человек обладает своим неповторимым набором биометрических характеристик, к которым относятся отпечатки пальцев, рисунок сетчатки, рукописный и клавиатурный почерк и т.д. Эти характеристики могут быть использованы для аутентификации пользователя.
Если аутентификация пользователя осуществляется на основе биометрических характеристик, угрозы кражи и подбора ключевой информации перестают быть актуальными - подделать биометрические характеристики человека, как правило, настолько дорого, что затраты злоумышленника на проникновение в защищенную операционную систему превысят выгоды от такого проникновения. Таким образом, механизм аутентификации пользователя на основе биометрических характеристик создает практически непреодолимую защиту на этапе аутентификации.
С другой стороны, практическая реализация данного механизма аутентификации неизбежно создает следующие проблемы:
- поскольку псевдопользователи не являются людьми и, следовательно, не имеют биометрических характеристик, для их аутентификации должен поддерживаться альтернативный механизм. При этом операционная система должна гарантировать, что этот альтернативный механизм не будет использоваться для аутентификации обычных пользователей.
- при двух последовательных входах в систему одного и того же человека его биометрические характеристики никогда в точности не совпадают. Поэтому в процессе аутентификации приходится использовать математический аппарат теории распознавания образов, при этом необходимо мириться с неизбежностью ошибок как первого рода (успешный вход от чужого имени), так и второго рода (отказ в доступе легальному пользователю).
- большинство биометрических характеристик человека постепенно меняются со временем, что заставляет регулярно корректировать эталонный образ аутентифицирующей информации.
- биометрические характеристики человека могут испытывать резкие кратковременные изменения. Например, если пользователь оцарапал палец, система аутентификации, основанная на отпечатках пальцев, не сможет его аутентифицировать до тех пор, пока царапина не заживет.
- аутентификация пользователя на основе биометрических характеристик требует применения дорогостоящей аппаратуры для получения образа используемой характеристики и сложных вычислительных алгоритмов для сравнения этого образа с эталонным, что приводит к большим финансовым затратам на создание системы аутентификации и затратам вычислительных ресурсов компьютера на ее поддержание.
В подавляющем большинстве случаев вышеперечисленные недостатки делают схему аутентификации, основанную на биометрических характеристиках, неприемлемой для практического использования. Однако в отдельных случаях биометрические характеристики могут эффективно применяться для аутентификации.
Наиболее пригодной для аутентификации биометрической характеристикой пользователя, видимо, является рукописный почерк. При использовании рукописного почерка для аутентификации пользователь, входя в систему, должен поставить на специальном сенсорном планшете свою личную подпись. Помимо рисунка подписи сенсорный планшет фиксирует скорость движения и силу нажатия пера. Далее четырехмерный (ширина, высота, скорость движения и сила нажатия пера) образ подписи пользователя сравнивается с эталонным образом, заранее созданным на основе 10 - 30 различных экземпляров той же подписи. При сравнении оценивается степень сходства образов. Если различия незначительны, пользователь успешно входит в систему. Если различия очень велики, пользователь получает отказ. Если различия заметны, но не очень велики, пользователь входит в систему, при этом корректируется эталонный образ подписи пользователя. Таким образом, плавные изменения подписи человека с течением времени учитываются автоматически.
Что же касается резких кратковременных изменений почерка, вызванных изменениями физического и эмоционального состояния пользователя, эти изменения система аутентификации учесть неспособна. Если физическое или эмоциональное состояние пользователя таково, что он практически неработоспособен, этот пользователь просто не сможет войти в систему. Например, оператор банка просто не сможет снять деньги со счета "под дулом пистолета" - изменение эмоционального состояния, вызванное испугом, неизбежно приведет к тому, что подпись пользователя будет отвергнута системой аутентификации.

Аудит

Процедура аудита применительно к операционным системам заключается в регистрации в специальном журнале, называемом журналом аудита или журналом безопасности, событий, которые могут представлять опасность для операционной системы. Пользователи системы, обладающие правом чтения этого журнала, называются аудиторами.
Необходимость включения в защищенную операционную систему функций аудита диктуется следующими обстоятельствами.
1. Подсистема защиты операционной системы, не обладая интеллектом, не способна отличить случайные ошибки пользователей от злонамеренных действий. Например, то, что пользователь в процессе входа в систему ввел неправильный пароль, может означать как случайную ошибку при вводе пароля, так и попытку подбора пароля. Но, если сообщение о подобном событии записано в журнал аудита, администратор, просматривая этот журнал, легко сможет установить, что же имело место на самом деле - ошибка легального пользователя или атака злоумышленника. Если пользователь ввел неправильный пароль всего один раз - это явная ошибка. Если же пользователь пытался угадать собственный пароль 20 -30 раз это явная попытка подбора пароля.
2. Администраторы операционной системы должны иметь возможность получать информацию не только о текущем состоянии системы, но и о том, как она функционировала в недавнем прошлом. Журнал аудита дает такую возможность, накапливая информацию о важных событиях, связанных с безопасностью системы.
3. Если администратор операционной системы обнаружил, что против системы проведена успешная атака, ему важно выяснить, когда была начата атака и каким образом она осуществлялась. При наличии в системе подсистемы аудита не исключено, что вся необходимая информация содержится в журнале аудита.
Большинство экспертов по компьютерной безопасности сходятся во мнении, что привилегия работать с подсистемой аудита не должна предоставляться администраторам операционной системы. Другими словами, множество администраторов и множество аудиторов не должны пересекаться. При этом создается ситуация, когда администратор не может выполнять несанкционированные действия без того, чтобы это тут же не стало известно аудиторам, что существенно повышает защищенность системы от несанкционированных действий администраторов.

Требования к аудиту
Подсистема аудита операционной системы должна удовлетворять следующим требованиям.
1. Только сама операционная система может добавлять записи в журнал аудита. Если предоставить это право какому-то физическому пользователю, этот пользователь получит возможность компрометировать других пользователей, добавляя в журнал аудита соответствующие записи.
2. Ни один субъект доступа, в том числе и сама операционная система, не имеет возможности редактировать или удалять отдельные записи в журнале аудита.
3. Только пользователи-аудиторы, обладающие соответствующей привилегией, могут просматривать журнал аудита.
4. Только пользователи-аудиторы могут очищать журнал аудита. После очистки журнала в него автоматически вносится запись о том, что журнал аудита был очищен, с указанием времени очистки журнала и имени пользователя, очистившего журнал. Операционная система должна поддерживать возможность сохранения журнала аудита перед очисткой в другом файле.
5. При переполнении журнала аудита операционная система аварийно завершает работу ("зависает"). После перезагрузки работать с системой могут только аудиторы. Операционная система переходит к обычному режиму работы только после очистки журнала аудита.
Для ограничения доступа пользователей к журналу аудита недостаточно использования обычных средств разграничения доступа. Дело в том, что в подавляющем большинстве операционных систем администраторы, используя свои привилегии, могут прочитать и изменить содержимое любого файла операционной системы. Поэтому для ограничения доступа к журналу аудита должны применяться специальные средства защиты.
Хотя операционные системы не требуют обязательного сохранения журнала аудита перед очисткой, это желательно делать. Наиболее удобно сохранять старые журналы аудита на WORM-дисках, поскольку эти диски допускают только однократную запись информации, и информация, записанная на такой диск, может быть стерта только при физическом повреждении диска.

Политика аудита

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

Интерактивное оповещение аудиторов

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


13PAGE 15


13PAGE 143315





Приложенные файлы

  • doc 26447963
    Размер файла: 274 kB Загрузок: 0

Добавить комментарий