Повышаем отказоустойчивость инфраструктуры

Рассел Смит (rms@russell-smith.net) — независимый ИТ-консультант, специализируется на управлении системами

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

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

Что такое зависимость объектов, влияющая на безопасность?

Контроллеры доменов, domain controllers (DC), обеспечивают безопасность всех устройств домена, поэтому из факта взлома DC сразу следует, что скомпрометированы все устройства домена. Некоторые аспекты безопасности конечных точек сети определяются контроллерами доменов, и такая зависимость вполне допустима. А теперь представим себе обратную зависимость — когда безопасность контроллера домена определяется конечной точкой. В этом случае мы имеем дело с зависимостью, которую необходимо устранить.

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

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

Защита важнейших элементов инфраструктуры от мошеннических систем

Случается, что домены Active Directory (AD) и важнейшие серверы той или иной компании вступают в контакт с системами, не подлежащими контролю администратора, — например, когда подрядчик подключает свой нетбук к вашей корпоративной сети. В таких случаях вы не можете быть уверены, что на подключенном устройстве установлены все модули коррекции, что оно защищено средством борьбы с вирусами и не заражено вредоносным программным обеспечением. Вы можете развернуть средства сетевой сегрегации, чтобы изолировать неизвестные и мошеннические устройства от важнейших систем своей компании — возможно, до тех пор, пока состояние последних не будет проверено с помощью систем управления сетевым доступом, таких, как система Microsoft Network Access Protection (NAP).

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

Устранение влияющих на безопасность нежелательных административных зависимостей и зависимостей, формируемых в процессе доступа

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

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

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

Лишение ИТ-специалистов службы поддержки прав администраторов домена

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

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

Воспользовавшись учетной записью с правом создавать группы в AD, откройте меню Start. Выделите пункты Administrative Tools и Active Directory Users and Computers. Создайте группу Desktop Administrators и добавьте в нее учетные записи ИТ-специалистов службы поддержки. На данном этапе вы можете также рассмотреть возможность исключения из данных записей привилегированных прав доступа, таких, как членство в группе Domain Admin.

