Share via

Усовершенствования в системе безопасности Windows 2008 (R2) Failover Cluster

  • Article

  • Замена учетной записи кластерной службы

  • Использование CNO и VCO

  • Использование Kerberos для аутентификации

  • Защита межузловых коммуникаций

    Замена учетной записи кластерной службы

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

    Теперь служба кластера работает, используя учетную запись локальной системы (Service-SID) с определенным набором прав на локальном узле кластера, которые позволяют ей правильно функционировать. (См. https://blogs.technet.com/b/askperf/archive/2008/02/03/ws2008-windows-service-hardening.aspx, https://msdn.microsoft.com/en-us/library/ms143504.aspx).

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

    Теперь он (Service SID) может явно указываться в списках контроля доступа (ACLs) к ресурсам, которые принадлежат только сервису и, тем самым, запретить доступ к этим же ресурсам другого сервиса. Он может быть присвоен в ходе установки приложения через вызов ChangeServiceConfig2 API или после установки с использованием утилиты SC.EXE, используя ее команду sidtype с различными ключами:

    • None (0x0) - Сервис не будет иметь Service-SID. Это установка по умолчанию.
    • Unrestricted (0x1) - Сервис будет иметь Service SID.
    • Restricted (0x3) - Сервис будет иметь Service-SID и маркер доступа ограничивающий запись

    Для измения свойств Service-SID необходимо использовать команду:

    sc sidtype <service name> <restricted | unrestricted> 

    Если вы хотите просмотреть конфигурацию сервиса, выполните команду:

    sc qsidtype <service name>

    В чем преимущество данного подхода?

    Посмотрите ниже приведенные рисунки.

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

    Использование CNO, VCO и CAP

    Контекст безопасности для кластера перенесен на объект имени кластера (Cluster Name Object – CNO), являющийся объектом-компьютером, создаваемым по умолчанию в контейнере Computers (Компьютеры) Active Directory® в момент создания кластера. После того, как кластер успешно создан, и CNO существует в Active Directory, учетная запись пользователя, использовавшаяся для установки и настройки кластера, более не нужна.

    Дополнительные объекты-компьютеры, создаваемые (по умолчанию, хотя это можно изменить) в контейнере Computers (Компьютеры) Active Directory, связаны с отказоустойчивым кластером. Эти объекты, именуемые объектами виртуальных компьютеров (Virtual Computer Object – VCO), приравниваются к ресурсам сетевого имени кластера, создаваемыми как часть точек доступа клиента (Client Access Points – CAP этот объект ранее, до Windows 2008, назывался Virtual Server) в кластере. CNO ответственен за создание всех VCO в Active Directory и добавляется к системному списку управления доступом (System Access Control List – SACL) всех VCO.

    При создании кластера CNO создается от имени пользователя, создающего кластер, следовательно этот пользователь должен иметь право на создание компьютерных объектов (Computer Object) в Active Directory. По умолчанию любой пользователь может создать 10 компьютерных объектов в Active Directory, поэтому (если это не запрещено), то он может создать 10 CNO. Для увеличения этого количества пользователю необходимо дать разрешение, Подробно о создании и модификации CNO можно прочесть https://technet.microsoft.com/en-us/library/cc731002(v=ws.10).aspx.

    Объект CNO может быть предварительно создан администратором домена и помещен в нужную папку. Для этого необходимо:

    • Создать объект с именем будущего кластера.
    • Перевести этот объект в состояние Disable
    • Да разрешения компьютерному объекту (CNO) Create Computer objects и Read All Properties. Этот пункт необходимо выполнить поскольку далее все VCO будут создаваться от имени CNO (в данном случае CLUSTER1)

     

    • Дайте разрешение Full Control на созданный вами CNO пользователю, который далее будет выполнять развертывание кластера.

     CNO также берет на себя ответственность за синхронизацию паролей домена со всеми созданными им объектами VCO. Этот процесс выполняется в соответствии с настроенной для домена политикой ротации паролей. Вдобавок, поскольку объект CNO ответственен за создание всех компьютерных объектов в кластере, связанных с объектами VCO, объект CNO (учетная запись кластера) должен иметь права уровня домена для создания объектов компьютера в контейнере, где создаются объекты VCO (по умолчанию, это контейнер Computers (Компьютеры)).

    Объект VCO может быть предварительно создан администратором домена и помещен в нужную папку. Для этого необходимо:

    • Создать объект с именем будущего сервиса или приложения.
    • Установите разрешение Full Control на созданный вами VCO учетной записи компьютерного объекта кластера.

    Если вы случайно удалили CNO или VCO, то:

    Использование Kerberos для аутентификации

    Kerberos теперь используется как метод проверки подлинности по умолчанию. Эта улучшенная функция безопасности становится возможной благодаря наличию учетных записей компьютеров в Active Directory. Но кластер имеется возможность использовать проверку подлинности протокола NT LAN Manager (NTLM), если приложению, не способному использовать для проверки подлинности Kerberos, понадобится доступ к ресурсам кластера.

    Однако для того, что бы использовать Kerberos, у вас должны быть созданы SPN для кластера и SPN-ы для приложений и сервисов.

    Проверить созданы ли SPN-ы можно с помощью утилит SETSPN.EXE и ADSIEdit.exe. 

    C:\>setspn -L CLUS-W2k12$
    Registered ServicePrincipalNames for CN=CLUS-W2K12,CN=Computers,DC=demo,DC=local:
            MSServerCluster/Clus-W2k12.demo.local
            MSServerCluster/Clus-W2k12
            MSServerClusterMgmtAPI/Clus-W2k12.demo.local
            MSServerClusterMgmtAPI/Clus-W2k12
            MSClusterVirtualServer/Clus-W2k12.demo.local
            MSClusterVirtualServer/Clus-W2k12
            HOST/Clus-W2k12.demo.local
            HOST/Clus-W2k12

    При размещении на Windows кластере приложения или сервиса (например SQL Server) необходимо будет выполнить регистрацию SPN-ов для него.

    Правила создания SPN-ов для SQL Server приведены здесь. (https://technet.microsoft.com/en-us/library/ms191153.aspx)

    Защита межузловых коммуникаций

    В кластере Windows 2008 (R2), была реализована более безопасна связь между узлами кластера, напрямую имеющими дело с процессом кластера. По умолчанию, все сообщения внутри кластера подписываются, используя цифровую подпись. Через командную строку Cluster.exe или PowerShell это свойство кластера может быть изменено так, чтобы, для предоставления дополнительного уровня безопасности коммуникаций, шифровались все сообщения между узлами.

    Это может быть особенно полезно при использовании геораспределенных кластеров, работающих через Internet.

     Изменение также возможно через CLUSTER.EXE или PowerShell.

     Изменения, внесенные в систему безопасности, повысили степень безопасности использования кластера и снизили риски администрирования, связанные с заменой паролей учетных записей, что часто приводило к остановке функционирования кластера.

    В кластере под управлением Windows 2012 сделаны дополнительные инвестиции в систему безопасности, что сделало использование этого кластера еще более удобным. 

     

    Александр Каленик, Senior Premier Field Engineer (PFE), MSFT (Russia)