Шифры безопасности и их реализация в Citrix ADC

Многие специалисты по информационным технологиям отлично ориентируются в основах шифрования SSL/TLS, а также в окружающих терминах, таких как «Heartbleed» и «POODLE». Но теория и реальный мир в ряде аспектов – это две абсолютно разные вещи, и опросы клиентов Citrix ADC показали, что многие используют конфигурацию из коробки для своих критических приложений. В том числе это касается и выбора наборов шифров SSL для коммуникаций клиентов с ADC (Client-to-ADC) и ADC с серверами (ADC-to-Server).

Корректный выбор и применение наборов шифров крайне важен не только для безопасности бизнес-приложений, но и для обеспечения доступности пользовательских возможностей. Далее мы рассмотрим, как корректно выбирать наборы шифров для окружений и управлять ими при помощи Citrix ADC, обеспечивая безопасность и доступность окружений.

Структура набора шифров (Cipher Suite).

Рассмотрим набор шифров SSL на примере набора от TLS 1.2.

Наиболее важными частями в наборе шифров (Cipher Suite) являются обмен ключами (Key Exchange) и массовое шифрование (Bulk Encryption). Которые определяют способ начального обмена ключами шифрования SSL и последующее шифрование данных во время сессии. Секция сигнатуры (Signature) менее интересна в разрезе нашего рассмотрения, но она оказывает непосредственное влияние на производительность.

Обмен ключами (Key Exchange):

• RSA – один из старейших методов обмена ключами, он обычно используется для обеспечения совместимости со старыми клиентами, его использование постепенно сокращается.
• DHE – обмен Диффи-Хеллмана (Diffie-Hellman) позволяет двум участникам независимо друг от друга сгенерировать общий секрет без риска компрометации.
• ECDHE – Версия с эллиптической кривой для DHE обладает свойствами DHE, но при этом использует меньше вычислительных ресурсов.

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

Массовое шифрование (Bulk Encryption):

• RC4 – это устаревший шифр, который использовался из-за его простоты и скорости, но из-за серьезных уязвимостей лучше отказаться от его использования.
• DES – это ещё один устаревший шифр, обладающий ключом с короткой длиной, который также не следует использовать.
• 3DES – запущенный три раза DES для достижения дополнительной безопасности. Постепенно от него отказываются и единственный сценарий, когда его использование оправдано – это обеспечение совместимости.
• AES – наиболее популярный шифр данных, используемый в SSL.
• ChaCha20 – современный, безопасный, быстрый шифр, который набирает популярность.

К счастью, стандарты TLS 1.3 немного проще за счёт того, что они поддерживают только эфемерный обмен ключами Диффи-Хеллмана (Diffie-Hellman), нужно только перечислить шифр массового шифрования данных и алгоритм аутентификации сообщений. Пример шифра TLS 1.3: TLS_AES_256_GCM_SHA384.

Теперь, когда мы прошлись по основам, рассмотрим, как определяются наборы шифров для соединений SSL. 

Процесс квитирования SSL.

В процессе начального квитирования SSL, клиент отправляет список шифров на сервер, в порядке предпочтения. Это сообщение называется clientHello, его можно легко увидеть в трассировке Wireshark, если открыть первый пакет, отправленный от клиента к серверу.

Пример, секции наборов шифров (Cipher Suites):

На снимке экрана, клиент предпочитает наборы шифров TLS 1.3, затем запрашивает шифры ECDHE от TLS 1.2, если соединение TLS 1.3 невозможно установить.

Наиболее важная вещь, которую нужно отметить – сервер SSL/TLS отвечает за выбор набора шифров. Это значит, что клиенты подключающиеся к Citrix ADC, находятся под властью машины, соответственно, очень важно корректно настроить наборы шифров для ADC. В противном случае опубликованные приложения подвержены риску компрометации.

Citrix ADC и группы/наборы шифров.

Как же все вышесказанное применяется по отношению к Citrix ADC? 

В первую очередь необходимо запомнить тот факт, что Citrix ADC одновременно выступает как клиентом, так и сервером для разных потоков подключений. В терминологии ADC – это типы подключений SSL: BackEnd и FrontEnd.

Предпочтительный путь настройки целостных параметров ADC – это использовать профили SSL (SSL Profiles).

Можно добавить профили SSL для подключений FrontEnd и BackEnd, которые будут использовать виртуальные серверы (vServer) и SNIP для предоставления соединений и подключения к клиентам/сервисам.

Так же в профиле SSL в разделе продвинутых параметров (Advanced Settings) можно добавить группы шифров SSL.

Здесь необходимо установить наиболее безопасную группу шифров для использования по умолчанию во всех вновь создаваемых виртуальных серверах (vServer) на Citrix ADC. Важно отметить, что наборы шифров, перечисленные выше по списку, имеют большее предпочтение. Это значит, что если клиент поддерживает первый набор шифров в списке, то Citrix ADC его и выберет.

Рассмотри группу шифров по умолчанию (DEFAULT) в Citrix ADC.

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

Рекомендации.

Золотое правило настройки: «Всегда размещайте более безопасные наборы шифров (Cipher Suite) в начале списка предпочтений (Preference List)».

