Локальная безопасность Windows 2000 Advanced Server

Безопасность Windows 2000 основана на аутентификации пользовате­лей. Проходя процедуру входа в систему (обеспечиваемую процес­сом WinLogon), пользователь идентифицирует себя компьютеру, после чего ему предоставляется доступ к открытым и запрещается доступ к закрытым для вас ресурсам.

В Windows 2000 также реализованы учетные записи групп. Когда учет­ная запись пользователя входит в учетную запись группы, установлен­ные для учетной записи группы разрешения действуют также и для учетной записи пользователя.

Учетные записи пользователей и групп действуют только на том компь­ютере под управлением Windows 2000, на котором они создаются. Эти учетные записи локальны для компьютера. Единственным исключени­ем из этого правила являются компьютеры, входящие в домен и по­этому принимающие учетные записи, созданные в Active Directory на контроллере домена. На каждом компьютере под управлением Windows 2000 существует свой собственный список локальных учетных записей пользователей и групп. Когда процессу WinLogon (который регистрирует пользователя в систе­ме и устанавливает его вычислительную среду) требуется обратиться к базе данных безопасности, он взаимодействует с Security Accounts Manager (диспетчер учетных записей безопасности, SAM), компонен­том операционной системы Windows 2000, который управляет инфор­мацией о локальных учетных записях. Если информация хранится локально на компьютере под управлением Windows 2000, SAM обра­тится к базе данных (хранимой в реестре) и передаст информацию процессу WinLogon. Если информация хранится не локально SAM запросит контрол­лер домена и вернет подтвержденную информацию о регистрации (идентификатор безопасности, security identifier) процессу WinLogon.

Независимо от источника аутентификации, доступ разрешен только к локальному компьютеру посредством Local Security Authority (локаль­ные средства безопасности, LSA) компьютера. При обращаении к другим компьютерам в сети, LSA локального компьютера передает идентификационные данные пользователя LS А другого компьютера, реализуя вход в систему каждого компьютера, с которым он контактирует. Чтобы получить доступ к другому компьютеру, этот компьютер должен принять идентификационные данные, предоставленные компьютером пользователя.

 

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

Принципалы безопасности, такие как пользователи и компьютеры, представлены в системе идентификаторами безопасности (security identifier, SID). SID уникально идентифицирует принципала безопас­ности для всех компьютеров домена. При создании учетной записи при помощи оснастки Local Users and Groups (Локальные пользователи и группы), всегда создается новый SID, даже если используется такие же имя учетной записи и пароль, как в удаленной учетной запи­си. SID будет оставаться с учетной записью в течение всего времени ее существования. Можно поменять любой другой атрибут учетной записи, включая имя пользователя и пароль, но в обычных обстоятельствах нельзя изменить SID, поскольку при этом создается новая учетная запись.   

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

Процесс WinLogon (часть процесса Local Security Authority) проверяет имя пользователя и пароль (или смарт-карту при соответствующей конфигурации), чтобы определить, можно ли разрешить доступ к компьютеру. Если указанный в диалоговом окне входа в систему домен является именем локального компьютера, LSA проверит учетную запись в соответствии с локальным SAM, хранимым в реестре. В ином случае LSA установит связь с контроллером домена и воспользуется для проверки подлинности данных пользователя аутентификацией Kerberos (в случае Windows 2000) или NLTM (в случае всех остальных версий Windows, включая Windows 2000 в режиме Mixed Mode), в зависимости от операционной системы клиента.

Если имя учетной записи и пароль правильны, процесс WinLogon coздаст токен доступа. Токен доступа (Acess Token) образуется из SIDучетной записи пользователя, SID групп, к которым принадлежит, учетная запись, и Locally Unique Identifier (локально уникальный; идентификатор, LUID), который определяет права пользователя и конкретный сеанс входа в систему.

Токен доступа создается при каждом вашем входе в Windows 2000.

