Как спроектировать систему управления доступом
Изображение создано нейросетью на shutterstock.com
Это упражнение, только более детально и под запись мы проделываем со всеми нашими клиентами, составляя ТЗ на внедрение системы управления доступом. Оно похоже на прорисовку карты местности. С такой картой можно адекватно выбирать маршрут и планировать ресурсы.
Разминка: пользователи и системы
Очевидно, что для начала нам понадобятся список видов пользователей и список систем.
Хорхе Луис Борхес в одном из рассказов упоминает классификацию животных, согласно которой они делятся на «принадлежащих Императору», «прирученных», «молочных поросят», «похожих издали на мух» и несколько подобных категорий. Я напоминаю об этом сейчас, потому что первые версии списков пользователей и систем могут быть настолько же бессистемны, и это нормально.
Итак, выписываем категории пользователей: офисные сотрудники, администраторы, разработчики...
Затем продолжайте перечислять группы пользователей, которым потребуются самые разные доступы. Сейчас интуитивное видение важнее рационального. Предположу, что список будет состоять более чем из 10 позиций и в нем появятся изначально неожиданные группы, например «подрядчик» или «клиент B2B». Это признак хорошей проработки. Остановиться следует, когда вам захочется отделить простого бухгалтера от главного. Полноценная ролевая модель сейчас не нужна. Далее второй список — системы, в которые нужно организовать доступ. Смотрим на список категорий пользователей и записываем системы для них. На данном этапе важно игнорировать сложность технической реализации единого входа в эти системы.
У вас получится: кадровая система, бухгалтерия, система службы поддержки, CRM...
Пока наполняется второй список, кое-что может добавиться в первый.
У небольшой организации список систем будет 10+. Крупная организация насчитает несколько десятков.
Остановитесь, когда устанете. Это лишь мысленное упражнение.
Просто: аутентификация
Техническое решение задачи единого доступа имеет три составляющие: хранение данных о пользователе, непосредственно вход (аутентификация) и определение прав доступа (авторизация).
Если мы говорим про единый вход, это означает, что пользователь логинится в систему аутентификации (также используются аббревиатуры IDP, SSO, IAM), а остальные системы ей доверяют.
Проработка сценариев входа — отдельная задача. Она может казаться аналитически емкой, но реализация сценариев будет относительно легкой, если для внедрения вы выбрали современную систему управления доступом. Это будет легко, даже если вы захотите не просто вход, а адаптивную мультифакторную аутентификацию (когда сценарий входа зависит от множества параметров: кто логинится, куда, когда, откуда, каким образом и так далее).
Поэтому в нашем мысленном упражнении сейчас важны не сценарии, а возможности систем взаимодействовать с единой системой аутентификации.
Системы, список которых вы составили ранее, нужно разделить на поддерживающие современные протоколы (ищем в документации слова OIDC, OAuth2.0, SAML) и не поддерживающие. С первыми интеграция будет относительно быстрой, вторые нужно изучать индивидуально, хотя и для них существуют решения. Например, мы для этих целей разработали Access gateway.
Сложнее: управление учетными записями
Теперь задумайтесь, откуда в системе аутентификации возьмется информация о пользователях. Один из самых частых ответов — LDAP-совместимый каталог (еще не так давно просто MS AD). Однако взгляните на список категорий пользователей. Все ли они есть в этом каталоге? Например, в нем ли хранятся данные клиентов, партнеров, подрядчиков, кандидатов, которые еще не сотрудники? Также подумайте, один ли у вас такой каталог или развернут так называемый мультилес. Только из вашего каталога нужно будет брать учетные данные или сотрудники партнеров/франчайзи/аутсорсеров приходят со своими?
Отдельного внимания заслуживают категории пользователей, для которых может не оказаться ответа на вопрос, в какой системе зарождаются их учетные данные. (Помните, в фильме «День Радио» упоминались «подкустовые выползни», про которых было известно, что они появляются из-под куста и сразу взрослыми.)
Кстати, после размышлений над источниками учетных данных список категорий пользователей может еще расшириться.
Со звездочкой: авторизация
Итак, пользователи разложены по каталогам, системы интегрированы с централизованной аутентификацией, наступает рабочий день. Как на практике с уверенностью определить, можно ли Саше создавать платежки, а Жене регистрировать товар на складе?
Всё зависит от того, что именно умеет каждая конкретная система из второго списка.
Вариант #1. Система умеет проверять права пользователя только сама у себя. В этом случае назначать права можно только внутри самой системы, и это довольно дорогое удовольствие, но иногда другого выхода нет.
Вариант #2. Система умеет проверять права пользователя в каталоге пользователей. Сейчас это один из самых распространенных вариантов. Минусы — помним, что не все пользователи живут в каталоге.
Вариант #3. Система умеет получать права из системы аутентификации и доверять им. Это удобнее и дешевле, поскольку доступы пользователя хранятся в одной центральной системе.
Вариант #4. Система может полностью отдать проверку внешней системе управления доступом. В этом случае все запросы на действия пользователя сначала попадают в систему авторизации. Она проверяет наличие прав на выполнение действия, и если права есть, только тогда запрос попадает в целевую систему уже без дополнительных проверок.
Скорее всего, мысленно распределить системы по этим категориям будет сложно, но вы уже знаете, какие задачи нужно сформулировать, чтобы начать проект внедрения единого входа с полностью прорисованной картой.
Правильные ответы
Каждый крупный бизнес уникален, как и его набор инструментов. Основная проблема полноценной организации доступа в реальных условиях состоит в разнообразии пользователей и систем, в которые надо организовать доступ. Но в любом случае минимальный набор функциональных блоков будет состоять из:
- системы аутентификации, включая многофакторную аутентификацию;
- системы управления учетными записями;
- системы управления ролями и привилегиями;
- системы авторизации.
Самая частая ошибка, которую мы наблюдаем, — нежелание компаний решать задачу управления доступом сразу целиком. Приобретая отдельные продукты под решение каждой отдельной задачи, компании тратят существенно больше денег, чем могли бы при комплексном подходе.
Наше решение по управлению доступом — RooX UIDM — построено на принципах платформы. Из множества модулей можно собрать эффективное кастомизированное решение для систематизации и управления доступом.
Опубликовано 28.10.2024
