За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.
Что же это такое?
Процитируем Википедию:
Авториза́ция (англ. authorization «разрешение; уполномочивание») — предоставление определенному лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий. |
Реализация авторизации при разработке корпоративной информационной системы или продукта, ориентированного на корпоративный сектор — очень сложная и ответственная задача, которой часто уделяется недостаточное внимание на этапе проектирования и первичном этапе разработки, что в будущем ведет к «костыльной» реализации.
Проблематика
Давайте разберемся, какие требования к авторизации встречаются, и почему их крайне важно учитывать изначально при проектировании системы, а не откладывать на будущее. Источников требований к авторизации в корпоративной информационной системе, как правило, два — это бизнес и информационная безопасность. В общем случае бизнес хочет хранить секреты в тайне и предоставлять полномочия пользователям в соответствии с их функцией в бизнес-процессе, а безопасность хочет обеспечить минимальную достаточность полномочий каждому пользователю и аудировать доступ.
Возьмем для примера гипотетическую систему согласования договоров крупной компании, типовой кровавый энтерпрайз. Практически наверняка возникнут следующие требования к авторизации от бизнеса:
- Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
- Автор договора должен видеть его на всех этапах.
- Создавать договор имеет право пользователь с грейдом не ниже 10.
- Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
- Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
- Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
- Руководство и секретариат головного офиса должны видеть документы всех филиалов.
- Пользователь, создавший договор, не должен иметь права его завизировать.
От безопасности мы могли бы получить следующие требования:
- Знать, кто имеет доступ к конкретному договору.
- Знать, кто имел доступ к конкретному договору в заданный момент времени.
- Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.
Думаю, разработчикам уже стало страшно :). Дополнительную боль доставляет высокая изменчивость этих требований. Кстати, по статистике одного большого франча 1С – дополнительные требования по авторизации — одна из самых частых задач по кастомизации типовых конфигураций.
Итак, обозначим, почему эти требования проблемные:
- Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
- Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
- Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики.
- Они влияют на производительность.
Пути решения
Решить данную задачу нам помогают разработанные модели управления доступом:
MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.
DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.
RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.
АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).
Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.
Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:
| Требование от бизнеса |
Решение |
|
|---|---|---|
| 1 |
Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе |
Тут напрашивается ACL, поскольку определить отношение пользователя к бизнес-процессу достаточно сложно, не записывая его в какой-то список в момент вовлечения. Это будет оптимальным решением с точки зрения производительности чтения относительно реализации с помощью политик. |
| 2 |
Автор договора должен видеть его на всех этапах |
Требование может быть реализовано обоими механизмами, но оптимальным я считаю ACL, поскольку в этом случае будет проще реализовать требование №3 от ИБ. |
| 3 |
Создавать договор имеет право пользователь с грейдом не ниже 10 |
Это политика (PBAC), без вариантов |
| 4 |
Визирующий должен видеть договор начиная с поступления к нему на этап и далее |
ACL будет оптимален |
| 5 |
Руководители подразделений должны видеть договоры своих подразделений вниз по иерархии |
Замечательная задача для PBAC, но его применение может снизить производительность чтения, а требования 1 и 2 от ИБ потребуют дополнительных усилий, поэтому стоит подумать над реализацией. |
| 6 |
Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования |
PBAC справится отлично |
| 7 |
Руководство и секретариат головного офиса должны видеть документы всех филиалов |
PBAC, с теми же ограничениями что и в п. 5 |
| 8 |
Пользователь, создавший договор, не должен иметь права его завизировать |
Это требование можно было бы закрыть с помощью PBAC, однако так делать не стоит. Это то самое место, где авторизация вступает в конфликт с бизнес-логикой, и если происходит такая ситуация, ответственность стоит отдать бизнес-логике. |
Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:
| Требование от ИБ |
Решение |
|
|---|---|---|
| 1 |
Знать, кто имеет доступ к конкретному договору |
Общий журнал для ACL и PBAC |
| 2 |
Знать, кто имел доступ к конкретному договору в заданный момент времени |
Общий журнал для ACL и PBAC |
| 3 |
Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей |
ACL |
Итого
Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований.
Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.
