Администрирование и управление ресурсами Windows Server
 Скачать 3.07 Mb.
|
|
Вывод: были изучены свойства наследования разрешений объектов, рассмотрены неоднозначные ситуации (копирование и перемещение как в пределах одного тома, так и в разные тома), изучен интерфейс управления наследованием разрешений. Проведен эксперимент по проверке главенствования привилегий над разрешениями на примере обхода перекресной проверки. Цель: обосновать необходимость применения свойства владения объектом. Опробовать смену владельца объекта. Возможность назначить владельцем какого- либо объекта предоставляется не только владельцам этого объекта, но и администраторам, а также пользователям с полным доступом. Администраторы могут стать владельцем любого объекта. Владельцы объекта могут свобода изменять разрешения на нем. Опробую смену владельца объекта, предварительно создам каталог от имени Администратора и передам его во владение customer_1 (рис. 40).  Рис. 40 «Смена владельца с customer_1 на Администратор»    Запретим доступ к папке owner_test для всех пользователей (рис. 41) и восстановим через учетную запись нового владельца customer_1 (рис. 42). Рис. 41 «Администратор может стать владельцем»    Рис. 42 «Восстановление разрешений через учетную запись нового владельца»    Передать права владения можно двумя способами: Текущий владелец может предоставить другим пользователям разрешение «Смена владельца», после чего те смогут в любой момент стать владельцами объекта. Пользователь, имеющий разрешение «Смена владельца», может сам стать владельцем объектов или назначать владельцем любую группу, членом которой он является. Пользователь, у которого есть право Восстановление файлов и каталогов может дважды щелкнуть Другие пользователи и группы и выбрать любого пользователя или группу, которым нужно присвоить владение. [справка] Вывод: разобран интерфейс управления владельцами. Рассмотрены учетные записи, которые могут изменять владельца (владелец, Администратор, учетные записи с правом «Восстановление файлов и каталогов»). Опробовано изменение владельца, удаление всех разрешений от старого владельца и установка разрешений новым владельцем. Цель: отформатировать сменный флэш-носитель в файловую систему NTFS, создать два каталога, на один назначить доступ группе Пользователи, на другой – конкретной учетной записи. Проверить и обосновать возможность доступа к каталогам на другом компьютере. Подключу сменный флэш-носитель к виртуальной машине с WS2008R2 и отформатирую его, затем создам два каталога с файлами и назначу разрешения на один группе Пользователи, а на другой учетной записи customer_1 (рис. 43).      Рис. 43 «Создание каталогов на флэш-носителе и назначение разрешений»  Проверю наличие доступа на основной машине. Доступ к папке, на которую назначен полный доступ для членов группы «Пользователи», разрешен (рис. 44).  Рис. 44 «Доступ к папке Пользователи, на которую назначен полный доступ для группы Пользователи»  Доступ к папке, на которую назначены разрешения только для учетной записи customer_1 – запрещен (рис. 45). Это связано с тем, что данной учетной записи нет на системе. Однако можно попробовать получить доступ от имени администратора (рис. 46).  Рис. 45 «Запрещен доступ к папке customer_1»   Рис. 46 «Доступ получен от имени администратора» От имени администратора доступ получен.  Учетная запись customer_1 имеет имя «Неизвестная учетная запись» с расшифровкой в виде SID (рис. 47).  Рис. 47 «Отображение имени customer_1 в другой системе»  Вывод: системная группа «Пользователи» есть на всех системах, поэтому удалось получить доступ к папке, доступ к которой имеют только члены группы «Пользователи». Предположу, что система проверят наличие SID в базе данных, и так как SID customer_1 на другом компьютере не нашлось – значит и доступ предоставлять нельзя. SID группы «Пользователи» совпадает на всех системах.Цель: изучить настройки разрешений на системные каталоги Windows, установленные по умолчанию. Для корневого каталога (C:\), каталогов \Windows, \ProgramFiles, \Users с некоторыми показательными подкаталогами рассмотреть владельца, назначенные разрешения и передачу наследования. Составить иерархическую схему каталогов с приписанными в краткой форме действующими разрешениями NTFS. Объяснить общий механизм защиты системы. Сопоставить роли в Windows субъектов безопасности Администратор и TrustedInstaller.  Рис. 48 «Иерархическая схема каталогов с приписанными в краткой форме свойствами безопасности» Как можно заметить (на рис. 48), одним и тем же пользователям выставлены разные права на разную область объектов — кому-то на папку, кому-то на под-папки и файлы. Это необходимо для грамотного наследования прав доступа. Когда в папке с выставленными параметрами безопасности создаётся папка или файл, в случае, если в корневой папке заданы параметры безопасности с наследованием, то папке задаются те же параметры. В ином случае автоматически присваивается полный доступ для групп SYSTEM и Администраторы, а также неопределённому пользователю с именем S-1-5-5-0-180966. Для сравнения, ОС Windows XP имеет примитивный настройки безопасности к файлам и каталогам – сетевой доступ предоставляется в общих свойствах – разрешение чтения и записи файлов и каталогов, без тонких настроек (до-запись данных, траверс, чтение/изменение атрибутов и прочее). Для предоставления доступа другим пользователям файл или каталог необходимо поместить в каталог «Общие файлы». Системные каталоги нельзя редактировать (переименование каталога, предоставление общего доступа и пр.) даже администратору. ОС Windows 10 имеет те же настройки доступа к файлам, что и Windows 7/Windows Server 2008. Мною было замечено, что высокоуровневые каталоги не имеют наследования и список разрешений достаточно строгий: TrustedInstaller (FC), СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ (FC), система (FC for subfolders and files), Администраторы (FC for subfolders and files), Пользователи (RE). В системных папках в основном владельцем является TrustedInstaller, чем ближе к целевым каталогам, тем чаще встречается в качестве владельца группа Администраторы. Общий механизм защиты системы – минимизировать вмешательство сторонних пользователей, строго определив список допустимых субъектов. Такой подход защитит систему от изменений, которые могут быть критическими для системы, простых пользователей. Для того, чтобы запретить любому пользователю удалять или изменять критически важные для работы операционной системы папки, файлы и драйвера с правами администратора, введена служба TrustedInstaller.exe. Чтобы повлиять на важные для системы файлы, администратор должен запросить разрешение от TrustedInstaller на изменение файла. TrustedInstaller.exe — это исполняемый файл-процесс, который отвечает за обновления компонентов Windows. Таким образом можно сказать, что роль TrustedInstaller (это встроенный пользователь, владеющий системными каталогами и файлами для защиты от несанкционированного изменения. Благодаря этому уменьшается вероятность вреда от недоброжелателей и вирусов) — защита файлов и каталогов от несанкционированного доступа и изменения важной системной информации. Службой может управлять администратор, задавая нужные параметры безопасности и владельца, это одна из ролей администратора. В качестве роли администратора также выступают настройка всей системы, делегирование доступом к файлам и каталогам, создание пользователей, групп, управление доменом и прочее. Проведу эксперимент – зайду под администратором и попробую изменить разрешение системного каталога. Как видно из рис. 49 – кнопки добавить или удалить неактивны. Попробую изменить владельца с TrustedInstaller на Администратор (рис. 49, справа).   Рис. 49 «Попытка изменить разрешения – слева; изменение владельца - справа» Однако добавить пользователя customer_1 с полными правами не получилось (рис. 50).  Это связано с тем, что владельцем подкаталогов Common Files и других также является TrustedInstaller, поэтому, чтобы изменения вступили в силу для всех подкаталогов необходимо переназначить Администратора владельцем всех вложенных подкаталогов.  Рис. 50 «Попытка назначить cutomer_1 полный доступ к каталогу Program Files» Вывод: в данном пункте изучены настройки разрешений на системные каталоги Windows, установленные по умолчанию. Составлена структурная схема некоторых системных каталогов с рассмотрением владельца и разрешений. Рассмотрен смысл ролей субъектов безопасности Администратор и TrustedInstaller: TrustedInstaller необходим для защиты критических системных файлов. Однако, изменив владельца с TrustedInstaller на Администратор – можно свободно менять разрешения. Такие действия могут привести к переустановке системы, поэтому к файлам, владельцем которых является TrustedInstaller необходимо относиться с должной внимательностью. Цель: реализовать сетевой доступ к общим файловым ресурсам. Назначить разрешения доступа и проверить защищенность файловых ресурсов при доступе по сети. Результаты свести в таблицу, поясняющую смысл разрешений на общий каталог.  Была создана сетевая папка test_permission (рис. 51). Сразу подключена под буквой диска «Z:».  Рис. 51 «Подключение сетевого диска» При попытке добавить файл в сетевую папку – отобразилось сообщение, информирующие, что у нас нет доступа к целевой папке. Посмотрю разрешения, которые были назначены по умолчанию (рис. 52).     Рис. 53 «Структура тестового каталога»  Рис. 52 «Просмотр установленных по умолчанию разрешений» Было создано три каталога с файлами и подкаталогами (рис. 53) для тестирования разрешений доступа по сети. Название каталогов соответствует разрешениям (рис. 54).    Рис. 54 «Назначение разрешений для сетевых ресурсов» Теперь залогинюсь под customer_1 и протестирую доступ к сетевым ресурсам (рис. 55).  Рис. 55 «Доступ к каталогу и файлам только для customer_1»  Доступ к папке, предназначенной для customer_1 соответствует ожиданиям. Для папки share доступ разрешен всем в пределах верхнеуровнего каталога, однако смысл каталогов ниже – каждый каталог соответствует каждому пользователю. Просматривать могут все, а создавать, изменять и удалять только владельцы (рис. 56). Для каталога validator(customer_only_read) customer_1 имеет право только просматривать содержимое и читать файлы, поэтому при попытке записать в файл, получаем сообщение «Отказано в доступе» (рис. 56, справа).   Рис. 56 «Тестирование доступа к сетевым ресурсам для customer_1» Последним протестирую доступ к сетевым ресурсам для validator (рис. 57). К папке only_customer_1 доступ запрещен. Для папки share права такие же, как и у customer_1. А для папки validator имеем полный доступ – как результат удачная запись в файл и удаление.  Рис. 57 «Тестирование под учетной записью validator» В результате проведенных эксперементов можно составить таблицу. В результате проведенных эксперементов можно составить таблицу сочетаний (полный доступ, изменение, чтение). Полный доступ:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||