아파치 ShardingSphere 데이터 탈감작은 전체 솔루션 상세

아파치 ShardingSphere 데이터 탈감작은 전체 솔루션 상세

저자에 관하여

팬 후안, 부문 수석 DBA의 Jingdong 번호, 가족 Jingdong 데이터베이스 미들웨어 개발, 운영 및 데이터베이스 자동화 플랫폼 개발, 운영 및 프로덕션 데이터베이스의 유지 보수 유지 보수의 수를 주로 담당하고 있습니다. Jingdong 6.18,11.11는 에스코트 작업과 다른 큰 홍보 활동에 참여하고있다. Jingdong 여러 가족 데이터베이스 자동화 플랫폼 설계 및 개발 프로젝트에 대한 책임이있다, 지금 아파치 ShardingSphere 데이터베이스 미들웨어 개발을 분산에 초점을 맞추고 있습니다. 학습 등 관련 분야를 데이터베이스, 자동화, 분산 미들웨어를 탐험 할 의사가 있슴.

한 배경

보안 제어 관리의 중요한 부분이었다, 데이터 보안 제어 탈감작이 범주에 속한다. 인터넷 기업, 전통 산업은 데이터 보안은 항상 매우 중요하고 민감한 주제를 부착하고있다. 데이터 탈감작은 탈감작에 의해 특정 민감한 정보 수정 규칙 데이터, 민감한 데이터의 개인 정보의 안정적인 보호를 의미합니다. 일부 상용 고객에게 같은 전화 번호, 카드 번호, 고객 번호 및 관련 부서의 규정에 따라 기타 개인 정보 등의 보안 데이터 나 민감한 데이터를 포함하는 데이터가 둔감 할 필요가있다.

실제 비즈니스 시나리오에서, 관련 사업 개발 팀은 종종 자기 암호화 시스템을 구현하고 유지하기 위해 회사의 보안 부서의 요구에 필요한, 장면이 탈감작을 변경하는 경우, 탈감작 자체 유지 보수 시스템은 종종 재건에 직면하고 있습니다 나 위험을 수정합니다. 또한, 이미 온라인 사업을 위해 어떻게 SQL 운영, 투명성, 보안의 경우,하지 않고 비즈니스 로직을 수정, 저 위험 탈감작 원활를 변환?

고충 및 비즈니스 변환의 탈감작에 대한 업계의 요구에 따라 아파치 ShardingSphere는 제공 업데이트 완료, 보안, 투명, 저렴한 비용으로 탈감작 데이터 통합 솔루션을.

두 이전 서론

아파치 ShardingSphere는 샤딩-JDBC, 샤딩 - 프록시 및 샤딩-사이드카 (계획) 서로 독립적이 3 구성 생태계 이루어지는 분산 데이터베이스 오픈 소스 미들웨어 솔루션 세트이지만, 하이브리드 배치와 함께 사용될 수있다 제품 구성. 그들은 표준화 된 데이터 조각, 분산 트랜잭션 및 다양한 자바 동종, 이종 언어, 용기 및 기타 클라우드 네이티브 응용 프로그램의 다양한 시나리오에 적용 할 수있다와 같은 분산 제어 기능을 제공 할 수 있습니다.

이러한 핵심 기능에서 ShardingSphere 서브 기능 모듈 속하는 둔감 분산 데이터 관리 모듈. 이것은 사용자로부터의 SQL 파싱을 수행하고, 기반 사용자가 제공 한 구성 탈감작 SQL 재기 때문에 원래의 데이터를 암호화하고 (선택적) 원본 데이터와 동시에 암호문 데이터는 내부 데이터베이스에 저장 달성하기. 사용자 데이터 쿼리를,이 암호문 데이터의 데이터베이스에서 제거하고 해독 할 때, 원래는 결국 해독 된 데이터는 사용자에게 백업 할 수 있습니다. 아파치 ShardingSphere 사용자가 같은 일반 데이터와 같은 탈감작 데이터의 사용과 구현 세부 사항의 데이터 탈감작에 초점을 맞출 필요가 없습니다 그래서 분산 데이터베이스 미들웨어 자동화 및 투명한 데이터 탈감작 방법. 또한, 모두 온라인 비즈니스 탈감작 개혁을, 또는 비즈니스 사용 탈감작 기능의 새로운 라인은 ShardingSphere은 상대적으로 완벽한 솔루션을 제공 할 수 있습니다.