Это значит, что всегда необходимо размещать наборы шифров, TLS 1.3 или TLS 1.2 с использованием обмена ключами ECDHE в начале списка предпочтений. Звучит достаточно просто, но есть ряд нюансов и исключений, которые необходимо учесть. Тем не менее, безопасность должна оставаться в приоритете.

Рекомендации по наборам шифров:

• Если это возможно, придерживайтесь золотого правила.
• Создавайте настраиваемую группу шифров по умолчанию для обоих типов подключений (FrontEnd и BackEnd). Не следует использовать группу шифров Citrix ADC по умолчанию без тщательной проверки.
• Создайте дополнительные настраиваемые группы шифров для каждого сервиса, требующего более или менее строгой безопасности.
• Если вы не уверены в том, что считать безопасным, а что нет, можете обратиться к новейшему списку предпочтений Windows Server 2022, чтобы увидеть, что Microsoft считает безопасным.

Предостережения по наборам шифров:

• Не используйте наборы шифров SSL3, TLS1 и TLS1.1 (если это возможно).
• Не размещайте небезопасные наборы шифров в начале групп шифров по умолчанию для исключительных сценариев. Вместо этого, используйте настраиваемые группы шифров для реализации требований и применяйте их только по необходимости.
• При размещении небезопасных наборов шифров убедитесь, что они находятся внизу списка.
• Не используйте уязвимые шифры для массового шифрования (Bulk Encryption), такие как RC4, DES или 3DES, если это возможно.

Совместимость и производительность.

Есть только две причины, по которым отходят от золотого правила (Всегда размещайте более безопасные наборы шифров в начале списка предпочтений): совместимость и производительность.

Совместимость (Compatibility).

Существуют ситуации, в большинстве своем связанные с подключениями клиентов (FrontEnd), когда Citrix ADC должен обслуживать клиентов со старыми операционными системами или приложениями, которые требуют устаревших версий TLS и/или наборов шифров. В таких ситуациях необходимо разобраться в бизнес-обоснованиях и совместно с командой обеспечения безопасности определить риски и дальнейшие шаги. Это очень важно, чтобы лица, принимающие решения, понимали риски, связанные с использованием небезопасных наборов шифров. Не следует принимать такое решение самостоятельно, не согласовав его со всеми заинтересованными сторонами.

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

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

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

Размеры ключей могут играть важную роль в производительности. Ключи шифрования большего размера – более безопасны, но во многих случаях стараются использовать достаточную, а не максимально возможную безопасность, с целью обеспечения необходимого уровня производительности. Например, ключ RSA с длиной 2048, считается безопасным, но при этом он меньше, чем ключи с длиной 3072 и 4096. Ключи большего размера предоставляют более высокий уровень безопасности, который, как правило, не требуется на сегодняшний день (или в ближайшем будущем). При этом увеличенная длина ключа будет создавать дополнительную нагрузку на вычислительные ресурсы при установке соединения SSL.

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

Несмотря на то, что это все правда, переход к обмену ключами DHE или ECDHE может существенно сократить общее количество запросов в секунду, которое система, такая как Citrix ADC сможет поддерживать. Это в двойне правда для старого оборудования, которое не имеет аппаратной поддержки для расчета эллиптических кривых, такого как аппаратные платформы (MPX) Citrix ADC 5900/8600/26000 с их чипсетами Intel Coleto Creek.

В таком случае, к вопросу выбора предпочтительных наборов шифров нужно подойти максимально серьезно (особенно для соединений FrontEnd), или можно оказаться в ситуации, когда пострадают возможности пользователей из-за перегруженности вычислительных ресурсов ADC.

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

Заключение.

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

P.S. Если тема траффика HTTPS вам интересна, я могу порекомендовать несколько моих статей по этой тематике: «HTTP3, TLS 1.3 и Citrix ADC» и «Использование Citrix ADC для развертывания сетевого моста QUIC».

Практический аспект настройки SSL/TLS для веб-серверов можно посмотреть в веб-кастах «Настройка SSL/TLS для Apache в CentOS 8» и «TLS-шифрование NGINX в CentOS 8».

Использование Citrix ADC для развертывания сетевого моста QUIC

Citrix ADC теперь поддерживает режим развертывания сетевого моста QUIC (прокси) для трафика HTTP/3, обеспечивая балансировку нагрузки, расширенную безопасность и более высокую производительность для трафика QUIC. Развертывание прокси предполагает, что Citrix ADC разрывает трафик клиента до сервера и повторно устанавливает новое соединение к серверу для получения запрашиваемой информации.

Citrix ADC обеспечивает постоянные соединения QUIC между клиентом и сервером, что полезно в случае миграции соединений или повторной привязки NAT. Новый зашифрованный транспортный протокол интернета QUIC ускоряет трафик протокола передачи гипертекста (HTTP) за счёт встроенной безопасности и, как ожидается, заменит TCP и TLS в сети. HTTP/3 – это новейшая версия HTTP, она определяет потоки данных между браузерами и веб-сайтами. Ранее я уже писал про преимущества протокола QUIC.

