浅谈两种加密技术,加密算法实现

　　背景

　　对于互联网公司来说，数据安全一直是一个非常重要和敏感的话题。如果个人信息涉及客户安全数据或一些商业敏感数据，如身份证号、手机号、卡号、客户号等。被泄露，会造成严重的数据安全隐患。

　　在真实的业务场景中，相关业务开发团队往往需要根据公司安全部门的需要，自行实现和维护一套加解密系统，自行维护的加解密系统往往面临着重构或修改的风险。因此，我们希望实现一个通用的敏感数据处理框架，如何在不修改业务逻辑和业务SQL的情况下，透明、安全、低风险地实现无缝的数据加解密转换。

　　框架中加密实现方案的比较：首先通过下面的列表讨论几种加密实现方案的优缺点：

　　通过对上述方案的比较，得出的结论是，实现一个加密框架至少有以下要求：

　　代码的侵入性较小。接入成本低。叠加更多帧。高性能和高可用性。支持股票数据的加密。可以发现，数据库驱动层比其他方案缺点更少。那么，有没有一种方案可以在不改变数据库驱动的情况下，满足数据透明加解密的要求呢？

　　数据库访问架构计算机领域的任何问题都可以通过增加一个间接的中间层来解决，这本身就体现了分层的重要性。比如Unix系统也是基于层开发的，大致可以分为三层，分别是内核、系统调用和应用层。每一层都封装了上层的实现细节，并公开抽象接口进行调用。

　　基于这种软件思想也可以实现数据库访问。因为不同厂商的数据库服务器差别很大，所以需要定义一个API来执行SQL语句，以提供对多个数据库的统一访问。例如，Java的JDBC和go的数据库提供了一个基准和规范，在此基础上可以构建更高级的工具和接口。数据库开发人员遵循这个基准和规范，他们编写的应用程序被称为数据库驱动的。

　　(1)面向方面编程(AOP)是软件开发中的一个热门话题。一种通过预编译和运行时动态代理实现程序功能统一维护的技术。AOP可用于分离与业务无关的功能，如权限认证、日志记录、性能监控、错误处理等。通过在执行前后拦截指定的方法，可以重用同一个函数，避免业务代码的入侵。因此，AOP可以降低代码逻辑之间的耦合度，提高程序的可重用性，同时提高开发效率。

　　(2)通过AOP截取并重写业务SQL的假设，实现了一个数据库驱动的XDriver，这是XDBC的标准API的具体实现。下面这段伪代码是AOP用来拦截XDriver，从而重写业务SQL。

　　公共接口数据库{

　　/**

　　*执行SQL

　　*/

　　ResultSet executeQuery(字符串SQL)；

　　}

　　公共类XDriver实现数据库{

　　@覆盖

　　公共结果集executeQuery(字符串sql) {

　　ResultSet resultSet=null

　　//TODO

　　返回结果集；

　　}

　　}

　　公共类XDriverIntercepter实现数据库{

　　私有数据库数据库；

　　public void set Database(Database Database){

　　这个。数据库=数据库；

　　}

　　@覆盖

　　公共结果集executeQuery(字符串sql) {

　　string new SQL=rewrite SQL(SQL)；

　　返回database . execute query(new SQL)；

　　}

　　/**

　　*重写SQL

　　*/

　　私有字符串重写Sql(字符串sql) {

　　string new SQL=“”；

　　//TODO

　　返回newSql

　　}

　　}如上面的代码所示，假设有一个名为account的表，表字段mobile和address需要加密，可以做如下处理：

　　在帐户表中添加mobile_encryted和address_encrypted字段。XDriverIntercepter拦截xRiver的executeQuery方法重写SQL。

　　重写SQL因为SQL是一种完美的编程语言，所以解析SQL的语法和解析其他编程语言(如Java、C和Go)没有本质区别。

　　(1)抽象语法树的SQL解析过程分为词法解析和语法解析。

　　词法分析将SQL分解成不可分割的原子符号，称为Token。令牌包含关键字(也称为符号)和非关键字。

　　语法分析是生成抽象语法树的过程。

　　例如，下面的SQL:

　　从帐户中选择地址，其中mobile=？解析后，抽象语法树如下图所示：

　　将抽象语法树转换成下图：

　　将抽象语法树分解成以下SQL:

　　选择address_encrypted作为来自帐户的地址，其中mobile_encrypted=？并发控制

　　在高并发场景中，不希望重复解析SQL，这会影响性能。但是，如果SQL解析仅仅是互斥的，那么在高并发场景中，大量的请求将被阻塞和等待。因此，需要优化并发控制：

　　通过分段锁，降低了锁的粒度，提高了效率。SQL解析结果放入缓存，避免重复解析。

　　(二)缓存消除策略业务SQL复杂多变。如果每个SQL分析结果都缓存，会影响内存占用。因此，对于不同的SQL，有必要有相应的缓存失效策略：

　　参数化查询SQL解析结果永久缓存。默认情况下，字符串串联SQL解析的结果缓存1秒钟。如果在1秒内再次访问，消除时间将被刷新。缓存1秒避免了高并发场景下大量重复SQL解析带来的内存压力。因此，建议使用参数化查询SQL来提高性能。