셋째, 수요 시나리오 분석

데이터 탈감작 수요의 경우, 실제 비즈니스 시나리오는 일반적으로 두 가지 경우로 나누어집니다 :

1. 비즈니스의 새로운 라인은 보안 부문의 필요의 규정은 사용시, 다음 암호 해독 과정을 암호화와 같은 데이터베이스에 저장되어있는 등 은행, 전화 번호, 사용자 민감한 정보를 포함합니다. 시스템이 새로운이기 때문에, 그래서 구현하기가 비교적 간단하다, 재고 데이터 청소 문제가 없습니다.

2. 일반 텍스트 데이터베이스에 저장된 때까지, 온라인 사업이었다. 갑자기 관련 부서는 온라인 비즈니스 된 정류에 둔감 할 필요가있다. 이 장면은 일반적으로 세 가지 문제를 처리해야합니다

   가) 역사적 데이터는 탈감작 치료, 세척의 수를 할 필요가 방법.

   사용 후 해독을 제거, b)는 SQL 및 비즈니스 로직없이 변경 될 수있는 방법, 데이터 처리 및 데이터베이스에 저장된 둔감 추가합니다.

   C)은 평문과 암호문 데이터 사이의 구현보다 안전하고 원활하고 투명하게 마이그레이션 서비스 시스템이 얼마나.

넷째, 프로세스 흐름 상세

전체 아키텍처

암호화-JDBC와 ShardingSphere 제공하는 서비스 코드를 함께 배치했다. 파티 서비스는 암호화-JDBC JDBC 프로그래밍에 필요한. 암호화-JDBC 추가 변환을 사용하지 않고 모든 표준 JDBC 인터페이스, 비즈니스 코드를 구현하기 때문에 호환이 될 수 있습니다. 이 경우, 사업의 코드는 책임을 암호화-JDBC 언급 된 데이터베이스와의 모든 상호 작용을 실시하고 있습니다. 비즈니스는 탈감작 규칙을 제공합니다. 변환 동작 후 데이터베이스와 비즈니스 코드의 중간 및 기본 데이터베이스 다리, 암호화-JDBC 캔 요격 사용자 행동과 상호 작용한다.

Encrypt-JDBC将用户发起的SQL进行拦截，并通过SQL语法解析器进行解析、理解SQL行为，再依据用户传入的脱敏规则，找出需要脱敏的字段和所使用的加解密器对目标字段进行加解密处理后，再与底层数据库进行交互。

ShardingSphere会将用户请求的明文进行加密后存储到底层数据库；并在用户查询时，将密文从数据库中取出进行解密后返回给终端用户。

ShardingSphere通过屏蔽对数据的脱敏处理，使用户无需感知解析SQL、数据加密、数据解密的处理过程，就像在使用普通数据一样使用脱敏数据。

脱敏规则

在详解整套流程之前，我们需要先了解下脱敏规则与配置，这是认识整套流程的基础。脱敏配置主要分为四部分：数据源配置，加密器配置，脱敏表配置以及查询属性配置，其详情如下图所示：

数据源配置：是指DataSource的配置。

加密器配置：是指使用什么加密策略进行加解密。目前ShardingSphere内置了两种加解密策略：AES/MD5。用户还可以通过实现ShardingSphere提供的接口，自行实现一套加解密算法。

脱敏表配置：用于告诉ShardingSphere数据表里哪个列用于存储密文数据（cipherColumn）、哪个列用于存储明文数据（plainColumn）以及用户想使用哪个列进行SQL编写（logicColumn）。

如何理解用户想使用哪个列进行SQL编写（logicColumn）？

我们可以从Encrypt-JDBC存在的意义来理解。Encrypt-JDBC最终目的是希望屏蔽底层对数据的脱敏处理，也就是说我们不希望用户知道数据是如何被加解密的、如何将明文数据存储到plainColumn，将密文数据存储到cipherColumn。换句话说，我们不希望用户知道plainColumn和cipherColumn的存在和使用。所以，我们需要给用户提供一个概念意义上的列，这个列可以脱离底层数据库的真实列，它可以是数据库表里的一个真实列，也可以不是，从而使得用户可以随意改变底层数据库的plainColumn和cipherColumn的列名。或者删除plainColumn，选择永远不再存储明文，只存储密文。只要用户的SQL面向这个逻辑列进行编写，并在脱敏规则里给出logicColumn和plainColumn、cipherColumn之间正确的映射关系即可。

