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

Работа с подсистемой безопасности в ОС Windows

1. Цель работы: изучить модель безопасности операционной системы Windows, получить навыки практического использования ее средств обеспечения безопасности.

 

2. Краткие сведения из теории:

Классификация защиты семейства ОС Windows

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

Так, например, версии Windows NT/2000 были сертифицированы по классу С2 критериев TSSEC («Оранжевая книга»). Требования к операционной системе, за­щищенной по классу С2, включают:

- обязательную идентификацию и аутентификацию всех пользователей опера­ционной системы. Под этим понимается способность операционной системы иден­тифицировать всех пользователей, которые получают санкционированный доступ к системе, и предоставление доступа к ресурсам только этим пользователям;

- разграничительный контроль доступа — предоставление пользователям воз­можности защиты принадлежащих им данных;

- системный аудит — способность системы вести подробный аудит всех дейст­вий, выполняемых пользователями и самой операционной системой;

- защита объектов от повторного использования — способность системы пре­дотвратить доступ пользователя к информации ресурсов, с которыми до этого ра­ботал другой пользователь.

ОС Microsoft Windows XP Professional (SP2/SP3) имеет действующие сертифи­каты ФСТЭК России и может использоваться в составе автоматизированных сис­тем до класса защищенности 1Г включительно в соответствии с требованиями ру­ководящего документа "Автоматизированные системы. Защита от несанкциониро­ванного доступа к информации. Классификация автоматизированных систем и тре­бований по защите информации" (Гостехкомиссия России, 1992).

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

Для защиты данных Windows использует следующие основные механизмы: аутентификация и авторизация пользователей, аудит событий в системе, шифрова­ние данных, поддержка инфраструктуры открытых ключей, встроенные средства сетевой защиты. Эти механизмы поддерживаются такими подсистемами Windows как LSASS (Local Security Authority Subsystem Service, подсистема локальной ау­тентификации), SAM (Security Account Manager, диспетчер локальных записей безопасности), SRM (Security reference Monitor, монитор состояния защиты), Active Directory (служба каталогов), EFS (Encrypting File System, шифрующая файловая система) и др.

Защита объектов и аудит действий с ними в ОС Windows организованы на основе избирательного (дискреционного) доступа, когда права доступа (чтение, за­пись, удаление, изменение атрибутов) субъекта к объекту задается явно в специ­альной матрице доступа. Для укрупнения матрицы пользователи могут объеди­няться в группы. При попытке субъекта (одного из потоков процесса, запущенного от его имени) получить доступ к объекту указываются, какие операции пользова­тель собирается выполнять с объектом. Если подобный тип доступа разрешен, по­ток получает описатель (дескриптор) объекта и все потоки процесса могут выпол­нять операции с ним. Подобная схема доступа, очевидно, требует аутентификации каждого пользователя, получающего доступ к ресурсам и его надежную идентифи­кацию в системе, а также механизмов описания прав пользователей и групп поль­зователей в системе, описания и проверки дискреционных прав доступа пользова­телей к объектам. Рассмотрим, как в ОС Windows организована аутентификация и авторизация пользователей.

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

S - R - I - S0 - S1 -... - Sn - RID

S - неизменный идентификатор строкового представления SID;

R - уровень ревизии (версия). На сегодня 1.

I - (identifier-authority) идентификатор полномочий. Представляет собой 48­битную строку, идентифицирующую компьютер или сеть, который(ая) выдал SID объекту. Возможные значения:

- 0 (SECURITY_NULL_SID_AUTHORITY) — используются для сравнений, когда неизвестны полномочия идентификатора;

- 1 (SECURITY_WORLD_SID_AUTHORITY) — применяются для конст­руирования идентификаторов SID, которые представляют всех пользовате­лей. Например, идентификатор SID для группы Everyone (Все пользовате­ли) — это S-1-1-0;

- 2 (SECURITY_LOCAL_SID_AUTHORITY) — используются для построе­ния идентификаторов SID, представляющих пользователей, которые вхо­дят на локальный терминал;

- 5 (SECURITY_NT_AUTHORITY) — сама операционная система. То есть, данный идентификатор выпущен компьютером или доменом.

Sn - 32-битные коды (колчеством 0 и более) субагентов, которым было пере­дано право выдать SID. Значение первых подчиненных полномочий общеизвестно. Они могут иметь значение:

- 5 — идентификаторы SID присваиваются сеансам регистрации для выдачи прав любому приложению, запускаемому во время определенного сеанса регистрации. У таких идентификаторов SID первые подчиненные полно­мочия установлены как 5 и принимают форму S-1-5-5-x-y;

- 6 —когда процесс регистрируется как служба, он получает специальный идентификатор SID в свой маркер для обозначения данного действия. Этот

идентификатор SID имеет подчиненные полномочия 6 и всегда будет S-1- 5-6;

- 21 (SECURITY_NT_NON_UNIQUE) — обозначают идентификатор SID пользователя и идентификатор SID компьютера, которые не являются уни­кальными в глобальном масштабе;

- 32 (SECURITY_BUILTIN_DOMAIN_RID) — обозначают встроенные идентификаторы SID. Например, известный идентификатор SID для встро­енной группы администраторов S-1-5-32-544;

- 80 (SECURITY_SERVICE_ID_BASE_RID) — обозначают идентификатор SID, который принадлежит службе.

Остальные подчиненные полномочия идентификатора совместно обозначают домен или компьютер, который издал идентификатор SID.

RID - 32-битный относительный идентификатор. Он является является иден­тификатором уникального объекта безопасности в области, для которой был опре­делен SID. Например, 500 — обозначает встроенную учетную запись Administrator, 501 — обозначает встроенную учетную запись Guest, а 502 — RID для билета на получение билетов протокола Kerberos.

При генерации SID Windows использует генератор случайных чисел, чтобы обеспечить уникальность SID для каждого пользователя. Для некоторого произ­вольного пользователя SID может выглядеть так:

S-1-5-21-789336058-484763869-725345543-1003

Предопределенным пользователям и группам Windows выдает характерные SID, состоящие из SID компьютера или домена и предопределенного RID. В таб­лице 1 приведен перечень некоторых общеизвестных SID.

Таблица 1. Общеизвестные SID Windows

 

Полный список общеизвестных SID можно посмотреть в документации Platform SDK. Узнать SID конкретного пользователя в системе, а также SID групп, в которые он включен, можно, используя. Например, консольную команду whoami:

whoami /user /sid

Соответствие имени пользователя и его SID можно отследить также в ключе реестра HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ ProfileList.

SID пользо-	SID1... SIDn	DACL по	Привилегии	Прочие па-
вателя	Идентификаторы	умолчанию		раметры
	групп пользователя

 

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

Маркер доступа содержит идентификатор доступа самого пользователя и всех групп, в которые он включен. В маркер включен также DACL по умолчанию - первоначальный список прав доступа, который присоединяется к создаваемым пользователем объектам. Еще одна важная для определения прав пользователя в системе часть маркера - список его привилегий. Привилегии - это права доверен­ного объекта на совершение каких-либо действий по отношению ко всей системе. В таблице 2 перечислены некоторые привилегии, которые могут быть предостав­лены пользователю.

 

Управление привилегиями пользователей осуществляется в оснастке «Групповая политика», раздел Конфигурация Windows/Локальные политики/Назначение прав пользователя.

Чтобы посмотреть привилегии пользователя, можно также использовать команду

whoami /all

Остальные параметры маркера носят информационный характер и опреде­ляют, например, какая подсистема создала маркер, уникальный идентификатор маркера, время его действия. Необходимо также отметить возможность создания ограниченных маркеров (restricted token), которые отличаются от обычных тем, что из них удаляются некоторые привилегии и его SID-идетификаторы проверяются только на запрещающие правила. Создать ограниченный маркер можно программ­но, используя API-функцию CreateRestrictedToken, а можно запустить процесс с ограниченным маркером, используя пункт контекстного меню Windows “Запуск от имени...” и отметив пункт “Защитить компьютер от несанкционированных действий этой программы”.

Рисунок 2. Запуск процесса с ограниченным маркером

 

Ограниченные маркеры используются для процессов, подменяющих клиен­та и выполняющих небезопасный код.

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

- API-функции CreateProcessAsUser, CreateProcessWithLogon;

- оконный интерфейс (рис.2), инициализирующийся при выборе пункта кон­текстного меню “Запуск от имени.”;

- консольную команду runas:

runas /user:имя_пользователя program,

