HarmonyOS开发者限时福利来啦!最高10w+现金激励等你拿~ 了解详情
写点什么

以信任重构互联网基础

  • 2019-11-02
  • 本文字数:7263 字

    阅读完需:约 24 分钟

以信任重构互联网基础

一、互联网安全的困境

之前看到一句话:“当一个行业、做法成熟到所有人都在说时,它就已经快过气了,天花板已经触手可及”。互联网安全行业现有做法就已经看到天花板了,急需新的突破。


现有互联网安全基本做法做个总结就是“杀毒”、“防火墙”、“入侵检测”三板斧。这些做法的基本思路就是别人如何攻击,我就如何防御,用医学方面的比喻就叫做“对症治疗”。当然在不同场景里,这三板斧的比重是不一样的。比如在企业安全场景里,入侵检测会是很高的比重。


对症治疗的好处是能够很快见效。用杀软把病毒堵住了、病毒进不来,自然就不会有后续的病毒造成的破坏;用防火墙拦截了不该出现的流量和访问,自然就避免了后续的恶意行为;用入侵检测手段实时查处了入侵行为,就能针对性堵住入侵者避免资产损失。


这些治标的做法基本都是被动防御,是基于事故驱动的。导致的结果是几乎所有企业的安全部门都有个 SRC,很多时候安全部门的人都在救火。而且攻击与防御本就是不对等的。攻击只需要单点突破,防御需要的是体系化建设。所谓体系化建设,实际就是防御手段的完整度,其效果严重依赖相关负责人的经验和能力,依赖已经发生过的安全事故的总结,100 个人会有 100 种体系化建设的理解。而且传统企业安全手段的有效与否还依赖于企业的具体业务内容,根据业务内容会有不同的安全问题,然后对这些点做出针对性处理。


最终结果就是:很难有一个标准化的方法能够在所有安全场景通用,基本就是在一个场景有效的安全方案,到了另一个安全场景里都会见光死;甚至是上一个新业务都需要有全新的安全方案。这给整个安全行业及从业人员带来了极大的复杂度,也意味着企业及消费者的极高安全成本。


同时,因为传统安全做法对具体安全病症的强依赖,导致安全手段对业务内容的强侵入,使得安全部门经常与业务部门有各种业务冲突,安全工作开展非常不顺畅,也事实上给业务部门制造了障碍,阻碍了业务发展。这实际是“治标”这个做法导致的必然结果。


整个互联网安全行业经过 10 多年的大发展,目前基本做法理论都已经定型,很多问题从 10 多年前到现在依然不能很好解决,各种新的安全问题总是层出不穷。即使旧的安全问题,也是一次又一次出现。更重要的是,很多时候直接导致安全事故的问题,实际是在行业看来不值一提的诸如弱密码甚至无密码这种低级问题。有人说之所以这些问题解决不好,是因为安全方案的落实程度不同。但是一个 10 多年来整个行业都做不好的方案,不是应该被反思吗?每次安全事故后都强调责任心、安全重视度,但这是人的天性,与天性对抗必然会付出沉重的代价。

二、去中心技术重构信任

回到我们的本源:究竟是什么原因导致了互联网安全问题?


事实上,一切互联网安全问题的根源都是“可信”问题。展开前先说一个“可信”的基本定义:


可信是“可控”的等价词,指的是身份、数据、行为不会出现意料之外的情况,都是按照事先预定好的逻辑在运行。


互联网自从诞生之日起,其基础设施就是不安全的。比如 IP、Port 这样的东西,从设计之初就没考虑过鉴权以及准入逻辑,默认只要链路层面没问题,IP、Port 间就能相互通信。这点在机房入侵这件事上有很明显的例子:


通常机房入侵都是通过某些手段找到各种边界上的薄弱点予以突破,攻占其中一台服务器、业务资源。然后再以此为跳板,向其它服务器、业务、数据库等蔓延。这个过程中有个很重要的手段就是网络扫描和嗅探。网络扫描和嗅探之所以能成功,很重要的一点就是我们的服务器、业务之间,只要没有网络障碍就默认能够相互收发数据包,我们的基础设施之间是天然相互信任的。


现有的所有网络攻击手段也都是基于 IP、Port 这样的不可信的资源的,比如 DDOS 攻击的第一步就是设法找出攻击目标的真实 IP。 所以,只要解决了信任问题,大多数的互联网安全问题也就基本解决了,很多安全问题就失去了存在的土壤。这一点上,谷歌的零信任架构给我们做出了示范。其核心逻辑是以步步认证的方式构建一个可信的身份、数据、环境、行为。不过其基于传统技术手段实现,成本高昂,多数企业不具备实施的条件。谷歌的零信任架构就是事实上的可信身份在企业安全场景里的具体应用。


