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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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