《2023云安全实用指南.docx》由会员分享，可在线阅读，更多相关《2023云安全实用指南.docx（130页珍藏版）》请在课桌文档上搜索。
1、云安全实用指南1 .第1章原则与概念2 .第2章数据资产管理与保护3 .第3章云资产管理与保护4 .第4章身份与访问管理5 .第5章漏洞管理6 .第6章网络安全7 .第7章安全事件的检测、响应与恢复第1章原则与概念本书是一本实用指南，但在我们深入讨论实用细节之前，还需要从一个较高层次来介绍几个与云相关的安全原则。如果你是经验丰富的安全专家，只是刚接触云，那么可以直接从第6页“云共享职责模型”开始阅读。最小权限最小权限(leastprivilege)原则说起来很简单：对于承担某项工作的个人或自动化工具，应该只授予他们完成该任务所必需的访问权限，除此之外不再提供其他任何权限。最小权限原则中很容易被
2、忽视的是自动化部分，例如，如果某个访问数据库的组件不需要写权限，那么就不应该让它使用可对数据库写权限的凭证。如果某个项目中的应用符合最小权限原则，通常就意味着它的访问策略是默认拒绝(denybydefault)0也就是说，默认用户不会被授予任何(或只授予非常小的)权限，若要获取所需权限就必须进行申请和审批。在云环境中，部分管理员需要有云控制台的访问权限。云控制台是一个基于网页的控制台，用户可以通过这个页面创建、修改和删除某些云资产，例如虚拟机。对于云提供商来说，用户能访问云控制台就意味着用户拥有上帝特权，他可以操作该提供商管理的任何资源，不管提供商实际创建的系统在操作系统层面做了什么控制，他都
3、有可能从云环境的任何地方读取、修改和删除数据。出于这个原因，你应该收紧用户对云控制台的访问权限和使用特权，就像在本地部署(onpremises)环境中严格控制对物理数据中心的访问一样；另外，你还需要记录这些用户都做过哪些事情。纵深防御本书介绍的一些控制措施如果实施得当，你就无须使用其他控制方式。纵深防御(defenseindepth)是指，儿乎任何单一的安全控制都会以失败告终，原因可能是攻击者一直在持续不断地攻击，也可能是安全控制的实现方式存在漏洞。在纵深防御中，你需要创建多层安全控制，它们互有重叠，这样当一层被攻破时，下一层还能挡住攻击者。但这个原则如果把握不当，就很容易走极端，因此去了解你
4、可能要面对哪些风险是非常重要的，我们稍后会介绍这些内容。通常来说，一旦你指着安全控制中的任何一层问自己：“如果这一层失败了会怎样？”如果答案是(系统)彻底失败，就说明防御的层级还不够。威胁行为体、图和信任边界评估所面临的风险有多种方式，我个人倾向于一种面向资产(asset-oriented)的方式。这种方式需要你首要明确的是哪些资产需要保护，这也是为什么本书在第2章就开始深入介绍数据资产(dataasset)的原因。此外，你头脑中要时刻铭记谁可能会给你带来威胁，这会对你很有帮助。用网络安全术语来说，这些(带来问题的人或组织)就是潜在的“威胁行为体(threatactor)例如，你可能不需要考虑
5、如何为资金充沛的国家行为体(stateactor)做好防御，但需要考虑你自己经营的生意，因为罪犯可能会通过窃取你的数据而获利，或者“黑客行为体(hacktivist)”可能会攻击你的网站并使其瘫痪。在设计各种防御系统时，你需要经常在脑海中考虑以上提到的儿种情况。虽然市面上己经有大量关于威胁行为体、动机和方法的资源和讨论，1但本书介绍的四个主要威胁行为体可能是你最需要关心的：有组织犯罪(OrganiZedCrime)或独立罪犯(independentcriminal),主要目的是获利。 黑客行为体，主要目的是通过公布窃取的数据，实施破坏行为，扰乱业务来使你信誉受损。 内部攻击者(insideat
6、tacker),通常目的是损害你的信誉或获利。 国家行为体，目的可能是窃取机密或扰乱业务。我们从用户体验设计(UED)领域借鉴一种设计防御系统的方法：想象应用的所有适用场景，从每种场景中选取一个用户并给该用户取一个名字，然后用简笔画将这些用户都画到一张卡片上；在设计防御系统的过程中，始终保持这些卡片可见。接下来，你需要找出应用中需要访问哪些部分，最简单的方式就是画一张图，找出其中的脆弱之处可能在哪里。市面上有很多书是专门介绍如何完成这项工作的，2其实你无须成为专家就可以画出一些足够有用的图来帮助你做决定。但是如果你处在高风险的环境中，那么就需要用合适的工具创建一些更正式的图，而不是像我们这里用
7、简笔画的方式。应用架构有很多不同的类型，为了展示方便，我将采用一个简单的三层设计(three-tierdesign),建议如下：1 .首先画出一个“用户”，然后加入一个“管理员”(图1-1),以此作为我们的起点。以后你可能会遇到多种类型的用户和管理员，或有其他角色的情况，这里暂不考虑。2 .画出用户访问的第一个组件(例如Web服务器)，然后将该组件与用户连起来，并在连线上注明用户的访问方式(图1-2)。注意，这里的组件可能是一个serverless函数，也可能是一个容器、虚拟机或其他组件。由于这个组件可以被任何人访问，因此从这里开始是比较合适的。另外，我们不希望其他组件过于信任这个组件。图1-
8、2第一个组件3 .继续画出第一个组件需要访问的其他组件，再画出它们之间的连线（图1-3）。如果遇到实际存储数据的系统，就在它旁边画一个标记（这里我使用了圆柱体），并简要注明它具体存储了什么数据。重复以上过程，直到应用所需的全部组件都已画在图中。图13其他组件4 .现在画出管理员（以及你定义的其他角色）如何访问应用。注意管理员可能有多种访问应用的方式，例如，可通过云提供商提供的门户或应用编程接口（APl）访问，还可通过操作系统权限访问，或者通过与用户访问应用类似的方式访问（图1-4）。图1-4管理员权限5 .用虚线画出信任边界（图1-5）。信任边界（trustboundary）表示的是，边界内的
9、任意组件至少是在一定程度上清楚彼此的动机的，但对于边界外的任何组件必须先通过验证才能给予信任。这里的基本假设是：如果攻击者能进入信任边界内的某一部分，就有理由认为它最终能完全控制该信任边界内的任何部分，因此我们必须对跨信任边界采取一些额外的控制。注意，图中同一个信任边界内画了多个Web服务器，我想表达的意思是，这些Web服务器是彼此可以完全信任的，因此如果有人对其中一台有访问权限，他就对这一组服务器都有访问权限。换句话说，如果有人入侵了其中一台，那么他入侵其他几台也不会造成更大的损失。图1-5组件信任边界6.在某种程度上，我们对自己系统的信任要高于对其他外部系统的，因此我们将整套系统画进一个虚
10、线框里，包括管理员，但不包括用户（图1-6）。这里要注意，如果有多名管理员，例如一名Web服务器管理员和一名数据库管理员，那么他们可能会在不同的信任边界里。这种一个信任边界里嵌套另一个信任边界的情况，说明信任也有不同的层级。例如，一方面，某些服务器可能愿意接受另一个信任边界内的服务器发过来的网络连接，但仍然要对它们的身份进行验证。而另一方面，这些服务器可能根本不会接受“应用信任边界之外的系统发过来的任何连接。图16整个应用的信任边界本书在讨论共享职责模型、资产清单、控制和监控时还会以图16为例。目前为止，图中还没有出现与云相关的控制，但随着对本书的深入学习，我们将会逐步介绍这些内容。最后需要留
11、意图中每一条横跨两个信任边界的连线，这都是我们在实施安全措施时应该首要关注的地方。云交付模型云计算领域有一条不成文的规定：如果一本关于云计算的书里没有介绍基础设施即服务(InfrastructureasaService,IaaS)、平台即服务(PIatfOrmaSaSerVice,PaaS)和软件即服务(SoftwareasaService,SaaS)这些概念，那么这本书的内容体系就很难称为完整,而本书并不打算追求这种所谓的“完整”，因为我认为这些服务模型只对理解通用概念比较有用。尤其是现在IaaS和PaaS之间的界定，正变得越来越模糊。例如内容分发网络(ContentDeliveryNetw
12、ork,CDN)服务，在互联网上缓存信息以使得内容离用户更近，是属于IaaS还是PaaS?这其实并不重要，重要的是理解服务提供了什么(以及没有提供什么)，而不是去分清楚它是否恰好属于哪个特定类别。云共享职责模型一个最基础的安全问题是你必须要回答的：“安全的哪些方面由我负责？在本地部署环境中，这个问题通常已经隐式地回答了。开发部门只对代码错误负责，除此之外的其他所有事务一概由运维部门(IT)负责。而现在很多公司已经开始使用DeVOPS模型，在该模型中，安全职责都是需要跨部门共同承担的，开发和运维之间的职责划分已经难以区分，甚至根本不存在了。但不管公司的组织方式如何，几乎所有的安全职责都会落在公司
13、内部。从本地部署环境迁移到云环境的最大变化之一也许是，一个与安全相关的更加复杂的共享职责模型。在本地部署环境中，IT或一些其他部门负责服务器的运维，你与他们之间的职责划分会形成内部文档或合约。但在很多情况下，IT业务的用户已经习惯了将需求或代码交给内部的基础服务提供者，由后者替他们完成所有任务，尤其是在安全方面。即使你己经在云环境中运营了一段时间，你也可能尚未停下来去着手考虑云提供商的职责边界在哪里结束，以及自己的职责边界从哪里开始。这条边界线会因你购买的云服务的种类不同而有所差异。虽然几乎所有云提供商都会在它们的文档或培训里介绍这些内容，但最容易理解这种差异的方式还是用吃比萨来类比。在比萨即
14、服务3(Pizza-as-a-Service)中，我们假设你饿了，想吃比萨。你可以有多种选择，可以自己在家做，但这种方式需要自己准备很多原料，而且要花不少时间；也可以去食品店买一个加热即食的比萨，这样你只需要一个微波炉和一个可以吃比萨的地方，还可以打电话给你最喜欢的比萨外卖店，或者也可以坐到饭店直接点一个比萨。如果将以上过程涉及的各个部分，以及每个部分的职责方画到一起，我们就会得到图17。比萨传统本地部署基础设施即服务(IaaS)I 食用 II咎奈I平台即服务 (PaaS)I苏打水I软件即服务I在家,好1I加热区食I比萨外卖I外出就餐诙客职责提供商职责图1-7比萨即服务传统的本地部署就像自己在
15、家做比萨。你需要买很多原料，然后亲自将它们做成比萨，过程比较麻烦，但好处是足够灵活。全麦面饼上面撒凤尾鱼和肉桂？只要你能接受，做起来就没任何困难。如果你使用IaaS,最下面一层就已经为你做好了。你只需负责烘烤，再配点沙拉和饮料即可，这些都是你的职责。如果升级到PaaS,那么底层己经为你做好的事情就更多了，这些事情都可以直接作为你的整体计划的一部分(前一节提到，有时很难将一个服务划分为IaaS还是PaaS,因为在很多情况下这两者正在逐步融合为同一种类型。到底属于哪一类并不重要，重要的是理解这个服务提供了什么，以及你自己的职责是什么)。如果使用SaaS(对应图17中的“外出就餐”)，看上去似乎所有
16、事情都已替你做好，但其实并没有。你仍然要行使安全就餐的职责，呛到或噎到自己，饭店是不负责的。在SaaS领域中，这通常属于对访问控制合理管理的范畴。将比萨模型对应到技术领域，可以得到图1-8。图18云共享职责模型不过在实践中，云计算要比吃比萨的例子稍微复杂一些，因此图中有一些介于深灰和浅灰之间的区域。图中最下面的部分都是具体的（通常从字面上就可以看出来）。云提供商对物理基础设施的安全负全部责任它们所做的控制通常比很多公司在本地部署环境中所做的事情要多，例如带防尾随功能的生物特征访问、安全防护、级联防御屏障，以及其他类似的控制技术，其目的都是将未授权用户隔离在物理设施之外。类似地，如果提供商提供的
17、是虚拟化环境，那么虚拟化基础设施的安全控制的职责，即将你的虚拟环境与其他用户的虚拟环境隔离，就由提供商来承担。在2018年初曝出的SPeCtre和MeltdOWn漏洞中，一个潜在风险就是：一个虚拟机内的用户能够读取同宿主机上另一个虚拟机的内存。对于IaaS客户来说，修复这部分漏洞是云提供商的责任，但修复虚拟机操作系统内的漏洞则是客户的责任。在图1-8中，IaaS中的网络安全显示为一个共享职责。为什么呢？原因很难在图上画出来，但我们可以解释如下：网络有很多层，不同层的职责属于不同的责任方。云提供商有自己的网络，保障这些网络的安全是它们的职责，但通常在这层网络之上还有一层虚拟网络（例如，很多云提供
18、商提供虚拟私有云功能），保隙这层虚拟网络的安全就是客户的职责。客户需要将虚拟网络划分到合适的安全区（securityzone）中，并对其设置恰当的访问规则。有些实现还会涉及叠加网络（OVerlaynetWolk）、防火墙和透明加密，这些也是客户的职责。这些内容将在第6章深入讨论。操作系统安全的责任归属通常就比较简单直接。如果你使用的是IaaS,责任方就是你自己;如果购买的是PaaS或SaaS,责任方就是提供商。通常来说，如果购买的是这些服务，你就没有访问底层操作系统的权限（这里的一条经验法则是，如果你有打破一样东西的能力,你就有责任去保护它的安全）。中间件（middleware）这个词在这里是
19、泛指数据库、应用服务器或队列系统等软件的通用名称。它们位于操作系统和应用之间一没有被用户直接使用，但又是设计终端用户解决方案所必需的。如果你使用的是PaaS,中间件安全通常就是共享职责，提供商保证软件是最新的（或者保证能让你很容易升级到最新版本），但和安全相关的设置的职责属于你自己，例如加密的设置。应用层是终端用户真正使用的。如果你使用的是SaaS,那么这一层的漏洞（例如跨站脚本攻击或SQL注入）就是提供商的职责。不过，既然你正在读本书，可能就并不仅仅是在用别人提供的SaaS平台。如果应用安全层有漏洞，即使其他所有层的安全部署都无懈可击，你的所有信息也还是会轻易地暴露。最后，作为客户，数据访问
20、安全几乎永远是你的职责。如果你在云提供商平台错误地配置了允许对特定数据的访问，例如错误地授予存储权限、中间件权限或者SaaS权限，那么提供商也没有什么可以补救的办法。许多安全事件发生的根本原因是，客户以为云提供商会处理一些事情，但后来的事实证明没有任何一方会处理。在真实世界中，因客户对共享职责模型理解不足而导致的安全事件，有很多来自AWS（AmazonWebService）简单存储服务（SimpleStorageService,S3）中的桶（bucket）oAWSS3存储本身是安全的和加密的，但是如果没有设置恰当的访问控制，这些安全功能也起不到任何作用。这种错误理解导致了以下数据的泄露： 1.
21、98亿名美国选民的数据 自动跟踪公司记录 无线客户记录 超过300万份人口调查记录 超过5万份印度公民信用报告如果你认为共享职责模型的讨论过于浅显，那么恭喜你，你已经进入了前四分之一。根据BarraCUdaNetWorkS在2017年的一项调查，共享职责模型在日常业务开展中仍然被使用者广泛误解。大约77%的IT决策者认为，公有云提供商负责保护云上的客户数据安全，68%则认为这些提供商也负责保护客户应用的安全。但是如果你去读一读与公有云提供商的合同，就会发现里面根本没有这些内容！风险管理风险管我是一个很深奥的课题，有很多关于它的书。如果你有兴趣想认真研究风险管理，我推荐阅读DouglasW.Hu
22、bbard所著的TheFailureofRiskManagement:WhyIfsBrokenandHowtoFixIt一书（Wiley出版社出版），以及美国国家标准与技术研究院（NIST）发布的SpecialPublication800-30Rev1。如果用一个词来概括人们在评估风险和确定如何应对风险上的表现，这个词就是：非常糟糕。本节试图给你提供一些最基本的管理安全事件和数据泄露风险的知识。冒着过于浅显的风险来解释的话，风险一词指可能发生的一些坏事。在大部分风险管理系统中，风险等级的评定都是基于两方面的组合：坏事有多大概率发生（可能性），以及发生后带来多糟糕的后果（影响）。例如，很有可能会
23、发生（例如有人猜出了你的密码是“1234”），并且发生后有非常严重后果（例如你丢失了所有客户文件，需要支付巨额罚金）的就属于高风险。很小概率会发生（例如小行星同时撞毁两个位于不同地域的数据中心），但发生后也有非常严重后果（例如停业）的就属于低风险，具体取决于你所使用的风险等级评定系统。4本书将讨论未知风险（没有足够的信息来判断其可能性和影响的风险）和已知风险（至少能确定我们将会面对的那些风险）。对已知风险有了了解之后，你就可以从下面四种方法中选择一种方法进行应对：1 .避免风险。在信息安全领域，避免风险通常意味着关闭系统关闭了就没有任何风险，但同时也失去了系统运行能带来的所有收益。2 .降低风
24、险。系统仍然运行，但通过额外措施降低风险发生的可能性或发生后带来的影响。例如，你可以选择存储不太敏感的数据，这样当发生数据泄露时，后果不会过于严重。3 .转移风险。有偿地将这部分业务交给他人管理，这样风险就是他们的事。在云环境中这种方式非常常见，客户将管理更低层系统的风险交给云提供商。4 .接受风险。经过系统地评估风险等级和能持续带来的收益，判断出风险确实存在，设法让投资人一致同意这确实是一个风险，但允许继续运行。以上任何一种措施都可能是合理的。然而，我们不能接受的是：不知道面临哪些风险，或者虽然对风险有一定了解，但没有权衡后果或没有取得投资人同意就接受了这个风险，并继续运营业务。至少，你应该
25、在电子表格或某个文档里列一个清单，详细说明自己己知的风险、已经采取的行动，以及哪些需要征得同意。UlVerizon数据泄露调查报告是一个非常好的免费资源，介绍了不同类型的得逞攻击，它根据行业和攻击方式组织内容，其中的执行摘要部分尤其值得一读。|2|我推荐AdamShostack所著的ThreatModeling:DesigningforSecurity一书（Wiley出版社出版）。3原创概念来自AIbertBarron的一篇文章。4风险也可能会交织或聚合。可能性和影响都相对较小的两个风险可能会同时发生，后果比二者单独发生的后果之和要更加严重。例如，在有冗余电源的情况下，单独断开任何一路，其影响
26、可能都是可以忽略的，但是如果两路同时断开，后果就非常严重了。这种情况很难发现，2017年亚特兰大机场断电就是一个很典型的例子。第2章数据资产管理与保护在第1章中，你已经对提供商的职责在哪结束、你的职责从哪开始有了一些概念上的了解。接下来的第一件事就是：确定你的数据存在哪里，或者将要存在哪里，以及如何保护它们。“资产管理(assetmanagement)”一词经常给大家带来很多困惑。到底什么算是我们的资产？管理这些资产又该如何去做？一个显而易见(但并无帮助)的回答是：资产是你拥有的任何有价值的东西。我们来详细讨论这个主题。在本书中，我把资产管理分为两种类型：数据资产管理(Ciataassetma
27、nagement)和云资产管理(cloudassetmanagement)e数据资产对你来说是很重要的信息，例如客户姓名和地址、信用卡信息、银行账户信息，以及能访问这些数据的凭证(Credemia1)。云资产用来存储和处理数据，例如服务器和容器等计算资源、对象存储和块存储等存储资源、数据库和消息队列等平台实例。如何管理这类资产将在下一章介绍。虽然你可以从数据资产或云资产开始，但你可能只有时常前后对照学习才能形成一个全貌，我认为先从数据资产开始要更容易一些。理论上，管理云中的数据资产和管理本地部署环境的数据资产并无不同，但实际上对于前者，有些现成的云技术对我们还是很有帮助的。数据鉴别与分类如果你
28、至少画过一张“餐巾纸背面“图(back-of-the-napkindiagram),也清楚了上一章介绍的威胁模型，你就会对哪些是重要数据、需要关心的威胁行为体类型以及它们可能导致的后果等能有一些了解。我们先来看看威胁行为体有哪些攻击数据的方式。一种比较流行的信息安全模型是CIA三要素(triad)：机密性(confidentiality),完整性(integrity)和可用性(availability)。试图破坏数据机密性的威胁行为体希望窃取你的数据，然后通过售卖获利或者让你陷入困境。试图破坏数据完整性的威胁行为体则是想去修改你的数据，例如修改银行账户余额(注意，即使攻击者无法读取账户余额，这
29、种破坏也是有效的，我很乐意让我的银行账户余额和比尔盖茨的一模一样，即使不知道这个余额的具体值是多少)。试图破坏数据可用性的威胁行为体希望破坏你的网络以此来取乐、获利，或者使用勒索软件加密你的文件。1我们大部分人都只有有限的资源，因此必须要对耗费精力的各类事务排一个优先级。2数据分类系统可以为此提供帮助，但要注意如无绝对必要，不要将事情处理得过于复杂。示例数据分类等级每个公司的情况各不相同，但下面的规则可以作为评估数据价值的一个简单易行的起点，从而评估打破这些规则带来的数据外泄风险。低(low)此类信息可能会有计划或无计划地向公众开放，但即使其被公开，带给公司的影响也非常小，甚至可以忽略。下面是
30、几个例子： 你的服务器公网IP地址 不包含任何个人数据、密码或其他对攻击者有价值的应用日志数据 不包含任何密码或其他对攻击者有价值的软件安装资料中(moderate)如果没有恰当的保密协议，此类数据则不应当被公布到公司之外。在很多情况下(尤其是大公司)，此类数据在公司内部只有在需要知道(need-to-know)时才会公布。在大部分公司中，绝大部分信息都属于此类。下面是一些例子： 关于如何设计公司信息系统的详细资料，这些资料可能对攻击者很有用。 人事信息，这些信息可以给攻击者实施网络钓鱼(PhiShing)或假托攻击(pretextingattack)带来帮助。 例行财务信息，例如采购清单或差
31、旅费报销单，这类信息可能会被用来推测公司并购的可能性。高(high)此类信息对公司非常重要，一旦泄露就会给公司造成严重损失。你应该配备多重安全保护机制，严格控制对此类数据的访问。在一些公司中，这类数据被称为“王冠上的宝石列举以下儿个例子： 对竞争者非常有利的公司未来战略信息或财务信息。 商业机密，比如非常畅销的软饮料或炸鸡配方。 提供了“天国之钥”的机密信息，例如能访问云基础设施并带有完整权限的凭证。 你负责保管的一些敏感信息，例如客户的财务数据。 任何其他可能有新闻价值的信息。注意，法律和行业条例能有效规定你如何对信息进行分类。例如，欧洲联盟(简称欧盟)的通用数据保护条例(GeneralDa
32、taproteclionRegulation,GDPR)对处理个人数据有很多不同的要求，因此在GDPR保护范围内，你会选择将所有个人数据归类为“中”级风限,并做有针对性的保护。支付卡行业(PaymentCardIndustry,PCI)的要求会更严格，如果你的环境有持卡用户的数据，那么根据要求你会将这些数据归为“高级风险。另外，市面上有一些有助于数据分类和保护的云服务。例如，AmaZOnMaCie能帮你发现S3数据桶中的敏感数据，GoogleCloudDataLossPreventionAPl(GOOgle云防数据丢失API)可以帮助你分类或掩藏特定类型的敏感数据。不论使用哪种数据分类系统，你
33、都需要先定义出一份分类等级以及各等级的几个示例，然后确保生成、收集和保护数据的每个人都理解这套分类系统。相关行业或监管要求本书关注的是安全(SeCUrity),而不是合规(COmPlianCe)。总的来说，合规就是向第三方证明你的安全性如果系统和数据已经有了保护措施，那么通过合规认证还是很容易的。本书的内容是帮你将系统变得安全，但系统安全做好之后，还有其他的合规工作和文档需要完成。然而，一些合规要求会对安全性设计有影响。因此，我们有必要介绍几个行业或监管要求，即使这些内容现在出现得还为时尚早：欧盟GDPRGDPR适用于任何欧盟或欧洲经济区公民的用户数据，而不管数据实际存储在哪里。GDPR要求对
34、“任何能够通过特殊标识符就被直接或间接识别的自然人信息”编制目录，并进行保护和审计。本章介绍的技术将有助于你满足GDPR的一些要求，但你自己需要确保相关的个人数据己经在其保护范围内。美国联邦信息安全管理法案或联邦风险与授权管理计划联邦信息安全管理法案(FederaIInfOrmalionSeCUrityManagementAct,FISMA)只适用于单个机构，而联邦风险与授权管理计划(FederalRiSkandAUthoriZationManagementProgram,FedRAMP)认证适用于多个机构，但两者都要求按照联邦信息和信息系统安全分类(FIPS199)和其他美国政府的标准对数据
35、和系统进行分类。如果你所在的领域需要用到这些认证，那么就需要使用FlPSl99分类等级。美国国际武器贸易条例如果你受国际武器贸易条例(InlemaIionalTraffiCinArmSRegUlaliOnS,ITAR)管制，除了自己的控制，你还要选择符合ITAR的云提供商。一些云提供商提供此类服务，并且这些服务完全由美方人员管理。全球支付卡行业数据安全标准如果涉及信用卡信息的处理，那么你就需要符合支付卡行业数据安全标准(PaymentCardIndustryDataSecurityStandard,PCIDSS)的一些具体要求，并且有些类型的数据是不允许存储的。美国健康保险便利和责任法案如果你
36、在美国开展业务，并且正在处理任何与受保护的健康信息(PrOteCtedHeaIthInformation,PHI)有关的内容，健康保险便利和责任法案(HeaIthlnSUranCePortabilityandAccountabilityAct,HIPAA)则会强制要求你在服务说明中包含和保护这些信息，这通常会涉及一些加密工作。除此之外，其他国家也有很多监管和行业条例，例如MTCS(新加坡)、G-Cloud(英国)和IRAP(澳大利亚)。如果你觉得自己可能会面临这些条例的监管，那么就需要仔细阅读这些条例，确定它们所保护的数据类型，这样就能对数据分门别类加以划分，并提供相应的保护。3云中的数据资产
37、管理前面介绍的大部分内容并非只适用于云环境，而是也具备更好的通用性。然而，云提供商处在一个非常独特的位置，有助于你对数据进行鉴别和分类。如果你刚开始使用云环境，那么就可以依靠提供商给出所有你要存储数据的地方，提供商在这方面做得非常好，因为它们想因这些存储服务而向你收费！另外，在设计上使用云服务会带来一定程度的标准化。在很多情况下，你在云中的持续数据存储不是将数据散落在不同物理服务器的几千个磁盘上，而是会用到提供商提供的某种云服务，例如对象存储、文件存储、块存储、云数据库或云消息队列。你可以利用云提供商提供的相应工具对这些存储位置建立详细清单，或者（以谨慎控制的方式）访问这些存储位置来确定存储的
38、是什么类型的数据。也有一些云服务可以扫描所有的存储位置，然后尝试自动分类出重要数据的位置，这样你就可以利用这些信息给存储数据的云资产打上相应的标签。8f当鉴别重要数据时，不要忘记密码、APl密钥以及其他可以用来读取或修改这些数据的机密信息。我们将在第4章讨论保护这些机密信息的最佳方式，但前提是你要准确知道它们的存储位置。在我们的示例应用中，数据库里显然存储了用户数据。除此之外，还有哪些地方有重要资产？而以下列出的都需要加以考虑：Web服务器中有日志数据，可能被用来识别用户。 Web服务器中有一个传输层安全（TranSPe）rtLayerSecurity,TLS）证书密钥。有了这个密钥，再加上D
39、NS或BGP劫持，任何人都可以伪造你的网站，在客户试图登录网站时窃取他们的密码。 你是否存储了密码散列来验证用户？希望你使用的是第4章将要介绍的联合身份系统（federatedIDsystem）这一类系统，否则这些密码散列就是攻击者的理想目标。4 你的应用服务器需要一个密码或API密钥来访问数据库。一旦有了这个密码，攻击者就可以像应用一样读取和篡改数据库内的所有内容。从上面可以看出，即使在这些非常简单的应用中，也有很多不易察觉的地方需要保护。图2-1在图1-6的基础上在方框内添加了数据资产。给云资源打标签大部分云提供商以及容器管理系统（如Kubemetes）都有标签（tag）的概念。一个标签通
40、常是一个名字（或“键）和一个值的组合。这些标签的使用可以有多种目的，从对资产清单内的资源进行分类，到做出访问决策，再到选择警告对象等。例如，对于任何包含个人可识别信息（PerSOnalIyIdentifiableInformation,PII）的数据，可以将键设为PILdata,值设为yes,也可以将datatype作为键，Pn作为值。图2-1带数据资产的示例应用图存在一个很明显的问题：如果公司内每个人都使用不同的标签，那么标签的作用将会大打折扣。因此你需要创建一个标签列表，并给每个标签附上使用说明，让大家都知道应该何时使用这些标签。然后，将这个统一范本应用到多个云提供商那里，并做到在资源创建
41、时新标签能自动地（如利用自动化工具）打上去。即使你的云提供商没有显式地支持标签功能，它们通常也有其他的描述字段，因此你可以将这些标签以一种易于解析的格式（如JSON）填到这些字段里。标签的使用是免费的，因此可以毫无顾虑地创建大量标签虽然云提供商会对每个资源可打的标签数量有一定限制（通常每个资源允许使用15到64个标签）。如果某些标签随后不会被用作分类或用作决策参考，那么忽略它们即可。一些云提供商甚至提供自动巡检功能，可用来查看当前的标签是否正确地应用到了资源上，因此那些没有打标签的或打错了标签的资源能及早被发现和更正。例如，如果有一条规则要求每个资产必须打上该资产允许的最高数据安全等级标签，那
42、么你接下来就可以通过自动巡检发现那些没有打上这个标签的资源，或者所打标签没有在规定的安全等级范围内的资源。虽然所有主流的云提供商都以某种形式支持标签功能，但就在写作本书时，它们也并不能将此类服务做到全覆盖。例如，你能对创建的虚拟机打标签，但对数据库却不行。当标签功能不可用时，你只能退回到传统的办法：手动维护这些服务的实例列表。表2-1列出了不同云提供商提供的标签功能的名称。表2-1标签功能I基础设施功能名称iAmazonWebServicesTagsMicrosoftAzureTagsGooglcComputePlatformLabels和networktagsIBMCloudTagsKube
43、mctesLabels我们在第3章还会深入讨论打标签功能，但从现在开始，你就可以先粗略地创建儿个与数据相关的标签，并应用到不同的云资源上，例如dataclass:lowdataclass:moderatedataclass:highB!cregulatory:gdpro在云中保护数据本节介绍的一些数据保护技术也可以用于本地部署，但相比之下，很多云提供商提供的数据保护方式会更加简单和标准化，也相对比较便宜。令牌化如果可以存储与原始数据功能类似但对攻击者毫无用处的数据，为什么还要存储原始数据呢？令牌化（tokenization）技术是用一个（通常是随机生成的）令牌（token）代替一段原始的敏感数
44、据，经常用于对信用卡卡号的处理。这种方式的好处是：令牌通常和原始数据有相同的特点（例如同为16位长），因此底层那些处理此数据的服务无须做任何改动。在令牌化技术中，只有一个地方（“令牌服务”）知道真实的敏感数据。令牌化可以单独使用，也可以和下面要介绍的加密技术一起使用。令牌化的例子有：基于浏览器的云服务会在发送敏感数据之前先将其令牌化；位于浏览器和应用之间的云服务会先将敏感数据令牌化，然后才将其发送给应用。加密加密（encryption）是数据保护领域的银弹，我们希望“对所有数据加密”。但不幸的是，实际情况比想象中要更为复杂一些。数据可分为三种状态： 传输中（inmotion,正在通过网络传输）
45、 使用中（inuse,正在计算机CPU中接受处理或正停留在内存中） 已落盘（atrest,已位于持久存储中，例如磁盘）对传输状态的数据进行加密是一项必要的控制措施，我们将在第6章详细介绍。本节介绍其他两种状态的数据。加密所用的位数并不是越长越好（有时甚至没用）。例如，虽然量子计算机可能最终会对AES-128构成威胁，但在写作本书时，AES-128仍然符合美国联邦政府标准，而且通常比AES256更快。另外，如果哈希被截断为更短的长度，那么像SHA512这样的哈希算法就不会提供更多的保护。对使用中的数据加密在写作本书时，对“使用中”的数据进行加密还是相对比较新的领域，它主要定位于安全要求非常高的环
46、境。它需要硬件平台的支持，而且还需要云提供商将这种支持公开给用户。其中，最常见的实现是加密进程内存，这样即使是特权用户（或以特权用户身份运行的恶意软件）也无法读取进程的内存，即便是处理器也只能在进程运行时才能读取。5如果所处的是安全要求非常高的环境，并且威胁模型中包含保护内存中的数据不受特权用户的访问，那么你应当寻找支持内存加密的平台；提供商在此功能上各有自己的品牌，例如IntelSGXAMDSME以及IBMZPervasiveEncryption0对已落盘的数据加密正确实现对已落盘数据的加密是最为复杂的一件事情，复杂之处并非是对数据进行加密本身，很多函数库都可以做这件事情。真正的问题是，一旦
47、做了数据加密，你就有了一个访问相应数据的密钥，那大家把这个密钥放到哪里了呢？放到了数据旁边！想象一下，你锁了一扇门，然后把钥匙挂到门旁的一个挂钩上，并且挂钩上面还写着“钥匙”等提示信息。要想达到真正的安全（而不是仅仅为了勾上一个“已完成加密”的待办事项），你必须有正确的密钥管理。幸运的是，很多云服务可以帮我们做这件事。g”V。加密后的数据无法达到高效的压缩。因此如果你想对数据进行压缩，就应该在加密之前做。在传统的、对安全要求很高的本地部署环境中，通常是购买硬件安全模块（HardWareSecurityModule,HSM）来保存密钥，一般是以扩展卡或网络访问模块的形式。HSM对未授权访问有很多
48、重要的逻辑和物理保护机制。对于大部分系统而言，任何有物理访问权限的人都可以很容易地进入系统，但HSM的传感器一旦检测到有人试图取走数据、用X光扫描数据、乱动数据的电源或其他看起来有威胁的行为，它就可以立即删除数据。由于HSM费用较贵，因此对于大部分本地部署来说，可行性不高。然而在云环境中，对于中等预算的项目，类似HSM和密钥管理系统这样的高级技术也都是可以考虑使用的。一些云提供商支持用户为自己的云环境租用专用HSMo虽然最高安全等级的环境可能确实需要这样的功能，但在云环境中专用HSM仍然是比较昂贵的。还有一种选择是密钥管理服务（KeyManagemenISerVice,KMS）,这是一种多租户服务，背后是使用HSM保证密钥的安全。你必须对HSM和KMS（而不仅仅是HSM）持有信任，即使它们本身也增
