Производительность и безопасность приложений, доставляемых в современное рабочее пространство

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

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

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

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

Технологии доставки приложений, такие как балансировка нагрузки (Load Balancing), разгрузка SSL, WAN, SaaS и веб-оптимизация формируют основу для производительности. Эти технологии должны работать вместе, чтобы позволить службе ИТ доставлять потрясающие возможности пользователям вне зависимости от их расположения в локальном, облачном или гибридном окружении. Интеграция этих распределенных технологий – это то, что делает сетевые решения Citrix особенными, обеспечивая потрясающие возможности и видимость для ИТ этих возможностей.

Рассмотрим для примера компанию, которая начала перенос своего портфолио приложений и рабочих нагрузок в сервисы SaaS, а также в решения с облачным размещением. Чтобы получить лучшую производительность и сократить затраты, она примеряет решение Citrix SD-WAN, которое предоставляет оптимизированную производительность на более чем 4000 приложений SaaS, а также новых решениях компании с облачным размещением и ее локальным центром обработки данных (ЦОД).

Компания оптимизирует производительность не только при помощи качества обслуживания (QoS) на уровне пакетов, но также сокращает затраты, используя менее скоростное подключение к сети интернет для обеспечения производительности.

Компания может извлечь выгоду на другой части интегрированного решения Citrix, развернув Citrix ADC для балансировки рабочих нагрузок. Это подойдет как для традиционного подхода к приложениям, так и для новых облачных (Cloud-native) подходов, использующих Kubernetes и контейнеры. Развертывание Citrix ADC в объединении с Citrix Intelligent Traffic Management позволяет выбрать точки лучшей производительности серверов или сервисов для доставки приложений и обеспечения высококачественных возможностей. Данным сервисом вполне может быть Citrix Workspace в дополнение к прочим веб к традиционным приложениям.

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

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

Расширенная безопасность при помощи Palo Alto и ZScaler добавляет интеграцию к, возможно, уже имеющейся инфраструктуре. Citrix ADC предоставляет безопасность для доставляемых приложений начиная с фундаментального межсетевого экрана веб-приложений (Web App Firewall, WAF). Но присутствуют и новые векторы безопасности, которые оказывают влияние на центр приложений среди ботов и растущее доверие к API. Разрушение сервисов через ботов – это возрастающая проблема информационной безопасности. Управление ботами (Bot Management) Citrix защищает приложения, не оказывая влияния на производительность.

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

Видимость производительности и безопасности.

Все точки интеграции в рамках портфолио Citrix передают отчёты в центральное решение управления и аналитики, предоставляя видимость одновременно для производительности и безопасности. При помощи Citrix Application and Delivery Management (ADM) можно обеспечить производительность и безопасность пользователей и клиентов, а также соответствие бизнес требованиям. Citrix ADM – это центральная система, которая является единой точкой для всех задач управления и требований к отображению, предоставляющая подробности обнаруженных ошибок и возможности их устранения.

По ссылке можно больше узнать о сетевых решениях Citrix и их возможностях обеспечения производительности и безопасности в соответствии с требованиями цифровой трансформации (Digital Transformation).

Командлеты для работы c переменными в Windows PowerShell 5

Пришло время продолжить изучение переменных в Windows PowerShell.

В веб-касте описываются и демонстрируются командлеты для работы с переменными: New-Variable, Set-Variable, Get-Variable, Clear-Variable и Remove-Variable. Основной упор в веб-касте сделан на преимущества использования командлетов. В частности, рассматриваются способы автоматизации управления переменными, просмотр свойств и методов объекта PSVariable и использование ссылочного типа (Reference Type).

Подробности и видео: LebedevUM.

P.S. Это третий веб-каст в группе, поэтому если вы не знакомы с переменными в Windows PowerShell, начните свое знакомство с предыдущих веб-кастов группы:

