Вы находитесь в разделе Типовых решений систем безопасности
Защита от инсайдеров. решение может быть только комплексным ,часть2,Пример (отметим, что могут быть и иные варианты) разграничительной политики для исследуемых офисных приложений к системным ресурсам, позволяющей решить рассматриваемую задачу защиты при обеспечении корректности функционирования анализируемых приложений, представлен в Табл.1. Таблица 1. Единые разграничения для анализируемых процессов
Видим, что сформулированная задача защиты (а ведь это очень критичная по возможным последствиям и сложная для решения задача) может быть решена, причем решена эффективно, при этом настройки, обеспечивающие реализацию необходимой разграничительной политики доступа к ресурсам, минимальны (практически несколько строк в интерфейсах соответствующих механизмов защиты). Заметим, что задача защиты системных ресурсов при этом решается в общем виде, т.к. становится неважным, известным ли, либо каким-либо новым макро-вирусом осуществляется атака (не требуется выявления каких-либо сигнатур). Итак, мы решили задачу изменения области приложений системного средства в полном объеме. С учетом этого, перейдет к рассмотрению основной задачи защиты информации от НСД – к реализации разграничительной политики доступа к ресурсам в общем случае. Рассмотрим, в чем особенность ее постановки и подходов к решению в корпоративных приложениях. 1. Задача реализации разграничительной политики доступа к ресурсам Защита от НСД (в том числе, и в части противодействия возможности хищения данных инсайдерами) сводится к реализации разграничительной политики доступа к ресурсам, к тем ресурсам, которые необходимы для выполнения служебной деятельности сотрудником компании, и потому, которые разрешены для подключения к системе. Однако, в корпоративных приложениях задача реализации разграничительной политики доступа к ресурсам в самой своей сути уже кардинально иная, нежели задача, решаемая механизмами защиты современных универсальных ОС. Причиной этому служит то, что обрабатываемые данные в корпоративных приложениях, как правило, могут быть категорированы по уровню конфиденциальности: открытая информация, конфиденциальная информация и т.д. (на практике, как правило, все ограничивается двумя категориями – открытая и конфиденциальная) При этом один и тот же пользователь в рамках выполнения своих служебных обязанностей должен обрабатывать, как открытые, так и конфиденциальные данные. Однако априори эти данные имеют совершенно различную ценность для предприятия, следовательно, режимы их обработки должны различаться (например, только открытую информацию можно передавать во внешнюю сеть, сохранять на внешних накопителях, конфиденциальные данные могут обрабатываться только неким корпоративным приложением и т.д., сохраняться на накопителе только в зашифрованном виде, причем знание ключа не должно давать пользователю возможность нарушить ее конфиденциальность и т.д.). Это обусловливает, что основу разграничительной политики уже должны составлять не какие-либо конкретные ресурсы, а режимы обработки категорированной информации, причем при задании правил обработки информации уже, в первую очередь, должен рассматриваться не вопрос разграничения доступа к ресурсам между различными пользователями, а вопрос реализации различных режимов обработки данных различной категории для одного и того же пользователя и правила доступа пользователей к режимам обработки категорированной информации. Введем основополагающее для рассматриваемых приложений защиты информации понятие сессия. Под сессией пользователя будем понимать режим обработки пользователем данных соответствующей категории, реализуемый соответствующей разграничительной политикой доступа к ресурсам. По категории обрабатываемых в сессии данных, будем соответствующим образом подразделять на категории и сессии: открытая, конфиденциальная и т.д. Сформулируем основополагающие принципы реализации разграничительной политики доступа к ресурсам в корпоративных приложениях. Принцип 1. В корпоративных приложениях при реализации разграничительной политики доступа к ресурсам в качестве субъекта доступа к ресурсам следует рассматривать сущность сессия, т.е. именно для этой сущности, как субъекта доступа, и должна формироваться разграничительная политика доступа к ресурсам. Под сессионным контролем доступа будем понимать разграничение между сессиями прав доступа к ресурсам, основанное на задании и реализации разграничительной политики доступа сессий к ресурсам и на назначении привилегий сессиям (в том числе, и по доступу к ресурсам). Ввиду того, что один и тот же пользователь на одном компьютере должен обрабатывать данные различных категорий конфиденциальности, один пользователь должен получать доступ к различным сессиям, соответственно доступ к смене сессии. Под доступом пользователя к сессии будем понимать запуск на защищаемом компьютере соответствующего режима обработки категорированной информации. Соответственно под изменением пользователем сессии будем понимать изменение на защищаемом компьютере режима обработки категорированной информации. Принцип 2. В общем случае (когда несколько сотрудников предприятия допущены на одном и том же компьютере к обработке данных одной и той же категории) субъектом доступа в корпоративных приложениях определяется парой сущностей сессия, пользователь (учетная запись), при этом правила доступа к ресурсам для пользователей следует рассматривать как подмножество (усеченное множество) правил доступа, заданных для сессии. Принцип 3. В корпоративных приложениях при реализации разграничительной политики доступа к ресурсам в качестве объекта доступа к ресурсам следует рассматривать сущность сессия, т.е. именно к этой сущности, как к объекту доступа, и должна формироваться разграничительная политика доступа пользователей (учетных записей) к ресурсам Первый вопрос, возникающий, в части реализации сессионного контроля доступа, состоит в том, а допустим ли обмен информацией между сессиями (если да, то по каким правилам), либо обработка информации в сессии должна быть полностью изолированной (в этом случае пользователь получает возможность доступа к информации иной категории только посредством изменения сессии). Требование 1. Обработка информации между сессиями различной категории должна быть полностью изолированной. Допускается обмен информацией между различными пользователями только в рамках сессий одной категории. Данное требование может быть сформулировано, исходя собственно из задачи защиты информации от несанкционированного доступа (НСД), включающей защиту от нарушения конфиденциальности (хищения) данных, обеспечение доступности и целостности (противодействие несанкционированному искажению и удалению) данных. Соответственно, при попытке реализации обмена данными в сессиях различной категории (для одного пользователя), получаем следующее противоречие. С одной стороны, можно было бы дополнительно разрешить чтение (не запись) документов в сессии, категория которых ниже категории сессии (это не приведет к хищению категорированных данных – их категория при этом не понизится). Такие правила реализуются, так называемым, принципом мандатного контроля доступа к ресурсам. С другой стороны, нельзя разрешить подобную возможность, т.к. запись при этом разрешается в объекты категории выше, чем категория прочтенных данных, а чем ниже категория (например, открыто), тем выше вероятность заражения документов вирусами, как следствие, тем выше вероятность заражения данных высокой категории в результате прочтения данных низкой категории (результатом такого разрешения является многократное повышение вероятности нарушения доступности и целостности данных высокой категории конфиденциальности, т.е. именно тех данных, которые, в первую очередь, и должны защищаться от НСД). Получаем единственно возможное корректное решение - обработка информации между сессиями различной категории должна быть полностью изолированной. Переход же к обработке информации другой категории при этом должен осуществляться сменой пользователей текущей сессии. В порядке замечания отметим, что во многих средствах защиты, применяемых для обработки категорированной информации, реализован мандатный принцип контроля доступа, который сводится к следующему:
Реализация данного принципа контроля доступа не эффективна в рассматриваемых приложениях, ввиду того, что им не обеспечивается основополагающее требование к защите категорированной информации от НСД, включающей защиту не только от нарушения конфиденциальности (хищения) данных, но и обеспечение доступности и целостности (противодействие несанкционированному искажению и удалению) данных. Следствие. При реализации сессионного контроля доступа не должно существовать объекта доступа (ресурса), к которому не реализована разграничительная политика доступа. Данное требование выполнимо только при условии реализации разрешительной разграничительной политики Все, что не разрешено – явно не указано, то запрещено. Казалось бы, это требование очевидно, т.к. при невыполнении данного требования невозможно изолировать режимы обработки категорированной информации. Любой ресурс, в том числе, и файловый объект, доступ к которому не разграничивается, является каналом понижения категории информации, приводящей к возможности ее хищения, за счет несанкционированной смены пользователем режима ее обработки. Однако на практике, порою, защиту от хищения данных пытаются реализовать простейшим образом, задав разграничения лишь к отдельным ресурсам, например, к отдельным файловым объектам, хранящим конфиденциальные данные, не понимая, что это бессмысленно – доступ должен быть разграничен ко всем объектам! Необходимость выполнения данного требования накладывает очень серьезные ограничения на реализацию интерфейсных решений. Сегодня в средства защиты часто вводятся упрощающие настройку формализации отношения. Пример тому – использование меток безопасности (иногда называют мандатами). Упрощение администрирования (ради чего и вводятся метки – это лишь интерфейсное решение, все подобные настройки могут быть реализованы и с использованием матрицы доступа, не формализующей отношения) состоит в том, что вводятся метки, соответствующие категориям обрабатываемой информации. Данные метки присваиваются субъектам и объектам доступа. При контроле же доступа задаются определенные правила сравнения меток (формализованные отношения). Например, если метки совпадут (и данные и пользователь имеют категорию конфиденциально), то доступ к файловому объекту пользователю разрешается, нет – не разрешается. Вот здесь и возникают проблемы. Сама идея формализации отношений с использованием меток, как интерфейсное решение, упрощающее задачу администрирования, возможно, и не так плоха, но вот как формализовать подобные отношения, обеспечив выполнение соответствующего требования и одновременно работоспособность системы и приложений. Не будем забывать, что доступ должен разграничиваться для всех пользователей ко всем объектам, а если это, например, системный диск, какую метку (категорию конфиденциальности) ему присвоить? И таких вопросов появляется множество. Подчас, на практике, все это приводит к тому, что система и приложения могут корректно функционировать лишь в одном случае, если вводится только одна (один тип) метки. Но это вообще бессмысленно. Второй, не мене важный вопрос, касающийся реализации сессионного контроля доступа к ресурсам, состоит в том, что первично: выбор сессии с последующим доступом к данным в рамках выбранной сессии, либо, наоборот, выбор сессии, посредством чтения данных определенной категории - категория которых определяет категорию сессии (режим обработки этих данных). Требование 2. Сессия должна быть задана (выбрана) до начала обработки данных (данные должны загружаться – из файлового объекта, из сети и т.д. только после того, как определен режим их обработки, соответственно, способы загрузки и обработки, т.е. сессия). В противном случае имеем следующее противоречие. Если сессия определяется тем, какие данные считаны (например, если считываются конфиденциальные данные, то вступает в силу конфиденциальная сессия – режим обработки конфиденциальных данных), то необходимо в начальный момент времени (сессия не определена) разрешить пользователю чтение данных всех категорий, к которым он допущен в рамках своей служебной деятельности. Однако при этом не могут быть реализованы требования к заданию различных режимов обработки данных различных категорий (невозможно задать для данных различных категорий, каким приложением, с какими привилегиями пользователя, с какого устройства, с какими правами доступа к системным ресурсам и т.д., они могут быть прочитаны). Следовательно, для реализации этого условия, режимы обработки (в частности, по доступу к данным различных категорий конфиденциальности) до выбора сессии должны совпадать, что противоречит Требованию 1. Заметим, что на сегодняшний день большинство известных нам средств защиты почему-то построены вопреки данному, вполне очевидному требованию. И, наконец, необходимо акцентировать внимание еще на одном, уж казалось бы, совсем очевидном требовании. Сессионный контроль доступа реализуется посредством набора механизмов разграничения прав доступа сущности “сессия” к различным ресурсам (чем изолируются режимы обработки конфиденциальных данных). В общем случае сущность сессия может определяться различными способами (об этом далее). Очевидно, что при построении средства защиты должно выполняться следующее требование. Требование 3. Сущность сессия при реализации разграничения доступа ко всем ресурсам (что задает режимы обработки категорированных данных) должна определяться одним и тем же способом. Казалось бы все ясно и очевидно. Но возьмите существующие системы защиты. Например, под одной учетной записью, в зависимости от категории прочитанного документа (что уже, как выше отмечалось, некорректно), можно обрабатывать как открытую, так и конфиденциальную информацию – вступают соответствующие сессии разграничения прав доступа к ресурсам. Однако, это касается только файловых объектов. При этом разграничения для ряда ресурсов, например, доступ к устройствам, задаются для учетной записи (т.е. в любой сессии права доступа пользователя к этим ресурсам одинаковы). Корректность реализации разграничительной политики доступа к ресурсам во многом связана с реализацией Требования 1, состоящего в том, что обработка информации между сессиями различной категории должна быть полностью изолированной. А это напрямую связано со способом задания сущности сессия. Очевидно, что, так как мы говорим о контроле доступа к ресурсам, то в общем случае без включения каких-либо дополнительных категорий, мы имеем три сущности для определения сессии: учетная запись пользователя, процесс (имя процесса), ресурс (категория объекта). Категорией объекта сущность сессия назначать нельзя (вступаем в противоречие с Требованием 1 – сессия должна задаваться до прочтения объекта какой-либо категории), остаются сущности учетная запись пользователя или процесс (имя процесса). Альтернативным решением является включение каким-либо образом дополнительной сущности, определяющей сессию. Включение в схему контроля доступа к ресурсам дополнительной сущности сессия При реализации данного способа решение может состоять в следующем. Вводится некий дополнительный субъект выбор сессии, пусть это программа, управление которой выносится в виде меню на рабочий стол. При входе пользователя в систему (после идентификации и аутентификации) автоматически запускается сессия выбор сессии (соответствующая программа) – пользователю разрешается доступ только к объекту выбора сессии (предлагается выбрать сессию для работы, ко всем иным ресурсам, в том числе и возможность запуска любого иного приложения, доступ пользователя запрещен). Объектом доступа здесь служат настройки механизмов контроля доступа к ресурсам, которые должны быть загружены в результате выбора соответствующей сессии. После выбора сессии вступают в силу разграничения для выбранной пользователем сессии (в общем случае, совокупность разграничений для сущностей пользователь и сессия) – пользователь может работать в данной сессии. Переход от сессии к сессии (изменение сессии) осуществляется аналогично и поддерживается необходимыми для корректной реализации разграничительной политики доступа к ресурсам мерами, в частности, осуществляется очистка буфера обмена, освобождаемой оперативной памяти, принудительно завершаются приложения, запущенные в предыдущей сессии и т.д. Естественно, что в части обеспечения корректности решения рассматриваемой задачи выдвигается ряд дополнительных требований по реализации разграничительной политики доступа к ресурсам, в частности, буфер обмена, файловые объекты, не разделяемые между пользователями: временные файлы, корзина и т.д., и другие ресурсы, в том числе, системные (исполняемые файлы, объекты реестра ОС и т.д.), устройства, сетевые ресурсы уже должны разделяться между сессиями – субъектом доступа к ресурсам становится сущность сессия, которую выбирает (изменяет) пользователь перед началом обработки информации соответствующей категории. Данное решение позволяет корректно решить рассматриваемую задачу защиты в общем виде. При этом субъект доступа определяется парой сущностей сессия, пользователь (учетная запись), причем основу разграничительной политики составляет задание прав доступа к ресурсам и привилегий для сущности сессия (не для учетных записей пользователей). Данный способ практически не имеет недостатков, за исключением одного. Он требует радикального изменения всей концепции защиты, реализуемой в современных универсальных ОС, где в качестве субъекта доступа рассматривается сущность пользователь. Другими словами, чтобы его реализовать, необходимо забыть обо всех наработках и реализованных в современных универсальных ОС решениях и создать всю защиту заново, совершенно на иных принципах. По нашему мнению, если подобное, корректно реализованное средство защиты и может появиться на рынке, то не скоро. Ведь это надо переделать все механизмы защиты, заточив их под новые принципы контроля доступа. С точки зрения реализации сессионной обработки данных различных категорий конфиденциальности, возникает вопрос, а можно ли реализовать режим одновременной работы пользователя в нескольких сессиях (т.е. без обязательного завершения предыдущей сессии перед выбором последующей сессии). Теоретически подобная возможность существует и состоит она в следующем. Будем отождествлять сессию с сущностью процесс. При этом для каждой сессии разрешим запускать определенный набор процессов (в любом случае замкнутость программной среды реализуется для субъекта доступа сессия), а при запуске процесса позволим пользователю выбирать сессию, в которой запускается данный процесс. При этом в системе одновременно может быть одним пользователем запущено несколько процессов в разных сессиях. Не будем останавливаться на анализе вопросов обеспечения корректности данного решения (очевидно, что технических проблем здесь хватает), лишь отметим, что это существенное усложнение итак весьма непростой задачи для практической реализации. Использование для задания сессии сущности пользователь (учетная запись) Рассмотренный выше способ решения задачи, при всей своей привлекательности и теоретической обоснованности, весьма сложен для практической реализации (по крайней мере, средства защиты, корректно реализующие данный способ, на наш взгляд, на сегодняшний день отсутствуют, и их создание потребует времени), а задачу противодействия внутренним ИТ-угрозам необходимо решать уже сегодня. Попытаемся максимально облегчить задачу реализации сессионного контроля доступа к ресурсам (переведем наши теоретические исследования в более практическую плоскость), памятуя о том, что вся разграничительная политика доступа к ресурсам в современных универсальных ОС реализуется для субъекта доступа пользователь (учетная запись), причем, как в части задания правил доступа к ресурсам, так и в части задания привилегий, т.е. попытаемся максимально использовать существующие на сегодняшний день наработки, применительно к решению рассматриваемой задачи защиты информации – противодействие внутренним ИТ-угрозам. С учетом того, что вся разграничительная политика доступа к ресурсам, включая задание привилегий, в современных системах реализуется для субъекта доступа пользователь (учетная запись), а основу сессионного контроля доступа к ресурсам составляет задание разграничительной политики доступа для субъекта доступа сессия, имеет смысл попытаться использовать для задания сессии сущности пользователь (учетная запись). При реализации данного способа решение может состоять в следующем. Итак, сессия должна определяться учетной записью. Введем понятие категории учетной записи, соответственно данные определенной категории могут обрабатываться только под учетной записью соответствующей категории. Пользователь для обработки данных соответствующей категории должен войти в систему под этой учетной записью. Очевидно, что данное решение позволяет реализовать разграничительную политику для учетных записей при обработке категорированной информации, т.е. относительно простое решение рассматриваемой задачи существует!. Заметим, что при этом реализуются все требования, сформулированные выше, в частности, может быть обеспечена изолированная обработка данных различных категорий (по средством реализации изолированной обработки данных для различных учетных записей), а сессия выбирается пользователем до получения доступа к данным (до прохождения процедуры идентификации доступ к какому-либо ресурсу невозможен). Для работы в сессии также могут устанавливаться привилегии, назначаемые при данном решении учетным записям. Возможность решения задачи в общем виде также обусловливается и тем, что разграничения могут быть реализованы для субъекта сессия, пользователь. Для этого для каждого пользователя должны быть созданы собственные учетные записи для обработки данных различных категорий. Очевидно, что одним из важных свойств системы защиты является ее минимальное влияние на удобство работы пользователя. Недостатком рассмотренного выше способа решения задачи является то, что, во-первых, для изменения сессии необходима смена учетной записи, во-вторых, пользователь не может работать одновременно в двух сессиях. Однако здесь нам приходит на помощь возможность обработки данных в многопользовательском режиме, предоставляемая современными универсальными ОС. Например, современные ОС семейства Windows, предоставляют возможность пользователю запустить процесс с правами другого пользователя (под другой учетной записью) без перезагрузки. Это реализуется с использованием утилиты runas. Начиная с Windows XP, данная опция вынесена в интерфейс (запуск процесса с правами другого пользователя можно осуществить из проводника, выбрав ее для исполняемого файла по правой кнопки мыши). Таким образом, одновременно (на рабочем столе) пользователем могут быть запущены приложения под различными учетными записями (никакой перезагрузки компьютера при этом не требуется). Сразу отметим, что не следует заблуждаться относительно того, что задача противодействия внутренним ИТ-угрозам сколько-нибудь корректно может быть решена механизмами защиты современных универсальных ОС – они для этого не предназначены. Рассматривая возможность задания сущности сессия учетной записью, мы лишь говорили о способе, позволяющем максимально использовать существующие наработки, не более того! Чтобы решить задачу корректно, необходим весьма внушительный список дополнительных механизмов защиты. Теперь несколько слов о корректности решения задачи. Требования к корректности при данном способе задания сессии определяются требованием к реализации изолированной обработки данных различной категории конфиденциальности – в данном случае – к изолированной обработке данных одним и тем же пользователем под различными учетными записями. Акцентируем внимание читателя лишь на некоторых проблемах (на примере архитектурных решений ОС Windows), без устранения которых в принципе невозможно говорить о каком-либо решении задачи противодействия внутренним ИТ-угрозам рассматриваемым способом:
Самым большим недостатком данного подхода к решению задачи (конечно, при условии корректной его реализации, за счет добавления в систему соответствующих механизмов защиты), на наш взгляд, является существенное усложнение задачи администрирования. Ведь данный подход предполагает создание для каждого пользователя нескольких учетных записей. Использование для задания сессии сущности процесс Если выше нами рассматривались альтернативные решения в общем виде, то данное решение частное. Частность данного решения обусловливается тем, что сессия определяется сущностью процесс или полнопутевым именем процесса. Т.е., другими словами, категорируется некий информационные сервис (например, работа с сетью Интернет разрешается только в открытой сессии). Запуск категорированного процесса означает запуск категорированного информационного сервиса (приложения) с соответствующей ему разграничительной политикой доступа к ресурсам. При реализации данного способа решение может состоять в следующем. Разграничение прав доступа устанавливается для процессов (приложений), характеризующих категорируемый информационный сервис, например, для процессов сетевых служб. Т.е. именно процесс выступает в качестве субъекта доступа, следовательно, для всех пользователей разграничения при работе с этим процессом совпадут. Для получения доступа к категорированному информационному сервису пользователь должен запустить процесс, для которого заданы соответствующие права доступа к ресурсам (по сути, изменить сессию) – все запросы пользователя к ресурсам, производимые данным процессом (например, к файловым объектам, к объектам реестра ОС, к сетевым ресурсам – хостам, и т.д.) будут осуществляться в рамках прав доступа к ресурсам, заданных для процесса. Не смотря на свою частность (один и тот же информационный сервис – процесс, может использоваться только для обработки данных одной категории), такое решение весьма эффективно в некоторых конкретных приложениях, например, если с компьютера, на котором обрабатывается конфиденциальная информация, пользователям следует разрешить доступ в сеть Интернет, при этом предотвратить возможность передачи конфиденциальных данных пользователями в сеть. К кажущимся недостаткам данного способа можно отнести то, что для его реализации (как и в первом рассматриваемом случае) необходимо коренным образом изменить принципы реализации разграничительной политики доступа к ресурсам, используемые в современных универсальных ОС, т.к. здесь субъектом доступа выступает сущность процесс, а не сущность пользователь (учетная запись). Однако если речь заходит о корпоративных приложениях, то этого все равно будет не избежать, т.к. существует еще одна, не менее актуальная задача защиты информации – противодействие внешним ИТ-угрозам. Основу же противодействия внешним ИТ-угрозам составляет реализация разграничительной политики доступа к ресурсам для субъекта процесс, т.к. применительно к этой задаче, уже не пользователь, а именно процесс (приложение) несет в себе угрозу НСД к информации. Комплексная же система защиты информации должна в равной степени обеспечивать противодействие как внутренним, так и внешним ИТ-угрозам (смешно будет, если, защищая корпоративную сеть, про одну из этих доминирующих групп угроз мы забудем). Таким образом, рассматривая возможность практического использования данного способа, подразумеваем, что средство защиты, ориентированное на использование в корпоративных приложениях, априори должно предоставлять такой сервис защиты информации, как разграничение прав доступа к ресурсам для субъекта процесс. В этих предположениях (заметим, мы говорим об эффективных средствах защиты информации), реализация данного способа не требует сколько-нибудь серьезной модернизации разграничительной политики доступа к ресурсам, обеспечиваемой средством защиты информации. Не лишним будет уточнить, что при реализации данного способа также должно быть предусмотрено ряд технических мер, направленных на обеспечение корректности решения, в частности, замкнутость программной среды должна устанавливаться для субъекта доступа процесс, между соответствующими процессами должен разграничиваться буфер обмена и др. Это обусловливается тем, что в сессиях различных категорий обработка информации осуществляется под одной учетной записью (одним пользователем). Важнейший вывод, который мы можем сделать, исследовав вопросы корректности реализации сессионного контроля доступа к ресурсам, состоит в том, что какой способ задания сущности сессия не реализуй, выполнение Требования 1, состоящего в том, что обработка информации между сессиями различной категории должна быть полностью изолированной, требует реализации в средстве защиты от инсайдеров достаточно внушительного комплекса механизмов защиты, без которых о какой-либо эффективности средства защиты (а значит, и в принципе о защите) говорить вообще не приходится! В порядке замечания отметим, что на рынке средств защиты сегодня представлено достаточно много решений. Все они предполагают реализацию разграничительной политики доступа к объектам для учетных записей. Но вот как их применить для противодействия инсайдерским атакам, ведь большинство из них не реализуют возможности полной изоляции режимов обработки на компьютере данных различных категорий конфиденциальности. Как следствие, подобные средства становятся полностью бесполезными для использования в рассматриваемых приложениях. Правда, отметим, что потребитель должен это еще увидеть, во всем этом разобраться, т.к., как ни странно, именно для решения актуальной задачи противодействия инсайдерам некоторые из этих средств защиты и позиционируются их поставщиками. Задачи криптографической защиты конфиденциальной информации В отличие от механизмов защиты от НСД, призванных противодействовать хищению информации, несанкционированной модификации данных и системных ресурсов, механизмы криптографической защиты призваны решать задачу раскрытию похищенной информации. Другими словами, где не могут в полном объеме решить задачу механизмы защиты от НСД, вступают в силу механизмы криптографической защиты. Очевидно, что защита от НСД и криптографическая защита – это не альтернативные, а дополняющие друг друга решения, средство же защиты должно быть комплексным – содержать и те, и другие механизмы. Честно говоря, очень странное впечатление оставляют средства защиты, реализующие либо только защиту от НСД, либо только криптографическую защиту. Отсутствие комплексной защиты, подчас, приводит к появлению, мягко говоря, удивительных решений. Вот простой пример. В продаже начали появляться средства защиты от НСД, реализующие функцию, так называемого, теневого копирования. Проще говоря, данные, сохраняемые пользователем на отчуждаемом накопителе (например, Flash-устройство), автоматически где-то сохраняются еще (например, в зарезервированной для этих целей области жесткого диска), якобы в целях последующего контроля действий пользователя. Не будем говорить о таких мелочах, что собственно возможность подобного контроля весьма сомнительна, т.к. пользователь может преобразовать данные перед записью на накопитель (например, заархивирует с паролем), что сделает саму процедуру контроля бессмысленной, не здесь следует говорить вообще об абсурдности подобного решения. Если пользователю разрешается сохранять любые данные на накопителе, о каком контроле речь, если только определенные – мы получаем задачу защиты от инсайдеров при обработке категорированной информации в своей классической постановке, решаемую реализацией различных режимов обработки данных различных категорий конфиденциальности (пользователю должна разрешаться запись на накопитель только данных соответствующей категории). Если существует возможность сохранять на накопителе только открытую информацию, что контролировать? Если вам необходимо разрешить запись на отчуждаемый накопитель конфиденциальной информации, которым можно воспользоваться для печати данных напрямую (без использования вычислительного средства) – остается единственно возможное решение – шифрование данных, сохраняемых на отчуждаемый накопитель (иначе надо ставить часового рядом с каждым принтером). Если вы обеспокоены тем, что внешний накопитель может быть вынесен за территорию предприятия (а любые организационные меры, призванные противодействовать этой возможности, весьма сомнительны), необходима реализация соответствующей ключевой политики, не позволяющей пользователю расшифровать данные при наличии своего ключа шифрования, иначе, как только на своем рабочем месте (на определенном компьютере). Вот вырисовывается политика безопасности, как видим, использование механизмов контроля она не предполагает, да и откуда им взяться при решении задачи защиты информации в корпоративных приложениях? Этот пример позволяет перейти и к формированию требований к реализации механизмов криптографической защиты информации, используемых в корпоративных приложениях. Сегодня наиболее развиты средства, позволяющие создавать, так называемый, защищенный диск, на который пользователь может сохранять конфиденциальные данные в зашифрованном виде. Опять же вся защита здесь основана на полном доверии к пользователю – именно пользователь выбирает, в каком виде ему хранить защищаемую информацию – никакого принуждения со стороны администратора. Возможно, что это решение не так и плохо для личного использования, однако, очевидно, что подобные решения не должны использоваться в корпоративных приложениях – здесь совсем иные требования к защите, именно санкционированный пользователь в данных приложениях и несет в себе основную угрозу хищения конфиденциальных данных, что диктует необходимость реализации совсем иных подходов к построению защиты. Сформулируем основополагающие принципы криптографической защиты данных в корпоративных приложениях. Принцип 1. Объектами криптографической защиты должны являться объекты любого уровня иерархии (диск, папка (каталог, подкаталог), файл) на жестком диске и на внешних накопителях, причем как на локальных, так и на разделенных в сети. При этом средством защиты должна предоставляться возможность задания любого набора объектов (например, несколько каталогов на выбор, включая разделенные в сети) в качестве объектов криптографической защиты. Принцип 2. Ключ шифрования должен создаваться только администратором и предоставляться им пользователю. Ключ шифрования, предоставляемый пользователю, должен обеспечивать возмость расширования данных только на конкретном компьютере (возможно, только при условии нахождении данного компьютера в составе ЛВС предприятия – сетевая ключевая политика). Наличие у пользователя носителя с данными, ключа шифрования, средства криптографической защиты не должно позволять расшифровать эти данные, иначе, как на своем рабочем месте. Принцип 3. Средство защиты должно обеспечивать возможность задания различных ключей шифрования для различных защищаемых объектов (в том числе и на одном компьютере) – в пределе, для каждого объекта свой ключ шифрования, при этом ключ шифрования никоим образом не должен генерироваться на основе идентификационных данных (идентификатор и пароль) пользователей. Когда же мы начинаем говорить о необходимости криптографической защиты канала связи, то должны понимать, что принципиальны отличия и при построении VPN для корпоративных приложений и личного использования. Корпоративная VPN – это наложенная на сеть общего пользования сетевая инфраструктура, ограниченная рамками корпорации. Подобную инфраструктуру в общем случае составляют локальные вычислительные средства, объединяемые в корпоративную локальную сеть, корпоративные локальные сети, объединяются в единое коммуникационное пространство, к которому, кроме того, подключаются удаленные и мобильные пользователи. Хранение и обработка в рамках виртуальной (основанной на использовании каналов связи общего пользования) сети корпоративной информации требует ее защиты. При построении VPN для корпоративных приложений (где одной из наиболее актуальных задач защиты является защита от инсайдерских атак), сразу следует задумываться о необходимости работы пользователя под принуждением и полным контролем со стороны администратора безопасности – именно администратор должен формировать ключи шифрования, обеспечивать возможность взаимодействия пользователей по сети только с определенным набором компьютеров и пользователей и т.д. Ключ шифрования либо вообще не должен быть доступен пользователю, либо он не должен позволять пользователю расшифровывать данные, которые могут быть им перехвачены в сети. Заметим, что среди представленных на рынке средств построения VPN, для использования в корпоративных приложениях, на самом деле, пригодны единицы. Подытоживая все сказанное, в заключение, можем сделать два важных вывода: Вывод 1. Эффективное противодействие внутренним ИТ-угрозам (в частности, инсайдерским атакам) может быть обеспечено только средством защиты, реализующим определенные требования, как в части достаточности набора механизмов защиты для корпоративных приложений, так и в части корректности их реализации. Вывод 2. Эффективное противодействие внутренним ИТ-угрозам (в частности, инсайдерским атакам) может быть обеспечено только средством защиты, решающим задачу защиты в комплексе, содержащем в своем составе необходимый и достаточный набор механизмов защиты от НСД и механизмов криптографической защиты. Вывод 3. Современные универсальные ОС даже гипотетически не могут обеспечить эффективное противодействие внутренним ИТ-угрозам (в частности, инсайдерским атакам), встроенные в них механизмы защиты для решения этих задач просто не приспособлены. Это обусловливает необходимость применения в корпоративных приложениях средств добавочной защиты информации. Часть 1 Читайте далее:  Комментарий к security 50 04 - 10 февраля 2008 года Созидающая волоконная оптика 08 - 09 марта 2008 года 14 - 20 апреля 2008 года ,рынок it, 28 - 30 апреля 2008 года ,рынок безопасности, 01. 04. 2008 05 - 11 мая 2008 года ,рынок безопасности, 12 - 18 мая 2008 года ,рынок it, 26 - 31 мая 2008 года ,рынок it, Организация строительно-монтажных, пусконаладочных работ и ввода в эксплуатацию интегрированных сист Наш опыт прокладки кабелей Заземление в системах промышленной автоматизации ,часть 2, Способы устранения искажений видеосигнала в линиях связи Как бороться с периодическим проявлением дефектов в системах безопасности
|
||||||||||||||||||||||||
