Материалы о рабочей средеРасставаясь с администратором

Уэс Миллер (Wes Miller)

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

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

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

Как мы дошли до этого?

Мой вызов читателям: прочувствуйте все на себе

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

То, что большинство пользователей действуют как администраторы, коренится в истории Windows®. В первых версиях Windows, до Windows NT® 3.1, каждый из интерактивных пользователей имел те же права, что и остальные – безопасности, по сути, не существовало. Для домашних систем это было не столь уж ужасно; это просто значило, что все программное обеспечение устанавливается одинаково. Предположение состояло в том, что пользователь владел компьютером и что все ПО устанавливалось для всех пользователей на этом компьютере.

При первом появлении Windows NT она явно не смогла сразу завладеть корпоративным рынком (не говоря уж о потребительском). А в силу совместимости Win32® между 32-разрядной версий Windows и Windows NT большинство поставщиков приложений не перестраивали свои приложения лишь ради инфраструктуры безопасности Windows NT. По сути, лишь с появлением Windows 2000 многие из ориентированных на потребителя независимых поставщиков ПО начали обращать внимание на Windows NT. Проблему вывела на первый план Windows XP, закончившая семейство Windows 9х.

Но приложения по-прежнему выпускались исходя из предположения, что каждый пользователь в системе имеет разрешение на запись в Program Files (пользователи не имеют), а также HKEY_LOCAL_MACHINE (HKLM) в реестре (пользователи не имеют) и HKEY_CLASSES_ROOT (пользователи не имеют). Особенно плохо в плане предположений о наличии доступа дело обстоит у игр; см. статью Мэтта Клэпэма (Matt Clapham) на эту тему по адресу technetmagazine.com/issues/2007/02/Gaming.

Это представляет проблему, поскольку многие межсистемные приложения хранят свои файлы и параметры реестра в этих местах, и для их установки необходим доступ на чтение и запись в эти места. Увы, некоторые приложения настаивают на записи в эти разделы после установки. Например, у моей дочери есть игра на основе Flash. Она пытается установить нестандартный проигрыватель при каждом запуске – а это значит, что когда моя дочь работает как пользователь, а не как администратор, приложение не запускается, выдавая неустранимую ошибку. Хотя это и крайний пример, да и речь идет о потребительском приложении, в реальности большинство непотребительских приложений не работают как следует при использовании пользователями, не являющимися администраторами. На самом деле, те, кто принял мой вызов (см. врезку «Мой вызов читателям: прочувствуйте все на себе»), могут обнаружить, насколько сама Windows нетерпима к работе в качестве пользователя.

Если взглянуть на рис. 1, можно увидеть, как выполнение IPConfig /release в качестве пользователя выглядит на Windows XP. Если сравнить это с рис. 2, можно заметить, что та же команда под Windows Vista выглядит немногим лучше, но, по крайней мере, можно понять причину ее сбоя. Отметьте, что средства работы с сетью в целом улучшены, чтобы позволить пользователям обновлять свои IP-адреса. Аналогично, попытка запуска окна управления компьютером (compmgmt.msc) в качестве пользователя позволяет выполнять ограниченный набор задач в обеих версиях – но обычно приводит к раздражающим тупикам, как показывает рис. 3. Хотя в Windows Vista изначально многие из средств в этом окне отсутствуют изначально, она предоставляет более четкие сообщения об отказе в доступе.

Figure 1** Running as a user under Windows XP **(Щелкните изображение, чтобы увеличить его)

Figure 2** Running as a user under Windows Vista **(Щелкните изображение, чтобы увеличить его)

Figure 3** Misleading message after running compmgmt.msc as a user on Windows XP **(Щелкните изображение, чтобы увеличить его)

Почему это имеет значение

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

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

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

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

Устранить опытных пользователей?

Когда мы разрабатывали Protection Manager, одним из комментариев от клиентов было: «На Windows XP у нас все пользователи работают как опытные пользователи, а не как администраторы, так что мы в безопасности». На деле, однако, опытные пользователи стоят лишь в нескольких шагах от администраторов. Существует несколько потенциальных дыр, которые при небольшом усилии позволяют опытному пользователю Windows XP стать администратором. В реальности группа опытных пользователей была устранена на Windows Vista и Windows Server® 2008; она будет иметься только в системе, обновленной с предыдущей версии Windows. В общем, использования группы опытных пользователей всегда следует избегать, даже если используется Windows XP.

Полномочия с потерями

Те, кто читал мою мартовскую статью о тонких клиентах Windows (technetmagazine.com/issues/2008/03/DesktopFiles), могут вспомнить, что я выступал против идеи утончения Windows XP для сохранения места. В том же ключе, существует обычная практика перевода администраторов в пользователи, которую необходимо будет рассмотреть, причем рассмотреть внимательно. Это практика изменения списков контроля доступа на реестре и файловой системе с предоставлением пользователям возможности записи в места, куда они обычно производить ее не могут – что делает возможной работу проблемных приложений.

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

Как насчет UAC?

