К сожалению на практике так сделать не получается.
В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
Поэтому сценарий с едиными mapped dirve обречен на неудачу.
Еще забыл сказать. Когда выдаются права «per group» делать это могут сотрудники тех. поддержки, которым делегирован доступ в АД на изменения состава групп, но которые не являются администраторами файловых серверов.
Расскажите, пожалуйста, на чём основывается ваша уверенность, что такого подхода достаточно для реализации любого рабочего сценария?
Уверенность основана на опыте работы по данному документу, но на слово «любой» я не претендую.
Лично я в свою виндовую давность deny вполне пользовался, и индивидуальные права (per user) выдавал. И оно вовсе не превращалось в ад, потому что это были вполне осознанные исключения, которые конвертировались в правила (т.е. превращались в группы) как только оказывались постоянно востребованными.
Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.
Выдача «per user» прав плоха тем, что когда необходимо предоставить доступ как у «Ивана Федоровича» сделать это очень сложно. В то время как при выдаче прав «per group» можно просто скопировать и переименовать учетку в АД.
Да и еще, когда к вам приходит запрос «Куда Иван Федорович имеет доступ», то по составу групп в его учетной записи вы всегда сможете это быстро сделать не проводя аудит всех систем организации.
Mapped drive при управлением доступом это зло.
Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)
Название правильное, поскольку данный документ именно корпоративный стандарт конфигурирования.
В нем нет цели покрыть все возможные способы организации общего доступа к файлам, что и отражено в сфере его действия.
Для других систем и случаев нужны другие стандарты, Еще раз подчеркну что это один из возможных вариантов.
Чем больше баз будет проанализировано тем лучше. Потому как аудит это по сути распутывания клубка.
В первую очередь конечно смотрим на базы данных сертификатов (выпущенных, отозванных, в ожидании запросов).
Анализ базы данных пользователей позволит определить круг лиц, которые пользовались криптой, что может помочь идентифицировать "повисшие" бизнес-процессы, когда человек работал, потом его уволили и ни кем не заменили, но сам процесс еще живой.
Средств автоматизации для анализа УЦ не использовал. Применительно к MS CA пользовался Powershell скриптами, для OpenSSL только ручной анализ.
В жизни возникают ситуации когда происходит поглощения бизнеса, что неминуемо тянет за собой поглощение инфраструктуры, вот вам и два диска О ссылающиеся на разные места.
Второй нюанс это историческое развитие сети. Если вы ее разработали и ведете на протяжении всей жизни это одно, а если вам приходится наводить порядок в уже существующей это совсем другое.
Поэтому сценарий с едиными mapped dirve обречен на неудачу.
Короче сплошные плюсы :)
Уверенность основана на опыте работы по данному документу, но на слово «любой» я не претендую.
Вы все правильно говорите, но когда увольняется человек который раздавал права подобным образом, или когда к процессу выдачи прав нужно подключить нового админа, разобраться почему «Иван Федорович» не может прочитать тот или иной файл когда у него доступ «вроде как есть» бывает очень сложно.
Выдача «per user» прав плоха тем, что когда необходимо предоставить доступ как у «Ивана Федоровича» сделать это очень сложно. В то время как при выдаче прав «per group» можно просто скопировать и переименовать учетку в АД.
Да и еще, когда к вам приходит запрос «Куда Иван Федорович имеет доступ», то по составу групп в его учетной записи вы всегда сможете это быстро сделать не проводя аудит всех систем организации.
Пример. К вам приходит заявка «Дайте доступ на папку отчет на диске О», у вас диск O ссылается на один источник, у админов на другой у запрашиваемого пользователя на третий. Куда давать доступ? :)
В нем нет цели покрыть все возможные способы организации общего доступа к файлам, что и отражено в сфере его действия.
Для других систем и случаев нужны другие стандарты, Еще раз подчеркну что это один из возможных вариантов.
В первую очередь конечно смотрим на базы данных сертификатов (выпущенных, отозванных, в ожидании запросов).
Анализ базы данных пользователей позволит определить круг лиц, которые пользовались криптой, что может помочь идентифицировать "повисшие" бизнес-процессы, когда человек работал, потом его уволили и ни кем не заменили, но сам процесс еще живой.
Средств автоматизации для анализа УЦ не использовал. Применительно к MS CA пользовался Powershell скриптами, для OpenSSL только ручной анализ.