Отличия HTTP/3.

Многие годы протокол HTTP эволюционировал и во многом стал похож на связку протоколов TCP, TLS и HTTP/2, реализованных на базе транспортного протокола UDP. Однако с точки зрения установки соединения и передачи данных – это более эффективно. На диаграмме ниже показано сравнение стеков протокола HTTP/2 и HTTP/3. Типичное квитирование QUIC требует одного цикла обработки между сервером и клиентом по сравнению с двумя циклами для квитирования TCP и TLS. Другими словами, QUIC обрабатывает аутентификацию и шифрование за один шаг.

Отличительные особенности HTTP/3:

• Быстрое квитирование (Faster Handshake): HTTP/3 использует QUIC, объединенный с TLS 1.3, что ускоряет квитирование.
• Улучшенная производительность (Improved Performance): HTTP/3 не подвержен ошибками блокировки заголовка TCP, что является одной из самых больших проблем HTTP/2.
• Встроенная безопасность (Built-in Security): TLS 1.3 новее и более безопасен, чем TLS 1.2 в HTTP/2.
• Устойчивая миграция сети (Reliable Network Migration): HTTP/2 требует пересмотра сессии для браузеров, а с QUIC передача проще.

Сетевой мост QUIC и Citrix ADC.

Сетевой мост QUIC (QUIC Bridge) – это один из возможных сценариев применения HTTP/3 в Citrix ADC. В данном случае Citrix ADC выступает в качестве прокси и маршрутизирует, а также балансирует нагрузку пакетов данных QUIC от клиентов к фоновым серверам.

Рассмотрим пример, в котором клиент с включенной поддержкой HTTP/3 в браузере собирается посетить веб-сайт со своего ноутбука. Клиент вводит URL и имя хоста преобразуется в IP-адрес. В развертывании прокси квитирование происходит между клиентом и Citrix ADC, а другое соединение между Citrix ADC и сервером. Citrix ADC располагается между участниками и управляет трафиком. На диаграмме ниже показан Citrix ADC в режиме прокси.

Режим передачи сетевой мост QUIC (QUIC Bridge) в Citrix ADC:

1. Клиент подключается к URL через сеть Wi-Fi.
2. Сервер DNS разрешает имя хоста в IP-адрес.
3. Устанавливается соединение UDP.
4. Контроллер доставки приложений (ADC) маршрутизирует пакеты QUIC до сервера назначения на базе типа пакета.
5. Выполняется балансировка нагрузки (Load Balancing).
6. Клиент перемещается в мобильную сеть из сети Wi-Fi.
7. Устанавливается соединение UDP.
8. Контроллер доставки приложений (ADC) маршрутизирует пакеты QUIC до сервера назначения на базе типа пакета.
9. Удержание сессии (Session Persistency) гарантирует подключение к тому же серверу после миграции соединения.

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

Начать использовать HTTP/3.

Прокси QUIC в Citrix ADC можно использовать и для защиты приложений от уязвимостей. Большинство браузеров на сегодняшний день поддерживают HTTP/3 и Citrix ADC может помочь с балансировкой нагрузки трафика QUIC, вне зависимости от используемых браузеров и приложений.

Поддержка сетевого моста QUIC доступна в Citrix ADC с версии 13.0.76.x. Дополнительную информацию можно получить при помощи следующих ссылок: QUIC, Citrix Application Delivery Controller (ADC) и Citrix Application Delivery Management (ADM).

Протокол gRPC доступен для развертываний Citrix ADC

В Citrix ADC протокол gRPC – это легковесная, высокопроизводительная платформа удаленного вызова процедур (RPC) с открытым исходным кодом. Платформа gRPC оптимальна для работы с разными языками, запущенными на любых операционных системах. Она обеспечивает лучшую безопасность и производительность по сравнению с другими протоколами.

За счёт использования gRPC поверх протокола HTTP/2 можно:

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

Почему gRPC в Citrix ADC.

Протокол gRPC в Citrix ADC применяется поверх HTTP/2 для поддержки высоко производительных и масштабируемых интерфейсов разработки приложений (API). За счет использования двоичных значений вместо текста, достигается увеличенная эффективность полезной нагрузки с точки зрения потребления памяти и хранения значений в числовых форматах.

В Citrix ADC запросы HTTP/2 мультиплексируются в одном подключении TCP, обеспечивая несколько конкурентных сообщений без ущерба для использования сетевых ресурсов. Также используется сжатие заголовков с целью сокращения размера запросов и ответов.

Принцип работы gRPC.

Конечная конфигурация gRPC работает как отправка запроса gRPC от клиента по протоколу HTTP/2 и отправка ответа обратно от сервера gRPC. На следующей диаграмме показана работа конфигурации gRPC на устройстве Citrix ADC.

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

1. Для развертывания конфигурации gRPC, необходимо сначала включить HTTP/2 в профиле HTTP и включить глобальную поддержку HTTP/2 на стороне сервера.
2. Когда клиент отправит запрос gRPC, виртуальный сервер балансировки нагрузки проверит трафик gRPC при помощи политик.
3. На базе проверки политик, виртуальный сервер балансировки нагрузки (с привязанными к нему сервисами gRPC) завершит обработку запроса и перешлет его фоновому серверу gRPC.
4. Аналогичным образом, когда сервер gRPC отвечает клиенту, Citrix ADC завершает обработку ответа и перенаправляет его клиенту gRPC.

