8(495)909-90-01
8(964)644-46-00
pro@sio.su
Главная
Системы видеонаблюдения
Охранная сигнализация
Пожарная сигнализация
Система пожаротушения
Система контроля удаленного доступа
Оповещение и эвакуация
Контроль периметра
Система домофонии
Парковочные системы
Проектирование слаботочных сетей
Аварийный
контроль
Вы находитесь в разделе Типовых решений систем безопасности

Комплексный подход к решению задачи защиты компьютерной информации



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

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

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

Пусть множества С = {С1,…, Ск} и О = {О1,…, Оk} – соответственно линейно упорядоченные множества субъектов и объектов доступа. В качестве субъекта доступа Сi, i = 1,…,k рассматривается как отдельный субъект, так и группа субъектов, обладающих одинаковыми правами доступа, соответственно, в качестве объекта доступа Оi, i = 1,…,k может также рассматриваться как отдельный объект, так и группа объектов, характеризуемых одинаковыми к ним правами доступа. Пусть S = {0,1} – множество прав доступа, где 0 обозначает отсутствие доступа субъекта к объекту, 1 – разрешение доступа (в зависимости от типа доступа, вместо разрешения 1, можно ввести тип разрешения: запись Зп, чтение Чт, выполнение Вп.

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



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

Модель контроля доступа формально может быть описана следующим образом - элемент (Dij) матрицы Dij = 1, если i = j, иначе Dij = 0.

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


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


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

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

Основу полномочного контроля доступа составляет способ формализации понятий группа пользователей и группа объектов, на основании вводимой шкалы полномочий. Наиболее широко на практике используется способ иерархической формализации отношения полномочий, состоящий в следующем. Иерархическая шкала полномочий вводится на основе категорирования данных (открытые, конфиденциальные, строго конфиденциальные и т.д.) и прав допуска к данным пользователей (по аналогии с понятием формы допуска). Будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}). Соответствующая формализация правил доступа субъектов к объектам при этом сводится к следующему:
  • Субъект имеет право доступа Зп/Чт к объекту в том случае, если полномочия субъекта и категория объекта совпадают;
  • Субъект имеет право доступа Чт к объекту в том случае, если полномочия субъекта выше, чем категория объекта;
  • Субъект не имеет прав доступа к объекту в том случае, если полномочия субъекта ниже, чем категория объекта.


Матрица доступа D, описывающая полномочную модель контроля доступа, имеет следующий вид.



Модель полномочного контроля доступа формально может быть описана следующим образом - элемент (Dij) матрицы Dij = Зп/Чт, если i = j, иначе Dij = Чт, если i > j, соответственно Dij = 0, если i < j, где i - порядковый номер объекта (номер строки в матрице доступа), j - порядковый номер субъекта (номер столбца в матрице доступа).

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

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

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

Применение механизма меток безопасности – это уже попытка формализации анализа прав диспетчером доступа (т.е. это способ обработки запроса диспетчером доступа).

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

Рассмотрим правила анализа меток диспетчером доступа для модели полномочного контроля доступа. Для этого введем следующие обозначения:
  • Ms – метка безопасности субъекта (группы субъектов) доступа;
  • Mo – метка безопасности объекта (группы объектов) доступа;
  • Метка безопасности с порядковым номером i – Mi устанавливается для субъекта доступа с порядковым номером i – Ci и для объекта доступа с порядковым номером i – Oi.


