首页 > 安全保障 > JOS数据加解密对接文档指南

JOS数据加解密对接文档指南

一.概述和对接流程

1.1 产品背景

业务核心资产:数据、数据、还是数据
安全事件频发:消费者数据泄漏、商家对服务商的信任危机与公关危机等
现有管控局限大:生态链路中不可控的系统或应用,管控成本越来越高

1.2 产品简介

产品名称 :数据加解密服务
本产品提供针对消费者敏感数据存储的加密能力,用于防止因外部或内部安全威胁所导致的数据泄露问题,从而提高数据安全的防护水平。

价值主张:

a、基础安全保障
加解密从根本上夯实了数据安全性。对敏感字段加密后,可以有效防止数据库内容 被直接盗取。且密钥以用户维度隔离,有效解决应用的水平权限隔离问题。
b、数据库内容和密钥存储管理分离
开发者的云主机和云数据库中只存储加密数据,不保存密钥。只需接入本产品提供的SDK,密钥在开发者应用运行过程中动态的向宙斯发起动态请求。这在增强安全系数的同时,也简化了开发者管理、存储密钥的成本。
c、安全与服务平滑性兼得
SDK
提供智能的、丰富的api可以自动识别数据库中存量密文的版本、自动加密、解密。开发者接入我们的SDK后,可以做到在不停服务的条件下做密钥升级。
d、接入简单便捷
加解密方案不依赖硬件,加解密SDK集成在现有SDK中,对数据库无特殊要求,使用成本、改造成本低。


1.3 产品技术架构
1.3.1 
产品架构:

1.3.2 技术架构:

a、开发者调用宙斯API返回的是加密数据

b、开发者在自己的数据库中以密文方式储存敏感信息,直到需要使用的时候,再调用SDK进行解密。为了降低密钥被盗取的风险,密钥是用户粒度的,也就是每个用户的数据都是用不同的密钥加密的。

c、在应用中需要对敏感信息进行展示等操作时,调用SDK中提供的解密函数进行解密。SDK会自动从宙斯API获取对应的密钥。此外,密钥的网络请求、管理和本地缓存也会自动由SDK完成。


d、开发者需要根据自己的应用业务逻辑改造代码、接入本产品的SDK,通过本产品提供的SDK中的加密、解密等API完成敏感数据的加解密转换。

1.4 接入流程:

1.4.1 在线提交开通服务申请入口(点我访问,业务类型选择:JOS-数据加解密对接-开通加解密(截图一)),在问题描述中提供加解密应用的APPKEY,下面电话栏,邮箱栏以次提供对应信息(截图二),后期运营将回复与沟通。开通后,将在控制台里的应用管理里看到“安全中心-数据加解密”。

截图一(由于目前没有全量开放,请在拿到APPKEY时联系业务线运营增加加解密权限)

截图二

1.4.2 应用代码开发:开发者需要根据自己的应用业务逻辑改造代码,接入SDK进行加解密处理。


1.4.3 灰度发布上线
:为了降低接入过程导致的使用风险,支持开发者进行单个应用下的用户级别的白名单接入配置,白名单内的用户试用成功后,再进行全部用户切换。

1.4.4 平台验收
:开发者开发完成上线并已自己完成第1个自己测试店铺后,根据平台的验收模板(最下面六、附录:附件一:数据加解密验收文件模板)提交相关的验收资料压缩包(点我提交,业务类型填写:JOS-数据加解密对接-加解密验收(截图一)),在工单中增加附件,提交【数据加解密验收文件】和手机号、邮箱并配合平台进行验收(截图二)。

截图一

截图二

1.4.5 全部正式上线:单个应用灰度成功后,全部切换到“全店铺加密”,正式上线后,需要针对数据库里的明文字段数据进行一次全面的加密清洗,确保敏感字段数据都加密存储。

1.5.整改须知


1.5.1
整改范围