Заключение.

Использование gRPC в развертывании Citrix ADC имеет преимущества над традиционными интерфейсами разработки приложений (API), так как работа происходит поверх протокола HTTP/2. Она поддерживает быстрые и эффективные коммуникации для развертываний микросервисов в облаках. Так как все большее число сервисов Citrix перемещается в облако, возможность обрабатывать вызовы gRPC при помощи Citrix ADC обеспечит требуемые производительность и безопасность вместе с простотой управления.

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

Citrix ADC CPX: потребляемая память и микро-сервисы

Citrix ADC доставляет операционную целостность при помощи единой базы кода на различных форм-факторах: аппаратных устройствах (MPX), виртуальных (VPX), голом железе (BLX) и контейнерах (CPX). Это значит, что все устройства Citrix ADC могут предоставлять одинаковый набор возможностей.

В развивающемся мире связанных сервисов Citrix ADC CPX разворачивается к каждой единице приложения (поду) для обеспечения поддержки. Этот ADC в контейнере должен быть адаптирован для такого масштаба развертывания за счёт оптимизации размера и производительности. Рассмотрим, что сделал Citrix за последнее время для обеспечения возможности хорошей работы ADC в контейнерных окружениях.

Сетка сервисов (Service Mesh) и прокси (Proxy).

В мире микро-сервисов на долю трафика “восток-запад” (East-West) в облачных приложениях приходится большая часть. Так же он имеет аналогичные требования к маршрутизации, наблюдению и безопасности, как и трафик север-юр (North-South) в традиционных ADC. За счёт размещения прокси ближе к микро-сервису сетка сервисов гарантирует, что трафик восток-запад (East-West) может автоматически контролироваться без явных действий со стороны разработчиков микро-сервисов.

При внутреннем развертывании (Sidecar Deployment), один прокси, обычно, разворачивается для каждого пода, чтобы получить сетку сервисов. Каждый прокси требует памяти, потребляет ресурсы процессора, создаёт дополнительную нагрузку в плоскости управления и обеспечивает дополнительную задержку. Так как кластер Kubernetes масштабируется до тысяч подов, накладные расходы увеличиваются. Очень важно для прокси потреблять крохотный объем памяти, при этом предоставляя богатый набор возможностей и поддерживая низкую задержку в рамках требуемых условий.

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

Объем потребляемой памяти Citrix ADC CPX.

Использование памяти одного экземпляра CPX включает всю память, к которой процесс может обратиться, в том числе память подкачки, память которая выделена, но не используется, и память от общих библиотек. Обычно это называется размер виртуального набора (Virtual Set Size, VSS).

Чем больше экземпляров CPX порождается, тем больше памяти используется всеми экземплярами. Чтобы получить актуальное потребление памяти экземпляром CPX в Citrix провели эксперимент: развернули очень большое число экземпляров CPX на одном узле, поддерживая стабильность системы. При отключённой подкачке (Swapping), память, выделяемая на экземпляры, рассчитывалась по формуле: общее использование памяти узлом разделенное на общее число экземпляров прокси.

Так как Citrix ADC имеет единую базу кода на для всех форм факторов, сокращение потребления памяти Citrix ADC CPX – это отдельная инженерная задача. Перезагрузки Citrix ADC (MPX/VPX) обычно происходят раз в несколько месяцев. Они обслуживают множество гигабит ежесекундно и поддерживают высокую пропускную способность. Эти устройства также нуждаются в широком разнообразии управляющих интерфейсов – REST API, SNMP, SSH и прочих. Для удовлетворения этих потребностей выделяется некоторый объем памяти и используется множество управляющих демонов.

Но при развертывании под управлением API прокси разворачивается не на долго и редко превышает пропускную способность в несколько Mbps. Следовательно, оптимизация выполняется с учётом этих требований:

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

Создание экземпляра CPX в режиме оптимизированной памяти (Memory Optimized Mode).

Развертывание лёгкого режима CPX (Light Mode) не отличается от обычного CPX. Указание дополнительного параметра окружения NS_CPX_LITE=1 позволит развернуть более лёгкую версию CPX.

docker run ‒ dt -P –privileged=true -e NS_CPX_LITE=1 ОБРАЗ:ТЕГ

Подробнее познакомиться с созданием экземпляров ADC CPX можно в документации по продукту.

Развертывание Citrix ADC CPX.

Режим оптимизированной памяти Citrix ADC CPX, подходит в следующих сценариях:

• Развертывание на входе (Ingress Deployment): Citrix ADC CPX может быть настроен в качестве балансировщика нагрузки сервисов Kubernetes. Он будет использоваться для балансировки траффика “Север-Юг” (North-South) для сервисов Kubernetes, отправляемого клиентами из-за пределов кластера Kubernetes.
• Внутреннее развертывание (Sidecar Deployment): Каждый под содержит Citrix ADC CPX, в качестве стороннего устройства, которое может принимать весь входящий и исходящий трафик для приложения, запущенного в поде. CPX может изолировать основное приложение от всех вспомогательных задач, выступая в качестве внутреннего устройства.

