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

[1] A.A. Грушо , Е.Е. Тимонина -- Модель невлияния для сети. -- Обозрение прикладной и промышленной математики, т. 7 (1), Москва: ТВП, 2000

[2] A.A. Грушо , Е.Е. Тимонина -- Двойственность многоуровневой политики безопасности. -- Тез. конф. "Методы и технические средства информационной безопасности", С.-Петербург, 2000

[3] A.A. Грушо , Е.Е. Тимонина , Э.А. Применко -- Анализ и синтез криптоалгоритмов. Курс лекций. -- Йошкар-Ола: изд-во Марийского филиала Московского открытого социального университета, 2000

[4] A.A. Грушо , Е.Е. Тимонина -- Языки в скрытых каналах. -- Труды XXX международной конференции "Информационные технологии в науке, образовании, телекоммуникации, бизнесе", Украина, 2003

[5] A.A. Грушо , Е.Е. Тимонина -- Оценка времени обучения агента для организации скрытого канала. -- Дискретная математика, Т. 15 (2), 2003

[6] A.A. Грушо , Е.Е. Тимонина -- Преодоление защиты от скрытого канала. -- Обозрение прикладной и промышленной математики, Т. 10 (3), Москва: ТВП, 2003

[7] А.А. Грушо , Е.Е. Тимонина -- Проблемы компьютерной безопасности. -- Сб. научных докладов "Информационные технологии в производстве, медицине, психологии и этике" Академии информационных управленческих технологий. — М.: Центр Управления Полетами, 2003

[8] А.А. Грушо , Е.Е. Тимонина -- Стохастические скрытые каналы. -- Материалы международн. семинара "Информатика и общество" I&S'04 (10-24 января). — Низкие Татры, 2004

[9] А.А. Грушо , Е.Е. Тимонина -- Нарушение безопасности систем с единой точкой входа. -- Материалы 8-ой международной конференции "Связь-2004", озеро Иссык-Куль, 22-29 августа, 2004, Новосибирск: ЗАО РИЦ Прайс Курьер, 2004

[10] А.А. Грушо , Е.Е. Тимонина -- Скрытые каналы с использованием HTML. -- Труды XXXII международной конференции и III международной конференции молодых ученых "Информационные технологии в науке, образовании, телекоммуникации и бизнесе.

А.А. Грушо (Доктор физико-математических наук)

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

Рассмотрим сеть, состоящую из узлов

Эффективность защиты информации

07.08.2003

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

Факторы, влияющие на уровень защиты информации, систематизированы в ГОСТ Р 51275-99. Однако, независимо от воли и предвидения разработчиков возникают и иные, заранее неизвестные при проектировании систем защиты информации (СЗИ) обстоятельства, способные снизить эффективность защиты или полностью скомпрометировать предусмотренные проектом меры информационной безопасности. Оценка эффективности защиты информации должна обязательно учитывать эти объективные обстоятельства, а ее характеристики, как это следует из ГОСТ Р 50922-96, должны иметь вероятностный характер. Развитие подобной методологии, включая систему нормативных документов, содержащих количественные, измеримые показатели эффективности СЗИ, обеспечит интересы как заказчиков, так и проектировщиков. Особую важность приобретает обоснование оптимальных значений показателей эффективности, учитывающее целевое предназначение информационной системы.

Для решения рассматриваемой проблемы предлагается использовать системный подход. Как отмечали авторы [8], «сама идея количественного определения эффективности с полным правом может рассматриваться как поворотный пункт истории науки».

Экономический аспект

Массовое создание, внедрение и эксплуатация информационных систем привели к возникновению спектра новых проблем в сфере безопасности личности, общества и государства. Внимание к этим проблемам закономерно. Если коммерческая организация допускает утечку более 20% важной внутренней информации, то она в 60 случаях из 100 банкротится [17]. Утверждают также [11], 93% компаний, лишившихся доступа к собственной информации на срок более 10 дней, покинули бизнес, причем половина из них заявила о своей несостоятельности немедленно.

