Tls offload что это

Linux Kernel TLS и Nginx

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

Предыстория

В далеком 2015 году Randall Stewart и Scott Long из компании Netflix выступили на конференции AsiaBSDCon2015 c докладом об оптимизации раздачи шифрованного контента. Основной посыл доклада — необходимо переносить шифрование данных в ядро операционной системы для уменьшения количества копирований данных между kernel-space и user-space и использовать оптимизированный неблокирующий системный вызов sendfile(). Тема оказалась очень перспективной и уже в 2016 году на конференции Netdev 1.2 Dave Watson из Facebook выступил с докладом о необходимости создания TLS сокетов в ядре Linux, а Boris Pismenny, Ilya Lesokhin и Liran Liss из Mellanox — с докладом о возможности использовать аппаратное ускорение TLS в сетевых картах. Так же тема обсуждалась на HighLoad++ 2017 докладчиком от Tempesta Technologies.

Поддержка в ядре Linux

Итогом всех этих разговоров стало появление Kernel TLS в ядре Linux 4.13 (2017 год) c поддержкой TLSv1.2 и шифра AES128-GCM. Первоначально поддерживалось шифрование только исходящего трафика, поддержка дешифрования появилась позже в ядре Linux 4.17 (2018 год). В версии 5.1 добавили поддержку TLSv1.3 и AES256-GCM, а в версии 5.2 еще и шифр AES128-CCM (2019 год).

Поддержка в user-space

Во всех указанных выше докладах рассказывалось, что в ядро можно поместить только шифрование полезных данных, а все согласования и контрольные сообщения TLS необходимо обрабатывать всё так же в user-space. И для этого использовалась модифицированная версия OpenSSL. Однако на момент публикации докладов в открытом доступе не было информации о том, какие именно модификации в эту широкоизвестную библиотеку надо сделать, чтобы поддержать функционал. Пожалуй, единственным доступным примером использования Linux Kernel TLS была статья в блоге Filippo Valsorda Playing with kernel TLS in Linux 4.13 and Go, появившаяся сразу после выхода ядра Linux 4.13. И, хотя она показывала действительный пример использования технологии, это не принесло понимания в то, как же использовать технологию в реальных проектах. Ведь очень мало кто самостоятельно пишет WEB-сервер для своего проекта, обычно все используют известные и проверенные временем инструменты.

Поддержка в OpenSSL

Первые обсуждения технологии в OpenSSL появились летом 2017 года незадолго до выхода ядра Linux 4.13 (PR 3631), однако процесс обсуждения шел очень и очень медленно, первые реальные замечания появились в октябре (уже после выхода ядра 4.13), а собственно рабочий вариант начали обсуждать в феврале 2018. К моменту согласования всех исправлений, окно добавления нового функционала в OpenSSL 1.1.1 было закрыто, и поддержку Kernel TLS перенесли в следующий релиз. С того времени добавили поддежку Kernel TLS RX, и SSL_sendfile() — вызов соответствующего syscall с небольшой обработкой возможных ситуаций в протоколе TLS. Но сейчас на дворе 2020 год, OpenSSL 3.0 еще не вышел, TLSv1.3 поддерживается подавляющим большинством браузеров, а шифр AES128-GCM активно вытесняется более стойким AES256-GCM. Поэтому я взял на себя смелость и отправил Pull Request на поддержку новых шифров и TLSv1.3 в надежде, что его примут до нового релиза библиотеки.

Поддержка в WEB-серверах

Но поддержать Kernel TLS в TLS библиотеке мало. В докладах про технологию говорилось, что максимальную эффективность можно получить используя отправку без копирования данных в user-space — используя системный вызов sendfile(). И серверное приложение должно уметь различать ситуации, когда можно использовать sendfile() на сокете с TLS, а когда необходимо «по-старинке» делать read()/SSL_write(). Некоторые подвижки в сторону добавления функционала в Nginx появились в апреле 2019 года, но в основной код изменения приняты не были. Позиция разработчиков в том, что API для этих функиций в OpenSSL еще не утвержден, а собственно сам код, предложенный в патче, не выглядит достаточно портируемым на разные платформы. Скажу честно, код не только выглядит не очень красиво, но и содержит ошибки, которые не позволяют собрать Nginx без дополнительных исправлений. Поддержки Kernel TLS в других веб-серверах я вообще не смог найти (может быть кто-то видел — подскажите в комментах).

И что же делать?

Пока сообщество ожидает выхода релиза OpenSSL 3.0, чтобы начать разработку поддержки Kernel TLS в Nginx в условиях стабильного API, я пошел иным путём. В своём уютном уголочке GitHub я сделал 2 вещи:

