Облачная разработка CloudBase (Tencent CloudBase, TCB) — это облачная интегрированная среда разработки и инструментальная платформа, предоставляемая Tencent Cloud. Она предоставляет разработчикам высокодоступные серверные облачные сервисы с автоматическим эластичным масштабированием, включая бессерверные вычисления, хранилище, хостинг, и т. д. Возможность, которую можно использовать для разработки различных клиентских приложений (мини-программ, общедоступных учетных записей, веб-приложений, клиентов Flutter и т. д.) интегрированным облачным способом.

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

01. Введение

«Cloud Development Gateway» — это шлюз безопасности для облачной разработки, основанный на приложении Envoy для приложения, WeChat/Enterprise WeChat и общедоступной учетной записи H5/web. Он обеспечивает частные ссылки для облачной разработки, управление трафиком, слабое ускорение сети и т. д. безопасный, стабильный, облачный доступ к приложениям.

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

1.1 Проблемы с HTTPS

Более 90% веб-сайтов в мире используют HTTPS. Сам HTTPS использует TLS для шифрования трафика бизнес-запросов. Учитывая надежность существующего шифрования TLS1.2/1.3 и нынешнюю вычислительную мощность, взлом методом грубого взлома практически невозможен. Так необходимо ли шлюзу снова использовать частный канал для шифрования бизнес-трафика? Фактически, необходимо атаковать HTTPS. Злоумышленники могут использовать MITM для получения входящего трафика клиента и сервера.

Расшифровка трафика HTTPS через MITM требует, чтобы клиент доверял стороннему корневому сертификату, выданному посредником, и существуют некоторые пороговые значения для установки самого корневого сертификата; Поэтому среди распространенных методов атаки злоумышленники обычно не используют этот метод. Во-первых, это условие атаки обычно требует, чтобы злоумышленник и атакуемый находились в одной локальной сети. Во-вторых, доверие к корневому сертификату злоумышленника требует сотрудничества атакуемого, а также требует полномочий администратора или root. Суровые условия использования MITM делают этот метод менее распространенным в реальных атаках. Чаще всего Msfvenom используется для генерации полезных данных, чтобы обманом заставить злоумышленника выполнить операцию и получить тем самым доступ к машине. Поскольку MITM сложно использовать напрямую, можно ли игнорировать этот риск безопасности в наших бизнес-сценариях? В целом в бизнесе действительно можно считать, что использование HTTPS уже соответствует требованиям безопасности. Однако в некоторых областях с более высокими требованиями к сценариям безопасности одного использования HTTPS недостаточно. Например, цена платформы электронной коммерции и исходная информация учетной записи регистрационной платформы; конкуренты могут отслеживать цены на товары друзей в режиме реального времени с помощью метода MITM, чтобы корректировать цены на своих собственных платформах в режиме реального времени, тем самым гарантируя их собственное преимущество в низкой цене; скальперы могут в режиме реального времени запрашивать источник номера, регистрировать номер как можно скорее после его выделения и т. д.

1.2 Меры против MITM

Поскольку MITM сам по себе представляет определенные риски для бизнеса, как его можно избежать в обычных обстоятельствах?

• использовать mTLS Выполните двустороннюю аутентификацию.
• использовать SSL Pinning Проверьте привязку доменного имени и сертификата.
• Проверьте, есть ли сеть пользователяиспользоватьактерское мастерствоили VPN (Банк APP обычно используется).
• Дайте вашему бизнесу еще один уровень шифрования,использовать частную ссылку для передачи.

Суть mTLS заключается в двусторонней аутентификации сертификатов клиента и сервера, которую обычно можно решить в сценариях приложений. Однако реальный бизнес обычно требует полной поддержки. В сценариях апплетов H5/Web и WeChat нет полномочий. получить информацию о сертификате. SSL Pinning также имеет аналогичные проблемы. Независимо от того, mTLS или SSL Pinning обычно полагается на системный API, предоставляемый операционной системой при проверке сертификатов, а системный API легко обойти с помощью таких инструментов, как Xposed и Frida. Метод проверки пользовательского агента также не очень надежен, и его решение по-прежнему зависит от системного API. Аналогично, злоумышленники также могут использовать виртуальную сетевую карту Tun для его обхода.

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

02. Двухуровневая архитектура.

Трафик, проходящий через шлюз, представляет собой трафик HTTP (уровень L7). Стандартный HTTP-запрос состоит из трех частей: строка запроса (строка запроса), заголовок запроса (заголовок запроса) и тело сообщения запроса (тело запроса HTTP): Там; состоит из трех частей: статус ответа (строка состояния), заголовок ответа (Response Header) и тело ответного сообщения (Response Body).

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

