Контакты
Подписка
МЕНЮ
Контакты
Подписка

Компьютерная безопасность. Удобство администрирования СЗИ от НСД и эффективность защиты

Компьютерная безопасность. Удобство администрирования СЗИ от НСД и эффективность защиты

В рубрику "Защита информации" | К списку рубрик  |  К списку авторов  |  К списку публикаций

Компьютерная безопасность. Удобство администрирования СЗИ от НСД и эффективность защиты

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

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

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

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

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

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

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

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

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

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

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

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

Рассматриваемая реализация обеспечивает и принципиальную возможность упрощения администрирования за счет использования масок. Маска - это регулярное выражение, содержащее метасимволы "*", "?" и т.п., покрывающие несколько имен ресурсов сразу. Поэтому вместо внесения некоторого количества похожих имен ресурсов в списки правил разграничения доступа, вносится только одна маска, содержащая общую часть имен этих ресурсов и метасимволы, задающие правила последующего сравнения маски и имен ресурсов.

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

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

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

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

Заметим, что снижение вероятности ошибок администрирования здесь достигается не только простотой настройки прав доступа к ресурсам, но и наглядностью разграничительной политики доступа к ресурсам. Так, на рис. 1 в одном окне интерфейса отображается вся разграничительная политика доступа ко всем объектам файловой системы (в том числе и к объектам, разделенным в сети, и к объектам на внешних накопителях, включая мобильные), заданная для пользователя User 1 (иных прав доступа он не имеет, т.к. они не разрешены по умолчанию). Захотите посмотреть разграничительную политику для другого пользователя, выберите его, она также будет отображена в одном окне интерфейса. Не требуется перебирать объекты, смотреть на их атрибуты – все наглядно и информативно!

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

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

Метки безопасности являются элементами линейно упорядоченного множества M = {M1,…, Mk}. Метки безопасности назначаются субъектам и объектам (группам субъектов и объектов), служат для формализованного представления соответственно их категорий и уровней полномочий. Таким образом, в качестве учетной информации субъектов и объектов доступа, кроме их идентификаторов – имен, каждому субъекту и объекту задаются метки безопасности из множества M. Контроль доступа реализуется на основе правил, определяющих отношение линейного порядка на множестве M, где для любой пары элементов из множества M, задается один из типов отношения {>,<,=} (на практике реализуется выбор подмножества M, изоморфного конечному подмножеству натуральных чисел – такой выбор делает естественным арифметическое сравнение меток безопасности).

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

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

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

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

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

А теперь вернемся к интерфейсному решению, рассмотренному нами ранее (см. рис.1) и попытаемся его использовать для настройки полномочного контроля доступа к ресурсам. При этом нашей целью является реализация универсального решения, позволяющего задавать любые отношения субъектов и объектов доступа (необходимо "уйти" от жесткой формализации отношений, при это существенно не усложнив задачу настройки полномочной разграничительной политики доступа к ресурсам). Используем для назначения категорий понятие "профиль" (рис.1), присвоив соответствующие имена профилям “конфиденциально”, “открыто” и т.д. Назначение полномочий субъектам (пользователям), тогда будет состоять во внесении соответствующей учетной записи в соответствующий профиль. Назначение соответствующей профилю категории объектам состоит в размещении их для заданного профиля с правами “Ресурсы, разрешенные для записи” (при этом к ним будет разрешен доступ и на запись, и на чтение). По сложности подобные действия практически полностью совпадают с заданием меток (разметкой) субъектов и объектов. А вот теперь, если потребуется, мы можем реализовать практически любое правило, т.к. правила жестко не формализуются нашим интерфейсом. Например, чтобы реализовать правило, рассмотренное выше (для мандатного принципа контроля доступа), разместим для профиля "конфиденциально" объекты, предназначенные для хранения открытых данных (категория “открыто”) с правами "Ресурсы, разрешенные для чтения". Вот и все усложнение задачи администрирования – при этом получаем тот же результат, реализовав ту же разграничительную политику доступа к ресурсам, что и при использовании меток безопасности! Но при этом нет никакой жесткой формализации, задача реализации разграничительной политики доступа к ресурсам может быть решена корректно!

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

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

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

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

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

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

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

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

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

Вот для настройки разграничительной политики доступа к ресурсам для субъекта "процесс" дополнительная помощь администратору просто необходима. Например, ответьте на вопрос, к каким системным ресурсам можно запретить, а к каким необходимо разрешить доступ приложению Internet Explorer, чтобы минимизировать ущерб от возможных атак на это приложение и при этом обеспечить корректность его функционирования? Не просто, вероятность ошибок администрирования здесь высока! А решить эту задачу необходимо, если используется данное приложение (в котором, кстати говоря, достаточно регулярно обнаруживаются ошибки), конечно, в предположении, что нас беспокоят вопросы защищенности соответствующих объектов.

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

Рис.5. Отображение зарегистрированных событий в журнале аудита

С учетом же того, что за продолжительное время тестовой эксплуатации может быть собран весьма большой по объему журнал аудита, в КСЗИ предусмотрена возможность фильтрации событий по одному, либо по совокупности параметров. Окно фильтра журналов представлено на рис.6.

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

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

Рис.6. Интерфейс настройки фильтра зарегистрированных событий

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

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

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

В КСЗИ “Панцирь-К” для ОС Windows 2000/XP/2003 данная возможность реализована следующим образом.

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

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

Окно фильтра отображения настроек в КСЗИ “Панцирь-К” для ОС Windows 2000/XP/2003 представлено на Рис. 7, окно отображения настроек в текстовом виде - на Рис.8.

Рис. 7. Окно фильтра настроек КСЗИ для отображения в текстовом виде

Рис. 8. Окно отображения настроек КСЗИ

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

Статьи про теме