1. Создал форк OpenSSL и бэкпортировал всё связанное с Kernel TLS в стабильную версию OpenSSL 1.1.1 (ветка OpenSSL_1_1_1-ktls). Специально для того, чтобы иметь возможность проверять функционал в условиях стабильной работы остальной части библиотеки. По мере выхода стабильных версий стараюсь делать rebase, чтобы форк был актуальным.
2. Создал форк Nginx, в который добавил (на основе патча от Mellanox) поддержку вызова SSL_sendfile() в условиях, когда это действительно возможно и с необходимыми проверками SSL сокета, и возможность включения/выключения функционала через конфигурационную переменную. Помимо этой фичи в моем форке так же есть несколько патчей, немного оптимизирующих работу Nginx, и исправляющих некоторые баги (ветка master-feature). По мере возможностей я стараюсь делать rebase на основе master-ветки основного репо Nginx, чтобы поддерживать форк в условно-актуальном состоянии.

./configure --with-openssl= --with-openssl-opt="enable-ktls" 

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

Материал для IT World: Повышение производительности систем с помощью новых решений Intel

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

В своем экспертном материале компания NUT.Tech делится опытом работы с интересным решением от Intel и рассказывает обо всех тонкостях его использования.

Когда перед компанией встает задача развивать высокопроизводительные масштабируемые решения, в самую первую очередь нужно думать о конфигурации вашего железа. Например, мы выбрали решение на базе центральных процессоров Intel Xeon Gold processor 6230R, которое позволяет достигать до 110 Gbps исходящего трафика при более 20к RPS, используя сетевые интерфейсы 25 Gbps. Если судить по нашему опыту, то для более эффективного использования места в стойках, стоит всегда стремиться увеличивать плотность видео отдачи с одного юнита, не забывая в этой гонке о резервировании и об отказоустойчивости сервиса, в целом. Таким образом, если мы когда-то имели дело с серверами видео отдачи с исходящим трафиком в несколько Gbps, изначально базирующихся на платформах с процессором Intel Xeon Processor X5660 (нам они нравились своей сбалансированностью), то сейчас эволюционировали до платформ на центральных процессорах 2nd Generation Intel Xeon Scalable Processors.

Пример конфигурации сервера видеоотдачи:

Intel Xeon Gold 6230R Processor

RAM: 16GB DDR4 2933MHz

SATA SSD PM883 480Gb

Intel XXV710-DA2 (2x25Gbps)

Увеличить производительность такой конфигурации позволяют адаптеры, использующие технологию технологии Intel QuickAssist (Intel QAT) за счет обработки TLS сессий (в нашем случае TLS 1.3 c шифром TLS_AES_256_GCM_SHA384). Так же данная технология позволяет ускорить обработку следующих операций: симметричное шифрование и аутентификацию, асимметричное шифрование, цифровые подписи, RSA, DH, ECC и сжатие данных без потерь.

Intel QAT адаптеры представляют собой устройства с тремя физическими чипами (поддерживающих виртуализацию с помощью Virtual Function устройств) использующие шину PCI-E Gen3.0 x16, которым можно передать нагрузку по обработке сессий шифрования с клиентами.

Для оптимальной конфигурации потребовалась платформа с шестью слотами PCI-E (4x PCI-E Gen3.0 x8 для сетевых карт и 2х PCI-E Gen3.0 x16 слотам для Intel QAT адаптеров).

Тесты проводились в разных конфигурациях, как с одним, так и с двумя акселераторами, в итоге был сделан вывод, что для лучшей производительности для двух процессоров использовать две карты Intel QAT, тем самым утилизировав их co-processor’ы на 80%.

При использовании такого сервера видеоотдачи с Nginx, Intel QAT адаптер берет на себя около 30% нагрузки по шифрованию сессий с клиентами.

Intel Xeon Gold 6230R Processor

Балансировка нагрузки с помощью FortiGate

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

FortiGate обеспечивает комплексную защиту вашей инфраструктуры и балансирует нагрузки серверов, распределяя потоки трафика по заданным правилам, что позволяет объединить в одном устройстве функции балансировщика нагрузки, Next Generation Firewall (NGFW) и защиту от угроз.

Балансировка нагрузки на основе решений FortiGate обеспечивает:

• быструю и надежную обработку запросов;
• значительное упрощение сетевой архитектуры;
• снижение операционных расходов.

Балансировщик нагрузки поддерживает HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL или более низкоуровневые протоколы TCP/UDP или IP. Сохранение сеанса поддерживается на основе идентификатора сеанса SSL или на основе введенного файла cookie HTTP.

