Все знают, что один из наиболее важных принципов сетевой безопасности заключается в том, чтобы предоставлять как можно меньше прав: предоставлять обычным пользователям только те права, которые непосредственно необходимы им для работы, и не более того. Например, если обычным пользователям не нужен доступ к данным, хранящимся в ресурсе Accounting, не давайте им никаких прав на этот ресурс.
Принцип «как можно меньше привилегий» — это больше чем принцип безопасности, это спасительное средство для администратора. Причина этого, заключается в том, что пользователи – это любопытные создания, которые пробуют все подряд. Дайте пользователю права локального администратора на их компьютер, и они попробуют все множество вещей, таких как установка дополнительного программного обеспечения, изменение конфигурационных настроек, и даже залезут в реестр, чтобы посмотреть, что там можно настроить для лучшей работы их компьютера. С точки зрения администратора это может быть катастрофой, т.к. неправильная настройка может повредить некоторые приложения, или даже вывести компьютер из строя. Затем пользователь начинает звать на помощь, и у вас как у администратора есть два варианта: либо очистить их машину и заново установить операционную систему со стандартного образа вашей компании, или бесполезно потратить время, часами пытаясь выявить причину проблемы. Второй вариант – это обычно пустая трата времени, в противоположность политике компании, пользователь сохранял важные файлы на своем компьютере и не на сетевом ресурсе. А первый вариант – это практически плевок против ветра, вы заново устанавливаете систему пользователя, а он снова беспрепятственно может ее вывести из строя.
Group Policy один из способов определения того, что может, а что не может пользователь делать со своим компьютером. Но что делать, если политики компании (или культурные или политические или другие реалии) требуют необходимость возможности для пользователя самостоятельно настраивать свою машину? В этом случае у вас есть два варианта, либо давать пользователям права локального администратора, либо нет. Т.к. первый вариант вызывает проблемы, о которых я рассказал выше, давайте рассмотрим возможности второго варианта.
Если вы выберите не делать учетную запись пользователя в домене локальным администратором на его машине, то пользователь начинает громко жаловаться на ряд причин, которые включают следующее:
Последние три жалобы достаточно легко обойти (я покажу это в свое время), но проблема невозможности установки программного обеспечения достаточно сложна по нескольким причинам. Во-первых, большинство программного обеспечения (включая многие приложения Microsoft) требуют права локального администратора для того, чтобы их можно было установить для любых версий Microsoft Windows. На основе этого мы сталкиваемся с фактом, что некоторым приложениям необходимо специальные области для записи в файловую систему и реестр. Но это ненастоящая причина того, что приложениям необходимы права администратора для установки—реальная причина заключается в том, что разработчики обычно слишком ленивы, чтобы позаботиться о создании пакетов для установки, которые будут также работать не под учетной записью администратора. Все это означает дополнительную работу для разработчика (которую большинство разработчиков стараются избежать). Но это также означает разработку этих приложений, работая также не под учетной записью администратора, что опять приводит к необходимости о многом позаботиться – гораздо проще разрабатывать приложение, когда вы вошли в систему, как администратор.
Так как же установить программное обеспечение, если у вас нет прав администратора на машину? Утомительный способ заключается в том, чтобы выйти из системы, зайти в нее с правами администратора, установить ваше программное обеспечение, выйти из системы, и снова зайти в нее, используя вашу обычную учетную запись, а затем начать использовать программное обеспечение, как обыкновенный пользователь. Более необычный способ – это использовать возможность повторного входа в систему (команда Runas.exe) Windows 2000 и выше. На файлах с расширением .exe (и файлах .msc или консольных) вы можете нажать правой кнопкой мыши на иконке и выбрать “Run as…”, а затем указать полномочия локального администратора для установки программы. К несчастью, возможность “Run as…” не появляется, когда вы нажимаете правую кнопку мыши на файлах .msi, но обходным путем здесь может быть использование команды Runas из окна командной строки (cmd.exe).
К несчастью, некоторые программы после того, как они были установлены с использованием команды Runas по прежнему не будут правильно работать, когда вы запустите их с правами обыкновенного пользователя. Это происходит потому, что когда вы используете команду Runas для установки чего-либо, некоторые важные настройки записываются в профиль локального администратора, а не в профиль пользователя, который вошел в систему в настоящий момент. И конечно, это вызывает проблемы, когда вы пытаетесь позже запустить установленное приложение как обычный пользователь. Опять же, разработчик, который написал программу, должен был позаботиться о решение этой проблемы, но зачем беспокоиться об этом, если все равно все запускают Windows с правами администратора?
Я сам сталкивался с такой проблемой несколько раз как с приложениями сторонних производителей, так и с приложениями .NET Framework, и это расстраивает. Например, недавно я хотел получить электронный курс по обучению разработке в ASP.NET от Microsoft. К несчастью, по некоторым причинам я не мог загрузить курс (само приложение .NET), если я входил в систему с использованием учетной записи пользователя домена, поэтому я открыл ссылку в Internet Explorer используя права локального администратора и благополучно загрузил курс. Но когда я попытался запустить курс локально на моей машине, он не запустился, когда я попытался это сделать с правами обычного пользователя. Поэтому я попытался использовать Runas, чтобы запустить курс с правами администратора, но он все равно не запустился. В конце концов, я вышел из системы, зашел с правами администратора для того чтобы начать работать. Кошмар! Может быть, если я исследовал проблему дальше, я бы выяснил почему это не работало с первого раза, но это хорошо иллюстрирует, почему большинство людей все время работают в Windows с правами администратора—если вы работаете не с правами администратора, вы можете потратить кучу времени, чтобы заставить вещи работать.
К тому же—и это то, что только недавно стало рассматриваться экспертами по безопасности—может оказаться, что вся эта проблема с минимумом привилегий, всего лишь отвлекающий маневр. Конечно, если вы зашли администратором, и вы идете в интернет, мимо различных гадких сайтов и загрузили вирус, то это вирус получит контроль над вашей системой с вашими собственными правами, т.е. с правами администратора. А если вы обычный пользователь, и заходите на тот же самый сайт, то вирус получает ограниченный доступ (уровень привилегий пользователя домена) к вашей системе, поэтому потенциальный вред будет уменьшен. В действительности все гораздо сложнее. Если вредоносный код, который вы загрузили – это червь, который использует слабость в службе Windows, то не важно под какой учетной записью вы зашли.
К тому же, умнейшие хакеры уже работают над созданием новых возможностей, благодаря которым хакерский код сможет захватить систему даже при работе в ней с минимальными правами. Поэтому выходящая возможность Least—privilege User Account (LUA) Longhorn (теперь Windows Vista), которая отказывается от устаревших групп Power Users и разрешает установку и запуск LUA-совместимых приложений с использованием прав обычных пользователей, в действительности не панацея для проблем безопасности, окружающих использование минимума привилегий. Вы может поспорить на свой последний доллар, что плохие парни найдут новые возможности для взлома вашей системы.
Поэтому, пока минимум привилегий – это неплохое решение. Но так не будет продолжаться долго. Но другими словами, вы можете по-прежнему рассматривать стратегию «минимум привилегий» как простое средство против хакеров.
Вернемся назад к списку жалоб наших обычных пользователей и поищем некоторые способы обхода проблем. Предположим, вы вошли как обычный пользователь и хотите открыть папку для общего доступа в вашей системе. Если вы откроете Windows Explorer (explorer.exe) и нажмете правой кнопкой на папке, то вы не увидите там закладки Sharing и не сможете этого сделать. Runas не работает с explorer.exe, потому что Explorer уже запущен для оболочки. К счастью существует обходной путь: используйте Runas, чтобы запустить (iexplore.exe) вместо Windows Explorer (explorer.exe). Когда откроется, наберите C:\ в адресной строке и нажмите на кнопку Folders на панели инструментов, неожиданно оно станет выглядеть так, словно вы запустил Windows Explorer. Теперь перейдите к папке, которую вы хотите открыть общий доступ, нажмите правую кнопку мыши и выберите Sharing and Security, далее все стандартно.
Пока мы здесь, заметьте, что дерево папок в IE отображает узел Control Panel. Выберите этот узел и в правом окне вы увидите апплеты Control Panel. Попробуйте изменить дату и время — это сработает! Т.к. IE запущен с правами администратора, все приложения, к которым вы обращаетесь с его помощью, включая Control Panel, также будут запускаться с этими правами. То же проходит и в случае с Power Options, Network Connections, System, и другими апплета, к которым вы имели ограниченный доступ, при работе не в качестве администратора.
Существует однако еще более простой способ (способ с IE работает, но немного путано, если iexplore.exe не в системной директории), для которого надо сделать следующее:
Теперь, когда вы зайдете опять как простой пользователь, вы можете нажать правую кнопку мыши на explorer.exe (или его ярлыке), выбрать “Run as…”, указать полномочия администратора, и Windows Explorer теперь запустится с правами администратора.
Запуск Windows не под учетной записью администратора – это сложная задача, и до тех пор, пока она вносит свои преимущества, можно терпеть все ее недостатки. К тому же, эти преимущества не такие большие, как говорят многие специалисты по безопасности, и они будут лишь работать до тех пор, пока плохие парни, не найдут новые способы обойти систему безопасности.
Какой вы имеет опыт в решении данной проблемы? А вы заставляете ваших пользователей работать не под учетными записями локальных администраторов? С каким трудностями вы при этом столкнулись? И как вы попытались решить эти проблемы? Напишете мне обо всем этом, и я соберу все ваши ответы в следующей статье на WindowsNetworking.com, где я вновь подниму проблему при работе не под учетной записью администратора.
www.windowsnetworking.com
Tags: Windows Vista