为什么要这么做呢？答案在文章后面，即为了让已上线的业务能无缝、透明、安全地进行数据脱敏迁移。

查询属性的配置：当底层数据库表里同时存储了明文数据、密文数据后，该属性开关用于决定是直接查询数据库表里的明文数据进行返回，还是查询密文数据通过Encrypt-JDBC解密后返回。

脱敏处理过程

举个栗子，假如数据库里有一张表叫做t_user，这张表里实际有两个字段pwd_plain，用于存放明文数据、pwd_cipher，用于存放密文数据，同时定义logicColumn为pwd。那么，用户在编写SQL时应该面向logicColumn进行编写，即INSERT INTO t_user SET pwd = '123'。ShardingSphere接收到该SQL，通过用户提供的脱敏配置，发现pwd是logicColumn，于是便对逻辑列及其对应的明文数据进行脱敏处理。可以看出ShardingSphere将面向用户的逻辑列与面向底层数据库的明文列和密文列进行了列名以及数据的脱敏映射转换。如下图所示：

这也正是Encrypt-JDBC核心意义所在，即依据用户提供的脱敏规则，将用户SQL与底层数据表结构割裂开来，使得用户的SQL编写不再依赖于真实的数据库表结构。而用户与底层数据库之间的衔接、映射、转换交由ShardingSphere进行处理。为什么我们要这么做？还是那句话：为了让已上线的业务能无缝、透明、安全地进行数据脱敏迁移。

为了让读者更清晰了解到Encrypt-JDBC的核心处理流程，下方图片展示了使用Encrypt-JDBC进行增删改查时，其中的处理流程和转换逻辑，如下图所示。

五、解决方案详解

在了解了ShardingSphere脱敏处理流程后，即可将脱敏配置、脱敏处理流程与实际场景进行结合。所有的设计开发都是为了解决业务场景遇到的痛点。那么面对之前提到的业务场景需求，又应该如何使用ShardingSphere这把利器来满足业务需求呢？

新上线业务

业务场景分析：新上线业务由于一切从零开始，不存在历史数据清洗问题，所以相对简单。

解决方案说明：选择合适的加密器，如AES后，只需配置逻辑列（面向用户编写SQL）和密文列（数据表存密文数据）即可，逻辑列和密文列可以相同也可以不同。建议配置如下（Yaml格式展示）：

encryptRule:
  encryptors:
    aes_encryptor:      type: aes
      props:
        aes.key.value: 123456abc
  tables:
    t_user:
      columns:        pwd:
          cipherColumn: pwd
          encryptor: aes_encryptor

使用这套配置，Encrypt-JDBC只需将logicColumn和cipherColumn进行转换，底层数据表不存储明文，只存储了密文，这也是安全审计部分的要求所在。如果用户希望将明文、密文一同存储到数据库，只需添加plainColumn配置即可。整体处理流程如下图所示：

已上线业务改造

业务场景分析：由于业务已经在线上运行，数据库里必然存有大量明文历史数据。现在的问题是如何让历史数据得以加密清洗、如何让增量数据得以加密处理、如何让业务在新旧两套数据系统之间进行无缝、透明化迁移。

解决方案说明：在提供解决方案之前，我们先来头脑风暴一下：首先，既然是旧业务需要进行脱敏改造，那一定存储了非常重要且敏感的信息。这些信息含金量高且业务相对基础重要。如果搞错了，整个团队KPI就再见了。所以不可能一上来就停业务，禁止新数据写入，再找个加密器把历史数据全部加密清洗，再把之前重构的代码部署上线，使其能把存量和增量数据进行在线加密解密。如此简单粗暴的方式，按照历史经验来谈，一定凉凉。

那么另一种相对安全的做法是：重新搭建一套和生产环境一模一样的预发环境，然后通过相关迁移洗数工具把生产环境的存量原文数据加密后存储到预发环境，而新增数据则通过例如MySQL主从复制及业务方自行开发的工具加密后存储到预发环境的数据库里，再把重构后可以进行加解密的代码部署到预发环境。这样生产环境是一套以明文为核心的查询修改的环境；预发环境是一套以密文为核心加解密查询修改的环境。在对比一段时间无误后，可以夜间操作将生产流量切到预发环境中。此方案相对安全可靠，只是时间、人力、资金、成本较高，主要包括：预发环境搭建、生产代码整改、相关辅助工具开发等。除非无路可走，否则业务开发人员一般是从入门到放弃。