Health Check — механизм проверки работоспособности серверов для предотвращения отправки трафика балансировки нагрузки на неработающие серверы. Для проверки используется ICMP ping или другое более сложное тестирование TCP-соединений. Health Check удаляет из кластера балансировки нагрузки неработающие реальные серверы. Удаление реальных серверов из кластеров основано на настройках:

• Interval — с какой частотой проверяется сервер;
• Timeout — максимальное допустимое время ответа, прежде чем сервер будет считаться недоступным;
• Retry — количество отказов до того, как сервер считается недоступным, после чего удаляется.

Типы Health Check по протоколам: TCP, HTTP, PING.

Virtual Server — виртуальный сервер, на чей внешний IP-адрес поступает трафик, который перенаправляется к балансировщику нагрузки.

Real Server — действительный, реальный, сервер, на который поступают запросы после балансировки. За каждым виртуальным сервером может быть закреплено несколько реальных серверов. Конфигурация реального сервера включает IP-адрес и номер порта, на котором реальный сервер принимает сеансы. Устройство FortiGate отправляет сеансы на IP-адрес реального сервера, используя номер порта назначения в реальной конфигурации сервера. Конфигурация сервера включает его IP-адрес и номер порта, на котором принимает сеансы.

SSL Offloading — механизм ускорения SSL-соединения клиентов с сервером, при котором операции шифрования производятся на FortiGate вместо самих серверов с помощью отдельного специального процессора. Данный механизм можно применить, только если для балансировки нагрузки задан тип одного из протоколов SSL (HTTPS, IMAPS, POP3S, SMTPS, SSL). FortiGate предоставляет возможность выбрать, какие сегменты SSL-соединения будут получать разгрузку SSL, определив режим:

• Client ⟷ FortiGate — режим, при котором аппаратно ускоренная обработка SSL/TLS только в части соединения между клиентом и устройством FortiGate. Этот режим называется half mode SSL offloading. Сегмент между устройством FortiGate и сервером будет использовать открытое (clear text) соединение, что обеспечит лучшую производительность;
• Full — режим, при котором применяется аппаратно ускоренная обработка SSL к обеим частям соединения: сегментом между клиентом и блоком FortiGate и сегментом между блоком FortiGate и сервером, то есть Client ⟷ FortiGate ⟷ Server. Сегмент между устройством FortiGate и сервером будет использовать шифрованное соединение, но «рукопожатия» будут сокращены. Это не так эффективно, как разгрузка SSL в half mode, но все же повышает производительность.

HTTP multiplexing — функция, которая позволяет веб-клиенту использовать одно соединение TCP для всех запросов к серверу. Данная особенность снижает нагрузку на веб-сервер за счет установки единого соединения, по которому параллельно отправляются запросы и ответы. Каждый фрагмент ассоциируются с помощью специальных встроенных мета-данных, что обеспечивает возможность корректной обработки множества несвязанных запросов HTTP или HTTPS в различном порядке в одном и том же соединении. Более того, ответы получаются по мере их готовности, следовательно, тяжелые запросы не будут блокировать обработку и выдачу более простых объектов.

Например, если веб-браузеры пользователей совместимы только с HTTP 1.0, в котором данная функция не реализована, то включение опции HTTP multiplexing может повысить производительность между веб-сервером и FortiGate.

Persistence — параметр, который сохраняет и отслеживает данные сеанса, чтобы убедиться, что пользователь подключается к одному и тому же серверу каждый раз, когда он делает запрос, являющийся частью одного и того же сеанса или последующих сеансов. HTTP cookie persistence использует внедренные файлы cookie для обеспечения сохраняемости.

При настройке Persistence FortiGate балансирует нагрузку нового сеанса на реальный сервер в соответствии с методом балансировки нагрузки. Если у сеанса есть HTTP cookie или идентификатор сеанса SSL, устройство FortiGate отправляет все последующие сеансы с одним и тем же файлом cookie HTTP или идентификатором сеанса SSL на один и тот же реальный сервер.

Методы балансировки нагрузки ⁠ ​

Трафик может распределяться между серверами на основе методов:

• static — равномерное распределение нагрузки между серверами по заранее определённому алгоритму, не учитывая занятость серверов;
• round-robin — распределение на основе алгоритма round-robin, выполняющего перебор равнозначных между собой серверов по циклу, независимо от времени ответа или количества подключений;
• weighted — распределение на основе присвоенных весов серверам для учёта особенностей и различий, где серверы с большим значением веса получают больший процент подключений;
• least-session — распределение, при котором запросы направляются на сервер, имеющий наименьшее количество текущих подключений, рекомендуется использовать при схожих возможностях серверов;
• least-rtt — распределение на основе Round-Trip-Time (время приема-передачи), при котором запросы направляются на сервер с наименьшим таким показателем, который определяется монитором Ping health check и по умолчанию равно 0, если Ping health check не установлен;
• first-alive — раздача нагрузки на первый действующий сервер, обеспечивая защиту от сбоя: сеансы не распределяются между серверами, а обрабатываются одним “первым”, пока он “живой”, а затем переключается на другой работающий сервер;
• http-host — распределение на основе HTTP-заголовка хоста, чтобы направить соединение к определенному серверу.

Перед настройкой балансировщика ⁠ ​

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

1. Перейдите в System → Feature Visibility.
2. Включите Load Balance в списке Additional Features.

В данном примере будут рассмотрены настройки Load Balancing для HTTP и HTTPS на аппаратном FortiGate-100E, первоначальную базовую настройку которого можно провести согласно инструкциям по настройке межсетевых экранов. В качестве серверов используются облачные серверы в Облачной платформе Selectel.

FortiGate и проект в Облачной платформе соединены приватной сетью, для подключения которой используется сеть глобального роутера между регионами и услугами, что позволяет устанавливать за межсетевым экраном также выделенные серверы и серверы в Облаке на базе VMware.

Настроить балансировщик ⁠ ​

В данной конфигурации балансировщик распределяет HTTP-трафик из интернета на три веб-сервера, находящихся во внутренней сети. Сеансы HTTP принимаются на интерфейсе wan1 с IP-адресом назначения 172.20.120.121 на TCP-порте 3080 и перенаправляются с внутреннего интерфейса на веб-серверы. При пересылке адрес назначения сеансов преобразуется в IP-адрес одного из веб-серверов.

Аналогичным образом происходит балансировка HTTPS-трафика.

Создать Health Check ⁠ ​

HTTP ⁠ ​

Для проверки работоспособности создайте Health Check на уровне HTTP, для которого можно детально настроить URL /index.html и контент ctel .

Для настройки Health Check, который отправляет get-запросы по адресу http:///index.html и выполняет поиск на возвращенной веб-странице фразы «Selectel», выполните следующие действия:

1. Перейдите в раздел Policy & Objects → Health Check.
2. Нажмите кнопку Create New.
3. Укажите имя в поле Name.
4. Укажите тип HTTP в поле Type.
5. Введите порт в поле Port (по умолчанию для HTTP-трафика — 80).
6. Введите искомую фразу в поле Matched content.
7. При необходимости укажите другие параметры.

HTTPS ⁠ ​

Для мониторинга работоспособности серверов на уровне HTTPS создается аналогичный Health Check, только без детальной проверки контента и URL.

Создать Virtual server ⁠ ​

HTTP ⁠ ​

Virtual Server для HTTP ⁠ ​

Создается Virtual server, на который будет поступать HTTP-запросы.

1. Перейдите в раздел Policy & Objects → Virtual Servers.
2. Нажмите кнопку Create New.
3. Укажите имя в поле Name, тип HTTP в поле Type, интерфейс в поле Interface.
4. В Virtual server IP и Virtual server port — внешний IP-адрес и порт, на которые будут поступать запросы.
5. В выпадающем меню Load balancing method выберите метод балансировки нагрузки, который подходит для вашего случая.
6. Включите опцию Persistence, чтобы сохранять данные о сеансе, выбрав значение HTTP Cookie.
7. Выберите монитор работоспособности Health check, созданный ранее, нажав +.
8. Включите опцию HTTP multiplexing, если необходимо использовать единое TCP-соединение между веб-клиентом и сервером, в том числе и для поступающих несвязанных запросов и ответов.
9. Включите опцию Preserve client IP для сохранения IP-адреса клиента в HTTP-заголовке X-Forwarded-For . Это может быть полезно при включении HTTP multiplexing, если на реальных серверах требуются сохранить исходный IP-адрес клиента, например, в log-сообщения.

Привязать реальные серверы к виртуальному ⁠ ​

1. В разделе Policy & Objects → Virtual Servers, где продолжается настройка Virtual Server, создайте Real Servers.
2. В таблице Real Servers нажмите Create New.
3. В открывшемся окне добавьте IP-адрес и порт сервера, по которым требуется подключение. В данном случае HTTP-сервер развернут на 80 порту.
4. Нажмите кнопку OK.
5. Добавьте все сервера, участвующие в балансировке нагрузки, повторив пункты 1-4.
6. Сохраните настройки Virtual Server, нажав кнопку OK.

