Изоляция арендаторов в многопользовательском приложении

Здравствуйте, все! В этой главе мы разовьем наши предыдущие обсуждения по темам многопользовательских приложений. Если вы ещё не читали предыдущие статьи, мы рекомендуем начать с них!

• Являются ли многопользовательские приложения = SaaS?
• Модели аренды для многопользовательского приложения

При обсуждении многопользовательских приложений важно подумать о изоляции арендаторов. Это означает отделение и защиту данных и ресурсов различных арендаторов в единой системе (например, в облачной инфраструктуре или многопользовательском приложении).

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

В сценарии Software as a Service (SaaS) изоляция арендаторов включает создание структур в рамках SaaS, которые строго регулируют доступ к ресурсам. Это предотвращает любые несанкционированные попытки доступа к ресурсам другого арендатора.

Хотя объяснение может показаться абстрактным, мы используем примеры и ключевые детали, чтобы подробнее объяснить концепцию изоляции.

Изоляция арендаторов не противоречит "общей" концепции многопользовательской системы#

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

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

Уровни изоляции#

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

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

Диаграмма ниже иллюстрирует этот спектр изоляции.

Аутентификация и авторизация не равны "изоляции"#

Использование аутентификации и авторизации для контроля доступа к вашим SaaS-средам важно, но этого недостаточно для полной изоляции. Эти механизмы — лишь часть головоломки безопасности.

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

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

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

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

Идентичность в многопользовательских приложениях#

Мы обсудили изоляцию арендаторов, но как насчет идентичностей? Как решать, должны ли они быть "изолированными" или нет?

Часто возникает путаница в понятии "изоляции идентичности". Это может касаться ситуаций, когда один реальный пользователь имеет две идентичности в общем понимании.

1. Обе идентичности могут существовать в единой системе идентификации. Например, у Сары может быть личная электронная почта, зарегистрированная вместе с корпоративной почтой, связываемой через единый вход (SSO).
2. Пользователи поддерживают две отдельные идентичности внутри различных систем идентификации, представляющих совершенно разные продукты. Эти продукты полностью не связаны друг с другом.

Иногда эти сценарии называют "изолированной идентичностью". Однако такой ярлык может не помочь в принятии решения.

Вместо того, чтобы определять, нужна ли вам "изоляция идентичности", рассмотрите, требуется ли вам или части вашего бизнеса или продукта поддерживать отдельные системы идентификации. Этот ответ может направить дизайн вашей системы управления идентификацией и доступом (IAM). Для краткого ответа по многопользовательскому приложению,

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

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

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

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

Logto представляет функцию "Организация" в ноябре#

Logto в настоящее время активно разрабатывает функцию "Организация", с целью выхода в ноябре 2023 года. Эта функция специально создана для удовлетворения требований изоляции арендаторов, необходимых для создания SaaS-продукта, соответствующего отраслевым стандартам и лучшим практикам.

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