当您的应用获取平台中涉及消费者的隐私数据(包括但不限于:消费者的姓名、电话、收货地址等)时,您的应用就应对这些敏感的消费者隐私数据进行存储加密,具体可参考平台定义的敏感API列表


1.5.2
整改要求


a. 平台已明确要求对涉及存储消费者隐私数据获取的应用进行存储加密,否则将依据其平台相关规则对违规者进行处罚,具体请参考:第三方服务安全开发规京东服务市场违规处罚规中的相关内容

b. 处罚依据:该应用系统通过appkey或相关权限获取并存储京东平台用户的隐私数据时,未按照官方认可的安全方案对其存储的用户隐私数据进行安全加密。

c. 处罚措施:请参考:第三方服务安全开发规 京东服务市场违规处罚规的处理办法。

1.6 在线支持
如有任何疑问,可通过以下方式联系并获得帮助:
在线支持中心:点我访问 ,业务类型:JOS-数据加解密对接-加解密对接问题反馈,进行问题反馈;





二.应用代码开发

2.1 准备工作

2.1.1 访问权限申请

    默认相关接口权限已开通,如有问题请提交工单;

2.1.2 确定需要改造的敏感API列表和敏感字段列表
您通过自己调用的接口列表与平台提供的敏感接口列表进行交叉匹配出将需要改造的敏感接口和字段。平台提供的敏感接口列表和敏感字段如下https://open.jd.com/home/home#/doc/common?listId=377


2.2 下载最新SDK
目前已支持Java版本,后续将支持PHP版本和.NET版本等。

下载SDK方式请参考文档https://open.jd.com/home/home#/doc/common?listId=842
加解密源码目录:open-api-sdk\src\main\java\com\jd\security

2.3 加解密流程

当您获得到敏感接口返回的加密数据后,在接口中Number类型字段表现为encrypt_开头的字段(其他类型字段不变),例如接口返回列名中有姓名phoneNumber字段,那么在您完全接入加解密产品后,该字段会为NULL,但是encrypt_phoneNumber字段有密文值,如需获取明文值,请调用解密方法获得明文,直接将密文存入数据库,等用时在解密。


2.4 开发说明 


2.4.1 解密接口仅限于业务应用,在接入完成后,不允许将解密结果明文存入数据库;
2.4.2 
相同数据每次网关返回的加密结果不同,所以密文字段不能用于索引检索;
2.4.3 密文串解密的结果为byte数组,使用UTF-8编码;
2.4.4 SecretJdClient为密钥管理的实现类,用于抽象封装密钥生命周期相关的底层逻辑,用于用户解密和数据库唯一索引生成,数据接口仍然需要使用DefaultJdClient请求;
2.4.5 不同用户token使用的密钥不同,即每一个token对应一个TDEClient并缓存在本地,请预估业务量防止OOM
2.4.6 设原文长度为Xbyte未经编码的密文长度为 Ybyte Y=X/16*16 +50 意思是:原文长度除16向下取整得到的结果剩16 ,得到的值加50。密文经过base64编码后,最终得到的密文字符个数Z Z=Y/3*4Y/3的意思是Y除以3向上取整。因为base64是把38位变48位相当于会增加33%的长度。   
2.4.7 SecretJdClient默认会启用两个后台线程, jd-sdk-secret-flush-thread用于定时刷新密钥保证密钥的有效性,jd-sdk-api-report-thread用于解密接口的调用统计情况上报,我们只统计调用次数,异常等信息用于风险统计,不会统计任何隐私数据。
2.4.8 TDEClient对象实例不要自行建立缓存机制,特别注意不要将该实例存放到成员变量中,每次使用的时候请通过SecretJdClient.getInstance()获取,底层封装了缓存逻辑,不必担心性能问题,如果应用程序自行缓存了TDEClient会导致SDK底层缓存过期机制失效,并有可能导致引用不释放引发内存泄露。

2.5 代码演示