Citrix ADC CPX спроектирован таким образом, чтобы быть многогранным прокси. Клиенты могут использовать одинаковый набор возможностей в центре обработки данных (ЦОД), сетке сервисов и в облаке, полагаясь на единую основу кода, сформированную двумя десятилетиями применения в самых инновационных компаниях мира.

Дополнительную информацию о Citrix ADC CPX можно получить на странице Citrix в Github.

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

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

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

Решение – это единая прикладная сетевая платформа, от центра обработки данных до периметра 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).

Анонс Citrix Virtual Apps and Desktops 1912 (LTSR)

Под самый занавес 2019-го года, как и планировалось, Citrix провел итоговую черту и выпустил релиз с длительной поддержкой (LTSR) Citrix Virtual Apps and Desktops 1912. Релиз содержит новые возможности и компоненты, накопленные текущими релизами (CR) более чем за два года.

Релизы с длительной поддержкой (LTSR).

Релиз с длительной поддержкой (LTSR) выходит раз в несколько лет. Данный трек релизов Citrix Virtual Apps and Desktops нацелен на производственные окружения, которые предпочитают оставаться на одной версии продолжительное время. Программа релизов с длительной поддержкой (LTSR) предлагает 10 лет поддержки, таким образом, администраторы имеют большой запас времени для планирования, тестирования и развертывания своих окружений. Подробней об этом можно прочитать в статьях «Подготовка к следующему релизу с длительной поддержкой (LTSR) Citrix Virtual Apps and Desktops 1912» и «Citrix Virtual Apps and Desktops (CVAD): Текущий релиз (CR) или релиз с длительной поддержкой (LTSR)».

Разумеется, для клиентов, которые используют текущий релиз (CR) Citrix Virtual Apps and Desktops - 1912 остается важным обновлением, в первую очередь он является прямым продолжением текущего релиза (CR) 1909 и содержит ряд собственных улучшений.

Новое.

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

В свою очередь, я представлю 10 причин обновиться до релиза 1912, которые обозначил Nick Rintalan (архитектор Citrix):

1. Тонкое выделение блочного хранилища (Thin Provisioning of Block Storage) – современные релизы Citrix Hypervisor официально поддерживают тонкое выделение блочного хранилища, такого как FC и iSCSI благодаря GFS2.
2. Linux – окружения, которым необходимо что-либо на базе Linux, уже используют текущие релизы (CR). При этом за последние 8 текущих релизов виртуальный агент доставки (VDA) Linux существенно преобразился. Подробнее познакомиться с виртуальным агентом доставки (VDA) можно при помощи статьи: «Виртуальный агент доставки (VDA) для Linux (Citrix Virtual Apps and Desktops 1906)».
3. Улучшения Director (Director Enhancements) – за последние 9 релизов с LTSR 7.15 Citrix Director непрерывно улучшался и добавил множество новых возможностей и метрик. Например, начиная с релиз 1903 можно увидеть время входа (Logon Time) и время загрузки профиля (UPM Load Duration), а также начиная с релиз 1906 выполнить пробу рабочего стола (Desktop Probing).
4. Персонализация пользователя (User Personalization) – пользовательские уровни (User Layers) появились в Citrix AppLayering 4.14 (сразу после релиза 1808). Это одна из новинок 1912 – при установке или обновлении виртуального агента доставки для одиночной сессии (Single-Session VDA) можно добавить «User Personalization». Эта возможность предоставляется Citrix AppLayering (но не требует отдельной инфраструктуры) и обеспечивает возможность сохранять пользовательские данные и установленные приложения между сессиями. Данная возможность теперь полностью заменяет PvD и AppDisks, которые переведены в состояние устаревших (Deprecated) еще в релизе 7.13. Обратите внимание, что пользовательские уровни мигрируют в момент входа пользователя в систему, а не во время загрузки (как PvD и AppDisks), поэтому данный функционал требует отдельного тестирования.
5. Ввод/вывод Machine Creation Service (MCS I/O) – по аналогии с кэшем записи для PVS, Citrix добавил такую же возможность для MCS в текущем релизе (CR) 1903. Некоторое время назад данная возможность называлась «MCS Write-back Cache v2», но на самом деле она увеличивает производительность хранилища за счет использования оперативной памяти в первую очередь с переключением на диск только при необходимости.
6. Асинхронный ввод/вывод Provisioning Services (PVS Asynchronous I/O) – до выхода PVS 1808, целевое устройство обрабатывало входящие запросы хранилища операционной системы через последовательное пересечение трех различных уровней (кэша оперативной памяти (RAM Cache), файла VHDX (VHDX File) и сетевой поточной передачи (Network Streaming)) для завершения запроса. Начиная с 1808 (и при помощи флажка (CheckBox) в 1811, чтобы сделать жизнь чуточку проще) теперь можно отправлять и обрабатывать три потока асинхронно, что позволяет сократить задержку и существенно увеличить производительность.
7. HDX Insight 2.0 (NSAP) – он меняет все, команда разработки полностью заново спроектировала то, как работает HDX Insight. Citrix представил 28-ой виртуальный канал, который называется «NSAP» и предоставляет выделенный, несжатый путь для данных Insight. Это может легко удвоить масштабирование Insight/AppFlow, не говоря уже о повышении стабильности и масштабируемости ADC.
8. Microsoft Outlook, Skype и Teams – практически все используют Microsoft Outlook, Skype или Teams. Теперь их можно разворачивать в окружении Citrix. Возможность перенаправления поиска Outlook (Outlook Search Redirection) впервые появилась в 7.18 и изменялась несколько раз для обеспечения развертывания Outlook в окружении без сохранения состояния (Non-persistence) с простым и удобным поиском. Также в последних релизах была проделана существенная переработка, кода для высокопроизводительной интеграции Microsoft Teams (о ней я расскажу в одной из следующих статей).
9. Ключевые улучшения пользовательских возможностей (Key UX Enhancements) – адаптивная пропускная способность EDT делает протокол лучше, чем, когда бы то ни было.
10. Интеграция с облаком (Cloud Integration) – здесь все так же, как и с Linux, если в окружении есть какая-либо интеграция с Citrix Cloud, значит оно использует текущий релиз (CR). За последние несколько релизов Citrix внес множество значимых (и низкоуровневых) изменений в работу гибридного облака.