以可信方式解决互联网安全的根本问题,实际就是要构建可信身份、可信网络、可信计算环境、可信程序、可信存储,以此形成一个全新的互联网基础设施。

2.1 可信身份

首先要明确的是可信身份并不等价于实名认证,而是以这个身份的名义发出的数据、指令不可能是未知的“人”冒充别人发出的。这里的“人”可以是真实的自然人,也可以是某个程序、某个服务器、某个业务。常见的身份冒用场景就是建立一个会话,然后基于这个会话生成一个业务、数据通道供后续其它逻辑使用。这种单点验证、多路复用的做法给身份冒用留下了空间,不符合可信身份的基本要求。


实践中,传统技术方案下有很多不好处理的逻辑,光是 KMS(密钥管理系统)就是一个很不好搞定的的系统。新技术方案下,我们通常会把具体的技术方案用区块链、IPFS 等去中心技术实现:


第一,身份认证首先要知道去哪里认证。利用以太坊的 ENS 或者 IPFS 的 IPNS 能达到和 DNS 类似效果。不同点在于:


  1. 不存在 DNS 污染这样的问题,也不会有 DNS 劫持,解析结果一定是真实可信赖的。

  2. 不管是以太坊的 ENS 还是 IPFS 的 IPNS,它们都是去中心化系统,不需要向特定的服务器发起解析请求。只要在业务可达的任何位置,甚至是业务方本地/同服务器部署一个节点程序,就能实现解析服务。

  3. 基于 2 的原因,其可用性、安全性都要高于传统技术下的 DNS 服务。同时,也降低了网络复杂度。比如,传统网络架构下,为了向不同网络环境暴漏 DNS 资源,这些网络间势必就需要有一个专用的数据通道,这又会引入新的安全风险,而且网络复杂度明显提高,增加了运维成本和运维风险。


第二,身份认证需要有认证依据。目前比较有效的方案是公私钥认证,这就涉及到 KMS 系统的相关逻辑。


  1. 通常把公私钥明确区分为身份公私钥和权限公私钥,也就是身份和权限分离,好处是身份和权限可以随时调整。结合身份验证的逻辑,身份泄露不是必然会导致权限泄露。

  2. 公私钥仅仅用来做身份认证以及协商密钥,不用来做加解密,不在网络传输任何私钥相关信息(明文或者密文),确保前向安全性。

  3. 合理使用门限加密等方案,确保私钥可用性以及验证逻辑的安全性。门限加密逻辑下,私钥被随机拆分成很多碎片由不同的人持有,使用者无需取回所有密钥碎片、只需要取得一定数量的碎片就能最终解密出完整的密钥。这个过程中,每取一次密钥碎片就要接受一次身份认证,多个身份认证都被绕过的可能性几乎不存在,安全性得到提高。同时,因为无需取得所有密钥碎片,所以可以应对认证系统部分节点崩溃的问题,可用性得到提高。


第三,认证过程需要有可信的数据通道。以太坊的 whisper 是可信通道的不错选择。通过这个方式,通信双方的身份一定是可信的、不可伪造的,认证双方可以对对方的情况一无所知。这个“对方”可以是任何一个运行了以太坊节点的服务器、甚至个人 PC;网络环境上,双方甚至都可以位于某个家庭路由器的后面,没有任何特别要求;“对方”也不一定是一个确定的服务器,可以是很多具有相同功能、位于不同的物理或者逻辑位置的节点中的一个。


从以上描述来看,实际上这个架构解决了很多传统安全风险的攻击点:无需公网 IP、无需对外开放端口、无需特定网络结构、无需专门的容灾逻辑、无可以攻击的中心化资源。


然后需要强调的一点是,虽然以上说了这么多“认证”,实际上,作为去中心身份逻辑的组成部分,具体业务实践中,并不建议按照之前的那种“验证”-“业务”-“结束”的逻辑来用。正确的用法应该是类似于 restful API 的做法:并不需要专门有个登陆过程,而是在 业务的全流程中带上身份信息,服务提供者根据身份信息确认后续动作,这是与传统 C/S 或者 B/S 架构系统下不一样的地方。而且所谓认证也未必是”登陆”这样的逻辑,一切能证明身份的方式都可以是认证,比如签名验证机制。

2.2 可信网络+命名网络+软件定义网络

