前言：

数据合规业务要面对日新月异的信息技术所带来的挑战。律师不能简单的告诉客户“行或不行”“合法或不合法”，而应积极与客户的业务人员和技术人员加强沟通，让双方在“业务”“技术”“成本”“法律”等各个因素之间找到最优方案，从而实现合规业务的真正价值。以下是我们就解决数据跨境异地多活合规问题的一些思考和实践。

 

 

什么是异地多活

异地多活实际上是互联网业务的一个全新架构的名称。异地多活是区别与传统的单活架构相对的概念。在互联网业务当中，传统的中小型应用的架构是一般单活架构。（见下图1）

（图1）

如图1所示，单活架构的前端为应用（一般为手机App或者是网站）；后端为数据库（一般MYSQL等数据库），由于需要避免前端应用直接访问数据库，因此还需要有一个中间层来处理前端发出的各种请求。90%以上的中小型应用的互联网应用和网站都在单活架构，但是，单活架构存在以下几个缺点：

1.异地访问速度慢

互联网不是直连架构。我们从办公室访问某个网站，中间要经过很复杂的路由的过程，路由的节点越多，访问的速度就会越慢。例如：黑龙江的客户访问服务器设在上海的网站，就一定要经过多个路由的过程，这个时候速度和用户体验肯定不佳。（见下图2）

 

（图2）

 

2.易受网络波动的影响

在传统的单活架构中，核心的业务服务器与数据库服务器只有一组，被放置在核心机房当中。相当于“将鸡蛋放在一个篮子里”。一旦数据路服务器所在的核心机房出现网络中断、流量攻击、电力中断等问题，业务必然受到影响。

3.不符合灾备的要求

传统的单活架构下，业务数据库的热库以及其冷备份一旦都被放置在同一机房内。一旦该机房发生火灾、水灾、建筑倒塌等灾难性事件，就意味着企业所有的数据都会灭失且无法恢复。“911事件”便是一个极好的例证。“911事件”中，德意志银行的数据中心被埋入废墟，但因其拥有良好的异地备份方案与业务连续性计划，所以遭遇事故之后数据和业务很快得到恢复。但纽约银行完全没有预料到其数据中心会遭遇如此严重的事故，其包括数据库与冷备份在内的所有业务数据全部损毁，在几个月之后不得不破产清盘。为了解决单活架构存在的以上问题，多活架构应运而生。异地多活的核心是：将关键的业务服务器和最关键的数据库的服务器分别部署在不同城市，这种架构可以很好的解决单活架构存在的以上三个缺点。（见下图3）

 

（图3）

在使用异地多活架构后，北京的用户可以就近访问北京的服务器，上海的用户可以访问上海的服务器，任何一个地方的网络波动或机房事故都不会影响其他地区的业务访问。由于拥有多个数据库实例，所以企业不用担心任何一个地方的服务器出现问题。一旦某地的节点出现事故甚至灾难性事件，用户流量将自动切换至其他服务器。与传统的单活架构相比，异地多活架构在技术实现层面，特别是在数据库的修改、并发、回滚等方面要复杂的多。异地多活架构要解决的核心问题是：数据库可以有多个实例，但数据库的记录必须唯一。因此，必须能够让多个数据库之间的记录保持一致和同步。否则，就会出现用户在上海下订单，到北京之后却发现上海订单找不到的尴尬局面。这个问题需要通过数据库之间的双向同步机制来实现。这就是异地多活架构技术含量最高的地方，一旦实现了完整的异地多活，用户的访问速度、业务的安全性和鲁棒性都会大大提高。目前，异地多活架构已经被大的互联网公司普遍采用。

 

关于跨境异地多活

随着对外交往的增多，互联网应用的跨境交易也在不断发展。用户不仅仅需要在不同城市之间进行业务访问，更有可能需要在境外进行业务访问。典型的跨境应用有三种类型：跨境电商、跨境旅游、各类导航。这是跨境的异地多活应用最广泛的三个场景。由于互联网跨国访问的网络迟延非常严重，因此，与一般的异地多活相比，跨境异地多活的需求更为迫切。（见下图4）

 

