BM:为什么区块链是更好的应用服务器/数据库架构
高天 2020-02-12 19:55:32发布
55058
摘要:“未来几年不采用区块链技术就像银行不采用SSL”  

传统的web应用程序基础结构在设计时将安全性作为事后考虑事项,在过去的25年中,许多公司一直试图修补一个根本不安全的体系结构。这种体系结构的设计假设服务器可以被信任和保护,但是多年的经验告诉我们,没有服务器是安全的,更不用说内部的攻击了。换句话说,服务器基本上是集中式的。

 

我们过去认为“问题”在于用户和服务器之间的连接,因此我们引入了SSLHTTPS。但后来我们发现,黑客会破坏数据库并窃取密码。所以我们开始存储密码的哈希值,但后来我们发现黑客会在盗取哈希值后强行破解密码。然后,我们引入了密码旋转,这样在强制输入密码时密码就会改变,等等。

 

企业正花费数十亿美元试图保护它们的服务器和数据库,尽管付出了所有这些努力,但仍然没有简单的方法来审计系统并确保企业按预期运行。

 

Block.one是构建区块链软件,以保证数据库和用户帐户的安全,防止未经授权的访问和未解释的修改。对于区块链,用户采用高度安全的私有密钥,这些密钥存储在安全的硬件中,用于对每个用户交互进行签名,而不是简单地对到服务器的连接进行身份验证。区块链创建了一个不可变的日志,建立了接收用户输入的绝对和确定性的顺序,而智能合约提供了确定性的业务逻辑,确保了所有系统之间的一致性。

 

未来的Block.one。其中一项是创建消除密码和昂贵的审计,为公司节省数十亿美元,防止身份盗窃,并为所有人提供更高的可靠性和审计能力。

 

多年来,我一直认为每个多用户网站都可以从采用区块链后端中获益。与流行的观点相反,区块链不必是缓慢、低效的数据库,也不必在抵制审查、开放获取的基础上运行。区块链可以在安全性、审计能力、透明度和业务流程的整体完整性方面为公司提供巨大的改进,即使区块链完全由公司自己操作,区块链的任何内容都不会公开。

 

本文旨在揭示区块链在企业环境中的真正价值,并为区块链行业的发展指明方向。

 

 

常见的误解

 

在区块链行业中,许多人认为区块链只有在将互不信任的各方连接起来时才会带来利益。他们认为,传统的数据库技术已经可以完成确保业务完整性所需的所有工作。换句话说,他们认为传统的数据库复制和“数据完整性”保证就足够了。在这个过程中,他们忽视区块链所提供的完全不同的安全性和完整性保证:

 

1对全局事件序列的承诺

2业务逻辑的确定性执行

3业务逻辑和数据完整性的紧密耦合

4取消密码

 

在传统的业务应用程序体系结构中,业务逻辑与数据库是分离的。通常有一个应用服务器,如Node.jsJ2EE,它提供了修改数据库的密码。js服务器的作用是通过密码或多因素身份验证方案对用户进行身份验证。一旦应用服务器对用户进行了身份验证,它就会发出一个会话令牌,用于对未来的用户交互进行身份验证,直到超时或会话的某些元素(IP)发生更改。

 

显然,这种传统设计通过应用服务器管理的单个登录/密码执行所有数据库操作。应用服务器负责实现自己的最终用途的身份验证方案。显然,通常有多个用户可以访问用户名和密码。数据库管理员可以向许多不同的应用服务器和/或个人分配和撤销凭据。

 

高级系统确保在水平扩展的系统中,每个应用服务器都有自己的用户名/密码,在某些情况下甚至可以使用公钥基础设施和硬件安全模块(HSMs)。但是,即使在这里,数据库也只验证到应用服务器的连接。为了提供审计日志,它必须记录安全连接的整个数据流。但是,即使是这个日志也只记录应用服务器请求的“读写”,而应用服务器已经丢失了关于向应用服务器表达的原始用户意图的所有信息。

 

