• утилизация ресурсов (Resource Utilization) для физических пространств дисков. Это требование реализуется файловой системой NTFS в Windows 2000;
• блокировка интерактивного сеанса (Interactive Session Locking) и путь доверительных отношений (Trusted Path) для первоначального входа пользователя (initial user logging on). Это требование реализуется компонентом Winlogon в Windows 2000;
• защита внутренней передачи данных (Internal Data Transfer Protection), чтобы обезопасить данные от раскрытия и несанкционированной модификации при передаче между физически раздельными частями системы Windows 2000 как распределенной операционной системы. Это требование реализуется службой IPSEC в Windows 2000;
• систематическое устранение обнаруживаемых недостатков в системе защиты (Systematic Flaw Remediation). Это требование реализуется Microsoft Security Response Center и Windows Sustained Engineering Team.
Ha момент написания этой книги Windows XP Embedded, Windows XP Professional и Windows Server 2003 все еще проходили оценку на соответствие Common Criteria. Набор критериев расширен по сравнению с тем, который применялся к Windows 2000. Комитет Common Criteria в настоящее время рассматривает Windows XP и Windows Server 2003 (Standard, Enterprise и Datacenter Edition) для оценки технологий следующих типов (см. niapnist.gov/cc-scheme/in_evaluation.htmt)\
• распределенной операционной системы;
• защиты конфиденциальных данных;
• управления сетью;
• службы каталогов;
• брандмауэра;
• VPN (Virtual Private Network);
• управления рабочим столом;
• инфраструктуры открытого ключа (Public Key Infrastructure, PKI);
• выдачи и управления сертификатами открытого ключа; • встраиваемой операционной системы.
Ниже перечислены главные компоненты и базы данных, на основе которых реализуется защита в Windows.
• Монитор состояния защиты (Security Reference Monitor, SRM) Компонент исполнительной системы (\Windows\System32\ Ntoskrnl.exe), отвечающий за определение структуры данных маркера доступа для представления контекста защиты, за проверку прав доступа к объектам, манипулирование привилегиями (правами пользователей) и генерацию сообщений аудита безопасности.
• Подсистема локальной аутентификации (local security authentication subsystem, LSASS) Процесс пользовательского режима, выполняющий образ \Windows\System32\Lsass.exe, который отвечает за политику безопасности в локальной системе (например, крут пользователей, имеющих право на вход в систему, правила, связанные с паролями, привилегии, выдаваемые пользователям и их группам, параметры аудита безопасности системы), а также за аутентификацию пользователей и передачу сообщений аудита безопасности в Event Log. Основную часть этой функциональности реализует сервис локальной аутентификации Lsasrv (\Windows\System32\Lsasrv.dll) — DLL-модуль, загружаемый Lsass.
• База данных политики LSASS База данных, содержащая параметры политики безопасности локальной системы. Она хранится в разделе реестра HKLM\SECURITY и включает следующую информацию: каким доменам доверена аутентификация попыток входа в систему, кто имеет права на доступ к системе и каким образом, кому предоставлены те или иные привилегии и какие виды аудита следует выполнять. База данных политики LSASS также хранит «секреты», которые включают в себя регистрационные данные, применяемые для входа в домены и при вызове Windows-сервисов (о Windows-сервисах см. главу 5).
• Диспетчер учетных записей безопасности (Security Accounts Manager, SAM) Набор подпрограмм, отвечающих за поддержку базы данных, которая содержит имена пользователей и группы, определенные на локальной машине. Служба SAM, реализованная как \Windows\System32\ Samsrv.dll, выполняется в процессе Lsass.
• База данных SAM База данных, которая в системах, отличных от контроллеров домена, содержит информацию о локальных пользователях и группах вместе с их паролями и другими атрибутами. Ha контроллерах домена SAM содержит определение и пароль учетной записи администратора, имеющего права на восстановление системы. Эта база данных хранится в разделе реестра HKLM\SAM.
• Active Directory Служба каталогов, содержащая базу данных со сведениями об объектах в домене. Домен — это совокупность компьютеров и сопоставленных с ними групп безопасности, которые управляются как единое целое. Active Directory хранит информацию об объектах домена, в том числе о пользователях, группах и компьютерах. Сведения о паролях и привилегиях пользователей домена и их групп содержатся в Active Directory и реплицируются на компьютеры, выполняющие роль контроллеров домена. Сервер Active Directory, реализованный как \Windows\System32\Ntdsa.dll, выполняется в процессе Lsass. Подробнее об Active Directory см. главу 13.
• Пакеты аутентификации DLL-модули, выполняемые в контексте процесса Lsass и клиентских процессов и реализующие политику аутентификации в Windows. DLL аутентификации отвечает за проверку пароля и имени пользователя, а также за возврат LSASS (в случае успешной проверки) детальной информации о правах пользователя, на основе которой LSASS генерирует маркер (token).
• Процесс входа (Winlogon) Процесс пользовательского режима (\Windows\System32\Winlogon.exe), отвечающий за поддержку SAS и управление сеансами интерактивного входа в систему. Например, при регистрации пользователя Winlogon создает оболочку — пользовательский интерфейс.
• GINA (Graphical Identification and Authentication) DLL пользовательского режима, выполняемая в процессе Winlogon и применяемая для получения пароля и имени пользователя или PIN-кода смарт-карты. Стандартная GINA хранится в \Windows\System32\Msgina.dll.
• Служба сетевого входа (Netlogon) Windows-сервис (\Windows\System32 \Netlogon.dll), устанавливающий защищенный канал с контроллером домена, по которому посылаются запросы, связанные с защитой, например для интерактивного входа (если контроллер домена работает под управлением Windows NT), или запросы на аутентификацию от LAN Manager либо NT LAN Manager (vl и v2).
• Kernel Security Device Driver (KSecDD) Библиотека функций режима ядра, реализующая интерфейсы LPC (local procedure call), которые используются другими компонентами защиты режима ядра — в том числе шифрующей файловой системой (Encrypting File System, EFS) — для взаимодействия с LSASS в пользовательском режиме. KsecDD содержится в \Windows\System32\Drivers\Ksecdd.sys.
Ha рис. 8–1 показаны взаимосвязи между некоторыми из этих компонентов и базами данных, которыми они управляют.
ЭКСПЕРИМЕНТ: просмотр содержимого HKLM\SAM и HKLM\Security
Дескрипторы защиты, сопоставленные с разделами реестра SAM и Security, блокируют доступ по любой учетной записи, кроме Local System. Один из способов получить доступ к этим разделам — сбросить их защиту, но это может ослабить безопасность системы. Другой способ — запустить Regedit.exe под учетной записью Local System; такой способ поддерживается утилитой PsExec (wwwsysinternals.com), которая позволяет запускать процессы под этой учетной записью:
C:›psexec — s — i — d c: \windows\regedit.exe
SRM, выполняемый в режиме ядра, и LSASS, работающий в пользовательском режиме, взаимодействуют по механизму LPC (см. главу 3). При инициализации системы SRM создает порт SeRmCommandPort, к которому подключается LSASS. Процесс Lsass при запуске создает LPC-порт SeLsaCommandPort. K этому порту подключается SRM. B результате формируются закрытые коммуникационные порты. SRM создает раздел общей памяти для передачи сообщений длиннее 256 байтов и передает его описатель при запросе на соединение. После соединения SRM и LSASS на этапе инициализации системы они больше не прослушивают свои порты. Поэтому никакой пользовательский процесс не сможет подключиться к одному из этих портов.