Если вы напрямую зашифруете каждую часть запроса, зашифруете ее и перешлете непосредственно на шлюз, а шлюз точно так же ее расшифровает, то, похоже, вы сможете решить проблему, с которой столкнулись. Однако напрямую зашифрованный и перенаправленный запрос не является стандартным HTTP, поэтому для обработки запрошенный трафик понижается с уровня L7 до уровня L4. Также очень разумно использовать L4 для сценариев приложений. Однако сценарии H5/Web ограничены. Современные браузеры по-прежнему не поддерживают соединения Raw Socket, что затрудняет унификацию дизайна приложения и архитектуры H5/Web.

2.1 Инкапсуляция бизнес-трафика

Независимо от приложения, H5/Web или апплета WeChat, поддерживаются HTTP-запросы. Для этого необходимо разработать нашу архитектуру, а нижний уровень также необходимо реализовать на основе HTTP. По соображениям безопасности, а также для того, чтобы строки бизнес-запросов, заголовки запросов и тела сообщений запросов были зашифрованы, более целесообразно использовать метод передачи HTTP в HTTP. Информация о строке бизнес-запроса, заголовки и тело сообщения шифруются и помещаются в тело сообщения частного канала перед пересылкой, а затем объединяются с некоторыми методами сериализации (например, буферами протокола) для сжатия данных запроса, что может обеспечить более высокую производительность. , и может иметь меньшую длину передачи.

Для разных типов клиентов можно использовать дистрибутив SDK для интеграции их в бизнес. Бизнес-клиент использует SDK для выполнения HTTP-запросов, а SDK завершает шифрование запроса. Кроме того, бизнес-SDK также может добавлять скрытую информацию. При возникновении сбоя в работе проблему можно обнаружить более своевременно, объединив журнал и механизм оповещения.

2.2 Ранний архитектурный дизайн

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

