Стандарты
защищенности ОС
Ключевое
понятие концепции Федеральных критериев
— профиль защиты — нормативный документ,
который регламентирует все аспекты
безопасности продукта информационных
технологий в виде требований к его
проектированию, технологии разработки
и квалификационному анализу.
Основное
внимание уделяется требованиям к составу
средств защиты и качеству их реализации,
а также адекватности предполагаемым
угрозам безопасности. Профиль защиты
состоит из следующих пяти разделов:
описание, обоснование, функциональные
требования, требования к технологии
разработки, требования к процессу
квалификационного анализа. Описание
профиля содержит классификационную
информацию, необходимую для его
идентификации в специальной картотеке.
Федеральные критерии предлагают
поддерживать такую картотеку на
общегосударственном уровне, что позволит
любой организации воспользоваться
созданными ранее профилями защиты
непосредственно или использовать их в
качестве прототипов для разработки
новых. Обоснование содержит описание
среды эксплуатации, предполагаемых
угроз безопасности и методов использования
продукта. Этот раздел ориентирован на
службы безопасности организаций, которые
принимают решение о возможности
использования данного продукта. Раздел
функциональных требований содержит
описание возможностей средств защиты
и определяет условия, в которых
обеспечивается безопасность в виде
перечня угроз, которым данные средства
защиты успешно противостоят. Раздел
требований к технологии разработки
продукта охватывает все этапы его
создания и содержит требования не только
к процессу разработки, но и к условиям,
в которых она проводится, к используемым
технологическим средствам, а также к
документированию.
Раздел
требований к процессу квалификационного
анализа регламентирует порядок его
проведения в виде методики исследований
и тестирования продукта. Федеральные
критерии не содержат единой шкалы
классов безопасности. Разработчики
могут выбирать набор требований для
каждого конкретного продукта информационных
технологий с учетом среды его эксплуатации.
Стандарты защищенности ос
Для
оценки защищенности ОС существуют
стандарты для компьютерных систем
вообще.
-
В
1992 году Государственная техническая
комиссия при президенте РФ опубликовала
документы, посвященные защите
информационных систем «Средства
вычислительной техники. Защита от
несанкционированного доступа. Показатели
защищенности от несанкционированного
доступа к информации». -
В
данном документе рассматриваются
требования к обеспечению защищенности
программно-аппаратных компонентов
компьютерных систем и средств
вычислительной техники (аппаратных
средств и совокупности программных и
технических элементов систем обработки
данных, способных функционировать
самостоятельно или в составе других
систем). -
Установлено
семь классов защищенности средств
вычислительной техники, седьмой самый
низший. -
Документ
«Автоматизированные системы. Защита
от несанкционированного доступа к
информации. Классификация Автоматизированных
систем и требования по защите информации». -
В
данном документе все автоматизированные
системы делятся на три группы, в каждой
из которых вводится своя иерархия
классов защиты. -
I
группа – Многопользовательские системы,
в которых пользователи имеют различные
полномочия доступа к информации. -
II
группа – Многопользовательские системы,
в которых пользователи имеют одинаковые
полномочия доступа к информации. -
III
группа – однопользовательские системы,
в которых два или более пользователя
не могут работать одновременно, то есть
пользователь может войти в систему не
раньше, чем предыдущий пользователь
завершит работу с ней. -
Самым
известным документом – стандартом
безопасности компьютерных систем
является «Критерии безопасности
компьютерных систем», выпущенный в
1983 году, носит название «Оранжевая
книга». Он описывает семь классов
защищенности компьютерных систем.
Классы безопасности компьютерных систем
Orange
Book Критерии
оценки
достоверных
компьютерных
систем
(Trusted Computer Systems Evaluation Criteria).
Это
руководящие документы Гостехкомиссии.
Критерии
оценки безопасности информационных
технологий (ITSEC Information Technology Security
Evaluation Criteria), действующие в странах
Западной Европы.
Новый
международный стандарт ISO/IEC 15408 Единые
критерии оценки безопасности в области
ИТ чаще всего называют просто Common
Criteria ( Единые критерии ).
Класс d.
Минимальный
уровень безопасности. В этот класс
попадают системы, которые были заявлены
на сертификацию, но ее не прошли.
Класс с1.
Избирательная
защита доступа. Среда
класса С1 предназначена для пользователей,
обрабатывающих данные одного уровня
секретности. Предусматривает наличие
достоверной вычислительной базы (TCB),
выполнение требований к избирательной
безопасности. Обеспечивается отделение
пользователей от данных (меры по
предотвращению считывания или разрушения
данных, возможность защиты приватных
данных). В настоящее время по этому
классу сертификация не предусмотрена.
Класс с1.
Защита,
удовлетворяющая требованиям избирательной
политики управления доступом, которая
заключается в том, что для каждого
объекта и субъекта в системе явно и
недвусмысленно задается перечень
допустимых типов доступа.
Политика
обеспечения безопасности — дискреционная.
Идентификация и аутентификация: ТСВ
(Trusted Computing Base — совокупность аппаратных
и программных механизмов защиты, которые
отвечают за поддержку политики
безопасности) должна требовать, чтобы
пользователи идентифицировали себя
перед началом каких-либо действий, в
которых ТСВ предполагает быть посредником.
ТСВ обязательно использует один из
механизмов аутентификации (например,
пароли) для проверки подлинности
идентификации пользователей.
Архитектура
системы. ТСВ должна
содержать домен, который обеспечивает
ее собственную работу и защиту от внешних
воздействий.
Целостность
системы обеспечивается периодическими
проверками на правильность и корректность
функционирования аппаратных и
микропрограммных элементов ТСВ.
Тестирование
функций безопасности.
Механизм защиты должен соответствовать
описанию, содержащемуся в документах:
–
руководство пользователя;
– руководство
администратора системы на средства
защиты;
– документация по тестам
(разработчики системы должны предусмотреть
документ, в котором дается описание
плана и процедур тестирования);
–
документация по проекту — описание
основополагающих принципов защиты и
их реализации в системе.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Заявления разработчиков программного обеспечения о соответствии высокому классу безопасности зачастую противоречат действительности.
Вам наверняка приходилось слышать, что Microsoft Windows NT 4.0 или еще какая-либо известная ОС соответствует классу безопасности C2.
Заявления разработчиков программного обеспечения о соответствии высокому классу безопасности зачастую противоречат действительности.
Вам наверняка приходилось слышать, что Microsoft Windows NT 4.0 или еще какая-либо известная ОС соответствует классу безопасности C2. Однако эти утверждения зачастую не соответствуют истине: в большинстве случаев производители программного обеспечения либо опережают события, либо выдают желаемое за действительное.
Безопасным в США называют компьютерный продукт, прошедший программу оценки надежности продукта (Trusted Product Evaluation Program, TPEP) от имени и по поручению Национального центра компьютерной безопасности (National Computer Security Center, NCSC), подведомственного Агентству Национальной Безопасности. Каждый такой продукт относят к тому или иному классу безопасности.
Класс безопасности определяется набором требований и правил, изложенных в документе «Критерии оценки надежных компьютерных систем» (Trusted Computer System Evaluation Criteria, TCSEC), который по цвету обложки чаще называют «Оранжевой книгой». Существует семь классов безопасности: A1, B3, B2, B1, C2, C1, D (они приведены в порядке уменьшения требований, т. е. класс B3 выше класса B1 или C2). Помимо своих специфических требований более высокий класс включает в себя требования, предъявляемые к более низкому классу.
Кроме того, интерпретация «Оранжевой книги» для сетевых конфигураций (так называемая «Красная книга») описывает безопасную сетевую среду и сетевые компоненты.
В Таблице 1 представлен список безопасных компьютерных продуктов (Evaluated Product List, EPL) в соответствии с их классами безопасности (http://www.radium.ncsc.mil/tpep/epl/epl-by-class.html). Для краткости здесь перечислены только последние версии. К сожалению, компьютерный продукт, успешно прошедший тестирование, появляется в списке с большой задержкой (до нескольких месяцев). Например, известно, что операционная система Novell NetWare 4.11 получила сертификат по классу C2 в начале октября 1997 г., но в список EPL ее еще на момент написания статьи не внесли. Следует отметить, что в настоящее время тестирование по классу C1 не проводится. Таким образом, вопреки распространенному мнению, C2 — самый низкий класс безопасности.
ТАБЛИЦА 1 — ПРОГРАММНЫЕ ПРОДУКТЫ ПО КЛАССАМ БЕЗОПАСНОСТИ
|
Опеpационные системы |
Сетевые компоненты |
Пpиложения |
|
| Класс A1 | не существуют в настоящее время | MLS LAN (Boeing) Gemini Trusted Network Processor (Gemini Computers) |
не существуют в настоящее время |
| Класс B3 | XTS-300 STOP 4.1a (Wang Federal) | не существуют в настоящее время | не существуют в настоящее время |
| Класс B2 | Trusted XENIX 4.0 (Trusted Information Systems) | VSLAN/VSLANE 6.1 (General Kinetics) | не существуют в настоящее время |
| Класс B1 | UTS/MLS, Version 2.1.5+ (Amdahl) SEVMS VAX and Alpha Version 6.1 (Digital Equipment) ULTRIX MLS+ Version 2.1 on VAX Station 3100 (Digital Equipment) CX/SX 6.2.1 (Harris Computer Systems) HP-UX BLS Release 9.0.9+ (Hewlett-Packard) Trusted IRIX/B Release 4.0.5EPL (Silicon Graphics) OS 1100/2200 Release SB4R7 (Unisys) |
Trusted UNICOS 8.0 (Cray Reseach) CX/SX with LAN/SX 6.2.1 (Harris Computer Systems) |
INFORMIX-OnLine/Secure 5.0 (Informix Software) Trusted Oracle7 (Oracle) Secure SQL Server version 11.0.6 (Sybase) |
| Класс C2 | AOS/VS II, Release 3.10 (Data General) OpenVMS VAX and Alpha Version 6.1 (Digital Equipment) AS/400 with OS/400 V3R0M5 (IBM) Windows NT Version 3.5 (Microsoft) Guardian-90 w/Safeguard S00.01 (Tandem Computers) |
не существуют в настоящее время | INFORMIX-OnLine/Secure 5.0 (Informix Software) Oracle7 (Oracle) SQL Server version 11.0.6 (Sybase) |
Необходимо иметь в виду, что тестируются не операционные системы или программные продукты как таковые, а программно-аппаратная конфигурация. Например, Microsoft Windows NT 3.5 имеет класс C2, лишь когда эту ОС (обязательно с Service Pack 3) устанавливают на компьютеры Compaq Proliant 2000 и 4000 (Pentium) или DECpc AXP/150 (Alpha).
Сертификат будет не действителен, не только если NT установить на другой тип компьютеров (пусть даже это Proliant 6000), но и если SCSI-контроллер производства Compaq (именно такой стоял в сертифицированной машине) заменить на другую модель. Более того, чтобы обеспечить уровень безопасности C2, необходимо строго следовать инструкциям, содержащимся в документе Microsoft «Установки для соответствия защиты уровню C2». Так, если отключена система аудита или на винчестере присутствует MS-DOS, то ни о каком уровне C2 не может быть и речи.
Формально процедуры тестирования и сертификации бесплатны, но косвенные затраты по подготовке необходимых документов и проведению тестов выливаются в весьма круглую сумму. Не всякая компьютерная компания может себе это позволить. Сам же процесс сертификации длится порядка двух лет, что также не добавляет энтузиазма разработчикам ПО. Довольно часто продукт получает сертификат к тому времени, когда он уже устарел или устарела программно-аппаратная конфигурация, на которой продукт испытывался. Но и получение сертификата безопасности не гарантирует отсутствия «дыр», что Национальный центр компьютерной безопасности честно признает. Известны многочисленные случаи, когда в системах, имеющих сертификат, безопасность не соответствовала заявленной.
В связи с вышеизложенным большинство компьютерных компаний предпочитают не тестировать свои продукты, тем более что сертификат важен только при использовании в военных и государственных учреждениях (и то не всех). Обычно речь идет о так называемой совместимости с тем или иным классом безопасности, т. е. процедура тестирования не проводится, но, как говорится, «фирма гарантирует». Зачастую коммерческие организации этим вполне и удовлетворяются.
Если взглянуть на Таблицу 1, то обращает внимание отсутствие операционных систем и приложений, которые удовлетворяли бы требованиям класса A1. Самой безопасной ОС является XTS-300 STOP 4.1a компании Wang Federal, соответствующая классу B3. STOP 4.1a — не просто операционная система, а полный пакет, включающий помимо самой ОС еще и аппаратное обеспечение на основе процессора Intel 486. Данная ОС принадлежит к UNIX-подобным операционным системам, но удовлетворяет экстремально высоким требованиям к безопасности. Но даже с этой ОС не обошлось без ошибок. Например, в сообщении DDN от 23 июня 1995 г. говорится о проблемах в версии STOP 4.0.3.
Среди компьютерных специалистов бытует мнение о невысокой защищенности ОС UNIX. Список EPL говорит об обратном. Самые безопасные ОС принадлежат именно к семейству UNIX. Правда, эти версии UNIX дополнены мощными системами аудита и средствами разграничения полномочий не только на уровне пользователей, но и на уровне компонентов ОС.
ВМЕСТО ЗАКЛЮЧЕНИЯ
Все, о чем говорилось в этой статье, не имеет ровным счетом никакого отношения к российской действительности. Тестирование и сертификацию средств вычислительной техники и автоматизированных систем в России осуществляет Гостехкомиссия при Президенте РФ, и совсем по иным правилам, нежели Национальный центр компьютерной безопасности США. Российские классы защищенности имеют весьма отдаленное отношение к американским классам безопасности. Более того, ни одна компьютерная система, уже имеющая американский сертификат, не пройдет тестирования в Гостехкомиссии без удовлетворения ряду специфических требований.
Вдобавок американские критерии не действуют и в Европе, где имеется свой аналог «Оранжевой книги» под названием «Критерии оценки безопасности информационной технологии» (Information Technology Security Evaluation Criteria, ITSEC). В отличие от «Оранжевой книги» в ITSEC делается упор на понятиях «целостность» и «доступность».
Когда при покупке компьютерного продукта вам сообщают, что он соответствует американскому классу безопасности, помните, что в общем случае это ничего не значит. Если продукт новый, то, скорее всего, он не имеет американского сертификата, а если имеет, то в России этот сертификат не действует.
Константин Пьянзин — обозреватель LAN, с ним можно связаться
по адресу: koka@osp.ru.
МИНИСТЕРСТВО ПО НАУКЕ И ОБРАЗОВАНИЮ РФ
ВОЛЖСКИЙ ПОЛИТЕХНИЧЕСКИЙ ИНСТИТУТ (филиал) ГОУ ВПО ВОЛГО-
ГРАДСКОГО ГОСУДАРСТВЕННОГО ТЕХНИЧЕСКОГО УНИВЕРСИТЕТА
КАФЕДРА «ИНФОРМАТИКА И ТЕХНОЛОГИЯ ПРОГРАММИРОВАНИЯ»
Модель безопасности ОС Windows
Методические указания к лабораторным работам по
курсу «Защита информации»
Волгоград 2011
УДК 004.056
Рецензент: к.т.н., доцент каф. ВАЭ и ВТ ВПИ (филиал) ВолгГТУ Капля В.И.
МЕТОДИЧЕСКИЕ УКАЗАНИЯ К ЛАБОРАТОРНЫМ РАБОТАМ: Модель безопас-
ности ОС Windows/ Сост. Лясин Д.Н., Саньков С.Г.; Волгоград. гос. техн. ун-т. -
Волгоград, 2011, – 24 с.
Содержатся сведения, необходимые для изучения средств обеспечения ин-
формационной безопасности в одной из самых популярных на сегодняшний день
операционных систем - Windows. Рассмотрены принципы построения архитектур
подсистемы безопасности ОС Windows, приведено описание работы систем аутен-
тификации, авторизации, аудита системы, шифрования данных с использованием
EFS. Рассмотрены различные интерфейсы работы с подсистемой безопасности:
оконный графический, консольные команды, API-функции. Задания к лабораторной
направлены на освоение обучающимися средств обеспечения безопасности ОС
Windows на практических примерах.
Предназначены для студентов, обучающихся по направлению 230100 "Ин-
форматика и вычислительная техника" и направлению 231000 "Программная инже-
нерия" всех форм обучения в рамках курса «Защита информации»
Ил. 12. Библиогр.: - 6 назв.
Издается по решению редакционно-издательского совета Волгоградского го-
сударственного технического университета
© Волгоградский государственный
технический университет, 2011
© Волжский политехнический институт, 2011
2
Лабораторная работа №6
Средства обеспечения безопасности ОС Windows
Цель: изучить модель безопасности операционной системы Windows, получить
навыки практического использования ее средств обеспечения безопасности.
1. Основные сведения
1.1. Классификация защиты семейства ОС Windows
Защита конфиденциальных данных от несанкционированного доступа является
важнейшим фактором успешного функционирования любой многопользователь-
ской системы. ОС Windows не является исключением и требования к защите объ-
ектов файловой системы, памяти, объектов ядра операционной системы внесли
существенный вклад в процесс ее проектирования и реализации.
Так, например, версии Windows NT/2000 были сертифицированы по классу С2
критериев TSSEC («Оранжевая книга»). Требования к операционной системе, за-
щищенной по классу С2, включают:
- обязательную идентификацию и аутентификацию всех пользователей опера-
ционной системы. Под этим понимается способность операционной системы иден-
тифицировать всех пользователей, которые получают санкционированный доступ к
системе, и предоставление доступа к ресурсам только этим пользователям;
- разграничительный контроль доступа — предоставление пользователям воз-
можности защиты принадлежащих им данных;
- системный аудит — способность системы вести подробный аудит всех дейст-
вий, выполняемых пользователями и самой операционной системой;
- защита объектов от повторного использования — способность системы пре-
дотвратить доступ пользователя к информации ресурсов, с которыми до этого ра-
ботал другой пользователь.
ОС Microsoft Windows XP Professional (SP2/SP3) имеет действующие сертифи-
каты ФСТЭК России и может использоваться в составе автоматизированных сис-
тем до класса защищенности 1Г включительно в соответствии с требованиями ру-
ководящего документа "Автоматизированные системы. Защита от несанкциониро-
ванного доступа к информации. Классификация автоматизированных систем и тре-
бований по защите информации" (Гостехкомиссия России, 1992).
1.2. Идентификация пользователей
Для защиты данных Windows использует следующие основные механизмы:
аутентификация и авторизация пользователей, аудит событий в системе, шифрова-
ние данных, поддержка инфраструктуры открытых ключей, встроенные средства
сетевой защиты. Эти механизмы поддерживаются такими подсистемами Windows
как LSASS (Local Security Authority Subsystem Service, подсистема локальной ау-
тентификации), SAM (Security Account Manager, диспетчер локальных записей
безопасности), SRM (Security reference Monitor, монитор состояния защиты), Active
Directory (служба каталогов), EFS (Encrypting File System, шифрующая файловая
система) и др.
3
Защита объектов и аудит действий с ними в ОС 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 в свой маркер для обозначения данного действия. Этот
4
идентификатор 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 Название Описание
S-1-1-0 Все Группа, в которую входят все пользователи
S-1-5-2 Сеть Группа, в которую входят все пользовате-
ли, зарегистрировавшиеся в системе из се-
ти
S-1-5-7 Анонимный вход Группа, в которую входят все пользовате-
ли, вошедшие в систему анонимно
S-1-5-домен-500 Администратор Учетная запись администратора системы.
По умолчанию только эта запись обеспечи-
вает полный контроль системы
S-1-5-домен-501 Гость Учетная запись пользователя-гостя
Полный список общеизвестных SID можно посмотреть в документации
Platform SDK. Узнать SID конкретного пользователя в системе, а также SID групп,
в которые он включен, можно, используя консольную команду whoami:
whoami /user /sid
Соответствие имени пользователя и его SID можно отследить также в ключе
реестра HKLMSOFTWAREMicrosoftWindows NTCurrentVersion ProfileList.
5
После аутентификации пользователя процессом Winlogon, все процессы, за-
пущенные от имени этого пользователя будут идентифицироваться специальным
объектом, называемым маркером доступа (access token). Если процесс пользова-
теля запускает дочерний процесс, то его маркер наследуются, поэтому маркер дос-
тупа олицетворяет пользователя для системы в каждом запущенном от его имени
процессе. Основные элементы маркера представлены на рис. 1.
SID пользо- SID1 … SIDn DACL по Привилегии Прочие па-
вателя Идентификаторы умолчанию раметры
групп пользователя
Рисунок 1. Обобщенная структура маркера доступа.
Маркер доступа содержит идентификатор доступа самого пользователя и
всех групп, в которые он включен. В маркер включен также DACL по умолчанию -
первоначальный список прав доступа, который присоединяется к создаваемым
пользователем объектам. Еще одна важная для определения прав пользователя в
системе часть маркера – список его привилегий. Привилегии - это права доверен-
ного объекта на совершение каких-либо действий по отношению ко всей системе.
В таблице 2 перечислены некоторые привилегии, которые могут быть предостав-
лены пользователю.
Таблица 2. Привилегии, которыми могут быть наделены пользователи
Имя и идентифика- Описание привилегии
тор привилегии
Увеличение приоритета Пользователь, обладающий данной привилегией может изменять
диспетчирования приоритет диспетчирования процесса с помощью интерфейса Дис-
SeIncreaseBasePriorityPrivilege петчера задач
Закрепление страниц в Процесс получает возможность хранить данные в физической па-
памяти мяти, не прибегая к кэшированию данных в виртуальной памяти на
SeLockMemoryPrivilege диске.
Управление аудитом и Пользователь получает возможность указывать параметры аудита
журналом безопасности доступа к объекту для отдельных ресурсов, таких как файлы, объ-
SeAuditPrivilege екты Active Directory и разделы реестра.
Овладение файлами или Пользователь получает возможность становиться владельцем лю-
иными объектами бых объектов безопасности системы, включая объекты Active
SeTakeOwnershipPrivilege Directory, файлы и папки NTFS, принтеры, разделы реестра, служ-
бы, процессы и потоки
Завершение работы сис- Пользователь получает возможность завершать работу операцион-
темы ной системы на локальном компьютере
SeShutdownPrivilege
Обход перекрестной Используется для обхода проверки разрешений для промежуточ-
проверки ных каталогов при проходе многоуровневых каталогов
SeChangeNotifyPrivilege
Управление привилегиями пользователей осуществляется в оснастке
«Групповая политика», раздел Конфигурация Windows/Локальные полити-
ки/Назначение прав пользователя.
6
Чтобы посмотреть привилегии пользователя, можно также использовать
команду
whoami /all
Остальные параметры маркера носят информационный характер и опреде-
ляют, например, какая подсистема создала маркер, уникальный идентификатор
маркера, время его действия. Необходимо также отметить возможность создания
ограниченных маркеров (restricted token), которые отличаются от обычных тем, что
из них удаляются некоторые привилегии и его SID-идетификаторы проверяются
только на запрещающие правила. Создать ограниченный маркер можно программ-
но, используя API-функцию CreateRestrictedToken, а можно запустить процесс с
ограниченным маркером, используя пункт контекстного меню Windows “Запуск
от имени…” и отметив пункт “Защитить компьютер от несанкционированных
действий этой программы” (рис.2).
Рисунок 2. Запуск процесса с ограниченным маркером
Ограниченные маркеры используются для процессов, подменяющих клиен-
та и выполняющих небезопасный код.
Маркер доступа может быть создан не только при первоначальном входе
пользователя в систему. Windows предоставляет возможность запуска процессов от
имени других пользователей, создавая для этих процессов соответствующий мар-
кер. Для этих целей можно использовать:
- API-функции CreateProcessAsUser, CreateProcessWithLogon;
- оконный интерфейс (рис.2), инициализирующийся при выборе пункта кон-
текстного меню “Запуск от имени…”;
- консольную команду runas:
runas /user:имя_пользователя program ,
где имя_пользователя - имя учетной записи пользователя, которая будет использо-
вана для запуска программы в формате пользователь@домен или доменпользова-
тель;
program – команда или программа, которая будет запущена с помощью учетной
записи, указанной в параметре /user.
7
В любом варианте запуска процесса от имени другой учетной записи необхо-
димо задать ее пароль.
1.3. Защита объектов системы.
Маркер доступа идентифицирует субъектов-пользователей системы. С другой
стороны, каждый объект системы, требующий защиты, содержит описание прав
доступа к нему пользователей. Для этих целей используется дескриптор безопас-
ности (Security Descriptor, SD). Каждому объекту системы, включая файлы, прин-
теры, сетевые службы, контейнеры Active Directory и другие, присваивается деск-
риптор безопасности, который определяет права доступа к объекту и содержит сле-
дующие основные атрибуты (рис.3):
- SID владельца, идентифицирующий учетную запись пользователя-владельца
объекта;
- пользовательский список управления доступом (Discretionary Access Control
List, DACL), который позволяет отслеживать права и ограничения, установленные
владельцем данного объекта. DACL может быть изменен пользователем, который
указан как текущий владелец объекта.
- системный список управления доступом (System Access Control List, SACL),
определяющий перечень действий над объектом, подлежащих аудиту;
- флаги, задающие атрибуты объекта.
Авторизация Windows основана на сопоставлении маркера доступа субъекта с
дескриптором безопасности объекта. Управляя свойствами объекта, администрато-
ры могут устанавливать разрешения, назначать право владения и отслеживать дос-
туп пользователей.
Версия SD
ACL
SID владельца
размер редакция
число записей SID группы
ACE [1] DACL
ACE […]
SACL
ACE [n]
Флаги Объект
ACE
Идентификатор Права Тип Механизм
безопасности доступа записи наследования
Рисунок 3. Структура дескриптора безопасности объекта Windows
Список управления доступом содержит набор элементов (Access Control En-
tries, ACE). В DACL каждый ACE состоит из четырех частей: в первой указывают-
ся пользователи или группы, к которым относится данная запись, во второй – права
доступа, а третья информирует о том, предоставляются эти права или отбираются.
Четвертая часть представляет собой набор флагов, определяющих, как данная за-
8
пись будет наследоваться вложенными объектами (актуально, например, для папок
файловой системы, разделов реестра).
Если список ACE в DACL пуст, к нему нет доступа ни у одного пользователя
(только у владельца на изменение DACL). Если отсутствует сам DACL в SD объек-
та – полный доступ к нему имеют все пользователи.
Если какой-либо поток запросил доступ к объекту, подсистема SRM осущест-
вляет проверку прав пользователя, запустившего поток, на данный объект, про-
сматривая его список DACL. Проверка осуществляется до появления разрешаю-
щих прав на все запрошенные операции. Если встретится запрещающее правило
хотя бы на одну запрошенную операцию, доступ не будет предоставлен.
Рассмотрим пример на рис.4. Процесс пытается получить доступ к объекту с
заданным DACL. В маркере процесса указаны SID запустившего его пользователя,
а также SID групп, в которые он входит. В списке DACL объекта присутствуют
разрешающие правила на чтение для пользователя с SID=100, и на запись для
группы с SID=205. Однако, в доступе пользователю будет отказано, поскольку
раньше встречается запрещающее запись правило для группы с SID=201.
запрос
Объект
R/W
Маркер
доступа SRM DACL
SID 78 W Deny
SID 100
SID 201 WX Deny
SID 201
Груп-
SID 79 RW Allow
SID 202
пы SID 100 R Allow
SID 205
SID 205 W Allow
Запрос от-
Процесс клонен!
Рисунок 4. Проверка прав доступа пользователя к объекту
Необходимо отметить, что запрещающее правило помещено в списке DACL
на рисунке не случайно. Запрещающие правила всегда размещаются перед разре-
шающими, то есть являются доминирующими при проверке прав доступа.
Для определения и просмотра прав доступа пользователей к ресурсам можно
использовать как графические средства контроля, так и консольные команды.
Стандартное окно свойств объекта файловой системы (диска, папки, файла) на
вкладке Безопасность (рис. 5) позволяет просмотреть текущие разрешения для
пользователей и групп пользователей, редактировать их, создавать новые или уда-
лять существующие.
9
Запрещающие ACE
Разрещающие ACE
Рисунок 5. GUI-интерфейс Windows для изменения прав доступа к объектам
При определении прав доступа к объектам можно задать правила их наследо-
вания в дочерних контейнерах. В окне дополнительных параметров безопасности
на вкладке Разрешения при выборе опции «Наследовать от родительского объ-
екта применимых к дочерним объектам разрешения, добавляя их к явно за-
данным в этом окне» (рис. 6) можно унаследовать разрешения и ограничения, за-
данные для родительского контейнера, текущему объекту.
При выборе опции «Заменить разрешения для всех дочерних объектов за-
данными здесь разрешениями, применимыми к дочерним объектам» разреша-
ется передача определенных для объекта-контейнера правил доступа его дочерним
Унаследовать права от
родителя
Передать права дочер-
ним объектам
Рисунок 6. Определение параметров наследования прав доступа к объектам
объектам.
В этом же окне на вкладке Владелец допустимо узнать владельца объекта и
заменить его. Владелец объекта имеет право на изменение списка его DACL, даже
если к нему запрещен любой тип доступа. Администратор имеет право становиться
владельцем любого объекта.
10
С учетом возможности вхождения пользователя в различные группы и неза-
висимости определения прав доступа к объектам для групп и пользователей, зачас-
тую бывает сложно определить конечные права пользователя на доступ к объекту:
требуется просмотреть запрещающие правила, определенные для самого объекта,
для всех групп, в которые он включен, затем то же проделать для разрешающих
правил. Автоматизировать процесс определения разрешенных пользователю видов
доступа к объекту можно с использованием вкладки «Действующие разрешения»
окна дополнительных параметров безопасности объекта (рис. 7).
Имя пользователя или
группы
Разрешения на доступ к
объекту для выбранного
пользователя или группы
Рисунок 7. Определение эффективных прав доступа пользователя (группы) к
объекту
Для просмотра и изменения прав доступа к объектам в режиме командной
строки предназначена команда cacls (icacls в Windows Vista и Widows 7).
cacls имя_файла [/t] [/e] [/c] [/g пользователь:разрешение] [/r пользователь [...]]
[/p пользователь:разрешение [...]] [/d пользователь [...]]
Назначения параметров команды приведены в таблице 3.
Таблица 3. Параметры команды cacls
Задаёт файл или папку, права доступа к которой необхо-
димо просмотреть/изменить (допустимо использовать
шаблоны с символами * и ?).
/t Изменение избирательных таблиц контроля доступа
(DACL) указанных файлов в текущем каталоге и всех под-
каталогах
/e Редактирование избирательной таблицы управления дос-
тупом (DACL) вместо ее замены
/c Заставляет команду продолжить изменение прав доступа
при возникновении ошибки, связанной с нарушениями
прав доступа
/g
/r
11
/p
/d группе
Для указания добавляемых или отнимаемых прав используются следующие
значения:
F- полный доступ;
C- изменение (запись);
W- запись;
R- чтение;
N- нет доступа.
Рассмотрим несколько примеров.
cacls d:test
Выдаст список DACL для папки test.
cacls d:test /d ИмяКомпьютераИмяПользователя /e
Запретит доступ к объекту для указанного пользователя.
cacls d:test /p ИмяКомпьютераИмяГруппы:f /e /t
Предоставит полный доступ к папке d:test и ее подпапках всем для членов
указанной группы.
Для программного просмотра и изменения списков DACL можно использо-
вать API-функции AddAccessAllowedAce, AddAccessDeniedAce, SetSecurityInfo.
Подробнее с этими функциями и примерами их использования можно ознакомить-
ся в [пособие].
1.4. Подсистема аудита.
Важный элемент политики безопасности – аудит событий в системе. ОС
Windows ведет аудит событий по 9 категориям:
1. Аудит событий входа в систему.
2. Аудит управления учетными записями.
3. Аудит доступа к службе каталогов.
4. Аудит входа в систему.
5. Аудит доступа к объектам.
6. Аудит изменения политики.
7. Аудит использования привилегий.
8. Аудит отслеживания процессов.
9. Аудит системных событий.
Рассмотрим более подробно, какие события отслеживает каждая из катего-
рий.
Аудит событий входа в систему
Аудит попыток пользователя войти в систему с другого компьютера или
выйти из нее, при условии, что этот компьютер используется для проверки под-
линности учетной записи.
12
Аудит управления учетными записями
Аудит событий, связанных с управлением учетными записями на компьюте-
ре: создание, изменение или удаление учетной записи пользователя или группы;
переименование, отключение или включение учетной записи пользователя; задание
или изменение пароля.
Аудит доступа к службе каталогов
Аудит событий доступа пользователя к объекту каталога Active Directory, для
которого задана собственная системная таблица управления доступом (SACL).
Аудит входа в систему
Аудит попыток пользователя войти в систему с компьютера или выйти из
нее.
Аудит доступа к объектам
Аудит событий доступа пользователя к объекту – например, к файлу, папке,
разделу реестра, принтеру и т. п., - для которого задана собственная системная таб-
лица управления доступом (SACL).
Аудит изменения политики
Аудит фактов изменения политик назначения прав пользователей, политик
аудита или политик доверительных отношений.
Аудит использования привилегий
Аудит попыток пользователя воспользоваться предоставленным ему правом.
Аудит отслеживания процессов
Аудиту таких событий, как активизация программы, завершение процесса,
повторение дескрипторов и косвенный доступ к объекту.
Аудит системных событий
Аудит событий перезагрузки или отключения компьютера, а также событий,
влияющих на системную безопасность или на журнал безопасности.
Решения об аудите конкретного типа событий безопасности принимаются в
соответствии с политикой аудита локальной системы. Политика аудита, также на-
зываемая локальной политикой безопасности (local security policy), является частью
политики безопасности, поддерживаемой LSASS в локальной системе, и настраи-
вается с помощью редактора локальной политики безопасности (Оснастка
gpedit.msc, Конфигурация компьютера - Конфигурация Windows – Параметры
безопасности – Локальные политики – Политика аудита, рис. 8).
13
Рисунок 8. Конфигурация политики аудита редактора локальной политики
безопасности
Для каждого объекта в SD содержится список SACL, состоящий из записей
ACE, регламентирующих запись в журнал аудита удачных или неудачных попыток
доступа к объекту. Эти АСЕ определяют, какие операции, выполняемые над объек-
тами конкретными пользователями или группами, подлежат аудиту. Информация
аудита хранится в системном журнале аудита. Аудиту могут подлежать как успеш-
ные, так и неудачные операции. Подобно записям ACE DACL, правила аудита объ-
ектов могут наследоваться дочерними объектами. Процедура наследования опре-
деляются набором флагов, являющихся частью структуры ACE.
Настройка списка SACL может быть осуществлена в окне дополнительных
свойств объекта (пункт “Дополнительно”, закладка “Аудит”, рис. 9).
записи ACE списка
SACL объекта
параметры наследования
ACE (аналогично DACL)
Рисунок 9. Интерфейс редактирования правил аудита для объекта
Для программного просмотра и изменения списков SACL можно
использовать API-функции GetSecutityInfo и SetSecutityInfo.
14
При инициализации системы и изменении политики 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%system32config.
Предупреждающее
сообщение
Сообщение об
ошибке
Информационное
сообщение
Рисунок 10. Оснастка Windows «Просмотр событий»
В журнал записываются события 3 основных видов:
1. Информационные сообщения о событиях.
Описывают успешное выполнение операций, таких как запуск или некоторое
действие системной службы.
2. Предупреждающие сообщения о событиях.
Описывают неожиданные действия, означающие проблему, или указывают
на проблему, которая возникнет в будущем, если не будет устранена сейчас .
3. Сообщения о событиях ошибок.
15
Описывают ошибки, возникшие из-за неудачного выполнения задач.
1.5. Шифрующая файловая система.
Начиная с версии 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
пользователя (RSA) FEK
DDF
Зашифрован-
ный файл
Шифрование данных
(DESX или AES)
Файл на диске
FEK
DRF
Открытый ключ аген-
та восстановления
RSA)
Рисунок 11. Схема шифрации файла в EFS
16
Для шифрации файлов с использованием EFS можно использовать графиче-
ский интерфейс или команду cipher.
Графический интерфейс доступен в стандартном окне свойств объекта по
нажатию кнопки «Дополнительно» (рис. 12). Зашифрованные объекты в стан-
дартном интерфейсе Windows Explorer отображаются зеленым цветом.
Рисунок 12. Графический интерфейс шифрования файла с использованием EFS
Необходимо отметить, что EFS позволяет разделять зашифрованный файл
между несколькими пользователями. В этом случае FEK шифруется открытыми
ключами всех пользователей, которым разрешен доступ к файлу, и каждый резуль-
тат шифрации добавляется в DDF.
Шифрование файла с использованием EFS защищает файл комплексно: поль-
зователю, не имеющему права на дешифрацию файла, недопустимы, в том числе,
такие операции, как удаление, переименование и копирование файла. Необходимо
помнить, что EFS является частью файловой системы NTFS, и в случае копирова-
ния защищенного файла авторизованным пользователем на другой том с файловой
системой, на поддерживающей EFS (например, FAT32), он будет дешифрован и
сохранен на целевом томе в открытом виде.
Консольная команда cipher может быть использована для шифра-
ции/дешифрации файлов из командной строки или в bat-сценарии.
cipher [{/e|/d}] [/s:каталог] [/a] [/i] [/f] [/q] [/h] [/k] [/u[/n]] [путь [...]] |
[/r:имя_файла_без_расширения]
Назначения параметров команды приведены в таблице 4.
Таблица 4. Параметры команды cipher
/e Шифрует указанные папки. Папки помечаются таким образом, что-
бы файлы, которые будут добавляться в папку позже, также шифро-
вались.
/d Расшифровывает указанные папки. Папки помечаются таким обра-
зом, чтобы файлы, которые будут добавляться в папку позже, не бу-
дут шифроваться
/s: каталог Выполняет выбранную операцию над указанной папкой и всеми
подпапками в ней.
/a Выполняет операцию над файлами и каталогами
/i Продолжение выполнения указанной операции даже после возник-
17
новения ошибок. По умолчанию выполнение cipher прекращается
после возникновения ошибки
/f Выполнение повторного шифрования или расшифровывания ука-
занных объектов. По умолчанию уже зашифрованные или расшиф-
рованные файлы пропускаются командой cipher
/k Создание ключа шифрования файла для пользователя, выполнивше-
го команду cipher. Если используется данный параметр, все осталь-
ные параметры команды cipher не учитываются.
/u Обновление ключа шифрования файла пользователя или ключа
агента восстановления на текущие ключи во всех зашифрованных
файлах на локальном диске (если эти ключи были изменены). Этот
параметр используется только вместе с параметром /n.
/n Запрещение обновления ключей. Данный параметр служит для по-
иска всех зашифрованных файлов на локальных дисках. Этот пара-
метр используется только вместе с параметром /u.
путь Указывает шаблон, файл или папку.
/r: имя_файла Создание нового сертификата агента восстановления и закрытого
ключа с последующей их записью в файлах с именем, указанным в
параметре имя_файла (без расширения). Если используется данный
параметр, все остальные параметры команды cipher не учитывают-
ся.
Например, чтобы определить, зашифрована ли какая-либо папка, необходимо
использовать команду:
cipher путьимя_папки
Команда cipher без параметров выводит статус (зашифрован или нет) для
всех объектов текущей папки.
Для шифрации файла необходимо использовать команду
cipher /e /a путьимя_файла
Для дешифрации файла, соответственно, используется команда
cipher /d /a путьимя_файла
Допустима шифрация/дешифрация группы файлов по шаблону:
cipher /e /a d:work*.doc
Пара открытый и закрытый ключ для шифрации FEK создаются для пользо-
вателя автоматически при первой шифрации файла с использованием EFS.
Если некоторый пользователь или группа пользователей зашифровали файл с
использованием EFS, то его содержимое доступно только им. Это приводит к рис-
кам утери доступа к данным в зашифрованных файлах в случае утраты пароля дан-
ным пользователем (работник забыл пароль, уволился и т.п.). Для предотвращения
подобных проблем администратор может определить некоторые учетные записи в
качестве агентов восстановления.
Агенты восстановления (Recovery Agents) определяются в политике безо-
пасности Encrypted Data Recovery Agents (Агенты восстановления шифрован-
18
ных данных) на локальном компьютере или в домене. Эта политика доступна че-
рез оснастку Групповая политика (gpedit.msc) раздел «Параметры безопасно-
сти»-> «Политика открытого ключа»-> «Файловая система EFS». Пункт меню
«Действие»-> «Добавить агент восстановления данных» открывает мастер до-
бавления нового агента.
Добавляя агентов восстановления можно указать, какие криптографические
пары (обозначенные их сертификатами) могут использовать эти агенты для восста-
новления шифрованных данных (рис. 13). Сертификаты для агентов восстановле-
ния создаются командой cipher с ключом /r (см. табл. 4). Для пользователя, кото-
рый будет агентом восстановления, необходимо импортировать закрытый ключ
агента восстановления из сертификата, созданного командой cipher. Это можно
сделать в маcтере импорта сертификатов, который автоматически загружается при
двойном щелчке по файлу *.pfx.
Рисунок 13. Добавление нового агента восстановления EFS
EFS создает – DRF (Data Recovery Field)-элементы ключей для каждого
агента восстановления, используя провайдер криптографических сервисов, зареги-
стрированный для EFS-восстановления. DRF добавляется в зашифрованный файл и
может быть использован как альтернативное средство извлечения FEK для дешиф-
рации содержимого файла.
Windows хранит закрытые ключи в подкаталоге Application DataMicro-
softCryptoRSA каталога профиля пользователя. Для защиты закрытых ключей
Windows шифрует все файлы в папке RSA на основе симметричного ключа, гене-
рируемого случайным образом; такой ключ называется мастер-ключом пользова-
теля. Мастер-ключ имеет длину в 64 байта и создается стойким генератором слу-
чайных чисел. Мастер-ключ также хранится в профиле пользователя в каталоге
Application DataMicrosoftProtect и зашифровывается по алгоритму 3DES с помо-
щью ключа, который отчасти основан на пароле пользователя. Когда пользователь
19
меняет свой пароль, мастер-ключи автоматически расшифровываются, а затем за-
ново зашифровываются с учетом нового пароля.
Для расшифровки FEK EFS использует функции Microsoft CryptoAPl (CAPI).
CryptoAPI состоит из DLL провайдеров криптографических сервисов (cryptographic
service providers, CSP), которые обеспечивают приложениям доступ к различным
криптографическим сервисам (шифрованию, дешифрованию и хэшированию). EFS
опирается на алгоритмы шифрования RSA, предоставляемые провайдером
Microsoft Enhanced Cryptographic Provider (Windows System32Rsaenh.dll).
Шифрацию и дешифрацию файлов можно осуществлять программно, ис-
пользуя API-функции EncryptFile и DecryptFile.
2. Порядок выполнения работы.
2.1. Ознакомьтесь с теоретическими основами защиты информации в ОС се-
мейства Windows в настоящих указаниях и конспектах лекций.
2.2. Выполните задания 2.2.1-2.2.8
2.2.1. Запустите в программе Oracle VM Virtualbox виртуальную ма-
шину WinXP. Войдите в систему под учетной записью администратора, пароль уз-
найте у преподавателя. Все действия в пп 2.2.1-2.2.8 выполняйте в системе, рабо-
тающей на виртуальной машине.
2.2.2. Создайте учетную запись нового пользователя testUser в оснаст-
ке «Управление компьютером» (compmgmt.msc). При создании новой учетной
записи запретите пользователю смену пароля и снимите ограничение на срок дей-
ствия его пароля. Создайте новую группу ”testGroup” и включите в нее нового
пользователя. Удалите пользователя из других групп. Создайте на диске С: папку
forTesting. Создайте или скопируйте в эту папку несколько текстовых файлов
(*.txt).
2.2.3. С помощью команды runas запустите сеанс командной строки
(cmd.exe) от имени вновь созданного пользователя. Командой whoami посмотрите
SID пользователя и всех его групп, а также текущие привилегии пользователя.
Строку запуска и результат работы этой и всех следующих консольных команд
копируйте в файл протокола лабораторной работы.
2.2.4. Убедитесь в соответствии имени пользователя и полученного SID
в реестре Windows. Найдите в реестре, какому пользователю в системе присвоен
SID S-1-5-21-1957994488-492894223-170857768-1004 (Используйте ключ реестра
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList).
2.2.5. Командой whoami определите перечень текущих привилегий
пользователя testUser. В сеансе командной строки пользователя попробуйте изме-
нить системное время командой time. Чтобы предоставить пользователю подобную
привилегию, запустите оснастку «Локальные параметры безопасности»
(secpol.msc). Добавьте пользователя в список параметров политики «Изменение
системного времени» раздела Локальные политики -> Назначение прав поль-
зователя. После этого перезапустите сеанс командной строки от имени пользова-
20
теля, убедитесь, что в списке привилегий добавилась SeSystemtimePriviege. По-
пробуйте изменить системное время командой time.
Убедитесь, что привилегия «Завершение работы системы»
(SeShutdownPrivilege) предоставлена пользователю testUser . После этого попро-
буйте завершить работу системы из сеанса командной строки пользователя коман-
дой shutdown –s. Добавть ему привелегию «Принудительное удаленное завер-
шение» (SeRemoteShutdownPrivilege). Попробуйте завершить работу консольной
командой еще раз (отменить команду завершения до ее непосредственного выпол-
нения можно командой shutdown –a).
2.2.6. Ознакомьтесь с справкой по консольной команде cacls. Используя эту
команду, просмотрите разрешения на папку c:forTesting. Объясните все обозначе-
ния в описаниях прав пользователей и групп в выдаче команды.
а) Разрешите пользователю testUser запись в папку forTesting, но запретите
запись для группы testGroup. Попробуйте записать файлы или папки в forTesting
от имени пользователя testUser. Объясните результат. Посмотрите эффективные
разрешения пользователя testUser к папке forTesting в окне свойств папки.
б) Используя стандартное окно свойств папки, задайте для пользователя
testUser такие права доступа к папке, чтобы он мог записывать информацию в пап-
ку forTesting, но не мог просматривать ее содержимое. Проверьте, что папка
forTesting является теперь для пользователя testUser “слепой”, запустив, напри-
мер, от его имени файловый менеджер и попробовав записать файлы в папку, про-
смотреть ее содержимое, удалить файл из папки.
в) Для вложенной папки forTestingDocs отмените наследование ACL от
родителя и разрешите пользователю просмотр, чтение и запись в папку. Проверьте,
что для пользователя папка forTestingDocs перестала быть “слепой” (например,
сделайте ее текущей в сеансе работы файлового менеджера от имени пользователя
и создайте в ней новый файл).
г) Снимите запрет на чтение папки forTesting для пользователя testUser.
Используя команду cacls запретите этому пользователю доступ к файлам с расши-
рением txt в папке forTesting. Убедитесь в недоступности файлов для пользовате-
ля.
д) Командой cacls запретите пользователю все права на доступ к папке
forTesting и разреште полный доступ к вложенной папке forTestingDocs. Убеди-
тесь в доступности папки forTestingDocs для пользователя. Удалите у пользовате-
ля testUser привилегию SeChangeNotifyPrivilege. Попробуйте получить доступ к
папке forTestingDocs. Объясните результат.
е) Запустите файловый менеджер от имени пользователя testUser и создайте
в нем папку newFolder на диске C. Для папки newFolder очистите весь список
ACL командой cacls. Попробуйте теперь получить доступ к папке от имени адми-
нистратора и от имени пользователя. Кто и как теперь может вернуть доступ к пап-
ке? Верните полный доступ к папке для всех пользователей.
ж) Создайте в разделе HKLMSoftware реестра раздел testKey. Запретите
пользователю testUser создание новых разделов в этом разделе реестра. Создайте
для раздела HKLMSoftwaretestKey SACL, позволяющий протоколировать отка-
зы при создании новых подразделов, а также успехи при перечислении подразде-
лов и запросе значений (предварительно проверьте, что в локальной политике
21
безопасности соответствующий тип аудита включен). Попробуйте от имени поль-
зователя testUser запустить regedit.exe и создать раздел в HKLMSoftware. Убеди-
тесь, что записи аудита были размещены в журнале безопасности (eventvwr.msc).
2.2.7. Шифрование файлов и папок средствами EFS.
а) От имени пользователя testUser зашифруйте какой-нибудь файл на диске.
Убедитесь, что после этого был создан сертификат пользователя, запустив оснаст-
ку certmgr.msc от имени пользователя (раздел Личные). Просмотрите основные
параметры сертификата открытого ключа пользователя testUser (срок действия,
используемые алгоритмы). Установите доверие к этому сертификату в вашей сис-
теме.
б) Создайте в папке forTesting новую папку Encrypt. В папке Encrypt соз-
дайте или скопируйте в нее текстовый файл. Зашифруйте папку Encrypt и все ее
содержимое из меню свойств папки от имени администратора. Попробуйте про-
смотреть или скопировать какой-нибудь файл этой папки от имени пользователя
testUser. Объясните результат. Скопируйте зашифрованный файл в незашифро-
ванную папку (например, forTesting). Убедитесь что он остался зашифрованным.
Добавьте пользователя testUser в список имеющих доступа к файлу пользователей
в окне свойств шифрования файла. Повторите попытку получить доступ к файлу от
имени пользователя testUser.
в) Создайте учетную запись нового пользователя agentUser, сделайте его
членом группы Администраторы. Определите для пользователя agentUser роль
агента восстановления EFS. Создайте в папке forTesting новый текстовый файл с
произвольным содержимым. Зашифруйте этот файл от имени пользователя
testUser. Убедитесь в окне подробностей шифрования файла, что пользователь
agentUser является агентом восстановления для данного файла. Попробуйте про-
читать содержимое файла от имени администратора и от имени пользователя
agentUser. Объясните результат.
г) Зашифруйте все текстовые файлы папки forTesting с использованием кон-
сольной команды шифрования cipher от имени пользователя testUser (предвари-
тельно снимите запрет на доступ к этим файлам, установленный в задании 2.2.6г).
д) Убедитесь, что при копировании зашифрованных файлов на том с файло-
вой системой, не поддерживающей EFS (например, FAT32 на флеш-накопителе),
содержимое файла дешифруется.
2.2.8. После демонстрации результатов работы преподавателю восстановите
исходное состояние системы: удалите созданные папки и файлы, разделы реестра,
удалите учетную запись созданного пользователя и его группы, снимите с пользо-
вателя agentUser роль агента восстановления.
2.2.9. Представьте отчёт по лабораторной работе преподавателю и отчитайте
работу.
2.3. Содержание отчета
Отчет по лабораторной работе должен содержать следующие сведения:
- название и цель работы;
- протокол выполнения лабораторной работы, содержащий список кон-
сольных команд, составленных при выполнении работы, и результаты их
выполнения.
22
3. Контрольные вопросы
1. К какому классу безопасности относится ОС Windows по различным
критериям оценки?
2. Каким образом пользователи идентифицируются в ОС Windows?
3. Что такое списки DACL и SACL?
4. Перечислите, каким образом можно запустить процесс от имени друго-
го пользователя.
5. Как происходит проверка прав доступа пользователя к ресурсам в ОС
Windows?
6. Что такое маркер безопасности, и какова его роль в модели безопасно-
сти Windows?
7. Как с использованием команды cacls добавить права на запись для всех
файлов заданной папки?
8. Какие события подлежат аудиту в ОС Windows?
9. Каким образом шифруются файлы в файловой системе EFS? Что такое
FEK? DDF? DDR?
10. Какие алгоритмы шифрования используются в EFS?
4. Л и т е р а т у р а
1. Соломон, Руссинович. Внутреннее устройство Microsoft Windows: Windows
Server 2003, Windows XP и Windows 2000. 4-е издание, СПб.: Питер, 2008., 992 с.
2. А. Чекмарев, А. Вишневский, О. Кокорева Microsoft Windows Server 2003.
Русская версия. Наиболее полное руководство. , СПб.: БХВ-Петербург, 2008 г.,
1120 с.
3. Лясин Д.Н., Саньков С.Г. Методы и средства защиты компьютерной ин-
формации (учебное пособие). – Волгоград, Издательство ВолгГТУ РПК "Политех-
ник”, 2005г.
4. У. Р. Станек. Командная строка Microsoft Windows. Справочник админист-
ратора. М.: Русская редакция, 2009., 480с.
5. Безопасность Windows Server 2003 в библиотеке Microsoft TechNet.
http://technet.microsoft.com/ru-ru/library/dd548350%28WS.10%29.aspx
23
Дмитрий Николаевич Лясин
Сергей Геннадиевич Саньков
Модель безопасности ОС Windows. Методические указания к лабораторным рабо-
там по курсу «Защита информации».
План выпуска электронных изданий 2011г., поз. N___
Подписано “На выпуск в свет ______”. Уч. -изд.л.
На магнитном носителе.
Волгоградский государственный технический университет.
400131 Волгоград , пр. Ленина , 28.
24
“Оранжевая книга” предусматривает четыре группы критериев, которые соответствуют различной степени защищенности: от минимальной (группа D) до формально доказанной (группа А). Каждая группа включает один или несколько классов. Группы D и А содержат по одному классу (классы D и А соответственно), группа С – классы C1, C2, а группа В три класса – B1, B2, В3, характеризующиеся различными наборами требований безопасности. Уровень безопасности возрастает при движении от группы D к группе А, а внутри группы – с возрастанием номера класса.
Группа D. Минимальная защита
Класс D. Минимальная защита. К этому классу относятся все системы, которые не удовлетворяют требованиям других классов.
Группа С. Дискреционная защита
Группа С характеризуется наличием произвольного управления доступом и регистрацией действий субъектов.
Класс С1. Дискреционная защита. Системы этого класса удовлетворяют требованиям обеспечения разделения пользователей и информации и включают средства контроля и управления доступом, позволяющие задавать ограничения для индивидуальных пользователей, что дает им возможность защищать свою приватную информацию от других пользователей. Класс С1 рассчитан на многопользовательские системы, в которых осуществляется совместная обработка данных одного уровня конфиденциальности.
Класс С2. Управление доступом. Системы этого класса осуществляют более гибкое управление доступом, чем системы класса С1, с помощью применения средств индивидуального контроля за действиями пользователей, регистрацией, учетом событий и выделением ресурсов.
Группа В. Мандатная защита
Основные требования этой группы – нормативное управление доступом с использованием меток безопасности, поддержка модели и политики безопасности. Для систем этой группы монитор взаимодействий должен контролировать все события в системе.
Класс В1. Защита с применением меток безопасности. Системы класса В1 должны соответствовать всем требованиям, предъявляемым к системам класса С2, и, кроме того, должны поддерживать определенную неформально модель безопасности, маркировку данных и нормативное управление доступом. При экспорте из системы информация должна подвергаться маркировке.
Класс В2. Структурированная защита. Для соответствия классу В2 вычислительная база компьютерного средства должна поддерживать формально определенную и четко документированную модель безопасности, предусматривающую произвольное и нормативное управление доступом, которое распространяется на все субъекты. По сравнению с классом В1 усилены средства аутентификации. Управление безопасностью осуществляется администраторами системы. Должны быть предусмотрены средства управления конфигурацией.
Класс В3. Домены безопасности. Для соответствия этому классу ядро защиты системы должно включать монитор взаимодействий, контролирующий все типы доступа субъектов к объектам, который невозможно обойти. Средства аудита включают механизмы оповещения администратора при возникновении событий, имеющих значение для безопасности системы. Требуется наличие средств восстановления работоспособности системы.
Группа А. Верифицированная защита
Данная группа характеризуется применением формальных методов верификации корректности работы механизмов управления доступом (произвольного и нормативного). Требуется дополнительная документация, демонстрирующая, что архитектура и реализация ядра защиты отвечают требованиям безопасности.
Класс А1. Формальная верификация. Системы класса А1 функционально эквивалентны системам класса В3, и к ним не предъявляется никаких дополнительных функциональных требований. В отличие от систем класса В3 в ходе разработки должны применяться формальные методы верификации, что позволяет с высокой уверенностью получить корректную реализацию функций защиты.
Приведенные классы безопасности надолго определили основные концепции безопасности и ход развития средств защиты. “Оранжевая книга” послужила основой для разработчиков всех остальных стандартов информационной безопасности и до сих пор используется в США в качестве руководящего документа при сертификации компьютерных систем обработки информации.
Статьи к прочтению:
- Классическая архитектура эвм ii принципы фон неймана
- Классификации тестирования.
Щерба Е.В. Модели безопасности компьютерных систем
Похожие статьи:
-
Политика безопасности в компьютерных системах.
Принципы хранения звук. и видео информации. Для записи-воспроизведения, а также использования различных данных на машиночитаемые носители данных…
-
Технология обеспечения безопасности компьютерных систем
Безопасность обработки данных зависит от безопасности использования компьютерных систем. Компьютерной системой называют совокупность аппаратных и…
Содержание
- Защита информации на уровне операционных систем
- Требования к защите информации
- Классы защищенности СВТ от НСД
- Требования безопасности информации к операционным системам
- Профили защиты операционных систем
- Встроенные механизмы и средства защиты ОС Windows Server 2012
- Разграничение полномочий для групп и учетных записей пользователей
- Разрешения на доступ к ресурсам для групп и учетных записей пользователей
- Локальная групповая политика (gpedit.msc)
- Локальная политика безопасности
- Защита реестра Windows
- Шифрующая файловая система EFS
- Средства безопасности сетевых подключений
Защита информации на уровне операционных систем
Требования к защите информации
Обеспечение защиты средств вычислительной техники (СВТ) и автоматизированных систем (АС) осуществляется системой разграничения доступа субъектов и объектов доступа, а также обеспечивающими средствами для этой системы.
Концепция защиты средств вычислительной техники и автоматизированных систем от несанкционированного доступа к информации утверждена решением Государственной технической комиссии при Президенте Российской Федерации от 30 марта 1992 г.
Способы реализации системы разграничения доступа (СРД) зависят от конкретных особенностей СВТ и АС. Возможно применение следующих способов защиты и любых их сочетаний:
- распределенная СРД и СРД, локализованная в программно-техническом комплексе (ядро защиты);
- СРД в рамках операционной системы, СУБД или прикладных программ;
- СРД в средствах реализации сетевых взаимодействий или на уровне приложений;
- использование криптографических преобразований или методов непосредственного контроля доступа;
- программная и (или) техническая реализация СРД.
В случае использования средств защиты от НСД в государственных информационных системах (ГИС) они должны быть сертифицированы минимум по 6 -ому классу. Средства вычислительной техники при этом должны быть сертифицированы не менее чем по 5 -ому классу.
Кроме того, в ГИС первого и второго классов защищенности средства защиты от НСД должны быть сертифицированы не ниже чем по 4 уровню контроля отсутствия недекларированных возможностей.
В информационных системах персональных данных (ИСПДн):
- в ИСПДн 1 уровня защищенности — средства защиты от НСД не ниже 4 класса, а СВТ — не ниже 5 класса;
- в ИСПДн 2 уровня защищенности — средства защиты от НСД не ниже 5 класса, а СВТ — не ниже 5 класса;
- в ИСПДн 3 уровня защищенности — средства защиты от НСД не ниже 6 класса, а СВТ — не ниже 5 класса;
- в ИСПДн 4 уровня защищенности — средства защиты от НСД не ниже 6 класса, а СВТ — не ниже 6 класса.
В ИСПДн первого и второго уровня защищенности должны использоваться средства защиты информации, также сертифицированные не ниже чем по 4 уровню контроля отсутствия недокументированных возможностей (НДВ).
Данные о сертификации средств защиты находится в Государственном реестре сертифицированных средств защиты информации, администрируемом ФСТЭК России. В частности, для продукции компании Microsoft имеем:
| № сертификата | Дата внесения в реестр | Срок действия сертификата | Предназначение средства (область применения), краткая характеристика параметров / (оценка возможности использования в ИСПДн) |
| 1929/1 | 14.05.2010 | 14.05.2019 | Microsoft Windows Server 2008 Enterprise Edition (SP2)– по 5 классу СВТ (может использоваться в 1Г и может использоваться для защиты информации в ИСПДн до 3 класса включительно) |
| 4006 | 29.08.2018 | 29.08.2023 | MS Windows Server 2016 — по 5 классу защищенности для СВТ |
| 4369 | 10.02.2021 | 10.02.2026 | ОС Microsoft Windows 10 в редакции Корпоративная — требования доверия (6), Требования к ОС, Профиль защиты ОС (А шестого класса защиты. ИТ.ОС.А6.ПЗ) |
Классы защищенности СВТ от НСД
ФСТЭК России устанавливает семь классов защищенности СВТ от НСД к информации. Самый низкий класс — седьмой, самый высокий — первый. Классы подразделяются на четыре группы, отличающиеся качественным уровнем защиты:
- первая группа содержит только один седьмой класс;
- вторая группа характеризуется дискреционной защитой и содержит шестой и пятый классы;
- третья группа характеризуется мандатной защитой и содержит четвертый, третий и второй классы;
- четвертая группа характеризуется верифицированной защитой и содержит только первый класс.
Требования безопасности информации к операционным системам
Требования безопасности информации к операционным системам утверждены приказом ФСТЭК России от 19 августа 2016 г. № 119 , вступили в силу с 1 июня 2017 г. Устанавливают 3 типа (А, Б, В) и 6 классов защиты ОС:
- Тип А – ОС общего назначения,
- Тип Б – встраиваемая ОС,
- Тип В – ОС реального времени.
6 класс – самый низкий, 1 класс – самый высокий
Операционные системы 6 класса защиты применяются в ГИС 3 и 4 классов защищенности, в АСУТП 3 класса защищенности, в ИСПДн при необходимости обеспечения 3 и 4 уровней защищенности персональных данных
Операционные системы 1, 2, 3 класса применяются в информационных системах, обрабатывающих государственную тайну.
Профили защиты операционных систем
Профили защиты операционных систем подробно рассмотрены в следующих методических документах ФСТЭК России:
- Методические документы. Профили защиты операционных систем типов «Б» и «В“. Утверждены ФСТЭК России 11 мая 2017 г.
- Методические документы. Профили защиты операционных систем типа «А“. Утверждены ФСТЭК России 8 февраля 2017 г.
Встроенные механизмы и средства защиты ОС Windows Server 2012
Операционная система Microsoft Windows Server 2012 имеет развитые встроенные механизмы и средства защиты, а именно:
- разграничение прав и полномочий пользователей с помощью учётных записей и групп;
- разграничение прав (разрешений) на доступ к объектам (на уровне объекта);
- локальная политика безопасности и групповые политики;
- защита реестра и ограничение прав доступа к нему;
- использование шифрующей файловой системы EFS и шифрование диска BitLocker;
- средства обеспечения безопасности сетевых подключений;
- средства аудита.
Разграничение полномочий для групп и учетных записей пользователей
Компьютеры, на которых установлена поддерживаемая версия Windows, могут контролировать использование системных и сетевых ресурсов с помощью взаимосвязанных механизмов аутентификации и авторизации. После аутентификации пользователя операционная система Windows использует встроенные технологии авторизации и контроля доступа для реализации второго этапа защиты ресурсов: определения, имеет ли аутентифицированный пользователь правильные разрешения для доступа к ресурсу.
Владельцы объектов обычно предоставляют разрешения группам безопасности, а не отдельным пользователям. Пользователи и компьютеры, добавленные в существующие группы, принимают разрешения этой группы. Если объект (например, папка) может содержать другие объекты (например, подпапки и файлы), он называется контейнером. В иерархии объектов связь между контейнером и его содержимым выражается ссылкой на контейнер как на родителя. Объект в контейнере называется дочерним, а дочерний объект наследует настройки контроля доступа родительского элемента. Владельцы объектов часто определяют разрешения для контейнерных объектов, а не отдельных дочерних объектов, чтобы упростить управление доступом.
Разрешения на доступ к ресурсам для групп и учетных записей пользователей
Общие ресурсы доступны пользователям и группам, отличным от владельца ресурса, и их необходимо защищать от несанкционированного использования. В модели управления доступом пользователи и группы (также называемые субъектами безопасности) представлены уникальными идентификаторами безопасности ( SID ). Им назначаются права и разрешения, которые информируют операционную систему о том, что может делать каждый пользователь и группа. Каждый ресурс имеет владельца, который предоставляет разрешения участникам безопасности. Во время проверки контроля доступа эти разрешения проверяются, чтобы определить, какие участники безопасности могут получить доступ к ресурсу и как они могут получить к нему доступ.
К общим ресурсам относятся файлы, папки, принтеры, разделы реестра и объекты доменных служб Active Directory ( AD DS ). Общие ресурсы используют списки контроля доступа ( ACL ) для назначения разрешений. Это позволяет администраторам ресурсов осуществлять контроль доступа следующими способами:
- запретить доступ неавторизованным пользователям и группам;
- установите четко определенные ограничения на доступ, который предоставляется авторизованным пользователям и группам.
Права доступа определяют тип доступа, который предоставляется пользователю или группе для объекта или свойства объекта. Используя пользовательский интерфейс управления доступом, можно установить разрешения NTFS для таких объектов, как файлы, объекты Active Directory, объекты реестра или системные объекты, такие как процессы. Разрешения могут быть предоставлены любому пользователю, группе или компьютеру. Рекомендуется назначать разрешения группам, поскольку это повышает производительность системы при проверке доступа к объекту.
Для любого объекта вы можете предоставить разрешения:
- группы, пользователи и другие объекты с идентификаторами безопасности в домене;
- группы и пользователи в этом домене и любые доверенные домены;
- локальные группы и пользователи на компьютере, где находится объект.
Права доступа к объекту зависят от типа объекта. Например, разрешения, которые можно прикрепить к файлу, отличаются от разрешений, которые можно прикрепить к разделу реестра. Однако некоторые разрешения являются общими для большинства типов объектов:
Когда устанавливаются разрешения, указываются уровни доступа для групп и пользователей. Например, можно разрешить одному пользователю читать содержимое файла, разрешить другому пользователю вносить изменения в файл и запретить всем другим пользователям доступ к файлу. Можно установить аналогичные разрешения для принтеров, чтобы определенные пользователи могли настраивать принтер, а другие пользователи могли только печатать.
Локальная групповая политика (gpedit.msc)
Политики параметров безопасности — это правила, которые можно настроить на компьютере или нескольких компьютерах для защиты ресурсов на компьютере или в сети. Расширение Параметры безопасности оснастки Редактор локальной групповой политики (Gpedit.msc) позволяет определять конфигурации безопасности как часть объекта групповой политики (GPO). Объекты групповой политики связаны с контейнерами Active Directory, такими как сайты, домены и организационные единицы, и позволяют администраторам управлять параметрами безопасности для нескольких компьютеров с любого компьютера, присоединенного к домену.
Настройки безопасности могут контролировать:
- аутентификацию пользователя в сети или на компьютере;
- ресурсы, к которым пользователям разрешен доступ;
- записывать ли действия пользователя или группы в журнал событий;
- членство в группе.
Для управления настройками безопасности для нескольких компьютеров можно использовать один из следующих вариантов:
- отредактировать определенные параметры безопасности в объекте групповой политики.
- использовать оснастку Шаблоны безопасности , чтобы создать шаблон безопасности, содержащий политики безопасности, которые вы хотите применить, а затем импортировать шаблон безопасности в объект групповой политики. Шаблон безопасности — это файл, представляющий конфигурацию безопасности, который можно импортировать в объект групповой политики, применить к локальному компьютеру или использовать для анализа безопасности.
Локальная политика безопасности
Помимо использования групповых политик безопасности Active Directory следует также использовать локальные политики, так как они затрагивают не только права пользователей, выполняющих вход через доменную учетную запись, но и локальные аккаунты. Для управления локальными политиками нужно использовать соответствующую оснастку Локальная политика безопасности , вызываемую командой secpol.msc ( Выполнить ( WIN+R )).
Например, при помощи локальной политики безопасности можно блокировать RDP-подключения для учетных записей с пустым паролем:
Computer Configuration — Настройки Windows — Настройки безопасности — Локальные политики безопасности — Параметры безопасности и включите (Enable) параметр Учетные записи: Разрешить использование пустых паролей только при консольном входе :
Защита реестра Windows
Реестр, а точнее разделы реестра, также относится к общим ресурсам Windows. Соответственно к ним также могут быть применены ограничения на доступ отдельных пользователей или групп:
Либо можно через редактор локальной групповой политики полностью запретить доступ к средствам редактирования реестра:
Нажать комбинацию клавиш Win+R , в окне редактирования следует ввести: gpedit.msc Откроется редактор локальной групповой политики. В нем в Конфигурация пользователя выбрать Административные шаблоны далее Система . Из списка найти пункт Запретить доступ к средствам редактирования реестра и кликнуть на нем дважды. Выбрать Включить и затем нажать ОК
Шифрующая файловая система EFS
Шифрованная система Encrypting File System (EFS) позволяет быстро зашифровать и поставить пароль на ваши файлы и папки в системе windows, используя собственную учетную запись пользователя. Поскольку файлы или папки были зашифрованы с использованием пароля учетной записи пользователя windows, другие пользователи на вашей системе, включая администратора, не может открыть, изменить или переместить папки, или файлы. Система EFS является полезной, если вы не хотите, чтобы другие пользователи смотрели ваши файлы и папки.
Encrypting File System и BitLocker это разные системы для шифрования. EFS считается менее безопасной, чем BitLocker. Любое лицо, знающее пароль учетной записи, под которой было произведено шифрование, может легко получить доступ к зашифрованной информации. Вы не сможете шифровать целые разделы диска, EFS работает только с файлами и папками, а BitLocker наоборот, только с дисками и съемными носителями.
Средства безопасности сетевых подключений
Операционная система Windows Server 2012 имеет развитые средства безопасности сетевых подключений:
- брандмауэр Windows в режиме повышенной безопасности;
- политика сети и удаленного доступа — служба маршрутизации и удалённого доступа;
- преобразование сетевых адресов NAT;
- криптографическая аутентификация, использование цифровых подписей и сертификатов безопасности;
- использование виртуальных частных сетей (VPN);
- шифрование передаваемых данных, возможность использования безопасного IP-протокола – Ipsec и протокола TLS.
Брандмауэр Windows позволяет создавать расширенные правила сетевых подключений для достаточно мощной защиты. Возможно создание правила доступа к Интернету для программ, белые списки, ограничивать трафик для определенных портов и IP адресов, не устанавливая сторонних программ-фаерволов для этого.
Подробнее средства безопасности сетевых подключений рассмотрены в материале Техническая защита информации в локальных и глобальных сетях»
Подборка по базе: Контрольная работа Вариант 1 Краткие сведения о якутском языке (, 01. Введение. Основные уравнения электродинамики.pdf, 1 Основные понятия и определения ИС.docx, 2 Б Классификация игр в дошкольной педагогике (1).ppt, Статья 3. Основные понятия, используемые в настоящем Федеральном, Издержки обращения и их классификация (9392066).docx, Вредители свеклы. Основные вредители свеклы. Меры борьбы с ними., Тема № 3.1 Классификация черезвычайных ситуаций природного и тех, 6. Негативное воздействие компьютера на здоровье человека и спос, МЕТОДИЧЕСКИЕ ОСНОВЫ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ
Практическая работа №12
Модель безопасности ОС Windows
Цель: изучить модель безопасности операционной системы Windows, получить навыки практического использования ее средств обеспечения безопасности.
1. Основные сведения
1.1. Классификация защиты семейства ОС Windows
Разработчики операционной системы Windows уделили серьезное внимание обес- печению безопасности работы пользователей. Это подтверждается категориями, присвоенными различным версиям данной операционной системы по тем или иным международным и национальным критериям оценки безопасности. Так, по классификации «Оранжевой книги» ОС Windows NT 4 еще в 1999 году получила класс безопасности C2, по стандарту ISO/IEC 15408 Common Criteria for
Information Technology Security Evaluation (Общие критерии оценки безопасности информаци-онных технологий) клиентские и серверные версии от Windows 2000 до
Windows 10, от
Windows Server 2008 до Windows Server 2013 получили уровень безопасности EAL4+, а операционные системы Windows 8, Windows Server 2012
Standard соот-ветствуют требованиям руководящего документа «Средства вычислительной тех-ники. Защита от несанкционированного доступа к информации. Показатели защи-щенности от несанкционированного доступа к информации» (Гостехкомиссия Рос-сии.1992) по 5 классу защищенности.
Какие средства безопасности предоставляют операционные семейства можно представить, если, например, познакомиться с требованиями оценки безопасности
C2 «Оранжевой книги». Согласно им, система должна обеспечивать:
средство безопасного входа в систему, которое обеспечивают точную идентификацию пользователей и предоставляют им возможности доступа к ресур-
сам компьютера только после прохождения процедуры аутентификации.
В Windows за идентификацию и аутентификацию пользователей отвечают процес- сы Winlogon.exe и Lsass.exe.
управление доступом, позволяющее владельцу ресурса (файла, раздела реестра, объекта ядра и др.) определить, кто имеет права на доступ к ресурсу, а также уточнить суть этих прав (чтение, изменение, запуск и т.п.). При использова- нии дискреционной модели доступа для уплотнения матрицы доступа владелец может наделять правами, разрешающими различные виды доступа к объекту, как
отдельного пользователя,
так группу пользователей.
Безопас- ный доступ реализуется в Windows компонентом Security Reference
Monitor
(SRM, монитор контроля безопасности) исполнительной системы Ntoskrnl.exe.
аудит безопасности, позволяющий регистрировать события, относящи- еся к вопросам безопасности. Идентификация пользователей при входе в систему позволяет привязывать все события безопасности в системе к конкретному пользо- вателю. В Windows аудит поддерживается SRM и Lsass.exe.
защита от повторного использования объекта, которая не позволяет пользователям просматривать данные, удаленные другим пользователем, или не
3
позволяет обращаться к памяти, которая ранее была использована, а затем осво- бождена другим пользователем. В Windows освобожденная память очищается системным потоком обнуления страниц, работающим во время простоя системы (с нулевым приоритетом).
1.2. Идентификация пользователей
Для защиты данных 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;
4
—
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
Название
Описание
S-1-1-0
Все
Группа, в которую входят все пользователи
S-1-5-2
Сеть
Группа, в которую входят все пользовате- ли, зарегистрировавшиеся в системе из се- ти
S-1-5-7
Анонимный вход
Группа, в которую входят все пользовате-
5
ли, вошедшие в систему анонимно
S-1-5-домен-500
Администратор
Учетная запись администратора системы.
По умолчанию только эта запись обеспечи- вает полный контроль системы
S-1-5-домен-501
Гость
Учетная запись пользователя-гостя
Полный список общеизвестных SID можно посмотреть в документации
Platform SDK. Узнать SID конкретного пользователя в системе, а также SID групп, в которые он включен, можно, используя консольную команду whoami:
whoami /user /sid
Соответствие имени пользователя и его SID можно отследить также в ключе реестра HKLMSOFTWAREMicrosoftWindows NTCurrentVersion ProfileList.
После аутентификации пользователя процессом Winlogon, все процессы, за- пущенные от имени этого пользователя будут идентифицироваться специальным объектом, называемым маркером доступа (access token). Если процесс пользова- теля запускает дочерний процесс, то его маркер наследуются, поэтому маркер до- ступа олицетворяет пользователя для системы в каждом запущенном от его имени процессе. Основные элементы маркера представлены на рис. 1.
SID пользо-
SID1 … SIDn
DACL по
Привилегии
Прочие па-
вателя
Идентификаторы
умолчанию
раметры
групп пользователя
Рисунок 1. Обобщенная структура маркера доступа.
Маркер доступа содержит идентификатор доступа самого пользователя и всех групп, в которые он включен. В маркер включен также DACL по умолчанию — первоначальный список прав доступа, который присоединяется к создаваемым пользователем объектам. Еще одна важная для определения прав пользователя в системе часть маркера – список его привилегий. Привилегии — это права доверен- ного объекта на совершение каких-либо действий по отношению ко всей системе.
В таблице 2 перечислены некоторые привилегии, которые могут быть предостав- лены пользователю.
Таблица 2. Привилегии, которыми могут быть наделены пользователи
Имя и идентифика-
Описание привилегии тор привилегии
Увеличение приоритета
Пользователь, обладающий данной привилегией может изменять диспетчирования приоритет диспетчирования процесса с помощью интерфейса Дис-
SeIncreaseBasePriorityPrivilege петчера задач
Закрепление страниц в
Процесс получает возможность хранить данные в физической па- памяти мяти, не прибегая к кэшированию данных в виртуальной памяти на
SeLockMemoryPrivilege диске.
Управление аудитом и
Пользователь получает возможность указывать параметры аудита журналом безопасности доступа к объекту для отдельных ресурсов, таких как файлы, объ-
SeAuditPrivilege екты Active Directory и разделы реестра.
6
Овладение файлами или
Пользователь получает возможность становиться владельцем лю- иными объектами бых объектов безопасности системы, включая объекты Active
SeTakeOwnershipPrivilege
Directory, файлы и папки NTFS, принтеры, разделы реестра, служ- бы, процессы и потоки
Завершение работы си-
Пользователь получает возможность завершать работу операцион- стемы ной системы на локальном компьютере
SeShutdownPrivilege
Обход перекрестной
Используется для обхода проверки разрешений для промежуточ- проверки ных каталогов при проходе многоуровневых каталогов
SeChangeNotifyPrivilege
Управление привилегиями пользователей осуществляется в оснастке
«Групповая политика»,раздел Конфигурация Windows/Локальные полити-
ки/Назначение прав пользователя.
Чтобы посмотреть привилегии пользователя, можно также использовать команду
whoami /all
Остальные параметры маркера носят информационный характер и опреде- ляют, например, какая подсистема создала маркер, уникальный идентификатор маркера, время его действия. Необходимо также отметить возможность создания ограниченных маркеров (restricted token), которые отличаются от обычных тем, что из них удаляются некоторые привилегии и его SID-идетификаторы проверяются только на запрещающие правила. Создать ограниченный маркер можно программ- но, используя API-функцию CreateRestrictedToken, а можно запустить процесс с ограниченным маркером, используя пункт контекстного меню Windows “Запуск
от имени другого пользователя” (рис.2).
Рисунок 2. Запуск процесса с ограниченным маркером
Ограниченные маркеры используются для процессов, подменяющих клиен-та и выполняющих небезопасный код.
Маркер доступа может быть создан не только при первоначальном входе пользователя в систему. Windows предоставляет возможность запуска процессов от
7
имени других пользователей, создавая для этих процессов соответствующий мар- кер. Для этих целей можно использовать:
— API-функции CreateProcessAsUser, CreateProcessWithLogon;
— оконный интерфейс (рис.2), инициализирующийся при выборе пункта кон- текстного меню “Запуск от имени другого пользователя”;
— консольную команду runas:
runas /user:имя_пользователя program,
где имя_пользователя — имя учетной записи пользователя, которая будет использо-вана для запуска программы в формате пользователь@домен или
доменпользова-тель;
program –команда или программа,которая будет запущена с помощью учетнойзаписи, указанной в параметре /user.
В любом варианте запуска процесса от имени другой учетной записи необхо-димо задать ее пароль.
1.3. Защита объектов системы.
Маркер доступа идентифицирует субъектов-пользователей системы. С другой стороны, каждый объект системы, требующий защиты, содержит описание прав доступа к нему пользователей. Для этих целей используется дескриптор безопас-
ности (Security Descriptor, SD).Каждому объекту системы,включая файлы,прин- теры, сетевые службы, контейнеры Active Directory и другие, присваивается де- скриптор безопасности, который определяет права доступа к объекту и содержит следующие основные атрибуты (рис.3):
— SID владельца, идентифицирующий учетную запись пользователя-владельца объекта;
— пользовательский список управления доступом (Discretionary Access Control
List, DACL), который позволяет отслеживать права и ограничения, установленные владельцем данного объекта. DACL может быть изменен пользователем, который указан как текущий владелец объекта.
— системный список управления доступом (System Access Control List, SACL), определяющий перечень действий над объектом, подлежащих аудиту;
— флаги, задающие атрибуты объекта.
Авторизация Windows основана на сопоставлении маркера доступа субъекта с дескриптором безопасности объекта. Управляя свойствами объекта, администрато- ры могут устанавливать разрешения, назначать право владения и отслеживать до- ступ пользователей.
8
ACL
Версия
SD
SID владельца
размер
редакция
SID группы
число записей
ACE [1]
DACL
ACE […]
SACL
ACE [n]
Объект
Флаги
ACE
Идентификатор
Права
Тип
Механизм
безопасности
доступа
записи
наследования
Рисунок 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.
9
запрос
Маркер
R/W
SRM
доступа
SID 100
Груп-
SID 201
SID 202
пы
SID 205
Запрос от-
Процесс
клонен!
Объект
DACL
SID 78
_W
Deny
SID 201
_WX
Deny
SID 79
_RW
Allow
SID 100
_R
Allow
SID 205
_W
Allow
Рисунок 4. Проверка прав доступа пользователя к объекту
Необходимо отметить, что запрещающее правило помещено в списке DACL на рисунке не случайно. Запрещающие правила всегда размещаются перед разре- шающими, то есть являются доминирующими при проверке прав доступа.
Для определения и просмотра прав доступа пользователей к ресурсам можно использовать как графические средства контроля, так и консольные команды.
Стандартное окно свойств объекта файловой системы (диска, папки, файла) на вкладке Безопасность (рис. 5) позволяет просмотреть текущие разрешения для пользователей и групп пользователей, редактировать их, создавать новые или уда- лять существующие.
Запрещающие ACE
Разрещающие ACE
Рисунок 5 – GUI-интерфейс Windows для изменения прав доступа к объектам
При определении прав доступа к объектам можно задать правила их наследо- вания в дочерних контейнерах. В окне дополнительных параметров безопасности
10
на вкладке Разрешения при выборе опции «Добавлять разрешения, наследуе-
мые от родительских объектов» (рис. 6)можно унаследовать разрешения и огра- ничения, заданные для родительского контейнера, текущему объекту.
Унаследовать права от родителя
Передать права дочер- ним объектам
Рисунок 6 – Определение параметров наследования прав доступа к объектам
При выборе опции «Применять эти разрешения к объектам и контейнерам
только внутри этого контейнера» разрешается передача определенных для объ- екта-контейнера правил доступа его дочерним объектам.
В этом же окне на вкладке Владелец допустимо узнать владельца объекта и заменить его. Владелец объекта имеет право на изменение списка его DACL, даже если к нему запрещен любой тип доступа. Администратор имеет право становиться владельцем любого объекта.
С учетом возможности вхождения пользователя в различные группы и неза- висимости определения прав доступа к объектам для групп и пользователей, зача- стую бывает сложно определить конечные права пользователя на доступ к объекту: требуется просмотреть запрещающие правила, определенные для самого объекта, для всех групп, в которые он включен, затем то же проделать для разрешающих правил. Автоматизировать процесс определения разрешенных пользователю видов доступа к объекту можно с использованием вкладки «Действующие разрешения» окна дополнительных параметров безопасности объекта (рис. 7).
11
Имя пользователя или группы
Разрешения на доступ к объекту для выбранного пользователя или группы
Рисунок 7 – Определение эффективных прав доступа пользователя (группы) к объекту
Для просмотра и изменения прав доступа к объектам в режиме командной строки предназначена команда icacls (cacls в Windows XP).
icacls имя_файла[/t] [/e] [/c] [/g пользователь:разрешение] [/r пользователь
[…]] [/p пользователь:разрешение […]] [/d пользователь […]]
Назначения параметров команды приведены в таблице 3.
Таблица 3. Параметры команды cacls
<имя файла>
Задаёт файл или папку, права доступа к которой необхо- димо просмотреть/изменить (допустимо использовать шаблоны с символами * и ?).
/t
Изменение избирательных таблиц контроля доступа
(DACL) указанных файлов в текущем каталоге и всех под- каталогах
/e
Редактирование избирательной таблицы управления до- ступом (DACL) вместо ее замены
/c
Заставляет команду продолжить изменение прав доступа при возникновении ошибки, связанной с нарушениями прав доступа
/g <пользователь |
Предоставление прав доступа указанному пользователю группа: разрешение>
/r <пользователь |
Отнимает права доступа указанного пользователя.
группа>
/p <пользователь |
Заменяет права доступа указанного пользователя группа: разрешение>
/d <пользователь |
Отказывает в праве доступа указанному пользователю или группа>
группе
Для указания добавляемых или отнимаемых прав используются следующие значения:
F — полный доступ;
12
C — изменение (запись);
W — запись;
R — чтение;
N — нет доступа.
Рассмотрим несколько примеров.
icacls d:test
Выдаст список DACL для папки test.
icacls d:test /d ИмяКомпьютераИмяПользователя /e
Запретит доступ к объекту для указанного пользователя.
icacls d:test /p ИмяКомпьютераИмяГруппы:f /e /t
Предоставит полный доступ к папке d:test и ее подпапках всем для членов указанной группы.
Для программного просмотра и изменения списков DACL можно использо- вать API-функции AddAccessAllowedAce, AddAccessDeniedAce, SetSecurityInfo.
Подробнее с этими функциями и примерами их использования можно ознакомить- ся в [3].
Рассмотренные способы работы с дискреционным списком доступа иллю- стрируют реализацию в Windows модели произвольного доступа. Но начиная с
Windows Vista фирма Microsoft реализовала элементы мандатного доступа для кон- троля доступа к объектам. За этот уровень обеспечения безопасности отвечает
Windows Integrity Control (WIC).КонцепцияWICвторит уже рассмотренным выше принципами принудительного (мандатного) управления доступом и основана на построении доверительных отношений между объектами и управлении действиями с ними пользователей на основе их уровня доверия. Базовым понятием WIC явля- ется уровень целостности (integrity level) объекта. WIC присваивает контролируе- мым объектам один из шести доступных уровней целостности:
Untrusted —анонимные процессы автоматически попадают в эту категорию.
Low —стандартный уровень при работе с Интернетом.Если браузерInternet
Explorer запущен в защищенном режиме, все файлы и процессы, ассоциированные
с ним, назначаются в эту категорию. Некоторые папки, такие как, например,
Temporary Internet Folder, также по умолчанию наделяются Низким уровнем дове-
рия.
Medium —в данном контексте работает большинство объектов.Ординарные пользователи получают Средний уровень, всем объектам присваивается данный уровень доступа, если не указан какой-либо иной.
High —уровень,ассоциированный в системе сАдминистраторами.Объек- ты Высокоо уровня недоступны обычным пользователям.
System —уровень для работы ядра операционной системы и его служб.
Installer —вершина в иерархии уровнейWIC.Его объекты могут изменять и удалять файлы всех предыдущих уровней.
Контроль по уровням целостности при доступе к объекту также осуществля- ется на основе правил ACE. Но это специализированные ACE, которые начиная с
13
Windows Vista хранятся в списке SACL дескриптора безопасности объекта наряду с правилами аудита. Уровень целостности пользователя (процесса, выполняющегося от его имени) хранится в его токене безопасности. При доступе процесса к объекту монитор безопасности сравнивает уровень целостности в токене с уровнем целост- ности в дескрипторе объекта (в SACL). Система выдает права доступа в зависимо- сти от того выше или ниже уровень целостности субъекта по отношению к объек- ту, а также в зависимости от флагов политики целостности в соответствующей
ACE объекта. Уровни целостности (IL) пользователя описываются в его идентифи- каторе безопасности, точнее – в его RID-части:
SID = S-1-16-0x0 — уровень Untrusted
SID = S-1-16-0x1000 — уровень Low
SID= S-1-16-0x2000 – уровень Medium
SID= S-1-16-0x3000 – уровень High
SID= S-1-16-0x4000 – уровень системы
Для изменения уровня целостности объектов можно использовать следую-щие инструменты:
— уже рассмотренную команду icacls с ключом /setintegitylevel. Например, вот так можно присвоить файлу низкий (l) уровень целостности:
icacls f:temp /setintegritylevel l
— используя специальные утилиты Chml («change mandatory label» ) для изме-нения уровня целостности файлов и папок, и Regil («Registry integrity levels») для работы с уровнями целостности ключей реестра.
Изменить уровень целостности процесса можно, например, запустив его ути-литой psexec.exe с соответствующим ключом. Вот как можно запустить блокнот с высоким уровнем целостности:
psexec –h notepad.exe
Очевидно, что изменять уровень целостности запускаемых процессов потен- циально небезопасная операция, поэтом ее могут запускать только процессы, у ко- торых в маркере доступа установлена привилегия
SeRelabelPrivilege
Узнать, каким уровнем целостности обладает процесс можно, например, за-пустив утилиту ProcessExplorer из набора Sysinternals [6] (рис. 8).
Рисунок 8 – Уровень целостности запущенных процессов в интерфейсе ProcessExplorer
14
Необходимо отметить, что контроль уровней целостности имеет более высо-кий приоритет при проверке прав доступа к объекту перед дискреционной табли-цей.
1.4. Подсистема аудита.
Важный элемент политики безопасности – аудит событий в системе. ОС
Windows ведет аудит событий по 9 категориям:
1. Аудит событий входа в систему.
2. Аудит управления учетными записями.
3. Аудит доступа к службе каталогов.
4. Аудит входа в систему.
5. Аудит доступа к объектам.
6. Аудит изменения политики.
7. Аудит использования привилегий.
8. Аудит отслеживания процессов.
9. Аудит системных событий.
Рассмотрим более подробно, какие события отслеживает каждая из катего- рий.
Аудит событий входа в систему
Аудит попыток пользователя войти в систему с другого компьютера или выйти из нее, при условии, что этот компьютер используется для проверки под- линности учетной записи.
Аудит управления учетными записями
Аудит событий, связанных с управлением учетными записями на компьюте- ре: создание, изменение или удаление учетной записи пользователя или группы; переименование, отключение или включение учетной записи пользователя; задание или изменение пароля.
Аудит доступа к службе каталогов
Аудит событий доступа пользователя к объекту каталога Active Directory, для которого задана собственная системная таблица управления доступом (SACL).
Аудит входа в систему
Аудит попыток пользователя войти в систему с компьютера или выйти из нее.
Аудит доступа к объектам
Аудит событий доступа пользователя к объекту – например, к файлу, папке, разделу реестра, принтеру и т. п., — для которого задана собственная системная таб-лица управления доступом (SACL).
Аудит изменения политики
Аудит фактов изменения политик назначения прав пользователей, политик аудита или политик доверительных отношений.
15
Аудит использования привилегий
Аудит попыток пользователя воспользоваться предоставленным ему правом.
Аудит отслеживания процессов
Аудиту таких событий, как активизация программы, завершение процесса, повторение дескрипторов и косвенный доступ к объекту.
Аудит системных событий
Аудит событий перезагрузки или отключения компьютера, а также событий, влияющих на системную безопасность или на журнал безопасности.
Решения об аудите конкретного типа событий безопасности принимаются в соответствии с политикой аудита локальной системы. Политика аудита, также называемая локальной политикой безопасности (local security policy), является ча- стью политики безопасности, поддерживаемой LSASS в локальной системе, и настраивается с помощью редактора локальной политики безопасности (Оснастка
gpedit.msc, Конфигурация компьютера — Конфигурация Windows – Параметры
безопасности – Локальные политики – Политика аудита, рис. 9).
Рисунок 9 – Конфигурация политики аудита редактора локальной политики безопасности
Для каждого объекта в SD содержится список SACL, состоящий из записей
ACE, регламентирующих запись в журнал аудита удачных или неудачных попыток доступа к объекту. Эти АСЕ определяют, какие операции, выполняемые над объек- тами конкретными пользователями или группами, подлежат аудиту. Информация аудита хранится в системном журнале аудита. Аудиту могут подлежать как успеш- ные, так и неудачные операции. Подобно записям ACE DACL, правила аудита объ- ектов могут наследоваться дочерними объектами. Процедура наследования опре- деляются набором флагов, являющихся частью структуры ACE.
Настройка списка SACL может быть осуществлена в окне дополнительных свойств объекта (пункт “Дополнительно”, закладка “Аудит”, рис. 10).
16
записи ACE списка
SACL объекта параметры наследования
ACE (аналогично DACL)
Рисунок 10 – Интерфейс редактирования правил аудита для объекта
Для программного просмотра и изменения списков SACL можно использовать API-функции GetSecutityInfo и SetSecutityInfo.
При инициализации системы и изменении политики LSASS посылает SRM сообщения, информирующие его о текущей политике аудита. LSASS отвечает за прием записей аудита, генерируемых на основе событий аудита от SRM, их редак- тирование и передачу Event Logger (регистратору событий). SRM посылает записи аудита LSASS через свое LPC-соединение. После этого Event Logger заносит запи- си в журнал безопасности.
Начиная с Windows Vista поддерживаются две категории журналов событий:
журналы Windows и журналы приложений и служб. Журналы Windows –
регистрируют общесистемных событий, и ведутся самой ОС. Журналы приложе-
ний и служб –индивидуальны для конкретных типов приложений и компонент
(Internet Explorer, MediaCenter, PoerShell и др.). События аудита записываются в журналы Windows следующих типов (на примере Windows 7):
1. Журнал приложений. В журнале приложений содержатся данные,относя- щиеся к работе приложений и программ.
2. Журнал безопасности. Журнал безопасности содержит записи о таких со- бытиях, как успешные и безуспешные попытки доступа в систему, а также о собы- тиях, относящихся к использованию ресурсов.
3. Журнал системы. В журнале системы содержатся события системных ком- понентов Windows. Например, в журнале системы регистрируются сбои при за- грузке драйвера или других системных компонентов при запуске системы.
4. Журнал установки. Фиксирует события,связанные с установкой или уда- лением компонент системы.
5. Журнал перенаправления. Фиксирует события,перенаправленные с со- седних компьютеров.
Просмотр журнала безопасности осуществляется в оснастке «Просмотр со- бытий» (eventvwr.msc, рис. 11). Сами журналы хранятся в файлах с расширением evtx в папке %SystemRoot%System32WinevtLogs.
17
Информационное сообщение
Сообщение об ошиб- ке
Предупреждающее сообщение
Рисунок 11. Оснастка Windows «Просмотр событий»
В журнал записываются события различных типов:
—
Сведение –сигнализирует об изменении в приложении или компоненте,
например, успешном доступе к ресурсу, запуске приложения или службы;
—
Предупреждение –сигнализирует о потенциально опасном событии,воз- никшем в приложении или компоненте, которые не мешают его работе, но могут стать причиной проблем в будущем;
—
Ошибка –сигнализирует о проблему,сказывающемся на окружени прило- жения или компонента, вызвавших событие;
—
Критическая ошибка -соответствует сбою,критичному для приложения или компонента, после которого они не могут продолжать работу;
1.5. Шифрующая файловая система.
Начиная с версии 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 – добавляется в заголовок зашифрованного файла (рис. 12). Такой подход обеспечивает надежное шифрование без потери эф- фективности процесса шифрования: данные шифруются быстрым симметричным
18
алгоритмом, а для гарантии секретности симметричного ключа используется асим- метричный алгоритм шифрования.
Файл, зашифро-
Открытый ключ
FEK
ванный EFS
пользователя (RSA)
DDF
Зашифрован-
ный файл
Шифрование данных
(DESX или AES)
Файл на диске
FEK
DRF
Открытый ключ аген-
та восстановления
RSA)
Рисунок 12. Схема шифрации файла в EFS
Для шифрации файлов с использованием EFS можно использовать графиче- ский интерфейс или команду cipher.
Графический интерфейс доступен в стандартном окне свойств объекта по нажатию кнопки «Дополнительно» (рис. 13). Зашифрованные объекты в стан- дартном интерфейсе Windows Explorer отображаются зеленым цветом.
Рисунок 13 – Графический интерфейс шифрования файла с использованием EFS
Необходимо отметить, что EFS позволяет разделять зашифрованный файл между несколькими пользователями. В этом случае FEK шифруется открытыми ключами всех пользователей, которым разрешен доступ к файлу, и каждый резуль- тат шифрации добавляется в DDF.
Шифрование файла с использованием EFS защищает файл комплексно: поль- зователю, не имеющему права на дешифрацию файла, недопустимы, в том числе, такие операции, как удаление, переименование и копирование файла. Необходимо помнить, что EFS является частью файловой системы NTFS, и в случае копирова-
19
ния защищенного файла авторизованным пользователем на другой том с файловой системой, на поддерживающей EFS (например, FAT32), он будет дешифрован и сохранен на целевом томе в открытом виде.
Консольная команда cipher может быть использована для шифра- ции/дешифрации файлов из командной строки или в bat-сценарии.
cipher [{/e|/d}] [/s:каталог] [/a] [/i] [/f] [/q] [/h] [/k] [/u[/n]] [путь[…]] |
[/r:имя_файла_без_расширения]
Назначения параметров команды приведены в таблице 4.
Таблица 4. Параметры команды cipher
/e
Шифрует указанные папки. Папки помечаются таким образом, что- бы файлы, которые будут добавляться в папку позже, также шифро- вались.
/d
Расшифровывает указанные папки. Папки помечаются таким обра- зом, чтобы файлы, которые будут добавляться в папку позже, не бу- дут шифроваться
/s:
каталог
Выполняет выбранную операцию над указанной папкой и всеми подпапками в ней.
/a
Выполняет операцию над файлами и каталогами
/i
Продолжение выполнения указанной операции даже после возник- новения ошибок. По умолчанию выполнение cipher прекращается после возникновения ошибки
/f
Выполнение повторного шифрования или расшифровывания ука- занных объектов. По умолчанию уже зашифрованные или расшиф- рованные файлы пропускаются командой cipher
/k
Создание ключа шифрования файла для пользователя, выполнивше- го команду cipher. Если используется данный параметр, все осталь- ные параметры команды cipher не учитываются.
/u
Обновление ключа шифрования файла пользователя или ключа агента восстановления на текущие ключи во всех зашифрованных файлах на локальном диске (если эти ключи были изменены). Этот параметр используется только вместе с параметром /n.
/n
Запрещение обновления ключей. Данный параметр служит для по- иска всех зашифрованных файлов на локальных дисках. Этот пара- метр используется только вместе с параметром /u.
путь
Указывает шаблон, файл или папку.
/r:
имя_файла
Создание нового сертификата агента восстановления и закрытого ключа с последующей их записью в файлах с именем, указанным в параметре имя_файла (без расширения). Если используется данный параметр, все остальные параметры команды cipher не учитывают- ся.
Например, чтобы определить, зашифрована ли какая-либо папка, необходимо использовать команду:
cipher путьимя_папки
20
Команда cipher без параметров выводит статус (зашифрован или нет) для всех объектов текущей папки.
Для шифрации файла необходимо использовать команду
cipher /e /a путьимя_файла
Для дешифрации файла, соответственно, используется команда
cipher /d /a путьимя_файла
Допустима шифрация/дешифрация группы файлов по шаблону:
cipher /e /a d:work*.doc
Пара открытый и закрытый ключ для шифрации FEK создаются для пользо- вателя автоматически при первой шифрации файла с использованием EFS.
Если некоторый пользователь или группа пользователей зашифровали файл с использованием EFS, то его содержимое доступно только им. Это приводит к рис- кам утери доступа к данным в зашифрованных файлах в случае утраты пароля дан- ным пользователем (работник забыл пароль, уволился и т.п.). Для предотвращения подобных проблем администратор может определить некоторые учетные записи в качестве агентов восстановления.
Агенты восстановления (Recovery Agents) определяются в политике без- опасности Encrypted Data Recovery Agents (Агенты восстановления шифро-
ванных данных) на локальном компьютере или в домене.Эта политика доступна через оснастку Групповая политика (gpedit.msc) раздел «Параметры безопасно-
сти»-> «Политика открытого ключа»-> «Файловая система EFS». Пункт меню
«Действие»-> «Добавить агент восстановления данных» открывает мастер до- бавления нового агента.
Добавляя агентов восстановления можно указать, какие криптографические пары (обозначенные их сертификатами) могут использовать эти агенты для восста- новления шифрованных данных (рис. 14). Сертификаты для агентов восстановле- ния создаются командой cipher с ключом /r (см. табл. 4). Для пользователя, кото- рый будет агентом восстановления, необходимо импортировать закрытый ключ агента восстановления из сертификата, созданного командой cipher. Это можно сделать в маcтере импорта сертификатов, который автоматически загружается при двойном щелчке по файлу *.pfx.
EFS создает DRF (Data Recovery Field) – элементы ключей для каждого агента восстановления, используя провайдер криптографических сервисов, зареги- стрированный для EFS-восстановления. DRF добавляется в зашифрованный файл и может быть использован как альтернативное средство извлечения FEK для дешиф- рации содержимого файла.
21
Рисунок 14. Добавление нового агента восстановления EFS
Windows хранит закрытые ключи в подкаталоге Application DataMicro-softCryptoRSA
каталога профиля пользователя. Для защиты закрытых ключей Windows шифрует все файлы в папке RSA на основе симметричного ключа, генерируемого случай- ным образом; такой ключ называется мастер-ключом пользователя. Мастер-ключ имеет длину в 64 байта и создается стойким генератором случайных чисел. Ма- стер-ключ также хранится в профиле пользователя в каталоге
Application
DataMicrosoftProtect и зашифровывается по алгоритму 3DES с помощью ключа,
который отчасти основан на пароле пользователя. Когда пользователь меняет свой пароль, мастер-ключи автоматически расшифровываются, а затем заново зашифро- вываются с учетом нового пароля.
Для расшифровки FEK EFS использует функции Microsoft CryptoAPl (CAPI).
CryptoAPI состоит из DLL провайдеров криптографических сервисов (cryptographic service providers, CSP), которые обеспечивают приложениям доступ к различным криптографическим сервисам (шифрованию, дешифрованию и хэшированию). EFS опирается на алгоритмы шифрования RSA, предоставляемые провайдером
Microsoft Enhanced Cryptographic Provider.
Шифрацию и дешифрацию файлов можно осуществлять программно, ис- пользуя API-функции EncryptFile и DecryptFile.
2. Порядок выполнения работы.
2.1. Ознакомьтесь с теоретическими основами защиты информации в ОС се- мейства Windows в настоящих указаниях и конспектах лекций.
2.2. Выполните задания 2.2.1-2.2.8 2.2.1. При выполнении лабораторной работы запустите в программе Oracle
VM Virtualbox виртуальную ма-шину Win7Test. Войдите в систему под учетной записью администратора. Все действия в пп 2.2.1-2.2.8 выполняйте в системе, рабо-тающей на виртуальной машине.
2.2.2. Создайте учетную запись нового пользователя testUser в оснаст-ке
«Управление компьютером» (compmgmt.msc). При создании новой учетной
22
записи запретите пользователю смену пароля и снимите ограничение на срок дей- ствия его пароля. Создайте новую группу ”testGroup” и включите в нее нового пользователя. Удалите пользователя из других групп. Создайте на диске С: папку
forTesting.Создайте или скопируйте в эту папку несколько текстовых файлов
(*.txt).
2.2.3. С помощью команды runas запустите сеанс командной строки
(cmd.exe) от имени вновь созданного пользователя. Командой whoami посмотрите
SID пользователя и всех его групп, а также текущие привилегии пользователя.
Строку запуска и результат работы этой и
всех
следующих консольных команд копируйте в файл протокола лабораторной работы.
2.2.4.
Убедитесь в соответствии имени пользователя и полученного SID
в реестре Windows. Найдите в реестре, какому пользователю в системе присвоен
SID S-1-5-21-1957994488-492894223-170857768-1004 (Используйте ключ реестра
HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList).
2.2.5. Командой whoami определите перечень текущих привилегий пользователя testUser. В сеансе командной строки пользователя попробуйте изме- нить системное время командой time. Чтобы предоставить пользователю подобную привилегию, запустите оснастку «Локальные параметры безопасности»
(secpol.msc). Добавьте пользователя в список параметров политики «Изменение
системного времени» раздела Локальные политики -> Назначение прав поль-
зователя.После этого перезапустите сеанс командной строки от имени пользова- теля, убедитесь, что в списке привилегий добавилась SeSystemtimePriviege. По- пробуйте изменить системное время командой time.
Убедитесь, что привилегия «Завершение работы системы» (SeShutdown-
Privilege) предоставлена пользователюtestUser .После этого попробуйте завер- шить работу системы из сеанса командной строки пользователя командой shut-
down –s.Добавть ему привелегию «Принудительное удаленное завершение»
(SeRemoteShutdownPrivilege).Попробуйте завершить работу консольной коман- дой еще раз (отменить команду завершения до ее непосредственного выполнения можно командой shutdown –a).
2.2.6. Ознакомьтесь с справкой по консольной команде icacls. Используя эту команду, просмотрите разрешения на папку c:forTesting. Объясните все обозначе- ния в описаниях прав пользователей и групп в выдаче команды. а) Разрешите пользователю testUser запись в папку forTesting, но запретите запись для группы testGroup. Попробуйте записать файлы или папки в forTesting от имени пользователя testUser. Объясните результат. Посмотрите эффективные разрешения пользователя testUser к папке forTesting в окне свойств папки. б) Используя стандартное окно свойств папки, задайте для пользователя tes-
tUser такие права доступа к папке,чтобы он мог записывать информацию в папку
forTesting,но не мог просматривать ее содержимое.Проверьте,что папка
forTesting является теперь для пользователя testUser “слепой”,запустив,напри- мер, от его имени файловый менеджер и попробовав записать файлы в папку, про- смотреть ее содержимое, удалить файл из папки. в) Для вложенной папки forTestingDocs отмените наследование ACL от родителя и разрешите пользователю просмотр, чтение и запись в папку. Проверьте, что для пользователя папка forTestingDocs перестала быть “слепой” (например,
23
сделайте ее текущей в сеансе работы файлового менеджера от имени пользователя и создайте в ней новый файл).
г) Снимите запрет на чтение папки forTesting для пользователя testUser.
Используя команду icacls запретите этому пользователю доступ к файлам с расши- рением txt в папке forTesting. Убедитесь в недоступности файлов для пользовате- ля.
д) Командой icacls запретите пользователю все права на доступ к папке
forTesting и разреште полный доступ к вложенной папке forTestingDocs.Убеди- тесь в доступности папки forTestingDocs для пользователя. Удалите у пользовате- ля testUser привилегию SeChangeNotifyPrivilege. Попробуйте получить доступ к папке forTestingDocs. Объясните результат.
е) Запустите файловый менеджер от имени пользователя testUser и создайте в нем папку newFolder на диске C. Для папки newFolder очистите весь список
ACL командой cacls. Попробуйте теперь получить доступ к папке от имени адми- нистратора и от имени пользователя. Кто и как теперь может вернуть доступ к пап- ке? Верните полный доступ к папке для всех пользователей. ж) Создайте в разделе HKLMSoftware реестра раздел testKey. Запретите пользователю testUser создание новых разделов в этом разделе реестра. Создайте для раздела HKLMSoftwaretestKey SACL, позволяющий протоколировать отка- зы при создании новых подразделов, а также успехи при перечислении подразде- лов и запросе значений (предварительно проверьте, что в локальной политике без- опасности соответствующий тип аудита включен). Попробуйте от имени пользова- теля testUser запустить regedit.exe и создать раздел в HKLMSoftware. Убедитесь, что записи аудита были размещены в журнале безопасности (eventvwr.msc). з) С использованием команды whoami проверьте уровень целостности для пользователя testUser и администратора (учетная запись ВПИ). Запустите какое- нибудь приложение (калькулятор, блокнот) от имени testUser и администратора. С использованием утилиты ProcessExplorer (можно найти в папке c:Utils на вирту- альной машине) проверьте уровень целостности запущенных приложений. Объяс- ните разницу. Верните пользователю testUser права на полный доступ к папке
forTesting.От имени администратора создайте в папке forTesting текстовый файл
someText.txt.Измените уровень целостности этого файла до высокого с использо- ванием команды icacls. Запустите блокнот от имени пользователя testUser, открой- те в нём файл someText.txt, измените содержимое файла и попробуйте сохранить изменения. Объясните причину отказа в доступе. Как можно предоставить пользо- вателю testUset доступ к файлу?
2.2.7.
Шифрование файлов и папок средствами EFS.
а) От имени пользователя testUser зашифруйте какой-нибудь файл на диске.
Убедитесь, что после этого был создан сертификат пользователя, запустив оснаст- ку certmgr.msc от имени пользователя (раздел Личные). Просмотрите основные параметры сертификата открытого ключа пользователя testUser (срок действия, используемые алгоритмы). Установите доверие к этому сертификату в вашей си- стеме.
б) Создайте в папке forTesting новую папку Encrypt. В папке Encrypt со- здайте или скопируйте в нее текстовый файл. Зашифруйте папку Encrypt и все ее содержимое из меню свойств папки от имени администратора. Попробуйте про-
24
смотреть или скопировать какой-нибудь файл этой папки от имени пользователя
testUser.Объясните результат.Скопируйте зашифрованный файл в незашифро- ванную папку (например, forTesting). Убедитесь что он остался зашифрованным.
Добавьте пользователя testUser в список имеющих доступа к файлу пользователей в окне свойств шифрования файла. Повторите попытку получить доступ к файлу от имени пользователя testUser. в) Создайте учетную запись нового пользователя agentUser, сделайте его членом группы Администраторы. Определите для пользователя agentUser роль агента восстановления EFS. Создайте в папке forTesting новый текстовый файл с произвольным содержимым. Зашифруйте этот файл от имени пользователя
testUser.Убедитесь в окне подробностей шифрования файла,что пользователь
agentUser является агентом восстановления для данного файла.Попробуйте про- читать содержимое файла от имени администратора и от имени пользователя
agentUser.Объясните результат. г) Зашифруйте все текстовые файлы папки forTesting с использованием кон- сольной команды шифрования cipher от имени пользователя testUser (предвари- тельно снимите запрет на доступ к этим файлам, установленный в задании 2.2.6г). д) Убедитесь, что при копировании зашифрованных файлов на том с файло- вой системой, не поддерживающей EFS (например, FAT32 на флеш-накопителе), содержимое файла дешифруется.
2.2.8. После демонстрации результатов работы преподавателю восстановите исходное состояние системы: удалите созданные папки и файлы, разделы реестра, удалите учетную запись созданного пользователя и его группы, снимите с пользо- вателя agentUser роль агента восстановления.
2.2.9. Представьте отчёт по лабораторной работе преподавателю и отчитайте работу.
2.3. Содержание отчета
Отчет по лабораторной работе должен содержать следующие сведения:
— название и цель работы;
— протокол выполнения лабораторной работы, содержащий список кон- сольных команд, составленных при выполнении работы, и результаты их выполнения.
3.
Контрольные вопросы
1.
К какому классу безопасности относится ОС Windows по различным критериям оценки?
2.
Каким образом пользователи идентифицируются в ОС Windows?
3.
Что такое списки DACL и SACL?
4.
Перечислите, каким образом можно запустить процесс от имени друго- го пользователя.
5.
Как происходит проверка прав доступа пользователя к ресурсам в ОС
Windows?
6.
Что такое маркер безопасности, и какова его роль в модели безопасно- сти Windows?
25
7.
Как с использованием команды icacls добавить права на запись для всех файлов заданной папки?
8.
Что такое уровень целостности? Как он влияет на права доступа субъ-ектов к объектам ОС? Как можно узнать и задать уровень целостности для объек-тов и субъектов?
9.
Какие события подлежат аудиту в ОС Windows?
10.
Каким образом шифруются файлы в файловой системе EFS? Что такое
FEK? DDF? DDR?
11.
Какие алгоритмы шифрования используются в EFS?
Практическая работа №13