Прошедшие проверку подлинности пользователи наделяются правом добавления к домену рабочих станций, так что члены группы Desktop Administrators могут добавлять к домену компьютеры. Но проблема состоит в том, что данное право лимитируется особой квотой, которая по умолчанию составляет 10 систем. Существует несколько способов обойти это препятствие. Чтобы иметь возможность заблаговременно создавать в AD учетные записи компьютеров, в контейнере Computers предоставьте ИТ-специалистам службы поддержки права Create Computer Objects и Delete Computer Objects или модифицируйте атрибут AD ms-DS-MachineAccountQuota. Более подробную информацию об упомянутых методах можно найти в статье Microsoft «Domain Users Cannot Join Workstation or Server to a Domain» (http://support.microsoft.com/?id=251335).

После того как вы примете решение, каким именно образом снять ограничение на включение в домен новых рабочих станций, можете настроить групповую политику так, чтобы сотрудники с правами Desktop Administrators были включены в число членов группы Administrators на ваших рабочих станциях. В разделе Administrative Tools меню Start найдите консоль управления групповыми политиками Group Policy Management Console (GPMC) и раскройте свой домен на левой панели экрана. Выберите организационную единицу, содержащую объекты вашего компьютера. Помните, что присоединение объекта «групповая политика» Group Policy Object (GPO) непосредственно к используемому по умолчанию контейнеру Computers не допускается, так что вам придется создать организационную единицу (OU) для объектов computer, если такая единица еще не сформирована. Щелкните на OU правой кнопкой мыши, в раскрывшемся меню выберите пункт Create a GPO in this domain and link it here, назначьте имя новому GPO и нажмите кнопку ОК.

В левой панели консоли GPMC щелкните на новом объекте GPO правой кнопкой мыши и выберите в контекстном меню пункт Edit. На экране появится окно редактора Group Policy Management Editor. В левой панели окна раскройте узлы Computer Configuration, Windows Settings Security Settings, затем правой кнопкой мыши щелкните на пункте Restricted Groups и выберите Add Group. В поле Add Group введите с клавиатуры «Administrators» и нажмите кнопку ОК. В окне Administrators Properties, представленном на экране 1, нажмите кнопку Add (ту, что расположена рядом с полем Members of this group) и введите имена групп локальных систем или учетных записей, входящих в состав группы local Administrators на вашей рабочей станции. Далее нажмите кнопку Browse и добавьте Domain Admins, а также Desktop Administrators. На каждой рабочей станции, к которой применяется данный объект GPO, групповая политика Restricted Groups фиксирует новый состав группы local Administrators. Если вам требуется более гибкий механизм управления, можете изменить настройки в предпочтениях групповых политик (Group Policy Preferences), чтобы членство в группах обновлялось, а не записывалось поверх старых данных. Нажмите кнопку ОК и закройте программу Group Policy Management Editor.

Экран 1. Настройка групповой политики Restricted Groups

Дождитесь, когда групповая политика будет обновлена на рабочих станциях или вручную выполните команду

gpupdate /force

на рабочей станции в организационной единице, с которой связан объект GPO. Вы увидите, что к группе local Administrators на этой рабочей станции добавлена группа Desktop Administrators, а используемые по умолчанию группы остаются без изменений.

Что такое кэшированные учетные данные и диспетчер учетных данных

В системе Windows кэшированные учетные данные хранятся в защищенном разделе системного реестра (HKEY_local_machine\security\cache). Функцию кэширования доменных учетных данных можно отключать, однако во всех сетях, кроме самых защищенных, такая операция создает исключительные неудобства — особенно для пользователей ноутбуков. Чтобы попасть в этот раздел реестра, нужно запустить редактор реестра с правами SYSTEM. Здесь я не буду объяснять, как это делается; даже если вы намерены удалить необходимые значения реестра, система Windows просто прекратит кэширование учетных данных. Значения реестра не рассчитаны на то, чтобы к ним обращались или удаляли их в ручном режиме, так что эти значения лучше всего оставить в покое.

Кэш не поддается очистке, однако вы можете удалять имена пользователей и пароли, защищенные с помощью API диспетчера учетных данных, что позволяет приложениям, таким как Remote Desktop Client, обеспечивать безопасное хранение учетных данных для каждого пользователя Windows. Чтобы оперативно добраться до представленного на экране 2 диалогового окна Stored User Names and Passwords, в окне командной строки введите символы

rundll32.exe keymgr.dll, KRShowKeyMgr

Экран 2. Диалоговое окно Stored User Names and Passwords

В этом диалоговом окне вы можете добавлять, удалять или редактировать учетные данные, а также при необходимости резервировать и восстанавливать их. Чтобы перейти к более современной версии интерфейса Windows 7, в панели управления выберите пункты User Accounts, Credentials Manager.

Учетные записи служб

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

В версии Windows Server 2008 R2 специалисты Microsoft реализовали управляемые учетные записи служб managed service accounts (MSA), которые функционируют подобно учетным записям компьютеров AD в том смысле, что пароли записей назначаются и переустанавливаются в автоматическом режиме. Эти учетные записи можно создавать только с помощью оболочки Windows PowerShell; они не имеют совместимости со всеми службами сторонних производителей. Управляемые учетные записи служб должны быть установлены на компьютере. По замыслу разработчиков, они могут ассоциироваться только с одним устройством, а значит не могут использоваться в сценариях, предусматривающих переход на другой ресурс кластера при сбое. В процессе настройки службы, ориентированной на работу с управляемой учетной записью, поля паролей следует оставлять незаполненными. Более подробные сведения о конфигурировании подобных учетных записей можно найти в статье «Управление учетными записями служб с помощью MSA», опубликованной в Windows IT Pro/RE № 8 за 2010 год. Отметим, что в следующей версии Windows Server — Windows Server 8 — будут реализованы групповые MSA, и упомянутые ограничения будут сняты.