什么是软件安全？

当今的软件系统管理着大量数据，其中很大一部分被认为是敏感的，特别是考虑到当前的通用数据保护法规（GDPR）要求。 作为用户，您认为私有的任何信息对您的软件应用程序都是敏感的。 敏感数据可以包括无害信息，例如电话 码，电子邮件地址或标识 ； 不过，我们通常会更多地考虑丢失风险较高的数据，例如您的信用卡详细信息。 该应用程序应确保没有机会访问，更改或拦截该信息。 除了要使用此数据的用户外，任何其他方都不能以任何方式与其进行交互。 广义上讲，这就是安全的含义。

GDPR 自 2018 年推出以来，在全球引起了广泛关注。它总体上代表了一系列涉及数据保护的欧洲法律，并赋予人们对其私有数据的更多控制权。 GDPR 适用于在欧洲拥有用户的系统的所有者。 如果此类应用程序的所有者不遵守所施加的规定，则可能面临重大处罚。

我们在各层中应用安全性，每一层都需要不同的方法。 将这些图层与受保护的城堡进行比较。 黑客需要绕过一些障碍才能获得该应用程序管理的资源。 每个层的安全性越好，有不良意图的人管理数据或执行未经授权的操作的机会就越小。

黑暗向导（黑客）必须绕过多个障碍（安全层）才能从公主（您的应用程序）中窃取魔剑（用户资源）

安全是一个复杂的主题。 对于软件系统，安全性不仅适用于应用程序级别。 例如，对于 络来说，需要考虑的问题和要使用的特定实践，而对于存储，则是另外一个讨论。 同样，在部署等方面也有不同的哲学。 Spring Security 是属于应用程序级安全性的框架。 在本部分中，您将大致了解此安全级别及其含义。

应用程序级安全性指的是应用程序为保护其执行环境以及处理和存储的数据而应做的所有事情。 请注意，这不仅与应用程序影响和使用的数据有关。 应用程序可能包含一些漏洞，这些漏洞使恶意人员可以影响整个系统！

我们在各层中应用安全性，并且每一层都取决于它下面的层。 在本书中，我们讨论 Spring Security，这是一个用于在最顶层实现应用程序级安全性的框架。

更明确地说，让我们使用一些实际案例进行讨论。 我们将考虑如图所示部署系统的情况。 对于使用微服务架构设计的系统，这种情况很常见，尤其是如果您将其部署在云中的多个可用性区域中。

图 1.4

如果恶意用户设法访问了虚拟机（VM）并且没有应用的应用程序级别的安全性，则黑客可以控制系统中的其他应用程序。 如果在两个不同的可用区域（AZ）之间进行通信，则恶意个人会发现更容易拦截消息。 此漏洞使他们可以窃取数据或模拟用户。

我们在多层上设计。 在解决其中一层的安全问题时，最好的做法是尽可能多地假设上述层不存在。 考虑一下图1.2中与城堡的类比。 如果您由30名士兵管理 “层”，则需要使他们准备得尽可能强大。 您甚至知道在到达他们之前，您需要过火热的桥，您才能做到这一点。

考虑到这一点，让我们考虑一下出于恶意的个人可以登录承载第一个应用程序的虚拟机（VM）。 我们还假设第二个应用程序没有验证第一个应用程序发送的请求。 然后，攻击者可以利用该漏洞并通过模拟第一个应用程序来控制第二个应用程序。

另外，考虑将这两个服务部署到两个不同的位置。这样，攻击者就不需要登录其中一个虚拟机，因为它们可以直接在两个应用程序之间的通信中间进行操作。

可用分区(如图1.4所示)在云部署中是一个独立的数据中心。该数据中心在地理位置上距离同一区域的其他数据中心足够远(并且有其他依赖关系)，因此，如果一个可用性区域出现故障，其他可用性区域也出现故障的概率非常小。就安全性而言，一个重要的方面是两个不同数据中心之间的通信通常通过公共 络。

单体和微服务