2.5.1 
加解密场景
public static void testDataEncryptOrDecrypt() throws Exception {
/*
*
请求宙斯网关获取凭证和密钥
* 1
、凭证和密钥缓存本地(用于数据加解密)
* 2
、数据来源于请求宙斯网关API敏感字段值
* 3
、数据加解密案例如下
*/
TDEClient tdeClient = SecretJdClient.
getInstance("https://api.jd.com/routerjson","accessToken","appKey",
"appSecret");

String type = "phone";
String plaintext = "16612341234";

//
加密手机号
String ciphertext = tdeClient.encryptString(plaintext);
System.out.println(type + "
明文:" + plaintext + ">密文:" + ciphertext);

//
判断是否为加密手机号码数据

if(tdeClient.isEncryptData(ciphertext))) {

//解密手机号
plaintext = new String(tdeClient.decrypt(ciphertext), "UTF-8");
System.out.println(type + "
密文:" + ciphertext + ">明文:" + plaintext);
}
}

输出结果:
phone
明文:16612341234>密文:AATGzmuhp0shxEHC2L6ZT2Tb72WeryMLG4Wy/+p7+hDS/CEdmAE=
phone
密文:AATGzmuhp0shxEHC2L6ZT2Tb72WeryMLG4Wy/+p7+hDS/CEdmAE=>明文:16612341234

2.6 注意事项


a. 不允许存储密钥
b. 
不允许存储解密结果明文



三.店铺加密白名单管理

已开通权限可进入的管理页面图


3.1 配置白名单

    开发者针对需要改造的敏感API列表和敏感字段列表进行系统改造后,需要进行灰度发布,避免一刀切可能影响所有商家。开启全部店铺加密配置前,请在多个测试店铺充分的测试后,确保应用明密文兼容,数据流转没有问题。开启全部店铺加密配置后,应用的全部授权店铺将敏感数据出参皆为密文,不再是明文,同时白名单将全部失效,并且无法退回到未开启状态,请谨慎操作。
   
店铺帐号通过登录授权后开发者应用可获取到店铺帐号token”,开发者通过这个token可调用宙斯接口获取店铺相关的数据,获取token方式可参考https://open.jd.com/home/home#/doc/common?listId=152 店铺帐号token”即为文档说明的Access token,此token有一定的期限,通过服务市场授权应用,Access token期限以购买周期为准。当Access token过期时,用户可以到京麦服务市场重新购买应用,用户重新授权后的新token不需要重新添加到白名单,同样能进行加解密操作。

3.2 注意事项


1) 
白名单: 填写白名单就是配置测试店铺,点击保存后会立即生效,所有敏感出参会为密文。
2) 
测试店铺配置可以同时配置多个店铺,注意配置的店铺不要超过 512个 。
3) 
白名单用户列表是添加店铺的主账号。
4) 
已增加白名单不允许删除。
5) 
执行全部店铺加密之前,请至少成功添加一个店铺加密白名单。


四.典型方案

4.1 Number字段类型加密方案
4.1.1 
背景

目前明文通过AES加密之后变成一串Base64的字符串,这种情况下SDK转换会报错,而且可能跟db存储的类型不匹配。

例如:jingdong.pop.loc.broadband.order.findPage接口的phone_number加密字段是Number类型。

问题:

a ) 老版本SDK

public class PopLocBroadbandOrderFindPageResponse  extends AbstractResponse{

private  PageResult  findpageResult;

}

public class PageResult implements Serializable{

  其他字段。。

  private  java.util.List<BroadBandOrderInfo>  data;

其他字段

}

public class BroadBandOrderInfo implements Serializable {

其他字段。。

       private  java.lang.Long  phoneNumber;

其他字段

}

   b )  加密后的信息格式AATGzmuhp0shxEHC2L6ZT2TbFRBAsDJlQtZR3YrbzFAlacgLPBc=

       c ) 从“AATGzmuhp0shxEHC2L6ZT2TbFRBAsDJlQtZR3YrbzFAlacgLPBc=” 转换到phoneNumber失败。


4.1.2 解决方案

加密逻辑变更:

阶段1Token白名单):加密请求,在返回密文的同时也返回明文,用于开发者做切换。
api
返回加密结果:{"phone_number"=12345678910, "encrypt_phone_number"=加密(12345678910)} // 新增一个返回字段 encrypt_phone_number

阶段2(全店铺加密):加密请求,不返回Number类型明文字段(相当于明文字段作废)。
api
返回加密结果:{“phone_number”=null, "encrypt_phone_number "=加密(12345678910)}

开发者需要做以下几件事情:

a) 下载最新版本SDK
public class BroadBandOrderInfo implements Serializable {
private java.lang.Long phoneNumber;
private java.lang.String encryptPhoneNumber;
其他字段
}

b) 开发者判断下对应的DB字段(phone_number)是否数字类型, 如果是数字类型:
需要新增string类型字段存储,老数据迁移到新字段。 如果DB已是string类型的则忽略。

c) encrypt_phone_number字段做为 phone_number 存储。

4.2 密文字段检索方案

4.2.1 背景
应用在查询页面里,有针对敏感字段进行查询的功能,而这些敏感字段数据加密后不能直接进行匹配检索的,因为每次加密后的数据值是不一样的。所以提供以下相关的方案供开发者进行处理。

4.2.2精确查询场景的解决方案
    TDEClient.calculateStringIndex("data".getBytes("utf-8"));
    如果您需要对一个字段进行精确的检索,那么需要创建一个新字段(索引列)来存储索引值,索引值采用SHA-256进行加密。

    a、基于安全设计相同的明文密文不同,所以需要建立一列不可逆并且与明文一一对应的值用作索引,可以调用接口calculateStringIndex,使用明文精确查询时先经过calculateStringIndex运算得到索引值,再从新增的索引列匹配到要查询的行。
    b、计算索引列使用信息摘要算法,不可逆,并且要使用明文数据计算索引并存入库。

4.2.3“模糊查询场景的解决方案
    支持两种类型的关键字搜索场景:
    a)一种类型为固定格式的关键字搜索,比如手机号码:4127204557
    1.可搜索412
    2.搜索***720 (***为任意三个ascii字符串)
    3.搜索**272 (**为任意两个ascii字符串)
    4.*代表一个wildcard ascii字符,但仅能在prefix(字串)
    

    b)搜索任意子字符串,针对住址特別有用,举例来说,针对明文:北京朝阳区北辰西路8号院1号楼
    1.搜索北京
    2.搜索朝阳
    3.搜索北辰西路
    4.搜索1号楼
    

    解决方案1:
WildCard Prefix关键字搜索 (搜索功能较固定,但安全性较强)
1.public String obtainWildCardKeyWordIndex(String spt) throws NoValidKeyException, IndexCalculateException
spt:
明文字符串,默認編碼為UTF-8,但字符必須為ascii字符,適用於手機號與身分證號碼(格式長度已固定)
回傳hexwildcard索引字串 (明文長度兩倍)
2.public String calculateWildCardKeyWord(String queryW) throws NoValidKeyException, IndexCalculateException
queryW:
搜索字符串,默認編碼為UTF-8
回傳hexkeyword wildcard索引字串 (明文長度兩倍)
    

    解决方案2:
任意子字符串关键字搜索(功能较强,但安全性较弱)
    a.public String obtainKeyWordIndex(String spt) throws NoValidKeyException, IndexCalculateException
spt:
明文字符串,默认编码为UTF-8,适用于UTF-8字符,适用于姓名与地址搜索(长度未知格式)
回传hexwildcard索引字串 (约明文长度两倍)

    b.public String calculateKeyWord(String queryW) throws NoValidKeyException, IndexCalculateException
    

    代码演示:
TDEClient c1 = null;
try { 
c1=SecretJdClient.getInstance("https://api.jd.com/routerjson",accessToken, appKey, appSecret);
String plaintext = "4127204557";
String indexW = c1.obtainWildCardKeyWordIndex(plaintext);
// indexW为97362FB245E58C62DDC4
String subplaintext = "412";
String queryW = c1.calculateWildCardKeyWord(subplaintext);
// queryW 为97362F
// (
可直接在SQL query时采用%queryW%方式查询)
// queryW
indexW的子字串
Assert.assertTrue(indexW.contains(queryW)); 

subplaintext = "413";
queryW = c1.calculateWildCardKeyWord(subplaintext);
// queryW 为97362E
Assert.assertFalse(indexW.contains(queryW));

subplaintext = "***720";
queryW = c1.calculateWildCardKeyWord(subplaintext);
// queryW 为B245E5
Assert.assertTrue(indexW.contains(queryW));

subplaintext = "**720";
queryW = c1.calculateWildCardKeyWord(subplaintext);
// queryW 为2AB747
Assert.assertFalse(indexW.contains(queryW));
subplaintext = "*127";
queryW = c1.calculateWildCardKeyWord(subplaintext);
// queryW 为362FB2 
Assert.assertTrue(indexW.contains(queryW));
subplaintext = "******4557";
queryW = c1.calculateWildCardKeyWord(subplaintext);
// queryW 为8C62DDC4
Assert.assertTrue(indexW.contains(queryW));
} catch (Exception e) {
e.printStackTrace();
fail("Should not throw exceptions here.");
}
try {
c1=SecretJdClient.getInstance("https://api.jd.com/routerjson",accessToken, appKey, appSecret);
String plaintext = "尔克孜自治州1272F";
String indexW = c1.obtainKeyWordIndex(plaintext);
// indexW = RreJFARoKWFARqqBFAS4C31wRbWmAQRrCDFAkkqZFAkYOMjQlOxjfQS56C1wkYOMjQ5QLDC
String subplaintext = "自治州";
String queryW = c1.calculateKeyWord(subplaintext);
// queryW = S4C31wRbWmAQRrCDFA
// (可直接在SQL query时采用%queryW%方式查询)
// queryW
indexW的子字串
Assert.assertTrue(indexW.contains(queryW));
subplaintext = "尔克孜自治州";
queryW = c1.calculateKeyWord(subplaintext);
// queryW = RreJFARoKWFARqqBFAS4C31wRbWmAQRrCDFA
Assert.assertTrue(indexW.contains(queryW));

subplaintext = "
克克";
queryW = c1.calculateKeyWord(subplaintext);
// queryW = RoKWFARoKWFA
Assert.assertFalse(indexW.contains(queryW));
subplaintext = "2F";
queryW = c1.calculateKeyWord(subplaintext);
// queryW = kYOMjQ5QLDCg
Assert.assertTrue(indexW.contains(queryW));
subplaintext = "125";
queryW = c1.calculateKeyWord(subplaintext);
// queryW = kkqZFAkYOMjQltQlbgS56C1w
Assert.assertFalse(indexW.contains(queryW));
} catch (Exception e) {
e.printStackTrace();
fail("Should not throw exceptions here.");

    使用场景说明:
a.obtainWildCardKeyWordIndex/calculateWildCardKeyWord 
建议使用在已知固定format,例如说手机号码与身份证号,然后透过wildcard来进行搜索,像是***123。编码为hex string,长度为明文两倍。

b.obtainKeyWordIndex/calculateKeyWord
建议使用在住址/姓名等无法预期先知道的格式。长度约为明文两倍(中文字符为两倍,ASCII, alphanumeric变成4倍,根据组成会有所变化)

4.3 历史数据迁移方案

4.3.1 背景
在线上加密覆盖到全量用户后,接下去的一个重要步骤就是要把历史数据全量加密。

4.3.2 解决方案
准备工作:
a.
请确认代码逻辑已经做好明文和密文的兼容。

b.确认加密开关已打开。
c.
确认从云数据库和JOS API新流入的数据已经是密文的。

数据迁移建议方案:
在确认容错逻辑已完成后进行迁移。先进行少量客户迁移测试之后,可以进行全量迁移测试。

a)首先单个客户数据迁移测试
借用迁移1个客户的机会测试迁移方案。建议迁移量<100万。可以先从较低的并发数开始。例如:并发5-10个线程。
提前记录平时的性能;记录迁移期间再记录迁移时间、迁移过程中的云数据库的IOPS/连接/CPU/TPS/QPS等,和平时的性能做比较。

