Основное назначение добавочных средств защиты информации

Основное назначение добавочных средств защиты информации

А.Ю.Щеглов, д.т.н, проф.

ЗАО "НПП "Информационные технологии в бизнесе"

www.npp-itb.spb.ru

     Вместо введения.
Обратимся к одному любопытному исследованию, опубликованному на сайте www.itsec.ru:

• (Новость от 18.10.2006). Российский рынок средств защиты информации сегодня развивается довольно динамично. При этом в нашей стране отмечается значительное ежегодное увеличение количества зарегистрированных преступлений в сфере компьютерной информации. Следует отметить, что свыше 99% правонарушений совершается умышленно. Несмотря на то, что проблема информационной безопасности с каждым годом становится все острее, некоторые промежуточные результаты исследования "Средства защиты информации от несанкционированного доступа", проводимого журналом "Информационная безопасность/Information Security" (компания "Гротек") носят парадоксальный характер. Большая часть опрошенных (39,8%) считают, что отечественные компании и организации весьма неохотно идут на увеличение расходов на информационную безопасность (см. диаграмму, рис.1). Для сравнения: в большинстве зарубежных компаний, затраты на информационную безопасность составляют в среднем около 15% от бюджета информационных технологий компаний.
  

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

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

Преимущества использования сертифицированной ОС:

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

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

В порядке замечания отметим, что тезис "отсутствие необходимости установки дополнительных сертифицированных "наложенных" средств защиты информации…" даже по формальным признакам в части "выполнение требований нормативных документов" не совсем корректен. Приведем лишь несколько примеров невыполнения формальных требований, для чего обратимся к нормативному документу: "Гостехкомиссия России. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации", используемому при аттестации объекта информатизации. Рассмотрим и проанализируем выполнимость лишь нескольких требований к АС класса защищенности 1Г (защита конфиденциальной информации):

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

Другой пример требований:

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

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

Еще пример: должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа.

Данное требование не может быть реализовано корректно по ряду причин. Например, это наличие неразделяемых системой и приложениями объектов, например папка All Users, невозможность в полном объеме разграничить права доступа системных пользователей к системному диску. Сразу возникают вопросы работы с такими файловыми системами, как Fat, и т.д.

Если же обратиться к документу: "Гостехкомиссия России. Руководящий документ. Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от НСД к информации", в котором сформулированы требования к корректности реализации разграничительной политики доступа к ресурсам, то увидим еще больше несоответствий.

Наверное, уже достаточно, в конце концов, работа посвящена рассмотрению иных вопросов.

Продолжим. Для этого вновь обратимся к сайту www.itsec.ru, где опубликовано следующее сообщение:

• (Новость от 01.02.2006) под названием "ИТ-безопасность: никто не готов к новым угрозам". Компания Ernst&Young провела ежегодный глобальный опрос ИТ-руководителей о проблемах информационной безопасности. Как оказалось, пропасть между угрозами ИТ-безопасности и тем, что делается для защиты от них, стала еще шире. Компания Ernst&Young выпустила очередную, восьмую, версию своего ежегодного отчета "Global Information Security Survey 2005". В опросе приняли участие высшие исполнительные лица более 1,3 тыс. коммерческих и государственных организаций в 55 странах мира, включая Россию. Основную массу респондентов составили директора информационных служб (CIO) и отделов ИТ-безопасности (CSO). Наиболее общим и, пожалуй, самым значимым выводом из этого исследования явилось то, что пропасть между угрозами ИТ-безопасности и тем, что делается для защиты от них, стала еще шире. Другими словами, риски, вызванные постоянным развитием бизнеса во всем мире, эволюционируют так быстро, что специалисты по ИТ-безопасности не успевает адекватно отреагировать на них. Эксперты компании Ernst&Young посчитали эту тенденцию настолько важной, что даже включили слова "Отчет о расширяющейся пропасти" ("Report on Widening Gap") в название своего исследования.
  

Очевидно, что со временем неминуемо отношение к информационной безопасности изменится. Тогда остро встанет вопрос, что делать? А готовы ли мы будем ответить на этот вопрос?

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

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


Начнем сначала.

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

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

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

Важнейшими же условиями использования средств защиты в данных приложениях является следующее:

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

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

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

• (Новость от 24.07.2006). Грэхем Ингрэм, главный управляющий австралийского подразделения Группы оперативного реагирования на чрезвычайные ситуации в компьютерной области (AusCERT) утверждает, что распространённые антивирусные приложения блокируют лишь около 20 процентов недавно появившихся вредоносных программ. При этом популярные антивирусы пропускают до 80 процентов новых троянов, шпионов и других вредоносных программ. Это означает, что в восьми из десяти случаев недавно появившийся вирус может проникнуть на компьютер пользователя".
  