HTTPS ⁠ ​

Для работы балансировщика нагрузки FortiGate требуется загрузить SSL-сертификат.

Добавить SSL-сертификат ⁠ ​

1. Перейдите в раздел System → Certificates.
2. Убедитесь, что в System → Feature Visibility включено Certificates.
3. Выберите Import → Local Certificate.
4. В открывшемся окне установите Type — Certificate, загрузите Certificate file и Key file для вашего сертификата.
5. Введите пароль в поле Password.

После выполненных действий сертификат сервера появится в списке Certificates.

Virtual Server для HTTPS ⁠ ​

Для HTTPS виртуальный сервер создается аналогичным образом, что и для HTTP, указав тип Virtual Server в поле Type на HTTPS.

В качестве Persistence имеется возможность установить SSL Session ID помимо HTTP Cookie.

Для ускорения SSL-соединения в подразделе SSL Offloading выберите требуемый режим в поле Mode, определив таким образом какой сегмент сети будет разгружен: Client-FortiGate или Full.

Также выберите в выпадающем меню SSL-сертификат в поле Certificate, импортированный ранее.

Привязать реальный сервер к виртуальному ⁠ ​

В подразделе Real Servers аналогичным образом добавьте реальные сервера, между которым будет балансироваться нагрузка. Укажите корректные порты, на котором развернуты веб-сервера для HTTPS-трафика, по умолчанию это порт 443.

Создать политику ⁠ ​

Чтобы создать политику безопасности, включающую виртуальный сервер балансировки нагрузки в качестве адреса назначения:

1. Перейдите в раздел Policy & Objects → Pv4 Policy.
2. Нажмите кнопку Create New.
3. Укажите имя политики в поле Name.
4. Укажите входящий интерфейс — Incoming interface, исходящий интерфейс — Outgoing interface, за которым подключены серверы.
5. В поле источник (Source) выберите объект all, нажав +.
6. В поле назначение (Destination) выберите виртуальный сервер балансировки нагрузки, который был создан ранее. Важно, чтобы режим Inspection mode был установлен в настройках политики на Proxy-based. Если режим будет установлен на Flow-based, то виртуальный сервер будет недоступен.*
7. Выключите режим NAT, чтобы серверы “видели” IP-адреса подключившихся клиентов.
8. Для HTTP и HTTPS балансировщика политики создаются аналогичным образом. Разница только в выборе виртуального сервера в поле Destination.
9. Нажмите кнопку OK, чтобы сохранить настройки политики.

Результат ⁠ ​

В данном примере была настроена балансировка нагрузки HTTP-трафика между тремя серверами.

Запросы, поступающие по адресу виртуального сервера 172.20.120.121:3080, перенаправляются на реальные сервера по очереди в соответствии с выбранным методом.

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

Чтобы включить графическое отображение статусов серверов балансировщика, перейдите в раздел Monitor → Load Balance Monitor (для FortiOS версии 6.2).

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

# diagnose firewall vip realserver ? 

Например, следующие команды перечисляют и отображают информацию о статусе всех реальных серверов:

# diagnose firewall vip virtual-server real-server . # diagnose firewall vip realserver list 

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

# diagnose firewall vip virtual-server filter ? 

Самой наглядной проверкой является сниффер пакетов. Следующей командой в FortiGate можно отследить распределение трафика с установленными фильтрами порта и интерфейса для более удобного просмотра:

# diagnose sniffer pa lan ' port 80 ' ? . # diagnose sniffer pa lan ' port 80' 5 

Также трафик можно отследить на самом сервере, например, с помощью команды tcpdump. Ниже показан трафик при выключенном NAT при настройке политики для балансировщика на FortiGate, благодаря чему можно отследить исходящий IP-адрес клиента.

root@server1:~# tcpdump -n -i eth1 port 80 and host 192.168.101.2 

При включенном NAT в качестве исходящего IP-адреса отображается адрес FortiGate:

root@server1:~# tcpdump -n -i eth1 port 80 and host 192.168.101.2 

Библиотека разгрузки TLS управляемого модуля HSM Azure

Управляемый модуль HSM Azure предлагает библиотеку разгрузки TLS, совместимую с PKCS#11 версии 2.40. Управляемый модуль HSM Azure поддерживает не все функции, перечисленные в спецификации PKCS#11; Вместо этого библиотека разгрузки TLS поддерживает ограниченный набор механизмов и функций интерфейса для разгрузки SSL/TLS только с помощью F5 (BigIP) и Nginx, в основном для создания ключей сертификатов сервера TLS и создания цифровых подписей во время подтверждения TLS.

