我正在使用代理来请求后端与支付相关的API。 API 代理请求是使用 HTTP 协议发出的。 发出 API 请求时会传递用户敏感数据。
对于HTTP请求，我了解它们是以未加密的纯文本形式传递的，所以我担心没有安全风险。
我想知道我的担心是否正确，或者是否存在其他安全风险。
谢谢您的回复。
使用 HTTP 代理进行 API 请求，尤其是支付等敏感操作，确实会带来一些安全风险。
[ Client ] --(HTTP)--> [ Proxy Server ] --(HTTP)--> [ Payment API ]
| |
Unencrypted Unencrypted
Data Transfer Data Transfer
由于 HTTP 未加密，因此服务器和代理之间以及代理和 API 之间传输的数据可能会被攻击者拦截。
攻击者可能会拦截并更改正在发送或接收的数据，从而导致欺诈性交易或数据盗窃（中间人攻击）。
如果代理或网络遭到破坏，信用卡号、个人详细信息等敏感信息可能会被泄露。
如果没有加密，就没有简单的方法来确保数据在传输过程中不被篡改。
使用 HTTP 可能违反监管要求，例如支付卡行业数据安全标准 (PCI DSS)。
更安全的设置是将所有通信切换到 HTTPS。这对传输中的数据进行加密，使其更加安全。 HTTPS 使用 SSL/TLS 提供加密、身份验证和完整性。
[ Client ] --(HTTPS)--> [ Proxy Server ] --(HTTPS)--> [ Payment API ]
| |
Encrypted Encrypted
Data Transfer Data Transfer
例如，使用 Go:
// Example in Go: Sending an HTTPS request
package main
import (
"crypto/tls"
"net/http"
)
func main() {
// Configure HTTPS transport
tr := &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: false},
}
client := &http.Client{Transport: tr}
// Make HTTPS request
resp, err := client.Get("https://your-proxy-server.com/payment-api")
// Handle resp and err
}
请注意，我经常在企业中看到 HTTPS 代理和后端服务之间的 HTTP 流量。
这通常是由于网络架构中的设计选择造成的，称为代理级别的 SSL/TLS 终止。
[ Client ] --(HTTPS)--> [ HTTPS Proxy ] --(HTTP)--> [ Backend Service ]
| SSL/TLS termination
| Decryption of data
SSL/TLS加密和解密是资源密集型的。通过将此任务卸载到代理，后端服务可以减轻这种开销，从而提高整体性能。
但主要原因是：通过在代理处处理 SSL/TLS，您可以在一个地方管理证书、密码和 SSL/TLS 协议，而不是跨多个后端服务。
流量在代理处解密后，各种安全和监控工具就可以更有效地检查和过滤流量（在 Intranet 内）。
可以更简单地配置后端服务，无需进行复杂且容易出错的 SSL/TLS 设置。
并且，通过这个模型，我看到了像 F5 这样的 反向代理，它允许：
警告：该架构假定一个安全的内部网络，其中代理和后端服务之间的 HTTP 流量较少受到外部威胁。
然而，这确实暴露了内部威胁的风险。如果内部网络受到威胁，未加密的 HTTP 流量可能会被拦截。
对于某些类型的数据（例如支付信息或个人数据）来说，这不是一个好的模型，法规可能需要端到端加密，这意味着在到达后端服务的整个过程中保持数据加密。
这意味着，特别是在需要端到端加密的情况下，将使用 SSL/TLS 直通。这里，代理不会解密流量；相反，它将加密的数据直接传递到后端服务，然后由后端服务处理解密。
[ Client ] --(HTTPS)--> [ HTTPS Proxy ] --(HTTPS)--> [ Backend Service ]
| SSL/TLS passthrough
| No decryption of data
在这种情况下，后端服务必须能够处理 SSL/TLS 加密和解密。该设置增强了安全性，但增加了后端服务的复杂性和资源使用量。