БЕЗОПАСНОСТЬ

    

Вместо введения

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

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

Однако отсутствие теоретического обоснования принятых разработчиком решений не позволяет оценить реальную эффективность (потребительскую стоимость) подобных инструментов. Большинство же публикаций на эту тему в лучшем случае сводится к перечислению механизмов защиты, включенных в состав того или иного продукта. В качестве примера можем упомянуть статью "Еще одно средство для борьбы с внутренними угрозами" (см. http://pcweek.ru/?ID= 506755). Специфика средств защиты информации (применительно к любым их приложениям) такова, что их имеет смысл использовать (да и вообще говорить о какой-либо эффективности) лишь в том случае, если набор механизмов защиты позволяет решить поставленную задачу, а каждый механизм реализован корректно. Иначе кроме иллюзии защиты конечный потребитель ничего не получит (достаточно лишь одной возможности обхода средства защиты, чтобы оно было абсолютно бесполезным для практического использования) и в конечном счете просто зря потратит деньги.

Что же делать потребителю в ситуации, когда нет теоретически обоснованных требований к средству защиты ни с точки зрения достаточности набора механизмов защиты, ни в смысле корректности их реализации; когда разработчик не акцентирует внимание на этих проблемах, а лишь описывает некий предоставляемый им сервис защиты? Как потребителю ответить на вопрос, может ли то или иное средство защиты эффективно решить насущную для него проблему? Исходя из каких соображений, наконец, ему выбрать оптимальное решение, если их несколько? Опять же не будем забывать, что защита информации - это сложная научно-техническая и инженерная задача, и для ответа на все сформулированные выше вопросы требуется весьма высокая квалификация, прежде всего в области вычислительной техники и средств телекоммуникаций. Готов ли к этому потребитель, а если нет, то где ему взять подсказку?

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

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

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

Основополагающие принципы

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

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

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

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

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

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

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

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

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

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

Рис. 1. Изолированная обработка информации между сессиями различных категорий

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

- субъект имеет право доступа "запись-чтение" к объекту в том случае, если категория субъекта и категория объекта совпадают;

- субъект имеет право доступа "чтение" к объекту в том случае, если категория субъекта выше, чем категория объекта;

- субъект не имеет прав доступа к объекту в том случае, если категория субъекта ниже, чем категория объекта.

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

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

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

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

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

Рис. 2. Иллюстрация альтернативных схем выбора сессии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И так далее...

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

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

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

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

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

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

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

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

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

Автор статьи - докт. техн. наук, профессор, генеральный директор НПП "Информационные технологии в бизнесе" (www.npp-itb.spb.ru).