Потребность в обеспечении безопасности связана с тем, что существует множество субъектов и структур, весьма заинтересованных в чужой информации и готовых заплатить за это высокую цену. Так, стоимость устройств подслушивания, продаваемых только в США, составляет в среднем около 900 млн. долл. в год. Суммарный урон, нанесенный организациям, против которых осуществлялось прослушивание, составляет ежегодно в США около 8 млрд. долл. А ведь существуют и, соответственно, приобретаются устройства для несанкционированного доступа к информации и по другим каналам: проникновение в информационные системы, перехват и дешифровка сообщений и т.д. В результате, по данным SANS Institute, средний размер убытка от одной атаки в США на корпоративную систему для банковского и ИТ-секторов экономики составляет около полумиллиона долларов [19]. Примерная структура последствий неэффективного обеспечения информационной безопасности в американских организациях такова [18]: кража конфиденциальной информации — 20-25% от общего годового ущерба; фальсификация финансовой информации — 21-25%; заражение вредоносными программами — 11-12%; нарушение доступа к Web-сайтам — 1-11%; срыв работы информационной системы — 4-10%; незаконный доступ сотрудников к информации — 4-9%; другие виды ущерба — 14-33%.

В таких условиях все более широко распространяется мнение, что защита информации должна по своим характеристикам быть соразмерной масштабам угроз [1, 2, 16]. Отклонение от этого правила чревато дополнительным ущербом. Скажем, если уровень защищенности информационной системы превышает уровень C2 по «Оранжевой книге», то ее подсистема защиты потребляет значительную часть общих ресурсов (для систем уровня B1 эта доля составляет 20-50%, а для уровня B2 она может превышать 90%) [16]. Для каждой системы имеется оптимальный уровень защищенности, который и нужно поддерживать [2].

Качество и его подтверждение

Зачастую заказчик СЗИ плохо представляет себе значение того или иного средства и его вклад в общий уровень безопасности и в результате происходит увеличение затрат при практической неопределенности достигнутого эффекта. Как следствие, далеко не всегда заказчик СЗИ получает то, что ему реально нужно, и не может объективно проверить и оценить качество и эффективность предложенного решения [13].

Средства защиты информации в соответствии с действующими нормами и правилами подлежат обязательной или добровольной сертификации. Однако сертификация не является совершенным инструментом и не дает необходимых гарантий. В лучшем случае проверяется только 85% всех возможных состояний, а обычно — 60-70% [14].

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

Количественная оценка гарантий защиты

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

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

Обобщенные данные о возможных показателях эффективности приведены в таблице 1, а критериев — в таблице 2.

Количественная оценка эффективности

В соответствии с современной теорией оценки эффективности систем [15], качество любого объекта, в том числе и СЗИ, проявляется лишь в процессе его использования по назначению (целевое функционирование), поэтому наиболее объективным является оценивание по эффективности применения.

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

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

Методическое обеспечение

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

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

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

Нормативная база

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

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

Эти же замечания можно отнести и к международной нормативной базе по информационной безопасности, включающей около 50 международных стандартов ИСО/МЭК на критерии оценки безопасности ИТ и методы защиты средств и систем ИТ. Применение методов функциональной стандартизации в области информационной безопасности изложены в международном стандарте ИСО/МЭК 15408-99 «Критерии оценки безопасности информационных технологий». Фактически, Общие критерии предлагают набор исторически сложившихся и, самое главное, привычных в отрасли подходов к безопасности, которые используются, чтобы создавать изделия или системы, отражающие не столько потребности заказчика, сколько возможности разработчика. Важно отметить, что по своей сути они являются не критериями в полном смысле этого термина, а неким подобием общих технических требований, определяющих облик систем в зависимости от их назначения и условий функционирования.

Основные причины проблем

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

игнорирование системного подхода как методологии анализа и синтеза СЗИ; отсутствие механизмов полного и достоверного подтверждения качества СЗИ; недостатки нормативно-методического обеспечения информационной безопасности, прежде всего в области показателей и критериев.

Системность при защите информации

Уже в первых работах по защите информации были изложены основные постулаты, которые не утратили своей актуальности и по сей день [9]: абсолютную защиту создать нельзя; система защиты информации должна быть комплексной; СЗИ должна быть адаптируемой к изменяющимся условиям.

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

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

Технический аспект

По статистическим данным Национального отделения ФБР по компьютерным преступлениям, от 85 до 97% нападений на корпоративные сети не только не пресекаются, но даже и не обнаруживаются. Специальная группа экспертов провела анализ защищенности 8932 военных информационных систем; в 7860 (88%) случаях несанкционированное проникновение посторонних в эти системы было успешным. Администраторы только 390 из них обнаружили атаки и всего лишь 19 сообщили о них.

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

в какой мере система защиты

Идентификация рисков

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

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

