КОМПЬЮТЕРНАЯ БЕЗОПАСНОСТЬ. ПРИКЛАДНОЙ УРОВЕНЬ ЗАЩИТЫ ИНФОРМАЦИИ. ПОСТАНОВКА И РЕШЕНИЕ ЗАДАЧИ В ОБЩЕМ ВИДЕ

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

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

Требования нормативных документов к реализации прикладного уровня защиты информации.

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

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

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

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

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

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

Рассмотрим достоинства и недостатки защиты на прикладном уровне по сравнению с защитой на системном уровне.

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

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

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

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

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

Заметим, что именно такая концепция положена в основу построения Комплексной системы защиты информации (КСЗИ) «Панцирь-К» для ОС Windows 2000/XP/2003.

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

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

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

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

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

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

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

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

Рис. 1. Иллюстрация контроля действий пользователей на прикладном уровне

С учетом всего сказанного, сформулируем задачу защиты от НСД на прикладном уровне в общем виде.

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

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

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

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

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

Рис. 2. Интерфейс настройки механизма контроля целостности (замкнутости) программной среды

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

Альтернативная задача защиты информации от НСД на прикладном уровне.

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

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

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

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

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

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

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

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

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

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

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

Рис. 4. Интерфейс настройки сценариев автоматической реакции на строку события

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

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

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

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

Рис.5. Отображение структуры защищаемой корпоративной сети предприятия

Рис.6. Представление справочной информации по пользователям

В КСЗИ реализован механизм удаленного с сервера безопасности контроля активности клиентской части СЗИ от НСД. На рис. 7 проиллюстрированы возможные варианты текущего состояния клиентской части СЗИ от НСД, удаленно фиксируемые и отображаемые на сервере безопасности (в интерфейсе, приведенном на рис. 5): 1) компьютер выключен (по питанию) или не подключен к сети; 2) компьютер подключен к сети, но при соединении клиентской части СЗИ от НСД с сервером безопасности, аутентификация не проходит; 3) компьютер подключен к сети, но клиентская часть СЗИ от НСД на нем не активна; 4) компьютер подключен к сети и на нем активна клиентская часть СЗИ от НСД (штатный режим).

Компьютер в состоянии "1" обозначается темно-зеленым, в состоянии "2" – красно-желтым, в состоянии "3" – красным, и в состоянии "4" – ярко-зеленым цветом (рис.7).

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

Рис.7. Варианты отображения состояния защищаемых компьютеров на сервере безопасности

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

Рис.8 Уровневая модель защиты информации

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