关于单体和微服务架构风格的讨论是完全不同的。 我在本书的多个地方都提到了这些内容，因此您至少应该了解这些术语。 对于这两种架构风格的精彩讨论，我建议您阅读 Chris Richardson 的 Microservices Patterns（Manning，2018年）。

通过单体架构，我们引用了一个应用程序，在这个应用程序中，我们在同一个可执行工件中实现了所有的职责。将其视为一个满足所有用例的应用程序。职责有时可以在不同的模块中实现，以使应用程序更易于维护。但是在运行时，你不能把一个逻辑从另一个逻辑中分离出来。一般来说，单体架构在伸缩和部署管理方面提供的灵活性较低。

使用微服务系统，我们在不同的可执行工件中实现职责。您可以看到系统是由多个应用程序组成的，这些应用程序同时执行，并在需要时通过 络进行通信。虽然这为扩展提供了更多的灵活性，但也带来了其他困难。我们可以在这里列举延迟、安全问题、 络可靠性、分布式持久性和部署管理。

我在前面提到了身份验证和授权。事实上，这些在大多数应用程序中都经常出现。通过身份验证，应用程序识别用户(个人或其他应用程序)。识别它们的目的是为了能够在之后决定它们应该被允许做什么——这就是授权。我提供了大量关于身份验证和授权的细节。

在应用程序中，您经常会发现需要在不同的场景中实现授权。考虑另一种情况:大多数应用程序对用户获取某些功能的访问都有限制。要实现这一点，首先需要确定是谁为特定特性创建了对请求的访问——这就是身份验证。同样，我们需要知道他们的权限，以允许用户使用系统的那部分。随着系统变得越来越复杂，您将发现需要与身份验证和授权相关的特定实现的不同情况。

例如，如果您想针对代表用户的数据子集或操作授权系统的特定组件，该怎么办?假设打印机需要访问用户的文档。是否应该简单地与打印机共享用户的凭据?但这允许打印机拥有比需要更多的权利!它还公开用户的凭据。是否有一种不模仿用户的正确方法来实现这一点?这些都是基本问题，也是您在开发应用程序时遇到的一类问题:我们不仅想回答这些问题，而且在本书中您将看到带有Spring Security的应用程序。

根据为系统选择的体系结构，您将在整个系统以及任何组件的级别上找到身份验证和授权。正如您将在本书中进一步了解到的那样，对于Spring Security，有时您更愿意对同一组件的不同层使用授权。在第16章中，我们将更多地讨论这个方面的全局方法安全性。当您拥有一组预定义的角色和权限时，设计会变得更加复杂。

我还要提醒您注意数据存储。 静态数据增加了应用程序的责任。 您的应用不应以可读格式存储其所有数据。 应用程序有时需要使用私钥对数据进行加密或对数据进行哈希处理。 凭据和私钥之类的秘密也可以视为静态数据。 这些内容应仔细保存，通常保存在秘密保管库中。

我们将数据分类为“静止”或“过渡中”。在此上下文中，静止数据指的是计算机存储中的数据，或者换句话说，持久化数据。转换中的数据适用于从一点交换到另一点的所有数据。因此，根据数据的类型，应该实施不同的安全措施。

最后，正在执行的应用程序还必须管理其内部内存。这听起来可能很奇怪，但是存储在应用程序堆中的数据也可能存在漏洞。有时，类设计允许应用程序存储敏感数据，如证书或私钥很长一段时间。在这种情况下，有权创建堆转储的人可能会找到这些详细信息，然后恶意地使用它们。

通过对这些案例的简短描述，我希望我已经设法向您提供了应用程序安全性的概述，以及这个主题的复杂性。软件安全是一个复杂的问题。一个愿意成为这一领域专家的人需要理解(以及应用)，然后测试系统中所有协作层的解决方案。然而，在本书中，我们将只关注Spring安全性方面您特别需要理解的所有细节。您将了解到该框架适用于何处，不适用于何处，它如何提供帮助，以及为什么应该使用它。当然，我们将使用实际的示例来实现这一点，您应该能够适应自己独特的用例。