ISACA Journal | 创新治理：隐私创新

在撰写本文时，信息安全领域的一大新闻就是SolarWinds供应链被黑客攻击。由于攻击及随后态势的复杂性，信息安全研究人员认为本次攻击是由国家背景主导的APT攻击。

现实情况是，每个组织始终面临攻击者利用自身使用的第三方软件作为突破口攻击组织的风险。它可能不是软件，而是一个过程。我记得许多硬件供应商在其基础工作站的镜像上有所让步。恶意软件被植入镜像，因此计算机在出厂时已经被感染。这些是固有风险的例子，组织必须准备应对计划。有些组织可能不会遭遇APT，但是即便是一个简单的网络钓鱼攻击也可能带来一系列意外事件，而最终导致类似的结果。

多数情况下，对手需要信息，而隐私数据正是其中的一部分。虽然在过去的十年中，数据保护有了重大的创新，但是这类产品并不能为我们做所有事情。当我们审视自己的系统时，我们必须对隐私数据保护进行规划。研究表明，我们起步的时间越早，长期来看成本就越低。这意味着我们必须进行自己的“酝酿”。

01“酝酿”隐私保护

如果有足够的时间，彻底的妥协也无法阻止对手获得一切。因此，我们希望做的是在确保我们自己的系统不会受到负面影响的同时，尽可能地增加提取信息的难度。通常，这意味着，如果使用正确的应用程序和正确方式访问数据，则可以轻松访问数据。如果尝试通过另一种机制提取数据，则将花费更多的时间和精力。

付出更多的努力和更多的时间，我们就更有可能发现对手。这就是目标。但是，如果我们过度注重通过产品来解决差距，那么永远不会得到比早期创新更加显著的效果。我们可以使用完全相同的产品，但是如果能够在产品周期的早期关注隐私风险，我们就能够更充分并最大化地利用这些产品，从而降低总体风险。

当我们进行早期规划时，我们称其为“酝酿”解决方案。在开发用于保护隐私数据的解决方案时，应该立即想到几个关键领域：

• 加密静态数据

• 加密传输中数据

• 防止特权用户攻击

• 审计所有相关行为

02加密静态数据

当我们谈论加密静态数据时，通常是指文件本身。许多解决方案都可以对使用它们的系统透明地加密文件。如果没有使用正确的密钥对文件进行复制，您将无法读取它们。也就是说，即便您可以复制它们，除非您拥有解锁密钥，否则系统会阻止此类操作。 

但是，当我想到静态数据时，我认为我们需要超越这个简单的定义。例如，当关系数据库管理系统（RDBMS）打开其数据文件并有权访问该数据时，如果您没有权限访问适当的密钥，您是否可以查看该数据？如果答案是肯定的，那么虽然从技术上讲这不符合静态数据的定义，但肯定不是正在传输的数据。我宁愿不要用一个新词组来表达，但考虑到飞行的类比，也许“跑道上的数据”更加恰当？ 

无论如何，我们也必须考虑此状态下的数据。例如，某些平台将数据保留在磁盘上加密，但是一旦读取和/或修改，数据将以未加密状态保存在内存中。从技术上讲，当您考虑交换文件，闪存驱动器和其他涉及存储的管理机制时，即使意图是将数据保留在内存中，数据也可能最终存储在该存储的缓存中。在这种情况下，数据将不会被加密。 

例如，数据库平台可能会加密整个文件。但是，如果该进程可以访问文件并对其进行解密，则文件中的数据将被有效地未加密到平台。正是这种未加密的数据版本进入了内存缓冲区，以提高数据库性能。这与在文件本身内（例如在列或单元级别）对数据进行加密的情况不同。在这种特定情况下，数据库平台会将数据放入数据库文件中，由于它们存在于数据库文件中，因此在列或单元级别进行了加密。如果我们有一个页面操作要写入交换文件等，则加密版本就是写入磁盘的内容。虽然我是以数据库平台为例，但是应用程序从缓存中获取未加密数据的行为同样会被指责。

知道这种风险后，如果我们能够设计出一种解决方案，让可访问未加密数据的时间窗口最短，那就更好了。例如，在以Microsoft体系中，利用SQL Server2019的始终加密特性将保护数据库平台上内存中的数据。在应用程序方面，.NET Framework、.NET Core和.NET 5具有数据保护功能，可以对文件或流（例如驻留在内存中的文件或流）进行加密。

03加密传输中的数据