审查这样一个系统的审核员无法知道应用服务器(例如Node.js)是否遵循正确的业务逻辑,并正确地验证了最终用户的身份。js进程可以将用户操作“记录”到数据库中,这样审计人员就可以尝试重现相同的计算,但是这样的日志本身并不具有防篡改性,并且没有独立的可验证身份验证,即最终用户实际上授权了它所记录的操作。

 

可以尝试记录每个用户连接,但是由于用户经常通过连接传输他们的密码,这些日志最终会创建一个泄露用户凭证的蜜罐。更复杂的系统可以对这些日志进行加密,这样只有审计人员才能读取它们。

 

假设审计日志没有被篡改,审计人员将不得不通过应用程序逻辑运行相同的操作序列,以验证结果数据库状态是否匹配。这意味着应用服务器必须以确定性的方式实现。

 

 

确定性计算是困难的

 

虽然编写确定性代码看起来很“简单”,但实际上所有常见的计算机语言都是非确定性的,因为它们允许开发人员访问数据库中存储的数据之外的数据。这可以是一些简单的东西,如时间戳、内存地址、环境变量、IP地址,也可以是一些更微妙的东西,如硬件上的浮点行为或哈希表的插入顺序。在许多情况下,简单地访问长时间运行的应用程序服务器的内存变量就足以引入不确定性。启动/停止应用程序服务器的动作必须被记录和复制,否则在重播期间每个本地内存访问可能是不确定的。

 

事实是,编写确定性代码对于受过常见缺陷培训、积极寻找非确定性的最佳开发人员来说是一个挑战。典型的业务应用程序开发人员会发现以确定性的方式编写是困难的或不切实际的。

 

如果我们进一步假设应用程序代码是确定性的,应用程序忠实地记录用户事件,那么我们仍然面临在任何给定时间跟踪部署的代码版本的挑战。应用程序是动态的,并且经常更新,因此应用程序代码本身也必须是数据库状态的一部分,并且其更新的管理和记录必须具有与用户操作相同的安全性和可审计性。然后,审核员需要拥有应用服务器代码的所有版本的副本,并根据需要通过每次版本升级来重播用户输入(以及在过去重新启动代码时重新启动代码)

 

即使单个应用程序服务器在实现和部署方面都能够以确定的方式进行操作,它仍然会遇到一个主要的可伸缩性问题。只有一个应用服务器实例可以对数据库进行操作。并行访问可以通过复杂的锁实现,但是即使锁上的竞争条件也必须被记录和复制,或者两个具有不同本地变量的应用程序逻辑实例也可能产生不确定的输出。

 

在这一点上,人们可能会试图完全抛弃决定论,但在决定论缺失的情况下,随着时间的推移,一点细微的差异就会变成最终数据集的巨大差异。审计人员将被迫使用模糊逻辑和近似匹配,每个人都必须相信“模糊逻辑”足够好。

 

当然,要消除编写和部署确定性代码所付出的所有努力,惟一需要做的就是让数据库管理员直接修改数据库而不进行跟踪。在某些情况下,对用户输入日志和状态的仔细更新可能会创建两个不同的数据库状态,每个状态都通过了确定性测试,但仍然具有不同的和不可调和的输出。例如,假设一个教授向系统提交了一个学生成绩F,然后这个学生通过黑客/贿赂的方式进入数据库来更改他的成绩和教授提交的日志。

 

 

更换密码

 

任何关心完整性的多用户系统的最终目标都是确保不能伪造用户输入。用户名/密码或其他主观的多因素身份验证(SMS或谷歌身份验证器)的使用依赖于服务器来判断密码是否匹配或输入了正确的SMS代码/电子邮件链接/身份验证器代码。很明显,这对系统的完整性来说是一个巨大的问题,但是为了以防万一,我将提供一个真实世界的例子来说明这些系统有多糟糕。

 

2016年,我在一家加密货币交易所开设了一个账户,该账户遭到黑客攻击,黑客窃取了价值数万美元的比特币。从我的角度观察到的黑客行为显示为发送到我的电子邮件的“密码重置”邮件,然后是另一封表明我的密码已成功重置的电子邮件。然后我收到一封电子邮件,要求确认我的比特币的提取(带有代码/链接)。然后我收到了一个通知,说我的取款手续已经办完了。

 

