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

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

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

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

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

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

Постановка задачи защиты информации в корпоративных приложениях. Основные понятия и определения

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

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

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

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

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

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

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

Аксиома 2. Сущность "сессия" должна быть определена единым способом для всех механизмов контроля доступа к ресурсам.

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

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

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

Определение 3. Под доступом пользователя к сессии будем понимать запуск на защищаемом компьютере соответствующего режима обработки категорированной информации. Соответственно, под изменением пользователем сессии будем понимать изменение на защищаемом компьютере режима обработки категорированной информации.

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

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

Базовые принципы (требования к корректности) реализации

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

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

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

Введем следующие обозначения.

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

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

• субъект имеет право доступа "Зп/Чт" к объекту в том случае, если полномочия субъекта и категория объекта совпадают;
• субъект имеет право доступа "Чт" к объекту в том случае, если полномочия субъекта выше, чем категория объекта;
• субъект не имеет прав доступа к объекту в том случае, если полномочия субъекта ниже, чем категория объекта.

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

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

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

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

Утверждение доказано.

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

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

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

Модель сессионного контроля доступа можно представить матрицей доступа S и матрицей привилегий пользователя P, имеющими следующий вид:

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

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

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

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

Утверждение доказано.

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

Альтернативные способы определения сущности "сессия"

В общем случае возможны различные пути задания сущности "сессия".

Включение в схему контроля доступа к ресурсам дополнительных сущностей сессии "выбор сессии" и объекта "выбор сессии".

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

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

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

Использование для задания сессии сущности "пользователь (учетная запись)".

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

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

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

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

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

Сразу отметим, что не следует заблуждаться относительно того, что задача противодействия внутренним ИТ-угрозам сколько-нибудь корректно может быть решена механизмами защиты современных универсальных ОС – они для этого не предназначены. Рассматривая возможность задания сущности "сессия" учетной записью, мы лишь говорили о способе, позволяющем максимально использовать существующие наработки, не более того! Чтобы решить задачу корректно, необходим весьма внушительный список дополнительных механизмов защиты.

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

Акцентируем внимание читателя лишь на некоторых проблемах (на примере архитектурных решений ОС Windows), без устранения которых в принципе невозможно говорить о каком-либо решении задачи противодействия внутренним ИТ-угрозам рассматриваемым способом:

• Существуют файловые объекты, которые системными средствами не могут быть разделены между пользователями (к таким объектам, например, можно отнести папку All Uaers);
• В многопользовательском режиме (при запуске приложения под другой учетной записью) ОС не разграничивает между пользователями буфер обмена (является "принадлежность" рабочего стола);
• Существуют десятки способов межпроцессного взаимодействия (программа, реализующая подобный канал обмена данными, разрабатывается программистом средней квалификации в течение часа). Буфер обмена – это лишь наиболее очевидный и широко используемый способ межпроцессного взаимодействия. Поскольку все подобные “каналы” обмена данными "перекрыть" практически невозможно, ключевым механизмом при решении задачи противодействия внутренним ИТ-угрозам становится механизм обеспечения замкнутости программной среды (механизм, предотвращающий возможность запуска пользователем несанкционированных программ);
• В общем случае невозможно корректно определить учетную запись (пользователя), от которой осуществляется запрос доступа ко многим внешним устройствам (к тем устройствам, доступ к которым осуществляется не напрямую из приложения, а через драйвер устройства, кстати говоря, подобных устройств сегодня большинство). Т.к. запрос осуществляется непосредственно драйвером устройства, то идентифицируемое в этом случае средством защиты имя пользователя будет "System". Возможно это не столь критично при однопользовательском режиме обработки, поскольку можно предположить, что запрос инициирован единственным пользователем, зарегистрированным в системе – учетная запись не определяется из запроса, что уже некорректно, а любая некорректность несет в себе угрозу; при многопользовательском же режиме данная задача становится корректно не разрешимой (если вы используете средства разграничения прав доступа пользователей к устройствам, то можете провести соответствующий эксперимент). Единственно корректным решением здесь становится использование механизма обеспечения замкнутости программной среды – для пользователей разграничивается возможность запуска приложения работы с устройством;
• И т.д., и т.п.

Использование для задания сессии сущности "процесс"

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

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

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

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

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

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

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