在企业系统中，应用程序使用数据时，数据主要是通过网络传输的。在某些情况下，数据源和消费方应用程序位于同一系统上，并且在内存中传递，但是这种情况并非普遍。考虑这种情形：如果数据未经加密地通过网络传输，但是网络工程师无法通过系统或数据库平台访问数据，则会出现问题。我们希望网络工程师具备查看网络中的流量的能力。鉴于大多数平台都使用明确定义的协议，并且许多数据包分析工具都可以理解这些协议并可以自动将其解析，因此网络工程师完全有可能以这种方式访问他或她不应访问的数据。

因此，需要考虑数据如何在不同环境中流转。有时需要创造性的解决方案，尤其是在应用程序或后端平台本身不支持任何类型的加密的情况下。还有其他行的解决方案。例如，在网络层的两个终端之间，使用Internet协议安全（IPSec）可能是最好的答案。系统无需任何改造，但是可查看到的网络流量数据包显示至少使用IPSec进行了加密。

04防止管理员访问

毫无疑问，管理员通常对系统拥有完整的权限。防止他们看到数据非常具有挑战性。在大多数情况下，束缚于解决方案是行不通的。因此，必须“保护”隐私数据。已经提到的某些解决方案提供了一些防止管理员访问的功能。例如，始终加密和安全区域的结合以及在应用层正确实施内存保护的组合，可以防止管理员扫描内存中的未加密数据。

但是，未加密的数据可能会出现在许多意外的地方。几年前，我接触到的一个人力资源（HR）系统数据库账号以纯文本格式存储在以数据库名称命名的文本文件中。尽管这不是直接允许访问未加密的隐私数据，但它是间接允许的。该平台没有对数据库中的数据进行加密。因此，如果您可以获得数据库账号，则可以访问数据。我们最终提出了一个解决方案，在不更改应用程序的情况下，将文件权限和文件本身的审计作为缓释措施。

通常，团队必须通过创新，找到用来拦截或记录管理员访问数据的方法。审计追踪很重要。说到审计追踪，它们可能是我们唯一可用的控制。具体来说，它们在保护数据过程中充当了侦查控件。

05“酝酿”适当的审计

流行歌手迈克尔•杰克逊（Michael Jackson）死后大约一年，有报告表明有人不当地访问了他的病历。这明显违反了美国健康保险携带与责任法案（HIPAA），并且是罗纳德•里根加州大学洛杉矶分校（UCLA）医疗中心系列隐私泄露事件之一。好在系统在审计日志中记录了异常的访问，从而帮助医疗中心解决这个问题。 

我曾经见过在事后才将审计添加到系统中的情况。在这种情况下，开发团队必须具备超凡创造力才能找到可行的解决方案。我还见过无法添加审计的情况。而诸如罗纳德•里根加州大学洛杉矶分校（UCLA）医疗中心使用的系统从一开始就进行了适当的审计。我们从不希望遇到审计不完善的情况，但是我们不确定当没有新系统或对现有系统进行重大甚至重写后，审计是否存在不完善。这使我们回到了隐私保护这个问题。 

不足与过多之间有一条线。我们必须尽早地确定这条线的位置，这也是从一开始就考虑如何添加审计的另一个原因。在不同的测试周期中，不同的用例应揭示系统获取的数据是否足够或系统记录的信息是否过多（带来不需要的干扰信息）。尽管安全信息和事件管理（SIEM）系统可以过滤掉大部分噪音，但我们这样做是以牺牲计算资源和增加时延为代价的。根据隐私数据的敏感程度，这可能会让我们迟些关注到警报信息。

06展望未来

攻击的复杂程度将不断提高。数据保护产品将持续推出新功能。随着新攻击的发展，我们需要创新的缓释策略和步骤。最好是一开始就采用新方法并将其融合到循环周期中。否则，可能存在无法弥补的差距。我们需要考虑如何保护静态和传输中数据的隐私，限制管理员对数据的访问，并建立适当的审计追踪机制。尽管我们无法阻止所有攻击，但我们希望可以减少其有效性和持续时间。 

编者注：本文出自ISACA Journal 2021年第2期。尾注略。根据译者对原文的理解略作增删后翻译。文章内容仅代表作者本人观点。 

作者：K. Brian Kelley，CISA，CSPO，MCSE，Security+，是主要致力于Microsoft SQL Server和Windows安全性的作者和专栏作家。 

翻译：文静雅，CISA，PMP，CIIPT-A，ISACA微信公众号特邀通讯员。 

校稿：王岩 （Liam Wong），CISA、CDPSE、CISSP、PMP、OCM 11g/12c、PGCA、MCDBA、MCSE，ISACA微信公众号特邀通讯员。

相关内容