Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

Существуют три основных аспекта ИБ:

доступность;конфиденциальность;целостность.

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

Размер ущерба удобно оценивать по трехуровневой шкале как низкий, умеренный или высокий ().

Рисунок 1. Шкала оценки ущерба при нарушении информационной безопасности

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

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

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

Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

Рисунок 2. Уровни информационной безопасности

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

Рисунок 3. Базовые требования безопасности к информации и ИС.

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

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

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

Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

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

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

Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

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

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

Рисунок 6. Обеспечение информационной безопасности. Процессный подход.

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

Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

Владимир Антонович Галатенко (доктор физико-математических наук)
Информационный бюллетень JET INFO

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

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

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

Регуляторы безопасности для минимального уровня ИБ

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

Рисунок 4. Регуляторы безопасности по уровням ИБ

Оценка рисков: политика и процедуры. Разработка, распространение, периодический пересмотр и изменение:

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

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

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



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

Рисунок 5. Поддержание необходимого уровня безопасности

Лазерный диск с нулевым треком как средство защиты от копирования

, журнал CODE

Задумывались ли вы, почему нумерация треков лазерных дисков начинается с единицы, а не с нуля? Ведь говорят, чтобы отличить программиста от простого смертного достаточно дать ему команду "рассчитайсь!". Нормальный человек скажет "первый" (если он действительно первый) и будет по-своему прав. Программист же сначала уточнит в какой системе исчисления вести расчет (в двоичной, восьмеричной, шестнадцатеричной…) и затем, сделав шаг вперед, гордо скажет "нулевой". "Так ведь лазерные диски изначально разрабатывались для пользователей! – ответите вы. – А пользователи более привычны к натуральной, а не позиционной системе исчисления и потому первый трек должен быть именно первым, но никак не нулевым".

И все же, несмотря на всю убедительность своих доводов, вы будете не правы. Отсчет треков всякого диска начинается не с единицы, но с нуля. Да, нулевой номер зарезервирован за служебным треком (вводной областью диска) и его содержимое недоступно на интерфейсном уровне, но это ничего не меняет! Поле TNO (Track Number) Q-подканала Lead-In области диска равно нулю, следовательно, с точки зрения привода всякий диск начинается с трека номер ноль. Электронная начинка привода читает и адресует нулевой трек точно так же, как и любой другой трек диска, сохраняя тем самым прозрачность и упорядоченность принятой системы нумерации. С точки зрения системных программистов, разрабатывающих микропрограммные прошивки, отсчет треков всегда начинается с нуля. С точки же зрения пользователей привода – с единицы. Одним словом, и волки сыты и овцы целы!

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

Если помимо внесения подложных данных в TOC мы еще и скорректируем содержимое Q-канала подкода, забив поле TNO нулями, то с точки зрения привода такой трек будет неотличим от вводной области диска и попытка его посекторного чтения будет обречена на провал (хотя некоторые приводы и не такое читают).
Субканальные данные нулевого трека теоретически должны быть доступны для чтения командами SEEK/READ SUBCHANNELL, но никаких гарантий на счет этого у нас нет, поскольку наличие двух подряд идущих Lead-In областей сильно нервирует привод, и его реакция становится совершенно непредсказуемой. Отказ от восстановления субканальных данных мало что меняет. Одно лишь наличие нулевого point'a в TOC'е – событие вполне неординарное и взаимно противоречивое.

Большинство приводов просто свихнутся и откажутся обрабатывать такой диск, совершенно непредсказуемым образом осуществляя чтение его оглавления. В частности, NEC при выполнении команды READ TOC возвращает ошибку, ASUS воспринимает нулевой трек как индикатор завершения TOC'а, а TEAC, столкнувшись с нулевым треком, начинает очень сильно нервничать и вместо атрибутов всех последующих треков выплевывает содержимое своих внутренних буферов вместе с мусором, оставшимся от TOC'а предыдущего диска. Короче говоря, нулевой трек делает лазерный диск практически полностью нечитабельным.

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

Весь фокус в том, что наличие нулевого трека на диске никак не препятствует чтению субканальных данных спиральной дорожки, но подавляющее большинство копировщиков (включая Алкоголь и Clone CD) скорее зависнут, чем скопируют такой диск! Таким образом, алгоритм работы защитного механизма сводится к "ручному" чтению TOC'а командами SEEK/READ SUBCHANNEL с последующей проверкой его содержимого на предмет наличия нулевого трека.

И хотя ключевой диск не может содержать никаких других данных, кроме собственно самого проверяемого TOC'а, – это ли беда? В каком-то смысле это даже достоинство.


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

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

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


рис. 1). Вызов "Диспетчера программ" с последующим умерщвлением разбушевавшегося процесса не решает проблемы, т.к. лоток диска остается заблокированным и приходится прибегать к помощи утилиты CD.lock.exe для уменьшения счетчика блокировок на единицу.

This Web server launched on February 24, 1997 Copyright © 1997-2000 CIT, © 2001-2009

Альтернативы

В качестве альтернатив помещению сервисов в CE мне видится только разнос сервисов по разным физическим машинам или виртуализация, т.е. организация на одном физическом сервере нескольких виртуальных посредством серверных решений компаний VMware, SWsoft и аналогов. В Linux существует хорошее средство виртуализации - vserver, позволяющее размещать на одном компьютере несколько систем, объединенных лишь общим ядром. Правда, оба эти метода связаны с большими накладными расходами, поэтому в ряде случаев более оправдано использовать chrooted environment, если нет возможности нарастить оборудование.

Автоматизация

Еще раз хотелось бы заострить внимание на автоматизации процесса: сисадмины, пишите скрипты! Не забывайте про китайский принцип "три года упорного труда - десять тысяч лет счастья" (c) Мао Цзе-дун.

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

В качестве конкретного примера приведу пример стартового скрипта для Apache в CE (продолжая начатую тему веб-сервера в CE): #!/bin/sh # start/stop/restart chrooted Apache web server # Den aka Diesel <diesel@sherdart.net>

PREFIX=/chroot/httpd APACHE_PREFIX=/usr MYSQL_SOCK=/var/run/mysql/mysql.sock

# если вы хотите использовать каталоги ~/public_html в CE, установите # HOMES_BIND=1 # и постоянно синхронизируйте $PREFIX/etc/passwd с основной системой

HOMES_BIND=0

httpd_start() { if [ -x $PREFIX/$APACHE_PREFIX/sbin/httpd ]; then echo "Starting Apache web server in the chroot environment..."

if [ HOMES_BIND = 1 ]; then mount --bind /home $PREFIX/home fi if [ -e $MYSQL_SOCK ]; then ln $MYSQL_SOCK $PREFIX$MYSQL_SOCK fi if ! `/usr/sbin/chroot $PREFIX $APACHE_PREFIX/sbin/httpd` ; then echo "ERROR" httpd_stop fi fi }

