上一期，我们揭秘了最近红红火火的RPA是什么！又红红火火地给自己布置了一篇关于“数据上云安全”的作业。在火火火火的天气里，今天就来交作业啦！老规矩，躲在安全的空调屋里，杀个瓜，听主播讲那些和安全有关的故事。
-------文字版分割线--------
大家好~我是美丽大方温柔善良但一看到在群里发无关广告还不给红包就丧失理智的群主兼主播兼服务生小姐姐兼微软智慧云拓展总监Grace。
大家都知道我的工作主要是围绕着微软的物联网和人工智能这两个方向上与合作伙伴落地场景来做一些探索，这个过程中有幸结识了合作伙伴云安行的玉林。
玉林在西雅图微软总部研发部门工作了20多年，主要做数据库系统和数据相关工作，现在是云安行科技的CEO。
今天的话题，便是认识了玉林总后，我们对云计算、物联网的发展一些新的思考。
数据上云安全吗？
无论是互联网，人工智能还是帽子大一点的数字化转型，都有一个本质——数！据！上！云！
上云这件事我们其实已经谈了很多年，大家都知道云计算是非常有好处的，可以解决很多问题。可是，从开始到现在，一直都没人能完全发自内心的说，上云这件事情绝对没有问题！我们都知道，想要踏踏实实的认可一件事，你必须得先解开心里的结，对于上云，这个结便是“安全”。
当然，要解决这个问题并不容易，目前就有一些企业存在因为信息泄露被行业诟病的问题，我们当然不希望未来还出现这样的情况，让数据一旦放到云端之后变成安全隐患。这种影响很可能决定一家公司的命运。
比如有一家做原材料的传统上市企业，花了两年时间做了一套挺厉害的系统，打通了自己的生产、执行、管理、库存、物流之后，发现了一条转型方向：那就是把自己的这套系统作为行业应用的服务，在竞争对手发现之前延伸到共有的客户群，在给自己的客户提供更好的工业互联网服务以外，还可以聚拢大量的行业数据。
然后嘛…就没有然后了，因为这个时候他们开始担心一件事情：自己这套系统自己用的时候有啥问题盖住就行了，但是如果给产业链上其他客户用的话，万一生产数据一旦泄露…不仅可能震惊整个生态，自己这个上市公司的股价就能表演10米跳台了！于是就来找到我们——想了解如果要让数据上云，特别是传统企业，怎么能从技术上非技术上都能说服自己。
所以，今天我们主要说两件事情：
1
怎么安全上云
过去十几年已经有非常多的公司不断地信息化，信息化的发展导致数据量变得越来越大，数据上云变得越来越必要，云上数据安全就变成核心问题。
2
如何管理数据
很多公司在上云过程中发现：上云也带来了管理上的问题，数据量大了之后怎么去管理这些数据，也是目前众多企业面临的问题。
比如某国内知名基因检测公司的基因数据量极大，大到什么程度？一个人的基本的检测数据大概几十个GB，加好了标注的数据将近80到90GB。一年的数据接近1个PB，1个PB什么概念？一张高清的照片大概20兆，1PB就是万张！并且这个数据量的增长速度是越来越快，而海量数据必须存储，存在哪儿？
医院的场景：
医院，08年还是2TB数据量，医院2TB的数据，那时候影像设备没那么好，X光、CT的设备不够多，当然随着增长，每年逐渐为70/80到TB的增量，很吓人。
医院而言，数据要永存！从我们技术而言，国家规定它的数据要存30年，30年对企业而言就是一个永存模型。其实网络中有很多存储服务器，且上面都是各个年代最高端的一些存储服务器。
但你去看嘛，基本上都是已满已满已满，或者是即将已满。所以过去五年很多企业开始讨论和正在上云。云很便利，但是呢大家还是担心，我知道云很好，但是万一云会带来一些额外的“安全的风险”怎么办？
所以这就是我们的理想和现实。
其实正经把上云的过程掰开来看的话，也难怪会有顾虑，当然这些顾虑一般人是看不出来的。可是我不是一般人嘛，我们分析一下啊：
“云服务商如果泄密怎么办”
“我不想把鸡蛋都放在一个篮子里”
“我要有绝对的访问控制权”
“我现有的IDC机房要合理用起来，注意经济性嘛”
解决办法有没有呢？
废话，要是没有解决办法我们今天就不讲了不是。
怎么安全上云？
我们来看看思路啊：
把左边想象是你的数据源，右边是可以分散存在多个数据中心的数据存储地点。
但是注意哦，此时在每个存储里放的不是一个数据库，也不是一张完整的表，都是一个无意义无序的数据碎片，在从数据源到数据存储的过程中被碎片化了。
即使是我是这个系统管理员，或者其他有管理权限的人偷偷拿到了系统，或者Copy了数据也一点用都没有。
这个过程保证了一个事，就是如果不是通过正常应用通道访问数据的话，黑客理论上没有任何可能还原数据的，就算是老汤哥也不可以！
那如果要做好这件事的话，这个过程中有哪些我们要考虑的呢？
第一件事叫CASB，云访问安全代理。
↓这里有个大概的模型↓
右边我们看到是公有云服务的不同服务层次，Iaas、Paas，Saas，左边是我们企业内部的应用，传统的方式我把我们的数据送到云厂商。
链路上就横着CASB，数据要通过新CASB层云访问安全代理转变成另外一种形态，有点像咱们原来说的网闸的模型，再进到后边的这个服务供应商里面，那么服务供应商是不知道数据的原始形态的，那也就不可用了。
第二件事要考虑到的是数据不仅仅只在一个仓库里封存，而是要能以可靠的方式分享，当然，得保证这个数据只给指定的人，那就得说到安全分享机制。
刚刚已经说了，数据已经以这种碎片化的形式存在在我们的系统中了，然后要通过我指定的渠道把数据分享出去，那就要把拼装这个碎片和管理碎片的权限给人家，同时被记录起来，数据确权可不就靠这事儿了么。
这事儿的想象的空间很大，在产业互联网里安全的数据确权和分享非常有用，等我们讲工业互联网的时候再说哈。
而且这样的结构才是我们说的追求网络的扩展，实际上追求的最重要的一件就是平等化的网络结构，去中心化的网络结构，才能在不同源的非互信的体制中大家可以互相延展，可以无限制的延展，甚至就像我们的手机打各国的电话是一样的模型。那么是如何配置这些存储资源，以便进行更好的授权控制呢?
↓看这里↓
一旦产生这种可自由分配或可自由配置的模型，实际上产生了几件事，这也是刚才推荐的多冗余策略…我们一旦产生分布式的模式的时候就可以充分的利用不同云计算平台的能力。
另外有了多供应商的时候，我们就有机会能得到不同的性价比差，原来我们用的是3、3、4的比例，现在某一个云厂商降价了，我们变成了1、1、8的比例，增大那个供应商的份额，那么我们整体的成本下降，对用户是自动可调的。所有的东西都是由用户直接控制的。
咱们刚才说CASB的那些事，加密分割成碎片，碎片扰乱成组，分散存储在不同的节点，这事儿是怎么做到的呢？
让我们想象一架飞机：
有可能某个人看到了飞机的某一个角落，所以我们要根据不同的文件特性以及它的类型等等，用不同的方式来保证每一个独立的数据碎片无意义。
哪怕任何人拿到这个碎片，有意义的信息他丁点儿都拿不到，这是前提。然后才是说如何能保障这张图纸能够安全的控制在用户的手里，这是我们这套逻辑完成的一个碎片化的方式的整个经过。你看在Azure当中的Blog存储的样子：
就像鹿鼎记把藏宝图撕碎分在8本四十二章经里面，要获得全部信息首先你要像韦小宝一样天赋异禀，又有吉人照耀找齐经书；之后还要有双儿这个小丫头把碎片拼在一起；最后还要再找一个懂满文的老师，把上面的满文变成汉语......
如何管理数据？
刚才我们说了数据怎么安全上云，解决的是一个底层数据存储的事情。接下来就要看企业用户关心的是什么。
用户关心的是连续的数据保护，是数据可被交互或可控交互，是我不要改我的数据存储习惯等等等等等等。
所以下面这些都是在做好一个多云存储的产品时需要被考虑的：
同时还有一些其他的技术考虑：
比如说到碎片化，大家想的第一个问题估计就是数据的完整性——数据被你咔嚓咔嚓了，如果某一个碎片丢了，是不是什么东西都回不来了？嗯，有可能。
其实上云是基于对每一个碎片进行md5校验，然后同时在云端进行三副本的模型，这简直就是微软Azure的标准动作呀，甚至需要的话，还可以做两地的六副本模型，这跟云中心的可靠性是一致的。
然后考虑的便是我们常说的数据可用性，云中心给的可用性一般是4个9，而为了保证更可用，实际上我们还有一个前置服务。其实就是用户的热数据或经常使用的数据是在他本地有一个拷贝的，不让它的业务受影响。
云中心建的机房的可靠性和可恢复性远超于企业自己的机房，前边的服务是一个异步的动作，数据在Queue里边等待直到我们的网络连通，两三个小时之后会恢复原来备份或者还原的动作。
说到这里，云有这么多的能力，是不是还可以帮着用户做更多一点事情？大家知道热存储、冷存储和极冷存储吧，那么他们几位的区别呢是成本差，极冷几乎是热存储的1/4的价格。热数据的响应时间最快，冷存储响应时间慢一点，极冷响应时间极慢、极慢…因为他是用冷磁介质或者说离线介质那种光介质来制作的。
就像我们都好喜欢拍照，不过大部分时候我们只用最近的热数据，一年以前的照片会偶尔翻一翻，而十年前的…只有在同学会的时候才去硬盘上找了对吧。除了前男友什么的，其他我肯定是不会删的，企业更是这样。
之前有过一个电视台的哥们找到我们说，他们每期节目都要存起来，放在一个大硬盘里，贴个标签往那一堆。这些节目基本上以后都不会再用，但是呢又不能扔，比方说某个领导在某一天讲的某一句话，有可能突然要翻出来，找起来就非常的困难！能不能有个办法？
这种事儿放在硬盘存仓库里是肯定是不行了，那我们要放到云端放到热的冷的或者是极冷的这样的一个分层的结构里去帮助调度，成本最低的同时又能够实现我的业务要求，正好顺便把备份和归档的事儿也完成了。
我就说那你把数据放在Azure上，比方用视频检索——AzureVideoindex这样一个API的话就很容易检索起来。
连关键词都自动给建好索引。
医院场景（数据量每年指数级递增），原来有一大堆的高端存储设备都满了，加入了云端这个理论上无限的资源池之后，再做扩容的动作都容易了。
不过这里还有个问题，这架构中的CASB调度同志会不会出问题呢？这个是特别重要的一件事，就是说云厂商生产了资源池，那么我作为送快递或者管理快递的这个人会不会把快递乱送，或者我出了问题您的东西都送不出去了呢？
诶等等，开头介绍的云安行的玉林总呢？和这篇东西有什么关系？
实际上就是因为云安行做出了一个云存储解决方案，才有了我们今天这番讨论。他们的方案里充分利用了多个公有、私有云的能力，除非极其特殊的情况，不然不可能所有公有云一起不能持续服务。
而CASB桥头堡是一个并行的多冗余的架构，本身是一个stateless方式。那么我们不需要用它来去连续的维系企业的业务流程的各个阶段，所以他出单点故障的几率也几乎没有，理论上不会发生，除非是全球断网，或者某一个基础协议坏掉了网络都不能用，真要发生这种事情我们就没IT可搞了。
刚才我们讲了很多“我”可以怎么怎么，那又有个问题了，这个“我”是谁？是管理员吗？
理论上讲不是，医院或者档案馆或者等等这种模型谁负责的？我们可以说是国家，医院的院长或者档案馆长，而技术的职责是分配给IT管理员去做，但是IT管理员只是在动作中能够完成它的使用，并不能真正的控制数据。
所以说云安行实际上就是把这个管理模型设计好，严格遵照Hippa和GDPR的标准，国内也遵从信息安全法，而业务上由企业来配置。
还想深入了解云安行云存储解决方案的话，下方进群联系管理员~
------我是接下来“还没完”的分割线------
1.微软超火的29大兴趣专家