где имяпользователя - имя учетной записи пользователя, которая будет использо­вана для запуска программы в формате пользователь@домен или домен\пользова- тель;

program - команда или программа, которая будет запущена с помощью учетной записи, указанной в параметре /user.

В любом варианте запуска процесса от имени другой учетной записи необхо­димо задать ее пароль.

Защита объектов системы

Маркер доступа идентифицирует субъектов-пользователей системы. С другой стороны, каждый объект системы, требующий защиты, содержит описание прав доступа к нему пользователей. Для этих целей используется дескриптор безопас­ности (Security Descriptor, SD). Каждому объекту системы, включая файлы, прин­теры, сетевые службы, контейнеры Active Directory и другие, присваивается деск­риптор безопасности, который определяет права доступа к объекту и содержит сле­дующие основные атрибуты (рис.3):

- SID владельца, идентифицирующий учетную запись пользователя-владельца объекта;

- пользовательский список управления доступом (Discretionary Access Control List, DACL), который позволяет отслеживать права и ограничения, установленные владельцем данного объекта. DACL может быть изменен пользователем, который указан как текущий владелец объекта.

- системный список управления доступом (System Access Control List, SACL), определяющий перечень действий над объектом, подлежащих аудиту;

- флаги, задающие атрибуты объекта.

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

Рисунок 3. Структура дескриптора безопасности объекта Windows

Список управления доступом содержит набор элементов (Access Control En­tries, ACE). В DACL каждый ACE состоит из четырех частей: в первой указывают­ся пользователи или группы, к которым относится данная запись, во второй - права доступа, а третья информирует о том, предоставляются эти права или отбираются. Четвертая часть представляет собой набор флагов, определяющих, как данная запись будет наследоваться вложенными объектами (актуально, например, для папок файловой системы, разделов реестра).

Если список ACE в DACL пуст, к нему нет доступа ни у одного пользователя (только у владельца на изменение DACL). Если отсутствует сам DACL в SD объек­та - полный доступ к нему имеют все пользователи.

Если какой-либо поток запросил доступ к объекту, подсистема SRM осущест­вляет проверку прав пользователя, запустившего поток, на данный объект, про­сматривая его список DACL. Проверка осуществляется до появления разрешаю­щих прав на все запрошенные операции. Если встретится запрещающее правило хотя бы на одну запрошенную операцию, доступ не будет предоставлен.

Рассмотрим пример на рис.4. Процесс пытается получить доступ к объекту с заданным DACL. В маркере процесса указаны SID запустившего его пользователя, а также SID групп, в которые он входит. В списке DACL объекта присутствуют разрешающие правила на чтение для пользователя с SID=100, и на запись для группы с SID=205. Однако, в доступе пользователю будет отказано, поскольку раньше встречается запрещающее запись правило для группы с SID=201.

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

Для определения и просмотра прав доступа пользователей к ресурсам можно использовать как графические средства контроля, так и консольные команды. Стандартное окно свойств объекта файловой системы (диска, папки, файла) на вкладке Безопасность (рис. 5) позволяет просмотреть текущие разрешения для пользователей и групп пользователей, редактировать их, создавать новые или уда­лять существующие.

 

При определении прав доступа к объектам можно задать правила их наследо­вания в дочерних контейнерах. В окне дополнительных параметров безопасности на вкладке Разрешения при выборе опции «Наследовать от родительского объ­екта применимых к дочерним объектам разрешения, добавляя их к явно за­данным в этом окне» (рис. 6) можно унаследовать разрешения и ограничения, за­данные для родительского контейнера, текущему объекту.

При выборе опции «Заменить разрешения для всех дочерних объектов за­данными здесь разрешениями, применимыми к дочерним объектам» разреша­ется передача определенных для объекта-контейнера правил доступа его дочерним

 

В этом же окне на вкладке Владелец допустимо узнать владельца объекта и заменить его. Владелец объекта имеет право на изменение списка его DACL, даже если к нему запрещен любой тип доступа. Администратор имеет право становиться владельцем любого объекта.С учетом возможности вхождения пользователя в различные группы и неза­висимости определения прав доступа к объектам для групп и пользователей, зачас­тую бывает сложно определить конечные права пользователя на доступ к объекту: требуется просмотреть запрещающие правила, определенные для самого объекта, для всех групп, в которые он включен, затем то же проделать для разрешающих правил. Автоматизировать процесс определения разрешенных пользователю видов доступа к объекту можно с использованием вкладки «Действующие разрешения» окна дополнительных параметров безопасности объекта (рис. 7).