«Использование чужого идентификатора сотрудниками организации ("маскарад")»

Для оценки угроз выбраны следующие косвенные факторы:

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

Для оценки уязвимостей выбраны следующие косвенные факторы:

Количество рабочих мест (пользователей) в системе. Размер рабочих групп. Осведомленность руководства о действиях сотрудников (разные аспекты). Характер используемого на рабочих местах оборудования и ПО. Полномочия пользователей.

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

История вопроса

Опубликованные стандарты в области защиты информации (ISO 15408, ISO 17799, ISO 9001, NIST 800-30, BSI, BS 7799, COBIT, ITIL и пр.) рассматривают вопросы анализа и управления информационными рисками (таблица 1), однако не содержат ряда важных деталей, которые обязательно надо конкретизировать при разработке практических методик управления рисками. Конкретизация этих деталей зависит от уровня зрелости организации, специфики ее деятельности и некоторых других факторов. Таким образом, невозможно предложить некую единую, приемлемую для всех отечественных компаний и организаций, универсальную методику управления рисками, позволяющую обеспечить экономически оправданную информационную безопасность предприятия. В каждом конкретном случае необходимо адаптировать общую методику управления рисками под определенные нужды предприятия, с учетом специфики его функционирования и ведения бизнеса. Давайте рассмотрим типичные вопросы и проблемы, возникающие при разработке методик управления информационными рисками в отечественных компаниях.

Таблица 1. Вопросы управления рисками в некоторых международных стандартах

Измерение рисков

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

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

РИСК = P происшествия * ЦЕНА ПОТЕРИ

Если переменные являются количественными величинами, то риск — это оценка математического ожидания потерь.

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

Определяется субъективная шкала вероятностей событий, например:
A - Событие практически никогда не происходит
B - Событие случается редко
C - Вероятность события за рассматриваемый промежуток времени – около 0.5
D - Скорее всего, событие произойдет
E - Событие почти обязательно произойдет

Кроме того, определяется субъективная шкала серьезности происшествий, например:
N (Negligible) – Воздействием можно пренебречь
Mi (Minor) – Незначительное происшествие: последствия легко устранимы, затраты на ликвидацию последствий невелики, воздействие на информационную технологию –незначительно.
Mo (Moderate) – Происшествие с умеренными результатами: ликвидация последствий не связана с крупными затратами, воздействие на информационную технологию невелико и не затрагивает критически важные задачи.
S (Serious) – Происшествие с серьезными последствиями: ликвидация последствий связана со значительными затратами, воздействие на информационные технологии ощутимо, воздействует на выполнение критически важных задач.
C (Critical) – Происшествие приводит к невозможности решения критически важных задач.

Для оценки рисков определяется шкала из трех значений:

Экономически оправданная безопасность

Сергей Петренко, Сергей Симонов, журнал "IT Manager" #15(3)/2004

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

Классы контрмер CRAMM (фрагмент)

Masquerading of User Identity by Insiders

Identification and Authentication
Logical Access Control
Accounting
Audit
Object Re-use
Security Testing
Software Integrity
Mobile Computing and Teleworking
Software Distribution
System Input/Output Controls
Network Access Controls
System Administration Controls
Application Input/Output Controls
Back-up of Data
Personnel
Security Education and Training
Security Policy
Security Infrastructure
Data Protection Legalisation
Incident Handling
Compliance Checks

Masquerading of User Identity by Contracted Service Providers

Identification and Authentication
Logical Access Control
Accounting
Audit
Object Re-use
Security Testing
Software Integrity
Mobile Computing and Teleworking
Software Distribution
System Input/Output Controls
Network Access Controls
System Administration Controls
Application Input/Output Controls
Back-up of Data
Personnel
Security Education and Training
Security Policy
Security Infrastructure
Outsourcing
Data Protection Legalisation
Incident Handling
Compliance Checks

Masquerading of User Identity by Outsiders

Identification and Authentication
Logical Access Control
Accounting
Audit
Object Re-use
Security Testing
Software Integrity
Mobile Computing and Teleworking
Software Distribution
System Input/Output Controls
Network Security Management
Network Access Controls
System Administration Controls
Application Input/Output Controls
Back-up of Data
Security Education and Training
Security Policy
Security Infrastructure
Data Protection Legalisation
Incident Handling
Compliance Checks

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

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

