Технический обзор платформы

Для кого это

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

Основные компоненты (концептуально)

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

Модель представления рабочей среды

Назначенные ресурсы отображаются в тенант-портале как управляемые цели запуска, а не как «сырые» сетевые назначения. Администраторы связывают пользователей с конкретными предложениями — как правило это рабочие приложения, точки входа в удалённую рабочую среду, офисные ПК, размещённые рабочие столы, операционные среды или внутренние приложения. Когда пользователь начинает запуск, выполнение нагрузки остаётся связанным с одобренной целью, а взаимодействие идёт через браузерно-инкапсулированную поверхность сессии, если это настроенный путь. Если политика и интеграция требуют другой модели доставки, та же модель назначения может передаться одобренному клиентскому пути вместо полного отображения в браузере. Важная граница: конечное устройство — это поверхность доступа, а не сама среда выполнения. Такое разделение позволяет организациям показывать цели Windows, Linux, macOS, серверные, облачные или гибридные через один портал и модель назначений, не включая пользовательские устройства во внутреннюю границу доверия сети.

Высокоуровневый сценарий запуска

1. Пользователь входит в портал в масштабе тенанта (MFA—если политика требует).
2. Для сессии определяется контекст тенанта, чтобы последующие проверки применялись к нужной конфигурации и разделу данных.
3. Назначения и авторизация оцениваются на сервере до подготовки любого удалённого пути.
4. В интерфейсе портала показываются допустимые ресурсы—в том числе назначенные рабочие приложения и опыт удалённого рабочего пространства.
5. Пользователь инициирует действие запуска для выбранного назначения.
6. Слой безопасного доступа выстраивает авторизованный путь сессии в соответствии с назначением и правилами тенанта.
7. Целевая среда становится доступной через браузерную поверхность или настроенную передачу клиенту—в зависимости от типа запуска.
8. Доступ остаётся ограниченным одобренным ресурсом—без подразумеваемого широкого сетевого охвата с конечной точки.

Что где выполняется

Типы сред

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

• Офисные ПК
• Среды Windows для ПК
• Среды Windows Server
• Среды Linux
• Среды macOS
• Облачные рабочие пространства
• Внутренние приложения

Кратко о пути выполнения

Идентификация, сессии и авторизация

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

Изоляция тенантов

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

Транспорт и периметр

Трафик использует шифрованные транспорты до точек обслуживания. Браузерный уровень не предполагает устаревший VPN-клиент на конечной точке; связность к внутренним или гибридным целям посредничается компонентами для исходящих аутентифицированных сессий—а не для сплющивания всей сети. Наборы шифров и версии TLS соответствуют производственным базовым линиям безопасности и меняются в окнах обслуживания.

Данные (общий уровень)

Портал хранит метаданные тенанта, назначения, события для аудита администрирования и конфигурацию интеграций в соответствии с продуктом. Секреты сторонних коннекторов хранятся по контролируемым шаблонам—а не во фронтенд-бандлах. Полезная нагрузка удалённых сессий идёт по выделенным путям; материалы учётных данных целевых сред остаются в границе удалённой сессии и не дублируются в веб-журналах по замыслу.

Наблюдаемость и эксплуатация

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

Расширяемость

Интеграции предпочитают стабильные HTTP API и стандартные протоколы идентификации там, где клиенты ждут совместимости (например каталог или SSO на высоком уровне). Флаги возможностей и поэтапные включения позволяют принимать функции без ослабления изоляции.

Граница публичной страницы

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