Насколько я понимаю, лучшие практики рекомендуют использовать группы безопасности с доменом Windows для назначения разрешений для файлов и папок. То есть вы должны создавать группы в Active Directory, заполнять их пользователями, а затем назначать разрешения для папок и файлов через группы, а не отдельных пользователей. Я вижу преимущества этого подхода, НО:
В моей организации мы используем корпоративную информационную систему для повседневной работы. Каждый проект и отдел регистрируются в системе, и система знает, кто принадлежит к каждому отделу и проекту. Мы внедряем механизм синхронизации папок, с помощью которого система может применять разрешения к общим папкам на наших файловых серверах для репликации нашей организационной структуры. Например, если у нас есть отдел «Продажи», в котором есть Алиса и Боб, система создаст общую папку «Продажи» и предоставит ей разрешения для Алисы и Боба. Это прекрасно работает и практически устранило необходимость вручную назначать разрешения папкам и пользователям.
Проблема в том, что мы не уверены, что группы Active Directory по-прежнему имеют смысл в этом сценарии. В принципе, мы предполагали, что одна или несколько групп AD будут созданы для каждого отдела и проекта, и разрешения будут назначены им как обычно. Например, были бы группы Dept-Sales-Head и Dept-Sales-Members, каждая со своими собственными участниками, для руководителя и сотрудников отдела продаж, и разрешения будут назначаться через эти группы. Наша автоматизированная система способна создавать группы AD и управлять ими. Но мы опасаемся, что у нас будет слишком много групп, так как количество организационных единиц в нашей компании растет. Мне кажется, я помню, что не рекомендуется иметь более 5000 групп на домен, и очень вероятно, что мы приблизимся к этому количеству через несколько лет, поэтому такой подход не будет масштабируемым.
Другой вариант, который мы рассматриваем, - отказаться от групп безопасности и иметь автоматизированную систему для назначения разрешений папкам с использованием индивидуальных учетных записей пользователей. Это устранило бы описанную выше проблему, но мы обеспокоены тем, что такой подход без групповой безопасности может иметь нежелательные последствия, которых мы не можем сейчас предвидеть.
Итак, мой вопрос: имеет ли смысл этот безгрупповой подход к назначению разрешений файловой системы? Предвидите ли вы какие-либо нежелательные последствия в долгосрочной перспективе?
Во-первых, автоматизация - это хорошо. Здорово, что вы пытаетесь автоматизировать управление этими утомительными вещами. Однако я вижу две потенциальные проблемы при попытке назначить права доступа к файлам напрямую пользователям.
Влияние на производительность файловой системы. Допустим, у вас есть общая папка с тысячами или сотнями тысяч файлов, и вам нужно добавить или удалить доступ сотрудника к этой общей папке. Даже если все права доступа к общему ресурсу унаследованы от корневой папки, ОС все равно необходимо изменить ACL каждого файла, чтобы обновить эти разрешения. С большой долей это может занять много времени и снизить производительность файлового сервера во время его обработки. Разрешения, примененные к группе, не оказывают никакого влияния, поскольку фактически в ACL ничего не меняется.
Проблемы с производительностью при использовании больших списков ACL. По общему признанию, я понятия не имею, каковы могут быть симптомы этого. Но я должен верить, что наличие списков ACL, содержащих сотни или более индивидуальных пользовательских записей, будет иметь негативные последствия. Я предполагаю, что вы увидите большую задержку на стороне клиента, так как серверу нужно больше работать для обработки ACL. Вы также, вероятно, увидите более высокую нагрузку на сам сервер, требующий более мощного оборудования для той же задачи.
Имеет ли смысл этот безгрупповой подход к назначению разрешений файловой системы?
При проектировании среды передовой опыт является отправной точкой, от которой можно отклоняться по различным деловым или техническим причинам. Если пользователям может потребоваться доступ к нескольким проектам, приближающимся к 1000, это может считаться технической причиной.
Учитывая нынешнюю Максимумы Active Directory (всего более 2 миллиардов объектов; максимальное количество участников в группах ~ 1000 и максимальное количество участников в группах 5000), я считаю, что «мы боимся, что в конечном итоге у нас будет слишком много групп» не является допустимой технической причиной.
Однако, если у компании есть другое приложение, которое может обновлять доступ к файлам и ресурсам в зависимости от роли пользователей в организации (что по сути является тем, чего пытаются достичь вложенные группы безопасности AD), это звучит как веская причина для оправдания пропуска это конкретная передовая практика - или, по крайней мере, отмечая, что это было достигнуто другими способами. Это не значит, что вы вообще обсуждаете удаление групп в Active Directory, это просто группы, используемые для управления доступом к общим файловым ресурсам.
По общему признанию, если вы все равно собираетесь управлять группами аналогичного состава в Active Directory (фильтрация безопасности для объектов групповой политики, таргетинг на уровне элементов для предпочтений групповой политики, назначение прав пользователей на серверах / рабочих станциях, делегированный доступ к объектам / ветвям в Active Каталог, доступ с аутентификацией AD или LDAP к другим приложениям или ресурсам), то может не иметь особого смысла отбрасывать группы только для этого. Но, если я правильно прочитал ваш вопрос, общий доступ к ресурсам в Организации отличается от контролируемого доступа к этим общим файловым ресурсам на основе проекта. Я правильно понял?
Кроме того, в наши дни при рассмотрении предоставления доступа к общим файловым ресурсам я всегда предлагаю обратить внимание на динамический контроль доступа.
Предвидите ли вы какие-либо нежелательные последствия в долгосрочной перспективе?
Излишне длинные списки SACL в случае, если приложение также не очищает записи для устаревших учетных записей.
Ненужная репликация и более крупные или более длинные резервные копии, когда фактические данные не меняются, потому что списки ACL для папок / файлов меняются чаще, чем в противном случае потребовалось бы для простых статических ACL.