您可能会认为GDPR是法务部需要担心的一项合规要求。您也许认为应用安全与这项新的法规没有太多关联。请您重新考虑一下！事实是应用程序（也称为软件）决定了一切。

从数据对象处收集的数据是由软件完成的，然后通过软件对数据进行分析，并将其呈现给需要使用软件的人。GDPR对数据处理的安全性有严格的要求，这就是为什么GDPR合规性也是一个应用安全问题。

1.    了解您的数据

因为您无法保护您所不知道的东西，所以对于企业来说了解其正在处理的数据是至关重要的。根据GDPR，数据处理实际是指您针对数据所进行的任何操作。像收集、修改、删除以及集合都属于数据处理。即使您正在收集数据，来确认某人是否受制于GDPR——比如其居住国——您就已经在处理GDPR数据了。大多数组织都拥有多个应用程序与多种方法来收集数据。拥有准确的详细目录，包括那些Microsoft Access数据库，是至关重要的。

一旦您确认了您所收集的数据，您就应该进行最小化练习。GDPR要求只收集与收集目的相关的必要数据。仅仅收集数据，并在之后再确认是否需要该数据是非常容易的。而GDPR则迫使您提前做出决断。这一要求实际上会带来比其表面所呈现出的更多的好处。如果您不需要某些数据点，那么就不要收集它们——这样您就不用担心要怎么去保护它们。为什么要承受额外的负担？确定对您的业务操作来说绝对重要和合理的数据，并且只收集这些数据。以谷歌为例，目前在您开通一个新账户时，谷歌会收集您的出生日期。如果您阅读了其理由注解，那么您就会了解到他们这么做是为了确认您是否满足接受某些谷歌服务的年龄限制。我的问题是——他们是否真的需要我的出生日期，还是只需要我的年龄？在GDPR开始执行后，谷歌是否以及如何做出改动将会是件值得关注的事。

2.    实施一个基于风险的方法

在减少了您正在收集的数据之后，现在该对数据进行分类或风险排序了。GDPR的重点是保护数据主体，其中很多都是围绕“对自然人的权利和自由的风险”展开的。在对数据进行分类时，组织需要了解数据对它所属个人的重要性。如果您丢失了这些数据，会对该数据主体造成哪些坏的影响？是仅仅带来一些小麻烦，还是会影响其生计？这就是需要站在攻击者角度思考的重要之处。拥有一个适当的威胁模型将会带来很大帮助。您可能认为某些数据是微不足道的，但是如果攻击者能够找到该数据的其他次要用途，会对人们的自由权造成影响，那么这些数据可能就不会如您先前所料那样微不足道了。以恒温器数据为例。可能乍一看真的不是那么重要，但是攻击者可以使用该数据来确定您是否在外度假，以及确定洗劫您房子，甚至窃取您的身份的时机，毕竟如果您正在乞力马扎罗山远足了话，可能不会保持警惕去及时检查您的信用监控服务。

准确的数据分类最终将决定您的风险，以及您应该在保护数据时实现多少安全控制。从本质上说，它将决定你应该在安全上花多少钱。GDPR要求采用基于风险的安全方法。然而，GDPR本身并没有规定任何控制措施，也没有针对任何特定数据集的“合规性”标记。GDPR为每个成员国的法院和数据保护机构提供了框架，以确定其安全级别是否符合所处理的风险。您也许能够侥幸逃脱低于标准的数据保护审查，但是一旦发生了投诉或漏洞事件，并且确定了您的控制程度是不充分的——那么您可能将陷入水深火热的境况之中。

3.    将安全性融入设计中

就在不久之前，我还经常发现应用安全是事后添加的。它是一种附加固定在其上，为了满足合规性需求；处理渗透测试的结果；漏洞扫描；或第三方审计。尽管情况正在改善，但安全似乎仍然是一些人的非功能性负担——其实很容易理解其中的原因。安全控制通常并不会使应用程序的初始价值提高很多。它不是一项功能，在很大程度上，它不会产生额外的收入，因此也很容易被忽视，有时甚至被掩盖。

GDPR改变了这一趋势，其要求构建“设计与默认安全性”。它规定数据保护原则应在整个进程的最初阶段实施，尽可能的保护是默认规范。

