Обеспечение безопасности служебных и важных учетных записей

Управление учетными записями служб

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

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

Анализ и документирование среды

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

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

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

•	Средство управления службами (sc.exe). Эта программа командной строки входит в состав операционных систем Windows Server 2003 и Windows XP. С ее помощью легко работать с диспетчером управления службами из командной строки, запрашивая и устанавливая свойства служб.
•	Средство управления списком служб (sclist.exe). В состав набора Windows 2000 Server Resource Kit входит средство вывода списка запущенных и остановленных служб локального или удаленного компьютера. Программа Sclist.exe используется для определения служб, запущенных на удаленных серверах, которые не оснащены мониторами или географически удалены от администратора.
•	Инструментарий управления Windows (WMI). Данный компонент входит в состав Windows Server 2003 и Windows XP. Он предоставляет данные, необходимые для управления корпоративной сетью, и обеспечивает контроль над ней. Администраторы используют инструментарий WMI для запроса и установки данных на компьютерах, в сетях, приложениях и службах. В дополнение к возможности использования сценариев для управления административными задачами, инструментарий WMI позволяет определять зависимости служб и все службы, от которых зависят эти службы.
•	Командная строка инструментария управления Windows (WMIC). Инструментарий WMI также содержит программу командной строки WMIC, которая предоставляет простой интерфейс командной строки к инструментарию WMI для выполнения запросов и удаленного управления компьютером. Результаты запросов WMIC можно выводить в формате таблиц HTML, которые можно просматривать в любом обозревателе, например в Internet Explorer.

Соблюдение принципа предоставления наименьших привилегий

В корпорации Майкрософт понимают важность безопасности и то, какую значительную роль играет принцип предоставления наименьших привилегий в обеспечении безопасности сетевой среды. Корпорация Майкрософт применила принцип предоставления наименьших привилегий в разработке операционной системы Windows Server 2003, чтобы обеспечить использование основными службами операционной системы учетных записей с наименьшими привилегиями и избавить таким образом пользователей от необходимости настраивать эти службы. При использовании этого подхода внимание должно быть сосредоточено на обеспечение безопасности служб, которые не входят в операционную систему, например поставляемых в качестве компонентов других продуктов, таких как Microsoft SQL Server, Microsoft Operations Manager или программные продукты других производителей.

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

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

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

Соблюдение принципа наименьшего количества служб

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

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

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

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

Развертывание и управление

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

Управление важными учетными записями и учетными записями администраторов

Для обеспечения безопасности учетных записей администраторов в сети Microsoft Windows можно применять несколько рекомендуемых подходов. Ниже перечислены часто используемые в корпоративных сетях среднего размера и хорошо зарекомендовавшие себя способы борьбы с уязвимостями, связанными с такими учетными записями.

Разделение ролей администратора домена и администратора предприятия

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

•

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

•

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

Разделение учетных записей пользователя и администратора

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

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

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

Использование службы «Вторичный вход в систему»

С помощью команды «Запуск от имени...» операционной системы Microsoft Windows 2000 можно запускать программы, используя учетную запись, отличную от той, с помощью которой осуществлен вход в систему. В Windows Server 2003 и Windows XP Professional аналогичная функция получила название службы вторичного входа в систему.

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

Использование раздельных сеансов служб терминалов для администрирования

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

Переименование стандартной учетной записи «Администратор»

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

Создание ложных учетных записей администратора

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

Создание вторичных учетных записей администратора и отключение встроенных учетных записей

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

Примечание.    Следует обязательно убедиться в наличии другой учетной записи с соответствующими привилегиями администратора перед отключением встроенной учетной записи «Администратор». Без этого отключение встроенной учетной записи администратора может привести к потере прав администратора домена и потребовать восстановления или переустановки системы.

Блокировка удаленных входов в систему под учетной записью «Администратор»

Хотя встроенную учетную запись администратора нельзя заблокировать, можно заблокировать удаленный вход в систему с использованием учетной записи администратора. Для этого в наборе Microsoft Windows 2000 Server Resource Kit имеется программа командной строки Passprop.exe, которая блокирует учетную запись для удаленного входа в систему. Использование этой программы командной строки с параметром /ADMINLOCKOUT подводит интерактивный и удаленный вход в систему с помощью учетной записи администратора под действие политик блокировки Windows 2000 Server.

