Хочу поделится опытом проектирования разрешений на файловых серверах. В теории и практике и Unix и Windows(как две наиболее популярные платформы) предоставляют достаточно средств и возможностей для назначения разрешений на объекты на файл серверах. Это достаточно заурядная задача когда у вас до сотни пользователей, пара серверов, и всего несколько уровней вложенности дерева каталогов. При росте колличества серверов, колличестве каталогов, да и пользователей в таких компаниях намного больше, появляется неприятное обстоятельство – резко растут расходы на поддержку инфраструктуры общего доступа к файлам(время и персонал). В данном топике хочется рассказать об основных требованиях к дизайну сервиса общего доступа к файлам, что позволит при их выполнении упростить поддержку и сократить расходы на нее. Заранее обращаю внимание, что не касаемся самого процесса содержания серверов(железа, фаловых и оперционных систем) и содержание объектов(типы контента), а рассматриваем только дизайн структуры общего доступа.
Опишем стразу условия которые будем рассматривать в качестве примера и реального применения.
В наличии на данный момент:
Географическое расположение серверов, пользователей, сетевая инфраструктура не имеет особого значения для данной ситуации.
В результате использования подобной ифраструктуры в течении пары лет, смены нескольких системных администраторов, регулярного назначения специальных разрешений на каталогах(цели не важны) по запросам пользователей, даже при тщательном ведении документации, соблюдении процессов внесения изменения и веднии событий об измененийх в инфраструктуре на подобных серверах возникает бардак в разрешениях каталогов. Типичное проявление беспорядка: необходимо понять почему пользователь Иванова Ольга(переводчик к примеру) имеет доступ к каталогу с информацией о финансах, да и еще может ее редактировать к тому же. Открываем разрешения каталога, моделируем эффективные разрешения на доступ для этого пользователя и видим что таки она может там хоть бабочек разводить, хотя судя по членству в группах на два уровня выше ее там и не должно быть никак. Возникает вопрос: как сложилась данная ситуация? Наверняка причиной является наследование разрешений, хотя может быть так же и какие либо особые разрешения которые на первый взгляд не видны. Может быть и обратная ситуация когда какой-либо пользователь не может получить доступ к документам которые ему положенно редактировать, и тут уже необходимо потратить, как правило, намного более времени на поиск причин и исправление ошибок. Все это приводит к большим затратам времени которые на самом деле можно было избежать при правильном планировании и соблюдении дизайна.
Что же можно предложить в качестве решения данной ситуации(а как далее увидим и большинства других возникающих на файловых серверах). Для начала это разработка дизайна для файловой инфраструктуры общего доступа. Дизайн должен состоять из документа описывающего как минимум следующие области:
Хочу остановиться на требованиях к логической структуре и разрешениям доступа, описание остальных же разделов дизайна относится уже к области сервис-менеджмента и выходит за рамки данного топика.
Основные рекомендации позволяющие избежать многих ошибок при поддержке сервиса:
Особое внимание при поддержке общего доступа к файлам стоит уделять последним трем пунктам, ибо нарушение любого из них сильно усложняет расследование инцидентов и дальнейшее пректирование и развитие сервиса. Любые необходимые действия с резрешениями на доступ можно выполнить в рамках последних трех пунктов.
Соблюдение этих правил делает ваш сервис предоставления общего доступа масштабируемым, понятным любому инженеру, более безопасным. Основным результатом будет явное снижение затрат на поддержку сервиса и снижение некоторых рисков.
Остальные разделы дизайна(цели, риски, роли, связи с иными политиками) в данном случае не менее важны для оптимального и успешного проектирования, внедрения и поддержки сервиса. Из чего следует необходимость уделять им не меньше внимания нежели дизайну разрешения или поддержанию порядка в структуре каталогов.
Во избежание холивара по поводу пункта 10. сразу хочу добавить, что любое запрещение доступа можно заменить правильно спроектированными разрешениями. Использование “Deny Access” сильно усложняет расследование инцидентов при больших уровнях вложенности, но и при малых тоже может доставить много хлопот. Соответственно использование наследования и только разрешающих наборов прав доступа дает уверенность в прозрачном механизме наследования и что нигде между несколькими уровнями ничего не скрыто от вас.
С ABE необходимо быть очень аккуратным и помнить о его наличии, в противном случае будет много недоумения при расследовании инцидентов.
Опишем стразу условия которые будем рассматривать в качестве примера и реального применения.
В наличии на данный момент:
- Пять основных серверов общего доступа к файлам
- Более пяти уровней вложенности на каждом сервере
- Более 500 каталогов на каждом сервере
- Более 10 тыс. файлов на каждом сервере
- Более 300 пользователей
Географическое расположение серверов, пользователей, сетевая инфраструктура не имеет особого значения для данной ситуации.
В результате использования подобной ифраструктуры в течении пары лет, смены нескольких системных администраторов, регулярного назначения специальных разрешений на каталогах(цели не важны) по запросам пользователей, даже при тщательном ведении документации, соблюдении процессов внесения изменения и веднии событий об измененийх в инфраструктуре на подобных серверах возникает бардак в разрешениях каталогов. Типичное проявление беспорядка: необходимо понять почему пользователь Иванова Ольга(переводчик к примеру) имеет доступ к каталогу с информацией о финансах, да и еще может ее редактировать к тому же. Открываем разрешения каталога, моделируем эффективные разрешения на доступ для этого пользователя и видим что таки она может там хоть бабочек разводить, хотя судя по членству в группах на два уровня выше ее там и не должно быть никак. Возникает вопрос: как сложилась данная ситуация? Наверняка причиной является наследование разрешений, хотя может быть так же и какие либо особые разрешения которые на первый взгляд не видны. Может быть и обратная ситуация когда какой-либо пользователь не может получить доступ к документам которые ему положенно редактировать, и тут уже необходимо потратить, как правило, намного более времени на поиск причин и исправление ошибок. Все это приводит к большим затратам времени которые на самом деле можно было избежать при правильном планировании и соблюдении дизайна.
Что же можно предложить в качестве решения данной ситуации(а как далее увидим и большинства других возникающих на файловых серверах). Для начала это разработка дизайна для файловой инфраструктуры общего доступа. Дизайн должен состоять из документа описывающего как минимум следующие области:
- цель
- пользу которую принесет соблюдение данной политки
- область применения
- требования к логической структуре файлового доступа
- требония к разрешениям доступа к объектам общего доступа
- роли которые необходимые/будут участвовать в проектировании, внедрении, поддержке данной инфраструктуры
- риски при внедрении и поддержке инфраструктуры
- основные проблемы которые могут быть при проектировании, внедрении, поддержке
- связи с какими-либо иными политиками, соглашениями, контрактами которые могут повлиять на дизайн, внедрение и поддержку сервиса общего доступа к файлам
Хочу остановиться на требованиях к логической структуре и разрешениям доступа, описание остальных же разделов дизайна относится уже к области сервис-менеджмента и выходит за рамки данного топика.
Основные рекомендации позволяющие избежать многих ошибок при поддержке сервиса:
- Для логической структуры дерева каталогов лучше всего использовать единый дизайн на всех серверах
- На всех серверах рекомендуется использовать одинаковую точку входа к каталогам(root level)
- Все каталоги которые должны иметь особые права доступа должны иметь собственные групы для пользователей которым необходим доступ именно в этот каталог
- Для предоставления доступа к каталогам рекомендуется использовать отдельные группы пользователей которые следует размещать в отдельном от остальных групп контейнере
- Все группы для предоставления доступа должны иметь единый заранее определенный дизайн именования
- Разрешения на каталоги можно выдавать только через включение в члены группы которая соответствует данному каталогу(никогда отдельному пользователю напрямую)
- При выставлении разрешений для вновь созданного каталога все системные ненаследуемые группы доступа должны удаляться
- Наследование разрешений должно быть включено начиная с корневого каталога(root level) и не должно отключаться ни при каких ситуациях
- Доступ к объектам можно предоставлять только путем предоставления двух основных наборов прав — на чтение(чтение списка объектов, чтение разрешений, чтение содержимого) и на измененние(права на чтение + изменение содержимого, удаление файлов и коталогов, создание файлов и каталогов). В отдельных случаях можно использовать специальные группы(отдельный тип групп) которые могут предоставлять только необходимую часть из двух основных полных наборов прав доступа
- Запрещается использовать «запрет доступа»(deny of access) ни при каких условиях
- Рекомендуется использовать ABE при необходимости скрыть от глаз лишние каталоги или же при необходимости не только запретить доступ, а и по мере возможности обеспечить видимость их отсутствия
Особое внимание при поддержке общего доступа к файлам стоит уделять последним трем пунктам, ибо нарушение любого из них сильно усложняет расследование инцидентов и дальнейшее пректирование и развитие сервиса. Любые необходимые действия с резрешениями на доступ можно выполнить в рамках последних трех пунктов.
Соблюдение этих правил делает ваш сервис предоставления общего доступа масштабируемым, понятным любому инженеру, более безопасным. Основным результатом будет явное снижение затрат на поддержку сервиса и снижение некоторых рисков.
P.S.
Остальные разделы дизайна(цели, риски, роли, связи с иными политиками) в данном случае не менее важны для оптимального и успешного проектирования, внедрения и поддержки сервиса. Из чего следует необходимость уделять им не меньше внимания нежели дизайну разрешения или поддержанию порядка в структуре каталогов.
Во избежание холивара по поводу пункта 10. сразу хочу добавить, что любое запрещение доступа можно заменить правильно спроектированными разрешениями. Использование “Deny Access” сильно усложняет расследование инцидентов при больших уровнях вложенности, но и при малых тоже может доставить много хлопот. Соответственно использование наследования и только разрешающих наборов прав доступа дает уверенность в прозрачном механизме наследования и что нигде между несколькими уровнями ничего не скрыто от вас.
С ABE необходимо быть очень аккуратным и помнить о его наличии, в противном случае будет много недоумения при расследовании инцидентов.