httpd_stop() { killall httpd if [ HOMES_BIND = 1 ]; then umount $PREFIX/home fi if [ -e $PREFIX/$MYSQL_SOCK ]; then rm -f $PREFIX/$MYSQL_SOCK fi }

httpd_restart() { httpd_stop sleep 1 httpd_start }

case "$1" in 'start') httpd_start ;; 'stop') httpd_stop ;; 'restart') httpd_restart ;; *) echo "usage $0 start|stop|restart" esac

Базовые принципы

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

Основные проблемы при создании chrooted среды создает именно тот факт, что приложение "не видит" никаких файлов за рамками своего корневого каталога. В общем - сильная сторона оказывается одновременно и слабой, как это часто бывает в этой жизни. Из этого обстоятельства вытекает тот факт, что если для нормальной работы программы нужны какие-то библиотеки и дополнительные файлы - их придется скопировать внутрь CE. Если с библиотеками вопрос в ряде случаев можно решить, статически слинковав искомое приложение и получить его в виде одного большого бинарного файла, то с остальными файлами этот трюк не пройдет. Для того, чтобы создать оптимальную изолированную "камеру" для сервиса, мы должны достаточно хорошо знать его внутреннее устройство, чтобы скопировать все нужное, не прихватив при этом в CE лишнего, т.к. жесткие диски у вас наверняка не бесконечного объема. Частично эту проблему помогают решить инструменты, входящие практически в любой современный дистрибутив Linux.

Что это такое?

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

Термин "chrooted environment" происходит от имени системного вызова chroot() и соответствующей утилиты chroot, которая производит запуск программы, имя которой передается ей в качестве аргумента, в таком окружении с измененным корневым каталогом, путь к которому также передается в качестве аргумента. Программа, запущенная в CE, ограничена в доступе к файловой системе его рамками. Во FreeBSD существует подобный подход к изоляции программ - jail (тюрьма), что более образно описывает ее назначение - целевое приложение оказывается в программной "тюрьме", из которой достаточно проблематично выбраться. Широко распространенным примером CE являются FTP-сервера, большинство из которых по умолчанию работают с chroot - клиент, зашедший на сервер, не может увидеть файлы выше каталога, назначенного администратором в качестве корневого.

Доступ до части основной файловой системы

Полная изоляция - это хорошо, но не всегда то, что надо. Пример из жизни: у пользователей на сервере есть свои веб-страницы, лежащие в ~/public_html, и адресуемые http://site/~user/. Как быть с ними, если веб-сервер в CE? Копировать пользовательские файлы - абсурд. Снова воспользоваться жесткими ссылками будет чрезвычайно неудобно при большом количестве файлов и, ко всему же, жесткие ссылки не работают для каталогов. Есть идея лучше: воспользоваться возможностью монтировать каталог в каталог (mount с опцией --bind). Т.е. мы просто при старте веб-сервера монтируем /home в /chroot/httpd/home, например, а при остановке - размонтируем. Однако здесь есть крупный подводный камень, из-за которого я и рекомендую все время размонтировать такие каталоги после остановки сервиса - на этапе настройки вы наверняка не с первого раза создадите работающее CE, и, возможно, будете несколько раз стирать /chroot/service - и не дай Бог в этот момент не отмонтировать оттуда каталоги - вы уже наверняка догадались, что произойдет в этом случае - нужные файлы отправятся прямиком в /dev/null.

Инструментарий

Вот они, наши основные помощники по помещению приложения в "тюрьму":

chroot - основная утилита, описанная выше, делает системный вызов chroot() chrootuid - функционально отличается от просто chroot лишь тем, что может еще и менять UID процесса посредствов setuid() - эта утилита может быть полезной, если вы хотите, чтобы сервис работал не от root, а его авторы не предусмотрели такой возможности (может отсутствовать в вашем дистрибутиве) ldd - выводит информацию о зависимостях от общедоступных (shared) библиотек strace - позволяет отслеживать системные вызовы и сигналы, чрезвычайно мощная утилита практический опыт - чем больше, тем лучше

Если помещенное в CE приложение не работает или работает не так, как нужно, то алгоритм отладки такой:

с помощью ldd выясняем, какие из библиотек требуются, и копируем их в CE (естественно, сохраняя структуру каталогов) внимательно смотрим вывод программы и лог-файлы - часто запускаемый сервис сам говорит, что ему не хватает для работы анализируем лог-файлы сервиса, лежащие уже внутри CE (если таковые имеются) запускаем программу через strace и сохраняем вывод STDOUT в файл для дальнейшего анализа: strace chroot /chroot/service /path/to/service 2> ./strace.log

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

Помимо уже упомянутых утилит, существуют и более продвинутые инструментальные решения по созданию CE, например - jailkit (работающий, кстати, не только на Linux, но и на FreeBSD, OpenBSD и MacOSX). Однако, по сути, этот пакет лишь делает за вас часть рутины, в любом случае пригодится знание того, как собрать CE руками.

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

Практический пример: Apache

Наверное, один из наиболее часто помещаемых в CE сервисов - веб-сервер Apache. Про это много написано и под разными углами, но я все же рискну повториться. Рассмотрим пошагово перенос в CE программной связки Apache 1.3.x + PHP 5 с учетом взаимодействия с СУБД MySQL (классический комплекс, именуемый в народе "LAMP" - Linux + Apache + MySQL + PHP). В примере предполагается, что мы имеем дело с дистрибутивной сборкой Apache в Slackware (для вашей системы файлы могут быть расположены немного по-другому, но принцип должен быть понятен).

Вот скрипт для автоматизированного создания CE: #!/bin/sh # create chrooted environment for Apache 1.3 + PHP 5 # Den aka Diesel <diesel@sherdart.net>

PREFIX=/chroot/httpd APACHE_PREFIX=/usr PHP_PREFIX=/usr APACHE_DATADIR=/var/www

# создаем структуру каталогов:

mkdir -p $PREFIX mkdir -p $PREFIX/dev mkdir -p $PREFIX/etc mkdir -p $PREFIX/lib mkdir -p $PREFIX/tmp mkdir -p $PREFIX/var/cache/proxy mkdir -p $PREFIX/var/run mkdir -p $PREFIX/$APACHE_PREFIX/bin mkdir -p $PREFIX/$APACHE_PREFIX/lib mkdir -p $PREFIX/$APACHE_PREFIX/sbin mkdir -p $PREFIX/$APACHE_PREFIX/libexec mkdir -p $PREFIX/var/log/apache mkdir -p $PREFIX/var/run/mysql mkdir -p $PREFIX/$PHP_PREFIX/lib/php mkdir -p $PREFIX/home