• Переменные в Windows PowerShell 5.
• Синтаксис имен переменных в Windows PowerShell 5.

Все веб-касты в хронологическом порядке: Windows PowerShell 5.

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

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum) 19 Янв 2020 в 1:28 PST

Возможности на базе Hyper-V

Hyper-V – это технология аппаратной виртуализации Microsoft, впервые вышедшая в 2008-ом году для обеспечения серверной виртуализации и ставшая основой множества продуктов и компонентов Microsoft. Диапазон возможностей простирается от повышения безопасности до расширения возможностей разработчиков и обеспечения наиболее совместимой игровой консоли. Последние добавления в этот список включают песочницу Windows (Windows Sandbox), Windows Defender Application Guard, System Guard и расширенное обнаружение угроз (Advanced Thread Detection), изолированные контейнеры Hyper-V (Hyper-V Isolated Containers), платформу гипервизора Windows (WHP), подсистему Windows для Linux 2 (WSL 2). Дополнительно, приложения, использующие Hyper -V: Kubernetes для Windows и Docker Desktop.

Так как область виртуализации Windows расширяется, становясь интегрированной частью операционной системы, многие новые возможности операционной системы зависят от Hyper-V. Соответственно, это создает ошибки совместимости со множеством популярным сторонних продуктов, которые предоставляют собственные решения виртуализации, заставляя пользователей выбирать между приложениями и потерей функциональности операционной системы. В связи с этим Microsoft объединился с ключевыми производителями программного обеспечения, такими как VMware, VirtualBox и BlueStacks для предоставления решений, которые напрямую используют технологии виртуализации Microsoft, устраняя необходимость выбора.

Песочница Windows (Windows Sandbox).

Песочница Windows (Windows Sandbox) – это изолированное, временное окружение рабочего стола, в котором можно запускать программное обеспечение без страха оказать негативное влияние на персональный компьютер. Любое программное обеспечение, установленное в песочнице Windows, остается только в песочнице и не может повлиять на хост. После закрытия песочницы Windows все состояние, включая файлы, изменения реестра и установленное программное обеспечение мгновенно удаляются. Песочница Windows построена на тех же технологиях, которые разрабатывались для работы мульти-арендных сервисов Azure, таких как Azure Functions, а также предоставляет интеграцию с Windows 10 и поддержку для графических приложений.

Windows Defender Application Guard.

Windows Defender Application Guard (WDAG) – это возможность безопасности Windows 10, представленная в Fall Creators Update (версии 1709), которые защищают от нацеленных угроз при помощи технологий виртуализации Hyper-V. Также WDAG обеспечивает корпоративным пользователям Microsoft Edge и Internet Explorer (IE) защиту от уязвимостей ядра (Zero-day) за счет изоляции не доверенных сессий браузера от операционной системы хоста. Это позволяет команде информационной безопасности при помощи WDAG заблокировать корпоративные хосты, при этом, разрешив корпоративным пользователям просматривать в браузере некорпоративный контент.

Application Guard изолирует не доверенные сайты при помощи нового экземпляра Windows на аппаратном уровне.

Windows Defender System Guard.

Для защиты критических ресурсов, таких как стек аутентификации Windows, ключи единого входа (Single Sign-On), биометрический стек Windows Hello и Virtual Trusted Platform Module (Virtual TPM), а также системной прошивки (Firmware) и оборудование – они должны быть доверенными. Windows Defender System Guard реорганизует существующие возможности целостности системы Windows 10 и поверх них настраивает набор вложений в безопасность Windows. Это спроектировано и разработано для обеспечения следующих гарантий безопасности:

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

Windows Defender Advanced Threat Detection.

Обнаружение и остановка атак, которые вмешиваются через агентов в режиме ядра на уровне гипервизора – это критический компонент универсальной платформы защиты конечных устройств в Microsoft Defender Advanced Thread Protection (ATP). Глубокая интеграция Windows Defender Antivirus с аппаратными возможностями изоляции позволяют обнаруживать признаки подобных атак.

