Файл: Администрирование и управление ресурсами Windows Server.docx
Добавлен: 03.05.2024
Просмотров: 34
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
О
бщий доступ предоставляем customer_1. Далее настраиваем детальнее. Безопасность -> дополнительно -> изменить разрешения.
Рис. 11 «Разрешение доступа к каталогу»
Рис. 10 «Распространение разрешений»
Дополнительные настройки разрешения позволяют выбрать на какие объекты будут распространяться разрешения (рис. 10).
Укажу для данной папки и ее подпапок разрешение просмотр содержания папки и чтение данных. Также, помещу исполняемый файл в эту папку. Он не должен запуститься (т.к. разрешение распространяется только на папки).
Далее были удалены наследуемые разрешения от родительских объектов.
Теперь, доступ к этой папке от Администратора также не доступен (рис. 12), однако, является Администратор владельцем и значит может установить полный доступ снова.
Рис. 12 «Отказ на доступ к папке»
Для папки others установлю разрешения для гостей (рис. 13)
Запрещаем чтение и разрешаем запись для гостей.
Из предупреждения становится ясно каким образом действуют разрешения и запреты для пользователя, находящегося в нескольких группах. Запреты более приоритетны, поэтому если одна из групп пользователя имеет запреты, то аналогичные разрешения, полученные от других групп, перестанут действовать.
Рис. 13 «Установка разрешений и запретов для гостей»
Теперь придумаю разрешения для каталога validator. Здесь я сниму наследуемые разрешения и буду добавлять двух пользователей – customer_1 и validator (рис. 14 и 15).
Рис. 15 «Для customer_1 разрешаем чтение и выполнение, просмотр содержимого папки, но запрещаем запись. Для validator добавляем разрешение изменения и записи»
Рис. 14 «Изменение общего доступа и корректировка разрешений для каталога validator и файлов с папками в нем»
Также удаляем унаследованные разрешения.
Ожидаемый сценарий: validator может изменять, удалять, читать и записывать; customer_1 может читать и выполнять, просматривать содержимое. Для данной папки использовались только стандартные разрешения и запреты.
Теперь рассмотрим настройку разрешений для последнего каталога: WS. На нем попробуем назначить разрешения для WS и запрет для операторов печати. Так как учетная запись WS является членом группы операторов печати, то запреты, более приоритетны, должны перекрыть разрешения (рис. 15).
При попытке удалить унаследованные разрешения при включенной функции – получаем сообщение об ошибке (рис. 16).
Рис. 16 «Попытка удалить объект «система» из списка разрешений»
Рис. 17 «Разрешения для anyFile в папке WS»
Вывод: были рассмотрены добавления как стандартных разрешений, так и особых. Исследован интерфейс добавления разрешений и механизм наследования.
Все каталоги и файлы создавались от имени Администратора. Разрешения также были добавлены от имени Администратора, чтобы исключить сценариев с доступом к объектам от владельца-создателя.
Первым тестируем разрешения от учетной записи customer_1.
Рис. 18 «Слева попытка чтения файла; справа попытка создать папку»
Так как, для customer_1 было добавлено только особое разрешение для папок и подпапок, исключая файлы, на «Содержание папки/чтение данных», которое означает, что мы можем просматривать имена файлов и подпапок, поэтому мы не можем изменять созданный файл. Создать папку также не получилось (рис. 18).
Теперь переместим выполняемый файл в папку customer_1.
При попытке переместить программу в целевую папку было запрошено повышение прав до администраторских. Мною были указаны имя и пароль учетной записи WS, которая находится в группе «Администраторы», однако, переместить программу не удалось, так как все группы и аккаунты, кроме владельца были преднамеренно удалены. Чтобы переместить программу в целевую папку вернусь в аккаунт Администратора.
Рис. 19 «Попытка запустить программу в каталоге customer_1»
З
апустить тестовую программу также не удалось (рис. 19). 
Теперь, логично будет вернуть к Администратору и назначить особое разрешение «Содержание папки/чтение данных» не только для папок и подпапок, но и для файлов. А потом попробовать запустить программу.
П
оявилась возможность запустить программу, однако не хватает динамической библиотеки dll – lbgcc, так как программа была скомпилирована компилятором g++ из пакета MinGW на другой машине. Для совместимости необходимо добавить dll библиотеку в системную папку или в другое место, указав путь в системных переменных.
Удаление также запрещено.
В папке others Гостю разрешено чтение, но запрещена запись (рис. 20).
Рис. 20 «Проверка чтения и запрещения на создание для гостя»
Теперь рассмотрю папку validator. Для validator в соответствии с установленными доступами разрешено создание и удаление файлов, изменение и дозапись.
Однако для изменений прав необходимо повышение прав до администраторских.
Теперь войду в учетную запись customer_1 и удостоверюсь, что данной учетной записи разрешено только чтение, а удаление и изменение запрещены. На рис. 21 показана попытка создания папки.
Рис. 21 «Попытка создать папку под учетной записью customer_1 в папке validator»
Рис. 23 «Изменение файла – отказано в доступе»
Рис. 22 «Чтение файла - успешно»
Рис. 24 «Попытка удаления файла – требуется повышение прав»
Теперь проверю последнюю папку WS. Данный сценарий должен показать приоритетность запретов над разрешениями. Операторам печати был выставлен ряд запретов – рис. 17, а учетной записи WS те же самые разрешения – активированы. Учетная запись WS является членом группы операторов печати.
На рис. 25 показано, что для группы «Операторы печати» запрещено чтение файлов. Однако создание в данной папке разрешено, так как наследуются разрешения от корневой папки. Именно разрешение для Администраторов позволяет создавать файлы в данной папке, а учетная запись WS является членом группы «Администраторы».
Рис. 25 «Первенство запрета над разрешением»
Вывод: были протестированы созданные папки и файлы с их разрешениями, как стандартными, так и специализированными. Рассмотрены случаи, когда запреты перебивают разрешения.
Команда iCACLS позволяет отображать или изменять списки управления доступом (Access Control Lists (ACLs)) к файлам и папкам файловой системы. Утилита iCACLS.EXE является дальнейшим усовершенствованием утилиты управления доступом CACLS.EXE.
Управление доступом к объектам файловой системы NTFS реализуется с использованием специальных записей в таблице MFT (Master File Table). Каждому файлу или папке файловой системы NTFS соответствует запись в таблице MFT, содержащая специальный дескриптор безопасности SD (Security Descriptor). Каждый дескриптор безопасности содержит два списка контроля доступа:
SACL управляется системой и используется для обеспечения аудита попыток доступа к объектам файловой системы, определяя условия при которых генерируется события безопасности. В операционных системах Windows Vista и более поздних, SACL используется еще и для реализации механизма защиты системы с использованием уровней целостности (Integrity Level, IL).
DACL - это собственно и есть список управления доступом ACL в обычном понимании. Именно DACL формирует правила, определяющие, кому разрешить доступ к объекту, а кому - запретить.
Каждый список контроля доступа (ACL) представляет собой набор элементов (записей) контроля доступа - Access Control Entries, или ACE. Записи ACE бывают двух типов (разрешающий и запрещающий доступ), и содержит три поля:
Получим информацию для каталога others, используя команду icacls (рис. 26).
бщий доступ предоставляем customer_1. Далее настраиваем детальнее. Безопасность -> дополнительно -> изменить разрешения. Рис. 11 «Разрешение доступа к каталогу»
Рис. 10 «Распространение разрешений»
Дополнительные настройки разрешения позволяют выбрать на какие объекты будут распространяться разрешения (рис. 10).
Укажу для данной папки и ее подпапок разрешение просмотр содержания папки и чтение данных. Также, помещу исполняемый файл в эту папку. Он не должен запуститься (т.к. разрешение распространяется только на папки).
Далее были удалены наследуемые разрешения от родительских объектов.
Теперь, доступ к этой папке от Администратора также не доступен (рис. 12), однако, является Администратор владельцем и значит может установить полный доступ снова.
Рис. 12 «Отказ на доступ к папке»
Для папки others установлю разрешения для гостей (рис. 13)
Запрещаем чтение и разрешаем запись для гостей.
Из предупреждения становится ясно каким образом действуют разрешения и запреты для пользователя, находящегося в нескольких группах. Запреты более приоритетны, поэтому если одна из групп пользователя имеет запреты, то аналогичные разрешения, полученные от других групп, перестанут действовать.
Рис. 13 «Установка разрешений и запретов для гостей»
Теперь придумаю разрешения для каталога validator. Здесь я сниму наследуемые разрешения и буду добавлять двух пользователей – customer_1 и validator (рис. 14 и 15).
Рис. 15 «Для customer_1 разрешаем чтение и выполнение, просмотр содержимого папки, но запрещаем запись. Для validator добавляем разрешение изменения и записи»
Рис. 14 «Изменение общего доступа и корректировка разрешений для каталога validator и файлов с папками в нем»
Также удаляем унаследованные разрешения.
Ожидаемый сценарий: validator может изменять, удалять, читать и записывать; customer_1 может читать и выполнять, просматривать содержимое. Для данной папки использовались только стандартные разрешения и запреты.
Теперь рассмотрим настройку разрешений для последнего каталога: WS. На нем попробуем назначить разрешения для WS и запрет для операторов печати. Так как учетная запись WS является членом группы операторов печати, то запреты, более приоритетны, должны перекрыть разрешения (рис. 15).
При попытке удалить унаследованные разрешения при включенной функции – получаем сообщение об ошибке (рис. 16).
Рис. 16 «Попытка удалить объект «система» из списка разрешений»
Рис. 17 «Разрешения для anyFile в папке WS»
Вывод: были рассмотрены добавления как стандартных разрешений, так и особых. Исследован интерфейс добавления разрешений и механизм наследования.
-
Цель: войти в систему от имени пользователей и проверить их возможности доступа к объектам файловой системы.
Все каталоги и файлы создавались от имени Администратора. Разрешения также были добавлены от имени Администратора, чтобы исключить сценариев с доступом к объектам от владельца-создателя.
Первым тестируем разрешения от учетной записи customer_1.
Рис. 18 «Слева попытка чтения файла; справа попытка создать папку»
Так как, для customer_1 было добавлено только особое разрешение для папок и подпапок, исключая файлы, на «Содержание папки/чтение данных», которое означает, что мы можем просматривать имена файлов и подпапок, поэтому мы не можем изменять созданный файл. Создать папку также не получилось (рис. 18).
Теперь переместим выполняемый файл в папку customer_1.
При попытке переместить программу в целевую папку было запрошено повышение прав до администраторских. Мною были указаны имя и пароль учетной записи WS, которая находится в группе «Администраторы», однако, переместить программу не удалось, так как все группы и аккаунты, кроме владельца были преднамеренно удалены. Чтобы переместить программу в целевую папку вернусь в аккаунт Администратора.
Рис. 19 «Попытка запустить программу в каталоге customer_1»
З
апустить тестовую программу также не удалось (рис. 19). Теперь, логично будет вернуть к Администратору и назначить особое разрешение «Содержание папки/чтение данных» не только для папок и подпапок, но и для файлов. А потом попробовать запустить программу.
П
оявилась возможность запустить программу, однако не хватает динамической библиотеки dll – lbgcc, так как программа была скомпилирована компилятором g++ из пакета MinGW на другой машине. Для совместимости необходимо добавить dll библиотеку в системную папку или в другое место, указав путь в системных переменных.
Удаление также запрещено.В папке others Гостю разрешено чтение, но запрещена запись (рис. 20).
Рис. 20 «Проверка чтения и запрещения на создание для гостя»
Теперь рассмотрю папку validator. Для validator в соответствии с установленными доступами разрешено создание и удаление файлов, изменение и дозапись.
Однако для изменений прав необходимо повышение прав до администраторских.
Теперь войду в учетную запись customer_1 и удостоверюсь, что данной учетной записи разрешено только чтение, а удаление и изменение запрещены. На рис. 21 показана попытка создания папки.
Рис. 21 «Попытка создать папку под учетной записью customer_1 в папке validator»
Рис. 23 «Изменение файла – отказано в доступе»
Рис. 22 «Чтение файла - успешно»
Рис. 24 «Попытка удаления файла – требуется повышение прав»
Теперь проверю последнюю папку WS. Данный сценарий должен показать приоритетность запретов над разрешениями. Операторам печати был выставлен ряд запретов – рис. 17, а учетной записи WS те же самые разрешения – активированы. Учетная запись WS является членом группы операторов печати.
На рис. 25 показано, что для группы «Операторы печати» запрещено чтение файлов. Однако создание в данной папке разрешено, так как наследуются разрешения от корневой папки. Именно разрешение для Администраторов позволяет создавать файлы в данной папке, а учетная запись WS является членом группы «Администраторы».
Рис. 25 «Первенство запрета над разрешением»
Вывод: были протестированы созданные папки и файлы с их разрешениями, как стандартными, так и специализированными. Рассмотрены случаи, когда запреты перебивают разрешения.
-
Цель: применить команду icacls для получения информации о разрешениях доступа на командном уровне.
Команда iCACLS позволяет отображать или изменять списки управления доступом (Access Control Lists (ACLs)) к файлам и папкам файловой системы. Утилита iCACLS.EXE является дальнейшим усовершенствованием утилиты управления доступом CACLS.EXE.
Управление доступом к объектам файловой системы NTFS реализуется с использованием специальных записей в таблице MFT (Master File Table). Каждому файлу или папке файловой системы NTFS соответствует запись в таблице MFT, содержащая специальный дескриптор безопасности SD (Security Descriptor). Каждый дескриптор безопасности содержит два списка контроля доступа:
-
System Access-Control List (SACL) - системный список управления доступом. -
Discretionary Access-Control List (DACL) - список управления избирательным доступом.
SACL управляется системой и используется для обеспечения аудита попыток доступа к объектам файловой системы, определяя условия при которых генерируется события безопасности. В операционных системах Windows Vista и более поздних, SACL используется еще и для реализации механизма защиты системы с использованием уровней целостности (Integrity Level, IL).
DACL - это собственно и есть список управления доступом ACL в обычном понимании. Именно DACL формирует правила, определяющие, кому разрешить доступ к объекту, а кому - запретить.
Каждый список контроля доступа (ACL) представляет собой набор элементов (записей) контроля доступа - Access Control Entries, или ACE. Записи ACE бывают двух типов (разрешающий и запрещающий доступ), и содержит три поля:
-
SID пользователя или группы, к которому применяется данное правило -
Вид доступа, на которое распространяется данное правило -
Тип ACE - разрешающий или запрещающий.
Получим информацию для каталога others, используя команду icacls (рис. 26).
