У меня есть файловый сервер с 20 общими папками, по одной для каждого отдела, и их сотрудники имеют разрешение на запись через группу AD с таким же именем этой папки.
Дело в том, что некоторым людям приходится записывать файлы в папки других отделов, поэтому у них также есть разрешение на запись в эту папку, что дает им полный доступ к любому файлу.
Я хочу изменить эту практику на эту:
Я создам группу AD для каждой должности в компании и дам каждому доступ для чтения и записи к разным папкам в соответствии с потребностями должности. Таким образом, каждый сотрудник будет иметь правильный доступ к файлам, и если сотрудник изменит вашу должность, мне нужно будет изменить ее только из вашей группы должностей.
Какие-либо предложения?
Что вы ищете в стиле лучших практик, так это AGDLP. В Википедии есть хорошее описание этого. http://en.wikipedia.org/wiki/AGDLP
Краткий вариант - объединить людей в универсальные или глобальные группы в зависимости от их ролей и названий в соответствии с конкретной ролью. (Подобно помещению групп Team1 и Team3 в DataTransferAppUsers.) Затем создайте локальные группы домена для разрешений (группа Share_DataTransfer_RW должна иметь доступ на изменение этого общего ресурса), а затем поместите универсальные группы в этот общий ресурс.
Не бойтесь делать группы пользователей конкретными и небольшими, а затем объединять их или объединять меньшие группы в более общие. Старайтесь избегать разделения групп пользователей на более чем одну или две разные иерархии. Держите группы людей отдельно от групп ролей, в группах ролей должны быть только группы. Постарайтесь еще больше избежать включения отдельных пользователей в локальные группы разрешений домена.
Пользователь -> Группа пользователей -> Группа ролей -> DomainLocalPermissionGroup -> ACL
Теперь, когда вы добавляете человека, вам нужно только ввести его в несколько групп пользователей. Когда вы добавляете новый ресурс для существующей роли, вы создаете 1 или 2 группы (только для чтения и / или для чтения) и применяете к ней эту роль. Когда вы создаете новую роль, вы просто создаете одну группу, а затем ищите ресурсы, которые она будет использовать.
Таким образом, вы используете AD, чтобы связать все вместе. Дисциплина исходит из того, что никогда и никогда не применять пользователя (учетную запись на жаргоне MS) или группу пользователей напрямую к любому ACL в локальной системе. Таким образом, вы можете быть уверены в том, что ничего не происходит вне поля зрения дерева разрешений, которое вы строите в AD.
Учитывая общую папку, \ nyc-ex-svr-01 \ groups \ bizdev; группа развития бизнеса в рамках отдела маркетинга организации, представленная в Active Directory как (существующая) глобальная группа безопасности «Член группы развития бизнеса»; и требование, чтобы вся группа имела доступ для чтения и записи к общей папке, администратор, следующий за AGDLP, может реализовать управление доступом следующим образом:
Создайте новую локальную группу безопасности домена в Active Directory с именем «Изменить разрешение на \ nyc-ex-svr-01 \ groups \ bizdev».
Предоставьте этой локальной группе домена набор разрешений NTFS на «изменение» (чтение, запись, выполнение / изменение, удаление) в папке «bizdev». (Обратите внимание, что разрешения NTFS отличаются от разрешений для общего ресурса.)
Сделайте группу «Член группы по развитию бизнеса» членом группы «Изменить разрешение для \ nyc-ex-svr-01 \ groups \ bizdev».
Чтобы подчеркнуть преимущества RBAC на этом примере, если группе бизнес-развития потребовались дополнительные разрешения для папки «bizdev», системному администратору нужно было бы отредактировать только одну запись управления доступом (ACE) вместо, в худшем случае, редактирования столько ACE, сколько пользователей с доступом к папке.
Я бы сказал, по профилю работы, это лучшая практика.