Существуют особые идентификаторы SID. System SID зарезервирован для системных служб, содержащие System SID токены доступа могут, обходить все ограничения безопасности, основанные на учетных записях. SID дает системным службам разрешение на осуществление тех; действий, которые обычная учетная запись пользователя (даже учетная запись Administrator (Администратор)) делать не может. Службы операционной системы запускаются ядром Windows 2000, а не процессом WinLogon, и эти службы получают System SID от ядра при своем запуске.

Доступ к ресурсам

Потоки (thread, отдельные ветви выполнения процесса) должны пре­доставлять токен доступа при каждой попытке доступа к ресурсу. Потоки получают токены доступа от родительских процессов при своем создании. Пользовательское приложение, например, обычно получает свой токен доступа от процесса WinLogon. Процесс WinLogon запускается от возбужденного пользователем прерывания (прерыва­ния клавиатуры Ctrl+Alt+Del) и может создать новый токен доступа, запрашивая или локальный диспетчер учетных записей безопасности (SAM), или Directory Services Agent (агент служб каталога, DSA) на контроллере домена Active Directory.

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

Основу безопасности Windows 2000 образует перемещаемый вход в систему (mandatory logon). В отличие от других сетевых систем, пользователь ничего не может сделать в Windows 2000, не предоставив имя учетной записи пользователя и пароль. Хотя можно выбрать автоматический вход в систему с идентификационными данными, предоставляемыми реестром, вход в систему при помощи учетной записи пользователя все равно происходит.

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

Поскольку токен доступа передается новому потоку во время его со­здания, то после входа пользователя в систему в дальнейшем нет необ­ходимости обращаться для аутентификации к локальной базе данных SAM или к Active Directory на контроллере домена.

При локальном входе пользователя в систему Windows 2000 проходит через следующие этапы.

1. Пользователь нажимает Ctrl +A1t+Del, что вызывает аппаратное пре­рывание, активизирующее процесс WinLogon.

2. Процесс WinLogon представляет пользователю приглашение ко входу в систему с полями для имени учетной записи и пароля.

3. Процесс WinLogon отправляет имя учетной записи и зашифро­ванный пароль локальным средствам безопасности (LSA). Если учетная запись локальна для этого компьютера Windows 2000, LSA запрашивает диспетчер учетных записей безопасности (SAM) локального компьютера Windows 2000; в другом случае LSA за­прашивает контроллер домена того домена, в который входит ком­пьютер.

4. Если пользователь представил допустимые имя пользователя и па­роль, LSA создает токен доступа, содержащий SID учетной записи пользователя и идентификаторы SID для групп, в которые входит пользователь. Токен доступа также получает LUID, который бу­дет описан далее в этой главе в разделе «Права или разрешения». Токен доступа затем передается обратно процессу WinLogon.

5. Процесс WinLogon передает токен доступа подсистеме Win32 вместе с запросом на создание процесса входа в систему для пользователя.

6. Процесс входа в систему устанавливает окружение пользователя, включая запуск Windows Explorer и отображение фона и значков рабочего стола.

 

Объекты и Разрешения

Windows 2000 поддерживает безопасность для различных типов объек­тов, включая (но не ограничиваясь ими) каталоги, файлы, принтеры, процессы и сетевые общие папки. Каждый объект предоставляет функ­ции, определяющие действия, которые могут быть выполнены для этого объекта, например: открыть, закрыть, читать, записывать, уда­лять, запускать, останавливать, печатать и т. д.

Информация безопасности для объекта содержится в дескрипторе без­опасности (security descriptor) объекта. Дескриптор безопасности со­стоит из четырех частей: владелец, группа, Discretionary Access Control List (список разграничительного контроля доступа, DASL) и System Acess Control List (системный список контроля доступа, SACL). Win­dows 2000 использует эти части дескриптора безопасности в следую­щих целях:

• владелец — эта часть содержит SID учетной записи пользователя-владельца объекта. Владелец объекта всегда может изменить на­стройки DACL (разрешения) объекта;

• группа — эта часть используется подсистемой POSIX Windows 2000. Файлы и каталоги в операционных системах UNIX могут принад­лежать групповой учетной записи, так же как и отдельной учетной записи пользователя. Эта часть содержит SID группы этого объек­та в целях совместимости с POSIX, а также для идентификации основной группы для учетных записей пользователя;