Библиотека разгрузки TLS внутренне использует REST API Azure Key Vault для взаимодействия с управляемым устройством HSM Azure.

Начало работы

Атрибуты PKCS#11

Для правильной интеграции с PKCS#11 для создания ключей (с помощью C_GenerateKeyPair) и поиска объектов ключей (с помощью C_FindObjectsInit/C_FindObjects) требуется решение для хранения атрибутов PKCS#11 в объекте ключа azure Key Vault. Библиотека разгрузки TLS преобразует эти необходимые атрибуты PKCS#11 в теги Key Vault Azure.

Эти «Теги атрибутов» имеют специальный префикс:

• p11_pri_ — атрибуты закрытого ключа
• p11_pub_ — атрибуты открытого ключа

Библиотека разгрузки TLS правильно задает атрибуты операций и времени существования ключей Azure Key Vault, чтобы служба правильно применяла эти ограничения для созданных ключей. Эти атрибуты также хранятся в виде тегов, как и другие атрибуты PKCS#11 для поддержки возможностей запросов.

Приложения, использующие библиотеку разгрузки TLS, используют один или несколько атрибутов PKCS#11 для поиска и использования ключевых объектов.

Ключи, созданные библиотекой разгрузки TLS, и их теги доступны через AZURE Key Vault REST API. Управление этими тегами атрибута P11 с помощью AZURE Key Vault REST API может привести к прерыванию работы приложений библиотеки разгрузки TLS.

Создание ключа

Библиотека разгрузки TLS включает средство создания ключей, mhsm_p11_create_key. Запуск средства без аргументов командной строки показывает правильное использование средства.

Средству создания ключей требуется субъект-служба, которому назначается роль «Пользователь шифрования управляемого устройства HSM» на область «/keys».

Средство создания ключей считывает учетные данные субъекта-службы из переменных среды MHSM_CLIENT_ID и MHSM_CLIENT_SECRET:

• MHSM_CLIENT_ID — необходимо задать идентификатор приложения (клиента) субъекта-службы.
• MHSM_CLIENT_SECRET — необходимо задать пароль субъекта-службы (секрет клиента).

Для управляемых удостоверений указанные выше переменные среды не требуются.

• Используйте аргумент , —identity чтобы включить управляемое удостоверение с помощью средства mhsm_p11_create_key.
• Значение client_id управляемого удостоверения, назначаемого пользователем, следует процитировать в файле конфигурации MHSM (mhsm-pkcs11.conf). client_id Если значение управляемого удостоверения, назначаемого пользователем, не указано, оно будет рассматриваться как управляемое удостоверение, назначаемое системой.

Средство создания ключа случайным образом создает имя ключа во время создания. Полный идентификатор ключа azure Key Vault и имя ключа выводятся на консоль для удобства.

MHSM_CLIENT_ID="" \ MHSM_CLIENT_SECRET="" \ mhsm_p11_create_key --RSA 4K --label tlsKey Key is generated successfully. \ Managed HSM Key ID: https://myhsm.managedhsm.azure.net/keys/p11-6a2155dc40c94367a0f97ab452dc216f/92f8aa2f1e2f4dc1be334c09a2639908 \ Key Name: p11-6a2155dc40c94367a0f97ab452dc216f 

Аргумент —label средства создания ключей указывает требуемый CKA_LABEL для созданных закрытых и открытых ключей. Эти атрибуты обычно требуются для настройки поддерживаемых решений разгрузки TLS (например, параметра конфигурации SSL nginx «ssl_certificate_key»).

Имя ключа требуется для любых изменений назначения ролей с помощью Azure CLI.

Управление доступом

Библиотека разгрузки TLS преобразует C_FindObjectsInit в вызов REST API azure Key Vault, который работает на область /keys. Службе MHSM требуется разрешение на чтение в этом область пользователю библиотеки разгрузки TLS, чтобы авторизовать операцию поиска ключей, созданных с помощью средства создания ключей.

Дополнительные сведения о локальном RBAC управляемого устройства HSM Azure см. в статье:

• Встроенные роли локального модуля RBAC управляемого устройства HSM Azure
• Управление ролями управляемого устройства HSM Azure

В следующем разделе описаны различные подходы к реализации управления доступом для субъекта-службы библиотеки разгрузки TLS и управляемого удостоверения.

Разгрузка субъекта-службы TLS

