Есть еще один способ оценки риска, он появился на свет в процессе работы в Microsoft, - DREAD (в вычислениях я буду использовать сокращение RiskDREAD) - по первым буквам английских названий описанных далее категорий.

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

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

Подверженность взлому (Exploitability) - мера усилий и квалификации, необходимых для атаки. Так, если ее может реализовать неопытный программист на домашнем компьютере, ставим большую жирную десятку (10). Если же для ее проведения надо потратить 100 000 000 долларов, оценка опасности - 1. И еще: атака, для которой можно написать алгоритм [а значит, распространить в виде сценария среди вандалов-любителей (script kiddies)], также оценивается в 10 баллов. Следует также учитывать необходимый для атаки уровень аутентификации и авторизации в системе. Например, если это доступно любому удаленному анонимному пользователю, подобная опасность оценивается 10 баллами. А вот атака, доступная только доверенному локальному пользователю, менее опасна.

Круг пользователей, попадающих под удар (Affected users) - доля пользователей, работа которых нарушается из-за успешной атаки. Оценка выполняется на основе процентной доли: 100% всех пользователей соответствует оценка 10, а 10% - 1 балл. Иногда опасность становится реальной только в системе, сконфигурированной особым образом. Опять же, оценивайте влияние опасности максимально удобным способом. Чрезвычайно важно проводить границу между сервером и клиентским компьютером: от ущерба, нанесенного серверу, пострадает больше клиентов и, возможно, другие сети. В этом случае балл значительно выше, чем оценка атаки только на клиентские компьютеры. Также не следует забывать о размерах рынка и абсолютном, а не только процентном, количестве пользователей. Один процент от 100 млн. пользователей - это все равно много.

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

Суммарная DREAD-оценка равна арифметическому среднему всех оценок (то есть надо их просуммировать и поделить на 5). После вычисления риска всех опасностей отсортируйте их в порядке убывания оценки, начиная с наибольшей. Например, так:

Опасность #1: Просмотр конфиденциальных данных о зарплате при их передаче через сеть 8 Потенциальный ущерб: просмотр личных данных о зарплате других пользователей - это серьезно 10 Воспроизводимость: воспроизводима на 100%

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

Еще один, более гибкий, способ - инвентаризация различных параметров опасностей, грозящих системе и анализ их в плане внедрения. Он очень похож на способ, разработанный Кристофером Клаусом (Christopher W. Klaus) - основателем компании Internet Security Systems, для оценки уязвимых мест, обнаруженных при применении продуктов этой компании. Вот некоторые вопросы, на которые следует ответить при рассмотрении опасностей:

как реализуется атака: при локальном или удаленном доступе? Может ли злоумышленник атаковать, не имея локального доступа? Очевидно, что «удаленные» атаки опаснее «локальных»;

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

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

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

Объединяем все вместе: декомпозицию, дерево опасностей, методы STRIDE и DREAD

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

Применять STRIDE к дереву опасностей довольно просто. Для этого для каждого компонента системы надо продумать ответы на следующие вопросы:

поддается ли компонент подмене;

возможно ли модифицировать компонент;

удастся ли злоумышленнику уйти ненаказанным, если он откажется от своих действий;

возможен ли просмотр компонента;

удастся ли взломщику блокировать доступ к процессу или потоку данных;

может ли злоумышленник повысить свои полномочия, успешно атаковав процесс?

Анализ путей в дереве опасностей, или как из капель мелких неприятностей рождается море проблем

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

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

Будильник прозвенел? Если нет, то не проспал ли я больше, чем на 30 минут?

Благополучно ли я преодолел душ? Могу ведь поскользнулся и упасть. Если да, то я поранился или только расстроился?

Автомобиль завелся? Если нет, то как я быстро поставлю его «на колеса» или придется ехать на другом?

Пробка на дороге? Если да, то насколько плотная?

Встреча с ГАИ? Если да, то как надолго?

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

Вы наверняка заметите, что отдельные элементы DFD-диаграмм подвергаются опасностям вполне определенного типа (табл. 4-3).