可信网络实际上就是要解决传统 IP 网络环境下的无认证机制,而命名网络解决的是传统网络通信对于 IP 的依赖性。IP 本身是个中心化资源,且与地理位置强依赖。传统互联网安全攻击针对的都是这样的中心化资源,只要中心停止服务了,整个系统就失去服务能力。


IP 与地理位置的强依赖也导致了中心资源对不同位置的用户服务质量和服务能力的差异,所以产生了 CDN 服务,但 CDN 只能处理静态资源,对动态服务无能为力。


  1. 可信网络/命名网络解决的就是以上这些传统网络的弊端。具体实践上:第一,利用以太坊的 ENS 或者 IPFS 的 IPNS 替代现有 DNS 的位 置,实现域名寻址、内容寻址,原因之前解释过,就不重复了。

  2. 利用 IPFS 节点以及公私钥机制实现命名网络+可信网络,对外提供标准的 socket-like 接口,降低现有程序改造复杂度;同时不再依赖 IP:Port 通信,而是网络名称,替代现有 IP:port 的位置。

  3. 基于 IPFS 提供的以公私钥隔离网络流量的机制,加上以太坊智能合约提供鉴权相关逻辑,实现可信网络+软件定义网络,能够相互通信的两个端点间一定是身份可信的。而且因为基于公私钥做网络隔离,所以可以实现类似软件定义网络的动态组网效果。

  4. 出于兼容现有程序、降低改造成本考虑,可以提供一个网络代理,监听本机 127.0.0.1 对应端口,由这个代理实现现有程序的 IP 网络向可信/命名网络的转换。监听 127.0.0.1 的目的是,这个 IP 地址不可被外部网络连接和使用,避免了 IP 网络环境中的扫描、爆破、嗅探等风险。

  5. 对于用户端程序可控的,比如各种用户端 APP,可以统一迁移到新的网络模型下;对于用户端程序不可控的,比如各种门户网站,暂时可以保持现有逻辑运行。同时改造现有代码逻辑,结合 IPFS 的内容分发能力以及以太坊智能合约实现的配置分发能力,实现多边缘节点的效果,尽量平稳向可信网络转变。


影响:


  1. 任何端点间的通信不再基于 IP:Port,而是网络名称。这种环境下,传统基于 IP/Port/域名攻击的逻辑基本都失效了,这些中心化资源也不再存在,使得攻击者失去攻击目标。

  2. 服务器不再需要统一放到某个或者某几个机房,可以位于任何一个网络环境以及物理、逻辑位置(甚至放在家用路由器后面),无需固定公网 IP,无需对外开放端口。

  3. 同一个通信地址可以对应不限数量的服务器且无需专门做容灾、负载均衡,得益于 IPFS 系统的相关算法,这个网络能自动实现近源访问和负载均衡逻辑。

  4. 很容易实现软件方式的组网效果,组网不再依赖机房架构等硬件限制,网络间实现逻辑上的流量隔离。而且此逻辑基于公私钥身份认证,不同网络间的数据不可互通,实现网络成员的可信。

2.3 可信计算

可信计算的基本要求是身份可信、数据可信、行为可信、执行环境可信。某些专家/学者可能还会有数据传输可信的说法,不过这里把它认为是数据可信的内涵之一,所以不单独列出。区块链技术实际上解决了身份、数据、行为可信问题,缺乏执行环境可信。传统可信计算方案更多是解决了执行环境可信问题,对于其它方面并没有可靠的解决方案而且成本高昂。在可信计算方面,区块链技术与传统方案刚好是强互补关系。


具体实践上:


  1. 身份可信之前已经说过了,这里不做重复。

  2. 数据可信方面,区块链依赖各种不同的共识机制已经很好的解决了这个问题。同时,IPFS 基于哈希算法的内容寻址逻辑也能实现数据可信。所以通常做法都是把数据的 IPFS 地址/域名存储到以太坊,把实际的数据内容存储到 IPFS。

  3. 行为可信,实际上说的就是程序可信。基于第二点说的数据可信,行为可信已经得到了解决。第四,执行环境可信,实际说的是程序在运行过程中产生的数据, 除非程序主动输出,否则任何方式、任何个人,也包括执行环境的控制方(比如服务器的所有者/运营方),都不可能得到这些数据、状态。


这一点,有软件和硬件以及软硬件结合等三个方案。软件方面,主要是 MPC,其实现方式主要是各种同态加密、零知识证明、门限加密等密码学算法以及与之配合的业务逻辑的精巧设计。


硬件方面,主要是 SGX、TrustZone 以及各种第三方 TPM 模块。


效果角度讲,他们都能单独实现可信执行环境,但是也都各有优缺点,不能单独作为实用方案。