Следующий шаг.

Уже прямо сейчас можно загрузить новый дистрибутив и начать тестирование новых возможностей в пред-производственных окружениях. Также можно напрямую обновиться с текущего релиза (CR) Citrix Virtual Apps and Desktops или релиза с длительной поддержкой (LTSR) Citrix XenApp and XenDesktop 7.15 CU4/CU5. В свою очередь страница LTSR FAQ продолжит обновляться ближайшие несколько недель.

P.S. В следующий раз я подробней расскажу об оптимизации доставки Microsoft Teams.

Защита корпоративных окружений при помощи инспекции контента Citrix ADC

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

Далее мы рассмотрим возможности инспекции контента Citrix ADC и как они могут помочь вести мониторинг корпоративного трафика.

Инспекция контента (Content Inspection) в Citrix ADC.

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

Когда необходимо проверить контент перед выгрузкой или загрузкой данных с сервера приложений, можно интегрировать Citrix ADC с устройством безопасности, которое будет развернуто в режиме ICAP, линейно или только-обнаружение (зеркало). Также Citrix ADC помогает разгрузить устройство безопасности от обработки SSL.

Ключевые возможности модуля инспекции контента Citrix ADC:

• Интеграция с IPS/NGFW.
• ICAP для взаимодействия с устройствами размещающими серверы ICAP.
• Поддержка зеркалирования трафика HTTP/HTTPS на пассивные устройства.

Сценарии применения инспекции контента.

Рассмотрим диаграмму, описывающую несколько сценариев применения инспекции контента в Citrix ADC.

Когда Citrix ADC получает трафик HTTP, он отправляется напрямую на стороннее устройство для инспекции. Если это трафик HTTPS, как показано на диаграмме, Citrix ADC расшифровывает трафик и отправляет его в открытом виде на сторонне устройство. Данная функциональность позволяет Citrix ADC обеспечивать следующие сценарии:

• Свободно подключать DLP, антивирусные и прочие устройства, которые умеют работать с ICAP: Citrix ADC может отправлять трафик в открытом виде по протоколу ICAP любому устройству, которое выступает в роли сервера ICAP. При помощи данной возможности можно добавлять защиту от потери данных (DLP), антивирус (AV) или любое другое устройство безопасности в развертывание без внесения серьёзных изменений. Поддержка протокола ICAP добавлена начиная с версии 12.0.
• Свободное подключение IPS, NGCW и так далее, без необходимости линейного подключения: Citrix ADC может отправлять трафик в открытом виде любому устройству безопасности, которое подключено к сети на втором уровне (L2). ADC может направлять трафик на устройство, такое как IPS или NGFW, получать ответ и отправлять трафик фоновому серверу (Backend) или же сбрасывать/обрывать (Drop/Reset) подключение на базе ответа. Также Citrix ADC может увязывать в цепочку различные устройства безопасности в определенном порядке. При помощи инфраструктуры политик можно использовать отдельные устройства для определенных типов трафика. Данная возможность поддерживается, начиная с версии 12.1.
• Свободное подключение устройств мониторинга, таких как IDS, для получения видимости: Citrix ADC. Может отправлять копию трафика HTTP на любое пассивное устройство при помощи возможности зеркалирования. При подобном развертывании ADC не ожидает ответа от пассивного устройства. Данная возможность доступна начиная с версии 13.0.
• Снижение затрат на AV, DLP и IPS за счет разрыва TLS на Citrix ADC для входящего трафика на серверы: Citrix ADC предоставляет разрыв TLS для входящих соединений SSL для серверов и позволяет администраторам получить просмотр трафика, чтобы убедиться, что входящий трафик безопасен и может быть пропущен. При помощи разгрузки TLS за счет разрыва на Citrix ADC, прочие устройства в сети могут сохранить ресурсы CPU, сократив затраты на емкость устройств.
• Обеспечение безопасности серверов приложений за счет устранения зашифрованных атак при помощи инспекции контента: Citrix ADC предоставляет просмотр трафика SSL при помощи перехвата SSL. Это обеспечивает администраторов возможностью определять зашифрованные атаки и защищать инфраструктуру.
• Снижение затрат на AV, DLP и FW при помощи разрыва TLS на Citrix ADC для сотрудников, получающих доступ к сети интернет: Citrix ADC предоставляет просмотр для соединений SSL направляющихся за пределы ЦОД и обеспечивая администраторов возможностью просмотра исходящего трафика для соответствия требованиям регуляторов.