Таблица 4-3. Связь элементов DFD-диаграмм и категорий опасностей в модели STRIDE

Тип опасности Затрагивает ли процессы? Затрагивает ли хранилища

данных?

Затрагивает ли внешние

субъекты?

Затрагивает ли потоки

данных?

S Да Да
T Да Да Да
R Да Да Да
I Да Да Да
D Да Да Да
E Да

Некоторые элементы этой таблицы следует пояснить.

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

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

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

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

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

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

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

В следующих таблицах (табл. 4-4 - 4-9) перечислены опасности, грозящие приложению расчета зарплаты. На рис. 4-8 и рис. 4-10 - 4-14 (они следуют после таблиц) иллюстрируются деревья опасностей для случаев, описанных в табл. 4-4 - 4-9.

Таблица 4-4. Опасность #1

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

Важно отметить опасность, грозящую коммутируемым сетям, так как многие полагают, что они защищены от прослушивания трафика, но на самом деле это не так. Если не верите, почитайте статью «Why your switched network isn’t secure» (Почему коммутируемые сети небезопасны) на сайте http://www.sans.org

Таблица 4-5. Опасность #2

Описание опасности Загрузка хакером подложных Web-страниц и кода на сервер
Объект под угрозой Web-страницы (7.0) и код ^^еЬ-сервиса (8.0)
Категория опасности Модификация данных
Риск Потенциальный ущерб: 7 Воспроизводимость: 7 Подверженность взлому: 7 Пользователи под ударом: 10 Вероятность обнаружения: 10 Общая оценка: 8,2
Примечания В утилите установки ПО всегда предусматриваются надежные механизмы аутентификации и авторизации. Так что единственной причиной загрузки ^^еЬ-страниц могут стать просчеты администраторов при конфигурировании. (Подкуп персонала считаем маловероятным)

Таблица 4-6. Опасность #3

Описание опасности Блокирование взломщиком доступа к приложению
Объект под угрозой Процесс обработки клиентских запросов
Категория опасности Отказ в обслуживании
Риск Потенциальный ущерб: 6
Таблица 4-6.

(окончание)

Описание опасности

Блокирование взломщиком доступа к приложению
Примечания Воспроизводимость: 6 Подверженность взлому: 7 Пользователи под ударом: 9 Вероятность обнаружения: 10 Общая оценка: 7,6

Другие части приложения также уязвимы для DoS-атак, однако Web-сервер обработки клиентских запросов находится на «передовой», и поэтому его легче атаковать. Защитив эту часть приложения, мы уменьшим до приемлемого уровня риск нападения на другие процессы.

Составляющая опасности 3.3: проблема схожа с проблемой декартова соединения (Cartesian join). Результат такого соединения в запросе к БД - набор всех возможных комбинаций всех таблиц, указанных в SQL-запросе. Так, если не указать ограничивающих условия, то при выполнении декартова соединения трех таблиц, одна из которых содержит 650 000 записей, вторая - 113 000, а третья - 75 100, пользователь получит результат из 5 165 095 000 000 000 записей.

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

Таблица 4-7. Опасность , #4

Описание опасности

Модификация взломщиком данных о заработной плате

Объект под угрозой Категория опасности

Риск

Примечания

Данные о заработной плате (12.0)

Модификация данных и возможность разглашения информации

Потенциальный ущерб: 10 Воспроизводимость: 5 Подверженность взлому: 5 Пользователи под ударом: 10 Вероятность обнаружения: 10 Общая оценка: 8

Опасность 4.3 заключается в возможности доступа к измененным данным о зарплате при пересылке через сеть от административной консоли (2.0) к процессу административной политики, а затем к хранилищу с данными по зарплате (12.0). Как видно на DFD-диаграмме (рис. 4-5), выполняется два перехода через границы машин

Таблица 4-8. Опасность #5