软件方案里,基于目前的算法效率以及硬件性能,无法满足处理大规模数据的需求,只能在一些特定场景使用。


硬件方案里,SGX 可以实现多安全实例,性能上也优于 TrustZone,但是其依赖 Intel 等具体厂家的硬件和服务,被诟病不够“去中心化”。关于这一点,还是要看具体场景。比如对于国家层面的应用场景,可能就需要在意这个问题,因为自主可控在这个场景里是强需求。但是很多具体的商用场景,对自主可控并不是强需求,这个问题基本就可以忽略。我们生活在一个现实的世界里,你总是需要有条件地信任一些东西。整个社会也是靠这个逻辑才得以维持正常运转,所以不必要对所有“中心”都一概抵触。


TrustZone 是 ARM 提供的一个可信硬件环境,但是其功能及可用性依赖手机厂商的具体实现,要做广泛应用还缺乏统一的实现标准。如果是在 IoT 领域,因为不身就不面向直接用户,所以手机上面临的这个问题基本可以忽略。


第三方 TPM 模块方面,目前市面上并没有成熟稳定的第三方生产商可以满足这个需求,暂时不予考虑。


软硬件结合方面看,目前最可行的就是使用 FPGA 等定制电路做软件加密方案的加速处理。MPC 实现里,最大的问题就在于性能问题。很多同态加密算法实现里都有大量的矩阵运算,这给 GPU 以及 FPGA 优化留下了很大的空间。


所以做个总结:


  1. 根据业务所在硬件条件选择合适方案。比如 PC 上可以选择 SGX 以及基于 GPU 加速的软件方案;服务器环境可以选择 FPGA 加 速的软件实现;手机上可以选择 WebGL 加速的软件实现,也可以选择手机厂商提供的 TrustZone 实现。

  2. 根据业务场景选择不同方案以及方案的组合。比如手机作为个人隐私设备,需要直接处理的数据并不多,不管是硬件方案还是软件方案,多数时候基本都能满足需求。

  3. 通过业务逻辑的精巧设计满足业务需求。比如数据加密共享场景,可以在云端使用高性能设备将待共享的数据重加密成以目标用户的密钥加密的密文。而目标用户只需要在手机上做密钥的同态加密以及最终数据的对称解密。

2.4 可信存储

可信存储不仅是数据的可信持久化,还包括数据的流转和使用过程中的可信要求。可信存储与之前的可信身份、可信计算等都是密不可分的,实践中几乎不会单独存在。


A、使用以太坊智能合约作为基本数据索引。以太坊的 TPS 很低,但是我们并不是简单将每个数据的索引直接写到以太坊。通常做法是这样:


对于频繁读但是写很少的数据,如果数据量很大,就将数据本身写到 IPFS 网络,只将数据地址写回以太坊智能合约;如果数据量不大,可以直接将数据写到以太坊智能合约。而以太坊智能合约的读性能只取决于单台节点的程序执行性能,在多节点情况下,读性能基本不可能影响到业务的正常运行。


对于写很频繁的数据,直接将数据本身写到 IPFS 网络;同时使用 以太坊的 whisper 可信通道向特定范围广播、堆积数据的 IPFS 地址,方便使用者获取数据;定时将最新数据的地址批量写到以太坊智能合约。


B、结合之前说过的可信身份和可信计算相关逻辑,实现数据使用、流转的控制,保持数据生命周期全过程的可信。


C、有需要的情况下,在 B 的基础上,建立数据产生、使用、流转的经济模式,以及数据存储/使用环境的经济模式,实现整个可信存储的价值最大化。


比如,作为数据共享平台,可以做到允许授权的人使用自己的数据,但是看不到、拿不走数据。这既充分盘活了数据价值,又避免了数据泄露带来的安全风险,是对生产力的提高。


再比如,某些用户有数据渲染、处理的需求(比如 AI 模型训练),但是自身并没有数据处理能力,所以有需求的用户可以把这件事委托给任何一个有能力的平台用户代为数据处理,请求者只需要拿到最后结果就行了,不用担心数据处理者(比如云平台)看到自己的数据。


以上是对可信逻辑实现方式的梗概性说明,距离直接动手做事还有相当的距离。真要去实现这些逻辑时,对所有这些技术的综合整合和利用能力是核心要求。

三、泛安全与基础设施的进化

上面说了传统安全行业的做法以及基于信任基础的新做法。前者是武术招式,后者是内功。前者成本相对低、见效快,后者成本相对高、见效慢。二者并不是二选一的关系,而是需要结合当前面临的实际情况,综合考虑轻重缓急,选择最合适的方案。我们应该清楚的是安全部门的目标是什么,不能把手段当目标。当前行业很重要的一个问题就是很多人、尤其是部分企业管理层,认为挖漏洞、做应急响应就是做安全,这纯粹就是把手段当目标了。


