Хотел бы поделиться своим опытом проектирования разрешений на файловых серверах.
В теории и на практике и Unix, и Windows (как две наиболее популярные платформы) предоставляют достаточные инструменты и возможности для назначения разрешений объектам на файловых серверах.
Это достаточно обычная задача, когда у вас до сотни пользователей, пара серверов и всего несколько уровней вложенности дерева каталогов.
С увеличением количества серверов, количества каталогов, а также количества пользователей в таких компаниях появляется неприятное обстоятельство — резко растут затраты на содержание файлообменной инфраструктуры (время и персонал).
В этой теме хотелось бы рассказать об основных требованиях к проектированию файлообменников, которые позволят упростить поддержку и снизить затраты при их реализации.
Обратите внимание заранее, что мы не занимаемся процессом обслуживания серверов (аппаратных, файловых и операционных систем) и содержимым объектов (типами контента), а рассматриваем только проектирование структуры публичного доступа.
Сразу опишем условия, которые мы будем рассматривать в качестве примера и реального применения.
Доступен на данный момент:
- Пять основных файловых серверов
- Более пяти уровней вложенности на каждом сервере
- Более 500 каталогов на каждом сервере
- Более 10 тысяч файлов на каждом сервере
- Более 300 пользователей
В результате использования такой инфраструктуры в течение пары лет, смены нескольких системных администраторов, регулярного назначения специальных разрешений каталогам (цели не важны) по запросам пользователей, даже при тщательном документировании, соблюдении процессов изменений и ведении событий об изменениях.
в инфраструктуре на подобных серверах бардак в правах каталогов.
Типичное проявление беспорядка: необходимо понять, почему пользователь Ольга Иванова (переводчик, например) имеет доступ к каталогу с информацией о финансах, а также может его редактировать.
Открываем права доступа к каталогу, моделируем эффективные права доступа для этого пользователя и видим, что она может там хоть бабочек разводить, хотя судя по членству в группах на два уровня выше ее, пути туда быть не должно.
Возникает вопрос: как развивалась эта ситуация? Наверняка причина в наследовании разрешений, хотя могут быть и какие-то особые разрешения, не видимые на первый взгляд. Может возникнуть и обратная ситуация, когда пользователь не может получить доступ к документам, которые ему предстоит редактировать, и здесь приходится тратить, как правило, гораздо больше времени на поиск причин и исправление ошибок.
Все это приводит к потере большого количества времени, чего на самом деле можно было бы избежать при правильном планировании и проектировании.
Что можно предложить в качестве решения данной ситуации (и как мы увидим далее, большинства других, возникающих на файловых серверах).
Для начала это разработка проекта инфраструктуры обмена файлами.
Проект должен состоять из документа, охватывающего как минимум следующие области:
- цель
- выгоды, которые будут получены от следования этой политике
- Область применения
- требования к логической структуре доступа к файлам
- требования к разрешениям доступа к публичным объектам
- роли, которые необходимы/будут задействованы в проектировании, внедрении и поддержке этой инфраструктуры
- риски при внедрении и обслуживании инфраструктуры
- основные проблемы, которые могут возникнуть при проектировании, внедрении, поддержке
- связь с любыми другими политиками, соглашениями, контрактами, которые могут повлиять на проектирование, внедрение и поддержку файлообменника.
Основные рекомендации, позволяющие избежать многих ошибок при поддержке сервиса:
- Для логической древовидной структуры каталогов лучше всего использовать единый дизайн для всех серверов.
- Рекомендуется использовать одну и ту же точку входа в каталог (корневой уровень) на всех серверах.
- Все каталоги, которые должны иметь специальные права доступа, должны иметь свои группы для пользователей, которым необходим доступ к данному конкретному каталогу.
- Для предоставления доступа к каталогам рекомендуется использовать отдельные группы пользователей, которые следует размещать в контейнере, отдельном от других групп.
- Все группы доступа должны иметь один и тот же предопределенный дизайн именования.
- Разрешения для каталогов могут быть предоставлены только через членство в группе, соответствующей каталогу (никогда отдельному пользователю напрямую).
- При настройке разрешений для вновь созданного каталога необходимо удалить все системные ненаследуемые группы доступа.
- Наследование разрешений должно быть включено, начиная с корневого уровня, и не должно отключаться ни при каких обстоятельствах.
- Доступ к объектам можно предоставить только путем предоставления двух основных наборов прав — на чтение (чтение списка объектов, разрешения на чтение, чтение содержимого) и изменение (право на чтение + изменение содержимого, удаление файлов и каталогов, создание файлов и каталогов).
В некоторых случаях можно использовать специальные группы (отдельный тип группы), способные предоставить только необходимую часть из двух основных полных наборов прав доступа.
- Запрещено использовать «запрет доступа» ни при каких обстоятельствах.
- Рекомендуется использовать ABE, если необходимо скрыть от просмотра ненужные каталоги или при необходимости не просто запретить доступ, но, по возможности, обеспечить видимость их отсутствия.
Любые необходимые действия с правами доступа можно выполнить в пределах трех последних пунктов.
Следование этим правилам сделает ваш сервис совместного использования масштабируемым, понятным любому инженеру и более безопасным.
Основным результатом станет явное снижение затрат на сервисную поддержку и снижение некоторых рисков.
P.S. Остальные разделы дизайна (цели, риски, роли, связи с другими политиками) в данном случае не менее важны для оптимального и успешного проектирования, внедрения и поддержки сервиса.
А значит, им необходимо уделять не меньше внимания, чем оформлению разрешения или поддержанию порядка в структуре каталогов.
Дабы не холиварить по поводу пункта 10, сразу хочу добавить, что любой отказ в доступе можно заменить правильно оформленными разрешениями.
Использование «Запретить доступ» значительно усложняет расследование инцидентов на больших уровнях вложенности, но и на малых уровнях может доставить массу неприятностей.
Соответственно, использование наследования и только разрешительных наборов прав доступа дает уверенность в том, что механизм наследования прозрачен и что нигде между несколькими уровнями от вас ничего не скрывается.
С ABE нужно быть очень осторожным и помнить о его наличии, иначе при расследовании инцидентов возникнет большая путаница.
Теги: #дизайн #управление сервисами #файловый сервер #файловый сервер #разрешения безопасности #оптимизация сервера #оптимизация сервера
-
Прикладная Психология
19 Oct, 24 -
Об Ит-Бизнесе И Не Только
19 Oct, 24 -
Мышь Для Скайпа?
19 Oct, 24 -
111 Заметок Доменера
19 Oct, 24 -
Песня Явы
19 Oct, 24