# выставляем 'sticky bit' на /tmp:

chmod 1777 $PREFIX/tmp

# создаем файл устройства /dev/null:

mknod $PREFIX/dev/null c 1 3 chmod 666 $PREFIX/dev/null chown root:sys $PREFIX/dev/null

# копируем конфигурационные файлы:

cat /etc/group|egrep "apache:|nobody:|nogroup:" > $PREFIX/etc/group cat /etc/passwd|egrep "apache:|nobody:" > $PREFIX/etc/passwd cat /etc/shadow|egrep "apache:|nobody:" > $PREFIX/etc/shadow chmod 640 $PREFIX/etc/shadow cp /etc/HOSTNAME $PREFIX/etc cp /etc/host.conf $PREFIX/etc cp /etc/hosts $PREFIX/etc cp /etc/nsswitch.conf $PREFIX/etc cp /etc/resolv.conf $PREFIX/etc cp /etc/localtime $PREFIX/etc cp -R /etc/apache $PREFIX/etc

# копируем данные и лог-файлы:

cp -R $APACHE_DATADIR $PREFIX`dirname $APACHE_DATADIR` cp -R /var/log/apache $PREFIX/var/log

Уязвимости CE

Как это ни прискорбно, наш мир далек от идеала, и программное обеспечение здесь не является исключением из правил. Из CE можно "выпрыгнуть", причем, иногда очень легко. Один из методов "побега" описан прямо в документации по chroot - цитирую: In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.

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

Итак, существует ряд проблем с безопасной работой в CE, однако существуют и контрмеры по их устранению. Одна из наиболее эффективных подпорок CE - это набор патчей на ядро под названием grsecurity. Эти патчи достойны настоящего параноика и позволяют достаточно туго затянуть гайки (вплоть до доведения системы до самого защищенного состояния - неработающего). Из интересующего нас в аспекте усиления CE можно отметить раздел 'Chroot jail restrictions', в котором:

запрет mount запрет двойных вызовов chroot() запрет использования pivot_root() (аналога chroot()) принудительная смена текущего каталога на "/" запрет установки suid и sgid флагов на файлы запрет fchdir() (иначе из CE можно сбежать через открытый файловый дескриптор, ведущий наружу) запрет создания файлов устройств запрет использования shared memory за границами CE запрет подключения к абстрактным Unix domain sockets запрет на управление процессами вне CE (чтобы из CE нельзя было убить внешний процесс либо еще как-то на него повлиять) запрет смены приоритета процессов вне CE (иначе возможна реализация DoS при выставлении минимального приоритета на другие работающие сервисы) запрет манипулирования sysctl записями запрет подключения модулей ядра, raw I/O операций, перезагрузки системы, смены системного времени, изменения файлов с иммунитетом и многое другое

Если вы подумаете: "а зачем такой концлагерь?" - я рискуя, окончательно разрушить вашу веру в устойчивость программного обеспечения, скажу, что почти каждый из пунктов перечисленного списка позволяет "сбежать" из CE. А вообще grsecurity содержит много интересного, рекомендую принять на вооружение. Единственный неприятный момент, связанный с этим набором патчей - некоторая инертность разработчика (порой выпуски свежих версий патчей задерживаются).