金庸小说里有以招式见长的独孤九剑,也有以内力见长的九阳神功,使用他们的大侠无一都是二者兼具,没有哪个人的成功是只用其中一方面的。我们的安全行业从业者之前很长一段时间,基于整个行业现状,多数人是扎根于招式的演练,修为内功的很少。招式演练,目前看是到了天花板的阶段,急需有新的突破口;而内力的修为,才刚开始,相关技术发展也处于起步阶段,急需更多的行业人士来发掘它的潜力。


另外一个方面,一直以来,安全都是保安角色,以嫁接的方式保护原本不安全的产品、服务,是纯成本部门,不产生直接的价值。在区块链、IPFS 等新技术环境下,这些基础设施除了满足业务需求,安全特性是其基本属性,而不是嫁接安全服务。安全特性在业务场景中将会越来越被弱化,但是其重要度并没有因此降低,只不过是二者逐渐融为一体,不分彼此。


所谓的泛安全,并不是安全的进化,而是整个基础设施的进化,也必将因此而带来新一轮的互联网形态的变化。比如我们将来可能不再需要向云平台买服务器、买数据库,云平台将是一个彻底的“劳动密集型”平台:它负责干活,不关心也不能够看到用户的数据、行为,用户仅仅需要向云平台分发任务,云平台主动从用户处接单,然后返回劳动结果给用户。


本文转载自公众号有赞 coder(ID:youzan_coder)


原文链接


https://mp.weixin.qq.com/s?__biz=MzAxOTY5MDMxNA==&mid=2455760104&idx=1&sn=ae746d1e36f86d8f3942492bb74391fe&chksm=8c686acdbb1fe3dbe4d9e57483e2774b6d01bd8875e1f35548a740bf45010f0cdfaf581f965a&scene=27#wechat_redirect


2019-11-02 08:001223

评论

发布
暂无评论
发现更多内容

经济金融的数字化转型并没有消除风险,风险反而更加复杂

CECBC

LeetCode 每日一题「接雨水」

陈皮的JavaLib

Java LeetCode 动态规划

实现一个执行Explain 命令的Mybatis 插件

water

「SQL数据分析系列」3. 查询入门

Databri_AI

MySQL select

《原则》(十四)

Changing Lin

6月日更

回归分析

Qien Z.

6月日更 回归分析

Python——列表切片

在即

6月日更

算法训练营 - 知识总结

心在飞

Trello个人生产力简易指南

俞凡

生产力 认知 大厂实践

架构实战营 - 模块6 - 作业

笑春风

假如我是创业公司CEO之电商小程序微服务拆分

ifc177

浏览器上有趣的Console命令都了解吗?

空城机

大前端 浏览器 6月日更

springboot启动流程之加载入口类

梦倚栏杆

视频号真人首播 - 踩坑经验总结

悟空聊架构

复盘 直播 视频号 6月日更

算法之异位词字符处理

Skysper

算法

Kubernetes手记(11)- 配置信息容器化

雪雷

k8s 6月日更

色情,科技,与女性

脑极体

Pandas高级教程之:Dataframe的合并

程序那些事

Python 数据分析 pandas 程序那些事 数据分析研究

数字化转型的征途

CECBC

小团队真的适合引入SpringCloud微服务吗?

xcbeyond

微服务 6月日更

面试官嘲笑我,这你都不会?

李阿柯

php 面试 redis cluster

物联网平台规则引擎流转到S3对比

张俭

azure IoT AWS 华为云

MySQL基础之十二:增删改

打工人!

myslq 6月日更

算法训练营 - 学习笔记 - 第十周

心在飞

SpringCloud Gateway 动态路由

黄仲辉

mongodb 响应式编程 源码阅读 动态路由 SpringCloud Gateway

架構實戰營 - 模塊 5 作業

Frank Yang

架构实战营

架构实战训练营 - 模块五课后作业

Johnny

架构实战营

前端 CSS 变量简介及基本使用方法

编程三昧

CSS css3 大前端 样式

【FlinkSQL】Flink SQL Query 语法(四)- Rattern Recognition

Alex🐒

flink 翻译 FlinkSQL flink1.13

标杆管理:让自己快速成长的实用工具

石云升

创业 职场经验 6月日更

【LeetCode】猜数字大小Java题解

Albert

算法 LeetCode 6月日更

以信任重构互联网基础_文化 & 方法_周燃_InfoQ精选文章