Субъект-служба разгрузки TLS используется приложением, которое использует библиотеку разгрузки TLS для доступа к ключам, и должно иметь как минимум следующие разрешения через назначения ролей:

• Разрешение KeyRead для всех ключей в управляемом устройстве HSM
• Разрешение KeySign на ключи, необходимые для разгрузки TLS

Администратор

Пользователь Администратор создаст пользовательское определение роли и назначения ролей. Таким образом, пользователю Администратор следует назначить одну из следующих встроенных ролей на область «/»:

• Специалист по системе шифрования управляемого устройства HSM
• Администратор политики управляемого устройства HSM
• Администратор Управляемого устройства HSM

Субъект-служба создания ключей

Субъект-служба создания ключей используется вместе со средством создания ключей (mhsm_p11_create_key) для создания ключей разгрузки TLS. Этому субъекту-службе следует назначить роль «Управляемый пользователь шифрования HSM» на область «/keys».

Azure CLI

Azure CLI можно использовать для выполнения таких задач, как назначение ролей.

Разрешительный подход

Разрешительный подход проще и подходит, если управляемый модуль HSM Azure используется исключительно для разгрузки TLS.

Назначьте роль пользователя шифрования субъекту-службе разгрузки TLS в область «/keys». Это дает субъекту-службе разгрузки TLS разрешение на создание ключей и их поиск для разгрузки TLS.

az keyvault role assignment create --hsm-name ContosoMHSM \ --role "Managed HSM Crypto User" \ --assignee TLSOffloadServicePrincipal@contoso.com \ --scope /keys 

Для управляемых удостоверений укажите аргументы команды следующим образом:

az keyvault role assignment create --hsm-name ContosoMHSM \ --role "Managed HSM Crypto User" \ --assignee-object-id \ --assignee-principal-type MSI \ --scope /keys 

Детализированный подход

Детализированный подход реализует детализированное управление доступом. Для этого требуется два субъекта-службы (субъект-служба разгрузки TLS и субъект-служба создания ключей) и пользователь Администратор.

Цель состоит в том, чтобы ограничить разрешения субъекта-службы разгрузки TLS для поддержки минимально необходимого для разгрузки TLS. Пользователь должен иметь разрешение на чтение для других ключей для поддержки функции C_FindObject* библиотеки.

Роль чтения пользователя библиотеки разгрузки TLS

Первым шагом в реализации детализированного подхода является создание пользовательской роли. Эту операцию необходимо выполнить только один раз.

Пользователь Администратор (с ролью «Администратор управляемого шифрования HSM» или «Администратор политики управляемого модуля HSM») создает настраиваемое определение роли «Роль чтения пользователя библиотеки TLS».

az keyvault role definition create --hsm-name ContosoMHSM --role-definition '< \ "roleName": "TLS Library User Read Role", \ "description": "Grant Read access to keys", \ "actions": [], \ "notActions": [], \ "dataActions": ["Microsoft.KeyVault/managedHsm/keys/read/action"], \ "notDataActions": [] \ >' 

Создание ключей

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

Предоставление разрешения

Пользователь Администратор назначает субъекту-службе разгрузки TLS следующие роли.

• Назначьте роль «Роль чтения пользователя библиотеки TLS» на область
• Назначьте роль «Управляемый пользователь шифрования HSM» в область

В следующем примере ключ имеет имя «p11-6a2155dc40c94367a0f97ab452dc216f».

az keyvault role assignment create --hsm-name ContosoMHSM \ --role "TLS Library User Read Role" \ --assignee TLSOffloadServicePrincipal@contoso.com \ --scope /keys az keyvault role assignment create --hsm-name ContosoMHSM \ --role "Managed HSM Crypto User" \ --assignee TLSOffloadServicePrincipal@contoso.com \ --scope /keys/p11-6a2155dc40c94367a0f97ab452dc216f 

Кэширование подключений

Чтобы повысить производительность вызовов sign к управляемой службе HSM, библиотека разгрузки TLS кэширует свои подключения TLS на серверах службы управляемого модуля HSM. По умолчанию библиотека разгрузки TLS кэширует до 20 подключений TLS. Кэшированием подключений можно управлять с помощью файла конфигурации MHSM (mhsm-pkcs11.conf).

"ConnectionCache":

Отключить

Если это значение равно true, кэширование подключений будет отключено. По умолчанию он включен.

MaxConnections

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