Изолированные Hyper-V контейнеры (Hyper-V Isolated Containers).

Hyper -V играет важную роль в возможностях контейнерной разработки на Windows 10. Контейнеры Windows требуют плотной связи между версией операционной системы контейнера и хоста, на котором они запущены. Hyper-V используется для инкапсуляции контейнеров на Windows 10 внутрь прозрачной, легковесной виртуальной машины. В разговорной речи данную возможность называют «Hyper-V Isolated Containers». Эти контейнеры запускаются в виртуальной машине, которая специально оптимизирована для быстродействия и эффективности использования ресурсов хоста. Изолированные Hyper-V контейнеры позволяют разработчикам вести разработку на множестве дистрибутивов Linux и Windows одновременно, а также управлять контейнерами при помощи привычных инструментов (таких как Docker).

Платформа гипервизора Windows (Windows Hypervisor Platform).

Платформа гипервизора Windows (WHP) добавляет расширенный интерфейс разработки приложений (API) пользовательского режима для сторонних стеков виртуализации и приложений, что позволяет создавать и управлять разделами на уровне гипервизора, настраивать привязку памяти для раздела, а также создавать и управлять работой виртуальных процессоров. Основное назначение – это сосуществование стороннего программного обеспечения (такого как VMware) с Hyper-V и прочими возможностями на базе Hyper-V. Безопасность на базе виртуализации (Virtualization-Based Security, VBS) – это одна из последних технологий, которая возможна благодаря этому сосуществованию.

WHP предоставляет API, похожий на платформу (Framework), которую предоставляет KVM на Linux и гипервизор macOS, и на данный момент опирается на QEMU и VMware.

Подсистема Windows для Linux 2 (Windows Subsystem for Linux 2).

Подсистема Windows для Linux 2 (WSL 2) – это новейшая версия архитектуры, которая позволяет подсистеме Windows для Linux запускать исполняемые файлы ELF64 на Windows. Это обновление возможностей включает в себя увеличенную производительность файловой системы, а также полную совместимость системных вызовов. Новые архитектурные изменения влияют на то, как исполняемые файлы взаимодействуют с Windows и аппаратным обеспечением компьютера, но предоставляют те же пользовательские возможности, что и WSL 1 (на данный момент широко распространенная версия). Основное отличие архитектуры WSL 2 заключается в настоящем ядре Linux, запущенном внутри виртуальной машины. Независимые дистрибутивы Linux могут быть запущены как в WSL 1, так и в WSL 2, могут быть обновлены (Upgrade) или понижены (Downgrade) в любое время, а также запущены в WSL 1 и WSL 2 одновременно.

Поддержка Kubernetes для Windows.

Kubernetes начал официально поддерживать Windows Server в производственной среде, начиная с релиза Kubernetes версии 1.14 (в марте 2019 года). Приложения на базе Windows составляют большую часть рабочих нагрузок во множестве организаций. Контейнеры Windows предоставляют современный путь для приложений Windows чтобы использовать процессы DevOps и изначально облачные подходы. По факту Kubernetes стал стандартом для управления контейнерами; данная поддержка позволяет широкой экосистеме приложений Windows не только использовать возможности Kubernetes, но и широкую, бесшовную и постоянно растущую экосистемы вокруг него. Организации, вкладывающие одновременно в приложения на базе Windows и Linux, больше не нуждаются в отдельных оркестраторах для управления рабочими нагрузками, что в результате приводит к увеличению операционной эффективности развертываний. Разработка, обеспечившая данный релиз опиралась на открытый исходный код и лучшие подходы сообщества, которые и добавили контейнеры Windows Server в Windows Server 2016.