При упоминании grsecurity на ум сразу приходят патчи проекта Openwall (который уже вырос в дистрибутив Openwall GNU/*/Linux, ориентированный на усиление безопасности) - однако, они менее эффективны и не предоставляют возможности тонкой настройки параметров.

В качестве заключения

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

PS: автор благодарит за конструктивные замечания, высказанные при подготовке статьи.

Статья написана по материалам доклада на .

Взаимодействие с другими сервисами

Итак, допустим, что мы благополучно упрятали сервис в CE. Казалось бы - дело сделано, можно идти пить согревающие напитки с друзьями, но в душу закрадываются какие-то смутные подозрения о том, что это не конец. И они вовсе не беспочвенны. Типовой пример - те же самые Apache + PHP + MySQL.

Предположим, что Apache с PHP у нас загорают в "тюрьме" CE, а MySQL "остался на свободе". Но им же надо как-то взаимодействовать друг с другом! Поместить MySQL в тот же CE - не очень хорошее решение (лучше его отсадить в отдельный CE, исходя из народной мудрости, учащей раскладывать яйца по разным корзинкам). С другой стороны, нарушать целостность CE тоже не хочется - иначе какой тогда в нем смысл? В такой ситуации есть неплохое решение: настроить связь с MySQL через UNIX domain socket (по умолчанию они так и взаимодействуют) и сделать на него жесткую ссылку (hard link) в CE с Apache. Единственное ограничение - жесткие ссылки работают только внутри одного раздела диска, поэтому лучше хранить все CE на одном разделе. В этой связи возникает новая проблема - слежение за тем, чтобы этот раздел не переполнился в результате действий пользователей или раздувания логов и тем самым не заблокировалась работа сервера (если речь идет о корневом разделе основной системы). Одним из эффективных путей предотвращения таких ситуаций может стать использование файловых квот, однако это уже выходит за рамки данной статьи. Помимо этого, не забывайте о том, что файл существует до тех пор, пока существует хотя бы одна жесткая ссылка на него - поэтому рекомендую в выше рассмотренном примере с MySQL убивать при остановке MySQL все жесткие ссылки на mysql.sock, а при запуске - создавать заново.

Альтернативным подходом является использование TCP сокетов для межпроцессного взаимодействия. Выбор конкретного решения - дело каждого.

Зачем это нужно?

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

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

Кстати, некоторые сервисы изначально подразумевают запуск в CE - например, распространенный DNS-сервер BIND создатели рекомендуют эксплуатировать в CE (создание окружения для нормальной работы этого сервиса подробно описано в официальной документации на BIND), при этом сам демон совершает системный вызов chroot(), если ему указать в качестве аргумента расположение корневого каталога CE. Аналогичная ситуация с MySQL - в конфигурационном файле указывается расположение подготовленного окружения для сервиса, демон при запуске помимо смены UID/GID, также вызывает chroot(). Те сервисы, в которых не предусмотрена работа в CE "из коробки", можно запускать с помощью уже упоминавшейся утилиты chroot.

Журналирование

Аналогичным же образом поступаем и с журналированием событий через syslog - настраиваем его для работы через дополнительный сокет (опция -a для syslogd) или пробрасываем жесткую ссылку с /dev/log в CE. Тем самым мы получаем обычное журналирование согласно syslog.conf, как будто бы сервис и не находился в CE.

Защита домашнего компьютера

,

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

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

Несколько ремарок. Для зануд: я владею "великим и могучим" достаточно свободно (см. ), чтобы не использовать килограммами смайлики, и если где-то коверкаю слова - то не по незнанию, а подчёркивания для.

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

Для сторонников теории заговора: я не рекламирую ничьих продуктов/услуг и не получаю за это мзду. Высказываю своё личное мнение, рождённое опытом работы с названными продуктами.

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

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

Для затравки: за много лет не было ни единого случая, чтобы компьютер, "окученный" мною, подхватил заразу - ни мой личный - ни тех знакомых, которые просили меня об этой услуге. Более того, некоторые знакомые, "продавшиеся" другим халтурщикам, через какое-то время упрашивали меня прийти снова и сделать всё по-своему - у них либо "тормоза" страшные (а чего вы ждали от KAV?), либо зараза замучила.

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

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

Шаг второй. Для защиты от вирусов, рекламного, шпионского софта, и прочей требухи я использую антивирус . Почему-то у многих людей вопрос выбора антивируса вызывает что-то вроде религиозной истерики. Не хочу им уподобляться; скажу лишь, что меня Dr. Web устраивает как меньшими требованиями к системным ресурсам, так и большей управляемостью: я могу по своему хотению включать/отключать любые его компоненты. Кроме того, я считаю, что при корректной настройке и наличии актуальных вирусных баз любой антивирус покажет уровень защиты, сопоставимый с конкурирующими продуктами. Иными словами, если ручки не кривые и базы свеженькие, можете расслабиться.

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

Любой антивирус обеспечивает, как минимум, 3 инструмента: сканер, дисковый монитор, и монитор почтового трафика.

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

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


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

Почтовый монитор - резидентная программа, которая перехватывает почтовый трафик (протоколы POP3 и SMTP) и его анализирует всё на тот же предмет. Несколько раз он меня выручал - когда по почте приходили вирусы. Mail.ru декларирует, что вся почта, идущая через их сервер, проверяется антивирусом, но то ли базы у них несвежие, то ли ещё что, но вирусы они иногда пропускают.

В бета-версии Dr. Web 4.33 присутствует ещё один монитор: теперь уже HTTP-трафика. Он, подобно почтовому, анализирует HTTP-протокол, и вылавливает заразу ещё "в проводах" - до того, как она оформилась в виде файла и попыталась записаться на ваш диск; хотя эту попытку должен пресечь файловый монитор. Красивая идея. Полезно для любителей "понавигировать" во всемирной помойке.

Заботясь о безопасности, в наше время нельзя ограничиваться одним только антивирусом. Хороший современный брандмауэр - вот то, что нам нужно! Мне нравится . Кроме функций собственно файрволла, его дополнительные модули (плагины) выполняют полезные функции: вырезают рекламу с web-страниц, ограничивает доступ к указанным ресурсам, позволяет избирательно разрешить/запретить работу интерактивных элементов на сайтах: cookies, скриптов, Flash, Gif, всплывающих окон, и т.д.

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



Как я уже говорил, всем этим вполне может "рулить" сам компьютер.

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

Осуществляется выход в Интернет.

1.1. Дозвон до провайдера. В этот момент в память загружаются , "Spider Guard" (файловый монитор Dr. Web), "Spider Mail" (почтовый монитор Dr. Web), "Spider Gate" (монитор HTTP-трафика).

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

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

1.4. Разрыв соединения. Всё это хозяйство (четыре защитных компонента) "вываливается" из памяти с тем, чтобы не тормозить работу в дальнейшем.

В дисковод вставляется CD или DVD-диск. При этом "взлетает" файловый монитор - мимо него не проскочит ни одна дрянь, даже если ею забит весь диск. А так как вирусные базочки у нас свеженькие (помните автообновление в каждом сеансе связи?), мы заслуженно имеем моральное удовлетворение.

2.1. При извлечении диска из привода файловый монитор сам "вывалится" из памяти - и компьютер опять не тормозит нисколечко!

В USB-порт вставляется флеш-накопитель. Всё происходит точно так же, как и в пункте 2.

В дисковод 3.5 '' вставляется дискета. Вот уж это событие я не знаю, как отследить. Поэтому всем усерам на панели быстрого запуска делаю два значка - для запуска и остановки службы "SpIDer Guard for Windows NT" - файлового монитора. И предупреждаю их: "перед вставкой дискеты нажми вот эту пимпочку, а после изъятия - эту".


Остаётся надеяться на его здравое желание оставить компьютер здравым.

Итак, мы перекрыли все каналы поступления "заразы" извне, и при этом не напрягли усера (всё крутится само собой, прям как у Емели), и не затормозили работу его системы. Честь нам и хвала!

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

Во время установки Dr. Web следует указать выборочную установку (см. ). "Родной" планировщик не стОит устанавливать: мы и так воспользуемся планировщиком, только более функциональным.

После успешной установки Dr. Web необходимо изменить метод запуска службы "SpIDer Guard for Windows NT" на ручной, а также удалить из автозагрузки (при помощи "msconfig") "spiderml" и "spidergate". Нечего им делать в отсутствие соединения с инетом.

Точно также, после установки , переводим в режим ручного запуска службу "Outpost Firewall Service".

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

Не пугайтесь, вам не придётся писать скрипты для него. Я сделал это за вас. Вот, и пользуйтесь.

Единственное, что вам может понадобиться отредактировать в скрипте - это букву CD (DVD) дисковода, а также раскомментировать события "OnFlashInsert" и "OnFlashEject" и проверить правильность буквы USB-накопителя.

Если вы всё сделаете правильно, наградой вам будет надёжная защита и отсутствие тормозов в работе.

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

Модель вероятностного контроля доступа к ресурсам

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

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

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

Видим, что при реализации данной схемы вероятность «заражения» документа более высокой категории, например, O1 (P1) не изменяется в связи с тем, что на том же компьютере обрабатывается информация более низкой категории, например, Ok (Pk). При этом будем понимать, что режимы обработки информации различных категорий могут кардинально различаться (например, при обработке на одном компьютере открытой Оk и конфиденциальной информации О1, имеем:
Pk >> P1,
причем в зависимости от реализованных правил и организационных мер по обработке конфиденциальных данных это отношение может составлять сотни, тысячи и более раз, то есть именно во столько раз можно снизить вероятность «заражения» конфиденциальных данных макровирусами, хранящимися в открытых данных, для которых порою, Pk = 1).

Назначение механизма контроля доступа к ресурсам

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

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

Пусть S = {0, Чт, Зп} — множество прав доступа, где «0» обозначает отсутствие доступа субъекта к объекту, «Чт» — разрешение доступа для чтения объекта, «Зп» — разрешение доступа для записи в объект.

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

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

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

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

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

Соответствующая формализация правил доступа субъектов к объектам при этом, как правило, сводится к следующему:

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

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

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

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

Недостатки частного решения. Комплексный

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

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

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

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

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

Задачи антивирусной защиты в корпоративных приложениях

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

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

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

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

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

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

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

В заключение отметим, что средство

Защита информации в корпоративных приложениях. Частные решения

А. Щеглов, А. Оголюк

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

Все многообразие угроз компьютерной безопасности можно свести к двум большим группам: внутренние и внешние IT- угрозы.

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

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

В результате получаем следующую статистику уязвимости ОС Windows. В 2005 году в ОС Windows было выявлено 812 «дыр» (исследования US-CERT). Специалисты из McAfee отмечают, что из 124 «дыр», обнаруженных в Windows XP Professional на сайте Secunia (Security Provider), 29 так и остались не устраненными, что дало компании основание присвоить Windows статус критически опасной ОС. Действительно, наличие уязвимостей (или «дыр») в системе делает ее защиту просто бесполезной — что толку в том, сколько и каких механизмов защиты реализовано, если есть известный канал НСД к информации?

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

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

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

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

Агрегирование

После консолидации событий начинается процесс их агрегирования, т.е. группирования однотипных событий вместе, что позволяет получить на экране вместо 10000 повторяющихся строк "UDP-Scan" или "SQL_SSRP_StackBo" (краткое название атаки Slammer в системе RealSecure Network 10/100) всего лишь одну строчку, которая дополнена новым параметром "число событий" (см. Таблицу 3).

Таблица 3. Снижение объема информации, отображаемой на консоли

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

Консолидация событий

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

Таблица 2. Консолидация событий на примере системы RealSecure SiteProtector с установленным модулем Third Party Module

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

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

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

Корреляция

Получив сообщение о том, что, например, ваша сеть атакована червем Slammer многие администраторы приходят в ужас и лихорадочно начинают вспоминать, а пропатчили ли они свои узлы. А что если, даже самая серьезная атака (например, Slammer) не нанесет вам никакого вреда по той простой причине, что у вас нет серверов на базе MS SQL? А если они у вас есть, но вы их давно защитили? Аналогичная ситуация происходит и с другими атаками, которые отвлекают внимание администратора и требуют вмешательства. А что, если на них вообще не надо реагировать (как ни парадоксально это звучит)? Ведь не каждый хакер знает всю подноготную вашей сети, и, зачастую, он наугад пытается атаковать ваши ресурсы, что приводит к тому, что атака не только не нанесет вам никакого ущерба, но и в принципе не может быть применима к вашей сети. Например, относительно недавно выпущенный SMBdie страшен только Windows-узлам, да и то, только тем, на которых не был установлен соответствующий Service Pack. Unix-машины к нему неуязвимы. Так зачем же реагировать на появление сообщения об атаке SMBdie? Хорошо, если ваша сеть небольшого размера и вы помните, что и где у вас установлено. А если нет? Куда лучше, если сообщения, не несущие никакой угрозы, вообще бы не показывались у вас на консоли и не отвлекали бы вас от более важных дел. Механизм корреляции, т.е. поиск взаимосвязей между разнородными данными, как раз и решает эту проблему, снимая с администраторских плеч нагрузку проведения ручного анализа и сопоставления разрозненных данных.

Модуль корреляции в SIMS не только автоматизирует процесс сопоставления разнородных данных, но и сам проводит анализ воздействия атаки на ваши ресурсы. Это может происходить по-разному:

Локальная корреляция, осуществляемая непосредственно на защищаемом узле. В этом процессе участвует система обнаружения и предотвращения атак уровня узла (host-based ID&PS), которая либо отражает атаку, о чем оповещает администратора безопасности, либо нет. В последнем случае требуется вмешательство специалистов, которые инициируют процесс расследования инцидентов.
В данном случае, система обнаружения и предотвращения атак должна не только зафиксировать атаку, но и оценить ее воздействие на атакуемый узел. Корреляция со сведениями об операционной системе. Если Windows-атака направлена на Unix-узел, то ее можно игнорировать и не забивать себе голову проблемой реагирования на такие нарушения. Если же атака "применима" к данной ОС, то в действие вступает следующий вариант корреляции. Корреляция атак и уязвимостей. Следуя определению атаки, она не может быть успешна, если атакуемый узел или сегмент сети не содержит уязвимости. Таким образом, сопоставляя данные об атаке с информацией об уязвимостях атакуемого узла или сегмента, можно с уверенностью будет сказать, применима ли зафиксированная атака к вашей сети и, если да, то нанесет ли она вам какой-либо ущерб.

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

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

Таблица 4. Результат работы механизма корреляции на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Корреляция на службе безопасности

Лукацкий А.В., , опубликовано в журнале BYTE #10/2003

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

Сканирование периметра сети Подбор пароля на узлах, видимых из Интернет Атаки червей Slammer и т.п. Использование уязвимостей Web-сервера и т.п.

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

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

Многие специалисты считают, что ложное обнаружение лучше, чем отсутствие сообщения об атаке. Однако это как раз та ситуация, когда количество переходит в качество. Со временем это становится головной болью любого администратора, которому приходится решать, реагировать на появившееся на консоли сообщение или проигнорировать его. В результате администратор просто перестает реагировать не только на ложные, но и на любые другие сообщения, в т.ч. и влекущие за собой тяжелые последствия. Например, в Таблице 1 показан фрагмент журнала регистрации широко известной в России системы обнаружения атак RealSecure Network 10/100, которая зафиксировала распространение червя Slammer, нашумевшего в начале этого года. Таких записей за период в один день в журнале может быть несколько десятков тысяч, ведь, как можно видеть, скорость распространения Slammer составляет несколько узлов в секунду.

Об авторе

Алексей Викторович Лукацкий, руководитель отдела Internet-решений Научно-инженерного предприятия "Информзащита" (Москва). Автор книг "Обнаружение атак", "Атака из Internet" и "Protect Your Information with Intrusion Detection". Связаться с ним можно по тел. (095) 937-3385 или e-mail: .

Огласите весь список, пжалуйста!

Число систем корреляции постоянно растет и к ним, например, можно отнести:

. . . . . . .

Несмотря на рост интереса к этим системам на Западе, в России о таких решениях говорят пока мало и это закономерно. У нас далеко не все используют системы обнаружения атак и межсетевые экраны, не говоря уже о средствах, стоящих существенно выше на эволюционной шкале защитных механизмов. Однако, несмотря на это, в России уже можно найти системы управления информационной безопасностью таких известных в мире безопасности компаний, как Internet Security Systems, Cisco Systems и Symantec.

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

Компания Cisco предлагает систему , которое построено на базе широко известной на Западе системы управления информационной безопасности одноименной компании.

Компания Symantec предлагает систему и семейство , вошедшее в пакет предложений Symantec после покупки последней компании SecurityFocus.

Приоритезация

Одна и та же атака может иметь различные последствия для разных узлов корпоративной сети. Например, узел, работающий под управлением ОС Solaris 2.5.1, уязвим для атаки Ping of Death, а узел, работающий под ОС Windows NT, не подвержен данной атаке. Можно привести и другой пример - наличие модема. Если модем подключен к компьютеру с выполнением всех требований по обеспечению информационной безопасности, то это нормальная ситуация, не требующая пристального внимания администратора безопасности. Напротив, модем, подключенный в обход межсетевого экрана, должен быть немедленно удален. Или сервис Telnet. На маршрутизаторе он нужен, а на большинстве рабочих станций - нет. Именно поэтому система централизованного мониторинга атак должна предусматривать возможность задания приоритетов для обнаруживаемых атак или уязвимостей. При этом задание приоритетов может быть как статическим (что было продемонстрировано выше на трех примерах), так и динамическим.

Зачем нужно динамическое задание приоритетов, и почему недостаточно статического метода? Допустим, на компьютере существует учетная запись Guest, с помощью которой любой злоумышленник сможет делать на компьютере все, что ему заблагорассудится. В обычных условиях эта уязвимость имеет высокий приоритет. Однако на практике, в зависимости от того, разрешена (enable) ли эта учетная запись или запрещена (disable), данная уязвимость может иметь самый высокий или самый низкий приоритет, соответственно. В такой ситуации приоритет может быть назначен только после корреляции событий, т.е. он должен задаваться динамически (сравните Таблицы 4 и 6).

Таблица 6. Результат работы механизма динамической приоритезации на примере системы RealSecure SiteProtector с установленным модулем SecurityFusion Module

Системы управления информационной безопасностью

Для того чтобы избежать описанных проблем, необходима эффективная система управления информационной безопасности (Security Information Management System, SIMS), которая позволяет все используемые защитные средства объединить в единый управляемый комплекс. Такая система:

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

Использование таких систем позволяет ответить на множество вопросов, постоянно возникающих в процессе обеспечения информационной безопасности, например:

Уязвим ли атакуемый узел к зафиксированной атаке? Нанесла ли атака ущерб ресурсам моей сети? Заблокировал ли установленный на атакуемом узле агент системы защиты зафиксированную атаку? Какая система атакуется в данный момент? Какие узлы моей сети являются источниками атак?

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

Консолидация (event consolidation). Агрегирование (event aggregation). Корреляция (event correlation). Приоритезация (event prioritization).

в области информационной безопасности определяется

Безопасность СУБД

Михаил Савельев

, #09/2005

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

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

Кроме того, если вернуться к случаям взлома БД и провести простой расчет, то он покажет несостоятельность попыток свалить всю вину за происшедшее на хакеров. Разделив объем украденных данных на типовую скорость канала доступа в Интернет, мы получим, что даже при максимальной загруженности канала на передачу данных должно было бы уйти до нескольких месяцев. Логично предположить, что такой канал утечки данных был бы обнаружен даже самой невнимательной службой безопасности.

И если перед нами стоит задача обеспечить безопасность корпоративной СУБД, давайте озадачимся простым вопросом: кто в компании вообще пользуется базой данных и имеет к ней доступ?

Существует три большие группы пользователей СУБД, которых условно можно назвать операторами; аналитиками; администраторами.

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

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

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

Блочные шифры

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

Наиболее простой и интуитивно понятный способ состоит в том, чтобы разбить исходный текст на блоки соответствующего размера, а затем отдельно каждый блок подвергнуть шифрующему преобразованию. Такой режим использования блочных шифров называют электронной кодовой книгой (ECB - electronic codebook). Его главный недостаток состоит в том, что одинаковые блоки исходного текста при шифровании дадут одинаковые же блоки шифр-текста - а это может существенно облегчить противнику задачу взлома. Поэтому режим ECB не рекомендуется использовать при шифровании текстов, по длине превышающих один блок - в таких случаях лучше воспользоваться одним из режимов, связывающих различные блоки между собой. По умолчанию в CryptoAPI блочные шифры используются в режиме сцепления блоков шифр-текста (CBC - cipher block chaining). В этом режиме при шифровании очередной блок исходного текста вначале комбинируется с предыдущим блоком шифр-текста (при помощи побитового исключающего ИЛИ), а затем полученная последовательность битов поступает на вход блочного шифра (рис. 14). Образующийся на выходе блок шифр-текста используется для шифрования следующего блока. Самый первый блок исходного текста также должен быть скомбинирован с некоторой последовательностью битов, но "предыдущего блока шифр-текста" еще нет; поэтому режимы шифрования с обратной связью требуют использования еще одного параметра - он называется инициализирующим вектором (IV - initialization vector).

Инициализирующий вектор должен генерироваться отдельно с помощью уже известной нам функции CryptGenRandom и, как и солт-значение, передаваться вместе с ключом в открытом виде. Размер IV равен длине блока шифра. Например, для алгоритма RC2, поддерживаемого базовым криптопровайдером Microsoft, размер блока составляет 64 бита (8 байтов).

Целостность и аутентичность информации

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

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

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

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

Цифровые конверты

Delphi и Windows API для защиты секретов (части 1,2,3)

Константин Виноградов, Лилия Виноградова,

Как реализовать методы криптографической защиты информации при помощи подручных средств – Windows и Delphi

Электронная цифровая подпись

Подписать вычисленный хеш в CryptoAPI позволяет функция CryptSignHash (хеш, описание ключа, комментарий, флаги, подпись, длина подписи). Вторым параметром может быть либо AT_KEYEXCHANGE, либо AT_SIGNATURE (в нашем случае логичнее использовать ключ подписи). Третий параметр в целях безопасности настоятельно рекомендуется оставлять пустым (nil). Флаги в настоящее время также не используются - на месте этого аргумента должен быть нуль. Готовую электронную подпись функция запишет в буфер, адрес которого содержится в предпоследнем параметре, последний же параметр будет содержать длину подписи в байтах.

Чтобы проверить правильность подписи, получатель подписанного сообщения должен иметь файл с открытым ключом подписи отправителя. В процессе проверки подписи этот ключ импортируется внутрь криптопровайдера. Проверка выполняется функцией CryptVerifySignature (хеш, подпись, длина подписи, открытый ключ, комментарий, флаги). О последних двух аргументах можно сказать то же, что и о параметрах комментарий и флаги функции CryptSignHash, назначение же остальных должно быть понятно. Если подпись верна, функция возвращает true. Значение false в качестве результата может свидетельствовать либо о возникновении ошибки в процессе проверки, либо о том, что подпись оказалась неверной. В последнем случае функция GetLastError вернет ошибку NTE_BAD_SIGNATURE. Для примера приведем наиболее значимые фрагменты программы проверки подписи:

Полный Delphi-проект примера можно найти .

Контейнеры ключей

Подключение к контейнеру производится одновременно с получением контекста криптопровайдера при вызове функции CryptAcquireContext - имя контейнера ключей передается функции вторым ее аргументом. Если второй аргумент содержит пустой указатель (nil), то используется имя по умолчанию, т. е. имя пользователя. В том случае, если доступ к контейнеру не нужен, можно передать в последнем аргументе функции флаг CRYPT_VERIFYCONTEXT; при необходимости создать новый контейнер используется флаг CRYPT_NEWKEYSET; а для удаления существующего контейнера вместе с хранящимися в нем ключами - CRYPT_DELETEKEYSET.

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

Криптографические возможности Windows

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

Итак, ОС мы доверяем. Чтобы криптозащиту нельзя было «обойти» с другой стороны - к примеру, перехватить из незащищенной области памяти секретные пароли - криптографические функции должны быть частью операционной системы. В семействе Windows, начиная с Windows 95, обеспечивается реализация шифрования, генерации ключей, создания и проверки цифровых подписей и других криптографических задач. Эти функции необходимы для работы операционной системы, однако ими может воспользоваться и любая прикладная программа - для этого программисту достаточно обратиться к нужной подпрограмме так, как предписывает криптографический интерфейс прикладных программ (CryptoAPI).

Разумеется, по мере совершенствования Windows расширялся и состав ее криптографической подсистемы. Помимо базовых операций, в настоящее время в CryptoAPI 2.0 поддерживается работа с сертификатами, шифрованными сообщениями в формате PKCS #7 и пр.

Описание функций CryptoAPI, помимо специальных книг, можно найти в MSDN Library.

Обмен ключами

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

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

Экспорт ключей в CryptoAPI выполняется функцией CryptExportKey (экспортируемый ключ, ключ адресата, формат, флаги, буфер, размер буфера):

экспортируемый ключ - дескриптор нужного ключа; ключ адресата - в случае сохранения открытого ключа должен быть равен нулю (данные не шифруются); формат - указывается один из возможных форматов экспорта (PUBLICKEYBLOB, PRIVATEKEYBLOB, SIMPLEBLOB); флаги - зарезервирован на будущее (должен быть равен нулю); буфер - содержит адрес буфера, в который будет записан ключевой BLOB (Binary Large OBject - большой двоичный объект); размер буфера - при вызове функции в этой переменной должен находиться доступный размер буфера, а по окончании работы в нее записывается количество экспортируемых данных. Если размер буфера заранее не известен, то функцию нужно вызвать с параметром буфер, равным пустому указателю, тогда размер буфера будет вычислен и занесен в переменную размер буфера.

От слов - к делу

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

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

Полный Delphi-проект можно взять .

Продолжение статьи, посвященное сертификатам (часть 4) -

Авторы ищут издателя для публикации учебного пособия по данной теме.
Персональный сайт авторов - http://www.is.svitonline.com/vilys/.

Проблема распределения ключей

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

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

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

Шифрование с использованием паролей

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

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

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

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

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

При соблюдении приведенных условий хеш-значение служит компактным цифровым отпечатком (дайджестом) сообщения. Существует множество алгоритмов хеширования. CryptoAPI поддерживает, например, алгоритмы MD5 (MD - Message Digest) и SHA (Secure Hash Algorithm).

Создание ключевых пар

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

провайдер - дескриптор криптопровайдера, полученный в результате обращения к функции CryptAcquireContext; алгоритм - указывает, какому алгоритму шифрования будет соответствовать создаваемый ключ. Информация об алгоритме, таким образом, является частью описания ключа. Каждый криптопровайдер использует для обмена ключами и подписи строго определенные алгоритмы. Так, провайдеры типа PROV_RSA_FULL, к которым относится и Microsoft Base Cryptographic Provider, реализуют алгоритм RSA. Но при генерации ключей знать это не обязательно: достаточно указать, какой ключ мы собираемся создать - обмена ключами или подписи. Для этого используются мнемонические константы AT_KEYEXCHANGE и AT_SIGNATURE; флаги - при создании асимметричных ключей управляет их размером. Используемый нами криптопровайдер позволяет генерировать ключ обмена ключами длиной от 384 до 512 бит**, а ключ подписи - от 512 до 16384 бит. Чем больше длина ключа, тем выше его надежность, поэтому трудно найти причины для использования ключа обмена ключами длиной менее 512 бит, а длину ключа подписи не рекомендуется делать меньше 1024 бит**. По умолчанию криптопровайдер создает оба ключа длиной 512 бит. Необходимую длину ключа можно передать в старшем слове параметра флаги; ключ - в случае успешного завершения функции в этот параметр заносится дескриптор созданного ключа.

Создание сеансовых ключей

CryptoAPI позволяет генерировать сеансовые ключи случайным образом - эту работу выполняет функция CryptGenKey, о которой шла речь ранее. Однако при использовании этой возможности за пределами США и Канады приходится учитывать американские ограничения на экспорт средств "сильной криптографии". В частности, до января 2000года был запрещен экспорт программного обеспечения для шифрования с использованием ключей длиной более 40 бит. Этим объясняется разработка Microsoft двух версий своего криптопровайдера - базовой и расширенной. Базовая версия предназначалась на экспорт и поддерживала симметричные ключи длиной 40 бит; расширенная же версия (Microsoft Enhanced Cryptographic Provider) работала с "полной" длиной ключа (128 бит). Поскольку алгоритм шифрования, как правило, требует использования ключа строго определенной длины, недостающее количество битв в урезанном "экспортном" ключе могло быть заполнено либо нулями, либо случайными данными, которые предлагалось передавать открыто.

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

Итак, CryptoAPI, в экспортном исполнении практически вынуждает нас использовать солт-значения, составляющие бОльшую часть ключа - 88 бит из 128-ми для симметричных алгоритмов в RC2; и RC4. Конечно, при такой эффективной длине ключа криптозащита не может считаться достаточно надежной. В реальной ситуации выход один - воспользоваться криптопровайдером, не ограничивающим длину ключа. Обладатели Windows XP могут прибегнуть к услугам расширенных версий провайдера Microsoft (Enhanced или Strong).
Пользователям более старых версий Windows, по-видимому, придется воспользоваться продуктами сторонних разработчиков. Например, свои версии криптопровайдеров предлагают российская компания и шведская . В Украине, насколько известно авторам, разработкой национального провайдера криптографических услуг занимается коллектив харьковских ученых под руководством профессора Горбенко, однако до широкого внедрения дело пока не дошло. Тем не менее, благодаря архитектуре CryptoAPI, прикладные программы могут разрабатываться и отлаживаться и с базовым провайдером Microsoft - так как интерфейс взаимодействия остается неизменным. Поэтому вернемся к обсуждению создания случайных сеансовых ключей.

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

1. при создании ключа функции CryptGenKey передается значение флага CRYPT_EXPORTABLE or CRYPT_CREATE_SALT;

2. с помощью функции CryptGetKeyParam с параметром KP_SALT сгенерированное солт-значение сохраняется в буфере;

3. ключ в зашифрованном виде сохраняется в буфере при помощи функции CryptExportKey, которой передается открытый ключ обмена ключами адресата;

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

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

Взаимодействие с CryptoAPI

Функции CryptoAPI можно вызвать из программы, написанной на любимом многими (в том числе и авторами) языке С++. Тем не менее, Pascal де-факто признан стандартом в области обучения программированию. (Не будем спорить о том, хорошо это или плохо, чтобы не ввязываться в драку, пусть даже и виртуальную.) Кроме того, в ряде отечественных компаний Delphi является базовым средством разработки. Поэтому все примеры были реализованы в среде Delphi. Хотя в качестве инструмента можно было бы выбрать и MS Visual C++.

Код функций криптографической подсистемы содержится в нескольких динамически загружаемых библиотеках Windows (advapi32.dll, crypt32.dll). Для обращения к такой функции из прикладной программы на Object Pascal следует объявить ее как внешнюю. Заголовок функции в интерфейсной части модуля будет выглядеть, например, так: function CryptAcquireContext ( phPROV: PHCRYPTPROV; pszContainer: LPCTSTR; pszProvider: LPCTSTR; dwProvType: DWORD; dwFlags: DWORD): BOOL; stdcall;

а в исполняемой части вместо тела функции нужно вписать директиву extern с указанием библиотеки, в которой содержится функция, и, возможно, ее имени в этой библиотеке (если оно отличается от имени функции в создаваемом модуле), например: function CryptAcquireContext; external ‘advapi32.dll’ name 'CryptAcquireContextA';

Таким образом, имея описание функций CryptoAPI, можно собрать заголовки функций в отдельном модуле, который будет обеспечивать взаимодействие прикладной программы с криптографической подсистемой. Разумеется, такая работа была проделана программистами Microsoft, и соответствующий заголовочный файл (wincrypt.h) был включен в поставку MS Visual C++. К счастью, появилась и Delphi-версия (wcrypt2.pas). Ее можно найти . Подключив модуль к проекту, вы сможете использовать не только функции CryptoAPI, но и мнемонические константы режимов, идентификаторы алгоритмов и прочих параметров, необходимых на практике.

И последнее замечание перед тем, как опробовать CryptoAPI в деле. Ряд функций был реализован только в Windows 2000. Но и на старушку Windows 98 можно найти управу: при установке Internet Explorer 5 интересующие нас библиотеки обновляются, позволяя использовать новейшие криптографические возможности. Нужно лишь задать для Delphi-проекта параметр условной компиляции NT5, после чего вызовы функций, появившихся лишь в Windows 2000, будут нормально работать.

Знакомство с криптопровайдерами

Функции CryptoAPI обеспечивают прикладным программам доступ к криптографическим возможностям Windows. Однако они являются лишь «передаточным звеном» в сложной цепи обработки информации. Основную работу выполняют скрытые от глаз программиста функции, входящие в специализированные программные (или программно-аппаратные) модули — провайдеры (поставщики) криптографических услуг (CSP - Cryptographic Service Providers), или криптопровайдеры (рис. 1).

Программная часть криптопровайдера представляет собой dll-файл, подписанный Microsoft; периодически Windows проверяет цифровую подпись, что исключает возможность подмены криптопровайдера.

Криптопровайдеры отличаются друг от друга:

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

По составу функций и обеспечивающих их алгоритмов криптопровайдеры подразделяются на типы. Например, любой CSP типа PROV_RSA_FULL поддерживает как шифрование, так и цифровые подписи, использует для обмена ключами и создания подписей алгоритм RSA, для шифрования — алгоритмы RC2 и RC4, а для хеширования - MD5 и SHA.

В зависимости от версии операционной системы состав установленных криптопровайдеров может существенно изменяться. Однако на любом компьютере с Windows можно найти Microsoft Base Cryptographic Provider, относящийся к уже известному нам типу PROV_RSA_FULL. Именно с этим провайдером по умолчанию будут взаимодействовать все программы.

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

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

CryptEnumProviders (i, резерв, флаги, тип, имя, длина_имени) - возвращает имя и тип i-го по порядку криптопровайдера в системе (нумерация начинается с нуля); CryptAcquireContext (провайдер, контейнер, имя, тип, флаги) - выполняет подключение к криптопровайдеру с заданным типом и именем и возвращает его дескриптор (контекст). При подключении мы будем передавать функции флаг CRYPT_VERIFYCONTEXT, служащий для получения контекста без подключения к контейнеру ключей; CryptGetProvParam (провайдер, параметр, данные, размер_данных, флаги) - возвращает значение указанного параметра провайдера, например, версии (второй параметр при вызове функции - PP_VERSION), типа реализации (программный, аппаратный, смешанный - PP_IMPTYPE), поддерживаемых алгоритмов (PP_ENUMALGS). Список поддерживаемых алгоритмов при помощи этой функции может быть получен следующим образом: при одном вызове функции возвращается информация об одном алгоритме; при первом вызове функции следует передать значение флага CRYPT_FIRST, а при последующих флаг должен быть равен 0; CryptReleaseContext (провайдер, флаги) - освобождает дескриптор криптопровайдера.

Каждая из этих функций, как и большинство других функций CryptoAPI, возвращает логическое значение, равное true, в случае успешного завершения, и false - если возникли ошибки.Код ошибки может быть получен при помощи функции GetLastError. Возможные значения кодов ошибки приведены в упоминавшейся выше документации. Например, при вызове функции CryptGetProvParam для получения версии провайдера следует учесть возможность возникновения ошибок следующим образом:

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