Для просмотра и изменения прав доступа к объектам в режиме командной строки предназначена команда cacls (icacls в Windows Vista и Widows 7).

cacls имя файла [/t] [/e] [/c] [/g пользователь:разрешение] [/r пользователь [...]] [/p пользователь:разрешение [...]] [/d пользователь [...]]

Рассмотрим несколько примеров.

cacls d:\test

Выдаст список DACL для папки test.

cacls d:\test /d ИмяКомпьютера\ИмяПользователя /e

Запретит доступ к объекту для указанного пользователя.

cacls d:\test /р ИмяКомпьютера\ИмяГруппы^ /e /t

Предоставит полный доступ к папке d:\test и ее подпапках всем для членов указанной группы.

Для программного просмотра и изменения списков DACL можно использо­вать API-функции AddAccessAllowedAce, AddAccessDeniedAce, SetSecurityInfo.

Подробнее с этими функциями и примерами их использования можно ознакомить­ся в [пособие].

 

Подсистема аудита.

Важный элемент политики безопасности - аудит событий в системе. ОС Windows ведет аудит событий по 9 категориям:

1. Аудит событий входа в систему.

2. Аудит управления учетными записями.

3. Аудит доступа к службе каталогов.

4. Аудит входа в систему.

5. Аудит доступа к объектам.

6. Аудит изменения политики.

7. Аудит использования привилегий.

8. Аудит отслеживания процессов.

9. Аудит системных событий.

Рассмотрим более подробно, какие события отслеживает каждая из катего­рий.

Аудит событий входа в систему

Аудит попыток пользователя войти в систему с другого компьютера или выйти из нее, при условии, что этот компьютер используется для проверки под­линности учетной записи.

Аудит управления учетными записями

Аудит событий, связанных с управлением учетными записями на компьюте­ре: создание, изменение или удаление учетной записи пользователя или группы; переименование, отключение или включение учетной записи пользователя; задание или изменение пароля.

Аудит доступа к службе каталогов

Аудит событий доступа пользователя к объекту каталога Active Directory, для которого задана собственная системная таблица управления доступом (SACL).

Аудит входа в систему

Аудит попыток пользователя войти в систему с компьютера или выйти из

нее.

Аудит доступа к объектам

Аудит событий доступа пользователя к объекту - например, к файлу, папке, разделу реестра, принтеру и т. п., - для которого задана собственная системная таб­лица управления доступом (SACL).

Аудит изменения политики

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

Аудит использования привилегий

Аудит попыток пользователя воспользоваться предоставленным ему правом.

Аудит отслеживания процессов

Аудиту таких событий, как активизация программы, завершение процесса, повторение дескрипторов и косвенный доступ к объекту.

Аудит системных событий

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

Решения об аудите конкретного типа событий безопасности принимаются в соответствии с политикой аудита локальной системы. Политика аудита, также на­зываемая локальной политикой безопасности (local security policy), является частью политики безопасности, поддерживаемой LSASS в локальной системе, и настраи­вается с помощью редактора локальной политики безопасности (Оснастка gpedit.msc, Конфигурация компьютера - Конфигурация Windows - Параметры безопасности - Локальные политики, Политика аудита, рис. 8).

Для каждого объекта в SD содержится список SACL, состоящий из записей ACE, регламентирующих запись в журнал аудита удачных или неудачных попыток доступа к объекту. Эти АСЕ определяют, какие операции, выполняемые над объек­тами конкретными пользователями или группами, подлежат аудиту. Информация аудита хранится в системном журнале аудита. Аудиту могут подлежать как успеш­ные, так и неудачные операции. Подобно записям ACE DACL, правила аудита объ­ектов могут наследоваться дочерними объектами. Процедура наследования опре­деляются набором флагов, являющихся частью структуры ACE.

Настройка списка SACL может быть осуществлена в окне дополнительных свойств объекта (пункт “Дополнительно”, закладка “Аудит”, рис. 9).

Для программного просмотра и изменения списков SACL можно использовать API-функции GetSecutityInfo и SetSecutityInfo.

