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


Планирование развертывания прокси приложения Microsoft Entra

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

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

В этой статье содержатся ресурсы, необходимые для планирования, эксплуатации и управления прокси-сервером приложения Microsoft Entra.

Планирование реализации

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

Необходимые компоненты

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

  • Соединители. Это простые агенты, которые можно развернуть на:

    • физическом оборудовании в локальной среде;
    • виртуальной машине, размещенной в любом решении гипервизора;
    • Виртуальная машина, размещенная в Azure, для включения исходящего подключения к службе прокси приложения.
  • Дополнительные сведения см. в статье "Общие сведения о соединителях частной сети Microsoft Entra".

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

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

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

  • Параметры сетевого доступа: соединители частной сети Microsoft Entra подключаются к Azure через HTTPS (TCP-порт 443) и HTTP (TCP-порт 80).

    • Конечный трафик TLS соединителя не поддерживается и не позволит соединителям устанавливать безопасный канал с соответствующими конечными точками прокси приложения Microsoft Entra.

    • Избегайте всех форм встроенной проверки исходящих соединений TLS между соединителями и Azure. Внутренняя проверка соединений между соединителем и внутренними приложениями возможна, но это может привести к снижению удобства работы пользователей, поэтому не рекомендуется.

    • Балансировка нагрузки самих соединителей также не поддерживается или даже не требуется.

Важные рекомендации перед настройкой прокси приложения Microsoft Entra

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

  • Подключение Azure. Перед развертыванием прокси приложения удостоверения пользователей должны быть синхронизированы из локального каталога или созданы непосредственно в клиентах Microsoft Entra. Синхронизация удостоверений позволяет Microsoft Entra ID предварительно пройти проверку подлинности пользователей перед предоставлением им доступа к опубликованным приложениям прокси приложения и иметь необходимые сведения об идентификаторе пользователя для выполнения единого входа.

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

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

  • Открытый сертификат. При использовании пользовательских доменных имен необходимо приобрести сертификат TLS/SSL. В зависимости от требований организации получение сертификата может занять некоторое время, и мы рекомендуем начать этот процесс как можно раньше. Прокси приложения Azure поддерживает стандартные, дикие карта или SAN-сертификаты. Дополнительные сведения см. в статье "Настройка пользовательских доменов с помощью прокси приложения Microsoft Entra".

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

  • Записи DNS для URL-адресов

    • Прежде чем использовать личные домены в прокси приложения, необходимо создать запись CNAME в общедоступном DNS, позволяя клиентам разрешать настраиваемый внешний URL-адрес предварительно определенного прокси приложения. Если не создать запись CNAME для приложения, использующего личный домен, удаленные пользователи не смогут подключаться к приложению. Действия, необходимые для добавления записей CNAME, могут отличаться от поставщика DNS к поставщику, поэтому узнайте, как управлять записями DNS и наборами записей с помощью Центра администрирования Microsoft Entra.

    • Аналогичным образом узлы соединителей должны уметь преобразовывать внутренний URL-адрес публикуемых приложений.

  • Административные права и роли

    • Для установки соединителя требуются права локального администратора для сервера Windows, на котором он устанавливается. Кроме того, для проверки подлинности и регистрации экземпляра соединителя в клиенте Microsoft Entra требуется как минимум роль приложения Администратор istrator.

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

  • Лицензирование: прокси приложения доступен через подписку Microsoft Entra ID P1 или P2. Ознакомьтесь со страницей цен Microsoft Entra, чтобы получить полный список параметров лицензирования и функций.

Обнаружение приложений

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