Повышение взломщиком собственных привилегий за счет
Описание опасности изъянов в процессе обработки клиентских запросов
Объект под угрозой Сервис обработки клиентских запросов (5.0)
Категория опасности Повышение привилегий
Риск Потенциальный ущерб: 10
Воспроизводимость: 2
Подверженность взлому: 2
Пользователи под ударом: 1
Вероятность обнаружения: 10
Общая оценка: 5
Примечания Рассматриваемый объект под угрозой выполняется в про-
цессе Web-сервера, а код - в контексте локальной системы.
Это означает, что любой недружественный код, выполняе
мый в контексте Web-сервера, обладает на компьютере при
вилегиями Local System. Воспроизводимость и затраты на
организацию низки, потому что единственно возможный
способ взлома - эксплуатация уязвимых мест в защите про-
цесса Web-сервера.
Пострадавших от атаки пользователей немного, так как по-
ражается только сервер. Впрочем, об этом можно говорить
с натяжкой, так как от взлома сервера страдают практичес-
ки все пользователи

Таблица 4-9. Опасность #6

Подмена компьютера, на котором выполняется
Описание опасности процесс обработки клиентских запросов
Объект под угрозой Сервис обработки клиентских запросов (5.0)
Категория опасности Подмена сетевого объекта
Риск Потенциальный ущерб: 10
Воспроизводимость: 2
Подверженность взлому: 2
Пользователи под ударом: 8
Вероятность обнаружения: 10
Общая оценка: 6,4
Примечания Есть несколько способов вывести «законный» компьютер из
сети: «в лоб» аннулировать его как сетевой объект (переиме-
нование или выключение питания) или сделать его недо-
ступным [атаки на DNS или «затопление» (flood) пакетами]
Дерево опасностей для опасности#2

Рис. 4-10. Дерево опасностей для опасности#2

Дерево опасностей для опасности #3

Рис. 4-11. Дерево опасностей для опасности #3

Дерево опасностей для опасности #4

Рис. 4-12. Дерево опасностей для опасности #4

Дерево опасностей для опасности #5

Рис. 4-13. Дерево опасностей для опасности #5

Дерево опасностей для опасности #6

Рис. 4-14. Дерево опасностей для опасности #6

Подсчет суммарного риска

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

Так что наиболее вероятной возможностью остается опасность так называемой «атаки нулевого дня» (zero-day attack) на сервер, то есть в те периоды, когда уязвимое место в продукте уже обнаружено, но компания-разработчик еще не успела выпустить «заплату», а хакеры уже оперативно соорудили exploit.

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

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

Повторение моделирования опасности

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

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

Этап 2. По методике STRIDE определите опасности, возможные для каждого объекта под угрозой. Они становятся вершинами деревьев опасностей; для каждого объекта под угрозой строится одно дерево.

Этап 3. В зависимости от ситуации постройте одно или более деревьев опасностей для каждого объекта под угрозой.

Этап 4. Оцените риск безопасности для каждого дерева опасностей по методике DREAD или аналогичному методу ранжирования опасностей.

Этап 5. Отсортируйте опасности в порядке убывания риска.

Закончив с этим, переходят к следующему этапу - определению методов реагирования на опасности.

Реакция на опасность

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

ничего не предпринимать;

предупредить пользователей;

устранить причину опасности вместе с частью приложения;

устранить причины, из-за которых система подвергается опасности.

Вариант 1: ничего не предпринимать

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

Вариант 2: предупредить пользователей

Вторая возможность - оповестить пользователей о проблеме и предоставить им самим решать, применять ли небезопасную функцию. В Microsoft Internet Information Services (IIS) некоторые проблемы решены именно так: когда администратор выбирает базовую аутентификацию (basic authentication), появляется диалоговое окно с предупреждением, что пароли пользователей будут пересылаться в незашифрованном виде, если только их не защитить другим способом, например средствами протокола SSL/TLS.

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

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

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

Вариант 3: устранить проблемную функцию

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

Вариант 4: решить проблему

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

Отбор методов для предотвращения опасности

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

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

Таблица 4-10. Основные методы (основанные на технологиях безопасности) борьбы с опасностями