При инициализации системы и изменении политики LSASS посылает SRM сообщения, информирующие его о текущей политике аудита. LSASS отвечает за прием записей аудита, генерируемых на основе событий аудита от SRM, их редак­тирование и передачу Event Logger (регистратору событий). SRM посылает записи аудита LSASS через свое LPC-соединение. После этого Event Logger заносит запи­си в журнал безопасности.

События аудита записываются в журналы следующих типов:

1. Журнал приложений. В журнале приложений содержатся данные, относя­щиеся к работе приложений и программ.

2. Журнал безопасности. Журнал безопасности содержит записи о таких со­бытиях, как успешные и безуспешные попытки доступа в систему, а также о собы­тиях, относящихся к использованию ресурсов.

3. Журнал системы. В журнале системы содержатся события системных ком­понентов Windows. Например, в журнале системы регистрируются сбои при за­грузке драйвера или других системных компонентов при запуске системы.

4. Журнал службы каталогов. В журнале службы каталогов содержатся со­бытия, заносимые службой каталогов Windows (на контроллере домена AD).

5. Журнал службы репликации. В журнале службы репликации файлов со­держатся события, заносимые службой репликации файлов Windows (на контрол­лере домена AD).

Просмотр журнала безопасности осуществляется в оснастке «Просмотр со­бытий» (eventvwr.msc, рис. 10). Сами журналы хранятся в файлах SysEvent.evt, SecEvent.evt, AppEvent.evt в папке %WinDir%\system32\config.

В журнал записываются события 3 основных видов:

1. Информационные сообщения о событиях.

Описывают успешное выполнение операций, таких как запуск или некоторое действие системной службы.

2. Предупреждающие сообщения о событиях.

Описывают неожиданные действия, означающие проблему, или указывают на проблему, которая возникнет в будущем, если не будет устранена сейчас.

3. Сообщения о событиях ошибок.

Шифрующая файловая система.

Начиная с версии Windows 2000, в операционных системах семейства Windows NT поддерживается шифрование данных на разделах файловой системы NTFS с использованием шифрующей файловой системы (Encrypted File System, EFS). Основное ее достоинст во заключается в обеспечении конфиденциальности данных на дисках компьютера за счет использования надежных симметричных ал­горитмов для шифрования данных в реальном режиме времени.

Для шифрации данных EFS использует симметричный алгоритм шифрования (AES или DESX) со случайным ключом для каждого файла (File Encryption Key, FEK). По умолчанию данные шифруются в Windows 2000 и Windows XP по алго­ритму DESX, а в Windows XP с Service Pack 1 (или выше) и Windows Server 2003 — по алгоритму AES. В версиях Windows, разрешенных к экспорту за пределы США, драйвер EFS реализует 56-битный ключ шифрования DESX, тогда как в вер­сии, подлежащей использованию только в США, и в версиях с пакетом для 128­битного шифрования длина ключа DESX равна 128 битам. Алгоритм AES в Windows использует 256-битные ключи.

При этом для обеспечения секретности самого ключа FEK шифруется асим­метричным алгоритмом RSA открытым ключом пользователя, результат шифрации FEK - Data Decryption Field, DDF - добавляется в заголовок зашифрованного файла (рис. 11). Такой подход обеспечивает надежное шифрование без потери эф­фективности процесса шифрования: данные шифруются быстрым симметричным алгоритмом, а для гарантии секретности симметричного ключа используется асим­метричный алгоритм шифрования.

Файл, зашифро­ванный EFS

Для шифрации файлов с использованием EFS можно использовать графиче­ский интерфейс или команду cipher.

 

Графический интерфейс доступен в стандартном окне свойств объекта по нажатию кнопки «Дополнительно» (рис. 12). Зашифрованные объекты в стан­дартном интерфейсе Windows Explorer отображаются зеленым цветом.

cipher [{/e|/d}] [/s:каталог] [/a] [/i] [/f] [/q] [/h] [/k] [/u[/n]] [путь [...]] | [/r:имя файла без_расширения]

Например, чтобы определить, зашифрована ли какая-либо папка, необходимо использовать команду:

cipher путь\имя_папки

Команда cipher без параметров выводит статус (зашифрован или нет) для всех объектов текущей папки.

Для шифрации файла необходимо использовать команду

