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

Библиотека проверки подлинности Майкрософт (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 в платформа удостоверений Майкрософт. Обновление зависимостей помогает обеспечить преимущества приложений и служб от последних инноваций и обновлений системы безопасности.

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

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

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

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

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

См. также

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

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