Запрос подписи в секунду (RPS) зависит от количества одновременных запросов и количества кэшированных подключений. Указание большего числа или даже ограничения по умолчанию не приведет к улучшению запросов на подписывание, если количество одновременных запросов подписывания PKCS11 меньше этого предела. Максимальное число одновременных подключений для достижения режима ускорения пула HSM уровня «Стандартный B1» составляет около 30 в зависимости от типа экземпляра. Но вы должны попробовать с разными числами, чтобы определить оптимальное количество одновременных подключений.

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

Использование библиотеки разгрузки TLS

Создание ключей

Библиотека разгрузки TLS включает средство создания ключей, mhsm_p11_create_key. Запуск средства без аргументов командной строки показывает правильное использование средства.

Средству создания ключей требуется субъект-служба, которому назначается роль «Пользователь шифрования управляемого устройства HSM» на область «/keys».

Средство создания ключей считывает учетные данные субъекта-службы из переменных среды MHSM_CLIENT_ID и MHSM_CLIENT_SECRET.

• MHSM_CLIENT_ID — необходимо задать идентификатор приложения (клиента) субъекта-службы.
• MHSM_CLIENT_SECRET — необходимо задать пароль субъекта-службы (секрет клиента).

Средство создания ключа случайным образом создает имя ключа во время создания. Полный идентификатор ключа azure Key Vault и имя ключа выводятся в консоль для вашего удобства.

MHSM_CLIENT_ID="" \ MHSM_CLIENT_SECRET="" \ mhsm_p11_create_key --RSA 4K --label tlsKey Key is generated successfully. Managed HSM Key ID: https://myhsm.managedhsm.azure.net/keys/p11-6a2155dc40c94367a0f97ab452dc216f/92f8aa2f1e2f4dc1be334c09a2639908 \ Key Name: p11-6a2155dc40c94367a0f97ab452dc216f 

Аргумент —label средства создания ключей указывает требуемый CKA_LABEL для созданных закрытых и открытых ключей. Эти атрибуты обычно требуются для настройки поддерживаемых решений разгрузки TLS (например, параметра конфигурации SSL nginx «ssl_certificate_key»).

Имя ключа является обязательным, если вы планируете реализовать детализированный доступ к ключам.

Реализация протокола TLS без ключа

Существует два подхода к созданию ключа и использованию ключа для протокола TLS Без ключей: более простой, более разрешительный подход и детальный подход, обеспечивающий более высокую безопасность. Подходы отличаются в усилиях по реализации и обеспечению безопасности.

Более простой подход

1. Создание субъекта-службы для библиотеки разгрузки TLS (например, TLSOffload ServicePrincipal)
2. Назначьте роль «Управляемый пользователь шифрования HSM» субъекту-службе разгрузки TLS в область «/keys».

az keyvault role assignment create --hsm-name ContosoMHSM \ --role "Managed HSM Crypto User" \ --assignee TLSOffloadServicePrincipal@contoso.com \ --scope /keys 

Детализированный подход

1. Создайте пользователя Администратор (например, TLSOffloadAdminUser) со следующей ролью:
   • Роль «Сотрудник по шифрованию управляемого устройства HSM» на область «/»
2. Создайте субъект-службу создания ключей (например, TLSOffloadKeyGenServicePrincipal) для создания ключа разгрузки TLS и назначьте следующую роль:
   • Роль «Управляемый пользователь шифрования HSM» на область «/keys».
3. Создание субъекта-службы для разгрузки TLS (например, TLSOffload ServicePrincipal)
4. Пользователь Администратор создает следующее определение настраиваемой роли:

az keyvault role definition create --hsm-name ContosoMHSM --role-definition '< \ "roleName": "TLS Library User Read Role", \ "description": "Grant Read access to keys", \ "actions": [], \ "notActions": [], \ "dataActions": ["Microsoft.KeyVault/managedHsm/keys/read/action"], \ "notDataActions": [] >' 

• Метка ключа: tlsKey
• Имя ключа: p11-6a2155dc40c94367a0f97ab452dc216f

• Роль «Роль чтения пользователя библиотеки TLS» на область «/keys»
• Роль «Управляемый пользователь шифрования HSM» на область

az keyvault role assignment create --hsm-name ContosoMHSM \ --role " TLS Library User Read Role" \ --assignee TLSOffloadServicePrincipal @contoso.com \ --scope /keys az keyvault role assignment create --hsm-name ContosoMHSM \ --role "Managed HSM Crypto User" \ --assignee TLSOffloadServicePrincipal@contoso.com \ --scope /keys/p11-6a2155dc40c94367a0f97ab452dc216f 

Дальнейшие действия

• Обзор управляемого устройства HSM Azure
• Встроенные роли локального модуля RBAC управляемого устройства HSM Azure
• Управление ролями управляемого устройства HSM Azure