Однако не стоит критически относиться к подобным средствам. Без всякого сомнения, для рассматриваемых приложений они необходимы. Здесь ведь встает вопрос: либо простые средства, либо никакие? Так уж лучше как-то, чем никак!

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

Важнейшими условиями использования средств защиты в данных приложениях является следующее:

• В данных приложениях априори присутствует конфиденциальная информация, требующая защиты;
  
• Критичным является не только факт хищения обрабатываемой информации, но и возможность ее несанкционированной модификации, либо уничтожения. Критичным в этих приложениях также становится вывод из строя системных средств на продолжительное время, т.е. важнейшими объектами защиты становятся системные ресурсы;
  
• Отсутствие квалификации пользователя в вопросах обеспечения информационной безопасности, да и нежелание заниматься этими вопросами (защищать требуется не его личную информацию) и? вместе с тем, наличие администратора безопасности, основной служебной обязанностью которого является защита информации (т.е. именно для решения этой задачи он и принят на работу, он априори должен обладать высокой квалификацией, т.к. в противном случае о какой-либо эффективной защите и говорить не приходится);
  
• Все задачи администрирования средств защиты должны решаться непосредственно администратором (кстати говоря, это одно из требований нормативных документов);
  
• Априорное недоверие к пользователю - пользователь обрабатывает не собственную, а корпоративную, либо иную конфиденциальную информацию, как следствие, должен рассматриваться в качестве потенциального злоумышленника (в последнее время даже появилось такое понятие, как инсайдер, а внутренняя ИТ-угроза - угроза хищения информации санкционированным пользователем - некоторыми потребителями и производителями средств защиты позиционируется чуть ли не как доминирующая, что не лишено оснований). Это, в том числе, обусловливает и появление актуальности решения задач удаленного контроля действий пользователей на вычислительных средствах предприятия;
  
• Обработка конфиденциальной информации в основном осуществляется в корпоративной сети, причем не всегда в локальной - это обусловливает невозможность эффективного решения задачи администрирования безопасности без соответствующего инструментария (АРМа администратора в сети).
  

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

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

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

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

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

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

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

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

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

• Должен осуществляться контроль доступа субъектов к защищаемым ресурсам в соответствии с матрицей доступа.
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Субъект имеет право доступа "Чт" к объекту в том случае, если полномочия субъекта ниже, чем категория объекта;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Рассмотрим, как легко настраивать сложную разграничительную политику доступа к файловым объектам (локальным и разделенным в сети, на жестком диске и на внешних накопителях) с использованием данного интерфейса. Так, из рис.2 видим, что лишь несколькими записями мы разрешили пользователю User 1 только запись и чтение в каталог D:\Doc (заметим, что разрешить доступ одной записью можно к файловому объекту любого уровня иерархии - диск, каталог, подкаталог, файл), а выполнение программ только из каталогов C:\Windows и C:\Program Files, одновременно запретив туда запись, - реализовали замкнутую программную среду.

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

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

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

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

Вот лишь небольшой комментарий к сказанному (опять же новость с сайта www.itsec.ru):

• (Новость от 02.03.2007) В операционной системе Windows Vista, поступившей в широкую продажу 30 января, обнаружена одна из первых уязвимостей. Дыру в системе User Account Control обнаружили специалисты компании eEye. Из соображений безопасности подробная информация об уязвимости не разглашается. Известно лишь, что задействовать ее может локальный пользователь с целью повышения уровня собственных привилегий в системе. Впрочем, удаленный злоумышленник также может воспользоваться брешью в том случае, если уже имеет доступ к компьютеру. Компания eEye проинформировала корпорацию Microsoft о дыре еще 19 января, однако патча пока выпущено не было…
  

Что же имеем. Уже 2 месяца из 12 ОС содержит уязвимость, или незащищена, о какой безопасности можно говорить, что будет дальше? Что же остается делать - только одно - использовать добавочные средства защиты. Вот и вторая ключевая задача добавочных средств защиты - повысить эксплуатационную безопасность системного средства - современной универсальной ОС. Подобное позиционирование задачи защиты очень важно, т.к. чтобы решать задачу, нужно понимать, в чем она состоит. А чтобы ответить на следующий вопрос, как решать данную задачу, каковы должны быть требования к добавочному средству защиты информации с этих позиций, необходимо обратиться к статистике обнаруженных уязвимостей. При их обобщении и системном анализе, данные задачи и соответствующие требования к средству добавочной защиты начинают "вырисовываться". Однако это вопрос самостоятельно исследования, и его рассмотрению мы посвятим отдельную работу.