五千年(敝帚自珍)

主题:【原创】云里雾里的云计算 [1] -- 邓侃

共:💬620 🌺1262
分页树展主题 · 全看首页 上页
/ 42
下页 末页
        • 家园 写那个黑客的书我看过。 呵呵

          这小子就是好玩,没有拿资料去卖钱、或者干啥。

        • 家园 几点澄清

          1. 公钥和私钥

          Hansens的表述是正确的。问题是如何实现1-N的通讯加密,即,1人写,多人读。我的想法是,

          a. 公钥和私钥,在加密解密方面,其实是没有区别的。可以用公钥加密,私钥解密,反过来也行。公钥和私钥的差别在于公钥有公开的分发渠道和鉴权机制,而私钥归个人保管。

          b. 用私钥加密,同事们想读,可以用公钥,公钥由公司统一代管。这样,读者不需要麻烦作者发放公钥。

          c. 德国人的钥匙很有意思,办公室的钥匙,同时可以打开大楼的门,以及公司的门,但是不能打开隔壁办公室的门。隔壁办公室的钥匙,也可以打开大楼的门,以及公司的门。所以,德国人的钥匙和锁,是有层次的。公钥也可以这么设计,一个部门的公钥,不仅可以解密本部门的文件,而且可以解密公司内部公开的文件,但是不能解密其它部门的文件。实现这样有层次的公钥并不难,一个简单的办法是把整个公钥分成几段,第一段负责公司内部公开的文件,第二段负责某特定部门的文件等等。

          2. 索引能否解密

          索引不能解密,否则Googler可以根据索引里的信息,复原原文的内容,即便不能一字不漏地全文复原,但是至少能做到八九不离十。

          所以,我原文里的话是有漏洞的。正确的说法是,索引不能加密,所以只能留在密室内,而不能上传到云计算公用平台。

          3. 数据库的加密

          数据库最多只能对字段逐个加密,譬如“greatness”变成“@#¥%”。但是不能整句整段地加密,否则B-tree就建不起来了。

          4. 密室

          密室的Root权限必须掌握在客户手里。Googler能知道的,是机器的heartbeat,用来监控机器运转的情况。需要时,和客户方的IT人员交流,指挥他们恢复密室机器的正常运转。


          本帖一共被 1 帖 引用 (帖内工具实现)
          • 家园 这个很有意思

            德国人的钥匙很有意思,办公室的钥匙,同时可以打开大楼的门,以及公司的门,但是不能打开隔壁办公室的门。隔壁办公室的钥匙,也可以打开大楼的门,以及公司的门。所以,德国人的钥匙和锁,是有层次的。公钥也可以这么设计,一个部门的公钥,不仅可以解密本部门的文件,而且可以解密公司内部公开的文件,但是不能解密其它部门的文件。实现这样有层次的公钥并不难,一个简单的办法是把整个公钥分成几段,第一段负责公司内部公开的文件,第二段负责某特定部门的文件等等

            RSA 里面的那个R 有一次就谈到这个, 不过当时给的需求是email, 就是不同等级的manager 不一定能解全部的秘文, 但这个有一个比较

            棘手的问题,担心几个有decrp 的合作后给解了, 因为是非正式场合, 我这个比较弱, 基本就是听了几耳朵

        • 家园 另外,信息安全的原则是隔离、隔离、再隔离

          政府专网是物理隔离、单独光纤。

          搞得我们这些做信息化的人头疼无比。

          每次用U盘同步数据的不是少数。弄2道不同国家的防火墙的更是常事。

          另外,加密的原则就是加密后的密文和加密前的明文是信息关联越少越好。

          保密上还有一个间接推论原则,也就是如果你的正文是加密的,但是我通过你公开的几个索引能猜到你这个文章大概是什么意思。或者另外一个例子,当年英国认为他们可以通过德国硝石的进口量数据来确定德国是否进入备战状态以及炸药的产量。

          当然英国的例子失败了,因为德国的科学家搞出了氨氧法制备硝酸,造炸药不受硝石的限制。

          这段话的意思是,如果是真的需要保密的数据,即使只泄露部分索引信息也是不可接受的。

          • 家园 我考虑,从技术之外解决也许更可行

            就现阶段的技术条件,我觉得要解决大企业重要数据的保密问题很困难,并且商业意义不大(大企业有钱就自己建了)

            相对而言,解决对保密程度要求不高的小企业需求可能更为现实和迫切。

            就小企业来说

            1、如果有一个较为可信的第三方提供的服务,可能即使不加密也是可以接受的。比如淘宝上的店主、阿里巴巴上的外贸小企业,他们的几乎所有信息都被淘宝、阿里巴巴掌握了,也不见他们哭着喊着要加密。

            这方面和政府联合建立一个云计算服务中心也许是一个办法,政府的第三方和权威性+云计算的低成本+服务小企业的政治需求,也许是个三结合的好办法。

            2、如果是对保密要求更高一些的,可以做分级储存,多层次权限管理,部分加密等技术辅助措施。实际上一个企业的重要秘密信息是不多的,这部分完全可以不放在云里面,或者仅仅是存储在云里面但云不需要对其解密。比如一个企业的客户名单多数是可以公开的,但是与客户的合同就是不可以公开的,那合同加密就可以了。对于检索和一般应用,有客户名单实际上能应付99%的需求,对于想看合同的,想看也不能给。对于客户通讯录这样介于公开和保密之间的信息,就可以用分级权限管理等方法处理。总之,根据实际业务在公开和保密之间平衡,不一定追求一个完美的解决办法。

            • 家园 分级管理

              比如一个企业的客户名单多数是可以公开的,但是与客户的合同就是不可以公开的,那合同加密就可以了。对于检索和一般应用,有客户名单实际上能应付99%的需求,对于想看合同的,想看也不能给。对于客户通讯录这样介于公开和保密之间的信息,就可以用分级权限管理等方法处理。

              这是最现实的做法。

              大家的讨论很好,尤其是Hansens兄指出我原文中的关于索引是否能加密的硬伤。

              稍后我去修改原文。

            • 家园 花分级管理,但仍然不能解决运行时泄密问题

              企业把大部分数据放在云端,少数核心数据放在本地。

              不过问题又来了——软件还是在云端运行啊,无论你数据放哪儿,云端总归要得到明文数据才能够分析啊。——所以本地也必须运行一些程序,得到中间数据后传给云端,出最终结果。不过这样软件流程定义就非常复杂了,哪些本地哪些远端。。。晕了。。。

          • 家园 太正确了

            索引中透露了正文中出现过那些词,以及这些词出现的位置。

            通过这些信息,理论上是可以反过来,通过索引,复制原文的。即便不能一字不漏的全文复制,也能复制得八九不离十。

        • 家园 不是商榷,是澄清

          关于加密的问题,着实费了一些脑筋。

          过年的时候,应酬很多,剩下的时间里,有空就琢磨加密和搜索的问题。方案想了一个又一个,推翻了一个又一个。

          最后积淀下来的就这么一点点。

          写之前觉得满肚子的话,可是写完一看,好像也没什么惊人之语。

          Hansens兄的问题问得好。这些问题,我都想过,只是限于篇幅,正文里没有展开说。

          我现在要离开一会儿。稍后答复。

          • 家园 云上活着的是AI的话就可以想象了

            加密数据进,加密数据出。AI内部独立模拟OS. google要破binary就很难。

            • 家园 关键是云是否可信

              如果云可信,那么用户就直接相信云好了。如果云不可信,那么除非AI是经过证明其机制完全可靠,而云又能证明其AI程序完全符合其公开的机制,否则AI仍然是不可信的。

            • 家园 兄台的AI指的是?
              • 家园 AI只是范指,我大致的意思是种超规模的图灵机。

                能独立于物理平台的计算云。用AI描述容易理解一点。

            • 家园 有解还是无解,我又犹豫了

              我原文的结论是,

              总之,虽然没有完美的解决方案,但是云计算平台加密的难题,还是有解的

              现在又犹豫了,似乎更合理的表述是,

              总之,云计算平台加密的难题,现在没有完美的解决方案。或许目前云计算平台能做的,是代管那些不太机密的内容和程序。

    • 家园 老邓家真是过年去了。

      家里的菜园子也荒芜了。

      看来本专栏现在是海外人士的乐园了。

分页树展主题 · 全看首页 上页
/ 42
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河