На страже безопасностиПрыжки по островам: смягчение проблемы нежелательных зависимостей

Йеспер М. Йоханссон

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

«социальной инженерии»). Атака не вышла за пределы рабочей станции, но было ясно, что вредоносные программы могли распространиться по всей сети. Я подробно рассказываю о такой форме атаки на сеть в моей (готовящейся к изданию) книге «Windows Server 2008 Security Resource Kit» («Набор ресурсов безопасности Windows Server 2008») (изд-во Microsoft Press®, 2008 г.), и для этой статьи используются части соответствующей главы этой книги.

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

Вдобавок, съемные носители являются далеко не единственным способов взлома клиентского компьютера. Помните о «10 непреложных законах безопасности» (доступных на microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx)? Основная идея закона 3 по-прежнему верна: «Если у злоумышленника есть неограниченный физический доступ к вашему компьютеру – это уже не ваш компьютер». В контексте данной темы, если у хакера имеется доступ к вашему компьютеру, компьютер следует считать взломанным. Это может быть осуществлено и с удаленного компьютера, если пользователь запустит его код на своем компьютере. В этом можно узнать первый из непреложных законов: «Если злоумышленник убедил вас запустить его программу на вашем компьютере – это уже не ваш компьютер».

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

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

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

Зависимость безопасности возникает, когда безопасность одного компьютера зависит от безопасности другого. Нередко говорится, что если взломан контроллер домена (domain controller – DC), то взломана и вся сеть. Это упрощенный способ заявить, что безопасность всех членов домена зависит от DC. Если не обеспечена безопасность DC, невозможно обеспечить безопасность их компьютеров. Если злоумышленник может изменять настройку безопасности домена, он может взять под контроль любой компьютер в домене, например, добавляя новые записи к группе администраторов на компьютере его члена. Уязвимости, допускающие вредоносные действия со стороны администратора, просто неинтересны. Предполагается, что у администратора имеется полный доступ ко всему, что он администрирует.

Зависимости в компьютерных системах неизбежны. На деле, они распространены и часто желаемы, но это не значит, что все зависимости приемлемы. В этом выпуске рубрики я расскажу, какие типы зависимостей приемлемы, а какие нет, после чего проанализирую типы зависимостей и способы их смягчения. В Windows Server 2008 Security Resource Ki я рассмотрю конкретные зависимости и управление ими более подробно.

Приемлемые зависимости

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

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

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

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

Неприемлемые зависимости

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

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

Рассмотрим это с точки зрения статистики. Если каждый компьютер в сети надежно защищен в течение 99,999% от времени своей работы, может показаться, что сеть отлично защищена. На деле, такой процент вероятно совершенно нереален во всех современных сетях, кроме мельчайших. Но предположим теперь, что в сети имеется 40,000 компьютеров, из которых каждый уязвим в течение 0,001% от времени своей работы. Можно отметить, что сеть в целом будет потенциально уязвима на протяжении 40% времени своей работы.

И, само собой, при наличии неуправляемых зависимостей один компьютер, атакованный в тот самый 0,001% времени, может открыть для таки всю сеть. Насколько защищенной она тогда является? Ясно, что защита более важных систем от менее важных совершенно необходима.

То же можно сказать об учетных записях пользователей и ПО. Например, новый клиент служб терминалов для Windows® позволяет хранить имена пользователей и пароли для практически прозрачного входа через службы терминалов. Эти учетные данные хранятся с использованием интерфейса API управления учетными данными, защищенного учетными данными, использованными основным сеансом входа в систему.

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

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

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

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

Анализ атаки

Ранее я описал, что может произойти при вставке вредоносного съемного накопителя в компьютер. Однако возможно, что очевидны только последствия для компьютера, в который вставлен накопитель. Так что предположим, что этот компьютер присоединен к домену, как показано на Рис. 1.

Рис. 1** Идеальные зависимости домена **

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

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

Рис. 2** Рискованные зависимости домена **

Простое изменение того, кто работает на каком из компьютеров, поставило под угрозу безопасность всей сети. Поскольку администратор домена входит в систему на сервере, безопасность DC и, следовательно, безопасность всего домена зависит от безопасности этого сервера.

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

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

В этой статье я представил только короткий обзор зависимостей, управления ими и их смягчения. Дополнительные сведения можно будет найти в моей книге, Windows Server 2008 Security Resource Kit. Она включает целую главу, посвященную вопросу обеспечения безопасности среды посредством анализа зависимостей и управления ими с использованием как изощренных методик, скажем изоляции серверов и доменов, так и более привычных методов, таких как управление учетными записями администраторов.

Я хотел бы поблагодарить Дэвида ле Бланка (David LeBlanc), который помог обрести форму зародышам идей, из которых выросла эта статья.

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

© 2008 Корпорация Майкрософт и компания CMP Media, LLC. Все права защищены; полное или частичное воспроизведение без разрешения запрещено.