Тип сведений Собираемые сведения
Тип службы Например, SharePoint, SAP, CRM, настраиваемое веб-приложение, API
Платформа приложений Например, Windows IIS, Apache в Linux, Tomcat, NGINX
Членство в домене Полное доменное имя (FQDN) веб-сервера
Расположение приложения Место расположения веб-сервера или фермы в вашей инфраструктуре
Внутренний доступ Точный URL-адрес, используемый при внутреннем доступе к приложению.
Какой тип балансировки нагрузки используется для фермы?
Получает ли приложение содержимое из других источников, кроме самого себя.
Определите, работает ли приложение через WebSockets.
Внешний доступ Решение поставщика, которое приложение уже может быть предоставлено через внешний интерфейс.
URL-адрес, который вы хотите использовать для внешнего доступа. При использовании SharePoint убедитесь, что были настроены сопоставления для альтернативного доступа в соответствии с этим руководством. В противном случае необходимо будет определить внешние URL-адреса.
Общедоступный сертификат При использовании личного домена приобретите сертификат с соответствующим именем субъекта. Если сертификат существует, запишите его серийный номер и расположение, откуда его можно получить.
Тип аутентификации Тип аутентификации, поддерживаемый приложением, например Базовая, Встроенная проверка подлинности Windows, на основе формы, на основе заголовка и утверждения.
Если приложение настроено для работы с определенной учетной записью домена, примите во внимание полное доменное имя (FQDN) учетной записи службы.
Если проверка основана на SAML, примите во внимание идентификатор и URL-адрес ответа.
Если проверка основана на заголовке, примите во внимание решение поставщика и конкретные требования для обработки типа аутентификации.
Имя группы соединителей Логическое имя для группы соединителей, которые будут назначены для предоставления канала и единого входа для этого серверного приложения.
Доступ пользователей и групп Пользователи или группы пользователей, которым будет предоставлен внешний доступ к приложению.
Дополнительные требования Обратите внимание на дополнительные требования к удаленному доступу или безопасности, которые следует учитывать при публикации приложения.

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

Определение требований организации

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

Открыть

  • Удаленные пользователи с присоединенными к домену устройствами или устройства, присоединенные к Microsoft Entra, могут безопасно получать доступ к опубликованным приложениям с простым единым входом (SSO).

  • Удаленные пользователи с одобренными личными устройствами могут безопасно получать доступ к опубликованным приложениям, если они были зарегистрированы в MFA и зарегистрировали приложение Microsoft Authenticator на своем мобильном телефоне в качестве способа аутентификации.

Система управления

  • Администратор istrator может определять и отслеживать жизненный цикл назначений пользователей приложениям, опубликованным через прокси приложения.

Безопасность

  • Доступ к этим приложениям могут получить только пользователи, назначенные приложениям вследствие членства в группе или отдельно.

Производительность

  • По сравнению с доступом к приложению из внутренней сети ухудшение производительности приложения не происходит.

Взаимодействие с пользователем

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

Аудит

  • Администраторы могут проводить аудит действий доступа пользователей.

Рекомендации по пилотным проектам

Определите количество времени и трудозатраты, необходимые, чтобы полностью подготовить к работе одно приложение для удаленного доступа с единым входом (SSO). Это можно сделать, запустив пилотный проект, который предусматривает его первичное обнаружение, публикацию и общее тестирование. Использование простого веб-приложения на базе IIS, предварительно настроенного для Встроенной проверки подлинности Windows (IWA), поможет установить базовые показатели, так как эта настройка требует минимальных трудозатрат для успешного развертывания удаленного доступа и единого входа.

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

Управление соединителем:

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

Управление приложениями:

  • Скорее всего, ваши рабочие ресурсы запомнят привычный и релевантный внешний URL-адрес. Избегайте публикации приложения с помощью предварительно определенных суффиксов msappproxy.net или onmicrosoft.com. Вместо этого предоставьте привычный проверенный домен верхнего уровня с префиксом логического имени узла, например intranet.<customers_domain>.com.

  • Ограничьте видимость значка пилотного приложения в пилотную группу, скрывая его значок запуска на портале Azure MyApps. Когда приложение будет готово для рабочей среды, можно ограничить его область соответствующей целевой аудиторией в том же подготовительном клиенте или путем публикации приложения в рабочем клиенте.

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

TLS между узлом соединителя и целевым приложением. Поскольку безопасность имеет первостепенное значение, необходимо всегда использовать TLS между узлом соединителя и целевыми приложениями. Это в частности необходимо, если веб-приложение настроено для аутентификации на основе форм (FBA), так как учетные данные пользователя фактически передаются в виде открытого текста.

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

  1. Протестируйте и проверьте общий доступ к веб-приложению с отключенной предварительной аутентификацией.
  2. В случае успешного тестирования и проверки включите предварительную аутентификацию и назначьте пользователей и группы. Протестируйте и проверьте доступ.
  3. Затем добавьте метод единого входа для своего приложения и протестируйте его еще раз, чтобы проверить доступ.
  4. При необходимости примените политики условного доступа и MFA. Протестируйте и проверьте доступ.