Правила (разрешения) состоят в следующем:
  1. Субъект С имеет доступ к объекту О в режиме “Чтения” в случае, если выполняется условие: Mc <, = Mo.
  2. Субъект С имеет доступ к объекту О в режиме “Записи” в случае, если выполняется условие: Mc = Mo.


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

  1. Метки могут быть не только иерархические (могут сочетать в себе как иерархические, так и не иерархические признаки). При этом подобная формализация уже не имеет смысла, и необходимо вводить такую опцию, как задание правила формализации, что кардинально усложнит задачу администрирования. Вообще при любой формализации не выполняется основное требование к построению сложной технической системе – ее универсальность. В данных же приложениях универсальность имеет очень большое значение – чем универсальней система защиты, тем шире возможности по формированию политики безопасности под конкретные ее приложения. В данном случае видим, что рассматриваемый способ формализации правил обеспечивает однозначное соответствие матрице доступа D для полномочной модели (ни шаг влево, ни шаг вправо).
  2. Данные правила позволяют разграничивать права доступа только между полномочиями и категориями (т.е. между соответствующими группами субъектов и объектов). Может потребоваться разграничивать доступ различных субъектов одной группы, имеющих одну привилегию, соответственно, к различным объектам одной категории. Т.е. подобный механизм не самодостаточный, наряду с ним потребуется использовать разграничения на основе матрицы доступа.
  3. Данные формализованные правила не распространяются на такой атрибут доступа, как выполнение Вп, с которым связана реализация ключевого механизма защиты – механизма обеспечения замкнутости программной среды (локализация ПО для пользователей). Т.е. подобный механизм не самодостаточный, наряду с ним потребуется использовать разграничения на основе матрицы доступа.
  4. В подобную формализованную схему разграничений практически не вписывается возможность задания разграничений для системных субъектов (например, System) и системных объектов (например, системный диск). Т.е. подобный механизм не самодостаточный, наряду с ним потребуется использовать разграничения на основе матрицы доступа.
  5. Эффективные разграничения к объектам файловой системы предполагают возможность задавать права доступа не только для субъектов пользователь, но и для субъектов процесс (эксклюзивно, либо совместно с правами пользователей), что никак не вписывается в рассматриваемую формализованную схему. Т.е. подобный механизм не самодостаточный, наряду с ним потребуется использовать разграничения на основе матрицы доступа.
  6. Разграничения доступа к файловым объектам составляют лишь часть задаваемых разграничений (существует множество иных ресурсов – реестр ОС, принтеры, сетевые ресурсы, всевозможные устройства). Разграничение доступа к большинству из этих ресурсов никак не связано с рассматриваемой возможностью формализации. Кроме того, в общем случае следует рассматривать сложность настройки не отдельно взятого механизма, а системы в целом (настройка разграничительной политики доступа к файловым объектам составляет лишь незначительную часть настройки механизмов защиты всей системы).


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

Постановка и решение задачи антивирусной защиты на основе полномочного контроля доступа. Возможности комплексирования альтернативных решений.

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


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

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

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

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


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

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

Рассмотрим, как данная задача может быть решена средствами полномочного контроля доступа. Опять же будем считать, что чем выше полномочия субъекта и категория объекта, тем соответственно, меньше их порядковый номер в линейно полномочно упорядоченных множествах субъектов и объектов - С = {С1,…, Ск} и О = {О1,…, Оk}). Обозначим же через Pi вероятность того, что документ i-й категории заражен макро-вирусом, при этом (как было сказано выше) априори имеем: P1 < P2 <…


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

Модель полномочного контроля доступа в данных приложениях формально может быть описана следующим образом - элемент (Fij) матрицы Fij = Зп/Чт, если i = j, иначе Fij = Зп, если i > j, соответственно Fij = 0, если i < j, где i - порядковый номер объекта (номер строки в матрице доступа), j - порядковый номер субъекта (номер столбца в матрице доступа).

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

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