Примечание.    Использование команды Passprop.exe /ADMINLOCKOUT в Windows Server 2003 затронет удаленный и интерактивный вход в систему с учетной записью администратора. При работе с этой программой следует соблюдать осторожность, поскольку использование учетной записи администратора для администрирования сервера невозможно, пока она находится в заблокированном состоянии.

Создание надежных паролей администратора

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

•	Содержит 15 или более знаков.
•	Никогда не содержит имен учетных записей, реальных имен или имени компании в любом виде.
•	Никогда не содержит полных слов, жаргонных терминов или иных удобных для подбора элементов.
•	Радикальным образом отличается от предыдущих паролей и не создается путем приращения.
•	Используют по крайней мере три из следующих типов знаков: • прописные буквы (A, B, C...); • строчные буквы (a, b, c...); • цифры (0, 1, 2...); • знаки, не являющиеся буквами или цифрами (@, &, $...); • знаки из кодировки Юникод (?, ƒ, ?...).

Автоматическое обнаружение ненадежных паролей

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

•	Оперативная проверка паролей. При оперативной проверке производятся попытки входа в систему с помощью общеизвестных уязвимостей пароля, например использование слова password в качестве пароля или даже использование пустых паролей. Анализатор безопасности Microsoft Baseline Security Analyzer (MBSA) является примером средства, использующего такой метод.
•	Автономная проверка паролей. При автономной проверке используются различные механизмы, использующие кэшированные учетные данные для проверки и даже оценки надежности паролей различных учетных записей. Средства, использующие такой подход, имеют ряд преимуществ перед предыдущим методом, но предполагают использование программ сторонних производителей.

Хотя сторонние средства и могут выполнять поиск ненадежных паролей, корпорация Майкрософт предоставляет анализатор безопасности Microsoft Baseline Security Analyzer (MBSA) для бесплатной загрузки. Анализатор безопасности MBSA может выдавать уведомления обо всех отключенных или заблокированных учетных записях, найденных при пересчете всех учетных записей пользователей для проверки паролей на наличие следующих уязвимостей:

•	пустые пароли;
•	использование имени пользователя в качестве пароля;
•	использование имени компьютера в качестве пароля;
•	использование слов password, admin или administrator в качестве пароля.

Дополнительные сведения см. на веб-странице анализатора безопасности Microsoft Baseline Security Analyzer (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Разрешение выполнения административных задач только надежным компьютерам

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

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

Дополнительные сведения об использовании протокола IPsec для изоляции доменов и серверов см. в техническом центре «Изоляция доменов и серверов» (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Аудит учетных записей и паролей

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

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

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

Запрет делегирования учетной записи

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

Учетные записи администратора должны иметь пометку «Важные учетные записи, которые нельзя делегировать». Такой подход помогает защитить учетные данные администраторов от имитации через серверы с пометкой о разрешении делегирования. Учетным записям компьютеров в службе каталогов Active Directory, соответствующим компьютерам, которые физически не защищены, должно быть отказано в делегированной проверке подлинности. Кроме того, учетным записям администраторов домена также должно быть отказано в делегированной проверке подлинности, поскольку они имеют доступ к важным данным и ресурсам сети.

Дополнительные сведения о делегировании учетной записи см. в документе «Включение делегированной проверки подлинности» (эта ссылка может указывать на содержимое полностью или частично на английском языке).

Обеспечение многофакторной проверки подлинности для учетных записей администраторов

Группы «Администраторы», «Администраторы предприятия» и «Администраторы домена» включают учетные записи, обладающие самыми широкими полномочиями в корпоративной сети. Соответственно, эти учетные записи должны быть защищены лучше всего.

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

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

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

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

Дополнительные сведения о методах мультифакторной проверки подлинности и смарт-картах см. в документе «Руководство по планированию безопасного доступа с использованием смарт-карт» (эта ссылка может указывать на содержимое полностью или частично на английском языке).