Сокращение избыточных разрешений и приложений

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

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

Что такое избыточные привилегии?

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

Неиспользуемые разрешения

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

Ваши активы находятся за дверью. У вас есть три ключа (синий, желтый и зеленый), которые позволяют открыть соответствующую дверь. Например, синий ключ может открыть синюю дверь. Если вам нужен доступ только к желтой двери, вы несете только желтый ключ.

Чтобы лучше защитить ресурсы, вы несете только ключи, необходимые при необходимости, и храните неиспользуемые ключи в безопасном расположении.

Редуцируемые права доступа

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

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

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

Разрыв разрешений и риск

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

Ось X представляет время , а ось Y представляет разрешения. В начале измеряемого времени вы запрашиваете и получаете разрешение для приложения. По мере роста и изменения бизнеса с течением времени вы добавляете новые разрешения для поддержки ваших потребностей, в результате чего наклон предоставленных разрешений увеличивается. Используемые разрешения могут быть ниже предоставленных разрешений, если вы забыли удалить ненужные разрешения (например, если приложение не прерывает), что приведет к разрыву разрешений.

Ниже приведены интересные наблюдения на платформе удостоверений Майкрософт.

• У нас более 4000 API в Microsoft Graph.
• Более 200 разрешений Microsoft Graph доступны на платформе удостоверений Майкрософт.
• Разработчики имеют доступ к широкому спектру данных и могут применять степень детализации к разрешениям, которые запрашивают их приложения.
• В наших исследованиях мы обнаружили, что приложения полностью используют только 10% разрешений для своих сценариев.

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

Скомпрометирована безопасность из-за чрезмерных полномочий

Давайте более подробно рассмотрим риски, которые приводят к пробелам разрешений с примером. Этот сценарий компрометации состоит из двух ролей: ИТ-администратора и разработчика.

• ИТ-администратор: Джефф является администратором клиента, который гарантирует, что приложения в идентификаторе Microsoft Entra являются надежными и безопасными. Часть работы Джеффа — предоставить согласие на разрешения, необходимые разработчикам приложений.
• Разработчик: Келли — это разработчик приложений, который использует платформу удостоверений Майкрософт и владеет приложениями. Задание Келли заключается в том, чтобы приложения имели правильные разрешения на выполнение необходимых задач.

Нижеприведенный распространенный сценарий компрометации безопасности из-за чрезмерных привилегий обычно состоит из четырех этапов.

1. Разработчик начинает настраивать приложение и добавлять необходимые разрешения.
2. ИТ-администратор проверяет необходимые разрешения и предоставляет согласие.
3. Неправильный субъект начинает взломать учетные данные пользователя и успешно взломает удостоверение пользователя.
4. Если пользователь владеет несколькими приложениями, они также перепривилегированы. Недопустимый субъект может быстро использовать маркер предоставленного разрешения для получения конфиденциальных данных.

Чрезмерное использование приложений

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

Давайте используем Microsoft Graph в рамках Microsoft Identity Platform в реальном примере, чтобы лучше понять неиспользуемые и сокращаемые разрешения.

Неиспользуемое разрешение возникает, когда приложение получает разрешения, которые не нужны для нужных задач. Например, вы создаете приложение календаря. Приложение календаря запрашивает Files.ReadWrite.All и получает разрешение. Ваше приложение не интегрируется с API-интерфейсами файлов. Поэтому приложение имеет неиспользуемое Files.ReadWrite.All разрешение.

Разрешения, поддающиеся редукции, обнаружить сложнее. Это происходит, когда приложение получает несколько разрешений, но имеет более низкую привилегированную альтернативу, которая обеспечит достаточный доступ для необходимых задач. В примере приложения календаря приложение запрашивает Files.ReadWrite.All и получает разрешение. Однако ему нужно только считывать файлы из OneDrive вошедшего пользователя и никогда не создавать новые файлы или изменять существующие. В этом случае ваше приложение использует Files.ReadWrite.All только частично, поэтому необходимо понизить версию до Files.Read.All.

Рекомендации по сокращению сценариев с избыточными привилегиями

Безопасность — это путешествие, а не назначение. Существует три отдельных этапа жизненного цикла безопасности:

• Предотвращение
• Auditing
• Remediation

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

• Предотвращение: при создании приложения полностью разобраться в необходимых разрешениях для вызовов API, которые ваше приложение должно выполнять. Запрашивайте только то, что необходимо для реализации вашего сценария. Документация по Microsoft Graph содержит четкие упоминания о разрешениях от минимальных привилегий до максимальных привилегий для всех конечных точек. Учитывайте сценарии с избыточными привилегиями, определяя необходимые разрешения.
• Аудит: Вы и ИТ-администраторы должны регулярно просматривать ранее предоставленные привилегии существующих приложений.
• Исправление. Если вы или ИТ-администраторы заметите чрезмерно привилегированное приложение в экосистеме, прекратите запрашивать токены для избыточного разрешения. ИТ-администраторы должны отозвать предоставленные согласия. Обычно для этого шага требуется изменение кода.

Рекомендации по поддержанию разрешений с минимальными привилегиями

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

• Повышайте уровень принятия, создавая надёжное приложение для клиентов, которое избегает чрезмерных запросов разрешений. Ограничьте разрешения приложения только тем, что он должен выполнить свою задачу. Эта практика снижает потенциальный радиус атак и повышает привлечение клиентов к использованию ваших приложений. Прилагайте больше усилий при проверке разрешений, которые запрашивают приложения, и принятии решения о том, предоставлять ли им эти разрешения.
• Остановите распространение, гарантируя, что плохие субъекты не могут использовать чрезмерные привилегии для получения дальнейшего доступа. При создании приложения, которое запрашивает ненужные разрешения, оно с наименьшей вероятностью будет одобрено или вообще получит отказ. Лучший способ контролировать ущерб заключается в том, чтобы предотвратить злоумышленников от получения повышенных привилегий, которые увеличивают масштаб ущерба. Например, если у вашего приложения есть User.ReadBasic.All только для чтения основных сведений пользователя, то ваши OneDrive, Outlook, Teams и любые конфиденциальные данные остаются в безопасности, если приложение скомпрометировано.

Дальнейшие действия

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