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

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

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

Что перепривилегировано?

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

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

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

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

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

Сокращаемые разрешения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приложения с избыточными привилегиями

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

Давайте используем Microsoft Graph как часть платформа удостоверений Майкрософт в реальном примере, чтобы лучше понять неиспользуемые разрешения и повторное разрешение.

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

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

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

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

• Предотвращение
• Аудит
• Серверы

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

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

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

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

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

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

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