Тип опасности Средства борьбы
Подмена сетевых объектов Надежный механизм аутентификации Защита секретных данных Отказ от хранения секретов
Модификация данных Надежный механизм авторизации Использование хешей МАС-коды Цифровые подписи

Протоколы, предотвращающие прослушивание трафика

Отказ от авторства Цифровые подписи Метки даты и времени Контрольные следы
Разглашение информации Авторизация

Протоколы с усиленной защитой от несанкционированного доступа

Шифрование

Защита секретов

Отказ от хранения секретов

Отказ в обслуживании Надежный механизм аутентификации Надежный механизм авторизации Фильтрация

Управление числом входящих запросов Качество обслуживания

Повышение уровня привилегий Выполнение с минимальными привилегиями

Методы защиты

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

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

Аутентификация

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

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

базовая аутентификация;

аутентификация на основе хеша;

аутентификация на основе форм;

аутентификация Microsoft Passport;

стандартная аутентификация Windows;

аутентификация по протоколу NTLM (NT LAN Manager);

аутентификация по протоколу Kerberos v5;

аутентификация на основе сертификатов X.509;

протокол IPSec (Internet Protocol Security);

 RADIUS.

Механизмы аутентификации различаются по надежности. Так, базовая аутентификация (Basic Authentication) намного слабее, скажем, аутентификации по протоколу Kerberos. Об этом необходимо помнить при определении методов защиты тех или иных конфиденциальных ресурсов. Кроме того, учитывайте, что одни методы предусматривают аутентификацию клиентов, а другие - серверов. Например, при базовой аутентификации проверяется подлинность только клиента, но не сервера. В табл. 4-11 показано, подлинность каких объектов подтверждают различные протоколы.

Таблица 4-11. Протоколы аутентификации клиентов и серверов

Аутентификация Аутентификация
Протокол клиента сервера
Базовая аутентификация Да Нет
Аутентификация на основе хеша Да Нет
Аутентификация на основе форм Да Нет
Microsoft Passport Да Нет
NTLM Да Нет
Kerberos Да Да
Сертификаты X.509 Да Да
IPSec Да (компьютер) Да (компьютер)
RADIUS Да Нет
Базовая аутентификация