Возможности инспекции контента предоставляют расширенный просмотр в соответствии с потребностями без компромиссов в гибкости. Подробнее познакомиться с инспекцией контента можно здесь: Citrix Docs.

Перевод механизма обработки трафика на инфраструктуру расширенных политик (Advanced Policy) в Citrix ADC

Инфраструктура политик Citrix ADC управляет трафиком в рамках устройства. Политики используют логические выражения для оценки запросов (Request) или ответов (Response) и на базе результатов проверки применяют одно или несколько действий.

В Citrix ADC можно использовать инфраструктуры как классических (Classic), так и расширенных (Advanced) политик. Инфраструктура расширенных политик (Advanced Policy) использует выражения, которые похожи на классические политики (Classic Policy), но способны анализировать комплексные данные и поддерживают настройку большего числа операций в выражениях. Например, они могут трансформировать данные в теле запроса в HTTP-запрос.

Расширенные политики (Advanced Policy) обладают большими возможностями, чем классические политики (Classic Policy) и требуются для использования новейших возможностей Citrix ADC. Citrix перевел классические политики (Classic Policy) в категорию устаревших (Deprecated), и если ваше устройство до сих пор использует классические политики (Classic Policy), то сейчас самое подходящее время для перехода на расширенные (Advanced).

Рассмотрим преимущества расширенных политик и причины перехода.

Причины перехода на расширенные политики (Advanced Policies).

Большинство компонентов Citrix ADC генерирует комплексные данные, которые необходимо проверять, что, в свою очередь, делает расширенные политики предпочтительными. Некоторые возможности инфраструктуры расширенных политик (Advanced Policy):

• Гранулированный анализ трафика на уровнях со 2 по 7-ой.
• Проверка любой части заголовка или тела как запроса, так и ответа HTTTP или HTTPS.
• Привязка политики к нескольким точкам привязки, которые поддерживает инфраструктура расширенных политик (Advanced Policy) по умолчанию; переопределение и привязка на уровне виртуальных серверов.
• Выражение «goto» для передачи управления другим политикам и точкам привязки, определяемым результирующим выражением проверки.
• Специальные инструменты, такие как наборы шаблонов (Pattern Sets), заголовки политик (Policy Labels), идентификаторы ограничения скорости (Rate Limit Identifiers), вызовы HTTP (HTTP Callouts), которые позволяют эффективно настраивать политики для комплексной проверки данных.

Создавать и управлять расширенными политиками и выражениями можно при помощи графического пользовательского интерфейса Citrix ADC. Графический интерфейс также обеспечивает, возможность проверки политик, которую можно использовать для оценки расширенных политик (Advanced Policy) и тестирования их поведения перед вводом в эксплуатацию, что позволит избежать ошибок настройки.

Рассмотрим компонент ICAP, который выполняет проверку контента в Citrix ADC. Этот компонент получает запросы HTTP, прерывает трафик и использует политики проверки содержимого (Content Inspection Policy) для оценки необходимости обработки запроса HTTP при помощи ICAP. Если это так, устройство расшифровывает и отправляет сообщение в виде плоского текста на серверы ICAP. При помощи службы трансформации контента (Content Transformation Service) на серверах ICAP запрос обрабатывает и отправляет его обратно на устройство. Устройство должно использовать расширенные политики (Advanced Policy), так как классические политики (Classic Policy) не могут выполнять комплексные операции, такие как: балансировка нагрузки (Load Balancing), преобразование контента (Content Transformation) и встроенное кэширование (Integrated Caching).

Пример:

add ContentInspection policy ci_pol_HTTP –rule HTTP.REQ.URL.CONTAINS(“html”) –action ci_act_svc

Некоторые динамические возможности позволяют использовать выражения расширенных политик (Advanced Policy) вместо классических (Classic Policy). Для этого необходимо обновить Citrix ADC до 12.0 build 56.20 и переключиться на инфраструктуру расширенных политик (Advanced Policy).

Переход на расширенные политики (Advanced Policies).

Рассмотрим вопрос миграции существующих классических политик (Classic Policy), особенно в сценариях с большим количеством (десятки и сотни), на расширенные политики (Advanced Policy).

Можно мигрировать существующие классические политики (Classic Policy) как вручную, так и при помощи инструмента nspepi, который может автоматически конвертировать классические политики (Classic Policy) и их выражения (команды, выражения и настройки) на инфраструктуру расширенных политик (Advanced Policy).