Таблица 4. Ориентировочная эффективность мероприятий в области защиты информации по критерию ROI (Return of Investment – возврат вложений)

Оценивание рисков

При оценивании рисков рекомендуется рассматривать следующие аспекты:

Шкалы и критерии, по которым можно измерять риски. Оценка вероятностей событий. Технологии измерения рисков.

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

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

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

Оценка уязвимости

Ответьте на вопросы:

1. Сколько людей имеют право пользоваться информационной системой?

Варианты ответов

a От 1 до 10 0 b От 11 до 50 4 c От 51 до 200 10 d От 200 до 1000 14 e Свыше 1000 20

2. Будет ли руководство осведомлено о том, что люди, работающие под их началом, ведут себя необычным образом?

Варианты ответов

a Да 0 b Нет 10

3. Какие устройства и программы доступны пользователям?

Варианты ответов

a Только терминалы или сетевые контроллеры, ответственные за предоставление и маршрутизацию информации, но не за передачу данных -5 b Только стандартное офисные устройства и программы и управляемые с помощью меню подчиненные прикладные программы 0 c Пользователи могут получить доступ к операционной системе, но не к компиляторам 5 d Пользователи могут получить доступ к компиляторам 10

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

Варианты ответов

a Да 10 b Нет 0

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

Варианты ответов

a Менее 10 человек 0 b От 11 до 20 человек 5 c Свыше 20 человек 10

6. Станет ли факт изменения хранящихся в информационной системе данных очевидным сразу для нескольких человек (в результате чего его будет очень трудно скрыть)?

Варианты ответов

a Да 0 b Нет 10

7. Насколько велики официально предоставленные пользователям возможности по просмотру всех хранящихся в системе данных?

Варианты ответов

a Официальное право предоставлено всем пользователям -2 b Официальное право предоставлено только некоторым пользователям 0

8. Насколько необходимо пользователям знать всю информацию, хранящуюся в системе?

Варианты ответов

a Всем пользователям необходимо знать всю информацию -4 b Отдельным пользователям необходимо знать лишь относящуюся к ним информацию 0

Ответьте на вопросы

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

Варианты ответов

a Ни разу 0 b Один или два раза 10 c В среднем раз в год 20 d В среднем чаще одного раза в год 30 e Неизвестно 10

2. Какова тенденция в статистике такого рода попыток несанкционированного проникновения в информационную систему?

Варианты ответов

a К возрастанию 10 b Остается постоянной 0 c К снижению -10

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

Варианты ответов

a Да 5 b Нет 0

4. Известны ли случаи нападения, угроз, шантажа, давления на сотрудников со стороны посторонних лиц?

Варианты ответов

a Да 10 b Нет 0

5. Существуют ли среди персонала группы лиц или отдельные лица с недостаточно высокими моральными качествами?

Варианты ответов

a Нет, все сотрудники отличаются высокой честностью и порядочностью 0 b Существуют группы лиц и отдельные личности с недостаточно высокими моральными качествами, но это вряд ли может спровоцировать их на несанкционированное использование системы 5 c Существуют группы лиц и отдельные личности с настолько низкими моральными качествами, что это повышает вероятность несанкционированного использования системы сотрудниками 10

6. Хранится ли в информационной системе информация, несанкционированное изменение которой может принести прямую выгоду сотрудникам?

Варианты ответов

a Да 5 b Нет 0

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

Варианты ответов

a Нет 0 b Да 5

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

Варианты ответов

a Да -10 b Нет 0

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

Варианты ответов

a Да -10 b Нет 0

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

Варианты ответов

a Ни разу 0 b Один или два раза 5 c В среднем раз в год 10 d В среднем чаще одного раза в год 15 e Неизвестно 10

Степень угрозы при количестве баллов:

До 9 Очень низкая От 10 до 19 Низкая От 20 до 29 Средняя От 30 до 39 Высокая 40 и более Очень высокая

Степень уязвимости при количестве баллов:

До 9 Низкая От 10 до 19 Средняя 20 и более Высокая

Технология оценки угроз и уязвимостей

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

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

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

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

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

Возможности и ограничения данного подхода

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

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

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

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

Выбор допустимого уровня риска

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