Чтобы ответить на вопрос, как быть – как совместить несовместимое при реализации единого комплексного решения, рассмотрим, какую информацию мы категорируем, применительно к решению задачи антивирусной защиты. Естественно, что качественное отличие в обработке имеет открытая информация и конфиденциальная информация, т.е. можем выделить две основные категории открыто и конфиденциально. При этом обработка конфиденциальной информации различных категорий, в части вероятности быть исходно зараженной макро-вирусом, уже отличается не столь существенно. С учетом сказанного, имеем смысл рассматривать следующее отношение вероятностей того, что документ i-й категории заражен макро-вирусом, обозначив категорию открыто, как k, имеем: P1 =P2 =…=Pk-1<
Естественно, что если мы не можем разрешить ни чтения, ни запись, то остается лишь одно решение, связанное с полным запретом доступа. С учетом сказанного, получаем модель полномочного контроля доступа, реализация которой позволяет решать рассмотренные альтернативные задачи в комплексе, описываемую матрицей доступа D(F):



Модель полномочного контроля доступа формально может быть описана следующим образом - элемент (D(F)ij) матрицы D(F)ij = Зп/Чт, если i = j, иначе D(F)ij = Чт, если i > j >1, соответственно D(F)ij = 0, если i < j > 1 и, если i > j = 1, где i - порядковый номер объекта (номер строки в матрице доступа), j - порядковый номер субъекта (номер столбца в матрице доступа).

Заметим, что по сути, при таком подходе к реализации полномочного контроля доступа обработка открытых данных полностью изолируется от обработки конфиденциальных данных. Результатом такого решения, никак не противоречащего идее обработки данных на основе полномочий пользователей и категорий объектов, является то, что повышение вероятности заражения макро-вирусом открытых данных никак не сказывается на вероятности заражения макро-вирусом конфиденциальных данных, что определяется условием: P1 =P2 =…=Pk-1<
В порядке замечания отметим, что в общем случае, использую рассмотренный подход (запрещая соответствующие права доступа) можно формировать различные правила контроля доступа (различные варианты защиты от “заражения” макро-вирусом конфиденциальных данных). Один из примеров соответствующей матрицы (изолируется обработка данных, наивысшей категории) доступа представлен ниже.



Формализация же правил обработки запроса диспетчером доступа на основе меток, при реализации комплексного решения вообще, на наш взгляд, не имеет смысла.

Подходы к реализации комплексного решения

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

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



Рис.1.

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

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

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

Несколькими записями в интерфейсе (см. Рис. настраивается и механизм обеспечения замкнутости программной среды. В поле Ресурсы, разрешенные для выполнения для каждого пользователя (для различных пользователей они могут не совпадать, что является очевидным условием при обработке данных различных категорий) следует внести те каталоги на жестком диске, из которых им разрешено запускать исполняемые файлы (соответственно к этим каталогам пользователям должен быть не разрешен доступ Зп), включая соответствующие каталоги системного диска, например, это могут быть каталоги C:\Program Files и C:\Winnt (WINDOWS) (на системном диске С). Видим как просто настраивается такой сложный механизм (сохраняются все действия администратора по установке и удалению ПО штатными средствами).

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

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



Рис.2

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

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

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

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

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

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



Рис. 3

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

Задача задания различных полномочий пользователям при работе с различными приложениями

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

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

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

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



Рис. 4

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

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

Задача реализации динамических полномочий пользователей. Альтернативные подходы к решению

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Рис.5

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

Запретив смену первичного маркера для приложения, мы тем самым запрещаем запуск этого приложения с правами другого пользователя.

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



Рис. 6

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

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

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

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

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

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




Читайте далее:
28 - 31 января 2008 года
Анализ рынка безопасности ,май 2005 года,
Воровство в супермаркете
6. предпочтения участников рынка безопасности 2007 года
Некоторые мысли после выставки mips 2008
Security 50 – лучшие в мире 50 компаний в области безопасности по объему продаж
01 - 03 февраля 2008 года
1.4. действия сил охраны
25 - 29 февраля 2008 года
07 - 13 апреля 2008 года ,рынок it,
21 - 27 апреля 2008 года ,рынок it,
Адаптер sb-1 для монтажа видеокамер на столбах
01- 04 мая 2008 года ,рынок it,
12 - 18 мая 2008 года ,рынок безопасности,
26 - 31 мая 2008 года ,рынок безопасности,