图源：Unsplash。HTTPS 不是合规的全部，但它通常是 Web 场景数据传输加密的最低入口。
很多企业讨论数据安全时，会把问题压缩成一句话：我们的网站是不是必须上 HTTPS？这个问题看似简单，实际包含三层不同的判断。第一层是技术判断：HTTP 与 HTTPS 在传输链路上到底差什么，证书在其中起什么作用。第二层是法律判断：法律法规是否直接要求“必须 HTTPS”，还是要求采取加密、访问控制、安全认证等技术措施。第三层是合规证明判断：当发生数据泄露、监管检查、等保测评、密评、个人信息保护审计或境外监管问询时，企业能否证明自己的传输加密措施与数据风险相匹配。
结论可以先放在前面：在今天的互联网业务中，仍然使用明文 HTTP 传输登录凭证、个人信息、交易数据、重要数据、内部管理数据或接口调用数据，通常已经很难被解释为“采取了合理安全措施”。中国法律并不总是逐字写明“所有网站必须使用 HTTPS”，但《网络安全法》《数据安全法》《个人信息保护法》《网络数据安全管理条例》《密码法》及商用密码制度，已经共同构成了对传输加密的强约束。香港《个人资料（私隐）条例》下的第4保障资料原则要求采取所有切实可行步骤并特别考虑资料的安全传送。欧盟 GDPR 第32条也把个人数据加密列为可选但非常关键的适当技术和组织措施。换言之，HTTPS 不是法律条文中的唯一答案，却往往是 Web 服务满足“传输安全”的基础答案。
一、先把技术边界讲清楚：HTTP、HTTPS、TLS 和证书分别是什么
HTTP 是应用层协议，负责定义浏览器和服务器之间如何请求、响应、提交表单、传递 Cookie、下载资源。传统 HTTP 本身不提供加密、身份认证和完整性保护。只要网络链路中存在可观察者，例如公共 Wi-Fi、运营商链路、企业网关、恶意代理、被入侵的路由器或同网段攻击者，HTTP 报文中的 URL、请求头、Cookie、表单字段、返回内容都可能被读取、复制、篡改或重放。
HTTPS 不是另一个业务协议，而是 HTTP over TLS。它把 HTTP 报文放进 TLS 建立的安全通道里传输。TLS 的目标可以概括为三件事：服务器身份认证、传输内容保密、传输内容完整性。IETF RFC 8446 对 TLS 1.3 的表述也很直接：TLS 让客户端和服务器应用能够通过互联网通信，并防止窃听、篡改和消息伪造。NIST SP 800-52 Rev.2 则把 TLS 定位为保护互联网电子传播中数据的机制，并要求美国政府 TLS 服务器和客户端支持 TLS 1.2，同时要求支持 TLS 1.3。
证书是 TLS 服务器身份认证的核心材料。浏览器访问 https://example.com 时，服务器会出示证书链，证明“我确实是这个域名对应的服务”。浏览器会检查证书是否由受信任的 CA 签发、域名是否匹配、证书是否过期、签名算法是否安全、证书链是否完整、是否被吊销或存在其他风险。只有这些检查通过，后续密钥协商和加密通信才有可信基础。
| 概念 | 解决的问题 | 不解决的问题 |
|---|---|---|
| HTTP | 定义 Web 请求和响应格式 | 不加密、不认证服务器身份、不防篡改 |
| HTTPS | 在 TLS 安全通道上传输 HTTP | 不自动保证后端数据库、日志、终端设备安全 |
| TLS | 提供认证、机密性、完整性 | 不决定业务是否过度收集数据 |
| 服务器证书 | 证明服务器域名身份，支持密钥协商 | 不证明企业合规，也不证明网站内容可信 |
| HSTS | 强制浏览器后续使用 HTTPS | 首次访问、子域配置、证书运维仍需正确处理 |
| 双向 TLS | 同时认证客户端和服务器 | 不替代账号权限、审计和业务授权 |
因此，企业不能把“买了证书”理解为“已经完成数据安全”。证书只是安全通道的身份证件，HTTPS 只是传输层保护。真正的合规还需要覆盖数据分类分级、接口鉴权、访问控制、日志脱敏、密钥管理、备份、终端安全、供应商管理和事件响应。
二、HTTP 明文传输的合规风险：问题不只是“被看见”
图源：Unsplash。HTTP 明文传输的风险不只在用户侧，也在接口、网关、代理和日志链路中。
明文 HTTP 的风险至少有四类。
第一是窃听风险。登录账号、密码、验证码、访问令牌、Cookie、身份证号、手机号、地址、订单、病历、金融信息、企业内部工单等，一旦通过 HTTP 传输，就可能被网络路径上的攻击者获取。对个人信息而言，这会直接落入“未经授权访问、泄露、丢失”的风险框架；对重要数据、商业秘密和内部系统数据而言，则可能演变为数据安全事件、供应链攻击或内网横向移动入口。
第二是篡改风险。攻击者可以修改返回页面、注入脚本、替换下载文件、篡改接口返回值。即便传输内容本身不包含个人信息，HTTP 也可能让用户下载到被篡改的软件包、配置文件或前端脚本，进而造成更严重的数据泄露。
第三是身份冒充风险。HTTP 没有可靠的服务器身份认证。用户以为自己访问的是企业官网，实际上可能被 DNS 劫持、网关劫持或恶意代理导向仿冒页面。证书错误、域名不匹配、过期证书被忽视，都会削弱用户对真实服务的判断能力。
第四是合规举证风险。安全事件发生后，监管和审计通常不会只问“有没有被攻击”，还会问“为什么这类数据没有加密传输”“为什么没有采取合理措施”“为什么没有及时发现和处置”。当行业普遍已经使用 HTTPS，浏览器也对 HTTP 标记“不安全”时，继续明文传输高风险数据，很难证明其安全措施符合技术发展水平和风险程度。
| 传输内容 | HTTP 风险 | 合规判断 |
|---|---|---|
| 静态公开页面 | 主要是篡改、钓鱼、注入风险 | 仍建议 HTTPS，尤其是官网、下载页、政策页 |
| 登录凭证、Cookie、Token | 窃听后可直接接管账户 | 应使用 HTTPS，并配合 Secure Cookie、HttpOnly、SameSite、会话过期 |
| 个人信息表单 | 泄露后影响个人权益 | 应使用 HTTPS，敏感个人信息还要强化权限和日志控制 |
| 支付、交易、金融信息 | 可能造成财产损失和身份冒用 | 应使用 HTTPS，并按行业要求做更高强度控制 |
| API 与移动端通信 | Token、设备信息、业务数据可被截获 | 应使用 HTTPS，必要时证书绑定、签名、防重放 |
| 内部管理后台 | 被截获后可能扩大为系统入侵 | 应使用 HTTPS、VPN/零信任、MFA、访问白名单 |
三、中国法下的传输加密：从“合理措施”走向“明确义务”
图源：Taylor Vick / Unsplash。数据传输加密不是孤立配置，而是网络、系统、应用和数据安全架构的一部分。
中国法对传输加密的要求不是单一条文，而是由网络安全、数据安全、个人信息保护、商用密码和行业监管共同组成。
《网络安全法》第二十一条确立网络安全等级保护制度，并要求网络运营者履行安全保护义务，防止网络数据泄露、被窃取、被篡改。其中明确包括采取数据分类、重要数据备份和加密等措施。第二十二条还要求网络产品、服务符合相关国家标准的强制性要求。虽然这不是“所有网站必须 HTTPS”的表达，但它把加密纳入网络运营安全义务，特别是当网络承载个人信息、重要业务或较高等级保护对象时，加密不再是可有可无的优化项。
《数据安全法》第二十七条要求开展数据处理活动的主体建立全流程数据安全管理制度，组织教育培训，并采取相应技术措施和其他必要措施保障数据安全；通过互联网等信息网络开展数据处理活动的，还应当在网络安全等级保护制度基础上履行数据安全保护义务。这里的“传输”本身属于数据处理活动的一部分。企业不能只保护数据库静态存储，而忽视浏览器、App、API、消息队列、供应商接口之间的数据流。
《个人信息保护法》第五十一条更直接。个人信息处理者应当根据处理目的、处理方式、个人信息种类、对个人权益的影响和可能存在的安全风险，采取措施防止未经授权访问以及个人信息泄露、篡改、丢失，其中包括采取相应的加密、去标识化等安全技术措施。对 Web 或 App 场景而言，如果个人信息在用户与服务器之间传输，HTTPS/TLS 通常就是“相应加密措施”的基本组成。
2025 年 1 月 1 日施行的《网络数据安全管理条例》进一步把要求细化到网络数据处理者。第九条要求网络数据处理者在网络安全等级保护基础上，加强网络数据安全防护，建立安全管理制度，采取加密、备份、访问控制、安全认证等技术措施和其他必要措施，保护网络数据免遭篡改、破坏、泄露或者非法获取、非法利用。它把加密、备份、访问控制和安全认证并列，说明监管关注的不是单个开关，而是“数据不被非法获取和利用”的整体能力。
| 国内依据 | 与传输加密相关的核心要求 | 对 HTTP/HTTPS 的含义 |
|---|---|---|
| 《网络安全法》第21条 | 等保义务、数据分类、重要数据备份和加密 | 对承载网络数据的系统提出加密和防泄露要求 |
| 《数据安全法》第27条 | 全流程数据安全制度和技术措施 | 传输是数据处理链路，不能只做存储安全 |
| 《个人信息保护法》第51条 | 采取加密、去标识化等措施防止泄露、篡改、丢失 | 个人信息表单、接口、后台应使用 HTTPS/TLS |
| 《网络数据安全管理条例》第9条 | 加密、备份、访问控制、安全认证等技术措施 | 明确把加密作为网络数据安全防护基本措施 |
| 《密码法》及商用密码制度 | 规范商用密码应用，重要网络与信息系统需密评 | 关键系统不能只“用了 TLS”，还要看密码合规性、正确性、有效性 |
| 行业监管规则 | 金融、医疗、政务、关基等通常有更高要求 | HTTPS 是底线，可能还需国密、专线、双向认证、密钥托管规范 |
四、国家标准与技术基线：GB/T 22239、GB/T 39786、GB/T 35273 如何落到 HTTPS
国家标准在合规中有两个作用。第一，它们把法律中的“必要措施”“相应技术措施”具体化，便于企业落地。第二，它们在等保测评、密评、审计和监管问询中常被用作判断依据。
GB/T 22239-2019《信息安全技术 网络安全等级保护基本要求》是等保 2.0 的基础标准之一。它把安全要求分解到安全通信网络、安全区域边界、安全计算环境、安全管理中心、安全管理制度等层面。在“安全通信网络”中，通信传输是重要控制点。对第二级、第三级、第四级对象，标准关注通信过程中的完整性、保密性和可信验证等要求。对企业来说，如果系统已定级并开展等保建设，HTTPS/TLS、VPN、专线加密、接口签名、管理通道加密、远程运维加密，往往都会进入整改清单。
GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》则是商用密码应用的基础标准。国家密码管理局在发布说明中明确，该标准从物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全四个技术层面提出密码应用技术要求，并从管理制度、人员管理、建设运行、应急处置等方面提出管理要求。它的重点不是“有没有 HTTPS”，而是密码是否用得合规、正确、有效：算法是否合规，协议是否安全，密钥如何生成、分发、存储、更新和销毁，证书和身份认证是否可信，重要系统是否定期开展商用密码应用安全性评估。
GB/T 35273-2020《信息安全技术 个人信息安全规范》虽然是推荐性国家标准，但长期作为个人信息保护合规的重要参考。它专门把个人敏感信息的传输和存储列为章节，并在个人信息处理、委托处理、共享转让、第三方接入、跨境传输、事件处置、个人信息安全影响评估等方面提出要求。对用户注册、登录、实名、支付、定位、通信内容、健康、未成年人信息等场景，企业至少应做到 HTTPS 全站覆盖、敏感字段不出现在 URL、日志脱敏、接口鉴权、防重放、访问控制和最小化传输。
| 标准 | 关注对象 | 对传输加密的落地影响 |
|---|---|---|
| GB/T 22239-2019 等保基本要求 | 分等级保护对象 | 要求围绕通信传输、完整性、保密性、可信验证建设控制措施 |
| GB/T 39786-2021 密码应用基本要求 | 信息系统密码应用 | 关注密码算法、协议、证书、密钥管理、应用有效性和密评 |
| GB/T 35273-2020 个人信息安全规范 | 个人信息处理活动 | 对个人敏感信息传输、第三方接入、跨境传输和事件响应提供参考 |
| GB/T 43206-2023 密码应用测评要求 | 密评活动 | 用于评价密码应用是否合规、正确、有效 |
| TLS 1.2/1.3、RFC 8446、NIST SP 800-52 | 国际技术基线 | 帮助确定协议版本、套件、证书和扩展配置是否过时 |
这里要注意一个常见误区：HTTPS 默认使用国际通用密码算法和证书体系，并不自动等同于“满足商用密码应用要求”。对一般互联网业务，使用合格的 HTTPS 证书和安全 TLS 配置通常已经能显著降低传输风险；但对关键信息基础设施、重要网络与信息系统、政务、金融、电信、能源、交通等重点场景，可能需要进一步评估是否应采用经检测认证的商用密码产品、国密算法、国密 SSL/TLS、密码机、密钥管理系统、双证书体系或密评要求。
五、证书不是装上就完：证书生命周期也是合规对象
图源：Unsplash。证书的本质是身份信任链，过期、错配、私钥泄露都会破坏传输安全。
证书合规经常被低估。很多企业把证书当成运维采购事项：到期前续费，Nginx 配一下，浏览器不报错就算完成。但从安全和合规角度看，证书至少涉及以下问题。
第一，证书类型与业务场景是否匹配。DV 证书只验证域名控制权，适合多数普通网站；OV、EV 证书会增加组织身份验证，但不能替代企业信用审查。内部系统、自建客户端、设备通信、API 调用和企业间接口，可能更适合私有 CA、mTLS 或专用证书体系。
第二，证书链是否完整可信。服务器必须正确配置中间证书链，避免部分客户端无法验证。证书域名应覆盖实际访问域名，包括主域、子域、通配符域名和 CDN 回源域名。过期证书、弱签名算法、错误主机名、混合内容都会影响安全和可用性。
第三，私钥管理是否到位。私钥泄露会让攻击者冒充服务器或解密特定场景下的历史通信。私钥不应随意分发给外包、供应商和多台服务器；应控制访问权限，使用安全文件权限、密钥管理系统、硬件安全模块或云 KMS；发生泄露时应及时吊销证书并更换密钥。
第四，证书自动化是否可靠。证书生命周期缩短是行业趋势，自动签发、自动部署、自动续期、自动监控会越来越重要。一次证书过期可能造成业务中断；一次错误续期可能导致移动端 App、IoT 设备或旧客户端无法连接。
第五，证书策略是否覆盖所有入口。企业常见的问题是官网用了 HTTPS，但 API、图片域名、埋点域名、管理后台、测试环境、对象存储、Webhook、回调地址、第三方 iframe 仍然有 HTTP 或弱 TLS。合规审计不会只看首页小锁，而会看数据真实流经的入口。
| 证书治理项 | 合规风险 | 建议做法 |
|---|---|---|
| 到期管理 | 业务中断、用户绕过警告 | 建立证书台账、自动续期、到期告警 |
| 私钥保护 | 服务器被冒充、通信被攻击 | 限权、加密存储、KMS/HSM、泄露吊销流程 |
| 域名覆盖 | 子域或 API 明文暴露 | 扫描所有域名、CDN、对象存储、回调地址 |
| 协议版本 | TLS 1.0/1.1、弱套件被利用 | 禁用过时协议和弱加密套件，优先 TLS 1.2/1.3 |
| 证书链 | 客户端验证失败 | 正确配置中间证书，监控 OCSP/吊销状态 |
| 内外部证书 | 内部系统忽视加密 | 管理后台、运维通道、内部 API 同样纳入 HTTPS/mTLS |
六、TLS 配置的技术底线：不是“能访问”而是“抗攻击”
HTTPS 访问成功只说明连接可用，不说明配置足够安全。真正的 TLS 基线应关注协议版本、加密套件、密钥交换、证书签名、前向保密、HSTS、重定向、Cookie 安全属性、混合内容、客户端兼容和监控。
从当前通用实践看，面向公众互联网的服务应优先支持 TLS 1.3，同时保留安全配置的 TLS 1.2 以兼容必要客户端。应禁用 SSLv2、SSLv3、TLS 1.0、TLS 1.1，禁用 RC4、3DES、NULL、EXPORT、弱 DH 参数和不安全重协商。应优先使用具备前向保密能力的 ECDHE 套件，使用 AES-GCM 或 ChaCha20-Poly1305 等 AEAD 算法。证书签名算法应避免 SHA-1。Cookie 应设置 Secure，避免通过 HTTP 发送会话标识；敏感请求应避免把个人信息放入 URL 查询参数，因为 URL 可能进入浏览器历史、代理日志、Referer 和服务器访问日志。
HSTS 是经常被忽略的关键控制。仅仅把 HTTP 301 跳转到 HTTPS，仍然可能受到首次访问降级攻击。HSTS 通过响应头告诉浏览器后续强制使用 HTTPS。成熟站点可以逐步设置较长 max-age，并评估是否加入 preload 列表。但 HSTS 也有运维风险：一旦子域、测试环境或旧系统还没有 HTTPS，贸然启用 includeSubDomains 可能造成访问故障。
| 配置项 | 推荐方向 | 合规意义 |
|---|---|---|
| 协议版本 | TLS 1.3 优先，TLS 1.2 安全兼容 | 体现“技术发展水平”与安全基线 |
| 弱协议 | 禁用 SSL、TLS 1.0/1.1 | 降低已知攻击面 |
| 加密套件 | ECDHE + AEAD，避免弱套件 | 提供保密性、完整性和前向保密 |
| HSTS | 逐步启用并评估 preload | 防止降级和用户误入 HTTP |
| Cookie | Secure、HttpOnly、SameSite | 防止会话在明文链路泄露 |
| 混合内容 | 全部资源 HTTPS | 防止脚本、图片、接口被篡改 |
| mTLS | 高风险 API、B2B、内部服务可采用 | 增强客户端身份认证 |
| 监控 | 证书到期、TLS 扫描、配置漂移 | 提供持续合规证据 |
七、香港要求：不是逐项列算法，而是要求“所有切实可行步骤”
图源：Unsplash。香港 PDPO 的传输安全要求采取风险和可行性判断，而不是单纯列举某个协议名称。
香港《个人资料（私隐）条例》（PDPO）采取的是原则型规则。附表1第4保障资料原则要求资料使用者采取所有切实可行步骤，确保其持有的个人资料受到保护，防止未经授权或意外的查阅、处理、删除、丧失或使用，并特别考虑资料种类、发生事件可能造成的损害、资料存放地点、设备安全措施、人员诚信审慎能力，以及确保资料安全传送的措施。
这意味着香港法下的关键问题不是“条例是否写明 HTTPS”，而是“在该业务场景中，HTTPS 是否属于切实可行且应当采取的安全传送措施”。对于银行、保险、电商、医疗、教育、人力资源、会员系统、政府服务和任何包含个人身份资料或账户资料的在线服务，答案通常很明确：HTTPS/TLS 是基本措施。PCPD 的资料保安页面也把 DPP 4(1) 与资料安全传送联系起来，并强调资料使用者在发生个人资料外泄时，需要证明已经采取所有合理可行步骤。
香港目前并没有一般性的法定强制数据泄露通知制度，但 PCPD 建议机构在发生个人资料外泄事故时通知 PCPD，并发布了《资料外泄事故处理及通报指引》。这在实务上会影响加密的价值：如果数据在传输或存储中使用了有效加密，且密钥未泄露，事件风险评估、通知范围和后续责任判断都会不同；如果数据通过 HTTP 明文传输，被截获后几乎无法证明攻击者不能读取内容。
| 香港依据 | 规则特点 | 对 HTTPS 的影响 |
|---|---|---|
| PDPO 附表1 DPP4 | 所有切实可行步骤，特别考虑安全传送 | 在线收集、传输个人资料时 HTTPS 通常是基础要求 |
| PCPD 资料保安建议 | 风险评估、技术和运营措施、处理者管理 | 要求从治理和技术两端证明安全 |
| PCPD 资料外泄通报指引 | 通报多为建议实践，但影响责任评估 | 加密强度会影响事件严重性和后续处置 |
| 银行业等行业指引 | 对金融资料和电子银行提出更高期望 | HTTPS 之外还需身份认证、交易确认、监控和审计 |
八、欧盟要求：GDPR 不指定 HTTPS，但把加密放进风险控制核心
图源：Wikimedia Commons，欧洲旗帜。GDPR 的逻辑是风险导向和问责，而不是只列技术清单。
欧盟 GDPR 的结构与中国、香港都不完全相同。它不会简单规定“所有网站必须 HTTPS”，而是要求控制者和处理者根据风险采取适当技术和组织措施。
GDPR 第5条确立完整性和保密性原则，要求以适当方式处理个人数据，防止未经授权或非法处理，以及意外丢失、毁损或损害。第25条要求数据保护设计和默认保护，把保护措施嵌入处理方式。第32条是传输加密讨论中最关键的条文：控制者和处理者应考虑技术发展水平、实施成本、处理性质、范围、背景、目的，以及对自然人权利自由的风险，采取与风险相适应的安全措施，其中包括个人数据假名化和加密、处理系统和服务持续保密性完整性可用性和韧性、事故后恢复能力，以及定期测试评估措施有效性的流程。第32条还特别要求评估因个人数据被传输、存储或以其他方式处理而发生未经授权披露或访问等风险。
这套规则对 HTTPS 的含义很清楚。只要网站或 App 处理个人数据，尤其是登录、支付、健康、儿童、位置、身份、通信、雇员、客户画像和跨境服务场景，企业必须解释其传输保护措施。HTTPS/TLS 是最常见且最成熟的措施。如果企业不用 HTTPS，就需要说明为什么在当前技术发展水平下仍能达到相同安全水平；这在多数互联网场景中几乎没有说服力。
EDPB 关于个人数据泄露通知的案例指南也强调，应根据事件风险判断是否通知监管机构和数据主体。加密、备份、访问控制、日志监控、密码哈希、密钥是否安全等因素都会影响风险判断。换言之，在欧盟法下，加密不仅是预防措施，也是事件发生后决定责任和通知义务的重要事实。
| GDPR 条文 | 核心要求 | 与传输加密的关系 |
|---|---|---|
| 第5条 | 完整性和保密性原则、问责 | 明文传输高风险数据难以证明符合原则 |
| 第25条 | 数据保护设计和默认保护 | HTTPS、HSTS、安全默认配置应内建到产品 |
| 第32条 | 风险适当安全措施，列举加密 | TLS 是个人数据传输安全的常规措施 |
| 第33、34条 | 数据泄露通知 | 加密状态影响是否构成高风险及通知范围 |
| 第28条 | 处理者合同义务 | 云服务、CDN、外包接口需约定传输安全 |
| NIS2 等网络安全规则 | 重要和关键实体网络安全管理 | 对数字服务、关键行业可能叠加更高安全义务 |
九、跨境业务中的共同底线：HTTPS 是入口，数据流治理才是主体
图源：NASA / Unsplash。跨境业务中，传输加密既包括用户访问，也包括后端、供应商和集团内数据流。
跨境业务最容易犯的错误，是只给用户前台页面上 HTTPS，却忽略真正的数据流。一个典型电商、SaaS、金融科技或内容平台，数据可能从用户浏览器进入前端网关，再进入 API 网关、业务服务、风控服务、日志系统、数据仓库、BI 系统、客服系统、邮件短信服务、CDN、对象存储、海外总部、境外开发团队和第三方供应商。每一段链路都可能构成传输，每一段链路都可能需要加密、认证和访问控制。
所以，合规视角下的“HTTPS 改造”不应停留在站点证书。企业至少应做一张数据传输清单，列出入口、出口、协议、数据类型、是否个人信息、是否敏感个人信息、是否重要数据、是否跨境、是否经第三方、是否加密、密钥归属、日志是否记录明文、异常如何告警。没有这张清单，企业很难在中国等保/密评、香港 PCPD 调查或欧盟 GDPR 问询中证明传输安全。
| 数据流 | 常见问题 | 建议控制 |
|---|---|---|
| 用户到网站/App | HTTP、混合内容、Cookie 明文 | 全站 HTTPS、HSTS、Secure Cookie |
| App 到 API | 旧 TLS、证书校验被关闭 | TLS 1.2/1.3、证书校验、必要时证书绑定 |
| 服务到服务 | 内网裸 HTTP、Token 长期有效 | 内网 TLS/mTLS、短期凭证、服务网格 |
| 企业到供应商 | API 文档要求不清、回调明文 | 合同约定 HTTPS、签名、防重放、IP 白名单 |
| 管理后台 | 只靠账号密码、远程 HTTP | HTTPS、MFA、VPN/零信任、审计日志 |
| 日志与监控 | URL 带敏感字段、日志记录 Token | 禁止敏感字段入 URL、日志脱敏、密钥隔离 |
| 跨境传输 | 境外访问、远程运维、集团共享不透明 | 传输影响评估、访问最小化、加密和合同保障 |
十、落地路线：从“把小锁点亮”到“可审计的传输加密体系”
如果企业要系统整改，可以按五步走。
第一步，盘点。列出所有域名、子域、API、App 接口、管理后台、对象存储、CDN、Webhook、供应商接口、内部服务和运维入口。不要只看生产环境，也要看测试环境、临时域名、老系统和营销活动页。
第二步，分级。按传输数据类型和业务影响分级：公开内容、一般个人信息、敏感个人信息、账号凭证、支付交易、重要数据、内部管理数据、密钥和令牌。不同数据等级对应不同保护强度。
第三步，改造。对公众 Web 做全站 HTTPS，HTTP 自动跳转 HTTPS，逐步启用 HSTS。对 App 和 API 强制 TLS 1.2/1.3，关闭证书校验绕过。对内部服务使用内网 TLS 或 mTLS。对供应商和 B2B 接口增加签名、防重放、访问白名单和调用审计。
第四步，治理证书和密钥。建立证书台账、到期监控、私钥权限、密钥轮换、吊销流程、自动部署和供应商管理。对重点系统评估是否需要商用密码产品、国密算法、密评或行业专项要求。
第五步，形成证据。保留 TLS 扫描报告、配置基线、证书台账、整改记录、等保/密评报告、个人信息保护影响评估、供应商合同、安全测试报告、事件演练记录。合规不是“配置好了就结束”，而是能持续证明控制有效。
| 阶段 | 输出物 | 审计价值 |
|---|---|---|
| 盘点 | 域名/API/数据流清单 | 证明知道数据在哪里传输 |
| 分级 | 数据类型和风险等级 | 证明加密强度按风险匹配 |
| 改造 | HTTPS/TLS/mTLS 配置记录 | 证明采取了具体技术措施 |
| 治理 | 证书、私钥、密钥生命周期台账 | 证明措施可持续运行 |
| 验证 | TLS 扫描、渗透测试、等保/密评报告 | 证明措施有效 |
| 留痕 | 变更、告警、事件演练记录 | 证明问责和持续改进 |
十一、常见误区：合规事故往往发生在“以为没问题”的地方
第一个误区是“只有登录页需要 HTTPS”。实际上，登录后所有携带 Cookie、Token、个人信息或业务数据的页面和接口都需要 HTTPS。否则攻击者可在登录后链路截获会话或业务数据。
第二个误区是“内网不用加密”。内网不是天然可信。云环境、容器、办公网、VPN、外包运维、开发测试环境都可能成为攻击入口。零信任和服务网格的发展，本质上就是承认内网也需要身份认证和加密。
第三个误区是“证书免费所以不可靠”。证书收费与否不是核心，关键在于 CA 信任、域名校验、私钥保护、自动续期和部署正确性。免费的 DV 证书如果管理得当，可以满足大量普通站点的传输加密需求；高风险场景则应考虑组织身份验证、私有 CA、mTLS 或行业要求。
第四个误区是“用了 HTTPS 就可以传任何数据”。HTTPS 保护的是链路，不解决过度收集、越权访问、明文日志、数据库泄露、前端 XSS、弱口令、供应商滥用和员工违规导出。传输加密只是数据安全体系的一层。
第五个误区是“监管只看有没有 HTTPS”。监管更关心风险是否被识别、措施是否有效、责任是否落实、证据是否完整。对高风险业务，只有 HTTPS 而没有访问控制、日志审计、密钥管理和事件响应，仍然可能不合格。
十二、结论：HTTPS 是最低门槛，密码和数据安全治理才是终局
图源：Unsplash。传输加密应被纳入持续安全运营，而不是一次性项目。
HTTP、HTTPS、证书和数据传输加密的合规逻辑，可以用一句话概括：法律通常不以某个协议名称作为唯一标准，而是要求数据处理者根据风险采取适当、必要、可证明的安全措施；在 Web 和 App 场景中，HTTPS/TLS 通常就是这个要求的基本实现。
对中国企业而言，传输加密已经同时受到《网络安全法》《数据安全法》《个人信息保护法》《网络数据安全管理条例》、等保、商用密码和行业监管的共同牵引。对香港业务而言，PDPO 第4保障资料原则要求所有切实可行步骤，并特别关注资料安全传送。对欧盟业务而言，GDPR 第32条把加密纳入风险适当安全措施，第25条要求安全内建和默认保护。三地规则的表达不同，但方向一致：越是敏感、越是大规模、越是跨境、越是关键业务，越不能容忍明文传输和不可证明的加密措施。
因此，企业不应再把 HTTPS 当作“网站美化”或“SEO 配置”，而应把它纳入数据合规、网络安全、个人信息保护、商用密码和供应链治理的共同控制项。真正成熟的做法不是问“法律有没有逐字要求 HTTPS”，而是问：哪些数据在传输，谁能访问，是否加密，证书和密钥是否可信，配置是否抗攻击，供应商是否同样遵守，发生事件时能否证明风险已经被合理控制。能回答这些问题，才算真正建立了面向监管和业务连续性的传输加密体系。
参考资料
- 中央网信办：《中华人民共和国网络安全法》。
- 工业和信息化部：《中华人民共和国数据安全法》。
- 工业和信息化部：《中华人民共和国个人信息保护法》。
- 中国政府网：《网络数据安全管理条例》。
- 国家密码管理局：《商用密码应用安全性评估管理办法》。
- 中国政府网：《关键信息基础设施商用密码使用管理规定》。
- 国家密码管理局：《GB/T 39786-2021 信息安全技术 信息系统密码应用基本要求发布说明》。
- 国家数字标准馆：《GB/T 22239-2019 信息安全技术 网络安全等级保护基本要求》。
- Code of China：《GB/T 35273-2020 Information security technology—Personal information security specification》。
- IETF：《RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3》。
- NIST：《SP 800-52 Rev.2: Guidelines for the Selection, Configuration, and Use of TLS Implementations》。
- 香港个人资料私隐专员公署：《PDPO Data Protection Principle 4 – Security of personal data》。
- 香港个人资料私隐专员公署：《Data Security》。
- 香港个人资料私隐专员公署：《Data Breach Notification》。
- EUR-Lex：《Regulation (EU) 2016/679, Article 32 Security of processing》。
- EDPB：《Guidelines 01/2021 on Examples regarding Personal Data Breach Notification》。