　　管理层通过AOP拦截、解析、重写业务SQL，实现透明的数据加密。并发和缓存控制保证了框架的高性能。从而基本实现加密框架基本功能。但是业务使用有很多个性化的需求。比较重要的如下：

　　加密密钥获取定义了需要加密的表和字段。除了默认实现，上述1和2还需要支持自定义算法扩展功能。

　　因此，有必要定义一种方法来集中上述配置，这样可以更有效地进行管理。

　　(1) SPI机制服务提供者接口(SPI)是一种API，设计用于由第三方实现或扩展。它可以用来实现框架扩展或组件替换。通过用户实现框架提供的相应接口，将用户自定义的实现类动态加载到其中，在保持框架完整性和功能稳定性的同时，满足用户在不同场景下的实际需求。

　　框架提供了内置的加密和密钥获取实现类，用户只需配置后即可使用。另一方面，为了满足用户不同场景的需求，还开放了相关的加密和密钥获取接口，用户可以根据接口提供具体的实现类。简单配置后，框架可以调用用户自定义的加密和解密方案：

　　EncryptAlgorithm用于实现自定义加密算法：该接口提供encrypt()和decrypt()方法。当用户插入、删除、更新时，框架根据配置规则调用encrypt()对数据进行加密并存储在数据库中。当用户选择时，它调用decrypt()方法从数据库中反向解密加密的数据，最后将原始数据返回给用户。KeyGenerate用于实现自定义的密钥获取：该接口提供了Generate()方法。出于安全原因，不建议简单地将加密密钥存储在本地。一旦密钥泄露，可能会造成数据泄露的风险。所以建议集中管理密钥，然后在具体的实现类中通过generate()远程获取密钥。除了以上接口，后期还可以添加数据脱敏等接口。

　　(2)配置模式的定义。虽然SPI机制可以满足用户的个性化需求，但用户仍然需要学习如何通过编码将自己的实现类和其他规则配置到框架中的成本。因此，有必要定义一种配置模式，以便用户只需参考用户文档即可使用该框架。由于yaml是目前常用的配置格式，所以框架的配置也是基于yaml定义的。的具体配置内容如下：

　　加密规则：

　　Query_with_cipher_column: true #要使用密文列来

　　道具：#自定义参数，

　　key1: xx #

　　加密器：#加密模块设置

　　加密器a:

　　算法：#加密算法

　　名称：AES-CBC #指定使用的加密算法。

　　对称密钥：#密钥生成

　　Name: LOCAL #指定使用的密钥生成。

　　表格：#加密表格设置

　　帐户：#表名

　　列：

　　移动：#逻辑列

　　Plain_column: mobile #明文列

　　Cipher _ column:移动加密#密文列

　　Encryptor: encryptor-a #指定使用的加密模块。

　　Key_type: mobile #列类型，每种类型对应一个key (3) SQL处理流程。因此，在不考虑并发场景和添加配置管理的情况下，框架会将一个SQL处理流程转换为下图：

　　股票加密对于有历史明文数据的网上业务，需要实现业务系统在明文和密文数据之间的安全平滑迁移。

　　配置中定义了以下三个参数：

　　query_with_cipher_column是否使用密文列查询。Plain_column明文列。密文列。假设有一个名为account的旧历史表，需要对字段mobile和address进行加密。可以采取以下步骤来实现加密数据的平滑迁移。

　　(1)网上业务的改造-迁移前，在账户表中添加mobile_encrypted，address_encrypted用于存储密文数据，并做如下配置：

　　Plain_column设置为mobile，address。Cipher_column设置为mobile_encrypted，address_encrypted。query_with_cipher_column设置为false。此时，数据处理流程如下：

　　(2)在线业务转换迁移过程中，从上图可以看出，当query_with_cipher_column设置为false时，明文列和密文列双写，明文列用于查询。此时，用户可以通过脚本对股票数据进行清理和加密。然后将query_with_cipher_column设置为true。

　　此时，数据处理流程如下：

　　(3)在线业务转换-迁移后，从上图可以看出，当query_with_cipher_column设置为true时，明文列和密文列双写，密文列用于查询。系统稳定运行一段时间后，可以删除账表中的明文列，也可以删除配置中的plain_column。最终的数据只会被加密并存储在密文列中。

　　此时，数据处理流程如下：

　　(四)在线业务转换流程因此，在线业务数据的加密转换流程如下：

　　现在总结归纳文章开头提到的需求，看看是怎么解决的：

　　代码入侵少：SQL由AOP重写，加密和解密逻辑与业务代码和数据库框架解耦。低访问成本：用户只需少量的修改和配置就可以集成框架，而无需修改原有的业务逻辑。覆盖更多框架：基于数据库驱动层的拦截，不影响上层ORM框架的选择。高性能、高可用性：框架通过分段锁、缓存等性能优化手段，保证对业务性能几乎没有影响。去中心化将大大降低异常对业务线的影响。支持股票数据加密：通过灵活配置明文和密文列，业务系统可以在明文和密文数据之间安全平滑地迁移。版权归作者所有：原创作品来自博主小二上九8，转载请联系作者取得转载授权，否则将追究法律责任。

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。