Рекомендации по авторизации

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

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

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

Рекомендации по разрешениям

Наиболее широко принятые приложения в Microsoft Entra ID следуют рекомендациям по согласию и авторизации. Ознакомьтесь с рекомендациями по работе с разрешениями Microsoft Graph и Microsoft Graph, чтобы узнать, как думать о запросах разрешений.

• Применение минимальных привилегий. Запрашивать только необходимые разрешения. Используйте добавочное согласие, чтобы запрашивать детализированные разрешения только вовремя. Ограничьте доступ пользователей с помощью технологий JIT/JEA, а также адаптивных политик на основе рисков и средств защиты данных.

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

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

Когда запрашивать разрешение

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

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

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

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

Станьте проверенным издателем

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

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

Хотя доступ к данным в API- интерфейсах, таких как Microsoft Graph, позволяет создавать расширенные приложения, ваша организация или клиент оценивают разрешения, запрашиваемые приложением, а также надежность вашего приложения.

Создание проверенного издателя Майкрософт помогает вам упростить прием запросов приложений клиентами. Когда приложение поступает от проверенного издателя, пользователей, ИТ-специалистов и клиентов, знают, что это происходит от кого-то, с кем корпорация Майкрософт имеет деловые отношения. Синяя проверка марк отображается рядом с именем издателя (компонент #5 в примере запроса на согласие разрешений ниже; см. таблицу компонентов в интерфейсе согласия приложения Microsoft Entra). Пользователь может выбрать проверенного издателя в запросе согласия, чтобы просмотреть дополнительные сведения.

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

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

• Разработка стратегии делегированных разрешений помогает реализовать оптимальный подход к управлению разрешениями в приложении и разработке с помощью принципов нулевого доверия.
• Разработка стратегии разрешений приложений помогает решить вопрос о подходе приложений к управлению учетными данными.
• Используйте рекомендации по разработке удостоверений и управления доступом в жизненном цикле разработки приложений для создания безопасных приложений.
• Рекомендации по безопасности для свойств приложения описывают URI перенаправления, маркеры доступа, сертификаты и секреты, URI идентификатора приложения и владение приложением.
• Настройка маркеров описывает сведения, которые можно получить в токенах Microsoft Entra. В нем объясняется, как настроить маркеры для повышения гибкости и контроля при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Настройка утверждений групп и ролей приложений в маркерах показывает, как настроить приложения с определениями ролей приложения и назначить группы безопасности ролям приложений. Эти методы помогают повысить гибкость и контроль при увеличении безопасности нулевого доверия приложений с минимальными привилегиями.
• Защита API описывает рекомендации по защите API путем регистрации, определения разрешений и согласия и принудительного доступа к достижению целей нулевого доверия.
• Получение авторизации для доступа к ресурсам помогает понять, как лучше всего обеспечить нулевое доверие при получении разрешений доступа к ресурсам для приложения.