将围绕数据泄露定义的争论描述为 “白热化” 未免太过夸张，毕竟我们尚未看到尸体从窗口飞出般的戏剧化情节。但随着《通用数据保护条例》(GDPR) 及其对数据不当处理施以重罚时代的到来，怎么定义数据泄露就是事关切实财务影响的严肃问题了。
很多厂商表示，媒体和标题党只会帮倒忙。但凡事件涉及数据且听起来像个可博眼球的新闻，大部分媒体就会给安上个 “数据泄露” 的关键词。所以，在吐槽《条例》缔造者居心不良之前，不妨冷静地回顾下GDPR决议对这么个模糊不清的主题设置诸多规定的思考过程。
到底是不是数据泄露?
如果生活就是墨守成规那么简单，那这篇文章就没必要写也没必要读了。但生活并不简单，理清定义还是有必要的。虽然大多数网络安全组织都倾向于认为数据泄露涉及未授权删除或查阅数据的行为，但并没有一个全知全能的 “数据泄露警署” 来推行这一定义。
前文提及的GDPR是与 “数据泄露警署” 最为接近的事物了，因为它拥有对违反其数据保护条例的人征收巨额罚金的权力。由于该新规定背后的当权者正在挥舞大棒杀鸡儆猴，我们不妨来分析一下他们是怎么定义个人数据泄露的。
| 对传输、存储或以其他方式处理的个人数据造成意外或非法破坏、遗失、变更、未授权披露或访问的安全违规事件。 |
GDPR进一步阐明：数据泄露是一类安全事件，但不是所有的安全事件都是数据泄露。这里存在三条决定性的信息安全基本原则，其中任何一条或多条都能构成数据泄露。
- 违反机密性 ——未授权或意外披露个人数据。
- 违反可用性 ——未授权或意外丧失对个人数据的访问权或造成对个人数据的破坏。
- 违反完整性——对个人数据的未授权或意外变更。
情况复杂多变。可仔细审查上述原则背景下的一些具体实例。
勒索软件攻击
认为勒索软件不是什么大事儿的想法简直大错特错。这种恼人的恶意软件在黑客圈中越来越流行，可对大大小小的公司企业造成数十亿美元的损失。
勒索软件通常是终端用户点击了网络钓鱼邮件中看似合法的恶意链接而植入系统的，会加密受害者的文件，要求受害者支付赎金以换取解密密钥。
这算是数据泄露吗?虽然系统中不受欢迎的勒索软件入侵本身只能被看作是安全事件，但GDPR告诉我们：具体事件的细节最重要——个人数据被访问的瞬间，就适用不一样的原则了。尽管数据访问权的遗失可能只是暂时的，并不能运用可用性原则 (假设你可以从备份计划中恢复出数据)，但根据具体情况，机密性原则中的 “未授权访问” 部分却有可能再次适用。
对所有此类事件，我们必须仔细审阅定义的精确措辞。员工点击网络钓鱼电子邮件链接释放出勒索软件算不算违反机密性原则?这可能属于 “意外访问” 条款的管辖范围，但也有可能不是。
开放S3存储桶之殇
亚马逊的云存储服务近些年让这家公司更加声名大噪。但问题是，错误配置的安全设置引发了数据泄露事件的盛行——拜未受保护的开放存储桶所赐。或者，这些事件仅仅是安全事件?
运用GDPR的三条安全原则一审便知。
偶然撞上一个开放S3存储桶某种程度上相当于随机访问一个网站，而该站点拥有者毫无安全措施地将网站暴露在公网上时并未预期会有人访问这个网站。很明显，近期的S3数据泄露中，比如威瑞森、LocalBlox和GoDaddy遭遇的那些，并没有哪家苦主想要暴露这数百万条个人数据集。
但如果是安全研究人员偶然遇到了开放存储桶，顺手查看一番的情况呢?他们会被就地归类为正在制造数据泄露事件的黑客吗?让我们回到机密性原则上来。必须承认，因为该存储桶就这么敞开在网上，这位友好的邻家研究员的确有权查看。若以该原则认定此类行为有罪，那只要看过不属于自己的东西难道就是罪犯吗?别人家没关窗帘被你看到室内陈设也算犯罪吗?
至于意外披露或访问的情况，那就跟机密性原则有关了。按常理推测，GoDaddy是不会想要自己的商业秘密和基础设施信息暴露在公网上的，于是，意外披露的情况存在。技术专家将S3存储桶问题的涌现归罪于糟糕的产品设计，称普通人太难搞懂并应用正确的安全设置了。
亚马逊可以从理论意义上争辩称，GoDaddy存储桶可被访问的事实并不构成数据泄露，因为除非该存储桶被拷贝或移动到外部，否则是没有发生任何损害的。然而，GDPR监管机构会回应称，GoDaddy将自身商业秘密交托给该亚马逊服务时并未预期该信息能在网上公开访问。
“我只是复制而已”
上一节内容引出了另一个问题：如果你只是复制了系统中的信息算数据泄露吗?截至目前，机密性原则可谓严酷监工的概念应该建立起来了，尤其是在其甚至连意外披露或访问都禁止的措辞方面。
这种情况下，很难申辩你只是复制了受保护数据而没有访问 (查看) 其内容，因此——违规罪名成立!但真的成立吗?未必。很明显，这种对GDPR标准的应用给律师、法庭和GDPR本身留下了很大的解释空间。
收集数据的各种方式
有时候你可能就在收集GDPR规定的个人数据而不自知：
- 有没有电子邮件订阅表单?通过这条途径收集的任何信息(姓名、邮箱地址等等)都算。
- 评论区呢?如果访客可以留下包含自身邮箱地址、网站URL、姓名等内容的评论，数据收集判定成立。
- 对虚拟主机有多信任?除非运营的是完全自给自足的服务器，否则就有很大概率往托管主机提供商那儿存储GDPR辖下的文件——即便你并不认为自己在通过作为托管主机标准流程的日志文件收集包含网站访客IP地址的数据。
上述问题很多在线云托管及云存储提供商都很难回答。亚马逊、谷歌和微软等公司可能发现自己违反了GDPR要求，但他们体量足够大，能够挺过经济处罚。小型服务提供商就未必了。
比如广受位于犹他州盐湖城的加拿大及美国中小企业推崇的虚拟主机提供商Bluehost。他们阐述了虚拟主机、客户和客户网站之间的复杂关系。虽然Bluehost在遵循严格的《隐私政策》收集、处理和存储客户数据方面毫无疑问符合GDPR规定，但其《数据处理协议》(涵盖通过客户网站上传服务器的数据) 却没那么确定了。托管服务提供商将GDPR终端用户要求简单转嫁给网站拥有者的行为并不鲜见。
对SaaS公司而言情况更加诡谲。SaaS公司仰赖第三方托管以维持业务运营。如果某SaaS应用要使用不符合GDPR规定的托管服务会出现什么状况?最近的一篇《福布斯》文章中，Varonis创始人 Yaki Faitelson 描述了此类案例的复杂性：
| SaaS公司及其云托管服务提供商都必须签署符合GDPR第28条规定的合约。这些合约旨在防止互相推诿责任，比如托管服务提供商对SaaS公司 (或SaaS公司对托管服务提供商) 宣称自己免于数据泄露责任。 |
结论
网站拥有者应重视对GDPR的解读，重点搞清构成数据泄露的要素有哪些，以及如何向客户通报数据泄露事件。注意72小时窗口期，因为这是必须通报数据泄露的时间底线。
涉及SaaS公司GDPR合规复杂性的《福布斯》文章：
https://www.forbes.com/sites/forbestechcouncil/2019/04/05/gdprs-territorial-scope-holds-new-surprises-for-u-s-service-firms/
【本文是51CTO专栏作者“李少鹏”的原创文章，转载请通过安全牛（微信公众号id:gooann-sectv）获取授权】
