论坛6 | 云时代的运维与安全 姚熙 「智能硬件的云端安全实践」



  • 时间: 2016年7月28日
    发言人: 姚熙|青莲云 CTO
    主题: 智能硬件的云端安全实践


    大家下午好,首先说一下青莲云,我们是专注于IOT的互联网服务公司。我们整个公司技术团队基本上大部分是从360和其他互联网公司出来的,本身带着很重的安全属性在里面。所以在我们公司里面做云平台上一些安全的实践,希望能跟大家分享一下。

    0_1470895559951_upload-8bb67393-7365-429c-a98c-3a2c57c4d256

    今天主要想跟大家分享几个方面,首先说一下与传统云服务,或者移动互联网、物联网平台相比有什么特殊之处。第二个我们作为后端的云平台在物联网领域到底应该解决哪些痛点。第三个简单过一下青莲云后端架构的问题。剩下的主要是切合今天演讲的主题,就是在安全方面跟大家分享一下我们现在到底是怎么做的。

    青莲云主要是IOT互联网的后端云,它和SaaS和PaaS不一样,我们提供的是一整套功能,不需要用户或者开发者或者企业再进行一系列的开发,或者再做一系列的架构、功能的叠加。我们主要是做一个双向实时的消息推送,同时我们还有一套自己的OTA的独立技术,这个技术前一段时间专利已经下来了。我们现在搞的比较好的一点就是,现在物联网中保证每个智能硬件的安全联网的问题,并没有保证智能硬件相互认识和联动的问题,而我们在云端做了这样一个工作,只需要用户或者厂商把它的功能点,或者硬件暴露出来,完全可以用,不需要再额外的开发任何的功能。

    0_1470895572607_upload-dc98bb91-1746-4fcb-ae0b-f61f447b9383

    这两幅图说的是2014—2017年装机量和硬件产品分类,实际上这是想说IOT物联网设备量很大,而且种类也是纷繁复杂。你产品不一样,数据肯定也有千差万别的区别。比如说现在有视频类的,文本类的,二进制的,音频等等的数据。作为一个公有的云平台的话,数据方面,包括我们协议的自定义,协议的定义还有一系列数据通道的转发,数据存储,这些兼容性我们都得考虑到。

    还有IOT的东西,实际上智能硬件要求实时相应性比较高,比如说我家里的智能冰箱、智能空调,时效性要非常强,这是很重要的一点。还有一点也很重要,现在大家提智能硬件或者智能制造,特别是对个人级消费产品来说,往往是轻设备端重云端。我设备端本身计算资源或者处理性能都非常少,我一个手环上面能有多少计算量?对不对。

    0_1470895618786_upload-0a9f56e8-25ca-42fd-a83b-a857ac456bfb

    刚才出现的问题对应过来就是现在整个青莲云或者整个物联网需要解决的四大问题:千万级并发的连接,时效,数据存储、分析、通路的东西,还有兼容性的问题。我们经常会遇到这样的实际情况,向下的话联网协议是千差万别的,比如说WiFi、蓝牙、Zigkee,上面联网协议也不一样。每一家云平台本身应用协议是不一样的,我们怎么跟第三方在数据打通或者消息转发上做到很好的兼容性?其实这也是一个难点。

    0_1470895631583_upload-743f2c08-c50d-43f6-878d-378686b0192c

    这是青莲云整个后端的架构图,分为三个层次。首先是接入层的东西,包括服务对象等等。我本身计算资源非常少,我们就想一个连接里面能不能做DS的解析、进行跳转,可以加一个分发的,一直到接入。接下来是一些核心服务,包括数据处理、设备管理、用户管理,还有一些安全引擎,还有我们的警告引擎。同时整个还有很大的亮点,就是设备联动引擎,同样是在云端做的。左边是消息的集群,第三层是数据实时分析或者Log的子系统。我们很多应用其实不需要到核心应用层,包括认证,还有我们每一次连接或者每一次设备重连都会做强安全的认证,这样我们就需要实时、全局的开启服务。开启服务到底放在哪里?是核心业务层还是接入层?我们当时有做过比较,一是功能比较,二是性能比较,实际上我们最后会在全局有个开启做这个东西。

    这是整个架构,是很通用的架构,在里面我们要提到整个性能。如果单拿出来我们的并发连接接入单台、单节点不是很高,但是接入量我们说的是并发量,是并发并且每一秒钟我们会发256字节的大小,我们要模拟真正在线长链接智能设备介入数,如果100台每秒钟传的数据是50字节,加上我的加密,自有的私有协议,整个加起来就100字节左右。我们翻一番算并发的话,是256字节每秒钟发,这样是单节点的100万台。单节点新建连接是20万每秒,下面是单节点吞吐量和平均响应时间。

    接下来会着重讲一下青莲云在安全方面做的一些工作,第一个是比较传统的,因为安全本身是一个链的问题。从底层到上面,全局的问题,所以在这几方面我们做了安全考虑。首先是数据链路的问题,SSL/TLS加密是必备的,说到数据还要考虑到你承载数据,组织数据的通讯格式,就是我们说的协议。应用层的协议包括网络层面传输的协议,我们都要考虑它的安全性。应用层面协议不单单是有文本类数据,还有音频、视频、语音类的数据,还有二进制的数据,所以我们要考虑兼容性的时候,我们要统一用自己可兼容的一套,私有的二进制协议来做。

    数据加密我们也会做,我们讨论用AES128还是AES256的时候,做了一个统计,实际上AES128基本上破解是不可能的,AES256性能消耗会大于40%—45%,所以觉得用AES128就可以了,其有数据序列化、对称密钥,数据签名,每次连接都不一样。

    业务逻辑安全,横向攻击、重放攻击都会考虑到。

    云平台自身的安全,下午在听青藤云的时候我们也听到了,我们也做相似的东西,我们有自己的安全模块部署在上面,有事情的话我们会直接发送到自身的后台系统。所以不单单是青云本身提供安全性能,我们除了自己的业务系统以外,自己还会再部署一套安全性小的安全功能放在上面。

    0_1470895666880_upload-9a0624df-0c3e-4da4-874a-2bfb19972ec6

    0_1470895673552_upload-a2aa4c8c-d7d6-4190-91d7-3b5a9031a45c

    这是前段时间看的新闻,觉得比较搞,我发这个例子就是说,现在智能硬件安全性很大一部分没有被大家真正考虑到,或者真正运用到实践中。前一段时间出现这个事情,它的指令基本上没有加密,它不会断开重连,重新生成,人家直接拿着你的ID就可以复制你的整个设备,这个产品肯定还有另外的漏洞,比如说水平权限的问题,肯定可以伪造,因为这是最基本的连接问题。

    0_1470895715918_upload-afc42a0d-bdb4-4ba1-8ff4-084333798e9c

    现在有70%智能硬件破解是由于本身平台或者到云端服务器链路传输不加密,或者身份认证、授权不当,有缺陷造成的。我们现在做的这个图,就是设备与设备之间,通过数据通路上面数据有加密,通讯链路有加密,到云端,而且每个设备的ID都是隔离没有任何关系的,甚至每一台设备在依次连接ID都是不一样的。我要保证如果它需要重放或者伪造攻击的话,压根没法攻破我们这道防线。

    0_1470895726450_upload-2d6d0000-bf76-457d-82cd-222761a3b7a8

    画的这个图是说明什么呢?刚才说安全本身是个进化的过程,从开始大家不知道怎么弄,慢慢的发现这儿有问题,那儿有问题,慢慢改。其实就是把你能够想到的,或者你没想到的,碰到钉子的问题一个一个的解决。最早是单一型材,第二个是一个产品,或者一类产品用同一个token,实际上这个力度还是不够的。你在应用的逻辑上没有做到设备与设备之间的分割,设备与当前状态,下一次状态,或者即将发生的状态隔离开的话,你肯定有地方暴露出来让别人拿到你的把柄。你其他地方做的再好都没用,木桶原理和安全问题非常贴近,它说明安全问题的话这是非常贴近的。我们一直在宣传一个理念,我们要保证每一次连接,每一次数据通路,每一次数据传输在单位时间内,连接每一个token都是不一样的。比如说以前我们做其他云产品的时候,单台可以做170万、180万并发,我们一个节点四台设备才可以达到100万并发,这是为什么?我们做了安全属性,逻辑上很复杂的计算,导致现在并发连接上不去。但是四台100万并发,目前来说一个单节点就够了,因为如果按照25%来算的话,可能是400万台、500万台设备的单节点。

    再说一下设备连接的强安全逻辑,比如说智能硬件进去以后要求三层,这只是逻辑层的三层,并不是物理层的三层。第一层会找分发,其实就是短链接,去了马上就回来,去了马上就回来,不要求你长链接,也不要求你占很多资源,但是唯一要求你快、稳定。我TCP对链路层没有任何加密,但是对协议我们有自己一套私有协议,还有自己一套数据要进行加密的。第二层是我们觉得在中间过程需要生成中间过程的Devics Token或者Devics ID,其实我拿你的token可以干很多事情。如果在第二层加上这样的交互过程的话,就很有作用了。第三层是通过第二层中间的过程,形成了最终的ID和token,就不会出现问题了。整个过程就是这三层,每次连接都会做这样的动作。

    0_1470895747606_upload-0d8b1663-5807-4ac9-acd5-5d3d6a12e56c

    我们现在谈一下安全和性能的问题,这是我们当时考虑OTA升级的一个迁移图,为什么把安全性能单独拎出来呢?你做的事情越来越多,你性能消耗也就越来越大,中间有个平衡的过程,像拔河一样,你要不过去一点,要不回来一点,要不在中间临界状态。上图我们精简后的一版状态迁徙图,这个版本的计算性能和那个版本的计算性能差了2.7倍,但是使用当前的状态机的情况下,我们业务逻辑安全级别,比如说本身数据的断点续传,导致整个状态机慢序话,整个状态可以到正确的状态里,
    性能和安全要兼顾,我们对数据进行加固的时候到底是用128还是256,刚才已经说过了。还有112,112到128,就是多16个字节,大家可能觉得有点低,但是经过计算之后128完全可以胜任,而且差40%的性能。我们要做一个平台或者做一个计算的话,我们要求的承载量或者计算速度也是一个指标。

    最后大家都在说智能硬件,我们比较了一下,我们一直在说智能硬件联网或者安全联网,横向对比的话就是人的吃住行是最简单的需求。那升级一点要出去认识人,通过学习有自己认知的能力,再升级有自己的感知能力。其实我们可以把智能硬件看成一个人,它最基本的诉求是我本身处理不了什么东西,需要云端“大脑”给我处理东西,我首先要连到云端,这是基本诉求。连到云端之后,能不能让A厂商和B厂商的智能硬件相互认识,或者A厂商出去的智能硬件都认识,所有厂商智能硬件可以相互认识,这时候我们提供这样一个平台,就可以通过这一套机制让设备与设备之间互联起来,不单单是去中心化的问题,不单单是所有设备通过网络连到我们的“大脑”上,我们还需要搭建一套周边所有设备与设备连接的网状的东西。

    我们现在有一个联动功能,M2M的能力。智能决策是我们云端联动大概的示意图,刚才一直在谈联动,联动对基本的要求是你这个设备必须抽象出来。这个设备在我们云端来看就是一个对象,这个设备商传输的数据点或者要求暴露出来的功能,比如说开关、上传温度,比如说电机、转速,都是这台对象暴露出来的。如果在云端,这个厂商出厂的产品愿意拿出来给别人共享,我们就可以生成相应的API,相应的抽象的某一个小的节点。这是一个基础,还有一个问题,我愿意把这个东西贡献出来,抽象出来,还存在一个问题。如果B厂商觉得你卖得挺好,需要跟你联动一下,在某个应用场景下能为用户创造更大的使用价值,这就需要B厂商问A厂商要授权,A厂商把授权给他以后,这时候又存在安全风险了。B厂商拿到token以后,到底能访问A厂商出去所有的API功能,还是只能访问到设备级,甚至于设备级里面的功能点,力度还是不一样的。

    假设我们买了A厂商的智能硬件产品,这时候我没有共享出去,我不愿意。虽然你这个厂商原本就支持联动,但是我买了这个产品我就不想让别联动,或者厨房和客厅就不联动。那我们云端到底该怎么处理?是直接给我们家客厅发指令还是厨房发指令,甚至是给客厅的设备发温度指令还是什么指令,这又不一样。

    0_1470895816265_upload-49c05325-0bbb-4483-981b-8b21b8a89509

    最后说一下上图,因为安全嘛,我们现在把云拿过来做一套离线系统,基于大数据分析的异常行为分析系统。这是为了事后追查在线的防御系统有可能的漏网之鱼,比如说我现在注册了,给他提供服务,他把厂商的ID和token泄露出来了,这时候怎么办?可能有人说没解。所以遇到这种场景的时候,我们就会把很多数据拿出来,我们就会看数据点。比如说某台产品上定了四个数据点,ABCD。它有十台设备一直在传E或者X数据点,从来没传过正确的数据点,正确数据点也有,但是非常少,他可能一秒钟传一次数据或者五秒钟传一次数据,我要把数据点拉出来,告诉他是异常的。我们再去看设备是不是异常的,这是我们后台用于离线系统处理。

    以上就是整个青莲云在云平台,在整个安全方面的实践,谢谢大家。


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待