cipher /е /а путь\имя_файла

Для дешифрации файла, соответственно, используется команда

cipher /d /а путь\имя_файла

Допустима шифрация/дешифрация группы файлов по шаблону:

cipher /e /а d:\work\*.doc

Пара открытый и закрытый ключ для шифрации FEK создаются для пользо­вателя автоматически при первой шифрации файла с использованием EFS.

Если некоторый пользователь или группа пользователей зашифровали файл с использованием EFS, то его содержимое доступно только им. Это приводит к рис­кам утери доступа к данным в зашифрованных файлах в случае утраты пароля дан­ным пользователем (работник забыл пароль, уволился и т.п.). Для предотвращения подобных проблем администратор может определить некоторые учетные записи в качестве агентов восстановления.

Агенты восстановления (Recovery Agents) определяются в политике безо­пасности Encrypted Data Recovery Agents (Агенты восстановления шифрован­ных данных) на локальном компьютере или в домене. Эта политика доступна че­рез оснастку Групповая политика (gpedit.msc) раздел «Параметры безопасно­сти»^ «Политика открытого ключа»-> «Файловая система EFS». Пункт меню «Действие»-> «Добавить агент восстановления данных» открывает мастер до­бавления нового агента.

Добавляя агентов восстановления можно указать, какие криптографические пары (обозначенные их сертификатами) могут использовать эти агенты для восста­новления шифрованных данных (рис. 13). Сертификаты для агентов восстановле­ния создаются командой cipher с ключом /г (см. табл. 4). Для пользователя, кото­рый будет агентом восстановления, необходимо импортировать закрытый ключ агента восстановления из сертификата, созданного командой cipher. Это можно сделать в мастере импорта сертификатов, который автоматически загружается при двойном щелчке по файлу *.pfx.

Рисунок 13. Добавление нового агента восстановления EFS

 

EFS создает - DRF (Data Recovery Field)-элементы ключей для каждого агента восстановления, используя провайдер криптографических сервисов, зареги­стрированный для EFS-восстановления. DRF добавляется в зашифрованный файл и может быть использован как альтернативное средство извлечения FEK для дешиф­рации содержимого файла.

Windows хранит закрытые ключи в подкаталоге Application Data\Micro- soft\Crypto\RSA каталога профиля пользователя. Для защиты закрытых ключей Windows шифрует все файлы в папке RSA на основе симметричного ключа, гене­рируемого случайным образом; такой ключ называется мастер-ключом пользова­теля. Мастер-ключ имеет длину в 64 байта и создается стойким генератором слу­чайных чисел. Мастер-ключ также хранится в профиле пользователя в каталоге Application DataYMicrosoftYProtect и зашифровывается по алгоритму 3DES с помо­щью ключа, который отчасти основан на пароле пользователя. Когда пользователь меняет свой пароль, мастер-ключи автоматически расшифровываются, а затем за­ново зашифровываются с учетом нового пароля.

Для расшифровки FEK EFS использует функции Microsoft CryptoAPl (CAPI). CryptoAPI состоит из DLL провайдеров криптографических сервисов (cryptographic service providers, CSP), которые обеспечивают приложениям доступ к различным криптографическим сервисам (шифрованию, дешифрованию и хэшированию). EFS опирается на алгоритмы шифрования RSA, предоставляемые провайдером Microsoft Enhanced Cryptographic Provider (\Windows\ System32\Rsaenh.dll).

Шифрацию и дешифрацию файлов можно осуществлять программно, ис­пользуя API-функции EncryptFile и DecryptFile.

 

3. Порядок выполнения работы:

«Локальная политика безопасности»

1. Установите в системе срок действия пароля не менее 2 и не более 30 дней.

2. Запретите использование пустых паролей.

3. Установите неповторимость паролей (заставьте пользователя употреблять по крайней мере 3 разных пароля).

4. Проверьте возможности блокировки компьютера при 5 неудачных попытках регистрации.

5. Присвойте некоторому пользователю право в системе архивировать и восстанавливать все каталоги.

Установите в системе правило не отображать имени последнего регистрировавшегося пользователя.

Содержание отчета:

1. Цель работы.

2. Краткое описание теории.

3. В рабочем отчете зафиксировать задание, результат его выполнения.

4. Сделать выводы по работе.