（图4）

上图中，我们使用ping的命令同时测试了百度服务器和美国哈佛大学的服务器。图片显示，百度服务器的响应时间是7纳秒-8纳秒（图4红框1），速度相当理想。哈佛大学的服务器响应时间从99纳秒-153纳秒不等（图4红框2）。由图中内容可知，在国内访问美国哈佛大学服务器所所需要的时间，是在国内访问百度服务器的20余倍。需要特别说明的是，本次测试我们选择的是互联网产业最发达的国家（美国）顶级学府的网站（哈佛大学），如果我们测试的对象是某互联网基础设施欠发达的国家的中小型应用，网络延迟应当更为严重。而严重的网络延迟会导致极其糟糕的用户体验，甚至可能直接导致应用报错。因此，有必要将异地多活架构应用在跨境业务当中。即，在与业务相关的国家直接部署核心应用与数据库的实例，让跨境用户可以就近访问。（见下图5）

 

（图5）

 

 

跨境异地多活引发的法律问题

如上所述，跨境异地多活可以很好的解决用户在不同国家的访问速度和用户体验问题，但是合规方面，跨境异地多活却遇到了很大的挑战。《数据出境安全评估办法》第四条规定：

数据处理者向境外提供数据，有下列情形之一的，应当通过所在地省级网信部门向国家网信部门申报数据出境安全评估：

（一）数据处理者向境外提供重要数据；

（二）关键信息基础设施运营者和处理100万人以上个人信息的数据处理者向境外提供个人信息；

（三）自上年1月1日起累计向境外提供10万人个人信息或者1万人敏感个人信息的数据处理者向境外提供个人信息；

（四）国家网信部门规定的其他需要申报数据出境安全评估的情形。

根据以上规定，数据出境安全审查的评估申报已成为数据处理者的一项法定义务。根据相关规定，数据出境行为的范围非常宽泛，将数据进行邮件报送、FTP传输、硬盘寄送、冷备份的转移、或者是前端在境内而数据库在境外等情况都被认定为属于数据出境。（见下图6、图7）

（图6）

（图7）

 

由于数据出境安全审查的规定出台不久，且兼有法律以及政策的双重特性，尚缺乏细化的指引，这就给互联网企业在实际操作中带来了一定困扰。互联网企业要不要申报数据出境安全审查评估？数据出境安全审查评估该如何申报？特别是异地多活架构下，需要在各个不同的业务国家设置数据库的实例，就给互联网企业带来更大数据合规风险。滴滴公司被处以天价罚款，便是忽视数据出境合规问题的惨痛教训。

 

跨境异地多活合规问题的解决方案

如上所述，跨境异地多活能够给用户带来极好的跨国访问体验，但却带来了巨大的合规风险。那么，在二者之间，能否找到一条出路？以下便是我们在合规业务中就这个问题的思考和探索，具体可以总结为以下三个方案：

方案一: 通过优化网络，避免数据跨境

在对这个方案详细解释前，请读者先看一下如下两张图（见下图8、图9）：

 

（图8）

图8是我国互联网运营商的国际出口的带宽图。从图中可以看出，国际出口带宽最高的运营商是中国电信。图9是我国互联网国际出口的分布图。从图上可以看出，我国互联网国际出口分布在上海、北京和广州三地。我们的建议是，如果企业业务规模尚小，数据出境的需求还不迫切。可以尝试将核心业务服务器与数据库服务器放在北京、上海、广州三地距离互联网国际出口最近的机房，这样可以最大的程度的减少网络延迟给跨境用户带来的网络延迟困扰。该方案的优点是：无需调整架构，也无需改写代码。该方案的缺点是：即便把机房放在互联网出口机房内，用户的跨境访问仍然要经过海底电缆的路由和传输，不能从根本上解决用户访问迟延的问题。（见下图10）

 

（图10）

方案二：在所有国家部署数据库并进行数据出境申报