Средства устранения неполадок. При устранении неполадок всегда начинайте с проверки доступа к опубликованному приложению из браузера на узле соединителя и убедитесь, что приложение работает надлежащим образом. Чем проще настройки, тем легче определить основную причину неполадки, поэтому попробуйте воспроизвести проблемы, используя минимальную конфигурацию, например с одним соединителем и без единого входа. В некоторых случаях средства веб-отладки, такие как Telerik Fiddler, могут стать незаменимыми при устранении проблем с доступом или содержимым в приложениях, доступ к которым осуществляется через прокси-сервер. Fiddler также может действовать в качестве прокси-сервера, помогающего отслеживать и отлаживать трафик для мобильных платформ, таких как iOS и Android, и практически всего, что можно настроить для маршрутизации через прокси-сервер. Дополнительные сведения см. в руководстве по устранению неполадок.

Внедрение решения

Развертывание прокси приложения

Действия по развертыванию прокси приложения рассматриваются в этом руководстве по добавлению локального приложения для удаленного доступа. Если установка не выполнена, выберите "Устранение неполадок прокси приложения" на портале или используйте руководство по устранению неполадок при установке агента прокси приложения Подключение or.

Публикация приложений с помощью прокси приложения

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

Вы также можете публиковать приложения с помощью PowerShell.

Ниже приведены рекомендации, которых следует придерживаться при публикации приложения.

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

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

  • Используйте соответствующие типы файлов cookie

    • Файл cookie только для HTTP: обеспечивает дополнительную безопасность, если прокси-сервер приложения включает флаг HTTPOnly в заголовки http-ответа set-cookie. Этот параметр позволяет снизить риск использования уязвимостей для атак, таких как межсайтовые сценарии (XSS). Выберите "Нет" для клиентов или агентов пользователей, которым требуется доступ к файлам cookie сеанса. Например, клиент RDP/MTC, подключающийся к шлюзу удаленных рабочих столов, опубликованным через прокси приложения.

    • Защищенный файл cookie. Если файл cookie имеет атрибут Secure, агент пользователя (клиентское приложение) будет включать файл cookie в HTTP-запросы, только если запрос передается по защищенному каналу TLS. Это позволяет снизить риск компрометации файла cookie через открытые текстовые каналы, поэтому этот параметр должен быть включен.

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

  • Преобразовывайте URL-адреса в заголовках. Эта функция включается для сценариев, где внутренние DNS не могут быть настроены для соответствия общедоступному пространству имен организации (т. н. разделенный DNS). Если приложению не требуется исходный заголовок узла в запросе клиента, оставьте здесь значение "Да". В качестве альтернативы необходимо, чтобы соединитель использовал полное доменное имя во внутреннем URL-адресе для маршрутизации фактического трафика и полное доменное имя во внешнем URL-адресе в качестве заголовка узла. В большинстве случаев эта альтернатива должна позволять приложению работать как обычно при удаленном доступе, но ваши пользователи теряют преимущества от сопоставления внутри и вне URL-адреса.

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

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

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

Рисунок 1

При включении преобразования ссылок для приложения Benefits ссылки на Expenses и Travel перенаправляются на внешние URL-адреса этих приложений, чтобы пользователи, обращающиеся к приложениям извне корпоративной сети, могли получить к ним доступ. Ссылки из приложений Expenses и Travel обратно в Benefits не работают из-за того, что для этих двух приложений не было включено преобразование. Ссылка на Feedback не перенаправляется, так как отсутствует внешний URL-адрес, и поэтому пользователи, использующие приложение Benefits, не смогут получить доступ к приложению Feedback извне корпоративной сети. См. подробные сведения о преобразовании ссылок и других вариантах перенаправления.

Получение доступа к приложению.

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

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

Рисунок 24

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

Рисунок 25

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

Гостевые пользователи также могут быть приглашены на доступ к внутренним приложениям, опубликованным через прокси приложения через Microsoft Entra B2B.

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

Рисунок 26

Если этот параметр не задан, пользователи могут получать доступ к локальному приложению через прокси приложения Microsoft Entra без разрешений, поэтому используйте с осторожностью.

Чтобы получить доступ к опубликованному приложению, нужно ввести его внешний URL-адрес в браузере или воспользоваться значком в https://myapps.microsoft.com.

Включение предварительной аутентификации

