Компьютерная безопасность. Простота или эффективность?

Компьютерная безопасность. Простота или эффективность?

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

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

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

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

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

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

Если речь заходит о противодействии атакам из сети, то здесь сразу встает проблема противодействия запуску всевозможных вредоносных и шпионских программ. Все подобные программы выявить антивирусными средствами не представляется возможным, всегда есть угроза занесения подобной программы на компьютер, а при отсутствии механизма обеспечения замкнутости программной среды, ее запуска. Данный тезис можно обосновать, но не будем здесь утруждать ни себя, ни читателя, приведем лишь одно из опубликованных мнений экспертов: "Грэхем Ингрэм, главный управляющий австралийского подразделения Группы оперативного реагирования на чрезвычайные ситуации в компьютерной области (AusCERT) утверждает, что распространённые антивирусные приложения блокируют лишь около 20 процентов недавно появившихся вредоносных программ. При этом популярные антивирусы пропускают до 80 процентов новых троянов, шпионов и других вредоносных программ. Это означает, что в восьми из десяти случаев недавно появившийся вирус может проникнуть на компьютер пользователя" (источник: www.itsec.ru  от 24.07.2006 г.).

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

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

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

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

Рис.1. Интерфейс настройки разграничений прав доступа к объектам файловой системы для субъекта “пользователь”

Отличительной особенностью реализации данного механизма защиты (позволяющей кардинально упрощать задачу администрирования) является то, что правила доступа назначаются пользователям, а не присваиваются в качестве атрибутов файловым объектам и то, что основной разграничительной политикой является разрешительная политика ("Ресурсы, разрешенные для…"). Это позволяет значительно упростить настройки, т.к. не требуется устанавливать соответствующие разграничения для всех объектов на жестком диске и внешних накопителях, локальных и разделенных в сети. При настройке механизма защиты (см. рис. 1) одной записью мы разрешили пользователю User 1 запись и чтение только в каталог D:\Doc (заметим, что разрешить доступ одной записью можно к файловому объекту любого уровня иерархии – диск, каталог, подкаталог, файл) , а выполнение программ только из каталогов C:\Windows и C:\Program Files (одновременно запретив туда запись – реализовали замкнутую программную среду). Нам необходимо контролировать и системные процессы и приложения, при этом предполагаем, что приложения администратором устанавливаются в простейшем случае только  в каталог C:\Program Files. Вот действительно существенное упрощение, правда, потребовавшее кардинальной переработки механизма контроля доступа к ресурсам.

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

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

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

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

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

Рис.2. Интерфейс настройки переназначения путей к каталогам

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

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

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

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

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

Почему же нельзя запретить пользователю System модификацию системного диска средствами ОС? Да потому, что некоторые системные процессы (априори запускаемые под учетной записью System) должны иметь право записи на системный диск. К таким процессам относятся: winlogon.exe, lsass.exe, csrss.exe, svchost.exe, services.exe и некоторые другие (всего не более десятка). Запретив подобное право доступа к системному диску пользователю System, тем самым, запретите и всем системным процессам – увидите “синий экран” (можете проверить).

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

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

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

Интерфейс настройки данного механизма защиты, реализованного в КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003, приведен на рис. 3.

Рис.3. Интерфейс настройки разграничений прав доступа к объектам файловой системы для субъекта “процесс”

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

Продолжим исследование. А если на защищаемом компьютере должна использоваться (либо просто установлена на системном диске, т.е. может запускаться пользователем) какая-либо виртуальная машина, например, позволяющая запускать командные файлы с расширением ".bat”. Это еще одна проблема, состоящая в том, что это уже не исполняемый файл, и для его запуска  системой осуществляется запрос не на выполнение, а на чтение. Поскольку для возможности работы пользователя на компьютере, мы должны разрешить ему одновременно запись и чтение в какие-либо объекты. Следовательно, он сможет записать и выполнить командный файл (по сути, в части безопасности, это то же, что и запустить исполняемый файл).

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

Интересно, а ответит ли нам не специалист на вопрос: присутствуют ли в дистрибутиве ОС Windows виртуальные машины, и если да, то какие? Как не специалист определит то, каким процессом обращается для запуска командного файла виртуальная машина? И т.д. и т.п.

Давайте и об этой проблеме умолчим, мы же боремся за простоту реализации СЗИ от НСД, эксплуатировать которую можно и без навыков администрирования!

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