b)迁移方案
根据前期计算好的迁移速度,计算迁移时间和方案。
首先确定迁移的最小粒度:例如,独立部署的ISV,则可决定一个部署为一个最小粒度。兼顾功能的独立性,以及迁移的总时长(控制在3个小时以内)。
第一天进行迁移时,继续记录数据量、时间……等。
如果迁移过程顺利无问题、且性能负载可以承受,可以在之后逐渐增加线程数。之后,可在第一天的基础上逐步增加线程数和迁移并发数。注意持续监测数据库性能。直至迁移完成。

c)代码逻辑注意
仅当用户token有效的,并且用户状态没有过期才能拉取到密钥。在迁移过程中,请排除已经过期token和无效的用户(即:冻结、清退等)。否则造成大量失败的密钥请求,且加密失败。
从数据库中拉取用户数据并加密的时候,请注意控制分页大小。



五.常见问题

1.SDK-问题
Q
目前加解密SDK支持哪些开发语言?
A
:目前有Java版本,后续将支持PHP版本和.NET版本等。

QSDK自研是否可行,需要遵守什么规范?
A
:本期暂时不支持,后续会考虑支持。

Q加密后的字段长度有多少? 
A
:设原文长度为Xbyte,未经编码的密文长度为 YbyteY=
X/16*16 +50,意思是:原文长度除16向下取整得到的结果剩16 ,得到的值加50。密文经过base64编码后,最终得到的密文字符个数ZZ=Y/3*4Y/3的意思是Y除以3向上取整。因为base64是把38位变48位相当于会增加33%的长度。


Q:同一个敏感字段值,宙斯网关每次返回的加密值是不一样的吗? 
A
:是的,每次加密的结果是不一样的。

2.店铺加密白名单问题
Q:
全店铺加密后,如果还有问题怎么办?能不能取消后再处理?
A
:可联系运营进行紧急管理处理。

Q:开启店铺加密是所有用户一起开还是可以先开放几个用户测试一下?
A
:按店铺维度进行加密,所以可以先开几个用户的加密进行测试,在加密白名单处可以自行配置。在开启全部店铺加密之前,最好能够填100个左右用户到加密列表中公测,避免测试不够完善导致全部开启后大批量用户不能使用。

Q:开启全店铺加密需要注意什么?
A
:全店铺加密开启后APP下所有授权用户的敏感出参全部为密文。 
所以开启全店铺加密之前,请先确认几个点:
1
、是否测试店铺加解密都没有问题。
2
、是否在程序中做了明密文兼容。
注意:开启全店铺后,这个app下有授权的店铺将全部开启密文方式。

Q:点击全店铺加密后多久全部生效?
A
:非及时生效,根据token的数量会有一定时间的延迟。

3.密钥问题
Q:
密钥如何获取,是否要定期升级?
A
:密钥是加、解密数据的关键,密钥不会定期升级,但是如果密钥存在泄漏风险,需要您配合升级密钥。 密钥的获取是通过SDK中加解密过程中自动获取的。

Q:加解密对计算的影响?
A
:用户秘钥命中缓存情况下:单台服务器加/解密单条数据耗时约0.03ms。 在密钥更新导致未命中缓存情况下,此时SDK需要通过接口获取最新密钥(包含重启服务,定时更新密钥),平均耗时约100ms

Q:调用加解密是否有频次限制?双11的时候会不会出现调用瓶颈?
A
:与加解密相关的接口调用次数与appkey的限流总次数有关。另外,加密解密函数的密钥有本地缓存策略,QPS单线程可达到30000次加密或解密。