Убедитесь, что приложение доступно через прокси приложения, обращающееся к нему через внешний URL-адрес.

  1. Перейдите к приложениям>Identity>Apps>Enterprise и выберите приложение, которое вы хотите управлять.

  2. Выберите прокси приложения.

  3. В поле предварительной проверки подлинности используйте раскрывающийся список, чтобы выбрать идентификатор Microsoft Entra и нажмите кнопку "Сохранить".

При включенной предварительной проверке подлинности идентификатор Microsoft Entra сначала вызовет пользователям проверку подлинности, а если настроен единый вход, серверное приложение также проверит пользователя перед предоставлением доступа к приложению. Изменение режима предварительной проверки подлинности с passthrough на идентификатор Microsoft Entra также настраивает внешний URL-адрес с помощью HTTPS, поэтому любое приложение, первоначально настроенное для HTTP, теперь будет защищены с помощью HTTPS.

Включение единого входа

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

Выбор параметра passthrough позволяет пользователям получать доступ к опубликованному приложению без необходимости проходить проверку подлинности в идентификаторе Microsoft Entra.

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

Чтение единого входа в приложения в приложениях в идентификаторе Microsoft Entra, чтобы помочь вам выбрать наиболее подходящий метод единого входа при настройке приложений.

Работа с приложениями других типов

Прокси приложения Microsoft Entra также может поддерживать приложения, разработанные для использования библиотеки проверки подлинности Майкрософт (MSAL). Он поддерживает собственные клиентские приложения, потребляя маркеры, выданные идентификатором Microsoft Entra, полученными в заголовках запроса клиента для выполнения предварительной проверки подлинности от имени пользователей.

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

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

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

Для поддержки прокси приложения Microsoft Entra можно использовать следующие возможности:

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

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

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

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

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

Управление реализацией

Обязательные роли

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

Бизнес-роль Бизнес-задачи Роли Microsoft Entra
Администратор службы поддержки Обычно ограничивается определением проблем, о которых сообщают конечные пользователи, и выполнением ограниченных задач, таких как изменение паролей пользователей, аннулирование маркеров обновления и мониторинг работоспособности служб. Администратор службы технической поддержки
Администратор удостоверений Чтение отчетов входа Microsoft Entra и журналов аудита для отладки проблем, связанных с прокси приложениями. Читатель сведений о безопасности
Владелец приложения Создание и контроль всех аспектов корпоративных приложений, регистраций приложений, а также параметров прокси приложения. Администратор приложения
Администратор инфраструктуры Владелец смены сертификатов Администратор приложения

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

Однако пользователям по-прежнему необходимо выполнять повседневные привилегированные операции, поэтому применение JIT-политик на основе управление привилегированными пользователями JIT-запросов для предоставления привилегированного доступа к ресурсам Azure и идентификатору Microsoft Entra — это наш рекомендуемый подход к эффективному управлению административным доступом и аудитом.

Создание отчетов и мониторинг

Идентификатор Microsoft Entra предоставляет дополнительные сведения об использовании приложений и работоспособности приложений организации с помощью журналов аудита и отчетов. Прокси приложения также упрощает мониторинг соединителей из Центра администрирования Microsoft Entra и журналов событий Windows.

Журналы аудита приложений

Эти журналы содержат подробные сведения о входах в приложения, настроенные с помощью прокси приложения и устройства и пользователя, обращаюющегося к приложению. Журналы аудита находятся в Центре администрирования Microsoft Entra и в API аудита для экспорта. Кроме того, отчеты об использовании и аналитике также доступны для вашего приложения.

Мониторинг соединителя частной сети

Соединители и служба отвечают за выполнение задач, связанных с высоким уровнем доступности. Вы можете отслеживать состояние соединителей на странице прокси приложения в Центре администрирования Microsoft Entra. Дополнительные сведения о обслуживании соединителей см. в статье "Общие сведения о соединителях частной сети Microsoft Entra".

Журналы событий Windows и счетчики производительности

Для соединителей настроены журнал администратора и журнал сеансов. В журналах администратора регистрируются основные события и соответствующие ошибки. В журналах сеансов содержатся все транзакции и подробные сведения об их обработке. Журналы и счетчики находятся в журналах событий Windows, чтобы получить дополнительные сведения о соединителях частной сети Microsoft Entra. Следуйте указаниям этого руководства по настройке источников данных журнала событий в Azure Monitor.

Руководство и действия по устранению неполадок

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

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