клиент HTTP -> шлюз SDK -> Модуль шифрования и дешифрования -> шлюзовой кластер (нижний уровень Посланник, обычно соответствует DownStream）-> Бизнес-услуги по возвращению к месту происхождения (часто называемые Upstream）

Модуль шифрования и дешифрования требует много CPU операция по обработке бизнес-запросов, поэтому она больше подходит для развертывания кластера во время развертывания, если конфигурация разумна. HPA Это может в основном удовлетворить потребности бизнеса. Кроме CPU Кроме того, необходимо учитывать некоторые особые сценарии. Например, в сценарии флэш-продажи бизнес-услуги могут увеличить время, необходимое для обработки запросов, из-за увеличения нагрузки. Увеличение затрат времени также означает накопление количества подключений в сети; короткий период времени, а количество запросов за короткий период времени может произойти в дальнейшем и может в конечном итоге привести к полному отказу в обслуживании из-за перегрузки одного канала связи. вверх по течению В этом случае увеличение затрат времени может привести к катастрофическим последствиям, Запросы модулей шифрования и дешифрования к шлюзовому кластеру необходимо объединить в пул.,Максимально повторно используйте соединения, а также настройте соответствующие таймауты и время сохранения соединения;,Быстро отклоняйте неудачные запросы, чтобы оптимизировать этот сценарий. Для запросов, превышающих максимальное количество соединений в пуле,Должны ли мы напрямую отклонить или удалить предыдущие связи?,Его также необходимо рассматривать в сочетании с реальными бизнес-сценариями.

Двухуровневая архитектура хорошо адаптирована к ранним бизнес-сценариям, но у нее есть и некоторые недостатки:

• В модуле шифрования и дешифрования отсутствуют необходимые проверки работоспособности и логика «все-смерть-все-живые».
• Модуль шифрования и Информация мониторинга дешифрования не является достаточно полной, а бизнес-показатели нуждаются в активной регистрации. Прометей для добавления новых индикаторов требует перепубликации сервиса;
• Увеличение затрат на ресурсы и затраты на техническое обслуживание.

В сцене двухслойной архитектуры Архитектура, Модуль шифрования и дешифрования служит первым прыжком всего индивидуального канала и первым принимает на себя основную тяжесть в сценариях с высоким уровнем параллелизма. Однако производительность шифрования и дешифрования и количество соединений не являются его главными узкими местами, с одной стороны, Модуль; шифрования и дешифрованияиспользовать Go Сопрограммы обрабатывают каждый запрос, и его производительность может быть гарантирована, кроме того, Go; C10k Давно это не проблема, но Модуль шифрования и дешифрования по запросу в качестве клиента IP Исправлено. На основании четверного соединения видно, что запрошенный локальный порт может быть переполнен из-за ненормальных условий, что приводит к невозможности создания новых запросов. Однако с вышеуказанной гарантией объединения в пул нет необходимости слишком беспокоиться. .

03. Проектирование одноуровневой архитектуры

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

В одноуровневой архитектуре трафик, фактически обрабатываемый Envoy, является внешним трафиком HTTP в HTTP, то есть трафиком частной ссылки, поэтому необходимо решить следующие вопросы:

• Envoy Как интегрировать Модуль шифрования и дешифрования？
• Посланник по каждому индивидуальному запросу,Как парсить бизнес-поток запроса на прикрытие приватной ссылки;,Собираетесь заменить поток частных ссылок бизнес-потоком?
• Как гарантировать, что процесс дешифрования после запроса будет выполнен до ограничения частоты и другой логики,Выполняется ли процесс шифрования после возврата после ограничения частоты и прочей логики?

Кроме того, из-за использования HTTP в HTTP файлы cookie и междоменная информация исходного бизнеса также должны учитываться для внутреннего трафика:

• Как обеспечить нормальное выполнение бизнес-файла Set-Cookie в условиях частной связи.
• Как правильно обрабатывать междоменные бизнес-заголовки (например, Access-Control-Allow-Origin, Access-Control-Allow-Headers и т. д.) и т. д.

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

3.1 Перехватчик посланника

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

Lua Filter Сама реализация относительно легка и часто используется для обработки некоторых простых бизнес-сценариев. Однако из-за Envoy Многое само по себе Worker Механизм обработки нитей, каждый Worker У каждого свой Lua среду выполнения, что приводит к Lua Filter Реальных глобальных переменных не существует. Кроме того, Луа Filter При обработке каждого запроса он выполняется синхронно. Если вам нужно выполнить какую-то сеть. IO операция приведет к Envoy Производительность существенно падает. Таким образом, шлюз можно комбинировать с использованием только при небольшом количестве запросов на модификацию или при чрезвычайно высоких требованиях к производительности. Lua Fitler。

External Processing Фильтр (далее именуемый gRPC перехватчик) предоставил gRPC Интерфейс предназначен для удаленного вызова и может динамически изменять практически все запрошенные и возвращаемые данные. Это именно то, что необходимо в таких сценариях, как частные каналы. gRPC Перехватчик разделит запрос на 4 индивидуальный gRPC серийный вызов

• ProcessingRequest_RequestHeaders, обработка заголовка запроса.
• ProcessingRequest_RequestBody — обработка тела запроса.
• ProcessingRequest_ResponseHeaders возвращает обработку заголовка.
• ProcessingRequest_ResponseBody возвращает обработку тела.

После поступления запроса на индивидуальное шифрование на шлюз он сначала будет получен RequestHeaders новости для RequestHeaders Обработка будет относительно простой. Определите, является ли это обнаружением. OPTIONS Или внутренняя проверка работоспособности, если да, верните напрямую 204, затем по запросу; Origin Просто динамически возвращайте заголовки, необходимые для разных доменов. Тело запроса Он содержит полную информацию о запросе бизнеса и должен быть расшифрован, прежде чем продолжить. HTTP Parser Получите строку бизнес-запроса, заголовок запроса и тело сообщения, затем используйте проанализированную информацию для перезаписи заголовка запроса и тела сообщения после перехода на один уровень Envoy; Он действует как первый переход всей ссылки, и запрошенный X-Forwarded-For Переписано как Remote адрес, чтобы предотвратить возможность подделки. Возвращаемый заголовок в основном такой же, как заголовок запроса. Единственное отличие состоит в том, что. Set Cookie Поддерживает несколько отдельных полей, которые необходимо объединить здесь. дело с.для ResponseBody Перед возвратом его необходимо переупаковать и зашифровать; поскольку код состояния бизнеса может быть ненормальным, а сама частная ссылка должна возвращаться нормально, код состояния бизнеса здесь нельзя скопировать в частную ссылку, чтобы избежать ненормального прерывания работы. запрос.

3.2 Порядок перехватчиков

использовать gRPC Перехватчик решает проблему шифрования и дешифрования потоков, но это слишком Filter Вопрос о сотрудничестве еще требует решения. посланник Во время запроса порядок выполнения перехватчиков — сверху вниз; обработка возврата — наоборот, снизу вверх.

Поэтому при запросе пройдите Lua Request Предварительная обработка, частная ссылка gRPC Затем перехватчик расшифровывает трафик, и когда расшифрованный трафик повторно отправляется на водонепроницаемую стену с ограничением частоты, это уже бизнес-данные. На обратном пути проехали по той же дороге Lua Reponse Предварительная обработка, затем использование частной ссылки gRPC Перехватчик инкапсулирован, поэтому вся ссылка открывается.

04. Резюме

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

-End-

Автор оригинала｜Ли Хаоюй