Данные компоненты и инструменты позволяют технологии Microsoft Hyper-V представлять новые пути обеспечения пользовательских возможностей. Песочница Windows (Windows Sandbox), Windows Defender Application Guard, System Guard и Advanced Thread Detection, изолированные Hyper-V контейнеры (Hyper-V Isolated-Containers), Windows Hypervisor Platform (WHP) и подсистема Windows для Linux (WSL 2) – это все новые компоненты Hyper-V, которые обеспечивают гибкость и безопасность Windows. Управление приложениями с использованием Hyper-V, такое как Kubernetes для Windows и Docker Desktop также показывает приверженность Microsoft к потребностям клиентов.

P.S. Тем, кто не знаком с возможностями Hyper-V, я рекомендую начать свое знакомство со статьи «Архитектура Hyper-V» и группы веб-кастов посвященной Hyper-V в Windows 10:

• Установка и управление Hyper-V в Windows 10
• Создание виртуальных машин Hyper-V в Windows 10
• Импорт и экспорт виртуальных машин Hyper-V в Windows 10
• Базовое управление Hyper-V через Windows PowerShell в Windows 10
• Продвинутое управление Hyper-V через Windows PowerShell в Windows 10
• Вложенная виртуализация Hyper-V в Windows 10

Управление модулями Apache в CentOS 8

Не откладывая в долгий ящик продолжаем наше знакомство с Apache HTTP Server в CentOS 8.

Данный веб-каст описывает модули (Modules) веб-сервера Apache, рассказывает о конфигурационных файлах, применении модулей и расположениях по умолчанию. Центральное место в веб-касте занимают демонстрации установки и применения модуля mod_php для обеспечения возможности использования языка PHP веб-сайтом и модуля mod_wsgi, который обеспечивает связь между веб-сервером и приложением, написанным на языке Python. Дополнительно в веб-касте затрагивается вопрос компиляции модулей из исходных кодов при помощи Apache Extension (apxs).

Подробности и видео: LebedevUM.

P.S. Это уже второй веб-каст в группе, поэтому если вы не знакомы с Apache HTTP Server, начните свое знакомство с веб-каста «Установка и настройка Apache в CentOS 8».

Следующий веб-каст будет посвящен виртуальному хостингу на базе веб-сервера Apache.

View this post on Instagram

A post shared by Yuriy Lebedev (@lebedevum) on Feb 3, 2020 at 11:29pm PST

Citrix App Layering и контейнеры профилей Microsoft FSLogix

Rob Zylowski (Citrix Consulting Enterprise Architect), будучи экспертом Citrix App Layering, подeлился своим видением относительно оптимизации Windows и приложений Windows в решениях Citrix Virtual Apps and Desktops. Я же, в свою очередь, адаптирую его видение выработки правильных решений на стыке технологий Microsoft и Citrix.

Ключом к построению наилучшего решения, является хорошее понимание всех доступных инструментов, что позволяет подбирать наилучший вариант в каждой конкретной ситуации. Так же важно понимать, что Microsoft FSLogix часто используется совместно с Citrix App Layering, так как эти инструменты решают разные задачи. Далее будут рассмотрены различия между App Layering и FSLogix, чтобы разобрать ситуации, когда один инструмент предпочтительнее другого, а в каких случаях их необходимо использовать совместно.

Различия FSLogix и App Layering.

Многие полагают, что Microsoft FSLogix и Citrix App Layering полностью идентичные технологии. Из-за того, что в App Layering есть уровень или технология на базе контейнера, которая позволяет пользователям хранить изменения машин VDI без сохранения состояния (Non-persistent VDI) при помощи доступного для записи файла VHD, сохраненного на общем сетевом ресурсе. А FSLogix предоставляет похожую технологию, с собственным решением на базе контейнера для хранения профиля пользователя Windows или файлов, связанных с Office (подобно тем, которые используют Outlook и OneDrive), также при помощи файлов VHD/VHDX в общем сетевом расположении.