Для получения дополнительной информации об утилите nspepi и ее процессе конвертации обратитесь к разделу документации «Conversation using nspepi». Для получения информации о классических политиках, которые выводятся из эксплуатации (Deprecated) и альтернативных, не устаревших компонентах, обратитесь к странице «Deprecated Features and Functions».

Пример ручной конвертации в расширенные политики (Advanced Policy).

Классическая политика (Classic Policy):

add filter policy f_pol1 -rule “REQ.HTTP.URL == /test” -reqAction RESET

Расширенная политика (Advanced Policy):

add responder policy f_pol1 “HTTP.REQ.URL.EQ(\”/test\”)” RESET

При помощи ручной конвертации, можно менять классические политики (Classic Policy) на расширенные (Advanced Policy) в конфигурационном файле устройства, но это может быть достаточно утомительно в случае с множеством политик. Чтобы избежать этого, можно использовать инструмент nspepi для конвертации всего файла.

Следующие шаги.

Citrix разрабатывает инфраструктуру политик Citrix ADC с быстро настраиваемыми политиками таким образом, чтобы уровень базовых политик и выражений оставался простым и при этом динамическим. Некоторые новые компоненты требуют от устройства Citrix ADC поддержки состояния и запоминания ключей (Tokens) для интеллектуального принятия решений в рамках жизненного цикла сессий. Выражения расширенных политик (Advanced Policy) помогают добиться этого и предоставляют операционные возможности.

Чтобы лучше изучить инфраструктуру расширенных политик (Advanced Policy) и переход с классических политик (Classic Policy) в частном случае – обратитесь к документации или приходите ко мне на курсы: SoftLine Education.

Анонс поддержки TLS 1.3 на Citrix ADC (в прошлом Citrix NetScaler ADC)

Citrix анонсировал поддержку Transport Layer Security версии 1.3 (TLS 1.3 IETF-RFC 8446) на устройствах Citrix ADC. TLS 1.3 предоставляет расширенную безопасность одновременно с высокой скоростью на всех коммуникациях между клиентами и серверами. Citrix является первым производителем ADC (контроллеры доставки приложений), выпустившим проект TLS 1.3 в ноябре 2017 года. RFC для TLS 1.3 формально опубликован в начале августа 2018 года. Citrix не тратил время зря и в соответствии со взятыми на себя обязательствами выпустил поддержку 1.3 для всех клиентов на Citrix ADC 12.1 (build 49.23) и всех последующих версиях. Это вновь делает Citrix первым производителем ADC, выпустившим поддержку для RFC TLS 1.3 из коробки на публично доступном релизе. Вместе с этим Citrix продолжает укреплять свое лидерство в области безопасной доставки приложений.

Клиенты могут защитить подключение на клиентской стороне при помощи TLS 1.3 в то время как Citrix ADC работает как прокси для классических приложений и позволяет клиентским подключениям быть защищенным при помощи TLS 1.3. В релизе Citrix ADC 12.1 (build 49.23) TLS 1.3 поддерживается на Citrix ADC VPX (виртуальное устройство) и Citrix ADC MPX (аппаратное устройство на базе Cavium N3).

Улучшения TLS 1.3.

TLS 1.3 обладает значительными улучшением по сравнению со своими предшественниками:

1. Значительное увеличение скорости подключения – TLS 1.3 сокращает число циклов обработки необходимых между клиентом и сервером для успешного квитирования (Handshake). 0-RTT (нулевое время обработки цикла) – возможность TLS 1.3, позволяющая первому запросу клиента быть отправленным раньше успешного установления соединения TLS, в результате чего, сокращается время подключения. TLS 1.3 также позволяет клиенту открыть несколько параллельных соединений при помощи открытия нового билета сессии для каждого подключения.
2. Значительно улучшенная защита от внешних угроз – предшественники TLS 1.3 восприимчивы к таким векторам атаки, как Padding Oracle, понижение протокола (Protocol Downgrade) и так далее. TLS 1.3 устраняет угрозы от этих атак. TLS 1.3 также предоставляет совершенную прямую секретность (Perfect Forward Secrecy) по умолчанию, которая обеспечивает защиту ключей сессии от компрометации, даже если частный ключ сервера скомпрометирован, также это помогает в будущей защите зашифрованных данных. В дополнение RFC TLS 1.3 на устройствах Citrix ADC VPX и MPX поддерживает следующие шифры:

• TLS1.3-AES256-GCM-SHA384 (0x1302).
• TLS1.3_CHACHA20_POLY1305_SHA256 (0x1303).
• TLS1.3-AES128_GCM-SHA256 (0x1301).

 

Внедрение TLS 1.3.

Существует множество ранних внедрений TLS 1.3, например, она включена по умолчанию в Mozilla Firefox 61 и Chrome 65. С практической стороны, Google и Facebook тоже включили поддержку TLS 1.3 на своих серверах. В то время как всего 5% подключений Firefox использует TLS 1.3, уже более 50% трафика Facebook идет через подключение TLS 1.3.

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