• Discretionary Access Control List — DACL содержит список учет­ных записей пользователя и учетных записей групп, обладающих разрешением на доступ к службам объекта. В DACL существует столько записей контроля доступа, сколько существует учетных записей пользователей или групп, для которых доступ к объекту был задан специально;

• System Acess Control List — SACL также содержит записи управ­ления доступом (АСЕ, access control entry), но эти записи АСЕ ис­пользуются для аудита, а не для разрешения или запрещения до­ступа к функциям объекта. SACL содержит столько записей АСЕ, сколько существует учетных записей пользователей или групп, для которых специально проводится аудит.

Каждая запись управления доступом в DACL или SACL состоит из идентификатора безопасности, сопровождаемого маской доступа. Маска доступа (access mask) в DACL определяет те функции объекта, для доступа к которым у SID есть разрешение. Специальный тип за­писи контроля доступа, называемый запрещающей записью АСЕ (deny АСЕ), указывает, что весь доступ к объекту будет запрещен для учет­ной записи, определенной идентификатором SID. Запрещающая АСЕ перекрывает все остальные записи АСЕ. Разрешение No Access (нет доступа) в Windows 2000 реализовано при помощи запрещающей за­писи АСЕ.

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

Записи управления доступом в SACL образуются тем же способом, что и записи в DACL (они составляются из SID и маски доступа), но мас­ка доступа в этом случае определяет те функции объекта, для которых будет проводиться аудит у этой учетной записи.

Не у каждого объекта есть списки DACL или SACL. Файловая систе­ма FAT, например, не записывает информацию безопасности, поэто­му у объектов файлов и каталогов, хранимых на томе FAT, нет спис­ков DACL и SACL. Когда DACL отсутствует, любая учетная запись пользователя обладает доступом ко всем функциям объекта. Это не равнозначно ситуации, когда список DACL объекта пуст. В этом слу­чае ни одна учетная запись не будет иметь доступа к объекту. Когда у объекта отсутствует SACL, аудит объекта невозможен.

Процессы не обращаются напрямую к таким объектам, как файлы, ка­талоги или принтеры. Операционная система Windows 2000 (а имен­но ее часть Win32) обращается к объектам от лица процессов. Основ­ная цель этого — сделать программы проще. Программа не обязана знать, как непосредственно манипулировать каждым типом объекта, она просто просит об этом операционную систему. Еще одним важным преимуществом, особенно с точки зрения безопасности, является то, что, поскольку операционная система выполняет все действия для про­цессов, она может принудительно отслеживать безопасность объектов.

Когда процесс просит подсистему Win32 выполнить действие над объектом (например, прочитать файл), подсистема Win32 сверяется с Security Reference Monitor (монитор проверки безопасности), чтобы удостовериться, что процесс обладает разрешением на осуществление действия над объектом. Security Reference Monitor сравнивает токен доступа процесса со списком DACL объектов, сверяя каждый SID в токене доступа с идентификаторами SID в списке DACL Если существу­ет запись управления доступом (АСЕ) с совпадающим SID, которая содержит маску доступа, разрешающую действие, и нет АСЕ с совпа­дающим SID, содержащей запрещающую маску для действия над объектом, то Security Reference Monitor разрешает подсистеме Win32 выполнить действие.

Security Reference Monitor также проверяет, осуществляется ли аудит доступа к объекту и требуется ли запись в журнал событий Security Log (Безопасность) Windows 2000. Аудит проверяется точно так же, как и проверка разрешений, — путем сравнения каждого SID в токене досту­па с SID каждой записи управления доступом. При обнаружении со­впадения монитор проверяет, принадлежит ли выполняемое действие (или функция) к перечисленным в маске доступа. Если да и если ре­зультат проверки безопасности по списку SACL совпадает с проводи­мым аудитом (произошел отказ в доступе и проводится аудит отказа в доступе, или доступ был успешен и проводится аудит успешного до­ступа, или произошли оба этих события), то в этом случае событие аудита записывается в журнал событий.

