Поделиться через

Использование удостоверения как платформы службы

  • Статья

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

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

Рекомендации

Внимание

Используя IDaaS, например идентификатор Microsoft Entra, Azure AD B2C или другую аналогичную систему, можно устранить многие проблемы, описанные в этой статье. Мы рекомендуем этот подход везде, где это возможно.

Требования к решению могут привести к использованию платформы или решения для удостоверений вне полки, которое вы размещаете и запускаете самостоятельно. Хотя использование предварительно созданной платформы удостоверений устраняет некоторые из проблем, описанных в этой статье, обработка многих из этих проблем по-прежнему является вашей ответственностью за такое решение.

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

Избегайте хранения учетных данных

При запуске собственной системы удостоверений необходимо сохранить базу данных учетных данных.

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

Независимо от того, как вы защищаете отдельные учетные данные, сохраняя базу данных учетных данных, вы делаете целевой объект для атак. Последние годы показали, что как крупные, так и небольшие организации имели свои базы данных учетных данных, предназначенные для атаки.

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

Реализация протоколов идентификации и федерации

Современные протоколы идентификации являются сложными. Отраслевые эксперты разработали OAuth 2, OpenID Connect и другие протоколы, чтобы гарантировать, что они устраняют реальные атаки и уязвимости. Протоколы также развиваются, чтобы адаптироваться к изменениям в технологиях, стратегиях атак и ожиданиях пользователей. Специалисты по идентификации, имеющие опыт работы с протоколами и способами их использования, находятся в лучшем положении для реализации и проверки систем, следовать этим протоколам. Дополнительные сведения о протоколах и платформе см. в статье OAuth 2.0 и OpenID Connect (OIDC) в платформа удостоверений Майкрософт.

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

Внедрение современных функций удостоверений

Пользователи ожидают, что система удостоверений имеет ряд расширенных функций, в том числе:

  • Проверка подлинности без пароля, которая использует безопасные подходы для входа, для которых пользователям не требуется вводить учетные данные. Секретные ключи являются примером технологии проверки подлинности без пароля.

  • Единый вход (SSO), который позволяет пользователям входить с помощью удостоверения от своего работодателя, учебного заведения или другой организации.

  • Многофакторная проверка подлинности (MFA), которая предлагает пользователям выполнять проверку подлинности самостоятельно несколькими способами. Например, пользователь может войти с помощью пароля, а также с помощью приложения authenticator на мобильном устройстве или кода, отправленного по электронной почте.

  • Аудит, который отслеживает все события, происходящие на платформе удостоверений, включая успешные, неудачные и прерванные попытки входа. Для судебной экспертизы попытки входа позже требуются эти подробные журналы.

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

  • JIT-управление доступом, которое временно позволяет пользователям входить в систему на основе процесса утверждения, а затем автоматически удалять авторизацию.

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

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

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

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

Использование надежной высокопроизводительной системы удостоверений

Так как системы идентификации являются такой ключевой частью современных облачных приложений, они должны быть надежными. Если ваша система удостоверений недоступна, остальной часть решения может быть затронута и либо работает в деградируемом режиме, либо не работает вообще. Используя IDaaS с соглашением об уровне обслуживания, вы можете повысить уверенность в том, что ваша система удостоверений будет оставаться в рабочем состоянии, когда это необходимо. Например, Идентификатор Microsoft Entra предлагает соглашение об уровне обслуживания для уровней служб "Базовый" и "Премиум", которое охватывает как процессы выдачи маркеров, так и вход. Дополнительные сведения см. в соглашениях об уровне обслуживания (SLA) для веб-служб.

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

Проверка безопасности и применение жестких элементов управления

Если вы запускаете систему удостоверений, это ваша ответственность за обеспечение безопасности. Примеры элементов управления, которые необходимо реализовать, включают:

  • Периодическое тестирование на проникновение, требующее специализированного опыта.
  • Проверка сотрудников и других пользователей с доступом к системе.
  • Жесткий контроль над всеми изменениями в решении со всеми изменениями, рассмотренными экспертами.

Эти элементы управления часто являются дорогостоящими и трудными для реализации.

Использование средств управления безопасностью в облаке

При использовании идентификатора Microsoft Entra в качестве поставщика удостоверений решения вы можете воспользоваться преимуществами функций безопасности на основе облака, таких как управляемые удостоверения для ресурсов Azure.

Если вы решили использовать отдельную платформу удостоверений, необходимо рассмотреть, как приложение может воспользоваться преимуществами управляемых удостоверений и других функций Microsoft Entra, одновременно интегрируясь с собственной платформой удостоверений.

Сосредоточьтесь на главном значении

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

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.

Автор субъекта:

  • Джон Даунс | Главный инженер программного обеспечения

Другие участники:

Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.

Следующие шаги