Дизайн системы полномочий является необходимым модулем почти для каждой системы.В последнее время у меня есть некоторый опыт проектирования системы полномочий. Я столкнулся с некоторыми ямами и у меня есть некоторые мысли, поэтому я хочу записать их и поделиться ими с вами.
Цель этой статьи — помочь вам понять некоторые основные концепции дизайна разрешений и предоставить общие идеи дизайна для систем разрешений.
Прежде всего, давайте бросим случай, читатели могут подумать о том, как выполнить это требование, если они разработают свою собственную систему разрешений?
Описание требования:
В университете много людей. Студенты готовятся к выпускным экзаменам. Для выпускной экзаменационной работы существуют следующие требования к управлению правами:
- В течение всего процесса преподаватель курса может просматривать экзаменационную работу.
- Во время экзамена наблюдатель курса может просматривать экзаменационную работу.
- Во время экзаменов студенты этого курса могут просматривать и писать свои собственные экзаменационные работы.
- После экзамена преподаватель курса может написать экзаменационную работу
- После экзамена декан года может просмотреть экзаменационные работы по всем предметам в классе.
- В течение всего процесса уборщица не может просматривать/писать контрольную работу.
- На протяжении всего процесса директор может просматривать любую бумагу
Примечание: Экзаменационный процесс делится на доэкзаменационный, во время экзамена и после экзамена. У человека может быть несколько ролей.
UML-диаграмма:
Аутентификация и авторизация
Контроль доступа к системе можно разделить на две части: аутентификация и авторизация. Это относительно независимые концепции, и их разделение помогает нам лучше понять структуру системы разрешений.
Аутентификация Аутентификация
Так называемая сертификация должна определить, являетесь ли вы самим собой. С точки зрения непрофессионала, это обычный шаг «входа» в нашу систему. Для этой проверки существует множество методов и технологий, таких как проверка формы, базовая проверка HTTP, функция «запомнить меня» на основе файлов cookie, OAuth2 и даже проверка отпечатков пальцев.
Технические детали различных методов аутентификации не будут подробно обсуждаться в этой статье, и эта часть не находится в центре внимания данной статьи. Читателям нужно только знать, что первым этапом контроля разрешений является аутентификация.Если аутентификация пройдена, это означает, что пользователь вошел в систему. Что касается управления полномочиями различных последующих предприятий, то оно не находится под управлением аутентификации.
Авторизация Авторизация
Аутентификация не имеет значения для управления бизнесом, так кто же здесь главный? Это авторизация. Именно этому посвящена данная статья.
Прежде всего, нам нужно подумать над вопросом: какова главная цель дизайна разрешений в нашей системе? Я думаю, что это сочетание «гибкости» и «простоты в управлении». Другими словами, наш дизайн разрешений должен гибко реагировать на изменения, включая изменения пользователей и изменения требований к бизнес-разрешениям. Но в то же время им должно быть проще управлять, чтобы наши разрешения были достаточно понятными и не путались.
Итак, основываясь на вышеуказанных целях, я думаю, что дизайн системы разрешений должен основываться на следующих трех принципах:
достаточно
Акцент здесь заключается в том, что система разрешений должна быть простой предпосылкой удовлетворения спроса, не переусердствовать. Например, для моего личного сайта-блога пользователю нужно иметь только один мой собственный, тогда мне нужно сделать очень сложный контроль доступа.
Средняя степень детализации
«Гранулярность» здесь относится к гранулярности разрешений. Если степень детализации разрешения слишком грубая, несколько бизнес-сценариев будут использовать одно разрешение, а гибкость будет низкой; если степень детализации разрешений слишком мала, это увеличит количество разрешений и затруднит управление.
В качестве детализации разрешений рекомендуется использовать бизнес-операции. Бизнес-операция соответствует разрешению. В отрасли также есть такие инструменты, как DDD (Domain Driven Design), помогающие лучше разделить бизнес.
Например, в нашем случае выше, хотя и у преподавателей, и у студентов есть операция «написание контрольной работы», на самом деле, понимая дело, мы можем разделить его на «ответы на вопросы» и «выставление оценок».
Существует ли однозначное соответствие между API и бизнес-операциями? Большинство бизнес-сценариев должно быть, но есть исключения. Например, чтобы отправить моменты WeChat, вам нужно личное присутствие, загрузка изображений и фактическое сохранение контента, который вы хотите отправить.Эти три операции образуют бизнес «Отправка моментов», который соответствует трем видам бизнеса.
Согласно практике автора, для доступа к этим трем API рекомендуется использовать одно разрешение. Или три разрешения, соответственно соответствующие соответствующему API, но есть понятие "группа разрешений", добавьте три из них в группу разрешений, и назначьте эту группу разрешений при фактическом назначении разрешений. Не рекомендуется, чтобы только три разрешения контролировали три API соответственно.
Используйте белые списки, когда это возможно
Это одна из известных принципов безопасности. Когда мы реализуем систему разрешений, мы должны попытаться использовать белый список вместо черный список. Например: только люди с администрацией XX могут проводить XX Business. Вместо этого люди без XX авторитет могут проводить XX Business.
Основная модель проектирования разрешений
Разработка разрешений — непростая задача, но в основном все системы требуют разработки разрешений. На самом деле, в отрасли уже есть несколько основных моделей дизайна разрешений. Вот лишь некоторые из часто используемых.
ACL
Списки контроля доступа в основном используются для простого контроля разрешений. Особенно в управлении сетевыми потоками, он часто используется и редко используется в бизнес-системах.
RBAC
Управление доступом на основе ролей (Role-Based Access Control), разрешения связаны с ролями, и пользователи получают разрешения этих ролей, назначая соответствующие роли. Это также самая распространенная модель дизайна разрешений в отрасли. RBAC плохо справляется с проверкой разрешений, связанных со «статусом данных», таких как требование о том, что «тестовая работа находится перед тестом, ее может просматривать только учитель». Вам нужно самому дописать персонажа до смерти, а потом прописать проверку логики в коде.
ABAC
Управление доступом на основе атрибутов (Attribute-Based Access Control) для решения вышеуказанных проблем в отрасли существует решение под названием ABAC. Оценка состояния данных путем написания динамического DSL и контроля разрешений с помощью специального синтаксиса.
ABAC также иногда называют PBAC (управление доступом на основе политик) или CBAC (управление доступом на основе утверждений). ABAC обычно используется в системах уровня платформы. Например, «облачные провайдеры», такие как AWS и Alibaba Cloud, имеют огромные ресурсы и роли и требуют очень гибкой системы управления разрешениями.
ABAC дорого реализовать. Управление также более сложное.
Пример (оперативная память Alibaba Cloud):
{
"Version": "1",
"Statement":
[{
"Effect": "Allow",
"Action": ["oss:List*", "oss:Get*"],
"Resource": ["acs:oss:*:*:samplebucket", "acs:oss:*:*:samplebucket/*"],
"Condition":
{
"IpAddress":
{
"acs:SourceIp": "42.160.1.0"
}
}
}]
}
Эволюция дизайна разрешений
На основании вышеизложенногодостаточноПринцип, согласно которому системы разрешений не должны быть слишком сложными. Мы можем условно разделить их на три категории от простых до сложных в соответствии с требованиями разрешения:
- Требуется только один администратор для управления всем, как личные сайты блога.
- Есть только некоторые пользователи и роли, а разрешения ролей относительно стабильны. Применимо к большинству систем.
- Пользователей и ролей много, и разрешения ролей можно легко изменить. Системы уровня платформы, такие как AWS.
Поскольку второй вариант подходит для большинства ежедневных проектов разработки, он в основном обсуждается позже. Если это третий тип, рекомендуется разработать индивидуальную систему разрешений на основе ABAC.
Различайте доступ и проверку
Давайте проясним некоторые понятия этих двух существительных:
- Доступ: то, могу ли я вызвать этот API, не имеет ничего общего с данными, они могут быть перехвачены на уровне шлюза.
- Валидация: я могу вызвать этот API, но есть ли соответствующее разрешение, связанное с бизнес-данными, вы можете написать Validator для проверки, рекомендуется поставить его в службу самого низкого уровня.
Для многих друзей, которые занимаются дизайном разрешений в первый раз, легко спутать их, и разработанные разрешения могут показаться запутанными.
Давайте еще раз проанализируем случай, взяв в качестве примера бизнес-операцию «чтение контрольной работы», мы можем иметь доступназываетсяREAD_PAPERи назначьте его ролям студентов, преподавателей, наблюдателей, деканов и директоров. От их имени они могут вызывать этот бизнес-API. При входе в конкретную логику проверки вам необходимо проверить базу данных, чтобы получить статус контрольной работы, соответствующий класс, идентификатор наблюдателя и другую информацию.ValidationЧтобы проверить эти данные, может ли текущая роль получить доступ.
В следующей статье более подробно будет представлен набор рекомендуемых решений для проектирования разрешений с точки зрения внешнего и внутреннего интерфейса, степени детализации разрешений и уровня кода.
Следующее уведомление: «Дизайн системных разрешений — рекомендуемая схема»