乍一看,我的电子邮件帐户似乎被黑了,但这是不可能的,因为我使用了多因素登录我的电子邮件。快速访问我的电子邮件安全页面显示,没有未经授权的访问我的电子邮件。我能看出来,因为谷歌会记录并显示所有访问我电子邮件的ip /设备。

 

所发生的事情是,攻击者在邮件到达我的电子邮件账户之前截获了邮件。应用服务器无法知道电子邮件被截获,因此只有在攻击者拥有应用服务器生成的一次性代码的情况下,才授权密码重置和撤回。

 

同样的漏洞也可用于SMS或任何其他依赖于用户控制的私钥之外的其他技术。最后,真正保护用户帐户的唯一方法是让所有用户采用基于硬件的私有密匙作为他们的登录凭证,并结合健壮和耗时的过程,以便在硬件密匙丢失时进行安全重置。

 

此时,多用户业务应用程序可以使用用户的私钥对每个用户请求签名,将这个签名的请求记录到数据库中,并使用确定性代码处理它。即使这样也不能提供人们所期望的完整性,因为整个用户请求仍然可能被删除,同时还会产生任何副作用。想象一下,当一名警官提交了你的罚单,然后所有的州都从这个请求中派生出来,你就可以入侵警察数据库并删除他签署的请求。

 

此时,精明的工程师会宣称,我提出的每个问题都可以通过更改应用程序逻辑来解决。他说的是对的,一个成熟的应用程序开发人员可以使用“传统数据库”、“传统应用程序服务器”和“通用密码原语”来构建一个相对安全且可审计的系统。根据同样的逻辑,一个精明的工程师可以声称数据库是完全不必要的,所有的东西都应该直接构建在文件系统上。另一位工程师可能会指出,通过从头开始编写代码,而不是依赖于Node.jsJ2EE等应用服务器框架,可以提高性能。这就好像所有的东西都是由低水平的技术制造出来的,我们也可以设计出性能最佳的晶体管。

 

我之所以指出这个极端,是因为它突出了高级框架在加速和保护新应用程序开发方面的真正效用。很少有人编写自己的密码库或算法,而编写这些库或算法的人要么是专家,要么在自己的系统遭到黑客攻击时充当警惕性的尾巴。从头开始开发/重新开发所有东西的成本可能会使每个应用程序都比在经过验证的框架上构建更昂贵。

 

 

区块链应用程序/数据库服务器的优点

 

区块链和EOSIO这样的开发框架之所以存在,是为了让应用程序开发人员不必为了构建安全的应用程序而重新创建“数据库”。安全性和决定论很难实现,这就是为什么技术构建在抽象细节的层中。EOSIO在同一过程中将确定性执行环境(WebAssembly)与快速数据库相结合。所有的用户操作都由他们自己的私钥签名,并记录在一个复制和分布式的数据库中,该数据库具有对块标头进行公开承诺的能力。

 

EOSIO这样的框架与传统的不安全系统一样强大且易于开发,这只是时间问题。在许多方面,EOSIO的体系结构已经比传统系统具有更高的性能,这是因为它将应用程序逻辑(Web程序集)放在与内存数据库相同的进程空间中。

 

在未来的几年里,Block.one其中一个目标是添加工具和接口,使在区块链上部署业务应用程序与在传统业务应用程序体系结构上部署相同的应用程序一样容易(或更容易)

 

很明显,采用区块链技术应该成为政府机构、上市公司和有责任防止欺诈和/或进行财务报告的企业的优先事项。在我看来,未来几年不采用区块链技术就像银行不采用SSL,一旦该技术广泛使用,不使用区块链技术就会被认为是疏忽。

 

今天是行动的时候了。如果应用程序的构建方式没有根本性的改变,您的企业和用户就不会安全,也不会安全。每耽搁一天,你的生意就会面临欺诈或黑客攻击的风险。

 

作者:Daniel Larimer

 

编译:共享财经Neo

点击进入招聘详情>
微信扫一扫
关注区块链新金融
扫一扫
下载数链APP
内容合作/商务合作:
gxcj@gongxiangcj.com
联系电话:
021-31128751