Первый подход типичен для базового уровня безопасности. Уровень остаточных рисков не принимается во внимание. Затраты на программно-технические средства защиты и организационные мероприятия, необходимые для соответствия информационной системы спецификациям базового уровня (антивирусное ПО, МЭ, системы резервного копирования, системы контроля доступа) являются обязательными, их целесообразность не обсуждается. Дополнительные затраты (если такой вопрос будет поставлен по результатам проведения аудита ИБ либо по инициативе службы безопасности) должны находиться в разумных пределах и не превышать 5-15% средств, которые тратятся на поддержание работы информационной системы.

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

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

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

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

Выбор контрмер и оценка их эффективности

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

в определении характеристик рисков корпоративной

Идентификация/аутентификация с помощью биометрических данных

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

Биометрией во всем мире занимаются очень давно, однако долгое время все, что было связано с ней, отличалось сложностью и дороговизной. В последнее время спрос на биометрические продукты, в первую очередь в связи с развитием электронной коммерции, постоянно и весьма интенсивно растет. Это понятно, поскольку с точки зрения пользователя гораздо удобнее предъявить себя самого, чем что-то запоминать. Спрос рождает предложение, и на рынке появились относительно недорогие аппаратно-программные продукты, ориентированные в основном на распознавание отпечатков пальцев.

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

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

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

