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

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

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

Общая ответственность за безопасность

До появления Виртуального рабочего стола Azure для локальных решений виртуализации, таких как службы удаленных рабочих столов, требовалось предоставить пользователям доступ к таким ролям, как "Шлюз", "Брокер", "Веб-доступ" и т. д. Эти роли должны были быть полностью резервируемыми и иметь возможность обрабатывать пиковую нагрузку. Администраторы установят эти роли как часть операционной системы Windows Server, и они должны быть присоединены к домену с определенными портами, доступными для общедоступных подключений. Чтобы обеспечить безопасность развертываний, администраторы должны постоянно убедиться, что все в инфраструктуре поддерживается и обновлено.

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

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

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

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

Рекомендуемые границы безопасности для сценариев Виртуального рабочего стола Azure

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

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

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

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

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

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

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

В таблице приведены рекомендации по каждому сценарию.