Рассказ о переводе администраторов в пользователи не может быть полон без обсуждения контроля учетных записей пользователей (User Account Control – UAC) в Windows Vista. UAC, подобно похожим функциям в Mac OS X, позволяет работать «как администратору», но не подвергая себя настолько большому риску.

Как это осуществляется? Взгляните на рис. 4, на котором в проводнике по процессам показана программа cmd.exe. Экземпляр cmd.exe справа был запущен без повышения прав, когда я работал как администратор. Как следствие, хотя пользователь справа идентичен пользователю слева (где cmd.exe был запущен с повышением прав), само приложение не содержит необходимых прав и маркеров для того, чтобы оно (и пользователь, использующий этот экземпляр) могло выполнять задачи, требующие административных прав. UAC работает, понижая область, открытую для атак, внутри интерактивного контекста пользователя. Единственная проблема состоит в том, что системеWindows должно быть как-то указано, что этой задаче требуются административные права и что пользователь согласен с повышением прав, необходимым для ее выполнения.

Figure 4** Two instances of cmd.exe with different privileges **(Щелкните изображение, чтобы увеличить его)

Маленькие щиты в Windows Vista показывают, какие именно задачи требуют повышения прав (см. рис. 5). Эти задачи требуют повышения прав при каждом их запуске – и это одно из больных мест, которые пресса решила выделить в случае Windows Vista. Альтернатива, допуск более «постоянных» учетных данных, является потенциальной угрозой безопасности, которую можно использовать для упрощения использования брешей в безопасности системы.

Figure 5** Shields in Windows Vista indicate the need for elevation **(Щелкните изображение, чтобы увеличить его)

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

Работа на Windows Vista в качестве пользователя?

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

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

Работа на Windows Vista в качестве пользователя не так уж отличается от работы на Windows XP в качестве пользователя. Я использую те же средства – PSExec, RunAs (а теперь и UAC) для выполнения задач в качестве администратора по мере необходимости. Здесь хорошо то, что немало задач, требовавших административных прав в Windows XP, более не требуют их. Например, пользователь Windows Vista может установить локальный принтер. (Сетевые принтеры могут быть установлены пользователями в Windows XP, но установка локального принтера требует административных прав.) В Windows Vista, пока пользователь физически сидит за машиной, а в хранилище драйверов находится драйвер принтера, он может установить принтер и управлять печатью на нем (дополнительные сведения приведены на странице go.microsoft.com/fwlink/?LinkId=111534). Обратите внимание, что в Windows Server 2008 эта функциональность отключена.

Само собой, пользователей изумляет функциональность часов (точнее, ее недостаток) при работе в качестве пользователя в Windows XP – попробуйте дважды щелкнуть часы, работая как пользователь (порой люди делают это, чтобы узнать дату вне зависимости от того, был ли этот компонент разработан для подобного использования или нет) – появится ошибка, показанная на рис. 6. Не слишком дружелюбно по отношению к пользователю. В Windows XP можно изменить политику, чтобы пользователи могли сделать это, но Windows Vista изменена, чтобы работать так изначально. Так что в целом работа в качестве пользователя, используется ли при этом UAC или работа ведется в качестве формального пользователя, а права повышаются в качестве другого, более терпима на Windows Vista, чем была на Windows XP.

Figure 6** In Windows XP, non-admins couldn't change the time **(Щелкните изображение, чтобы увеличить его)

Помните ограничения

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

Если пользователи работают как администраторы, обход любой групповой политики не составляет труда. Само собой, приложив небольшие дополнительные усилия, пользователи могут загрузится в Windows PE и изменить полномочия, для изменения которых у них обычно нету прав – хотя использование BitLocker либо другого шифрования диска/тома может сделать это невозможным или, как минимум, более сложным.

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

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

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

Вместо этого обьратите основное внимание на преимущества для безопасности организации и убедитесь, что у вас имеется основательный план для особых случаев, когда либо конкретный пользователь совершенно не может работать в качестве пользователя, либо имеется определенная задача, требующая прав администратора. Будете ли вы использовать что-то сделанное вручную, вроде моего сценария Run.vbs (который можно найти на technetmagazine.com/issues/2007/03/DesktopFiles) или коммерческое решение, помогающее осуществлять перевод (которое позволяет скрывать подробности от конечных пользователей, заставляя все «просто работать»), но начинать движение к избавлению от администраторов следует как можно скорее. Постоянный автор статей для журнала TechNet Magazine, Аарон Маргосис (Aaron Margosis) является настоящим проповедником работы не в качестве администратора. Тем, кто еще не знаком с его блогом, следует с ним познакомиться – это лучшее место для получения подробных сведений по этой теме (см. blogs.msdn.com/aaron_margosis)

Уэс Миллер (Wes Miller) на данный момент является старшим техническим руководителем продуктов компании CoreTrace (www.CoreTrace.com) в г. Остин, штат Техас. Ранее Уэс работал в компании Winternals Software, а также в корпорации Майкрософт в должности руководителя программы. Связаться с Уэсом Миллером можно по адресу technet@getwired.com.

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