Общедоступные и конфиденциальные клиентские приложения

Библиотека проверки подлинности Майкрософт (MSAL) определяет два типа клиентов; общедоступные клиенты и конфиденциальные клиенты. Клиент — это сущность программного обеспечения, которая имеет уникальный идентификатор, назначенный поставщиком удостоверений. Типы клиентов отличаются своей способностью безопасно проходить аутентификацию с сервером авторизации и хранить конфиденциальные данные, подтверждающие личность, чтобы они не могли быть доступны или известны пользователю в пределах его доступа.

Общедоступные клиентские приложения	Конфиденциальные клиентские приложения
Классическое приложение	Веб-приложение
API без браузера	Веб-API
Мобильное приложение	Служба/демон

Авторизация общедоступного клиента и конфиденциального клиента

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

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

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

Когда следует включить общедоступный поток клиента в регистрации приложения?

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

Секреты и их важность в доказательстве личности

Ниже приведены некоторые примеры того, как клиент может доказать свое удостоверение серверу авторизации:

• Управляемые удостоверения для ресурсов Azure – В сценариях аутентификации только для приложений разработчики приложений и служб в Azure могут переложить управление секретами, их ротацию и защиту на саму платформу. При использовании управляемых удостоверений удостоверения предоставляются и удаляются с ресурсами Azure, и никто, включая глобального администратора, не может получить доступ к базовым учетным данным. Используя управляемые удостоверения, можно предотвратить утечку секретов и доверить обработку безопасности поставщику.
• Идентификатор клиента и секрет . В этом шаблоне при регистрации клиента создается пара значений, создаваемых сервером авторизации. Идентификатор клиента — это общедоступное значение, определяющее приложение, а секрет клиента — конфиденциальное значение, используемое для подтверждения удостоверения приложения.
• Подтверждение владения сертификатом — инфраструктура открытых ключей (PKI), которая включает такие стандарты, как X.509, является основной технологией, которая обеспечивает безопасный обмен данными через Интернет и формирует основу конфиденциальности интернета. PKI используется для выдачи цифровых сертификатов, которые проверяют личность сторон, участвующих в онлайн-коммуникации, и является базовой технологией, которая обеспечивает такие протоколы, как HTTPS, которая широко используется для защиты веб-трафика. Аналогичным образом сертификаты можно использовать для защиты обмена данными между службами (S2S) в Azure, обеспечивая взаимную проверку подлинности между службами. Это включает в себя каждую службу, представляющая сертификат другому в качестве средства подтверждения его личности.
• Презентация подписанного утверждения. Используется в федерации удостоверений рабочей нагрузки, подписанные утверждения позволяют обмениваться маркером доверенного стороннего поставщика удостоверений с платформа удостоверений Майкрософт для получения маркеров доступа для вызова защищенных ресурсов Microsoft Entra. Федерацию удостоверений рабочей нагрузки можно использовать для включения различных сценариев федерации, включая Служба Azure Kubernetes, Amazon Web Services EKS, GitHub Actions и многое другое.

Когда имеется вопрос о подтверждении удостоверения клиента?

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

• Управление доступом к API— если у вас есть API, который измеряется (например, для выставления счетов), или предоставляет конфиденциальные данные или ресурсы, перед предоставлением доступа вы проверите удостоверение клиента. Например, это важно при обеспечении доступа к API только для авторизованных приложений и выставлении счетов правильному клиенту за использование API на основе учёта их потребления.
• Защита пользователей от подделки приложений. Если у вас есть развернутое приложение, ориентированное на пользователя (например, серверное веб-приложение), которое обращается к конфиденциальным данным или службам, использование клиентских секретов для защиты ресурсов, используемых этим приложением, может предотвратить от подделки злоумышленниками, которые могут пытаться проводить фишинг пользователей и извлекать данные или злоупотреблять доступом.
• Обмен данными S2S — если у вас есть несколько внутренних служб (таких как подчиненные API), которые должны взаимодействовать друг с другом, можно проверить удостоверение каждой службы, чтобы убедиться, что они авторизованы для доступа только к необходимым ресурсам для выполнения своей функции.

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

Конфиденциальные клиенты: рекомендации по управлению секретами

Используйте управляемые удостоверения для упрощения развертывания и безопасности . Управляемые удостоверения предоставляют автоматически управляемое удостоверение в идентификаторе Microsoft Entra для приложений, используемых при подключении к ресурсам, поддерживающим проверку подлинности Microsoft Entra. Приложения могут использовать управляемые удостоверения для получения маркеров приложения только для идентификатора Microsoft Entra без необходимости управлять учетными данными. Это может удалить множество сложностей, связанных с управлением секретами, а также повысить безопасность и устойчивость. Если вы используете управляемые удостоверения, то большинство из приведённых ниже лучших практик (если не все) уже реализованы для вас.

Используйте безопасное хранилище — храните секреты клиента в безопасном расположении, например Key Vault или зашифрованный файл конфигурации. Избегайте хранения секретов клиента в виде открытого текста или как проверенных файлов в системах управления версиями.

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

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

Использование длинных секретов и надёжного шифрования — тесно связано с предыдущей точкой, использование надёжных алгоритмов шифрования для данных как при передаче (по сети), так и при хранении (на диске) помогает обеспечить, что секреты с высокой энтропией вряд ли будут подобраны. Алгоритмы, такие как AES-128 (или более поздней версии), могут помочь защитить неактивных данных, а RSA-2048 (или более поздней версии) может помочь эффективно защитить данные во время передачи. Из-за постоянно развивающейся природы кибербезопасности всегда рекомендуется проконсультироваться с экспертами по безопасности и периодически просматривать выбор алгоритма.

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

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

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

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

Используйте актуальные библиотеки и пакеты SDK из доверенных источников. Платформа удостоверений Майкрософт предоставляет различные клиентские и серверные пакеты SDK и ПО промежуточного слоя, которые призваны повысить вашу продуктивность и обеспечить безопасность ваших приложений. Библиотеки, такие как Microsoft.Identity.Web, упрощают добавление проверки подлинности и авторизации в веб-приложения и API на платформе идентификации Microsoft. Обновление зависимостей помогает обеспечить преимущества приложений и служб от последних инноваций и обновлений системы безопасности.

Сравнение типов клиентов и их возможностей

Ниже приведены некоторые сходства и различия между общедоступными и конфиденциальными клиентскими приложениями:

• Оба типа приложений поддерживают кэш токенов пользователя и могут тихо получать токен (когда токен присутствует в кэше). Конфиденциальные клиентские приложения также имеют кэш токенов приложения для токенов, полученных самим приложением.
• Оба типа приложений могут управлять учетными записями пользователей и получать учетную запись из кэша маркеров пользователя, получать учетную запись из его идентификатора или удалять учетную запись.
• В MSAL общедоступные клиентские приложения имеют четыре способа получения токена с помощью отдельных аутентификационных потоков. Конфиденциальные клиентские приложения имеют только три способа получения токена и один способ для вычисления URL-адреса авторизационной конечной точки поставщика идентификационной информации. Идентификатор клиента передается один раз во время создания приложения и не требуется передавать повторно, когда приложение получает токен. Дополнительные сведения см. в о получении токенов.

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

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

См. также

Дополнительные сведения о настройке приложения и создании экземпляра см. в следующих статьях:

• Параметры настройки клиентского приложения
• Создание экземпляров клиентских приложений с помощью MSAL.NET
• Создание экземпляров клиентских приложений с помощью MSAL.js