即，在所有可能发生业务的国家部署业务服务器与数据库服务器，将全量用户数据整体复制至国外，并且按照国家规定进行数据出境申报。该方案的优点是：速度快，用户体验好。该方案的缺点是：•第一，将全量用户数据转移至境外涉及数据出境的安全评估，企业申报时要接受网信部门的严格审查。•第二，从网络安全的角度上看，这一方案涉及到巨大的网络安全风险。如果将企业全量用户数据部署在所有业务国家，那么在众多国家的数据中心中，有任何一个出现安全问题，就可能会产生拖库的严重后果。黑客将数据库碰撞、解密、清洗之后，企业的用户数据就会在暗网上被售卖，用户隐私就荡然无存。•第三，数据维护的成本非常高。在将全量用户数据转移后，就必须在业务当地设置完整的数据中心。日常的运维、管理、安全都会给企业带来沉重的负担。（见下图11）

（图11）所以，方案二是一个“笨办法”。除非企业的跨境业务在所在国家已经非常成熟，我们不建议采用这一方案。

方案三：用户数据临时跨境转移

该方案是我们针对互联网企业数据出境现实需求所制定的折衷方案。用户数据的临时跨境迁移的核心是：互联网企业不对全量用户数据做整体的跨境转移，只对可能会涉及到外国跨境交易的用户数据做临时性转移。那么，既然只对部分用户做跨境迁移，如何确定哪些用户有现实的数据跨境需求，并转移其数据呢？针对这一问题具体有以下几个判断方法：

•在一定条件下触发用户数据的跨境转移。例如：企业通过APP心跳包发现用户的IP地址发生变化，来确定用户已经达到国外；企业通过APP获取的LBS位置信息发生变化，来确定用户已经达到国外。企业通过APP在启动时发出的请求IP，来确定用户已经到达境外。此时便可将特定用户的数据从国内服务器转移至境外服务器。此外，还可以通过用户的其他行为数据进行分析判断，例如：某用户机票订单显示，其会在1月1号到泰国，那么企业可以在12月31号对用户数据进行转移。

•辅以大数据与算法判断。例如：企业通过大数据判断，某用户经常频繁前往某特定国家或地区，这种情况下便可将其数据进行跨境转移，以方便其访问。

•在用户跨境条件消失后及时将数据删除。根据大数据分析结果，90%以上的用户不会两次以上前往某一国家。因此，针对这一部分用户，可以在其跨境条件消失后，将其用户数据在境外服务器中及时删除。例如：中老年旅行团用户基本不会再次前往某一国家履行。但深圳、广州等地区用户多次前往港澳地区的可能性极大。此时可以通过数据分析来确定对用户数据进行相应的删除或保留操作。

该方案的优点是：（1）跨境转移的数据量较小，由于是在用户有切实跨境需求下才会传输用户数据，因此一般不会触发数据出境安全评估的申报条件。但需要特别说明的是，因为数据出境安全评估审查对出境数据的数量做累计计算。因此，在出境数据累积到法定申报标准之后，仍然需要依法申报。(2) 数据跨境的安全风险和成本较小，由于不会将大量数据保存在境外，即便是发生拖库等不安全事件，被泄露的数据仅涉及少量国内用户数据，不会导致全量国内用户数据的泄露。以上方案的缺点是：企业需要改造业务系统，需要有一套逻辑来判断用户的跨境状态、跨境需求、跨境数据的删除条件以及跨境数据保留的必要性等因素。但是我们认为，与企业的安全风险与合规风险相比，改造业务系统的成本付出非常值得。（见下图12）

 

（图12）

以上是我们在数据合规业务当中，解决跨境异地多活架构下数据合规问题的一些心得和体会。希望能够对合规法务、合规律师有所启发和帮助。需要特别强调的是，本文的目的不是帮助数据处理者逃避数据监管，而是帮助互联网企业合规经营，减少信息安全风险。互联网企业务必切实履行数据处理者的各项安全管理责任，依法对出境数据申报安全审查评估。