Активность в области биометрии очень велика. Организован соответствующий консорциум (см. http://www.biometrics.org/), активно ведутся работы по стандартизации разных аспектов технологии (формата обмена данными, прикладного программного интерфейса и т.п.), публикуется масса рекламных статей, в которых биометрия преподносится как средство обеспечения сверхбезопасности, ставшее доступным широким массам.

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

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

Лекция из курса Основы информационной безопасности

В.А.Галатенко

Интернет Университет Информационных Технологий, INTUIT.ru

Одноразовые пароли

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

Наиболее известным программным генератором одноразовых паролей является система S/KEY компании Bellcore. Идея этой системы состоит в следующем. Пусть имеется односторонняя функция f (то есть функция, вычислить обратную которой за приемлемое время не представляется возможным). Эта функция известна и пользователю, и серверу аутентификации. Пусть, далее, имеется секретный ключ K, известный только пользователю.

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

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

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

Система S/KEY имеет статус Internet-стандарта (RFC 1938).

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

Основные понятия

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

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

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

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

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

В сетевой среде, когда стороны идентификации/аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта:

что служит аутентификатором (то есть используется для подтверждения подлинности субъекта); как организован (и защищен) обмен данными идентификации/аутентификации.

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

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

Парольная аутентификация

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

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

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

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

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

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

Тем не менее, следующие меры позволяют значительно повысить надежность парольной защиты:

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

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

Ролевое управление доступом

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

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

Пользователи, объекты и роли.

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

Ролевой доступ развивается более 10 лет (сама идея ролей, разумеется, значительно старше) как на уровне операционных систем, так и в рамках СУБД и других информационных сервисов. В частности, существуют реализации ролевого доступа для Web-серверов.

В 2001 году Национальный институт стандартов и технологий США предложил проект стандарта ролевого управления доступом (см. http://csrc.nist.gov/rbac/), основные положения которого мы и рассмотрим.

Ролевое управление доступом оперирует следующими основными понятиями:

пользователь (человек, интеллектуальный автономный агент и т.п.);

сеанс работы пользователя;

роль (обычно определяется в соответствии с организационной структурой);

Сервер аутентификации Kerberos

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

Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты - пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа.

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

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

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

Проиллюстрируем описанную процедуру.

Управление доступом в Java-среде

Java - это объектно-ориентированная система программирования, поэтому и управление доступом в ней спроектировано и реализовано в объектном стиле. По этой причине рассмотреть Java-среду для нас очень важно. Подробно о Java-технологии и безопасности Java-среды рассказано в статье А. Таранова и В. Цишевского "Java в три года" (Jet Info, 1998, 11-12). С разрешения авторов далее используются ее фрагменты.

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

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

Чтобы справиться с этой проблемой, в JDK 1.1 ввели деление источников (точнее, распространителей) апплетов на надежные и ненадежные (источник определялся по электронной подписи). Надежные апплеты приравнивались в правах к "родному" коду. Сделанное послабление решило проблемы тех, кому прав не хватало, но защита осталась неэшелонированной и, следовательно, неполной.

В JDK 1.2 сформировалась модель безопасности, используемая и в Java 2. От модели "песочницы" отказались. Оформились три основных понятия:

источник программы; право и множество прав;

политика безопасности.

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

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

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

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

Весьма важным понятием в модели безопасности JDK 1.2 является контекст выполнения. Когда виртуальная Java-машина проверяет права доступа объекта к системному ресурсу, она рассматривает не только текущий объект, но и предыдущие элементы стека вызовов. Доступ предоставляется только тогда, когда нужным правом обладают все объекты в стеке. Разработчики Java называют это реализацией принципа минимизации привилегий.

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

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


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

Разработчики Java осознавали эту проблему. Чтобы справиться с ней, они ввели понятие привилегированного интервала программы. При выполнении такого интервала контекст игнорируется. Привилегированная программа отвечает за себя, не интересуясь предысторией. Аналогом привилегированных программ являются файлы с битами переустановки идентификатора пользователя/группы в ОС Unix, что лишний раз подтверждает традиционность подхода, реализованного в JDK 1.2. Известны угрозы безопасности, которые привносят подобные файлы. Теперь это не лучшее средство ОС Unix перекочевало в Java.

Рассмотрим дисциплину контроля прав доступа более формально.

Класс AccessController (встроенный менеджер безопасности) предоставляет единый метод для проверки заданного права в текущем контексте - checkPermission (Permission). Это лучше (по причине параметризуемости), чем множество методов вида checkXXX, присутствующих в SecurityManager - динамически изменяемом менеджере безопасности из ранних версий JDK.

Пусть текущий контекст выполнения состоит из N стековых фреймов (верхний соответствует методу, вызвавшему checkPermission(p)). Метод checkPermission реализует следующий алгоритм (см. Листинг 10.1).

i = N; while (i > 0) { if (метод, породивший i-й фрейм, не имеет проверяемого права) { throw AccessControlException } else if (i-й фрейм помечен как привилегированный) { return; } i = i - 1; }; // Выясним, есть ли проверяемое право у унаследованного контекста inheritedContext.checkPermission (p);

Листинг 10.1. Алгоритм работы метода checkPermission класса AccessController. (, )

Сначала в стеке ищется фрейм, не обладающий проверяемым правом.


Проверка производится до тех пор, пока либо не будет исчерпан стек, либо не встретится "привилегированный" фрейм, созданный в результате обращения к методу doPrivileged(PrivilegedAction) класса AccessController. Если при порождении текущего потока выполнения был сохранен контекст inheritedContext, проверяется и он. При положительном результате проверки метод checkPermission(p) возвращает управление, при отрицательном возникает исключительная ситуация AccessControlException.

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

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

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

Возможный подход к управлению доступом в распределенной объектной среде

Представляется, что в настоящее время проблема управления доступом существует в трех почти не связанных между собой проявлениях:

традиционные модели (дискреционная и мандатная); модель "песочница" (предложенная для Java-среды и близкой ей системы Safe-Tcl); модель фильтрации (используемая в межсетевых экранах).

На наш взгляд, необходимо объединить существующие подходы на основе их развития и обобщения.

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

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

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

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

Объекты изолированы друг от друга. Единственным видом межобъектного взаимодействия является вызов метода.

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

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

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

Рассматривается задача разграничения доступа для выделенного контейнера CC, компонентами которого должны являться вызывающий и/или вызываемый объекты.
ДИ этого контейнера полагается общеизвестным. Считается также, что между внешними по отношению к выделенному контейнеру объектами возможны любые вызовы.

Выполнение ПРД контролируется монитором обращений.

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

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

Параметры методов могут быть входными и/или выходными. При приеме вызова возникает информационный поток из входных параметров в вызываемый объект. В момент завершения вызова возникает информационный поток из вызываемого объекта в выходные параметры. Эти потоки могут фигурировать в правилах разграничения доступа.

Структурируем множество всех ПРД, выделив четыре группы правил:

политика безопасности контейнера; ограничения на вызываемый метод; ограничения на вызывающий метод;

добровольно налагаемые ограничения.

Правила, общие для всех объектов, входящих в контейнер C, назовем политикой безопасности данного контейнера.

Пусть метод M1 объекта O1 в точке P1 своего выполнения должен вызвать метод M объекта O. Правила, которым должен удовлетворять M, можно разделить на четыре следующие подгруппы:

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

Метод M объекта O, потенциально доступный для вызова, может предъявлять к вызывающему объекту следующие группы требований:

правила, описывающие требования к фактическим параметрам вызова; правила, накладывающие ограничения на вызывающий объект.

Можно выделить три разновидности предикатов, соответствующих семантике и/или особенностям реализации методов:

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

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

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