Бөлісу құралы:

Повышение безопасности приложений с помощью принципов "Никому не доверяй"

  • Мақала

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

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

Модель "Никому не доверяй" предписывает использование явной проверки вместо неявного доверия. В основе модели лежат три руководящих принципа:

  • Прямая проверка
  • Использование доступа с минимальными привилегиями
  • Предполагайте наличие бреши в системе безопасности

Лучшие методики модели "Никому не доверяй""

Следуйте этим рекомендациям по созданию приложений в рамках стратегии "Никому не доверяй" с использованием платформы удостоверений Майкрософт и ее инструментов.

Прямая проверка

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

Рекомендация Преимущества защищенности приложений
Используйте библиотеки проверки подлинности Майкрософт (MSAL). MSAL — это набор библиотек аутентификации Майкрософт для разработчиков. С помощью MSAL пользователи и приложения могут выполнять аутентификацию, а также получать маркеры для доступа к корпоративным ресурсам путем написания всего нескольких строк кода. MSAL использует современные протоколы (OpenID Connect и OAuth 2.0), которые устраняют необходимость в непосредственном управлении учетными данными пользователя со стороны приложений. Это значительно повышает уровень безопасности как для пользователей, так и для приложений, так как поставщик удостоверений становится периметром безопасности. Кроме того, эти протоколы постоянно совершенствуются с целью поддержки новых парадигм, использования возможностей и решения проблем в области безопасности идентификации.
При необходимости применяйте расширенные модули безопасности, например непрерывную оценку доступа и контекст проверки подлинности условного доступа. В идентификаторе Microsoft Entra некоторые из наиболее используемых расширений включают условный доступ, контекст проверки подлинности условного доступа и ЦС. Приложения, использующие расширенные функции безопасности, такие как непрерывная оценка доступа и контекст проверки подлинности условного доступа, должны быть готовы обрабатывать требования утверждений. Открытые протоколы позволяют использовать требования и запросы утверждений для вызова дополнительных возможностей клиента. Эти возможности могут быть продолжены взаимодействие с идентификатором Microsoft Entra ID, например при возникновении аномалии или изменении условий проверки подлинности пользователей. Эти расширения можно закодировать в приложении, не нарушая основные потоки кода для аутентификации.
Используйте правильный поток аутентификации в соответствии с типом приложения. Для веб-приложений всегда следует использовать потоки конфиденциальных клиентов. Для аутентификации в мобильных приложениях попробуйте использовать брокеры или системный браузер. Потоки для веб-приложений, в которых могут храниться секретные данные (конфиденциальные клиенты), считаются более безопасными, чем открытые клиенты (например, классические и консольные приложения). Если системный веб-браузер используется для проверки подлинности мобильного приложения, интерфейс безопасного единого входа позволяет использовать политики защиты приложений.

Использование доступа с минимальными привилегиями

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

  • Оценивайте запрашиваемые разрешения, чтобы при выполнении задачи был задан абсолютно минимальный необходимый набор разрешений. Не создавайте разрешения типа "полный охват" с доступом ко всей поверхности API.
  • При проектировании API предоставьте детальные разрешения, чтобы разрешить доступ с минимальными привилегиями. Начните с разделения доступа к функциям и данным на разделы, которыми можно управлять с помощью областей и ролей приложения. Не добавляйте API к существующим разрешениям таким образом, чтобы при этом менялась семантика разрешения.
  • Предложите разрешения только для чтения. Доступ для операций Write включает разрешения на выполнение операций создания, обновления и удаления. Клиент никогда не должен требовать доступ для записи, если он выполняет только чтение данных.
  • Предложите как делегированные разрешения, так и разрешения приложения. При пропуске разрешений приложений могут возникнуть жесткие требования для клиентов в таких распространенных сценариях, как автоматизация, микрослужбы и т. д.
  • При работе с конфиденциальными данными учитывайте права доступа типа "стандартный" и "полный". Ограничьте конфиденциальные свойства так, чтобы к ним нельзя было получить доступ с помощью разрешения на "стандартный" доступ, например Resource.Read. А затем реализуйте разрешение на "полный" доступ, например Resource.ReadFull, которое возвращает все доступные свойства, включая конфиденциальные сведения.

Предполагайте наличие бреши в системе безопасности

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

Рекомендуется следующее, чтобы предотвратить нарушения безопасности:

  • Правильно определите URI перенаправления для приложения. Не используйте одну регистрацию приложения для нескольких приложений.
  • Проверяйте универсальные коды ресурса (URI) перенаправления, используемые при регистрации приложения для владения и во избежание перехвата доменов. Не создавайте приложение как мультитенант, если оно не предназначено. |
  • Убедитесь, что владельцы приложений и субъектов-служб всегда определены и обслуживаются для приложений, зарегистрированных в арендаторе.

См. также