云開發(fā)網(wǎng)關(guān)技術(shù)架構(gòu)演進
共 7410字，需瀏覽 15分鐘
·
2024-07-23 08:45
??目錄
1 引言
2 雙層架構(gòu)設計
3 單層架構(gòu)設計
4 總結(jié)
01
全球使用 HTTPS 網(wǎng)站已經(jīng)超過了 9 成，HTTPS 本身使用 TLS 對業(yè)務請求的流量已經(jīng)進行加密，以現(xiàn)有的 TLS1.2/1.3 的加密強度和當前的算力來講，暴力破解可以說幾無可能。那么網(wǎng)關(guān)使用私密鏈路再次對業(yè)務流量加密，是否有必要呢？其實是有必要的，針對 HTTPS 攻擊者可以使用 MITM 來獲取客戶端和服務器傳入流量。
通過 MITM 來解密 HTTPS 的流量，需要客戶端去信任中間人頒發(fā)的第三方根證書；而安裝根證書本身有一些門檻。所以，在常見的攻擊方式中，攻擊者通常并不會使用這種方式。一是這種攻擊條件通常需要攻擊者和被攻擊者在同一個局域網(wǎng)下，二是信任攻擊者的根證書需要被攻擊者配合，同時也需要管理員或者 root 權(quán)限。使用 MITM 苛刻條件使這種方式在實際的攻擊中并不常見，更多的則是使用 Msfvenom 生成載荷，來誘騙被攻擊者執(zhí)行，從而獲取機器的權(quán)限。既然 MITM 很難直接被利用，是不是在我們業(yè)務場景就可以忽略這種安全風險呢？在一般的業(yè)務中，確實可以認為使用 HTTPS 就已經(jīng)達到了安全的需求，而在一些對安全場景要求較高的領(lǐng)域，只使用 HTTPS 還是不夠的。比如，電商平臺的價格、掛號平臺的號源信息；競對可以通過 MITM 方式實時監(jiān)聽友商的商品價格，做到自己平臺價格的實時調(diào)整，從而保證自己的低價優(yōu)勢；黃?？梢詫崟r查詢號源，在放號后第一時間進行掛號等等。
既然 MITM 本身對業(yè)務來說存在一定的風險，通常情況下該怎么避免呢？
使用 mTLS 進行雙向認證。
使用 SSL Pinning 做域名和證書的綁定校驗。
檢查用戶網(wǎng)絡是否使用代理或者 VPN（銀行 APP 常用）。
對業(yè)務再做一層加密，使用私密鏈路進行傳輸。
mTLS 的本質(zhì)是客戶端和服務端證書的雙向認證，在 APP 場景下通?？梢赃@么解決，然而真實的業(yè)務一般都要求全端支持，H5/Web、微信小程序的場景下，并沒有權(quán)限獲取到證書的信息。SSL Pinning 同樣有類似的問題。無論 mTLS 或者 SSL Pinning 在校驗證書的時候通常都依賴操作系統(tǒng)提供的系統(tǒng) API 進行校驗，而系統(tǒng) API 很容易使用 Xposed、Frida 等工具進行繞過。通過檢查用戶代理的方式同樣也不那么可靠，其判斷的依據(jù)仍然依賴系統(tǒng) API，同樣，攻擊者也可以使用 Tun 虛擬網(wǎng)卡的方式繞過。
使用私密鏈路對業(yè)務數(shù)據(jù)進行一次加密，可以很好的解決上面的問題，而且具有更好的兼容性和擴展性；即使是多端的場景，使用同一套解決方案也可以很好的處理。私密鏈路除了帶來鏈路的安全性，也可以隱藏服務端的真實業(yè)務，一些自動化爬蟲和攻擊腳本由于不清楚私密鏈路的具體協(xié)議，對應的請求會被網(wǎng)關(guān)直接拒絕掉。
02
經(jīng)過網(wǎng)關(guān)的流量都是 HTTP （L7 層）流量，一個標準的 HTTP 請求包含：請求行（Request line）、請求頭部(Request Header)、請求消息體（Request Body）三個部分；HTTP 返回包含：響應狀態(tài)（Status line）、響應首部（Response Header）、響應消息體（Response Body）三個部分。
在實際業(yè)務中，一些客戶會使用 URL 參數(shù)來實現(xiàn)自己的簽名等鑒權(quán)敏感信息，還有一些客戶會將敏感信息放到請求的頭部中去。如果只對請求的消息體進行加密，用戶的鑒權(quán)信息仍然可能被攔截和篡改。這就要求網(wǎng)關(guān)不但要保護請求的消息體，也要對請求的頭部和請求行進行保護；同樣的對于業(yè)務的返回響應狀態(tài)、響應首部、響應消息體也要進行保護。
如果直接對請求的各個部分進行加密處理，加密后直接轉(zhuǎn)發(fā)到網(wǎng)關(guān)，網(wǎng)關(guān)以同樣的方式進行解密，似乎就可以解決面臨的問題。但是，直接加密轉(zhuǎn)發(fā)的請求并不是一個標準的 HTTP，那么請求的流量從 L7 層也就降級到了 L4 層處理。針對 APP 這種場景使用 L4 也十分合理，不過 H5/Web 的場景卻受到了限制，現(xiàn)代瀏覽器仍然不支持 Raw Socket 的連接，這就會導致 APP 的設計和 H5/Web 的架構(gòu)很難統(tǒng)一。
無論 APP，H5/Web 還是微信小程序，都支持 HTTP 的請求。這就要求我們的架構(gòu)設計，底層也需要基于 HTTP 來實現(xiàn)。出于安全性的考慮，又需要對業(yè)務的請求行、請求頭部、請求消息體進行加密，那么使用 HTTP in HTTP 的傳輸方式就更加合適。將業(yè)務的請求行信息、頭部和消息體經(jīng)過加密后放到私密鏈路的消息體后再進行轉(zhuǎn)發(fā)，再結(jié)合一些序列化方式（比如：Protocol Buffers）來壓縮請求數(shù)據(jù)，即可以保證較高的性能，又可以有較小傳輸長度。
針對不同類型客戶端，可以采用分發(fā) SDK 的方式集成到業(yè)務。業(yè)務的客戶端使用 SDK 去調(diào)用 HTTP 請求，由 SDK 來完成請求的加密。除此之外，業(yè)務的 SDK 還可以添加埋點信息，在出現(xiàn)業(yè)務故障時，結(jié)合日志、告警機制可以更及時的發(fā)現(xiàn)問題。
轉(zhuǎn)發(fā)到網(wǎng)關(guān)的流量需要解密后才能做進一步的處理，因此在早期的設計方案中。最先考慮的也是添加一層加解密模塊的方式來處理。對應設計為：
客戶端 HTTP -> 網(wǎng)關(guān) SDK -> 加解密模塊 -> 網(wǎng)關(guān)集群（底層 Envoy，通常對應 DownStream）-> 回源業(yè)務服務（通常稱為 Upstream）
加解密模塊需要大量的 CPU 運算來處理業(yè)務的請求，因此在部署的時候更適合集群部署，只要配置合理的 HPA 就基本可以滿足業(yè)務的需要。除了 CPU 外，還需要考慮一些特殊場景，比如：秒殺的場景下，業(yè)務服務可能因為負載增加，導致請求的耗時增加；耗時的增加也意味短時間內(nèi)連接數(shù)的積累，而短時間的請求數(shù)可能會進一步增加，最終可能會導致鏈路的某一環(huán)超過負載而徹底拒絕服務。Upstream 的耗時增加可能會帶來災難性的后果，針對這種場景，加解密模塊到網(wǎng)關(guān)集群的請求需要做池化處理，要盡可能的復用連接；同樣也要配置合適的超時時間和連接保持時間，對于已經(jīng)失敗的請求要快速失敗來優(yōu)化這種場景。對于超出連接池最大數(shù)量的請求，是直接拒絕還是移除掉較早的連接，同樣需要結(jié)合業(yè)務實際的場景來考慮。
兩層的架構(gòu)很好的適應了早期的業(yè)務場景，不過也存在一些缺陷：
加解密模塊缺少必要健康檢查和全死全活邏輯
加解密模塊監(jiān)控信息不夠完善，業(yè)務指標需要主動注冊 Promtheus；添加新的指標需要重新發(fā)布服務
增加了資源成本和維護成本
在雙層架構(gòu)的場景下，加解密模塊充當整個鏈路的第一跳，在高并發(fā)場景下是首當其沖的。不過加解密的性能、連接數(shù)并不是其主要的瓶頸；一方面加解密模塊采用 Go 協(xié)程來處理每個請求，其性能可以有很好的保證；另外，Go C10k 早就不是問題，反而是加解密模塊作為客戶端請求時，其 IP 固定，基于連接的四元組可知，請求的本地端口可能因為異常情況而占滿，導致無法創(chuàng)建新的請求，不過有上述的池化保證，也不需要太過擔心。
03
網(wǎng)關(guān)的底層采用了開源的 Envoy 來進行流量的轉(zhuǎn)發(fā)，而 Envoy 本身就有豐富的監(jiān)控信息以及完善的健康檢查邏輯。那么是否可以將加解密模塊合并到 Envoy 呢？完全可以，不過一些技術(shù)難點需要解決。在雙層架構(gòu)中，Envoy 處理的流量就是業(yè)務的流量，因此可以根據(jù)某些頭部做集中式限頻，動態(tài)的增加和刪除某些頭部，或者根據(jù)某些信息添加風險等級。
在單層架構(gòu)中，Envoy 實際處理的流量是 HTTP in HTTP 的外層流量，即私密鏈路的流量，因此需要解決以下問題：
Envoy 怎么集成加解密模塊？
Envoy 對每個請求，怎么解析出業(yè)務流量后；覆蓋私密鏈路的請求，即將私密鏈路流量替換成業(yè)務流量？
如何保證請求后的解密流程在限頻等邏輯之前執(zhí)行，返回后的加密流程在限頻等邏輯之后執(zhí)行？
除此之外，由于采用 HTTP in HTTP，還要考慮原業(yè)務的 cookie、跨域信息在內(nèi)層流量：
怎樣保證私密鏈路情況下，業(yè)務 Set-Cookie 可以正常執(zhí)行。
如何正確處理業(yè)務跨域頭部（比如：Access-Control-Allow-Origin、Access-Control-Allow-Headers 等）等等。
單層架構(gòu)也是一個云開發(fā)各類網(wǎng)關(guān)統(tǒng)一架構(gòu)演進的方向，因此除了要考慮私密鏈路的場景，針對一些公網(wǎng)直接訪問以及 WebSocket 的場景也要進行兼容。
Envoy 提供了多種攔截器（Envoy Filter），可以動態(tài)的過濾、修改、監(jiān)聽某些字段，通過 Envoy Filter 可以實現(xiàn)更為復雜的業(yè)務邏輯。比較常用的攔截器有 Lua Filter、External Processing Filter 等。
Lua Filter 本身實現(xiàn)較為輕量，經(jīng)常用于處理一些簡單的業(yè)務場景。不過，由于 Envoy 本身是多 Worker 線程處理機制，每個 Worker 都有自己的 Lua 執(zhí)行環(huán)境，這也就導致 Lua Filter 沒有真正意義上的全局變量。另外，Lua Filter 在處理每個請求的時候都是同步執(zhí)行的，如果需要執(zhí)行一些網(wǎng)絡 IO 操作，就會導致 Envoy 的性能大幅下降。所以，網(wǎng)關(guān)只會在少量修改請求或者對性能要求極高的時候才會結(jié)合使用 Lua Fitler。
External Processing Filter（以下簡稱 gRPC 攔截器） 提供了 gRPC 接口供遠程調(diào)用，可以動態(tài)的修改請求和返回的幾乎所有數(shù)據(jù)，這正是網(wǎng)關(guān)私密鏈路這種場景所需要的。gRPC 攔截器會將一個請求拆成 4 個 gRPC 串行調(diào)用
ProcessingRequest_RequestHeaders，請求頭部處理。
ProcessingRequest_RequestBody，請求 Body 處理。
ProcessingRequest_ResponseHeaders，返回頭部處理。
ProcessingRequest_ResponseBody，返回 Body 處理。
一個加密的請求到網(wǎng)關(guān)之后，首先會接收到 RequestHeaders 消息，對于 RequestHeaders 處理會比較簡單，判斷是否為探測 OPTIONS 或內(nèi)部健康檢查，如果是則直接返回 204；再根據(jù)請求的 Origin 動態(tài)的返回跨域所需要的頭部即可。RequestBody 攜帶了業(yè)務的完整請求信息，需要先解密再做 HTTP Parser 獲取業(yè)務請求行、請求頭部和消息體；然后將解析后的信息，覆蓋掉請求的頭部和消息體；改為單層網(wǎng)關(guān)后，Envoy 就充當了整個鏈路的第一跳，還需要把請求的 X-Forwarded-For 復寫為 Remote 地址來防止偽造的可能。返回的頭部和請求的頭部處理基本一樣，一個不同點就是 Set Cookie 支持多個字段，這里需要合并處理。對于 ResponseBody 需要重新打包加密后再進行返回；由于業(yè)務的狀態(tài)碼可能存在異常，而私密鏈路本身是應該正常返回，所以這里并不能業(yè)務的狀態(tài)碼復寫到私密鏈路，以免請求異常中斷。
使用 gRPC 攔截器解決了流量加解密的問題，不過多個 Filter 的協(xié)作仍然需要處理。Envoy 在請求的時候，執(zhí)行的攔截器的順序是自上而下；返回的處理恰好相反，自下而上。
因此，在請求的時候先經(jīng)過 Lua Request 的預處理，私密鏈路的 gRPC 攔截器再進行解密，解密后的流量重新發(fā)到限頻/防水墻的時候，已經(jīng)是業(yè)務的數(shù)據(jù)了。在返回的時候同樣經(jīng)過 Lua Reponse 的預處理，再使用私密鏈路的 gRPC 攔截器進行封裝，這樣整個鏈路就打通了。
04
通常增加一層中間層可以解決業(yè)務所遇到的問題，不過增加一層映射也帶來新的問題；增加中間層同樣需要計算資源的支撐，為了高可用勢必需要增加多副本，這就降低了整個系統(tǒng)的 ROI。在網(wǎng)關(guān)這個場景下，通過合并加解密層到網(wǎng)關(guān)接入層，由雙層架構(gòu)演變成單層架構(gòu)，網(wǎng)關(guān)的架構(gòu)進一步統(tǒng)一，日志、監(jiān)控、告警也可以直接復用；在當前大背景下反而是一個更優(yōu)解。
????歡迎加入騰訊云開發(fā)者社群，享前沿資訊、大咖干貨，找興趣搭子，交同城好友，更有鵝廠招聘機會、限量周邊好禮等你來~
（長按圖片立即掃碼）