Читатель может возразить автору : системные процессы, системная учетная запись и т.д., что за изыски? Да не хватит злоумышленнику интеллекта воспользоваться рассмотренными уязвимостями, все это автором "надумано"!

Так ли это? Рассмотрим на примере динамику развития лишь  одной группы атак – атак на сервисы олицетворения с целью расширения привилегий.

В современных ОС семейства Windows для идентификации субъектов, выполняющих в системе различные действия, используются не имена (которые могут и не быть уникальными), а идентификаторы защиты (security identifiers, SID). SID имеются у пользователей, локальных и доменных групп, локальных компьютеров, доменов и членов доменов. SID представляет собой уникальное числовое значение переменной длины, формируемое из номера версии структуры SID, 48-битного кода агента идентификатора и переменного количества 32-битных кодов субагентов.

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

Маркер может быть основным (идентифицирует контекст защиты процесса) или олицетворяющим (применяется для временного заимствования потоком другого контекста защиты — обычно другого пользователя).

Олицетворение (impersonation) — средство, используемое в модели защиты Windows, предоставляющее возможность отдельному потоку выполняться в контексте защиты отличном от контекста защиты процесса, т.е. действовать от лица другого пользователя. Олицетворение, например, применяется в модели программирования "клиент-сервер". При заимствовании прав сервер временно принимает профиль защиты клиента, который обращается к ресурсу. Тогда сервер может работать с ресурсом от имени клиента, а система защиты проводить проверку его прав доступа.

Рис. 4 иллюстрирует схему обслуживания клиентского запроса.

Рис.4. Обслуживание клиентского запроса на доступ к ресурсу с использованием олицетворения

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

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

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

В порядке иллюстрации, приведем динамику изменения во времени процентной доли атак на расширение привилегий, см. рис. 5. Данная статистика в свое время была получена на основании бюллетеней безопасности Microsoft (http://www.microsoft.com/technet/security) и архива рассылки NTBugTraq (http://www.ntbagtraq.com, http://security.nnov.ru).

Рис. 5. Динамика изменения во времени процентной доли атак на расширение привилегий

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

Невольно возникает вопрос, почему же мы не требуем соответствующей квалификации от администратора безопасности, которая позволила бы ему оказывать противодействие сложным атакам, и пытаемся создать для него простую СЗИ от НСД, чем это, в конечном счете, чревато?! Давайте не будем считать потенциального злоумышленника дураком и неучем, особенно, когда дело касается корпоративных приложений и защиты конфиденциальных данных, по определению, являющихся “товаром”! Что же все-таки первично, если мы действительно хотим защитить свои конфиденциальные данные – простота или эффективность решений?

Поскольку уж мы коснулись в качестве примера темы противодействия атакам на сервисы олицетворения, то завершим исследование данного вопроса. На протяжении долгого времени  подобные уязвимости системы защиты ОС Windows семейства NT устранялись путем исправления ошибок в приложениях, что провоцировало появление новых атак, направленных на расширение привилегий. И вот, наконец,  в четвертом пакете обновления к ОС Windows 2000 впервые был реализован механизм противодействия атакам подобного рода путем введения отдельной привилегии, разрешающей олицетворение. Механизм контроля олицетворения, реализованный в ОС Windows 2000/XP/2003, заключается в предоставлении возможности доступа к сервисам олицетворения только определенным учетным записям с повышенными привилегиями (т.е. субъектом доступа к сервисам олицетворения является пользователь). Данный подход реализован путем введения отдельной привилегии "Олицетворение клиента после проверки подлинности", разрешающей только определенным учетным записям использовать заимствование прав. Это существенно изменило существующую статистику атак, однако, на наш взгляд, не позволило решить проблему в полном объеме.

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

Рассмотрим, как данный механизм защиты реализован в КСЗИ "Панцирь-К" для ОС Windows 2000/XP/2003. Интерфейс настройки данного механизма  приведен на рис. 6.

Рис.6. Интерфейс настройки разрешений/запретов олицетворения

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

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

Возвращаясь к проблеме простоты СЗИ от НСД. Что, этот механизм защиты просто настроить без навыков администрирования? Так давайте откажемся и от него, создавая СЗИ от НСД, только, не вернуться бы при этом к статистике, представленной на Рис.5 (в порядке замечания отметим, что решения данной задачи защиты мы не встречали ни в одной известной нам СЗИ от НСД).

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

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

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