Однако, пользовательские уровни (User Layer) App Layering на самом деле предназначены для предоставления практически полного сохранения состояния для платформы VDI без сохранения состояния (Non-persistent). Пользовательский уровень (User Layer) может быть использован для параметров приложений, сохраненных в профиле пользователя, а также для установленных пользователем приложений и сохраненных пользователем файлов где-либо на системе. FSLogix имеет две технологии на базе контейнеров – одна из которых охватывает весь профиль пользователя (Profile Container) и вторая, содержащая часть профиля пользователя имеющую отношение к Microsoft Office и поддерживающим его технологиям, таким как OneDrive (Office Container). Таким образом области применения продуктов существенно отличаются: FSLogix нацелен на профиль или часть профиля пользователя, а пользовательские уровни (User Layer) App Layering охватывают все операции записи на рабочей станции.

Это архитектурное отличие обозначает, что FSLogix и пользовательские уровни (User Layer) соответствуют двум различным наборам клиентских потребностей. Если необходимо решить проблемы, связанные с профилем или запуском Office в окружении VDI без сохранения состояния (Non-persistent) или в окружении служб удаленного рабочего стола (RDS) в таком случае лучше всего подойдут FSLogix или управление профилем Citrix (Citrix Profile Management, начиная с версии 7.18), которые имеют подобные возможности. Если необходимо предоставить пользователю возможности сохранения состояния (Persistent) поверх окружения VDI без сохранения состояния (Non-persistence), что может включать Outlook, OneDrive, индексирование поиска (Search Indexing) и так далее, то в таком случае пользовательские уровни (User Layer) App Layering могут стать правильным решением.

Разумеется, возможности App Layering гораздо шире, чем просто предоставление пользовательского уровня (User Layer). App Layering предоставляет платформу для управления комплексными наборами приложений и образов в окружениях с разными гипервизорами и облаках, в том числе управление облаками и динамическую доставку приложений.

В результате FSLogix прекрасно подходит для управления профилями пользователей и Outlook, а Citrix App Layering – для управления образами и приложениями.

Интеграция Citrix App Layering и Microsoft FSLogix.

На самом деле установка и использование FSLogix довольно проста. Установка состоит из загрузки и развертывания маленького установщика драйверов фильтрации, которые использует FSLogix. Затем используется набор объектов групповой политики (Group Policy), которые разворачиваются за счет вложенного файла ADMX. Для совместного использования с Citrix App Layering, FSLogix может быть установлен в уровень платформы (Platform Layer) или приложения (Application Layer). Если необходимо использовать образы настольной системы (Desktop Image), как с FSLogix, так и без, то рекомендуется использовать уровень приложений (Application Layer).

После запуска машины упаковки (Packaging Machine) уровня приложений (Application Layer), первый шаг установки – это скопировать FSLogixAppSetup.exe и запустить его от имени администратора (Run As Administrator). Следующий шаг очень важен: драйвер фильтрации (Filter Driver) использует концепцию высоты (Altitude), которая определяет порядок, в котором драйвер фильтрации одного типа будет предоставлять доступ к вызовам файловой системы от операционной системы. Производители драйверов фильтрации файловой системы запрашивают назначение высоты у Microsoft, которая управляет этим и назначает высоты. По умолчанию, высоты Citrix App Layering и Microsoft FSLogix не позволяют продуктам корректно работать совместно. Чтобы использовать FSLogix с Citrix App Layering, высота драйвера FSLogix (frxdrvvt) должна быть изменена при помощи следующей правки в реестре:

Отредактировать ключ HKLM\System\CurrentControlSet\Services\frxdrvvt\Instances\frxdrvvt\Altitude установив значение 138010.

Micah Adamson рекомендует использовать это значение высоты (138010) в его посте в msdn. После внесения изменения в реестр, необходимо перезагрузить машину упаковки (Packaging Machine), затем финализировать уровень.

FSLogix создает 4 локальные группы, которые используются для управления тем, какие пользователи FSLogix будут применяться в процессе установки:

• FSLogix Profile Include List.
• FSLogix Profile Exclude List.
• FSLogix ODFC Include List.
• FSLogix ODFC Exclude List.

Если используется Citrix App Layering, то единственный уровень, на котором можно добавить локальные группы – это уровень операционной системы (OS Layer). Это связано с тем, что база данных SAM зашифрована в Windows, и нет возможности собрать ее из разных уровней. Это значит, что даже добавленные при установке FSLogix группы в машину упаковки (Packaging Machine) при создании уровня приложений (Application Layer) останутся только в машине упаковки. Лучший способ решить данную задачу – это создать эти группы и настроить их членство при помощи предпочтений групповой политики (Group Policy Preferences) в доменных службах Active Directory (AD DS). Аналогичный способ используется для обработки членства в группах во время установки VDA в уровень платформы.

В соответствующем объекте групповой политики (GPO) добавьте предпочтение групповой политики в Конфигурация компьютера (Computer Configuration) → Предпочтения (Preferences) → Параметры панели управления (Control Panel Settings) → Локальные пользователи и группы (Local Users and Groups) и добавить группу с именем «FSLogix Profile Include List». Затем добавить в список ее членов необходимую доменную группу.

В группу исключения (FSLogix Profile Include List) необходимо добавить административные учетные записи и локального администратора. Это гарантирует, что при входе под административной учётной записью FSLogix не будет создавать контейнер для профиля, что в последствии может вызвать проблемы при управлении образом.

После публикации образа, который включает уровень FSLogx и развертывания файлов ADMX с корректной конфигурацией, VDA автоматически подключается к контейнеру профиля FSLogix, что позволяет настроить Outlook OST.

Чтобы увидеть список перенаправленного можно воспользоваться командной FSLogix: frx.exe list-redirects.

Последний вопрос – как много времени данные технологии добавляют к процессу входа в систему. Rob Zylowski провел эксперимент с одним и тем же образом опубликованным в трех конфигурациях:

• Совсем без управления профилями.
• С FSLogix и без пользовательских (User Layer) и эластичных уровней (Elastic Layer).
• С пользовательским уровнем (User Layer), без эластичных уровней (Elastic Layer) и без FSLogix.

Пять входов с расчетом среднего времени входа от нажатия иконки в интерфейсе StoreFront до отрисовки иконки файлового менеджера в панели задач показали незначительное преимущество FSLogix над пользовательским уровнем (User Layer). С небольшим отставанием от них показал себя полный вход в систему Windows без управления профилем.

Заключительные рекомендации.

1. Используйте FSLogix для решения проблем, связанных с перемещающимся профилем на VDI без сохранения состояния (Non-persistent).
2. Используйте пользовательские уровни (User Layers), если необходимо предоставить возможности сохраненного состояния (Persistent Experience) пользователю на VDI без сохранения состояния (Non-persistent).
3. При совместном использовании FSLogix и App Layering, необходимо устанавливать FSLogix в уровень приложений (Application Layer).
4. При совместном использовании FSLogix и App Layering, необходимо изменить высоту (Altitude) у драйвера фильтрации FSLogix.
5. При совместном использовании FSLogix и App Layering, необходимо использовать предпочтения групповой политики (GPP) для создания локальных групп FSLogix.

Хотелось бы выразить благодарность Rob Zylowski за предоставленный передовой опыт (Best Practices), надеюсь, он окажется полезным для вас. Возможно, в последствии, мы вернемся к теме совместного использования App Layering и FSLogix в части интеграции маскировки приложений (App Masking).

P.S. Если вы не знакомы с Microsoft FSLogix, то начать свое знакомство можно с моей статьи «Решения Microsoft FSLogix», также я уже ранее писал об интеграции FSLogix и App Layering: «Применение возможностей платформы FSLogix в виртуальном окружении Citrix».