那么，这对您的应用程序开发过程意味着什么呢？这实际上可以归结为在项目开始时考虑安全性，并在整个产品生命周期中继续保持安全心态。例如，针对您的应用程序进行威胁建模将帮助您获取攻击者的视角，并理解为什么有人可能想要攻击您的应用程序，以及他们可能会如何进行。

一个好的威胁模型会满足您的安全需求。这些需求与应用程序的功能需求一样重要。它们可能包括特定的控制措施和针对已确定威胁的对策；业务逻辑的安全预期，如访问控制或交易完整性；也可能是特定的监管要求，比如PCI。关键是要尽早构建这些需求，并在开发过程中不断改善它们。

4.    默认“安全”

在查看任何现代应用程序时，您将发现其是由组织内外的不同开发人员编写的大量组件、框架、API和代码片段组成的。并不是所有的都是安全的，并且不是所有人都默认使用安全的协议、设计模式或针对您应用程序处理的数据类型遵循相应实践。虽然从Stack Overflow中简单地拉出代码片段或者下载一个npm模块可能很容易，而且节省了时间，但是这对关键组件的安全影响可能是灾难性的。

在检查您的应用程序是否在默认情况下安全地完成所有事情时，请记住一些常见的应用程序设计问题，比如未对密码进行hash与salt；过分信任用户输入；或者使用一个加密执行欠佳的密码。请考虑不安全的默认值，这些默认值可能会随着商业需求下降，比如在没有适当威胁建模的情况下暴露敏感的地图数据。与此同时，考虑是否指定了所有与安全性相关的业务逻辑需求，例如，在一次商业交易中没有检查受制裁交易对手黑名单。

最终，您的组织需要建立一套公司范围的安全设计指导方针，开发人员可以遵循这些指导方针。例如，建立安全的设计原则，比如：纵深防御；简单的设计；以及组件的安全失效。建立安全的架构模式，如授权和认证子系统，集中式的日志记录，以及加固的接口设计。考虑创建集中式安全服务与组件，应用程序扫描“插件”并对安全的、经过审查的库和组件进行标准化，这些库和组件可以重新使用。

所有这些都将建立一组安全的默认值，这些默认值是所有软件开发活动所遵循的，并最终帮助您满足GDPR要求。

5.    信任，但需验证

信任您的开发人员和架构师遵循已建立的安全模式总是好的，但是验证是软件开发周期的一个重要部分。就像质保部门验证功能需求一样，应用程序的安全性也需要得到验证。GDPR需要定期测试和验证数据处理的安全性。

好的验证程序首先从验证安全架构与设计审查开始。在此过程中，您将检查设计问题是否会影响到您的应用程序；诸如是否正确设置身份认证与授权的事情；是否所有应该加密的东西都使用适当的加密技术进行了加密；在使用用户输入进行业务逻辑决策之前，该用户输入是否得到了正确的验证。

实施静态与动态扫描工具将帮助您捕获可能造成浅显漏洞的“低挂水果”或所有编码错误。在您的每夜构建中，以及您的QA或您的开发过程中构建这些工具的使用。为您的app准确配置这些工具，从而得到更低的误报率。

因为工具能提供的帮助是有限的，所以需要让开发人员审查彼此的代码，并考虑聘用一个安全公司来进行代码审查，并对重要的app与服务进行渗透测试。渗透测试将考虑您的业务需求与威胁模型。他们将深入研究应用程序，以了解攻击者真正能进行哪些操作，以及您的控制与对策是否有效。

特别建议：培训

我明白我们说的是Top 5，但是开发人员确实是从0开始的！虽然GDPR不强制执行任何特定的培训，但它是任何应用安全程序的一个组成部分。您的开发人员如何知道怎么编写安全代码？他们如何知道哪些组件是关键的，哪些组件应该要求安全指导？同样重要的是，如何建立一种重视安全的企业文化，特别是当没有人真正鼓励编写安全代码或生成安全架构的时候？这就是培训发挥作用的地方。适当的培训与提高安全意识项目将使您的组织能够满足GDPR的要求，让您的开发人员与测试人员明白该做什么以及何时来做。如何设计一个安全的架构；如何构建安全的身份认证程序；如何正确地保护您的数据库连接字符串，以及使用什么加密技术。所有这些知识都需要培训。

遵循这些活动将帮助你证明符合GDPR的要求。记住，GDPR是很宽泛的，但是如果您遵循这个规范的精神，那么即使数据保护权威存在问题，您的公司仍将会处于良好的状态。