Q:卖家更换名字后,密钥会变化吗?
A
:不会,密钥是根据卖家用户pin+appkey生成的,因为用户pin是唯一的,不会因修改名称后而变更。

Q:数据迁移是否要终止服务?
A
:数据迁移过程中,数据库中可能存在明文、密文,老密钥和新密钥的加密数据。考虑到这些因素只要做好代码的兼容性,是不需要终止服务的。

Q:两个不同的店铺能否使用同一个密钥?
A
:不能,平台的加密方式是一个用户pin+Appkey生成一个独立密钥,不同的店铺无法使用同一个密钥解密数据,并且请注意生成数据的店铺授权是否和加解密中的授权相同。

Q:一个密文怎么知道是密钥升级之前加密的还是升级之后加密的呢?
A
:加密API会自动用最新的密钥去加密,解密API会自动获取最新密钥版本。

4.其他问题
Q:
加解密的字段有哪些?后续会增加新的敏感API和敏感字段吗?
A
:有涉及到买家隐私数据的接口都是需要整改加密,并且会不定期增加。本期主要针对订单数据中买家的昵称、姓名、电话、邮箱、地址、身份证、车牌号、用户id等进行加密,具体详情查看
https://open.jd.com/home/home#/doc/common?listId=377 

Q:控制台不显示数据加密菜单是否不需要加密整改? 
A
:不是,控制台没有加密菜单入口的应用,不在本期整改计划中。但是您也可以提供详细的整改进度安排,联系运营审核加入数据加密计划,进入改造保护用户数据。

Q:入参需要改变为密文吗?
A
:不需要。数据加密整改API暂时只涉及到出参,不涉及API入参。

Q:我们数据库里已经有数据是加密的,里面也有敏感信息,那么是不是一定要改成你们的方式?
A
:调用宙斯网关返回的出参数据都是为密文的(非宙斯平台的加密处理的),需要你们使用宙斯平台的加密方式进行加密。


Q:获取TDEClient的时候,报错:“voucher api error -> acesServiceId为空,如何处理?

A:调用前,请在控制台上先把测试token加入店铺白名单。



六.附件

6.1 数据加解密验收文件模板(附件1

验收内容

是否必选

  验收标准

ISV提供的验收信息    

是否针对所有涉及的敏感接口字段进行改造

是否根据待改造的敏感接口字段进行改造,提供appkey、所有敏感接口及对应的敏感字段信息  

 

360buy开头的敏感接口

是否使用新的接口替代完360buy开头的敏感接口,提供所有待改造的360buy开头的接口列表    

 

密文是否正常展示

1、提供测试帐号可登录ISV应用进行查看
2、敏感字段数据需要脱敏模糊展示(比如手机号码138****1231),用户可主动点击查看明文
3、提供界面截图

 

精确查询密文    

1、提供测试帐号/密码/测试地址,可以登录ISV应用进行验收
2、根据查询案例在应用界面上精确查询是否正常
3、提供界面截图
4、如果有密文的“精确查询”功能,必须提交验收    

 

模糊查询密文

1、提供测试帐号/密码/测试地址,可以登录ISV应用进行验收
2、根据查询案例在应用界面上模糊查询是否正常
3、提供界面截图
4、如果有密文的“模糊查询”功能,必须提交验收

 

是否使用京东的加密算法进行存储    

 

1ISV提供一个密文,是否使用京东加密算法加密过的密文
2、数据库表里的数据截图(同一条密文数据)

 

是否存储在云鼎的云数据库里

是 

1、是否能提供ISV帐号下的云鼎云数据库的数据库实例ID
2、验证提供的数据库实例ID是否在ISV帐号下

 

历史数据是否清洗为京东加密后的密文(全店铺加密后且进行全部数据清洗后提交验收)

 

1ISV提供一个密文(存量数据),确认是否使用京东加密算法加密过的密文
2、数据库表里的数据截图(同一条存量数据的密文数据)