Базовая аутентификация - это простой протокол проверки подлинности, определенный как часть протокола HTTP 1.0 (см. RFC 2617 по адресу http://www.ietf.org/ rfc/rfc/rfc26l7.txt). Несмотря на то, что практически все Web-серверы и Web-браузеры поддерживают этот протокол, он исключительно небезопасен из-за полного отсутствия защиты пароля. Имя и пароль всего лишь кодируются по методу Base64! Короче говоря, базовую аутентификацию не стоит применять повсеместно: она не обеспечивает надежной защиты - исключение составляют случаи, когда соединение между клиентом и сервером защищается надежными средствами, например протоколом SSL/TLS или IPSec.

Аутентификация на основе хеша

Аутентификация на основе хешей, как и базовая, описана в RFC 2617, но у нее есть ряд преимуществ: наиболее важное, что пароль не пересылается открытым текстом. И еще, аутентификацию на основе хеша можно применять в других, отличных от HTTP, протоколах Интернета: в протоколе доступа к каталогам LDAP, почтовых протоколах IMAP (Internet Message Access Protocol), POP3 (Post Office Protocol 3) и SMTP (Simple Mail Transfer Protocol).

Аутентификация на основе форм

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

Аутентификация на основе форм работает следующим образом. Пользователю предлагается Web-страница, где он должен ввести имя и пароль и нажать кнопку отправки данных на сервер. Информация из Web-формы передается на Web-сервер (обычно по SSL/TLS-соединению), который на ее основании принимает решение об аутентификации. К примеру, имя и пароль могут храниться в базе данных или, в случае ASPNET, в конфигурационном XML-файле.

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

<%
Dim strUsername, strPwd As String strUsername = Request.Form("Username") strPwd = Request.Form("Pwd")

If IsValidCredentials(strUserName, strPwd) Then ' Прекрасно! Даем пользователю добро на вход!

' Отображаем этот факт, изменяя данные состояния Else

' Ой! Недопустимое имя пользователя и/или пароль Response.Redirect "401.html"

End If
%>

Аутентификация на основе форм чрезвычайно популярна в Интернете. Однако при неумелой реализации она может стать небезопасной.

Microsoft Passport

РаББрой-аутентификация - это централизованная схема аутентификации, поддерживаемая корпорацией Microsoft. Она применяется во многих сервисах (в том числе Microsoft Hotmail и Microsoft Instant Messenger) и на многочисленных сайтах электронной коммерции (в том числе 1-800-flowers.com, Victoria’s Secret, Wxpedia.com, Costco Online, OfiiceMax.com, Office Depot и 800.com). Ее основное преимущество в том, что для входа в Passport-службу, при переходе на другой Web-сервис, использующий Passport, не нужно заново вводить реквизиты. Для добавления в Web-сервис поддержки Passport необходимо загрузить комплект ресурсов разработчика Passport Software Development Kit (SDK) c сайта http://www.passport.com.

Поддержка технологии Passport в ASPNET реализована в классе PassportAuthen-ticationModule. С ее помощью в Microsoft Windows .NET Server можно войти в систему посредством функции LogonUser. Кроме того, Internet Information Services 6 (IIS 6) также поддерживает Passport в качестве стандартного протокола аутентификации, наравне с другими методами аутентификации: базовой, на основе хешей, Windows и на основе клиентских сертификатов X.509.

Стандартная аутентификация Windows

В Windows поддерживается два основных протокола аутентификации: NTLM и Kerberos. На самом деле к ним можно причислить также SSL/TLS, но мы рассмотрим его позже. Аутентификация в Windows происходит посредством интерфейсов SSPI (Security Support Provider Interface). Эти протоколы реализованы в виде SSP-провайдеров (Security Support Provider). В Windows существует четыре основных SSP-провайдера: NTLM, Kerberos, Schannel и Negotiate. Первый служит для NTLM-аутентификации, второй - для аутентификации Kerberos версии 5, а Schannel обеспечивает аутентификацию на основе клиентских сертификатов SSL/TLS. Провайдер Negotiate отличается от остальных тем, что не поддерживает никаких протоколов аутентификации, а применяется в этой ОС, начиная с Windows 2000, для выбора метода аутентификации клиента и сервера - NTLM или Kerberos.

Вопросы, связанные с SSPI, прекрасно изложены в книге Джеффри Рихтера (Jeffrey Richter) и Джейсона Кларка (Jason Clark) «Programming Server-Side Applications for Microsoft Windows 2000» (Microsoft Press, 2000) (Рихтер Дж., Кларк Дж. Д.

Программирование серверных приложений для Microsoft Windows 2000. Мастер-класс. СПб.:«Питер»; М.:«Русская редакция», 2001).

NTLM-аутентификация

Протокол NTLM поддерживают все современные версии Windows, в том числе Windows CE. NTLM работает по механизму «запрос - ответ» и применяется во многих Windows-службах, в том числе в службе доступа к файлам и печати, IIS, Microsoft SQL Server и Microsoft Exchange. Существует две версии NTLM. Версия 2, появившаяся в Windows NT SP 4, имеет одно значительное преимущество перед версией 1: она предотвращает атаки посредника (man-in-the-middle). Следует иметь в виду, что NTLM предусматривает аутентификацию только в одном направлении: клиента сервером, но не позволяет клиенту проверить подлинность сервера.

Аутентификация Kerberos v5

Протокол Kerberos v5 разработан в Массачусетском технологическом институте (Massachusetts Institute of Technology, MIT) и описан в документе RFC 1510 (http:// www.ietf.org/rfc/rfc1510.txt). В Windows 2000 и следующих ОС семейства Kerberos применяется при развертывании Active Directory. Одно из важнейших преимуществ Kerberos - взаимная аутентификация, то есть возможна проверка в обоих направлениях: от клиента к серверу и наоборот. Kerberos считается более надежным, чем NTLM, а во многих ситуациях он к тому же работает быстрее.

За подробным объяснением механизма работы Kerberos и принципов взаимодействия с серверными объектами по основным именам служб (service principal names, SPN) я отсылают вас к одной из написанных мной ранее книг: «Designing Secure Web-based Applications for Microsoft Windows 2000» (Microsoft Press, 2000) (М. Ховард, М. Леви, Р Веймир Разработка защищенных Web-приложений на платформе Microsoft Windows 2000. Мастер-класс. СПб: «Питер»; М.: «Русская Редакция», 2001).

Аутентификация на основе сертификатов X.509

Сертификаты X.509 сейчас чаще всего используются в SSL/TLS. При подключении к Web-серверу по протоколу SSL/TLS при помощи HTTPS, а не HTTP, или к серверу электронной почты посредством SSL/TLS приложение проверяет подлинность сервера. Для этого стандартное имя, извлеченное из сертификата сервера, сравнивается с именем компьютера, к которому подключается приложение. При несовпадении этих имен приложение предупредит пользователя о том, что, возможно, данное подключение ошибочно.

Я уже обращал ваше внимание на тот факт, что SSL/TLS по умолчанию позволяют выполнять аутентификацию сервера. Кроме того, на этапе согласования по протоколу SSL/TLS есть необязательная стадия проверки подлинности клиента на основе клиентских сертификатов. Чтобы эта возможность заработала, клиентское ПО должно иметь один или более клиентских сертификатов X.509, выданных центром сертификации, которому доверяет сервер.

Одна из самых перспективных реализаций клиентских сертификатов - смарт-карты - устройства размером с кредитку, на которых хранятся один или более сертификатов и связанные с ними закрытые ключи. В Windows 2000/XP поддержка смарт-карт встроена в ОС. На данный момент Windows поддерживает один сертификат и один закрытый ключ на каждую смарт-карту.

Подробно о сертификатах X.509, аутентификации клиентов, доверии и выпуске сертификатов рассказано в книге «Designing Secure Web-based Applications for Microsoft Windows 2000» (Microsoft Press, 2000) (М. Ховард, М. Леви, Р Веймир Разработка защищенных Web-приложений на платформе Microsoft Windows 2000. Мастер-класс. СПб: «Питер»; М.: «Русская Редакция», 2001).

Проблемы, связанные с именами в сертификатах

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

Но здесь возможны затруднения, так как у сервера может быть несколько корректных имен, например NetBIOS-имя \\Northwind, DNS-имя http://www.-northwindtraders.com или IP-адрес 172.30.121.14. Все эти имена правомочны. Если в сертификате указано DNS-имя, то при доступе по альтернативным именам возникает ошибка. Хотя сервер именно тот, который нужен, клиентское ПО не признает альтернативные имена правильными.

ПротоколIPSec

IPSec немного отличается от уже рассмотренных протоколов тем, что предусматривает только аутентификацию серверов. Kerberos также поддерживает проверку подлинности одних серверов другими, но в отличие от него IPSec не позволяет выполнять аутентификацию пользователей. IPSec предусматривает больше возможностей, чем простая аутентификация серверов: он также поддерживает целостность данных и конфиденциальность (об этом позже). Windows 2000/XP обладают встроенной поддержкой IPSec.

RADIUS

Многие серверы, в том числе Microsoft Internet Authentication Service (IAS), поддерживают службу RADIUS (Remote Administration Dial-In User Service) - стандарт де-факто для аутентификации удаленных пользователей, определенный в RFC 2058. В качестве базы данных аутентификации в Windows 2000 выступает служба каталогов Active Directory.

Авторизация

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

Windows поддерживает много механизмов авторизации, в том числе:

списки управления доступом (Access control lists, ACL);

привилегии;

IP-ограничения;

серверные разрешения.

Списки управления доступом

Все объекты в Windows NT/2000/XP можно защитить посредством списков ACL. ACL- это набор записей управления доступом (access control entries, ACE), каждая из которых определяет, какие действия по отношения к ресурсу разрешены участнику безопасности. Например, пользователю Блейк (Blake) разрешены чтение и запись объекта, а Шерил (Cheryl) может читать, записывать данные и создавать новые объекты.

Примечание ACL-списки подробно описаны в главе 6.

Привилегии

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

Примечание Принципы привилегий рассматриваются в главе 7.

IP-ограничения

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

Серверные разрешения

На многих серверах применяют собственные виды управления доступом для защиты своих объектов. Так, Microsoft SQL Server поддерживает разрешения, определяющие порядок доступа к таблицам, хранимым процедурам и представлениям. Приложения, основанные на COM+, поддерживают роли, или классы пользователей, для набора компонентов с одинаковыми правами доступа к наборам объектов. Роль определяет, каким пользователям разрешено вызывать интерфейсы компонента.

Технологии защиты от несанкционированного доступа и обеспечения конфиденциальности

Множество сетевых протоколов поддерживают защиту от несанкционированного доступа, а также конфиденциальность данных. Защита от несанкционированного доступа подразумевает способность защитить данные от удаления или изменения, как случайного, так и преднамеренного. Пользователю Блейку, который отправил пользователю Люку заказ на 10 самосвалов, вряд ли понравится, что кто-то изменит заказ в пути, увеличив число самосвалов до 20. Секретность означает то, что никто кроме Блейка и Люка просмотреть и изменить заказ не сможет. Windows поддерживает следующие протоколы и технологии для защиты от несанкционированного доступа и обеспечения конфиденциальности:

 SSL/TLS;
 IPSeC;

DCOM и RPC;

 EFS.
SSL/TLS

Протокол SSL разработан компанией Netscape в середине 90-х. Он обеспечивает шифрование данных, пересылаемых между клиентом и сервером, и использует MAC-коды (Message Authentication Code) для гарантии целостности данных. TLS - это версия SSL, утвержденная группой IETF (Internet Engineering Task Force).

IPSec

Я уже говорил, что IPSec поддерживает аутентификацию, шифрование для конфиденциальности данных и MAC-коды для целостности данных. Весь трафик между поддерживающими ^ес серверами шифруется и проверяется на целостность. Для использования преимуществ IPSec никакой дополнительной настройки приложений не нужно, так как IPSec реализован на IP-уровне сетевого стека TCP/IP

DCOM и RPC

Механизмы DCOM и RPC поддерживают аутентификацию, конфиденциальность и целостность. Если не использовать их для пересылки огромного объема данных, то на производительности работа DCOM и RPC сказывается мало. Подробнее - в главе 16.

Шифрующая файловая система EFS

В Windows, начиная с версии 2000, есть шифрующая файловая система EFS (Encrypting File System) - технология шифрования файлов, встроенная в файловую систему NTFS. Если SSL, TLS, IPSec и DCOM/RPC защищают данные при передаче, то EFS шифрует и гарантирует целостность файлов на диске.

Защищайте секретные данные, а лучше вообще не храните их

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

Шифрование, хеши, MAC-коды и цифровые подписи

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

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

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

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

В Windows есть готовый криптографический API-интерфейс CryptoAPI (Cryptographic API) для создания приложений с поддержкой шифрования, хеширования, создания MAC-кодов и цифровых подписей.

Примечание Шифрование, хеши и цифровые подписи подробно рассматриваются в главе 8.

Аудит

Цель аудита, иногда его называют журналированием (logging), состоит в сборе информации об успешных и неудачных попытках доступа к объектам, использования привилегий и других важных с точки зрения безопасности действий, а также регистрации этой информации для дальнейшего анализа в защищенном журнале. В Windows аудит реализован в виде журнала событий Windows, Web-журналов IIS и журналов иных приложений, в том числе SQL Server и Exchange.

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

Фильтрация, управление входящими запросами и качество обслуживания

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

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

Минимальные привилегии

Всегда используйте привилегии, как раз достаточные для выполнения задачи и не более того. Этой теме посвящена глава 7 целиком.

Особенности моделирования опасностей | Защищенный код | Устранение опасностей, грозящих приложению расчета зарплаты


Защищенный код



Новости за месяц

  • Июль
    2021
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс