Вместо введения приведем выдержку из недавно опубликованной статьи на сайте www.itsec.ru: "Нарушение конфиденциальности информации - самая большая внутренняя ИТ-угроза" (от 08.06.2005):

• "Величина ущерба от действий хакеров разнится. Если по 2003 году исследователи более-менее пришли к общему мнению и определились, что сумма составляет 17 млрд. долларов, то по 2004 году оценки совершенно разные. По данным исследовательской компании Datamonitor, мировой экономический ущерб от хакерских атак - явных и скрытых - может достигнуть 155,5 млрд. долларов. По мнению экспертов, ежегодно хакерами взламывается до 90% сетей предприятий;
• Один из основных элементов безопасности - это операционная система компьютера. Британские исследователи из группы mi2g наиболее безопасными платформами считают Apple Mac OS X и открытую версию UNIX - BSD (Berkeley Software Distribution). Операционные системы Linux и Microsoft Windows, напротив, были признаны слабо защищенными. Свои выводы специалисты mi2g сделали, проанализировав 235 тыс. успешных хакерских атак, проведенных во всем мире с ноября 2003 по октябрь 2004 года;
• Среди компьютеров под управлением ОС Linux взломанными оказались 65%, под управлением Windows - 25%.

Можно выделить несколько ключевых причин низкого уровня защищенности современных ОС:

1. Архитектурные недостатки встроенных в ОС механизмов защиты (их, на самом деле, много - это и невозможность в полном объеме разграничивать доступ к ресурсам, прежде всего, к системным, для системных пользователей (например, пользователей System и Root), некорректная реализация (либо вообще ее отсутствие) ключевых механизмов защиты информации, например, механизма обеспечения замкнутости программной среды, что приводит к возможности запуска троянов, черверй и иных несанкционированных программ, и т.д.;
2. Концептуальные недостатки построения защиты современных универсальных ОС, например, с одной стороны, средствами ОС не обеспечивается возможность корректного разграничения прав доступа для системных пользователей, с другой стороны, ОС предоставляет разработчикам приложений сервис запуска приложений под системной учетной записью. Результат этого - масса разнородный по своей сути атак на расширение привилегий, реализуемых с единой целью - получить права системного пользователя, доступ к ресурсам для которого системными средствами не разграничивая. Как следствие, ошибки в приложениях (возможность переполнения буфера приложения, возможность некорректного олицетворения потока с системными правами и др.), запускаемых с системными правами, несут себе уязвимость защиты собственно ОС, т.е. уровень защищенности ОС в большой мере определяется корректностью разработки приложений, не содержащих в своем составе механизмов защиты и не предназначенных для решения этой задачи;
3. Ошибки программирования в системных средствах. Они присутствуют всегда, часть из которых может нести в себе уязвимость защищенности ОС.

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

Определим понятие "Надежность системы защиты", как вероятность того, что в любой момент времени система защищена (определяется тем условием, что число обнаруженных и не устраненных в ней уязвимостей равно 0). Значение данной характеристики системы можно оценить с использованием простейшей формулы: P₀ = 1 - λ/µ

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

Расчетные значения (для различных входных параметров) исследуемой характеристики сведены в Табл.1.

Таблица 1

Время восстановления	Интенсивность отказов
	1 отказ в год	2 отказа в год	5 отказов в год	10 отказов в год
1 неделя	0,98	0,96	0.93	0,81
2 недели	0,96	0,92	0,81	0,62
1 месяц	0.92	0,85	0,62	0,23
2 месяца	0,85	0,69	0,24	-
3 месяца	0,77	0,54	-	-
4 месяца	0,69	0,39	-	-

Проанализируем полученный результат.

Рассмотрим, например, значение "0,98" (лучшее значение надежности системы защиты в Табл.1) - это значение достигается в том случае, если лишь в среднем обнаруживается одна уязвимость в год, при среднем времени ее восстановления (включающем устранение неисправности разработчиком и установки обновления потребителем) составляющим 1 неделю. При этом вероятность того, что в любой момент времени система защищена, равна лишь 0,98 (т.е. в любой момент времени с вероятностью 0,02 систему защиты можно считать отказавшей). Но это для современных ОС потенциально не достижимая характеристика. Тому есть ряд причин.

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

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

Кстати говоря, попытайтесь с использованием рассмотренного подхода и существующей статистики обнаруженных уязвимостей ОС Linux, оценить надежность защиты (или защищенность) этой ОС. Будет ли она превышать значение 0,5 - она скорее защищена или не защищена?

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

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

1. Выполнение формализованных требований к механизмам защиты, сформулированных в соответствующих нормативных документах.
2. Устранение архитектурных недостатков встроенных в ОС механизмов защиты.
3. Устранение концептуальных недостатков построения защиты ОС.
4. Обеспечение высоких эксплуатационных свойств средства защиты информации. Это связано со снижением вероятности ошибок программирования в механизмах защиты и повышением оперативности их исправления.

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

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

Предприятием ЗАО "НПП "ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ В БИЗНЕСЕ" завершена разработка комплексной системы защиты конфиденциальной информации (КСЗИ) "Панцирь" для ОС семейства Linux, основным потребительским свойством которой является принципиальное расширение функциональных возможностей защиты, по сравнению со встроенными в ОС механизмами, как следствие, кардинальное повышение обеспечиваемого ею уровня защиты конфиденциальных данных. Комплексность системы обусловливается тем, что она содержит в своем составе средства защиты для альтернативных платформ Unix (на систему для HP-UX - получен сертификат по 5 классу СВТ; Linux, Free BSD - подготовлены к проведению сертификационных испытаний), управление которыми может осуществляться с единого сервера безопасности. Возможность установки сервера безопасности на ОС семейства Windows, позволяет интегрировать средства защиты в гетерогенной среде с единым рабочим местом администратора безопасности (сервером безопасности).

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

КСЗИ реализует все механизмы защиты собственными техническими средствами.

КСЗИ реализована как программное средство защиты информации по технологии клиент-сервер, содержит:

• Клиентскую часть, решающую собственно задачи защиты информации и устанавливаемую на защищаемые объекты информатизации - рабочие станции и серверы, функционирующие под управлением ОС HP-UX, Linux, Free BSD (соответственно, для каждой платформы своя клиентская часть),
• Серверную часть (рабочее место администратора безопасности), устанавливаемую на выделенном компьютере администратора безопасности, с целью удаленного управления клиентскими частями, функционирующем под управлением операционных систем Windows или UNIX (серверная часть едина для всех приложений КСЗИ).

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

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

В части комплексирования встроенных в ОС механизмов защиты с механизмами добавочной защиты КСЗИ реализует две возможности:

• Использование добавочных механизмов защиты и управление ими из интерфейса КСЗИ;
• Управление из интерфейса КСЗИ встроенными в ОС механизмами защиты.

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

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

В части выполнения требований соответствующих нормативных документов в области защиты информации для механизмов управления доступом к ресурсам в КСЗИ (что принципиально отличает их от соответствующих встроенных в ОС механизмов) реализованы следующие принципы:

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

Формализованные требования к средствам идентификации и аутентификации пользователей задаются действующим сегодня нормативным документом "Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации".

В части выполнения требований к СВТ в части защиты конфиденциальной информации (5 класс защищенности СВТ), клиентская часть КСЗИ обеспечивает реализацию следующих механизмов защиты:

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

Требования:

КСЗИ должна контролировать доступ наименованных субъектов (пользователей) к наименованным объектам (файлам, программам, томам и т.д.).

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

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

Контроль доступа должен быть применим к каждому объекту и каждому субъекту (индивиду или группе равноправных индивидов).

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

Право изменять ПРД должно предоставляться выделенным субъектам (администрации, службе безопасности и т.д.).

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

Реализация в КСЗИ:

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

Каждый пользователь определяется следующими параметрами: реальный идентификатор пользователя (RUID), эффективный идентификатор пользователя (EUID). Это позволяет разграничивать доступ к объектам для пользователя (группы пользователей), осуществляя при этом контроль корректности заимствования прав (олицетворения), что принципиально повышает уровень защищенности системы. Устанавливаемыми атрибутами в КСЗИ могут назначаться следующие типы доступа к защищаемым объектам: запись/чтение/исполнение/создание/удаление/переименование/изменение прав пользователя/создание ссылок на защищаемый объект.

Драйвер устанавливается перед обработчиком запроса доступа, находящегося в составе ядра ОС - имеется возможность осуществлять разграничения, как собственным механизмом защиты КСЗИ (при этом встроенный механизм может отключаться средствами КСЗИ), так и встроенным в ОС, либо обоими вместе (в режиме резервирования механизма).

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

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

2. Дискреционный механизм управления доступом пользователей к устройствам.

Требования:

Те же, что и для управления доступом к файловым объектам.

Реализация:

Обращение к устройствам в ОС Unix реализуется через файловую систему, при этом в качестве объекта выступают файлы устройств, которые могут быть блоковые (дисковые устройства - дисковод, CD-ROM и т.д.), либо символьные (клавиатура, мышь и т.д.). Драйвером КСЗИ осуществляется разграничение доступа к файлам устройства (устройствам) для пользователей.

3. Дискреционный механизм управления доступом к удаленным рабочим станциям и серверам ЛВС по протоколу TCP(UDP)/IP.

Требования:

Те же, что и для управления доступом к файловым объектам.

Реализация:

В состав КСЗИ входит драйвер контроля доступа к сетевым ресурсам. В качестве объектов доступа выступают IP-адреса и значения портов доступа. Драйвер КСЗИ осуществляет фильтрацию сообщений позволяя взаимодействовать рабочей станции в составе ЛВС только с компьютерами, имеющими заданные IP - адреса, причем взаимодействовать только по заданным номерам портов.

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

Отдельно может задаваться политика по разграничению доступа для исходящих и входящих соединений (соответственно, для TCP - это разграничения для системных вызовов connect и accept, для UDP - это разграничения для системных вызовов send и recv).

4. Механизм очистки внешней памяти.

Требования:

При первоначальном назначении или при перераспределении внешней памяти КСЗИ должен предотвращать доступ субъекту к остаточной информации.

Реализация в КСЗИ:

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

5. Механизм идентификации и аутентификации.

Требования:

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

Реализация в КСЗИ:

КСЗИ реализует замену стандартной программы ОС аутентификации пользователей (в ОC Linux вся идентификация и аутентификация пользователей производится посредством данной программы) - login - на программу, входящую в состав КСЗИ, а также замену стандартной программы ОС назначения паролей (задания ограничений на пароль) пользователям passwd.

КСЗИ реализует:

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

КСЗИ обеспечивает:

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

6. Механизм регистрации (аудита) событий.

Требования:

КСЗИ должна осуществлять регистрацию следующих событий:

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

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

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

КСЗИ должна содержать средства выборочного ознакомления с регистрационной информацией.

Реализация:

Каждый собственный механизм защиты КСЗИ ведет регистрацию заданных администратором безопасности событий, регистрируя требуемые выше параметры.

КСЗИ реализует:

• регистрацию входа (выхода) операторов в ОС, либо регистрацию загрузки и инициализации операционной системы и ее программного останова;
• регистрацию запуска/завершения программ и процессов;
• регистрацию попыток доступа пользователей и программных средств (программ, процессов) к защищаемым томам, каталогам и файлам;
• действия по изменению ПРД и т.д.

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

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

7. Механизм контроля целостности КСЗИ.

Требования:

В СВТ пятого класса защищенности должны быть предусмотрены средства периодического контроля целостности программной и информационной части КСЗИ.

Реализация:

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

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

В дополнение к механизмам защиты рабочих станций, требуемым Руководящим документом для СВТ 5 класса защищенности, в КСЗИ реализованы следующие механизмы:

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

   Реализация:

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

   Каждый субъект доступа определяется не только параметрами пользователя: реальный идентификатор пользователя (RUID), эффективный идентификатор пользователя (EUID), но и параметром процесса - процесс, выполняющий действие. Это позволяет разграничивать доступ к объекту не только для пользователя (группы пользователей), но и для процесса. Устанавливаемыми атрибутами могут задаваться следующие типы доступа к защищаемым объектам: запись/чтение/исполнение/создание/удаление/переименование/ изменение владельца/ изменение прав пользователя/создание ссылок на защищаемый объект.

   КСЗИ реализует разграничение доступа, как только для пользователя (доступ к объекту разрешен, если он разрешен пользователю, обращающемуся к объекту) или только для процесса (доступ к объекту разрешен, если он разрешен процессу, обращающемуся к объекту), так для пользователя и процесса вместе (доступ к объекту разрешен, если он разрешен пользователю и процессу одновременно).

   Внимание. Субъектами доступа для механизма управления доступом к ресурсам КСЗИ являются: пользователь, процесс, либо пользователь и процесс одновременно (пользователь, запрашивающий доступ к ресурсу процессом).

   Замечание. Данный механизм привносит принципиально новые возможности в части защиты информации от НСД.

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

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

2. Обеспечение замкнутости программной среды.

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

   Реализация:

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

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

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

3. Механизм контроля целостности программ перед запуском.

   Реализация:

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

4. Механизм управления доступом к монтированию устройств.

   Реализация:

   Для подключения к системе устройства (дисковода, CD-ROM привода и др.) его необходимо смонтировать - "подключить" к файловой системе (к каталогу). "Точкой" подключения устройства к файловой системе определяется полнопутевое имя устройства. КСЗИ позволяет разграничивать доступ к монтированию устройств, посредством задания к каким каталогам, какие устройства и с какой файловой системой могут монтироваться.
   
   

5. Механизм аутентификации при загрузке в режиме Single-User Mode.

   Реализация:

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

6. Механизм предоставления привилегий администратору безопасности.

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

   Реализация:

   Механизм обеспечивает невозможность проводить какие-либо действия, относительно процессов КСЗИ пользователю с правами "root". При этом, так как КСЗИ разграничивает доступ к объектам, в частности к настройкам КСЗИ собственными средствами, пользователь с правами "root" не имеет возможности влиять на функционирование КСЗИ.

Заключение

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

Более подробную информацию о (КСЗИ) "Панцирь" для ОС семейства Linux и о других разработках компании (в частности, обеспечивающих защиту ОС Windows 2000/XP/2003) можно получить на сайте: www.npp-itb.spb.ru, либо запросить интересующие сведения по системам защиты и условиям их поставки по электронной почте: info@npp-itb.spb.ru.

Д.т.н., проф. А.Ю.Щеглов, К.А.Щеглов
(ЗАО "НПП "Информационные технологии в бизнесе)
info@npp-itb.spb.ru

обсудить  |  все отзывы (7)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[24238; 4; 2.75]