Поделиться через

Службы и рекомендации Azure для размещения рабочих столов

В следующих разделах описаны службы инфраструктуры Azure.

Портал Azure

После того как поставщик создаст подписки Azure, с портала Azure можно будет вручную создать среду для каждого клиента. Этот процесс можно автоматизировать с помощью скриптов PowerShell.

Дополнительные сведения см. в статье на веб-сайте Microsoft Azure.

Azure Load Balancer

Компоненты клиента запускаются на виртуальных машинах, которые взаимодействуют друг с другом в изолированной сети. Во время развертывания эти виртуальные машины доступны извне через подсистему балансировки нагрузки Azure с помощью конечных точек протокола удаленного рабочего стола или конечной точки удаленного PowerShell. После завершения развертывания эти конечные точки обычно удаляются, чтобы уменьшить контактную зону для атак. Остаются только конечные точки HTTPS и UDP, созданные для виртуальной машины, где работают веб-доступ к удаленным рабочим столам и шлюз удаленных рабочих столов. Это позволяет клиентам в Интернете подключаться к сеансам, работающим в службе размещения рабочих столов клиента. Если пользователь откроет приложение, которое подключается к Интернету, такое как веб-браузер, соединения будут переданы через подсистему балансировки нагрузки Azure.

Дополнительные сведения см. в статье Что такое подсистема балансировки нагрузки Azure.

Вопросы безопасности

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

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

Дополнительные сведения см. в следующих статьях:

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

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

  • Подписка Azure имеет ограничение на максимальное количество виртуальных сетей, ядер виртуальных машин и облачных служб, которые можно в ней использовать. Если поставщику нужно еще больше ресурсов, может потребоваться создать несколько подписок.
  • В облачной службе Azure есть ограничение на максимальное количество виртуальных машин, которые могут использоваться. Поставщику может потребоваться создать несколько облачных служб для больших клиентов, у которых превышен максимум.
  • Затраты на развертывание Azure частично основаны на количестве и размере виртуальных машин. Поставщику следует оптимизировать число и размер виртуальных машин для каждого клиента для создания работоспособного и экономичного решения размещения рабочих столов.
  • Ресурсы физического компьютера в центре обработки данных Azure виртуализируются с помощью Hyper-V. Узлы Hyper-V не настроены в кластерах узлов, поэтому доступность виртуальных машин зависит от доступности отдельных серверов, используемых в инфраструктуре Azure. Чтобы обеспечить более высокий уровень доступности, можно создать в группе доступности несколько экземпляров каждой роли службы виртуальной машины; при этом кластеризацию гостевых систем можно реализовать в виртуальных машинах.
  • В типовой конфигурации хранилища поставщик услуг будет иметь одну учетную запись с несколькими контейнерами (например, по одному для каждого клиента) и несколько дисков в каждом контейнере. Однако существует ограничение на общий объем хранилища и производительности для одной учетной записи. Для поставщиков услуг, которые поддерживают большое количество клиентов или клиенты с особыми требованиями к емкости и производительности, может потребоваться создать несколько учетных записей хранения.

Дополнительные сведения см. в следующих статьях:

Прокси приложения Microsoft Entra

Прокси приложения Microsoft Entra — это служба, предоставляемая в платных номерах SKU идентификатора Microsoft Entra, которая позволяет пользователям подключаться к внутренним приложениям через собственную службу обратного прокси-сервера Azure. Это позволяет скрыть конечные точки веб-доступа к удаленным рабочим столам и шлюза удаленных рабочих столов внутри виртуальной сети, что устраняет необходимость делать их доступными в Интернете через общедоступный IP-адрес. Хост-серверы могут использовать прокси приложения Microsoft Entra, чтобы сжать количество виртуальных машин в среде клиента, сохраняя полное развертывание. Прокси приложения Microsoft Entra также обеспечивает множество преимуществ, предоставляемых идентификатором Microsoft Entra, например условным доступом и многофакторной проверкой подлинности.

Дополнительные сведения см. в разделе Начало работы с прокси приложения и установка соединителя.