Третьего ноября этого года в Sysinternals был закрыт проект по развитию NewSID – утилиты, позволяющей менять идентификатор защиты компьютера (machine SID). Я написал NewSID (тогда она называлась NTSID) в 1997 году, поскольку на тот момент единственной программой, позволявшей менять SID, была утилита от Microsoft под названием Sysprep, которая не поддерживала смену идентификаторов защиты на тех машинах, на которых уже были установлены приложения.

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

Причиной, по которой я начал рассматривать возможность отправки NewSID на покой, были отзывы пользователей. Хотя в целом применение утилиты на Windows Vista было успешным, некоторые пользователи сообщали об ошибках в работе компонентов системы после использования NewSID. К тому же, сам я не проводил ее полного тестирования. Когда я принялся за изучение отзывов, я сделал шаг назад, чтобы понять, как дублированные SID могут становиться причинами проблем, поскольку раньше я принимал возможность этого на веру, как и все остальные. И чем больше я об этом думал, тем крепче была моя убежденность, что дублирование сертификатов безопасности, то есть наличие множества компьютеров с одинаковыми SID, само по себе не может быть причиной для возникновения проблем с безопасностью или чем-нибудь еще. Я поделился своими мыслями с командами разработчиков Windows, занимающимися безопасностью и развертыванием систем, и там никто не смог придумать такую последовательность действий, при которой две системы с одинаковыми SID, работающие в пределах рабочей группы или домена, могли бы стать причиной ошибки. С этого момента решение закрыть NewSID стало очевидным.

Я понимаю, что новость о том, что в наличии дублированных SID нет ничего страшного, станет для многих неожиданностью, особенно если учесть, что практика смены идентификаторов безопасности при развертывании систем из образов применяется еще со времен Windows NT. Эта статья разоблачает миф об опасности дублирования SID, и чтобы его развеять, я сначала объясню, что же такое идентификаторы безопасности компьютера и как они используются Windows, после чего продемонстрирую, что за одним исключением, Windows никогда не показывает идентификаторы безопасности вне компьютера, а потому иметь машины с одинаковыми SID абсолютно нормально.

Идентификаторы безопасности (SID)

Windows использует идентификаторы SID для представления не только машин, а вообще всего пространства имен System Security Principal, частью которого являются машины, учетные записи домена, пользователей и групп безопасности. Их имена - лишь более понятные для пользователей формы представления SID, позволяющие например переименовать учетную запись без необходимости обновлять для отображения внесенных изменений ссылающиеся на эту учетную запись списки управления доступом (ACL). Идентификатор SID - это числовое значение переменной длины, формируемое из номера версии структуры SID, 48-битного кода агента идентификатора и переменного количества 32-битных кодов субагентов и/или относительных идентификаторов (RID). Код агента идентификатора (identifier authority value) определяет агент, выдавший SID. Таким агентом обычно является локальная система или домен под управлением Windows. Коды субагентов идентифицируют попечителей, уполномоченных агентом, который выдал SID, a RID — не более чем средство создания уникальных SID на основе общего базового SID.

Увидеть, что собой представляет SID машины можно, если воспользоваться утилитой PsGetSid, запущенной через командную строку без параметров:

В этом SID номер версии равен 1, код агента идентификатора - 5, а далее идут коды четырех субагентов. Одно время в Windows NT идентификатор SID мог использоваться для идентификации компьютера в сети, поэтому для обеспечения уникальности при генерировании SID в Windows Setup он содержит один фиксированный (21) и три генерируемых случайным образом (числа после "S-1-5-21") кода субагентов.

Еще перед тем, как вы создадите первую учетную запись в системе, Windows определяет несколько встроенных пользователей и групп, включая учетные записи "Администратор" и "Гость". Вместо того, чтобы генерировать новые случайные идентификаторы SID для этих учетных записей, Windows обеспечивает их непохожесть, просто добавляя в SID уникальные для каждой учетной записи числа, называемые относительными идентификаторами (Relative Identifier, RID). Для упомянутых выше встроенных учетных записей RID определены заранее, поэтому у пользователя "Администратор" RID всегда равен 500:

После установки системы Windows назначает новым локальным учетным записям пользователей и групп номера RID, начинающиеся со значения 1000. Чтобы увидеть имя учетной записи, которой принадлежит указанный SID, можно воспользоваться PsGetSid. Пример внизу демонстрирует, что локальный SID с параметром RID, равным 1000, принадлежит учетной записи Abby - аккаунту администратора, имя которого система обязала меня ввести во время установки:

Плюс к этим динамически создаваемым SID, система определяет несколько аккаунтов, которые также всегда имеют предопределенные значения SID. Один из примеров – группа Everyone, SID которой в каждой системе Windows имеет значение S-1-1-0:

Другой пример - учетная запись Local System, под которой выполняются некоторые системные процессы, такие как Session Manager (Smss.exe), Service Control Manager (Services.exe) и Winlogon (Winlogon.exe):

Идентификаторы безопасности и списки управления доступом (ACL)

После того, как пользователь вошел в систему Windows под своей учетной записью, подсистема локальной авторизации (Local Security Authority Subsystem, Lsass.exe) создает сессию входа и маркер для нее. Маркер - это структура данных, которую ядро Windows определяет для представления учетной записи и которая содержит в себе SID этой учетной записи, а также SID групп, к которым принадлежит данная учетная запись на момент входа в систему и назначенные для этой учетной записи и групп привилегии безопасности. Когда последний маркер, ссылающийся на сессию входа, удаляется, LSASS удаляет и сессию входа, после чего пользователь считается вышедшим из системы. Ниже можно увидеть информацию о моей интерактивной сессии входа, отображенную с помощью утилиты Sysinternals LogonSessions:

