Управление удостоверениями и доступом для рабочих нагрузок SaaS в Azure
Удостоверение приложения является важной областью для рабочих нагрузок SaaS, так как она служит первой строкой защиты для защиты данных. Он часто упускается из виду до конца проекта, но многие решения о других элементах приложения зависят от твердой стратегии идентификации. Не недооценивайте важность идентификации для защиты данных клиентов.
В контексте рабочих нагрузок SaaS существует два разных типа удостоверений.
Удостоверение приложения, также известное как управление удостоверениями клиентов и доступом (CIAM), позволяет конечным пользователям проходить проверку подлинности и использовать приложение SaaS. Существует два основных метода входа пользователей в поставщик удостоверений приложения:
Федеративные удостоверения. Пользователи войдите с существующими учетными данными, которые поддерживаются другим поставщиком удостоверений. Этот поставщик может быть поставщиком удостоверений социальных сетей, таких как Google, Facebook или LinkedIn, или поставщик корпоративных удостоверений, используемый клиентами, например Microsoft Entra или Okta. Обслуживание учетной записи пользователя является ответственностью федеративного поставщика удостоверений.
Локальные удостоверения. Пользователи создают учетную запись только для приложения. Учетная запись защищена именем пользователя и паролем, секретным ключом или другими методами проверки подлинности. Обслуживание учетной записи пользователя является вашей ответственностью.
Корпоративное удостоверение — это решение для идентификации, которое используется для проверки подлинности внутренних пользователей и рабочих нагрузок в средствах повышения производительности бизнеса, внутренних средствах или службах Azure. Вы используете решение корпоративной идентификации для внутренних пользователей и рабочих нагрузок для проверки подлинности пользователей и рабочих нагрузок для проверки подлинности в средствах повышения производительности бизнеса, внутренних средствах или службах Azure.
См. сведения об управлении удостоверениями и доступом SE:05.
Удостоверения приложений и предприятий служат различным целям и могут использовать разные поставщики удостоверений. В этой статье рассматриваются рекомендации по проектированию удостоверений приложений, хотя оба типа, скорее всего, будут присутствовать в рабочей среде Рабочей нагрузки SaaS.
Управление удостоверениями включает в себя две связанные проблемы: проверка подлинности (проверка удостоверения пользователя) и авторизация (предоставление разрешений на основе удостоверения). Первые три раздела этой статьи посвящены проверке подлинности для SaaS. В последнем разделе рассматриваются рекомендации по авторизации для поставщиков SaaS.
Удостоверение в мультитенантном приложении
Сохранение данных клиента отдельно в мультитенантном приложении является критически важным. Эта сегментация зависит от вашего выбора эффективной проверки подлинности и авторизации пользователей. Кроме того, выбор модели аренды значительно влияет на ваши решения о поставщике удостоверений. Приоритет удостоверения в качестве основного периметра.
Ознакомьтесь с рекомендациями SE:04 для сегментации.
Рекомендации по проектированию
Ознакомьтесь с моделями аренды и развертывания для приложения. Могут возникнуть нюансы, влияющие на стратегию идентификации. Например, это неправильное представление о том, что шаблон меток развертывания требует поставщика удостоверений в каждой метке. Для большинства поставщиков удостоверений часто можно использовать альтернативную модель изоляции.
При выборе поставщика удостоверений для мультитенантности оцените влияние сбоев. Неправильные конфигурации могут привести ко всему приложению для всех клиентов. Весите затраты накладные расходы по риску потенциального радиуса воздействия.
Если вы развертываете решение в среде Azure клиента и управляете им от своего имени, может потребоваться интегрироваться с поставщиком удостоверений предприятия. Четкое представление об этих аспектах:
- Типы пользователей и их доступ, необходимые для взаимодействия с клиентами приложения. Например, пользователю A может потребоваться только доступ к входу в клиент 1, но пользователю B может потребоваться доступ как к клиенту 1, так и к клиенту 2.
- Соответствие нормативным требованиям к месту расположения данных, если они применимы к поставщику удостоверений. В некоторых случаях данные, хранящиеся поставщиком удостоверений, могут применяться к нормативным требованиям. Многие поставщики удостоверений предоставляют определенные рекомендации и возможности для этого сценария. Оцените, относится ли этот сценарий к вам и выполните необходимые действия для обеспечения соответствия требованиям.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Следуйте рекомендациям и рекомендациям поставщика удостоверений по секционированию решения для нескольких клиентов. | Изоляция клиентов помогает достичь целей безопасности и соответствия требованиям. |
| Избегайте нескольких учетных записей одного пользователя. У пользователя должна быть одна учетная запись с одним набором учетных данных, даже если им нужен доступ к нескольким клиентам. Предоставление доступа каждому клиенту по мере необходимости, а не создание нескольких учетных записей для одного пользователя. | Создание нескольких учетных записей для одного пользователя повышает риски безопасности и может запутать пользователей, которые должны помнить несколько имен пользователей и паролей для одного программного обеспечения. |
| При рассмотрении расположения данных запланируйте хранение пользовательских данных в отдельных расположениях. При развертывании отдельной метки развертывания для пользователей в других географических регионах также могут потребоваться отдельные поставщики удостоверений. Убедитесь, что у вас есть способ определить, где хранятся данные пользователей, чтобы вы могли направлять их в правильный регион для входа, если вам нужно. |
Вы сможете поддерживать требования соответствия требованиям и улучшить взаимодействие с пользователем, перенаправив пользователей в интерфейс входа, соответствующий их расположению. |
Выбора поставщика удостоверений
Каждый поставщик удостоверений предлагает уникальные функции, ограничения, модели ценообразования и шаблоны реализации. Microsoft Entra и Okta являются популярными параметрами удостоверений как услуга (IDaaS). Существуют также другие поставщики открытый код, такие как Keycloak и Authentik.
Рекомендации по проектированию
Задокументируйте требования к удостоверениям. Начните с перечисления функций, необходимых приложению, и в будущем потребуется. Типичные функции, которые следует учитывать, включают:
-
- Поддержка федеративного поставщика удостоверений для интеграции с решениями идентификации клиентов. Эта функция позволяет избежать создания новых удостоверений.
- Настраиваемый поток входа или регистрации, чтобы изменить внешний вид и чувствовать себя для поддержания фирменной символики. Эта функция также обеспечивает возможность внедрения пользовательской бизнес-логики в процесс входа или регистрации.
- Разделение данных клиента на отдельные силосы для поддержания изоляции клиента.
- Поддержка аудита для хранения или экспорта журналов входа для управления безопасностью.
Внимание
Учитывайте запланированный рост пользователей при оценке стоимости решения идентификации. Решение может не оставаться экономически эффективным или масштабируемым в долгосрочной перспективе, но это может быть полезно на данный момент. У вас есть план миграции, который можно использовать при возникновении необходимости.
Например, решение может быть доступно для 500 пользователей, но не является приемлемым для 5 миллионов. Если требуется минимальная настройка и удобная и удобная для миграции, она по-прежнему может быть правильным выбором, пока масштабирование затрат не будет оправдано переходом на другое решение.
Тщательно изучите возможности поставщика удостоверений. Убедитесь, что решение удостоверений соответствует списку необходимых функций. Даже если в настоящее время вам не нужны сложные сценарии, такие как федеративное удостоверение, рассмотрите будущие потребности. Для решений SaaS для бизнеса (B2B) федеративное удостоверение, вероятно, потребуется в конечном итоге.
Фактор затрат на управление. Для разных поставщиков удостоверений требуются различные уровни затрат на управление. Хорошо известные решения IDaaS обычно имеют меньше накладных расходов, так как они обрабатывают размещение, обслуживание и безопасность. Однако дополнительные затраты на решение открытый код могут быть полезными, если решение лучше подходит для ваших специализированных потребностей.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Не создавайте собственное решение удостоверений. Удостоверение является высоко специализированной областью, и создание решения для идентификации является сложным и дорогостоящим. Трудно создать решение для идентификации, безопасное и надежное. | Вы будете избегать антипаттерна создания собственного поставщика и повышения безопасности, надежности и эффективности работы вашего решения. |
| Создайте матрицу возможностей функций, предлагаемых поставщиками удостоверений, и сопоставите ее с требованиями к удостоверениям. | Вы обеспечите возможность развития без ограничения ограниченным набором функций удостоверений. |
| Предпочитайте варианты IDaaS по сравнению с открытый код решениями. Размещение решения открытый код самостоятельно несет значительные операционные издержки и риски безопасности. Однако вы можете выбрать этот вариант для удовлетворения конкретных требований к соответствию, месту размещения данных или надежности, которые поставщик не может выполнить. Дополнительные сведения см. в разделе поставщиков удостоверений IDaaS. |
Используя поставщик удостоверений IDaaS, вы будете избегать ненужных сложностей и сосредоточить усилия на основной бизнес. |
Федеративное удостоверение
Федеративное удостоверение, также известное как единый вход (SSO), позволяет пользователям входить с учетными данными, которые они уже используют в другом месте. Федеративное удостоверение можно включить, установив связь доверия между поставщиком удостоверений приложения и существующим поставщиком удостоверений клиента. Федеративное удостоверение является общим требованием для решений SaaS, особенно в B2B, так как клиенты предпочитают, чтобы их сотрудники использовали корпоративные учетные данные. Он предлагает несколько преимуществ для решений B2B, таких как централизованное управление удостоверениями и автоматическое управление жизненным циклом. В продуктах SaaS B2C интеграция с поставщиками удостоверений социальных сетей обычно позволяет пользователям входить с помощью существующих учетных данных.
Компромисс: сложность и эффективность работы. Работая с федеративными поставщиками удостоверений, вы разгрузите сложность управления удостоверениями пользователей. Однако вы берете на себя затраты на интеграцию с другим поставщиком удостоверений. Определите, где вы хотите сосредоточить свои рабочие усилия.
Хотя реализация федеративного удостоверения изначально проста, она становится более сложной по мере увеличения числа поддерживаемых поставщиков удостоверений. Тщательное планирование важно, особенно если каждый клиент использует уникальный поставщик удостоверений. Даже если они используют один и тот же поставщик удостоверений, для каждого клиента часто требуются уникальные отношения доверия из-за конкретных сведений о конфигурации.
На этом рисунке показана связь между приложением, поставщиком удостоверений приложения и подчиненными поставщиками удостоверений, которые можно реализовать с помощью федерации удостоверений.
Рекомендации по проектированию
Оцените типы и количество поставщиков удостоверений, необходимых для поддержки. Возможно, вам потребуется статическое число поставщиков удостоверений социальных удостоверений, или вам может потребоваться уникальное федеративное удостоверение для каждого клиента. Вы должны знать, будут ли клиенты использовать OpenID Connect (OIDC), язык разметки утверждений безопасности (SAML) или оба для интеграции.
Сопоставить интерфейс входа. Визуализировать поток пользователя процесса регистрации и входа. Обратите внимание на все особые требования, которые могут изменить структуру пользовательского потока. Например:
Настраиваемая фирменная символика. Белые метки или пользовательские домены входа на каждого клиента.
Пользовательские сведения. Сбор дополнительных сведений о пользователе во время регистрации или входа, например выбор клиента для пользователей с доступом к нескольким клиентам.
Выбор поставщика удостоверений. Если вы используете один поставщик удостоверений приложения, который имеет множество федеративных поставщиков удостоверений, доверяющих ему, решите, как выбрать поставщика. Этот выбор может выполняться вручную с помощью кнопки или автоматически на основе известных сведений о пользователе. По мере увеличения числа поставщиков автоматическое выделение становится более практическим. Эта возможность называется обнаружением домашней области.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Выберите поставщика удостоверений, который может масштабироваться для размещения необходимого количества федеративных поставщиков удостоверений. Помните о жестких ограничениях поставщика, которые не могут быть превышены. |
Вы убедитесь, что решение для идентификации может масштабироваться по мере роста. |
| Запланируйте подключение каждого федеративного поставщика удостоверений и автоматизировать процесс как можно больше. Это совместная работа между вашей организацией и клиентами включает обмен информацией для установления отношения доверия, как правило, с помощью протоколов OIDC или SAML. |
Интеграция удостоверений может занять много времени и усилий как для вас, так и для клиентов. Запланируя этот процесс, вы улучшите эффективность работы. |
| Отражает сложность и стоимость федеративного удостоверения в вашей ценовой и бизнес-модели. Позволяя клиентам использовать собственный поставщик удостоверений, увеличивает операционную сложность и затраты из-за затрат на обслуживание нескольких федеративных отношений доверия удостоверений. Обычно в решениях SaaS предприятия платят за более высокий уровень, который обеспечивает федеративный вход. |
Федеративное использование поставщика удостоверений клиента может быть скрытой стоимостью в решениях SaaS. Запланируя его, вы будете избегать непредвиденных затрат во время реализации. |
| Планирование выбора поставщика удостоверений пользователя во время входа. Рассмотрите возможность использования обнаружения домашней области. Идентификатор Microsoft Entra предоставляет встроенное обнаружение домашней области. |
Вы оптимизируете взаимодействие с клиентами и убедитесь, что пользователи направляются в правильный процесс входа. |
Авторизация
Авторизация пользователей имеет решающее значение для приложений SaaS, которые часто хранят данные для нескольких клиентов. Четко определите, как пользователи будут авторизованы для доступа только к своим данным без случайного доступа к данным других клиентов. Кроме того, предоставьте детализированную авторизацию в клиенте, позволяя пользователям считывать или получать доступ к определенной информации при ограничении обновлений или доступе к другим данным.
Рекомендации по проектированию
Выберите правильную модель авторизации для варианта использования. Существует два основных типа:
- Авторизация на основе ролей. Пользователям назначены роли или группы, а определенные функции ограничены определенными ролями. Например, администраторы могут выполнять любое действие, но пользователи в других ролях имеют ограниченные разрешения.
- Авторизация на основе ресурсов. Каждый ресурс имеет собственный набор разрешений. Пользователь может быть администратором одного ресурса, но не имеет доступа к другому.
Решите, где хранить данные авторизации. Данные авторизации для приложения можно хранить в:
- Поставщик удостоверений. Воспользуйтесь встроенными группами или ролями, отображая разрешения в качестве утверждений в маркере, выданном приложению. Затем приложение может применять правила авторизации с помощью этих утверждений маркера.
- Приложение. Разработайте собственную логику авторизации и сохраните разрешения пользователей в базе данных или аналогичной системе, что позволяет точно обработать элементы управления авторизацией на основе ролей или на уровне ресурсов.
Компромисс: сложность, гибкость и безопасность. Хранение данных авторизации в поставщике удостоверений и поиск с помощью утверждений токенов обычно проще, чем управление собственной системой авторизации. Однако авторизация на основе утверждений ограничивает гибкость и необходимо принять, что утверждения обновляются только при повторной отправке маркера, что может привести к задержке применения измененных разрешений.Оцените влияние делегированного управления. В большинстве приложений SaaS, особенно в приложениях B2B, управление ролями и разрешениями делегировано клиентам. Без этой функции вы можете увеличить затраты на управление, если клиенты часто изменяют разрешения своих пользователей.
Оценка мультитенантного доступа. В некоторых системах одному пользователю может потребоваться доступ к данным из нескольких клиентов. Например, консультантам может потребоваться доступ к данным из нескольких клиентов. Планирование предоставления клиентам доступа к этим пользователям и способу входа в систему будет поддерживать выбор и переключение между клиентами.
Рекомендации по проектированию
| Рекомендация | Преимущества |
|---|---|
| Запретить пользователям получать доступ к данным через границы клиента, если доступ не разрешен явным образом. | Несанкционированный доступ к данным другого клиента, даже случайного доступа, может рассматриваться как основной инцидент безопасности и доверие клиентов к вашей платформе. Блокировка ненужного доступа поможет избежать этих ситуаций. |
| Если данные являются статическими и изменяются редко, сохраните их в поставщике удостоверений. Если во время использования программного обеспечения требуются частые изменения, сохраните данные авторизации в приложении. | Выбор оптимального хранилища данных для данных авторизации повысит эффективность работы и поможет вам удовлетворить потребности масштабируемости. |
| Если вы делегируете управление разрешениями клиентам, предоставьте им четкий метод для управления разрешениями. Например, создайте веб-портал, доступный только администраторам клиента для изменения разрешений пользователей. | Вы предоставите клиентам больше контроля и избежать ненужного рабочего бремени в вашей группе поддержки. |
Дополнительные ресурсы
Мультитенантность — это основная бизнес-методология разработки рабочих нагрузок SaaS. В этих статьях содержатся дополнительные сведения об управлении удостоверениями и доступом:
- Рекомендации по архитектуре для удостоверений в мультитенантных решениях
- Архитектурные подходы к идентификации в мультитенантных решениях
Следующий шаг
Узнайте о выборе модели размещения вычислительных ресурсов, операционных аспектах и оптимизации параметров технологий, которые помогут вам соответствовать соглашениям и целям уровня обслуживания.