业务开发人员最希望的做法是：减少资金费用的承担、最好不要修改业务代码、能够安全平滑迁移系统。于是，ShardingSphere的脱敏功能模块便应用而生。可分为三步进行：

1. 系统迁移前

   假设系统需要对t_user的pwd字段进行脱敏处理，业务方使用Encrypt-JDBC来代替标准化的JDBC接口，此举基本不需要额外改造（我们还提供了SpringBoot，SpringNameSpace，Yaml等接入方式，满足不同业务方需求）。另外，提供一套脱敏配置规则，如下所示：

   encryptRule:  encryptors:    aes_encryptor:      type: aes
         props:        aes.key.value: 123456abc
     tables:    t_user:      columns:        pwd:          plainColumn: pwd
             cipherColumn: pwd_cipher
             encryptor: aes_encryptorprops:    query.with.cipher.column: false

   依据上述脱敏规则可知，首先需要在数据库表t_user里新增一个字段叫做pwd_cipher，即cipherColumn，用于存放密文数据，同时我们把plainColumn设置为pwd，用于存放明文数据，而把logicColumn也设置为pwd。由于之前的代码SQL就是使用pwd进行编写，即面向逻辑列进行SQL编写，所以业务代码无需改动。通过Encrypt-JDBC，针对新增的数据，会把明文写到pwd列，并同时把明文进行加密存储到pwd_cipher列。此时，由于query.with.cipher.column设置为false，对业务应用来说，依旧使用pwd这一明文列进行查询存储，却在底层数据库表pwd_cipher上额外存储了新增数据的密文数据，其处理流程如下图所示：

   

   新增数据在插入时，就通过Encrypt-JDBC加密为密文数据，并被存储到了cipherColumn。而现在就需要处理历史明文存量数据。由于Apache ShardingSphere目前并未提供相关迁移洗数工具，此时需要业务方自行将pwd中的明文数据进行加密处理存储到pwd_cipher。

2. 系统迁移中

   新增的数据已被Encrypt-JDBC将密文存储到密文列，明文存储到明文列；历史数据被业务方自行加密清洗后，将密文也存储到密文列。也就是说现在的数据库里即存放着明文也存放着密文，只是由于配置项中的query.with.cipher.column=false，所以密文一直没有被使用过。现在我们为了让系统能切到密文数据进行查询，需要将脱敏配置中的query.with.cipher.column设置为true。在重启系统后，我们发现系统业务一切正常，但是Encrypt-JDBC已经开始从数据库里取出密文列的数据，解密后返回给用户；而对于用户的增删改需求，则依旧会把原文数据存储到明文列，加密后密文数据存储到密文列。

   虽然现在业务系统通过将密文列的数据取出，解密后返回；但是，在存储的时候仍旧会存一份原文数据到明文列，这是为什么呢？答案是：为了能够进行系统回滚。因为只要密文和明文永远同时存在，我们就可以通过开关项配置自由将业务查询切换到cipherColumn或plainColumn。也就是说，如果将系统切到密文列进行查询时，发现系统报错，需要回滚。那么只需将query.with.cipher.column=false，Encrypt-JDBC将会还原，即又重新开始使用plainColumn进行查询。处理流程如下图所示：

   

3. 系统迁移后

   由于安全审计部门要求，业务系统一般不可能让数据库的明文列和密文列永久同步保留，我们需要在系统稳定后将明文列数据删除。即我们需要在系统迁移后将plainColumn，即pwd进行删除。那问题来了，现在业务代码都是面向pwd进行编写SQL的，把底层数据表中的存放明文的pwd删除了，换用pwd_cipher进行解密得到原文数据，那岂不是意味着业务方需要整改所有SQL，从而不使用即将要被删除的pwd列？还记得我们Encrypt-JDBC的核心意义所在吗？

   这也正是Encrypt-JDBC核心意义所在，即依据用户提供的脱敏规则，将用户SQL与底层数据库表结构割裂开来，使得用户的SQL编写不再依赖于真实的数据库表结构。而用户与底层数据库之间的衔接、映射、转换交由ShardingSphere进行处理。

   是的，因为有logicColumn存在，用户的编写SQL都面向这个虚拟列，Encrypt-JDBC就可以把这个逻辑列和底层数据表中的密文列进行映射转换。于是迁移后的脱敏配置即为：

   encryptRule:  encryptors:    aes_encryptor:      type: aes
         props:        aes.key.value: 123456abc
     tables:    t_user:      columns:        pwd: # pwd与pwd_cipher的转换映射          cipherColumn: pwd_cipher
             encryptor: aes_encryptor
    props:    query.with.cipher.column: true

   其处理流程如下：

   