А здесь (в окне Handle Process Explorer) можно увидеть информацию о маркере, который Lsass создал для этой сессии. Обратите внимание, что число, следующее за именем учетной записи (7fdee), соответствует идентификатору входной сессии из LogonSessions:

По умолчанию процессы наследуют копию маркера своего родительского процесса.

Так, каждый процесс, запущенный в моей интерактивной сессии, имеет копию маркера, изначально унаследованного им от процесса Userinit.exe, который первым создается Winlogon при каждом интерактивном входе в систему. Вы можете посмотреть содержимое маркера процесса, сделав двойной щелчок на строке процесса в Process Explorer и переключившись на вкладку Security в диалоговом окне свойств процесса:

Когда один из моих процессов открывает объект операционной системы, например, файл или ключ системного реестра, подсистема безопасности осуществляет проверку прав доступа, в ходе которой сверяются те записи в списке управления доступом (ACL) объекта, которые ссылаются на SID, находящийся в маркере процесса.

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

Дублирование SID

Пропагандируемый Microsoft способ создания установки Windows, пригодный для развертывания системы на группы компьютеров, заключается в установке Windows на эталонный компьютер и подготовке системы к клонированию с помощью утилиты Sysprep. Этот метод называется "обобщением образа", поскольку при его загрузке Sysprep персонализирует установку, генерируя новый SID компьютера, определяя имеющиеся аппаратные средства, сбрасывая счетчик активации и устанавливая прочие настройки, в том числе – имя компьютера.

Однако, некоторые IT-администраторы сначала ставят Windows на одну из своих систем, устанавливают и настраивают приложения, а затем используют такие средства развертывания, которые не сбрасывают SID на установочных образах Windows. До сих пор наилучшим средством в таких ситуациях было использование утилит для смены SID, таких как NewSID. Эти утилиты генерируют новый идентификатор безопасности машины, а затем пытаются обновить его во всех мыслимых местах, включая файловую систему и списки управления доступом в реестре. Причина, по которой Microsoft не поддерживает подобный способ изменения системы, довольно проста – в отличие от Sysprep, сторонние утилиты могут и не знать обо всех тех местах, где Windows хранит идентификатор безопасности компьютера. А раз так, то и надежность компьютера, на котором имеется и старый и новый SID, не может быть гарантирована.

Так что же, можно считать проблемой наличие нескольких машин с одинаковыми SID? Только в одном случае - если Windows при каких-либо обстоятельствах ссылается на SID других компьютеров. К примеру, если во время подключения к удаленной системе SID локального компьютера был передан на одну из удаленных систем и использовался там для проверки прав доступа, тогда дублированный идентификатор SID мог бы стать причиной наличия бреши в системе безопасности, поскольку удаленная машина не смогла бы отличить SID удаленной учетной записи от аналогичного SID локальной учетной записи (при условии, что в идентификаторах совпадают и SID компьютера, и RID). Однако как мы отмечали, Windows не позволяет пройти аутентификацию на удаленном компьютере, используя учетную запись, известную только локальному компьютеру. Вместо этого необходимо указать либо входные параметры, являющиеся локальными для удаленной системы, либо параметры учетной записи домена, считающегося доверенным для удаленной системы. Удаленный компьютер получает SID для локальной учетной записи в своей собственной базе данных учетных записей (SAM), а сведения об аккаунте домена об берет в базе Active Directory на контроллере домена. Удаленный компьютер никогда не предоставляет SID компьютера подключающейся машине.

Другими словами, не SID предоставляет доступ к компьютеру, а имя пользователя и пароль учетной записи: одно лишь знание SID учетной записи на удаленной машине не позволит получить доступ к компьютеру или его ресурсам. Чтобы еще раз убедиться в этом, достаточно вспомнить тот факт, что встроенные учетные записи (например, Local System) имеют одинаковые SID на любом компьютере, что могло бы стать серьезной уязвимостью, если бы доступ основывался на SID.

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

В целом ряде статей, посвященных дублированию SID, включая эту статью из базы знаний Microsoft, содержится предупреждение, что наличие у нескольких компьютеров одинаковых SID приводит к тому, что ресурсы на сменных носителях (например, на отформатированных в NTFS внешних дисках) не могут быть защищены средствами локальной учетной записи. Однако в них упускается из виду то обстоятельство, что права доступа на таких накопителях защитить не получится в любом случае, поскольку подсоединить их можно к такой машине, которой безразличны права доступа NTFS. Более того, сменные накопители чаще всего используют права доступа по умолчанию, позволяющие осуществлять доступ хорошо известным идентификаторам SID (группы "Администраторы", к примеру), одинаковым на любой системе. Это фундаментальное правило физической защиты, поэтому в Windows 7 включена функция Bitlocker-to-Go, позволяющая зашифровывать данные на сменных носителях.

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

Новая лучшая политика

Удивительно, что дублирование SID так долго считалось не подлежащей обсуждению проблемой лишь потому, что все думали, что кому-то об этом точно известно. К моему сожалению, на самом деле NewSID никогда не была по-настоящему полезной утилитой, и скучать по ней теперь нет никакого смысла. Официальная политика Microsoft по данному вопросу тоже изменится, поэтому можно рассчитывать на то, что в будущих версиях Sysprep этап генерации SID будет пропущен.