Некоторые действия применяются не к конкретному объекту, а к груп­пе объектов или ко всей операционной системе. Завершение работы с операционной системой, например, повлияет на все объекты в систе­ме. Пользователь должен обладать правами пользователя (user rights) для осуществления таких действий.

Средства Local Security Authority включают локально уникальный идентификатор (LUID) при созда­нии токена доступа. LUID описывает, какое из прав пользователя име­ет конкретная учетная запись. Local Security Authority создают LUID на основе информации о безопасности в базе данных диспетчера без­опасности учетных записей (для учетной записи локального компьюте­ра) или Active Directory (для учетной записи домена). LUID является объединением прав этой конкретной учетной записи пользователя и прав всех групп, в которые входит эта учетная запись.

Права имеют больший приоритет, чем разрешения (permissions). Вот почему учетная запись администратора может стать владельцем файла, чей владелец удалил все разрешения на доступ; Administrator (Админист­ратор) обладает правом Take Ownership of Files or Other Objects (сме­на владельца файлов или других объектов). Операционная система Win­dows 2000 вначале проверяет права пользователя и затем (если нет права пользователя, специально разрешающего действие) сверяет записи АСЕ, хранимые в DACL, с идентификаторами SID в токене доступа.

Учетные записи пользователя обладают правом на чтение и запись для объекта, для которого они являются владельцем, даже в случае нали­чия у того запрещающей записи АСЕ. Учетная запись пользователя может также изменять разрешения для принадлежащего ей объекта.

 

Файловая система NTFS

Файловая система NTFS — главный бастион безопасности Windows 2000. Безопасный компьютер под управлением Windows 2000 работает на платформе NTFS, образующей основу для постоянной безопасности.

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

Рассмотрим случай проникновения вируса на компьютер с Windows 95. Пользователь выполняет программу, содержащую вирус. Вирус опре­деляет, какая программа запустила текущую программу, и заражает ее, таким образом распространяя себя далее на один уровень. При следую­щем запуске этой программы вирус сделает то же самое, а также заразит каждую программу, порожденную этой программой. Через несколько циклов вирус распространится до ключевых программ операционной системы, таким образом заражая каждый выполняемый в ней файл. Рассмотрим теперь случай, когда пользователь выполняет зараженную вирусом программу в Windows 2000. Эта программа пытается записать свой вирусный заголовок в explorer.exe, но блокируется средствами без­опасности файловой системы NTFS, потому что у пользователя нет разрешений на запись в explorer.exe. Благодаря NTFS этот тип вирусов моментально останавливается Windows 2000. При попадании в систему некоторым вирусам удается выжить в пользовательском режиме (на­пример, макровирусам Word или червям Outlook), но эти вирусы все равно не могут заразить саму операционную систему — если только ви­рус не был запущен с учетной записью, обладающей административным доступом к компьютеру.

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

По умолчанию Windows 2000 находится в состоянии, предоставляющем полный доступ группе «все» (everyone) для корня всех дисков, вследствие чего все разрешения, наследуемые создаваемы­ми там файлами, также доступны для всех. Для получения какой-либо реальной пользы от безопасности файловой системы NTFS для при­ложений и хранимых пользователями файлов необходимо удалить разрешение, предоставляющее полный доступ для всех, и заменить его разрешениями с соответствующим уровнем безопасности для каждой папки на компьютере.

Управление разрешениями файловой системы NTFS осуществляется просто и работает аналогично тому; как разрешения устанавливались в предыдущих версиях Windows NT.

В Windows 2000 наследование обрабатывается по-другому, чем в Win­dows NT. В Windows NT унаследованные разрешения были просто таки­ми же, как у родительских объектов, и могли быть немедленно измене­ны. В Windows 2000, если объект наследует разрешения от содержащей объект папки, необходимо снять флажок Allow Inheritable Permissions (Переносить наследуемые от родительского объекта разрешения на этот объект), для того чтобы создать копию наследуемых разрешений и затем изменить существующие разрешения. Можно создавать новые записи АСЕ, не перекрывая установку безопасности.

 

Предыдущая12345678Следующая

Поделиться:

Воспользуйтесь поиском по сайту: