Поделиться через

Эффективное проектирование ролей

Во многих сценариях безопасность на основе ролей является очень эффективным механизмом, но существуют ситуации, когда она менее эффективна. Следует учитывать ряд факторов при определении того, где и как применять безопасность на основе ролей к конкретному приложению.

Характеристики пользователей и данных и пригодность ролей

Роли работают очень хорошо, чтобы охарактеризовать группы пользователей и, на этом основании, фильтровать действия, которые могут выполнять эти пользователи. Часто это выполняется на практике путем создания ролей, которые отражают место пользователя в организации, например роли "Менеджеры" и "Рассчитыватели", "Администраторы" и "Читатели", "Project One Employees" и "Project Two Employees". В таких случаях, когда доступ к данным является довольно универсальным относительно пользователей, роли можно использовать эффективно для применения бизнес-правил, таких как:

  • "Менеджеры могут передать любую сумму денег. Операторы могут перевести только до $ 10,000.

  • Администраторы могут изменить что угодно. Все остальные могут только читать.

  • "Сотрудники Project One могут получить доступ к определенной базе данных. Никто другой не может.

Пользователи могут естественно попасть в несколько ролей в зависимости от того, как роли моделировают организационную структуру бизнеса.

Однако роли не работают очень хорошо, когда решение о доступе к безопасности зависит от характеристик определенного фрагмента данных. Например, было бы трудно использовать роли для отражения сложных связей пользователей с данными, таких как:

  • "Конкретный менеджер может получить доступ к данным персонала только для ее отчетов".

  • Джо Потребитель может проверить баланс своего счета.

В таких случаях проверка безопасности часто выполняется в самой базе данных, где проще учитывать характеристики доступа к данным. Это означает, что необходимо использовать олицетворение для передачи удостоверения клиента вместе с базой данных и разрешить базе данных проверить запрос. Это может оказывать влияние на производительность и дизайн приложения. Например, пул подключений может перестать работать, если соединение устанавливается с использованием конкретного удостоверения пользователя. Обсуждение проблем, связанных с этим, см. в многоуровневая безопасность приложений и олицетворение клиента и делегирование.

Сложность и масштабируемость политики авторизации Role-Based

Какая бы политика безопасности ни была введена, будет эффективной только как ее реализация системными администраторами, развертывающими приложение. Если администраторы ошибаются при назначении пользователей правильным ролям в соответствии с политикой безопасности, политика не будет работать должным образом. Проблемы, скорее всего, возникают в следующих обстоятельствах:

  • Вы создали очень сложную политику на основе ролей, с множеством пользователей и ролей, сопоставленных с многочисленными ролями.
  • Вы создаете роли с неоднозначными критериями для того, кто должен принадлежать к ним.
  • На сайте установлено приложение, и его используют много пользователей; пользователи часто перемещаются внутри организации, меняя свои функции в зависимости от созданных вами ролей.
  • На сайте, где установлено приложение, имеется множество администраторов, с разделением обязанностей, поэтому администратор, знакомый с требованиями к безопасности приложения, потенциально не знакомы с большими группами пользователей, которые должны использовать его. Это особенно важно, так как пользователи перемещаются в организации— такая информация должна быть хорошо передана.

Кроме того, по мере увеличения числа ролей, назначенных приложению, возрастает и время, которое COM+ должно тратить на проверку членства вызывающего абонента в этих ролях, что может привести к вероятному снижению производительности.

Для управления сложностью и устранением этих проблем можно использовать следующие рекомендации.

  • Выбирайте название ролей, которые являются самоописательными. Сделайте его как можно более очевидным, какие пользователи должны принадлежать к каким ролям.
  • Сделайте политику на основе ролей максимально простой (но не упрощайте её чрезмерно). Выберите как можно меньше ролей, сохраняя эффективную политику.
  • Четко документируйте политику на основе ролей, созданную для администраторов, независимо от того, является ли членство в роли очевидным (для вас). В частности, используйте поле описания, доступное для каждой роли, чтобы описать намерение роли. Если вы не можете описать как правило, кто должен принадлежать роли в нескольких предложениях, это, вероятно, слишком сложно.
  • Настоятельно рекомендуется, чтобы администраторы приложения заполняли роли группами пользователей вместо отдельных пользователей. Это гораздо более масштабируемое решение. Это упрощает переназначение или удаление пользователей по мере перемещения в организации и изоляции администраторов от определенного объема надзора и проблем в обмене данными.

Пределы безопасности

сведения о контексте вызова безопасности

свойства контекста безопасности

использование ролей для авторизации клиента