至此，已在线业务脱敏整改解决方案全部叙述完毕。我们提供了Java、Yaml、SpringBoot、SpringNameSpace多种方式供用户选择接入，力求满足业务不同的接入需求。该解决方案目前已在京东数科不断落地上线，提供对内基础服务支撑。郑州治疗不孕不育哪里好：http://www.zzfkyy120.com/

六、中间件脱敏服务优势

1. 自动化&透明化数据脱敏过程，用户无需关注脱敏中间实现细节。

2. 提供多种内置、第三方(AKS)的脱敏策略，用户仅需简单配置即可使用。

3. 提供脱敏策略API接口，用户可实现接口，从而使用自定义脱敏策略进行数据脱敏。焦作国医胃肠医院好不好：http://jz.lieju.com/zhuankeyiyuan/37756433.htm

4. 支持切换不同的脱敏策略。

5. 针对已上线业务，可实现明文数据与密文数据同步存储，并通过配置决定使用明文列还是密文列进行查询。可实现在不改变业务查询SQL前提下，已上线系统对加密前后数据进行安全、透明化迁移。

七、适用场景说明

1. 用户项目使用Java语言进行编程。

2. 后端数据库为MySQL、Oracle、PostgreSQL、SQLServer。

3. 用户需要对数据库表中某个或多个列进行脱敏(数据加密&解密)。

4. 兼容所有常用SQL；

八、限制条件

1. 用户需要自行处理数据库中原始的存量数据、洗数。

2. 使用脱敏功能+分库分表功能，部分特殊SQL不支持，请参考SQL使用规范。

3. 脱敏字段无法支持比较操作，如：大于小于、ORDER BY、BETWEEN、LIKE等

4. 脱敏字段无法支持计算操作，如：AVG、SUM以及计算表达式

九、后续

本篇文章介绍了如何使用ShardingSphere产品之一的Encrypt-JDBC进行接入，接入形式还可以选择使用SpringBoot、SpringNameSpace等，这种形态的接入端主要面向JAVA同构，并与业务代码共同部署在生产环境中。面向异构语言，ShardingSphere还提供Encrypt-Proxy客户端。Encrypt-Proxy是一款实现MySQL、PostgreSQL的二进制协议的服务器端产品，用户可独立部署Encrypt-Proxy服务，并且像使用普通MySQL、PostgreSQL数据库一样，使用例如Navicat第三方数据库管理工具、JAVA连接池、命令行的方式访问这台具有脱敏功能的虚拟数据库服务器。

아파치 ShardingSphere의 기능 범위에 속하는 탈감작 기능 관리를 배포했습니다. 사실, 아파치 ShardingSphere이 생태계는 또한 데이터 단편화, 별도의 읽기 및 쓰기, 분산 트랜잭션, 모니터 관리와 같은 다른 더 강력한 기능을 가지고 있습니다. 심지어 사용 중첩되는 기능 모듈의 임의의 수를 선택할 수 데이터 슬라이스 데이터 둔감 +, + 또는 별도의 판독 및 기록 데이터 부분을 사용하고 모니터링하거나 제어 + 데이터 피스 등하면서, 예를 들어,. 선택된 기능 레벨을 오버레이 외에도 ShardingSphere 액세스 단말기는 다양한 형태, 예컨대 샤딩-JDBC 샤딩 - 프록시 또는 다른 시나리오의 사람들의 요구를 충족시키기 등을 제공한다 .

마지막에 X. 글

초기 서브 라이브러리 서브 테이블 함수로부터, 지금까지 ShardingSphere 지원 트랜잭션 기반 등 생태계 분산 코어 데이터 단편화 기능 분산 제어를 포함하여 형성. 또한 그것은 그것보다 단지 분산 데이터베이스 미들웨어 이상으로 식별뿐만 아니라 하위 라이브러리 하위 테이블에 능력이있다,뿐만 아니라 포괄적 인 솔루션 에코 시스템의 핵심으로 데이터 단편화, 분산 제어, 분산 트랜잭션을 형성 의에 오신 것을 환영 하는 공식 웹 사이트 에서 자세히 알아 GitHub의 ☺ 우리를 따르라!