InfoSec-云安全认证专家笔记-全-

InfoSec 云安全认证专家笔记（全）

012：云设计需求 🏗️

在本节课中，我们将学习CCSP认证“架构概念与设计”领域的一个核心部分：云设计需求。我们将探讨如何分析业务需求、进行业务影响分析、评估资产与风险，以及理解组织的风险偏好。这些知识是规划成功云迁移和安全云架构的基础。

需求分析

在深入探讨之前，需要指出，对于CCSP考试必须掌握的特定信息，我会用双星号（**）标出，并在屏幕上以不同颜色高亮显示。

许多组织目前正考虑将其网络运营迁移到基于云的设计中。显然，推动组织进行云迁移的最大驱动力是成本节约。但由于云计算存在不同的服务与交付模型，组织必须决定哪一种模型能优化其成功。这个决定不能轻率做出，业务转型必须支持业务需求。因此，企业必须对其流程、资产和需求进行真实的评估和理解。

您需要理解两种类型的需求：

  • 功能性需求：指设备、流程或员工为完成业务任务所必需的性能方面。例如，外勤销售人员必须能够远程连接到组织的网络。
  • 非功能性需求：指设备、流程或员工那些对于完成业务任务并非必需，但却是期望或要求的方面。例如，销售人员的远程连接必须是安全的。

进行全面的资产、利润和需求清点是必要的。收集这些数据有多种方法。通常，会联合使用几种方法，以减少遗漏的可能性。以下是一些（并非全部）收集业务需求的方法：

  • 访谈职能部门经理
  • 访谈用户
  • 访谈高级管理层
  • 调查客户
  • 收集网络流量数据
  • 清点资产
  • 收集财务记录
  • 收集保险记录
  • 收集市场数据
  • 收集监管要求

收集到足够的数据后，需要进行详细分析。此时将进行业务影响分析，我们接下来将对此进行讨论。

业务影响分析

业务影响分析是对组织内每项资产和流程的优先级评估。资产可以是有形的，也可以是无形的。它们可以包括硬件、软件、知识产权、个人财产、流程等等。有形资产的例子包括路由器和服务器，而无形的资产通常是您无法触及的东西，例如专利、商标、版权和业务方法。

恰当的分析应考虑影响，即每项资产的任何损害或损失对组织整体可能意味着什么。在业务影响分析过程中，我们需要识别关键路径和任何单点故障。您还需要确定合规成本，即组织必须遵守的立法和合同要求。您组织的监管限制将基于许多变量，包括组织运营所在的司法管辖区、组织所在的行业、客户的类型和所在地等。

一旦您清楚地了解了组织在业务线和流程方面的运作情况，您就能更好地理解组织可能从云迁移中获得哪些好处，以及与迁移相关的成本。业务影响分析旨在识别并生成对业务正常运作至关重要的系统和服务的优先级列表。

业务影响分析有三个主要目标：确定关键性、估算最大允许停机时间、评估资源需求。

在确定关键性时，必须识别每一项关键业务功能，并确定中断所造成的影响。估算最大允许停机时间（也称为最大可容忍停机时间），本质上是衡量组织在关键功能中断后能存活多久。换句话说，您需要估算组织在没有其关键资产或服务的情况下可以容忍的最长时间。您需要确定连续性目标和恢复目标的优先级，例如非常高、中等或低。优先级非常高的可能需要立即恢复，中等的可能需要三天，非常低的可能需要30天。

组织内的每个业务功能和流程应归入以下五类之一：关键、紧急、重要、正常、非必要。关键类可能需要在几分钟到几小时内恢复，紧急类在24小时内，重要类72小时内，正常类7天内，非必要类可能30天内。这样管理层可以更好地评估关键性和恢复需求。

恢复点目标是指必须从最近一次已知备份中恢复的文件的时间点。恢复时间目标是指从恢复点目标恢复到正常状态所需的时间。因此，我们要确保处于最大中断时间或最大可容忍中断周期之内。恢复时间目标基本上是从中断到恢复处理的总时间。恢复时间目标必须始终小于最大允许停机时间或最大可容忍停机时间。它包括基础设施、设施和工作空间的恢复。

最后一个目标是评估资源需求和恢复工作。我们在此关注的是恢复关键运营及相关相互依赖关系所需的资源。这涉及记录所有流程、程序、分析结果，然后向高级管理层汇报，识别关键部门和流程、重要的相互依赖关系、漏洞评估摘要以及从分析中生成的建议恢复优先级。

风险评估与资产

为了决定如何处理组织内的风险，我们需要了解某些信息，包括：所有资产的清单、对每项资产的评估、对关键路径、流程和资产的确定，以及对组织风险偏好的清晰理解。换句话说，就是他们愿意承担的可接受风险水平。

风险评估是用于识别、估算和优先处理信息安全风险的过程。这是美国国家标准与技术研究院特别出版物800-39中定义的风险管理过程的关键组成部分。根据NIST SP 800-39，进行风险评估的目的是识别对组织的威胁、组织内部和外部的漏洞、威胁利用漏洞可能造成的损害，以及损害实际发生的可能性。识别这些事实有助于确定风险，包括损害发生的可能性和潜在的损害程度。

评估风险需要仔细分析威胁和漏洞信息，以确定某些情况或事件可能对组织造成不利影响的程度，以及这些情况或事件发生的可能性。这是业务影响分析的一部分。

NIST将威胁定义为任何可能通过信息系统对组织运营和资产、个人、其他组织或国家造成不利影响的情况或事件，方式包括未经授权的访问、破坏、泄露或修改信息和/或拒绝服务。威胁源可分为以下几类，每类都可以扩展为具体的威胁：

  • 人为：例如恶意外部人员、恶意内部人员、生物恐怖主义、破坏者、间谍、政治或竞争行动者、关键人员流失、人为干预或文化问题导致的错误。
  • 自然：例如火灾、洪水、龙卷风、飓风、暴风雪、地震。
  • 技术：例如硬件故障、软件故障、恶意代码、未经授权的使用以及无线或新技术等新兴服务的使用。
  • 物理：例如闭路电视故障、设施组件故障或外围防御故障。
  • 环境：例如危险废物、生物制剂和公用事业故障。
  • 操作：影响机密性、完整性和可用性的流程（手动或自动）。

NIST将漏洞定义为信息系统、系统安全程序、内部控制或实施中可能被威胁源利用的弱点。在我们的专业领域，通常从人员、流程、数据、技术和设施方面识别漏洞。漏洞的例子可能包括：设施入口处缺少接待员、 mantra 陷阱或其他物理安全机制；财务交易软件中完整性检查不足；未要求用户签署承认其安全责任以及确认已阅读、理解并同意遵守组织安全政策的文件；组织的信息系统补丁和配置临时进行，因此既无文档记录也未及时更新。

可能性与影响共同决定风险，这是定性风险评估的一个组成部分。可能性可以通过威胁的能力以及是否存在对策来衡量。没有趋势数据可用的组织可以使用标记为高、中、低的序数尺度来评分可能性排名。影响的排名方式与可能性大致相同，主要区别在于影响尺度被扩展，并且依赖于定义而非序数选择。对组织影响的定义通常包括生命损失、金钱损失、声誉损失、市场份额损失等方面。一旦定义了这些术语，您就可以计算影响。如果一次攻击有可能导致生命损失，那么排名将始终是高的。

风险被确定为可能性和影响的乘积。例如，如果一次攻击的可能性为1（高），影响为100（高），则风险为100。因此，100将是可用的最高攻击排名。这些高可能性和高影响的场景应引起组织的立即关注。

组织可以选择以两种方式之一进行风险评估：定量或定性。

定量分析为分析过程的要素分配真实的数字（成本）。例如，保障措施成本、资产价值、业务影响、威胁频率、保障措施有效性和攻击概率。这里的关键在于它基于真实的数字和成本。进行定量分析时，请记住，定量分析基于真实的数字，如资产或资源的成本。

首先，我们确定资产价值。假设我们有一栋价值100万美元的建筑。第二件事是计算暴露因子。假设上次有人撞上这栋建筑造成了10万美元的损失。单一损失期望值是与所评估的特定风险相关的预期负面影响。结果将是我们的单一损失期望值：资产价值100万美元乘以暴露因子10%，等于10万美元的单一损失期望值。

接下来，我们计算年发生率。年发生率是每年预期发生给定影响的次数，以数字表示。假设似乎每四年就有人撞上我们的建筑一次，即0.25。单一损失期望值10万美元乘以年发生率0.25等于2.5万美元。年损失期望值则是单一损失期望值乘以年发生率，这给出了与特定风险相关的估计年度成本。在这种情况下，年损失期望值等于单一损失期望值乘以年发生率。因此，基本上您可以预期每年预留2.5万美元，持续四年，以覆盖10万美元的预期建筑损坏，这成为您的保障价值。或者，您可以投资2万美元，例如，在建筑前安装混凝土护柱或屏障，以减轻人们撞上建筑或撞击建筑的威胁，从而降低风险。

另一种方法是定性分析。这种方法更主观，没有真实的数字，主要基于风险可能性的情景以及对威胁严重性和对策有效性的意见进行排名，通常为高、中、低或1、2、3、4、5，甚至可能在1到10的尺度上。这里的关键在于它是基于判断、最佳实践、直觉和经验，没有与定性评估相关的真实数字。当关注攻击者时，您首先尝试识别攻击者可能想要攻陷以进入您系统的目标或资产，然后首先加固这些潜在目标。当关注软件时，您正在针对潜在威胁测试您的软件，例如SQL注入、身份验证破坏、跨站脚本、不安全的重定向、安全配置错误、敏感数据暴露、跨站请求伪造等。例如，网页代码缺陷可能导致威胁利用该漏洞攻陷您的系统或数据。

资产识别与估值

为了保护我们的资产，我们首先必须知道它们是什么。组织拥有或控制的一切都可以被视为资产，并且资产有多种不同的形式。资产可以是有形的物品，如IT硬件、零售库存、建筑物和车辆。资产也可以是无形的，如知识产权、公众认知和与业务伙伴或供应商的良好关系。人员也可以被视为资产，因为他们为组织提供的技能、培训和生产力。

为了保护我们所有的资产，我们必须知道它们是什么，在较小程度上知道它们在哪里以及它们做什么。如果我们失去了对我们控制下某物的跟踪，就不可能保护它。因此，创建健全的安全计划的第一步将是执行彻底、全面的清点。有许多方法和工具可以做到这一点，例如调查、访谈、审计等。在执行IT清点时，我们还可以将自动化纳入流程，以提高我们的能力和效率。

在我们确定资产的数量、位置和类型的同时，我们也希望确定每项资产的价值。我们需要能够知道这些资产中哪些提供了我们组织的内在价值，哪些支持这种价值。我们需要知道我们保护的资产的价值，以便我们知道投入多少时间、金钱和精力来保护它们。我们不想在价值5美元的自行车上安装10美元的锁。

估值通常是业务影响分析的一部分。我们为每项资产确定一个价值，通常以美元计，即如果我们失去该资产（无论是暂时还是永久）会给组织带来多少成本，更换或修复该资产需要多少成本，以及处理该资产损失的任何替代方法。有各种分配成本的方法。我们可以使用保险价值、重置成本或其他一些估值方法。

价值度量通常关注三个领域：绝对价值、相对价值和公平市场价值。

  • 绝对价值：仅关注资产的内在价值，不与其他资产进行比较。例如，一辆2019年款Oldsmobile 442，制造商建议零售价为6000美元。这就是该资产的成本。
  • 相对价值：类似资产的价值。例如，其他Cutlass 442，价格在3000到7000美元之间。
  • 公平市场价值：资产作为二手货可以出售的价格。例如，您买了一辆新车，在经销商处是6000美元。一旦您登记了所有权并开离停车场，它就成了二手车。现在，同一辆车价值1200美元，而不是6000美元。

关键性与单点故障

一旦清点评估完成，业务影响分析工作将继续进行，由高级管理层确定关键性。关键性是指组织没有它就无法运作或生存的那些方面。这些可能包括有形资产、无形资产、特定的业务流程、数据路径甚至关键人员。

以下是组织中关键方面的一些例子：

  • 有形资产：组织是一家租车公司。汽车对其运营至关重要。如果没有汽车租给客户，它就无法开展业务。
  • 无形资产：组织是一家音乐制作公司。音乐是公司的知识产权。如果音乐的所有权受到损害，例如版权受到挑战，然后公司失去所有权，或者保护音乐文件的加密被移除，音乐可以被无保护地复制，那么公司就没有任何有价值的东西，将无法生存。
  • 流程：组织是一家以其速度著称的快餐店。接受订单、准备和交付食物以及收款的流程对其运营至关重要。如果餐厅因某种原因无法完成该流程，例如收银机故障导致餐厅无法接受付款，餐厅就无法运作。
  • 数据路径：组织是一家国际航运公司。将订单与货运承运人匹配对其运营至关重要。如果公司无法完成其物流协调，将货物请求分配给有足够运力的承运人，它就无法提供服务，也将无法生存。
  • 人员：组织是一家外科服务提供商。外科医生对公司的存在至关重要。如果外科医生不能做手术，就没有公司。

虽然高级管理层拥有确定关键性的正确视角，但高级专业人员应该对组织的整体使命和功能有良好的理解，以便更好地服务和指导组织保护关键要素。

业务影响分析过程中另一个可以支持安全工作的是识别单点故障。如果在某个流程、程序或生产链中存在任何瓶颈点，即整个工作流会因为失去单一元素而停止的地方，那就是一个单点故障。单点故障，尤其是在关键路径上，对组织构成重大风险，应在识别后尽快解决。

与关键方面一样，单点故障可能由硬件、软件、流程或人员引起。处理单点故障的方法包括：

  • 增加冗余，以便如果单点故障失效，可以立即获得替代品。
  • 创建替代流程，在单点故障停机时取代其功能。
  • 交叉培训人员，使他们能够担任多种角色。
  • 持续、彻底地备份数据，并确保可以轻松快速地恢复，例如负载共享或平衡IT资产。

在云环境中，客户应期望提供商在其设施和架构内没有单点故障。迁移到云端的部分好处是云提供商能够提供健壮且有弹性的服务，不易因单点故障而失效。因此，客户可以专注于减少其自身运营侧在访问和使用云中数据时的任何单点故障。

请注意，并非所有单点故障都是关键方面的一部分，也并非组织的所有关键方面都包含单点故障。

风险偏好与风险处理

风险偏好或可接受风险水平并不是一个新概念，使用云服务并不会显著改变其任何方面。由于这个概念对整体安全实践的重要性以及它被纳入CCSP公共知识体系，在此值得提及。风险偏好或可接受风险水平是组织认为可以接受的风险水平、数量或类型。这因组织而异，基于许多内部和外部因素，并且可能随时间变化。

以下是对一些风险基础知识的快速回顾：风险是可能性和影响将被实现的可能性。风险可以减少，但永远无法消除。组织接受一个允许运营以成功方式继续的风险水平。只要不涉及健康与人身安全，接受高于常态或高于竞争对手的风险是合法且可辩护的。健康与人身安全相关的风险必须按照行业标准或组织所遵守的监管要求进行处理。

组织有四种主要方式处理风险：风险规避、风险接受、风险转移和风险缓解。

  • 风险规避：这并非真正处理风险的方法。它意味着放弃一个商业机会，因为风险实在太高，且无法通过足够的控制机制进行补偿。换句话说，风险超出了组织既定的风险偏好或可接受风险水平。
  • 风险接受：这与规避相反。风险在组织的风险偏好范围内，因此组织继续运营，不对该风险采取任何额外措施。
  • 风险转移：在这里，组织支付费用让他人以低于风险实现时潜在影响的成本来承担风险。这通常以保险的形式出现。这类风险通常与发生概率低但一旦发生影响高的事情相关。
  • 风险缓解：在这里，组织采取措施降低风险的可能性或影响，通常是两者都降低。这可以采取控制措施或对策的形式，通常是安全从业人员参与的领域。

风险存在于每一项活动中。我们可以管理风险、减弱风险，甚至最小化风险，但运营中始终存在风险因素。当我们选择通过应用对策和控制来缓解风险时，剩余的风险称为残余风险。安全计划的任务是持续降低风险，直到其符合组织风险偏好下的可接受风险水平。组织的风险偏好由高级管理层设定，是组织内所有风险管理活动的指南。安全从业人员必须透彻理解组织的风险偏好，才能正确有效地履行其职能。

总结与应用

一旦确定了业务需求并完成了业务影响分析，所获得的信息可以并且应该在整个组织的许多安全工作重复使用。例如，业务影响分析结果可用于风险评估、整个环境中特定安全控制的选择以及业务连续性或灾难恢复计划。了解组织的关键方面和所有资产的价值对于完成这些任务至关重要。

在本节课中，我们一起学习了：

  • 功能性和非功能性需求。
  • 收集业务需求的可能方法。
  • 业务影响分析流程。
  • 将有形或无形资产定义为资产，以及资产清点的重要性。
  • 讨论了资产估值为绝对价值、相对价值或公平市场价值。
  • 我们讨论了风险评估，包括威胁及其NIST定义（考试需要回忆）、漏洞及其NIST定义（考试需要回忆），以及损害、可能性和影响。
  • 我们还讨论了定量和定性分析。您需要回忆用于确定年损失期望值的公式以备考试。
  • 确定了关键性、单点故障，最后是风险偏好。

013：云模型边界 🏗️

在本节课中，我们将要学习CCSP认证“架构概念与设计”领域的一个重要主题：云模型边界。我们将探讨不同云服务模型（SaaS、PaaS、IaaS）中，客户与提供商之间的责任划分与控制边界，这对于理解云安全至关重要。

概述

云服务通常根据供应商提供的服务、客户的需求以及服务合同规定的各方责任，分为三种通用模型。理解这些模型中的控制边界是确保云安全合规的基础。

云服务模型

以下是三种主要的云服务交付模型。

软件即服务 (SaaS)

在SaaS模型中，客户对其所订阅的系统和应用程序的控制权最小。

  • 客户仅控制他们使用云服务提供商软件所创建的数据。
  • 云服务提供商控制底层的基础设施、平台和应用程序软件。

平台即服务 (PaaS)

在PaaS模型中，客户的控制权有所增加。

  • 客户控制他们上传的软件以及他们生成的数据。
  • 云服务提供商控制客户用来上传其软件的操作系统及以下层级（如运行时环境、服务器、存储、网络）。

基础设施即服务 (IaaS)

在IaaS模型中，客户对其使用的系统和应用程序拥有最多的控制权。

  • 客户控制从操作系统往上的所有层面，包括应用程序、数据和运行时环境。
  • 云服务提供商控制数据中心的基础设施（物理设施、服务器、网络硬件）。

核心关系可以概括为：

客户控制范围： SaaS < PaaS < IaaS
提供商控制范围： IaaS < PaaS < SaaS

传统环境与云环境的边界对比

上一节我们介绍了三种云模型的基本定义，本节中我们来看看云环境与传统IT环境在安全边界上的根本区别。

在传统环境中，组织拥有明确的IT边界。边界内的一切（数据、硬件、风险）都属于组织，边界外则是他人的问题。我们可以在内部环境与外部因素之间的接口处加固防御，例如建立非军事区（DMZ）。

云计算则并非如此。在云设计中，我们的数据存放在他人拥有的IT环境中，运行在不属于我们且基本不受我们控制的硬件基础设施上。我们的用户操作着我们访问权限有限、了解有限的程序和机器。因此，很难确切知道云模型中的边界在哪里、我们的风险位于何处以及它们实际延伸的范围有多广。

法律责任边界

在现行的法律和监管制度下，云客户最终要对任何数据损失承担法律责任。 即使云提供商被证明存在疏忽或恶意行为，这一点也成立。

如果云提供商因某种过失对客户造成损害，客户可以向提供商寻求赔偿。例如，如果云提供商雇佣的管理员非法出售属于云客户的数据访问权，客户可以起诉提供商要求赔偿。

然而，云客户仍然对适用于该数据损失的所有法定义务承担法律责任，例如遵守该司法管辖区内的数据泄露通知法律（如《通用数据保护条例》（GDPR）或美国隐私盾框架）。这一责任不会因为云客户将运营外包给云提供商而终止。客户始终要对其控制的数据负责。

不同云模型中的控制边界

了解了不变的法律责任后，我们来看看这些控制边界在不同云模型中的具体表现。

基础设施即服务 (IaaS) 中的边界

在IaaS中，云客户在所有可能的云模型中拥有最多的责任和权限。

  • 提供商负责：构成数据中心的建筑和土地、提供连接和电力、创建和管理硬件资产。
  • 客户负责：从操作系统往上的所有一切。所有软件将由客户安装和管理，所有数据将由客户提供和管理。

在安全方面，云客户仍然失去了传统环境中的部分控制权。例如，客户显然无法选择特定的IT资产，因此采购过程中的安全性（通常包括对供应商的审查）必须委托给云提供商。客户也可能失去监控数据中心内部网络流量的部分能力，这使得审计变得困难，进而影响安全策略和监管合规。组织在迁移上云时，可能需要调整安全策略以反映新的约束，并必须找到某种方式来提供必要的交付成果以满足监管机构的要求。

重要提示：在IaaS中，云客户仍然可以收集和审查从其部署的软件（包括操作系统）生成的事件日志，这能提供大量关于数据使用和安全性的信息和洞察，可能满足审计员的要求。

平台即服务 (PaaS) 中的边界

在PaaS中，云客户对环境的控制权进一步减少，因为云提供商现在负责安装、维护和管理操作系统。这将需要对安全策略进行进一步修改，并付出额外努力以确保符合法规。

然而，云客户仍然可以监控和审查软件事件，因为在操作系统上运行的程序属于客户，更新和维护软件的责任也在于客户。但操作系统的更新和管理现在落到了提供商身上，这虽然在运营和安全目的上意味着客户控制权的丧失，但也代表了成本节约和效率提升。

软件即服务 (SaaS) 中的边界

在SaaS中，对环境的大部分控制权都让渡给了提供商。云客户不拥有硬件、软件或两者的管理权。客户只负责向系统中提供和处理数据。就所有相关目的而言，云客户作为一个组织，承担了传统环境中普通用户的角色和职责，拥有很少的管理权限、特权账户和许可。

重申前面提到的，客户仍然对与数据保护相关的所有法定义务和合同义务负责，但在这种情况下，客户对数据如何受到保护几乎没有控制权。云提供商现在几乎独家负责所有系统维护、所有安全对策以及影响数据的大部分策略及其实施，但客户仍然要对其收集或保留的任何数据损失负责。

风险的共同点与缓解措施

在以上三种模型中，客户都放弃了一种基本形式的控制：对数据所在设备的物理访问权限。从组织的角度来看，这带来了风险的严重增加和保证度的降低。任何能够物理访问服务提供商数据位置的人最终都可能（无论是否经过许可）获取数据。

我们可以采取措施来降低此类风险导致泄露的可能性，并且我们需要这样做以履行尽职调查义务。例如：

  • 作为合同或服务级别协议的一部分，我们可以确保云提供商有一个流程来对所有能够访问数据中心和客户数据的人员进行背景调查和持续监控。
  • 我们可以验证在数据中心位置实施了物理安全措施。
  • 我们可以确保在云中处理和存储的数据经过加密。
  • 我们也可以在将数据发布到云之前对其进行加密，或在云中加密，并在提供商外部控制加密密钥。
  • 最后，我们可以在合同中规定提供商应承担的合同责任，同时牢记，对于任何数据损失，法律责任仍由客户承担。

总结

本节课中我们一起学习了各种云服务模型的名义边界，以及从客户和提供商角度看的与每种模型相关的权利和责任。

考试要点回顾：

  • 软件即服务 (SaaS)：客户对系统和应用程序的控制权最小。客户仅控制他们使用云服务提供商软件所创建的数据。
  • 平台即服务 (PaaS)：客户控制他们上传的软件以及他们生成的数据。这是软件开发或任何开发项目的最佳模型，因为你控制了用于开发的软件。在此模型中，云服务提供商控制操作系统。
  • 基础设施即服务 (IaaS)：客户对系统和应用程序的控制权最大。请记住，在所有服务模型中，云服务提供商都控制着数据中心。

014：保护敏感信息 🔐

在本节课中，我们将要学习CCSP认证架构概念与设计领域中的一个核心部分：如何在云环境中保护敏感信息。我们将探讨纵深防御的概念、设备加固、加密技术的应用、数据生命周期保护以及密钥管理等关键主题。

纵深防御与安全控制

上一节我们介绍了保护敏感信息的总体框架，本节中我们来看看实现这一目标的基础策略：纵深防御。

纵深防御并非新概念，但它同样适用于云环境。其核心实践是采用多种方法，通过重叠的安全手段来保护环境。这些手段应包括管理性、逻辑性、技术性和物理性控制的混合。

  • 从云服务提供商（CSP）的角度看，分层防御应包括：

    • 人员控制：严格的背景调查和持续监控。
    • 技术控制：如加密、事件日志记录和访问控制执行。
    • 物理控制：涉及整个园区、各个设施、数据中心内处理数据的区域、单个机架、特定设备以及进出园区的便携式介质。
    • 治理机制与执行：如强有力的政策和定期彻底的审计。

  • 从云客户（CSC）的角度看，类似的努力应包括：

    • 为员工和用户提供包含全面安全主题的培训计划。
    • 通过合同强制执行政策要求。
    • 在自带设备（BYOD）资产上使用加密和逻辑隔离机制。
    • 强有力的访问控制方法，可能包括多因素认证（MFA）。

设备加固：物理与虚拟

理解了基础策略后，我们需要将其落实到具体对象上。无论是传统环境还是云环境，设备加固都是关键实践。

在传统环境中，位于DMZ（内部网络与外部世界连接的区域）的设备会作为惯例进行加固。我们知道这些设备更可能遭受入侵尝试，并相应地对它们进行强化。对于云环境，最好遵循相同的实践，无论是从云提供商的角度，还是从云用户的角度，都将所有云相关设备视为位于DMZ中。这有助于我们形成良好的习惯和看待云的概念方式。

以下是设备加固的具体任务列表：

  • 云服务提供商应确保数据中心内的所有设备都得到加固，具体包括：

    • 移除所有来宾账户。
    • 关闭所有未使用的端口。
    • 不存在默认密码。
    • 实施强密码策略。
    • 对任何管理员账户进行严格保护和日志记录。
    • 禁用所有不必要的服务。
    • 严格限制和控制物理访问。
    • 根据供应商指南和行业最佳实践对系统进行打补丁、维护和更新。

  • 云客户则有相似但不同的任务列表。客户必须注意其访问云方式带来的风险，这通常涉及自带设备（BYOD）环境和远程访问。例如，云客户应确保：

    • 其BYOD基础设施中所有访问云的资产都受到某种形式的反恶意软件或安全软件的保护。
    • 在设备丢失或被盗时，具备远程擦除或远程锁定能力（用户需通过签署授权使用政策授予组织此权限）。
    • 使用某种形式的本地加密。
    • 通过强访问控制或多因素配置中的生物识别技术进行保护。
    • 拥有并正确使用虚拟专用网络（VPN）解决方案进行云访问。
    • 安装某种形式的数据丢失/泄露防护（DLP）解决方案，通常以移动设备管理（MDM）系统的形式存在。这允许组织对个人拥有的设备进行容器化，以将其个人数据与组织信息隔离。

不仅物理设备需要加固，虚拟设备也应以同样方式对待。由于云计算严重依赖虚拟化来实现负载平衡和可扩展性，因此必须记住，虚拟实例需要强有力的保护，无论是在活动时（防止处理中的数据被其他实例或用户检测到），还是在存储为文件时（因为它们包含攻击者想要获取的大量材料且配置上非常便携）。它们也必须以我们保护物理机器的所有相同方式进行加固。

加密技术：保护数据的机密性

设备是数据的载体，而数据本身需要更核心的保护。加密是保障企业机密性服务的通用且关键的技术。

了解可能需要部署或与之协作的相关数据安全技术非常重要，以确保云中数据的机密性、完整性和可用性（也称为CIA三要素）。潜在的控制和解决方案包括：

  • 加密：用于防止未经授权的数据查看。
  • 数据丢失防护（DLP）：用于审计和防止未经授权的数据外泄。
  • 文件和数据库访问监控：用于检测对存储在文件和数据库中的数据的未经授权访问。
  • 混淆、匿名化、令牌化和掩码：这些是不使用加密保护数据的不同替代方案。它是用随机字符或数据隐藏原始数据的过程。

加密支持CIA三要素中的机密性支柱。其原理是防止未经授权的数据查看。没有加密，以任何安全方式使用云都将是不可能的。远程用户使用加密来创建安全通信连接；云客户在企业内部使用加密来保护自己的数据；在数据中心内，云提供商使用加密来确保不同的云客户不会意外访问彼此的数据。

就本次具体讨论而言，足以说明应在数据中心中利用加密来：

  • 保护长期存储或归档的数据。
  • 保护短期存储的文件，如虚拟化实例的快照。
  • 防止授权人员对特定数据集的未经授权访问（例如，保护数据库中的字段，以便数据库管理员可以管理软件但不能修改或查看内容）。
  • 在云提供商和用户之间的通信中，用于创建安全会话或确保传输中数据的完整性和机密性。

最终，我们希望能够在数据加密的状态下在云中处理数据，而无需解密，这样数据即使暂时也不会暴露给授权用户以外的任何人。尽管此功能目前尚不可用，但正在进行的研究显示出希望。这项技术被称为同态加密，值得了解这个术语并理解其可能性，即使它仍处于实验阶段。

在整个企业架构中启用所有数据的加密可以降低与未经授权的数据访问和暴露相关的风险，但存在需要解决的性能限制和问题。开发人员需要考虑其应用程序将运行的环境以及它们可能具有的加密或掩码依赖关系。作为认证云安全从业者，有责任以提供最大安全效益的方式在企业内实施加密，在保护最关键任务数据的同时，最小化因加密导致的系统性能问题。

加密可以在数据生命周期的不同阶段实施，并涉及密钥的使用。没有正确的密钥，数据将不可读且不可用。对于考试，你需要记住的是：我们使用加密来保护静态数据、使用中数据和传输中数据。

以下是这三种状态的详细分解：

  • 静态数据：加密静态数据是防止任何人在数据归档或存储时看到他们无权查看的数据的好方法。可以根据要求使用不同的加密技术。例如，我们是实施长期保留还是短期存储？数据位于数据库中还是文件系统中？加密机制本身及其部署方式可能会有所不同。当我们在云中部署数据丢失防护（DLP）系统时，静态数据有时被称为基于存储的。你需要记住，在这种拓扑结构中，DLP引擎安装在数据静止的地方，通常是一个或多个存储子系统以及文件和应用程序服务器。
  • 使用中数据：此阶段的数据正在被共享、处理或查看。数据生命周期的这个阶段比其他数据加密技术更不成熟，通常侧重于数据丢失防护（DLP）系统等技术。DLP（也称为数据泄露防护）可用于检测未经授权的共享，而信息权限管理（IRM）或数字版权管理（DRM）解决方案可用于保持对信息的控制。可能还需要遵守HIPAA或PCI DSS等法规，这些法规反过来要求对穿越不受信任网络的数据以及特定数据类型进行相关保护。当我们在云中部署DLP时，使用中数据有时被称为基于客户端或端点的。DLP应用程序安装在用户的工作站和终端设备上。
  • 传输中数据：也称为动态数据。为了避免在传输过程中信息暴露或数据泄露，我们使用诸如IPsec、虚拟专用网络（VPN）、TLS/SSL和其他有线/无线协议等加密技术。传输中数据的一个例子是数据进出云进行处理、归档和共享时。当我们在云中部署数据丢失防护（DLP）时，动态数据有时被称为基于网络或网关的DLP。在这种拓扑结构中，监控引擎部署在组织网关附近，以监控HTTP、HTTPS、SMTP和FTP等传出协议。

数据库加密的三种方式

数据根据其状态需要不同的保护，而当数据存储在数据库中时，又有几种特定的加密方法。对于考试，你需要理解数据库加密的三种基本选项：

以下是这三种选项的详细分解：

  • 文件级加密：数据库服务器通常驻留在卷存储上。对于这种部署，你加密的是数据库所在的卷或文件夹。加密引擎和密钥驻留在附加到卷的实例上。例如，信息权限管理系统（IRM）或数字版权管理（DRM）解决方案，其中加密引擎通常在客户端实现，并将保留原始文件的格式。
  • 透明加密：许多数据库管理系统包含加密整个数据库或特定部分（如表）的能力。使用透明加密，加密引擎驻留在数据库内部，并且对应用程序是透明的。密钥通常驻留在实例内，但处理和管理它们可以卸载到外部密钥管理系统（KMS）。这种加密可以有效防止介质盗窃、备份系统入侵以及某些数据库和应用程序级别的攻击。
  • 应用程序级加密：加密引擎驻留在使用数据库或对象存储的应用程序中。它可以集成到应用程序组件中，或者由一个代理负责，该代理在数据进入云之前对其进行加密。代理可以在客户网关上实现，也可以作为驻留在外部提供商处的服务。由于数据在到达数据库之前已被加密，因此执行索引、搜索和元数据收集具有挑战性。

当加密由云提供商提供或支持时，需要对加密类型、强度、算法、密钥管理以及其他相关方的任何责任有清晰的了解，并记录在服务级别协议（SLA）或合同中。

云存储加密：卷与对象

数据库是存储数据的一种形式，而云中更基础的存储形式是卷存储和对象存储，它们也需要相应的加密策略。

根据数据的位置（静态、传输中或使用中），使用不同的技术。在处理特定威胁时，例如保护个人可识别信息（PII）或法律监管信息，或防御系统和平台管理员的未经授权访问和查看时，可能会应用不同的选项。

  • 基本级存储加密：加密引擎位于存储管理层，密钥通常由云提供商持有、存储或保留。引擎将加密写入存储的数据，并在数据退出存储（例如，将被使用时）解密。这种类型的加密与对象和卷存储都相关，但它只能防止硬件盗窃或丢失，无法防止云提供商管理员访问或来自存储层之上的任何其他未经授权的访问。
  • 卷存储加密：要求加密的数据驻留在卷存储上。这通常通过一个加密容器来完成，该容器被映射为文件夹或卷。基于实例的加密只允许通过卷操作系统访问数据，并提供防止物理丢失或盗窃、外部管理员访问存储、从系统获取和移除存储快照以及存储级备份的保护。卷存储加密不能防止通过实例进行的任何访问，例如在实例上运行的应用程序内进行操作的攻击。
    • 有两种方法可用于实现卷存储加密：基于实例的加密和基于代理的加密。
      • 当使用基于实例的加密时，加密引擎位于实例本身上。密钥可以在本地生成，但应在实例外部进行管理。
      • 当使用基于代理的加密时，加密引擎在代理实例或设备上运行。代理实例是一台安全机器，将处理所有加密操作，包括密钥管理和存储。代理将映射卷存储上的数据并提供对实例的访问。密钥可以存储在代理上或通过外部密钥存储（推荐方法），代理负责密钥交换和内存中所需的密钥保护。
  • 对象存储加密：大多数对象存储服务提供服务器端存储级加密（如上所述）。这种加密效果有限，因此建议使用外部加密机制在数据推送到云存储环境之前对其进行加密。

密钥管理：加密的核心挑战

实施加密后，管理加密密钥本身成为了安全链条中最关键也最具挑战性的一环。

密钥管理是任何加密实施中最具挑战性的组成部分之一。控制密钥的颁发、撤销、恢复和分发非常复杂。尽管像密钥管理互操作性协议（KMIP）这样的新标准正在出现，但保护密钥和适当的密钥管理仍然是你规划云数据安全时需要参与的最复杂任务。

此外，强大的密钥管理服务和安全的密钥管理生命周期对于集成到加密解决方案中也至关重要。

从安全角度来看密钥管理的重要性：

  1. 你需要消除对云提供商正确处理加密过程和控制的依赖或假设。
  2. 由于你拥有独特且独立的加密机制，可以在数据和传输级别应用额外的安全性和机密性层，因此你不会受到云环境中共享密钥或数据泄漏的束缚或限制。

我们需要理解的密钥管理考虑因素包括：加密密钥的存储方式和位置，以及它们如何影响数据的整体风险。规划密钥管理时，应考虑：

  • 在整个生命周期中随机数生成。
  • 加密密钥绝不应以明文形式传输，并应始终保留在可信环境中。
  • 当考虑密钥托管或密钥管理即服务时，应仔细规划，考虑所有相关法律、法规和管辖要求。
  • 无法访问加密密钥将导致无法访问数据。在讨论机密性威胁与可用性威胁时应考虑这一点。
  • 尽可能，密钥管理功能应与云提供商分开进行，以强制执行职责分离，并在尝试未经授权的数据访问时迫使串通发生。 换句话说，你不想将加密密钥存储在与提供加密服务的同一云提供商那里。

密钥管理存在一些常见挑战，例如密钥访问。最佳实践与监管要求相结合，可能会为密钥访问设定特定标准，同时限制或不允许云服务提供商员工或人员访问密钥。

密钥存储：密钥的安全存储对于保护数据至关重要。在传统的内部环境中，密钥存储在安全的硬件安全模块（HSM）中。这在云环境中可能并不总是可行。云中的密钥存储通常使用以下一种或多种方法实现：

  • 内部管理：在这种方法中，密钥存储在也充当加密引擎的虚拟机或应用程序组件上。这种类型的密钥管理通常用于存储级加密、内部数据库加密或备份应用程序加密。这种方法有助于减轻与介质丢失相关的风险。
  • 外部管理：在这种方法中，密钥与加密引擎和数据分开维护。它们可以在同一云平台上、组织内部或在不同的云上。实际的存储可以是一个单独的、专门为此任务加固的实例，或者是一个硬件安全模块（HSM）。实施外部密钥存储时，你需要查看密钥管理系统如何与加密引擎集成，以及密钥的整个生命周期（从生成到销毁）是如何管理的。
  • 由第三方管理：这是指由可信的第三方提供密钥托管服务。密钥管理提供商使用专门开发的安全基础设施和集成服务进行密钥管理。你必须评估任何你打算签约的第三方存储服务提供商，以确保允许第三方持有加密密钥的风险得到理解和记录。

备份和复制：在云中，数据备份和复制以多种不同的格式进行。这可能会影响长期和短期密钥管理有效维护和管理的能力。

对于云计算密钥管理服务，最常用的是以下两种方法：

  • 远程密钥管理服务：客户在现场维护密钥管理服务（KMS）。理想情况下，客户将拥有、运营和维护KMS，从而使客户能够控制信息机密性，而云提供商则可以专注于服务的托管、处理和可用性。
  • 客户端密钥管理：与远程密钥管理类似。客户端方法旨在让客户或云用户完全控制加密和解密密钥。这里的主要区别在于，大部分处理和控制都在客户侧完成。云提供商可以提供密钥管理服务，但KMS驻留在客户场所，密钥由客户生成、持有和保留。这种方法通常用于软件即服务（SaaS）环境和云部署。

无论最终采用何种方法，首选的解决方案都是不要将加密密钥与云提供商存储在一起。

对于考试，你需要理解以下几个关于密钥管理的术语：

  • 保护级别：密钥必须受到与其保护的信息相同或更高级别的保护。
  • 密钥恢复：一种备份机制，确保在密钥丢失、损坏或持有者被解雇或死亡时，组织能够持续访问其自己的加密信息。
  • 密钥分发：这是我们与对称密钥交换遇到的相同问题。加密密钥不能与数据在同一信道或传输介质中发送。因此，使用带外分发。带外意味着使用不同的信道传输密钥，如信使、传真、电话或其他方法。
  • 密钥撤销：基本上是撤销或终止对密钥的访问。
  • 密钥托管：确保可信第三方保存私钥或解密信息所需密钥副本的过程。
  • 外包密钥管理：在云计算中，最好将密钥存储在云提供商数据中心以外的地方。一种选择是使用云访问安全代理（CASB）。CASB是第三方提供商，为云客户处理信息访问管理和密钥管理服务。

通常，云服务提供商使用基于软件的解决方案来保护密钥，以避免基于硬件的安全模型带来的额外成本和开销。问题是，这些基于软件的密钥管理解决方案通常不符合美国国家标准与技术研究院（NIST）的联邦信息处理标准（FIPS）140-2中规定的物理安全要求。因此，缺乏FIPS加密认证可能对美国联邦政府机构和其他组织构成问题，尤其是在审计期间。

数据脱敏与匿名化

由于性能、成本和技术能力等多种原因，使用加密并不总是一个现实的选择。因此，需要采用额外的机制来确保可以实现数据机密性。掩码、混淆、匿名化和令牌化可以用于此目的。

  • 数据掩码或数据混淆：是从特定数据集中隐藏、替换或省略敏感信息的过程。数据掩码通常用于保护特定数据集，如个人可识别信息（PII）或商业敏感数据，或为了遵守某些监管要求（如HIPAA或PCI DSS）。它也可用于测试平台无法获得测试数据的情况。

对于考试，你需要熟悉屏幕上列出的这些常见的数据掩码方法：
* 随机替换：值被替换或附加一个随机值。
* 算法替换：值被替换或附加一个算法生成的值。这通常允许双向替换。
* 混洗：混洗数据集中的不同值，通常来自同一列。
* 掩码：使用特定字符隐藏数据的某些部分。通常适用于信用卡数据格式，其中前几位数字被全部替换为X，只显示最后四位或六位数字。
* 删除：简单地使用空值或删除数据。

数据掩码的主要方法是静态和动态：

  • 静态掩码：创建带有掩码值的数据新副本。

  • 动态掩码：有时称为即时掩码。它在应用程序和数据库之间添加了一个掩码层。掩码层负责在表示层访问数据库时即时掩码其中的信息。例如，这种类型的掩码可以向客户服务代表隐藏完整的信用卡号，但数据仍可用于处理。

  • 数据匿名化：是移除间接标识符的过程，以防止数据分析工具或其他智能机制从多个来源收集或提取数据以识别个人或敏感信息。匿名化过程类似于掩码，包括识别要匿名的相关信息并选择相关的数据混淆方法。识别个人、用户或个人信息有两个主要组成部分：直接标识符和间接标识符。

    • 直接标识符：是唯一标识主体的字段，通常称为个人识别信息（PII）。掩码解决方案通常用于保护直接标识符。
    • 间接标识符：通常包括人口统计或社会经济信息、日期或事件。间接标识符本身无法识别个人。风险在于数据聚合，当我们开始将许多间接标识符与外部数据结合起来时，可能会导致信息主体的暴露。间接标识符的挑战在于，这类数据能够被集成到自由文本字段中，这些字段往往比直接标识符更缺乏结构性，从而使过程复杂化。

  • 令牌化：是用一个非敏感的等价物（称为令牌）替换敏感数据元素的过程，该令牌通过令牌化系统映射回敏感数据，该系统没有内在或可利用的意义或价值。令牌通常是一组随机值，具有原始数据的形状和形式，并通过令牌化应用程序或解决方案映射回原始数据。令牌化不是加密。令牌化将数据完全从数据库中移除，用识别和访问资源的机制替换它。它用于在安全、受保护或受监管的环境中保护敏感数据。

令牌化可以在内部实现（需要集中保护敏感数据），也可以使用令牌化服务在外部实现。令牌化有助于遵守法规或法律，降低合规成本，减轻存储敏感数据的风险，或减少对该数据的攻击向量。

总结 📝

本节课中我们一起学习了在云环境中保护敏感信息的全面策略。

我们讨论了纵深防御的概念以及管理性、逻辑性、技术性和物理性控制的实施。探讨了设备加固的重要性，包括物理和虚拟设备。深入研究了加密技术，以及它如何保护静态数据（使用DLP时称为基于存储的，DLP引擎安装在数据静止处）、使用中数据（使用DLP时称为基于客户端或端点的，DLP应用程序安装在用户工作站和终端设备上）和传输中数据（也称为动态数据，使用DLP时称为基于网络或网关的DLP，监控引擎部署在组织网关附近监控传出协议）。

我们还分析了数据库加密的三种选项：文件级加密（驻留在卷存储上）、透明加密（加密引擎驻留在数据库内）和应用程序级加密（加密引擎驻留在使用数据库的应用程序中）。详细阐述了密钥管理和存储：内部管理、外部管理和第三方管理。强调了密钥管理功能应尽可能与云提供商分开进行，且切勿将加密密钥与同一云服务提供商存储在一起。解释了考试需要理解的术语：保护级别、密钥恢复、密钥分发、密钥撤销、密钥托管和外包密钥管理。

最后，我们介绍了当加密不可行时的替代方案：数据掩码或数据混淆及其常见方法（随机替换、算法替换、混洗、掩码和删除）和主要方法（静态和动态），以及数据匿名化和令牌化。

015：威胁建模 🛡️

在本节课中，我们将要学习CCSP认证中“架构概念与设计”领域的一个重要部分：威胁建模。我们将了解威胁建模的目的、核心模型（如STRIDE和DREAD）、云存储面临的特定威胁、云安全联盟（CSA）提出的九大风险，以及如何通过数据防泄漏（DLP）等技术来应对这些威胁。

威胁建模概述

威胁建模在应用设计完成后进行。其目标是确定应用中的任何弱点，以及在引入生产环境之前，潜在的入侵、出站路径和涉及的参与者。必须记住，云环境中的整体攻击面会被放大。因此，需要从攻击者（黑帽）的角度思考黑客可能攻击系统或连接的各种方式。

STRIDE威胁模型

STRIDE模型通常用于关注应用和操作系统威胁，但也可用于识别对网络和主机的威胁。您必须能够为考试回忆这个缩写词及其描述术语。

以下是STRIDE模型的组成部分：

  • 身份欺骗：攻击者冒充授权用户。
  • 数据篡改：攻击者试图以未经授权的方式修改目标数据。
  • 抵赖：攻击者或交易参与者可以否认或隐瞒其在该交易中的参与。这与不可抵赖性相反，后者指无法否认您确实参与了交易。
  • 信息泄露：此类别包括授权用户意外向未授权用户披露受保护数据的无意泄露，以及攻击者未经授权访问数据的恶意访问。
  • 拒绝服务：这是对保密性、完整性、可用性（CIA）三元组中可用性方面的攻击，导致授权用户无法访问系统、应用或数据。
  • 权限提升：当攻击者不仅获得对目标的访问权限，还能获得足以完全禁用或摧毁整个目标系统的控制级别时发生。

威胁优先级划分方法

识别或记录威胁后，需要分配威胁优先级，换句话说，对威胁进行排序或评级以便缓解。DREAD是考试中需要回忆的三种方法之一。

DREAD由以下术语组成：

  • 损害潜力：如果威胁实现，损害有多严重？
  • 可复现性：攻击者复制或利用该威胁有多复杂？
  • 可利用性：执行攻击有多困难？
  • 受影响用户：如果此漏洞或威胁实际发生，有多少用户（数量或百分比）会受到影响？
  • 可发现性：攻击者发现此弱点有多困难？

另外两种威胁优先级划分方法是：

  1. 概率乘以损害潜力排名：使用1到100的等级（100为最严重）。为概率和损害潜力各分配一个1到10的值（1低，10高），相乘，然后将结果按比例缩放到1到100。这是一种非常主观的方法。
  2. 高/中/低评级：这种方法更简单，为关键性分配高（立即处理）、中（最终处理）、低（可视为可选）的评级。

云存储面临的威胁类型

数据存储面临屏幕上列出的威胁类型，您应该为考试理解它们是什么。

  • 未经授权的使用：基本上指通过账户劫持或上传非法内容，未经许可使用数据存储。云存储的多租户特性使得追踪未经授权的使用更具挑战性。
  • 未经授权的访问：由于黑客攻击、多租户环境中权限设置不当或云提供商内部员工责任，可能导致未经授权的访问。
  • 拒绝服务：针对存储系统的DoS攻击（如针对性攻击）或DDoS攻击（如使用各种系统协调攻击目标系统），攻击CIA三元组中的可用性方面。可用性是云存储的一个强烈关注点，因为没有数据，任何实例都无法启动。
  • 数据损坏、修改和销毁：这可由多种原因引起，包括人为错误、硬件或软件故障、火灾或洪水等事件，或故意黑客攻击。它可能影响存储的特定部分或整个阵列。
  • 数据泄露：消费者应始终意识到云数据容易受到数据泄露的影响。泄露可能来自外部，也可能来自具有存储访问权限的云提供商员工。数据在云中倾向于被复制和移动，这增加了泄露的可能性。
  • 媒体被盗或意外丢失：此威胁适用于便携式存储，但随着云数据中心的增长和存储设备变得越来越小，它们遭遇盗窃或类似威胁的途径也越来越多。
  • 恶意软件感染或引入：几乎所有恶意软件的最终目标都是最终到达数据存储。
  • 使用后处理或清理不当：在云计算中，使用后处理具有挑战性，因为我们通常无法强制执行媒体的物理销毁。云中数据的动态特性（数据保存在不同存储中，且有多租户）带来了数字残留物可能被定位的风险，除非得到妥善处理（例如，通过加密粉碎，即加密数据存储然后销毁密钥，这使得在正常恢复情况下无法检索数据）。

云安全联盟（CSA）九大风险

屏幕上列出了云安全联盟（CSA）确定的九大风险。您应该为考试熟悉这些常见威胁并能够回忆它们。考试中可能会看到专门针对这九大CSA风险的题目，因此请记住它们的名称。

  • 数据泄露：泄露通常是由于数据库安全设计或配置不当，导致数据在没有适当授权的情况下暴露。如果多租户云服务数据中心设计不当，一个客户应用中的缺陷可能允许攻击者不仅访问该客户的数据，还能访问所有其他客户的数据。
  • 数据丢失：指与云环境中存储、处理或传输的信息相关的信息丢失、删除、覆盖、损坏或完整性丧失。云服务提供商的任何意外删除，或者更糟的物理灾难（如火灾或地震），都可能导致客户数据的永久丢失，除非提供商采取足够措施备份数据。此外，避免数据丢失的责任并不仅仅落在提供商身上。如果客户在上传到云之前加密了数据，但丢失了加密密钥，数据也将丢失。
  • 账户或服务流量劫持：成功后，这允许攻击者监视和窃听通信、跟踪流量、捕获相关凭据以及访问或更改账户和用户配置文件特征（例如更改密码）。如果攻击者获得您的凭据，他们可以窃听您的活动和交易、操纵数据、返回虚假信息并将您的客户重定向到非法站点，您的账户或服务实例可能成为攻击者的新基地。
  • 不安全的接口或API：云计算提供商公开一组软件接口或API，供客户用于管理和与云服务交互（配置、管理、编排和监控都是使用这些接口执行的）。通用云服务的安全性和可用性取决于这些基本API的安全性。从身份验证和访问控制到加密和活动监控，这些接口必须设计成能够防止意外和恶意的策略规避企图。API的附加组件显著增加了复杂性，导致可能被不安全地使用的多层API。
  • 拒绝服务：通过迫使受害者的云服务消耗过多的有限系统资源（如处理能力、内存、磁盘空间或网络带宽），攻击者导致系统速度慢到无法忍受。这些攻击基本上阻止用户从指定系统或位置访问服务和资源。
  • 恶意内部人员：根据美国国家标准与技术研究院（NIST）的定义，这是当前或前雇员、承包商或其他业务合作伙伴，他们拥有或曾经拥有对组织网络、系统或数据的授权访问权限，并故意超越或滥用该访问权限，以对组织信息或信息系统的保密性、完整性或可用性产生负面影响的方式行事。
  • 云服务滥用：我们已经知道，云并不总是以向用户提供的方式被使用。攻击者能够使用目录攻击、执行拒绝服务攻击、破解加密密码，或托管非法软件和材料以进行广泛分发。攻击者使用自己有限的硬件破解加密密钥可能需要数年时间，但使用一系列云服务器，他可能能够在几分钟内破解。或者，他可能使用那系列云服务器来发起分布式拒绝服务攻击。
  • 尽职调查不足：基本上指在推出云解决方案之前，没有调查和了解公司面临的风险。如果没有完全理解云服务提供商的环境、推送到云的应用程序或服务以及运营责任（如事件响应、加密和安全监控），组织正在承担未知水平的风险，其方式他们甚至可能无法理解，但与他们当前的风险相去甚远。这里有两个要素：应有注意和尽职调查。应有注意是制定和实施政策和程序，以帮助保护公司、其资产和人员免受威胁；尽职调查是我们如何证明我们的应有注意。
  • 共享技术漏洞：这是基于云服务提供商以可扩展的方式交付其服务的事实。他们在租户之间（并可能与其他提供商之间）共享基础设施、平台和应用程序。这可能包括基础设施的底层组件，从而导致共享的威胁和漏洞。建议采用深度防御策略，并应包括计算、存储、网络、应用程序和用户安全执行与监控，无论服务模型是基础设施即服务（IaaS）、平台即服务（PaaS）还是软件即服务（SaaS）。关键在于，单个漏洞或配置错误可能导致整个提供商云的泄露。

OWASP十大漏洞与威胁应对技术

开放Web应用安全项目（OWASP）开发了许多免费有用的产品，并提供了多个Web应用开发指南，包括开发指南、代码审查指南、测试指南、屏幕上列出的十大Web应用安全漏洞以及OWASP移动指南。攻击者经常利用这些类型的漏洞来完全控制软件、窃取数据或完全阻止软件工作。不要被愚弄，黑客使用这些信息来瞄准系统和漏洞，因为它概述了他们可以瞄准的常见漏洞，可以说是一张路线图。

您需要利用不同的技术来解决企业在云中数据的安全存储和使用方面，关于保密性、完整性和可用性所面临的各种威胁。

数据防泄漏（DLP）系统

了解数据分散如何在云中使用非常重要。数据分散类似于RAID（独立磁盘冗余阵列）解决方案，但实现方式不同。数据块被复制到云中的多个物理位置。RAID是一种数据存储虚拟化技术，它将多个物理驱动器组件组合成一个逻辑单元，以实现数据冗余、性能改进或两者兼得。在私有云中，您需要自己设置和配置数据分散。使用公共云则没有能力设置和配置数据分散，尽管您的数据可能受益于云提供商使用的数据分散。该技术的底层架构涉及使用擦除编码，它将数据对象（想象成一个带有自描述元数据的文件）分块成段。每个段被加密并切成片，然后分散到组织的网络中，驻留在不同的硬件驱动器和服务器上。如果组织失去对一个驱动器的访问，原始数据仍然可以重新组合。

如果数据通常是静态的，很少重写（如元数据文件和归档日志），则创建和分发数据是一次性成本。如果数据非常动态，则必须重新创建擦除码，并将生成的数据块重新分发。

其他潜在的控制和解决方案包括：

  • 数据防泄漏（DLP）：也称为数据泄露防护，用于审计和防止未经授权的数据外泄。
  • 加密：用于防止未经授权的数据查看。
  • 混淆、匿名化、令牌化和掩码：保护数据的不同替代方案，无需加密（这不是加密，而是加密的替代方案）。

DLP组件与架构

数据防泄漏（DLP）描述了组织为确保某些类型的数据（结构化和非结构化）根据政策、标准和程序保持组织控制之下而实施的控制措施。换句话说，您想知道您的数据在哪里、它在做什么以及谁在对它做什么。它用于审计和防止未经授权的数据外泄。要做到这一点，您首先需要知道您拥有什么、它在哪里以及谁有权访问它。

DLP由三个组件组成，您需要为考试记住：

  1. 数据发现与分类：这是DLP实施的第一阶段，也是一个持续和重复的过程。发现过程通常映射云存储服务和数据库中的数据，并支持基于数据类别（受监管数据、信用卡数据、公共数据等）进行分类。
  2. 监控：数据使用监控构成DLP的关键功能，监控跨位置和平台的数据使用，同时使管理员能够定义一个或多个使用策略。监控数据的能力可以在网关、服务器、存储以及工作站和终端设备上执行。监控应用程序应能覆盖用户可用的大多数共享选项（如电子邮件应用程序、便携式媒体和互联网浏览），并提醒他们策略违规。
  3. 执行：许多DLP工具提供检查数据并根据一组策略比较其位置、使用或传输目的地的能力，以防止数据丢失。如果检测到策略违规，可以自动执行指定的相关执行操作。执行选项可以包括提醒和记录、阻止数据传输、将其重定向以进行额外验证或在数据离开组织边界之前对其进行加密的能力。

我们已经说过，加密用于防止未经授权的数据查看和保护静态数据（如文件存储、数据库信息、应用程序组件、归档和备份应用程序）。通常，大多数加密部署涉及三个组件：数据（需要加密的数据对象）、加密引擎（执行加密操作）和加密密钥（请记住，所有加密都基于密钥，保护密钥是确保加密实施及其算法持续完整性的关键活动）。

最后，混淆、匿名化、令牌化和掩码是保护数据的不同替代方案，无需加密。

DLP拓扑类型

我们之前已经介绍了数据防泄漏架构的部分内容，但这对您理解考试非常重要。

  • 传输中的数据：有时称为基于网络或网关的DLP。监控引擎部署在组织网关附近，以监控正在进行的协议（如HTTP、HTTPS、SMTP和FTP）。拓扑可以是基于代理、网桥、网络分路或SPAN中继的混合。为了扫描加密的HTTPS流量，需要将启用SSL拦截或代理的适当机制集成到系统架构中。
  • 静态数据：有时称为基于存储的DLP。DLP引擎安装在数据静态存储的位置，通常是一个或多个存储子系统以及文件和应用程序服务器。这种拓扑对于数据发现和跟踪使用情况非常有效，但可能需要与基于网络或终端的DLP集成以进行策略执行。
  • 使用中的数据：有时称为基于客户端或终端的DLP。DLP应用程序安装在用户的工作站和终端设备上。这种拓扑提供了对用户如何使用数据的洞察，并能够添加网络DLP可能无法提供的保护。基于客户端的DLP面临的挑战是在所有终端设备（通常跨多个位置和大量用户）上实施的复杂性、时间和资源。

基于云的数据防泄漏注意事项

对于基于云的数据防泄漏，您需要考虑以下几点：

  1. 云中的数据倾向于移动和复制，无论是在位置之间、数据中心之间、备份之间，还是在组织内外来回移动。这种复制和移动可能对任何数据防泄漏实施构成挑战。
  2. 对云中企业数据的管理访问可能很棘手。您需要确保了解如何在基于云的存储中执行发现和分类。
  3. DLP技术可能影响整体性能，因为扫描所有流量以查找预定义内容的网络或网关DLP可能会影响网络性能。基于客户端的DLP扫描工作站对所有数据的访问，这可能对工作站的运行产生性能影响。您需要在测试和部署期间查看整体影响，以发现可能的瓶颈所在。

总结

本节课中我们一起学习了威胁建模的核心内容。我们讨论了STRIDE模型（身份欺骗、数据篡改、抵赖、信息泄露、拒绝服务、权限提升）和DREAD模型（损害潜力、可复现性、可利用性、受影响用户、可发现性）。另外两种威胁优先级划分方法是概率乘以损害潜力排名和高/中/低评级系统。

我们还讨论了CSA九大风险，这也是考试需要掌握的，包括数据泄露、数据丢失、账户或服务流量劫持、不安全的接口和API、拒绝服务、恶意内部人员、云服务滥用、尽职调查不足和共享技术漏洞。

我们谈到了OWASP十大漏洞、应对威胁的技术，最后是数据防泄漏（DLP）系统。

016：数据分类与分级 📊

在本节课中，我们将学习云数据安全领域的一个核心概念：数据的分类与分级。这是CCSP认证考试的重要内容，有助于为信息系统建立标准化的防护基线。

概述

数据分类与分级用于帮助标准化信息系统的防御基线，并确定员工或系统访问信息所需的适当性和信任级别。通过整合具有相似类别和级别的数据，组织能够明确所需的安全控制规模，以应对业务影响分析和漏洞评估中发现的威胁与漏洞。

数据所有者与分类分级

数据所有者最了解数据在组织中的使用方式及其对组织的价值，因此能够对数据进行适当的分类和分级。

以下是组织对数据进行分级的一些常见方式：

  • 按敏感性分级：例如，军事领域采用的“绝密”、“秘密”、“机密”、“非密”。数据根据其敏感性被赋予一个级别，这基于未经授权披露可能造成的负面影响。在此模型中，所有数据都必须被分级，即使是不敏感的材料也必须标记为“非密”。
  • 按管辖范围分级：例如，遵守欧盟的《通用数据保护条例》（GDPR）或其他监管要求。数据的来源地或存储点的地理位置可能对数据的处理方式有重大影响。例如，从欧盟公民处收集的个人身份信息（PII）受欧盟隐私法管辖，这些法律比美国的隐私法更为严格和全面。
  • 按关键性分级：这是业务影响分析、漏洞评估或风险评估的结果。对于组织生存至关重要的数据，其分级方式必须与普通的日常运营数据区分开来。业务影响分析有助于我们确定哪些材料应以这种方式进行分类。

分类与分级的区别

对于数据的“分类”与“分级”，除了特定法规覆盖的领域（例如，军事领域的分级结构由联邦法律定义），没有行业定义的法定强制定义。这两个术语经常可以互换使用。为了在本学习路径中讨论方便，我们将尝试遵循以下理解：数据根据其用途被“分类”，根据其某些特征被“分级”。请记住，这并不是这些术语的行业标准用法。

再次强调，数据根据其用途被分类，根据其特定特征被分级。

数据分类作为信息生命周期管理的一部分

作为信息生命周期管理过程的一部分，数据分类可以被定义为一个对数据进行分类的工具，以帮助组织有效回答以下问题：

  • 有哪些数据类型可用？
  • 特定数据位于何处？
  • 哪些访问级别是重要的？
  • 实施了哪些访问级别？
  • 实施了何种保护级别？是否符合合规法规？

建议采用数据分类流程来实施数据控制，例如数据防丢失系统和加密。数据分类也是某些法规和标准的要求，例如ISO 27000和支付卡行业数据安全标准（PCI DSS）。

常见的分类类别

实施数据分类有多种原因，数据的分类也有许多不同的参数和类别。以下是一些常用的分类类别：

  • 数据类型、格式和结构
  • 管辖范围、来源或所属地及其他法律约束
  • 上下文、所有权
  • 合同或业务约束
  • 信任级别和来源
  • 对组织或第三方的价值、敏感性和关键性
  • 保留和预防义务

分类类别应与要使用的数据控制措施相匹配。例如，在使用加密时，数据可以分为“需要加密”和“无需加密”。对于数据防丢失系统，则需要“内部使用”和“限制共享”等其他类别来正确分类数据。

组织对数据进行分类的方式

正如之前所述，数据所有者最了解数据在组织中的使用方式，这使其能够恰当地对数据进行分类。组织可以拥有任意数量的信息类别或类型，这些类别可以在整个组织中明确定义和重复使用，也可能由数据所有者在创建阶段任意指定。

以下是组织可能对数据进行分类的一些方式：

  • 按法规遵从性分类：不同的业务活动受不同法规约束。组织可能希望根据适用于特定数据集的法规来创建类别。这可能包括《格雷姆-里奇-比利雷法案》（GLBA）、支付卡行业数据安全标准（PCI DSS）、《萨班斯-奥克斯利法案》（SOX）或《健康保险携带和责任法案》（HIPAA）合规性。
  • 按业务功能分类：组织可能希望为数据的不同用途设定特定类别。数据可能根据其在计费、营销或运营中的用途进行标记。
  • 按职能部门分类：每个部门或办公室可能都有自己的类别，并将其控制的所有数据保留在自己的类别中。
  • 按项目分类：一些组织可能根据数据关联的项目来定义数据集，以此创建独立的、分隔的项目。

组织对数据进行分类的方式几乎没有限制。无论组织采用何种模式，都应在整个组织内统一采用和执行。临时性的分类与没有分类一样无效。

数据标记

数据标记通常指为数据附加额外信息，如部门、位置或创建者。标记选项之一是根据特定标准（如绝密、秘密、机密）进行分级。因此，分级通常被认为是数据标记的一部分。

分级可以是手动的（通常由创建数据的用户执行），也可以是自动的（基于策略规则，根据位置、创建者或内容自动执行）。

当数据所有者创建、分类和分级数据时，也需要对其进行标记。标记应指明数据所有者是谁（通常以办公室或角色表示，而非个人姓名或身份，因为人员可能在组织内变更角色或离开组织）。标记应采用必要的形式，以确保其持久性、可理解性和一致性。例如，硬拷贝数据上的标记可能打印在页眉和页脚，而电子文件中的标记可能嵌入在文件名或命名规则中。

标记应显而易见，并传达相关概念，而不必披露它们所描述的数据。根据组织的需求和业务性质，标记可能包含屏幕上列出的以下类型的信息：

  • 创建日期
  • 计划销毁或处置日期
  • 机密级别
  • 处理指示
  • 传播或分发说明
  • 访问限制
  • 来源
  • 管辖范围
  • 可能适用的法规

云环境中的挑战

在云部署中，数据分类与分级面临一些挑战：

  • 数据创建：安全从业者需要确保有适当的安全控制措施，以便任何人在创建或修改数据时，都被强制要求作为创建或修改过程的一部分对数据进行分类或更新。
  • 分级控制：处理云中的数据时，应实施控制措施，这些措施可能是管理性的（如为创建数据的用户制定指南）、预防性的或补偿性的。对于云客户来说，这些措施的实施可能具有挑战性。
  • 元数据分级：有时可以根据附加到文件的元数据（如所有者或位置）进行分级。为了使分级过程能够做出正确的决策，这些元数据应该可以被访问，这在云实现中有时具有挑战性。
  • 数据转换控制：应实施控制措施，以确保相关属性或元数据能够在数据对象格式更改以及云导入和导出过程中得以保留。
  • 重新分级考虑：云应用程序必须支持基于数据生命周期的重新分级过程。有时，数据对象的新分级可能意味着启用新的控制措施，如加密或保留与处置。例如，客户记录从市场部门转移到贷款部门。

总结

本节课中，我们一起学习了组织对信息进行分类和分级的多种方式，探讨了在云部署中实施分类与分级时面临的挑战。我们还讨论了信息生命周期管理、常用的分类类别，以及组织可能基于法规要求、业务功能或项目对数据进行分类的方式。最后，我们了解了数据分级与标记之间的关系。掌握这些概念对于构建有效的云数据安全策略至关重要。

017：数据生命周期管理 🔄

在本节课中，我们将学习数据安全生命周期管理。这是CCSP认证云安全领域的关键部分。数据是组织最有价值的资产，其安全控制措施应根据其价值来实施。我们将探讨数据生命周期的各个阶段、关键要素以及如何应用控制措施来保护数据。

数据生命周期概述 📊

上一节我们介绍了数据安全的重要性，本节中我们来看看数据生命周期的具体过程。数据生命周期框架由SANS研究所提出，并被云安全联盟采纳，它帮助组织将数据生命周期的不同阶段与相应的安全控制措施对应起来。

数据生命周期管理包含三个主要步骤：

  1. 映射不同的生命周期阶段。
  2. 整合不同的数据位置和访问类型。
  3. 将数据映射到功能、参与者和控制措施上。

该框架为数据访问的相关用例提供了映射，并协助在每个生命周期阶段（创建、存储、使用、共享、归档和销毁）制定适当的控制措施。

数据生命周期的六个阶段 🔄

以下是数据生命周期的六个核心阶段：

1. 创建
这是指生成或获取新的数字内容，或对现有内容进行修改和更新。此阶段可以在内部、云端或外部发生。在创建阶段对内容进行敏感性和价值分类是最佳时机。如果分类不正确，可能会导致实施不当的安全控制。

2. 存储
这是将数字数据提交到某种存储库的行为。存储通常与创建几乎同时发生。存储数据时，应根据其分类级别进行保护。应实施加密、访问策略、监控、日志记录和备份等控制措施，以避免数据威胁。如果访问控制列表实施不当、文件未进行威胁扫描或分类错误，内容就容易受到攻击。

3. 使用
这是指数据正在被查看、处理或以某种活动方式使用（不包括修改）。使用中的数据最脆弱，因为它可能被传输到不安全的位置（如工作站），并且为了处理，它必须被解密。应实施数据防泄漏、信息权限管理和数据文件访问监控等控制措施，以审计数据访问并防止未经授权的访问。

4. 共享
这是指信息被提供给其他人访问，例如在用户之间、向客户或合作伙伴共享。并非所有数据都应共享，也并非所有共享都会构成威胁。但由于共享的数据不再受组织直接控制，维护安全可能变得困难。可以使用数据防泄漏技术来检测未经授权的共享，并使用信息权限管理技术来保持对信息的控制。

5. 归档
这是指数据离开活跃使用状态，进入长期存储。长时间归档数据可能具有挑战性，成本与可用性之间的权衡会影响数据访问流程。归档的数据仍必须根据其分类进行保护，还必须满足监管要求，并且此阶段可能涉及不同的工具和提供商。

6. 销毁
这是指数据被从服务中移除。销毁阶段可以根据用途、数据内容和应用程序使用情况，解释为不同的技术含义。数据销毁可以指逻辑上擦除指针，或使用物理或数字手段永久销毁数据。应根据法规、所使用的云类型（如IaaS与SaaS）以及数据的分类来考虑销毁方法。

重要提示：生命周期被描述为一个线性过程，但数据可能会跳过某些阶段或在不同阶段之间来回切换。它不必遵循严格的1、2、3顺序。生命周期模型是一个参考框架，用于提供标准化的方法，并非所有实施或情况都会完全符合。

数据生命周期的三个关键要素 🔑

为了确定在此生命周期方法中需要部署哪些控制措施来保护数据，您需要关注三个关键要素：功能、位置和参与者。

  • 数据的功能：可以对数据执行什么操作，例如访问、处理或存储。
  • 数据的位置：数据存放在哪里。数据是可移植的，根据访问方式，它可能最终出现在不同类型的设备上。
  • 数据的参与者：谁可以实际访问数据。

每个功能（访问、处理、存储）都由参与者（人）在某个位置执行。我们需要分解这些领域。

首先，关键数据功能
以下是三个核心数据功能：

  • 访问：查看或访问数据，包括复制、文件传输和其他信息交换。需要问：谁可以访问相关数据？他们如何访问（通过什么设备或渠道）？
  • 处理：对数据执行事务，例如更新数据或在业务流程事务中使用数据。
  • 存储：将数据存储在文件或数据库中。需要问：数据位于何处？因为数据是可移植的资源，它能够在企业内部和外部不同位置之间快速轻松地移动。

其次，数据的位置
生命周期不是单一的线性操作，而是一系列较小的生命周期，始终在不同环境中运行。了解数据的逻辑和物理位置对于满足审计、合规性和其他控制要求非常重要。数据可以在内部网络生成，移动到云端进行处理，然后转移到不同的提供商进行备份甚至归档。

需要考虑的问题包括：谁可能访问我需要保护的数据？我需要保护的数据可能位于何处？每个位置有哪些控制措施？在每个生命周期的哪个阶段，数据可以在位置之间移动？数据如何通过什么渠道或系统在位置之间移动？这些参与者来自哪里？这些位置是可信的还是不可信的？

最后，数据的访问
传统的数据生命周期模型并未明确规定谁可以访问相关数据，以及他们如何访问。例如，移动计算作为一种数据访问方式，以及存储、处理和传输数据的大量机制和渠道，都放大了这一要求缺失的影响。

数据分散技术 🧩

在考虑位置时，我们还需要关注数据分散技术。这是一种常用于提高数据安全性但不使用加密机制的技术，取而代之的是位拆分和擦除编码。

  • 位拆分：类似于为RAID阵列添加加密。数据首先被加密，然后被分割成多个部分，这些部分随后被分布到多个存储区域。然而，位拆分有一些缺点：处理过程消耗大量CPU资源；存在可用性问题（需要所有数据部分都可用才能解密和使用信息）；存储要求和成本高于其他存储系统。

位拆分可以使用不同的加密方法，其中很大一部分基于两种秘密共享加密算法：

  1. 秘密共享缩短：使用一个三阶段过程：信息加密、使用信息分散算法、使用秘密共享算法分割加密密钥。数据和加密密钥的不同片段随后被签名并分发到不同的云存储服务。这使得在没有任意选择的数据和加密密钥片段的情况下无法解密。
    公式/代码表示：SSMS = Encrypt(Data) + IDA_Split(Encrypt(Data)) + SecretShare_Split(Key)

  2. 带里德-所罗门码的全或无变换：集成了全或无变换和擦除编码。此方法首先以无法在不使用所有块的情况下恢复信息的方式，将信息和加密密钥加密并转换为块，然后使用信息分散算法将块分割成“份额”，分发到不同的云存储服务。与秘密共享缩短类似，全或无变换是一种加密模式，只有在知道所有数据时才能理解数据。
    公式/代码表示：AONT-RS = AONT_Transform(Encrypt(Data)) + IDA_Split(Transformed_Blocks)

  • 擦除编码：适用于延迟容忍的大容量存储，通常在具有超大容量的对象存储上下文中发现。云运营商常用此技术。它类似于在RAID条带化中使用奇偶校验位。奇偶校验数据帮助您在丢失一个条带化驱动器时恢复丢失的数据；而擦除编码帮助您在云数据不可用或丢失时恢复丢失的数据。

擦除编码是一种数据保护方法，其中数据被分解成片段，扩展并用可配置数量的冗余数据片段进行编码，并存储在不同的位置（如磁盘、存储节点或地理位置）。这允许存储阵列中两个或更多元素发生故障，提供比RAID系统更多的保护。当使用加密时，这通常被称为分片。如果数据是静态的，创建和分发数据是一次性成本；如果数据是动态的，则必须重新创建擦除码并重新分发结果数据块。

数据分散类似于RAID技术，将数据分布在不同的存储区域，甚至可能分布在跨越地理边界的不同云提供商。然而，这带来了固有风险：如果数据分布在多个云提供商，一个提供商的故障可能导致用户无法访问数据，无论其位置如何，这对可用性构成威胁。

控制措施的映射与应用 🗺️

一旦记录并理解了访问、处理和存储这三个项目，就可以指定适当的控制措施并将其应用于系统，以保护数据并控制对数据的访问。这些控制措施可以是预防性、检测性（如监控）或纠正性的。

在完成映射各种数据阶段、数据位置和设备访问后，有必要确定可以对数据做什么（即数据功能）以及谁可以访问数据（即参与者）。一旦确定并理解了这一点，您就可以检查控制措施，以验证哪些参与者有权执行数据的相关功能。

控制措施充当将一系列可能操作限制为允许或禁止操作的机制。例如：

  • 加密：可用于限制未经授权的查看或使用数据。
  • 应用程序控制：通过授权和数字版权管理来限制处理。
  • 存储控制：防止不受信任或未经授权的方复制或访问数据。

此时，我们能够生成一个高级别的数据流映射，包括每个位置的设备访问和数据位置。对于每个位置，我们可以确定相关的功能和参与者。一旦完成映射，我们就能更好地定义要限制哪个参与者执行什么操作，以及通过哪种控制措施来限制。

您只需填写功能、参与者和位置区域，用“是”或“否”表示该项目是否可能执行。例如，在图表中：

  • 功能列下的“是，是”标识了可用且应允许的项目。
  • 参与者列下的“可能”为“是”，“允许”为“否”，标识了可能在未来某个时间点与组织协商决定允许的项目。
  • 位置列下的“否，否”标识了当前组织内不可用的项目，可能需要与组织协商部署和使用计划。

数据保护策略 📜

数据保护策略应包括云中不同数据生命周期阶段的指南。以下三个策略应得到适当的调整和关注：

1. 数据保留策略
这是组织为保持信息可操作或符合监管要求而制定的协议。其目标是：保留重要信息以备将来使用或参考；组织信息以便日后搜索和访问；处置不再需要的信息。该策略在法律法规和业务数据归档要求与数据存储成本、复杂性及其他数据考虑因素之间取得平衡。

一个良好的数据保留策略应为企业定义数据保留期限、数据格式、数据安全和数据检索程序。云服务的数据保留策略应包含以下组成部分：

  • 法规与标准要求：数据保留考虑因素高度依赖于数据类型及其相关的合规制度。
  • 数据映射：映射所有相关数据以了解数据类型（如结构化和非结构化）、数据格式、文件类型和数据位置（如网络驱动器、数据库、对象或卷存储）。
  • 数据分类：基于位置、合规要求、所有权或业务用途（即其价值）对数据进行分类，以决定适当的企业数据保留期限。
  • 数据保留程序：对于每个数据类别，应遵循管理该数据类型的适当数据保留策略。保留多长时间、保存在哪里（如物理位置和司法管辖区）、使用何种技术和格式，都应在策略中明确规定并通过程序实施。程序还应包括备份选项、检索要求以及恢复程序。
  • 监控与维护程序：确保整个过程正常运行，包括审查策略和要求，确保没有未经变更管理流程的更改。

2. 数据归档策略
数据归档基本上是识别非活动数据并将其移出当前生产系统（从而优化所需资源的性能），并转移到专门的长期归档存储系统。专门的归档系统更经济高效地存储信息，并在需要时提供检索。您的数据归档策略应包含以下所有要素：

  • 数据加密程序：使用加密进行长期数据归档对组织来说在密钥管理方面可能具有挑战性，因为糟糕的密钥管理可能导致整个归档被破坏。加密策略应指明使用何种介质、恢复选项以及需要加密缓解的威胁。
  • 数据监控程序：存储在云中的数据往往会为了维护数据治理而被复制和移动。您需要能够跟踪和记录所有数据访问和移动，并确保在整个数据生命周期中正确应用所有安全控制。
  • 执行电子发现和精细检索的能力：归档数据可能需要根据某些参数（如日期、主题、作者等）进行检索。归档平台应提供对数据进行电子发现的能力，以决定应检索哪些数据。
  • 备份和灾难恢复选项：应明确规定并清晰记录数据备份和恢复的所有要求。确保业务连续性和灾难恢复计划得到更新并与实施的任何程序保持一致非常重要。
  • 数据格式或介质类型：数据格式很重要，因为它可能被保存很长时间。专有格式可能会变化，使数据处于无用状态，这被称为介质或数据过时。有效的数字文件维护取决于对硬件、软件、文件格式和存储介质的适当管理。
  • 数据恢复程序：应定期启动数据恢复测试，以确保流程正常工作且归档文件完整。恢复测试应在隔离环境中进行，以降低风险（如恢复旧病毒或意外覆盖现有数据）。

3. 数据删除策略
数据保护程序的一个关键部分是安全处置不再需要的数据。未能这样做可能导致数据泄露和/或合规性失败。安全处置程序旨在确保系统中没有留下可用于恢复原始数据的文件、指针或数据残余。

需要数据删除策略的原因包括：

  • 法规或立法：某些法律和法规要求对特定记录进行特定程度的安全处置。
  • 业务和技术要求：业务政策可能要求安全处置数据。此外，像加密这样的流程可能是安全处置明文数据所必需的，即在处置前对其进行加密，然后销毁密钥，这个过程被称为加密粉碎。

在云环境中恢复已删除的数据对攻击者来说并非易事，因为基于云的数据是分散的，通常存储在不同的物理位置并具有唯一的指针。但这仍然是一个存在的攻击向量，在评估数据处置的业务要求时应予以考虑。

为了安全处置电子记录，您的数据处置策略应包括如何根据数据的分类和敏感性销毁数据，并与屏幕上列出的销毁方法保持一致：

  • 物理销毁：通过焚化、粉碎或其他方式物理销毁介质。
  • 消磁：使用强磁铁扰乱硬盘或磁带等磁性介质上的数据。
  • 覆写：用随机数据覆盖实际数据。覆写过程发生的次数越多，数据销毁被认为越彻底。
  • 加密：使用加密方法以加密格式覆盖数据，使其在没有加密密钥的情况下无法读取。

由于前三个选项并不真正适用于云计算，在云中处置数据的唯一合理剩余方法是加密数据然后销毁密钥，这被称为数字粉碎或加密粉碎。

记住：加密粉碎（也称为数字粉碎）是故意销毁最初用于加密数据的加密密钥的过程。由于数据是用这些密钥加密的，结果是数据变得不可读（至少直到所使用的加密协议被破解或攻击者能够暴力破解）。为了执行适当的加密粉碎，数据应完全加密，不留下任何明文，并且技术必须确保加密密钥完全不可恢复。这也是我们将密钥与托管数据的云服务提供商分开管理的另一个原因。

总结 📝

在本节课中，我们一起学习了数据生命周期的六个阶段：创建、存储、使用、共享、归档和销毁。请记住，它们不需要按特定顺序执行。

我们讨论了数据生命周期的三个关键要素：数据的功能（如访问、处理、存储）、数据的位置和数据的参与者。

我们讲解了数据的映射过程，并讨论了数据策略：保留、归档和删除。

最后，我们详细探讨了加密粉碎，也称为数字粉碎，这是在云环境中安全处置数据的关键方法。

通过理解数据生命周期并应用适当的控制措施和策略，您可以更有效地在云环境中保护组织最宝贵的资产——数据。

018：信息权限管理与数字权限管理

在本课程中，我们将学习云数据安全领域中的两个重要概念：信息权限管理（IRM）与数字权限管理（DRM）。我们将探讨它们如何应用于云服务，了解其核心功能、实现方式以及在云环境中部署时面临的挑战。课程最后，我们还将回顾与知识产权相关的法律保护形式。

概述

信息权限管理是一种用于保护包含敏感信息的文档免受未经授权访问的IT安全技术。与适用于歌曲、电影等批量生产媒体的传统数字权限管理不同，IRM主要针对个人创建的文档、电子表格和演示文稿。

上一节我们介绍了IRM与DRM的基本区别，本节中我们来看看IRM解决方案通常具备的关键能力。

以下是信息权限管理解决方案应提供的核心能力，无论内容类型或格式如何：

  • 持久保护：确保文档、消息和附件在静态、传输中乃至分发给接收者后都受到保护。数字权限管理应跟随其保护的内容，无论内容位于何处、是副本还是原始文件，或如何被使用。保护不应因生产环境中的简单操作而失效。
  • 动态策略控制：数字权限管理工具应允许内容创建者和数据所有者修改其控制下受保护数据的访问控制列表和权限。它允许内容所有者定义和更改用户权限，例如查看、转发、复制、打印，以及在分发后召回或使内容过期。
  • 自动过期：提供随时自动撤销对文档、电子邮件和附件访问的能力，从而无论内容分发或存储于何处，都能强制执行信息安全策略。由于某些知识产权法律保护的性质，大量数字内容不会永久受保护。当法律保护终止时，数字权限管理保护也应终止。同样，许可证也会过期，受保护内容的访问和权限也应随之过期，无论内容在许可期结束时位于何处。
  • 持续审计：数字权限管理应允许对内容的使用和访问历史进行全面监控。它提供内容已送达和已被查看的确认，并提供符合组织信息安全政策的证明。
  • 复制限制：数字权限管理的很大一部分目的是限制对受保护内容的非法或未经授权的复制。因此，DRM解决方案应在多种复制形式上强制执行这些限制，包括屏幕截图、打印、电子复制、电子邮件附件等。
  • 远程权限撤销：特定知识产权的权利所有者应有权随时撤销这些权利。此能力可能因诉讼或侵权而使用。
  • 支持现有身份验证安全基础设施：通过利用目录和身份验证系统中已有的用户和组信息，减少管理员参与并加快部署速度。
  • 映射存储库访问控制列表：自动将基于ACL的权限映射到控制存储库外部内容的策略中。
  • 与所有第三方电子邮件过滤引擎集成：允许组织根据公司信息安全策略和联邦法规要求自动保护外发电子邮件。
  • 支持电子邮件应用程序：为Microsoft Outlook和IBM Lotus Notes等电子邮件程序提供接口和支持。
  • 支持其他文档类型：除了Microsoft Office和PDF，也可以支持其他文档类型。
  • 额外的安全和保护能力：允许用户拥有额外能力，例如确定谁可以访问文档、禁止打印整个文档或选定部分、禁用复制、粘贴和屏幕截图功能、如果授予打印权限则为页面添加水印、随时使文档访问过期或撤销、通过完整的审计跟踪记录所有文档活动。

数字权限管理的核心与分类

数字权限管理的核心是加密内容，然后应用一系列权限。权限可以简单到防止复制，也可以复杂到指定基于组或用户的限制，例如剪切和粘贴、电子邮件发送、更改内容等。任何处理DRM保护数据的应用程序或系统都必须能够解释和实施这些权限，这通常也意味着需要与密钥管理系统集成。

数字权限管理主要分为两大类：消费者DRM和企业DRM。

  • 消费者数字权限管理：用于保护广泛分发的内容，如面向大众的音频、视频和电子书。存在多种不同的技术和标准，重点在于单向分发。消费者DRM在为消费者分发内容方面提供了良好的保护，但记录不佳，大多数技术都曾在某个时间点被破解。
  • 企业数字权限管理：用于在组织内部以及与业务伙伴之间保护组织的内容。重点在于更复杂的权限、策略以及与业务环境（特别是公司目录服务）的集成。企业DRM可以很好地保护存储在云中的内容，但需要深入的基础设施集成。它对于基于文档的内容管理和分发最为有用。

在云中实施DRM的挑战

数字权限管理侧重于通过安全和加密来防止未经授权的复制，将分发限制在仅被授权的人员。与数据防泄露系统一样，这通常是一种员工安全控制，在云中并不总是适用，因为所有数字权限管理/企业权限管理系统都基于加密，现有工具可能会破坏云功能，尤其是在软件即服务中。

DRM实施有两种类型：完全DRM和基于提供商的控制DRM。

  • 完全DRM：是使用现有工具的传统数字权限管理，例如，在将文件存储到云服务之前对其应用权限。如前所述，除非存在某种集成（目前很少见），否则这可能会破坏云提供商的功能，如浏览器预览或协作。
  • 基于提供商的控制DRM：云平台可能能够通过使用原生功能来强制执行与完全DRM非常相似的控制。例如，用户设备“查看”与“编辑”策略，该策略只允许某些用户在Web浏览器中查看文件，而其他用户可以下载和/或编辑内容。有些平台甚至可以将这些策略绑定到特定设备，而不仅仅是用户级别。

在云中部署数字权限管理会带来一些挑战：

  • 复制限制：因为DRM通常涉及防止未经授权的复制，而云需要创建、关闭和复制虚拟化主机实例，包括存储在虚拟主机本地的用户特定内容。数字权限管理可能会干扰自动资源分配过程。
  • 管辖权冲突：云跨越边界和国界，通常以数据所有者未知且无法控制的方式进行，当知识产权权利受地域限制时，这可能会带来问题。
  • 代理或企业冲突：为执行目的需要本地安装软件代理的数字权限管理解决方案在云环境、虚拟化引擎或自带设备企业使用的各种平台上可能无法始终正常运行。
  • 映射DRM和身份访问管理：由于涉及内容特定访问控制列表的额外访问控制层，DRM身份访问管理流程可能会与企业或云身份访问管理冲突或无法正常工作。当云身份访问管理功能外包给第三方（如云访问安全代理）时，这一点更为明显。
  • API兼容性：由于数字权限管理工具通常内置于内容中，材料的使用在不同应用程序（如内容阅读器或媒体播放器）中可能无法提供相同级别的性能。

知识产权与法律保护

数字权限管理解决方案用于保护知识产权，以遵守相关保护并维护所有权。知识产权是那类无形的宝贵财产，字面意思是“思维的资产”。您应该为考试熟悉知识产权的法律保护形式，它们是：版权、商标、专利、商业秘密。

  • 版权：在美国，对思想表达的法律保护称为版权。版权授予首次创造思想表达形式的任何人，通常涉及文学作品、电影、音乐、软件和艺术作品。版权不涵盖思想、特定词语、口号、食谱或公式，这些东西通常可以通过其他知识产权保护来确保。版权保护思想的有形表达，而不是思想的形式。例如，版权保护一本书的内容，而不是书籍本身的实体副本。非法复制书籍内容属于版权侵权，而窃取实体书籍本身则属于盗窃。版权属于作者或作者出售或授予权利的人，而不是当前持有书籍实体副本的人。版权的期限根据其创建条款而异，取决于作品是个人创作还是根据合同创作。通常，版权有效期为作者死后70年，或雇佣作品首次出版后120年。版权赋予创作者对作品的独家使用权（有一些例外）。创作者是唯一合法允许公开表演作品、从作品中获利、复制作品、基于原作创作衍生作品、进口或出口作品、广播作品或出售/转让这些权利的实体。这些独家权利存在例外，包括合理使用原则下的例外，如教学、评论、新闻报道、学术研究、讽刺、图书馆保存、个人备份和为残障人士制作版本等。
  • 商标：与版权不同，商标保护旨在应用于特定的词语和图形。商标是组织的代表，即品牌。商标旨在保护组织在市场（尤其是公众认知中）建立的声誉和商誉。商标可以是组织的名称、徽标、与组织相关的短语，甚至是特定的颜色、声音或这些元素的组合。为了使商标受法律保护，必须在管辖区域内注册，通常是美国专利商标局。在USPTO注册的商标可以使用®符号表示已注册。各州也提供商标注册，在州注册的商标通常使用™符号。只要商标所有者继续将其用于商业目的，商标就可以永久有效。商标侵权是可诉的，商标所有者可以起诉侵权。
  • 专利：美国专利商标局也负责注册专利。专利是保护发明、工艺、材料、装饰和植物生命形式的知识产权的法律机制。获得专利后，专利所有者获得生产、销售和进口专利财产的专有权。专利通常从专利申请之日起持续20年。与其他知识产权保护一样，专利侵权可在联邦法院提起诉讼。
  • 商业秘密：商业秘密是涉及许多与专利材料相同方面的知识产权。它们也可能包括一些未申请专利的内容，例如信息聚合，例如客户或供应商名单。在美国，商业秘密也类似于版权，因为对其的保护在创建时即存在，无需任何额外的注册要求。然而，与知识产权保护不同，被视为商业秘密的材料必须确实是秘密的，不能向公众披露，并且必须努力保持其秘密性以维持这种法律保护。然后，商业秘密受到法律保护，防止非法获取。任何试图通过盗窃或盗用获取商业秘密的人都可以在民事法庭被起诉，也可以因这一罪行在联邦法院被起诉。然而，商业秘密保护并不赋予其他知识产权保护所授予的专有权。任何非该商业秘密所有者的人，通过合法手段发现或发明相同或类似的方法、工艺和信息，都有理由并可以自由地利用这些知识为自己谋利。事实上，通过合法手段发现他人商业秘密的人，也可以自由地为其申请专利，前提是同一材料或概念上没有现有专利。与商标一样，只要所有者仍在商业上使用它，商业秘密就可以永久有效。

加密在DRM中的应用

加密支持CIA三要素中的保密性（保密性、完整性、可用性），通过防止未经授权的数据查看来实现。在整个企业架构中为所有数据启用加密，可以降低与未经授权的数据访问和暴露相关的风险，但需要解决性能限制和问题。

这里需要记住的是，我们使用加密来保护传输中、静态和使用中的数据。

  • 传输中的数据：也称为动态数据。为了避免在传输过程中信息暴露或数据泄露，我们使用诸如IPsec、VPN和其他无线协议等加密技术。传输中数据的一个例子是数据进出云进行处理、归档和共享时。当我们在云中为传输中的数据部署数据防泄露时，这有时被称为基于网络或网关的DLP。在这种拓扑结构中，监控引擎部署在组织网关附近，以监控HTTP、HTTPS、SMTP和FTP等传出协议。
  • 静态数据：加密静态数据是防止任何人在数据归档或存储时看到他们无权查看的数据的好方法。可以根据要求使用不同的加密技术，例如，是实施长期保留还是短期存储，或者数据是位于数据库还是文件系统中。加密机制本身及其部署方式也各不相同。当我们在云中为静态数据部署数据防泄露时，这有时被称为基于存储的DLP。在这种拓扑结构中，数据防泄露引擎安装在数据静态存储的位置，通常是一个或多个存储子系统和文件/应用程序服务器。
  • 使用中的数据：是指正在被共享、处理或查看的数据。数据生命周期的这个阶段比其他加密技术更不成熟，通常侧重于数据防泄露系统等技术。数据防泄露，也称为数据泄漏防护，可用于检测未经授权的共享。信息权限管理或数字权限管理解决方案可用于保持对信息的控制。可能还需要遵守HIPAA或PCI DSS等法规，这反过来要求对穿越不受信任网络的数据以及某些类型的数据进行相关保护。当我们在云中部署数据防泄露以支持使用中的数据时，这有时被称为客户端或基于端点的DLP应用程序，它安装在用户的工作站和终端设备上。

对于数据库加密，考试需要理解三种基本选项：

  1. 文件/卷加密：数据库服务器通常驻留在卷存储上。对于这种部署，使用加密引擎加密数据库的卷或文件夹，密钥驻留在附加到该卷的实例上。
  2. 透明加密：许多数据库管理系统包含加密整个数据库或特定部分（如表）的能力。加密引擎驻留在数据库内部，对应用程序是透明的。
  3. 应用层加密：在应用层加密中，加密引擎位于使用数据库的应用程序中。由于数据在到达数据库之前已被加密，因此执行索引、搜索和元数据收集具有挑战性。

总结

在本课程中，我们一起学习了信息权限管理与数字权限管理的区别、数字权限管理工具的特性、在云中部署数字权限管理所面临的挑战、知识产权（如版权、商标、专利和商业秘密）以及数字权限管理中使用的加密技术。理解这些概念对于设计和管理安全的云环境至关重要。

019：数据保留策略 📚

在本节课中，我们将要学习云数据安全领域的一个重要组成部分：数据保留策略。我们将探讨其定义、目标、核心组件，以及如何在云环境中有效实施和管理这些策略。

概述

数据保留策略是组织为满足运营信息需求和法规遵从性要求而制定的协议。它旨在平衡法律、法规和业务数据归档需求与数据存储成本、复杂性之间的关系。一个完善的策略应明确规定保留期限、数据格式、数据安全及数据检索程序。

策略、标准、流程与程序的关系

在深入探讨数据保留策略的组件之前，我们需要理解组织治理文档的层级关系。

  • 策略：定义了组织应遵循的方向和高级别目标。
  • 标准：位于策略之下，明确了可接受与不可接受的行为或行动基线。缺乏标准意味着流程缺乏一致性和质量。
  • 流程：一套为实现特定目标而设计的输入输出系统，可以支持标准或策略。
  • 程序：为支持标准而建立的详细步骤，明确了谁在何时、何地、如何执行任务。
  • 支持文档：包含详细步骤或图示的工作手册、在线手册、指南、模板、表格等，用于支持流程或程序。

上一节我们介绍了治理文档的框架，本节中我们来看看数据保留策略的具体构成要素。

数据保留策略的核心组件

一个完整的数据保留策略应包含以下关键部分。

以下是策略必须定义的组件列表：

  1. 保留期限

    • 指数据应被组织保存的时间长度，通常针对归档用于长期存储的非生产环境数据。
    • 保留期限常以年为单位，并由法规、立法或合同协议规定。例如，某些财务记录需保留7年，医疗记录（如受HIPAA管辖）可能需保留6年。

  2. 数据映射

    • 这是映射所有相关数据以理解数据类型（结构化和非结构化）、数据格式、文件类型以及数据位置（网络驱动器、数据库、对象或卷存储）的过程。

  3. 保留格式

    • 策略应描述数据实际如何归档，包括存储介质类型（如磁带、光盘、云存储）以及针对该数据的特定处理规范。
    • 例如，某些法规（如PCI DSS）要求存储中的数据必须加密。此时，策略需包含对加密引擎、密钥存储和检索程序的描述，并引用相关法规。

  4. 数据安全与分类

    • 这涉及根据数据的位置、合规要求、所有权或业务用途（即其对组织的价值）对数据进行分类。
    • 分类也用于决定企业适用的正确保留程序。组织应有一个总体的数据分类策略，作为数据创建者、保管者和用户的指南。
    • 数据保留策略应特别提及不同类别数据将如何归档和检索。

  5. 数据保留程序

    • 这些程序应基于管理该数据类型的相应数据保留策略来执行。
    • 数据应保存多久、保存在何处（物理位置及司法管辖区）以及如何保存（技术和格式）都应在策略中明确规定，并通过程序实施。
    • 程序还应包括针对所管理数据类型的备份选项、检索要求和恢复程序。

  6. 数据检索程序

    • 存储的数据可用于纠正生产错误、作为业务连续性和灾难恢复备份，或用于数据挖掘以获取商业智能。
    • 但存储的数据只有在能够被高效且经济地检索并投入生产时才有用。策略应包含数据存入存储和恢复数据的详细流程描述。

  7. 监控、维护与执行

    • 这是确保整个流程正常运行的步骤，包括审查策略和要求，以确保任何变更都经过变更控制委员会（CCB）的审批。
    • 与所有组织策略一样，该策略应详细列出策略应多久被审查和修订一次、由谁执行、不遵守政策的后果，以及组织内哪个实体负责政策的执行。
    • 测试组织从存储备份中恢复的流程非常有用，有时甚至是法规要求，以确保流程有效且人员受过培训，能在中断发生时恢复数据。

云环境中的数据保留考量

在云中管理数据保留可能尤其棘手。例如，可能难以确保云服务提供商在指定的保留期限后不再保留组织的数据。

在考虑云迁移以及与潜在云提供商谈判时，组织应特别注意确保提供商能够在服务级别协议（SLA）中支持组织的保留政策。

总结

本节课中我们一起学习了数据保留策略的重要性及其核心组件。我们探讨了保留期限、数据映射、保留格式、数据安全与分类、数据保留程序、数据检索程序以及监控维护与执行。理解并妥善制定数据保留策略，对于确保云数据安全、满足合规要求及优化存储资源至关重要。

020：数据审计

概述

在本节课中，我们将要学习CCSP认证云数据安全领域的一个重要组成部分：数据审计。我们将探讨数据审计政策、审计日志与事件、安全信息与事件管理系统以及证据保管链等核心概念。

数据审计政策

作为CCSP认证云数据安全领域的一部分，接下来我们看看数据审计。在深入本课程之前，需要指出，我将通过用不同颜色高亮显示的方式，指出你必须为CCSP考试掌握的特定信息。屏幕上用双星号标注的颜色高亮的所有内容都与考试相关。

与所有其他资产一样，组织需要通过进行数据审计，定期审查、盘点和检查其拥有的数据的使用情况和状态。

与数据管理的其他要素一样，组织应制定对其数据进行审计的政策。该政策应包括对审计周期、审计范围、审计职责、内部和外部审计流程与程序、适用法规以及监控、维护和执行的详细描述。

与所有类型的审计一样，组织应特别注意确保审计人员不向管理结构中拥有或受其审计数据影响的任何人报告。必须避免利益冲突，审计才具有有效性和实用性。

审计日志与事件

在大多数组织中，审计以日志记录为基础。日志记录可以多种形式进行，例如事件日志记录、安全日志记录或流量日志记录。

事件可以定义为发生的事情。并非所有事件都重要，但许多事件是重要的。根据跟踪的事件和属性的数量，能够区分哪些事件需要关注可能具有挑战性，可能会产生大量数据。这些数据需要存储，然后进行分析，以发现可能表明系统中存在威胁或漏洞的活动模式，并加以解决。

你可以使用安全信息和事件管理系统来收集和分析来自多个系统的数据流，例如事件、安全和流量日志记录，并结合工具来分析日志数据。

日志可以由应用程序、操作系统和设备生成，用于一般或特定目的。例如，作为操作副产物收集日志的设备，如服务器；或主要以日志记录为目的的设备，如入侵检测系统或安全信息和事件管理系统。

为了能够进行有效的审计和调查，事件日志应包含尽可能多的被检查过程的相关数据。

开放Web应用程序安全项目是一个在线社区，在Web应用程序安全领域提供免费的文章、方法、文档、工具和技术。它建议将屏幕上列出的这些属性集成到事件数据中。可以将其视为4W：时间、地点、人物和事件。

以下是OWASP建议集成到事件数据中的关键属性列表：

  • 时间：例如日志日期和时间、事件日期和时间以及事件时间戳。事件时间戳可能与日志记录时间不同。
  • 地点：例如应用程序标识符、应用程序地址、工作站身份、服务名称和协议、地理位置、窗口或页面以及代码位置。
  • 人物：无论是人类还是机器用户，包括源地址、用户身份。
  • 事件：例如事件类型、事件严重性、安全相关事件标志以及事件描述。

日志审查与存储

日志审查和审计是具备特定培训和经验的人员的专业任务。审查员需要了解操作。如果审查员无法区分哪些是授权活动，哪些不是，他们就没有为流程增加安全价值。被指派审查日志的人员必须足够频繁地执行此任务，以便他们能识别基线活动，从而识别偏离基线的情况。

安全从业者的一个自然倾向可能是记录所有内容。我们领域的人以不愿放弃数据而闻名，想知道关于一切的一切。这样做的问题是，记录所有内容会带来额外的风险和成本。聚合如此多的日志数据会带来额外的漏洞并需要额外的保护，而记录所有内容所需的存储将导致存储系统和空间的大规模重复。

云环境中的数据审计挑战

云环境中的数据审计可能带来一些近乎不可能的挑战。云提供商可能出于运营、合同、安全责任或竞争原因，不愿意或实际上无法向客户披露日志数据。因此，组织在选择云迁移时必须再次考虑具体的审计要求，并将任何此类规范包含在与云提供商的合同或服务级别协议中。

数据审计政策涉及数据生命周期所有阶段的活动。

安全信息与事件管理系统

安全信息和事件管理系统通常提供此处列出的功能。让我们稍微分解一下这些功能：

  • 数据聚合：日志管理聚合来自许多来源的数据，包括网络、安全服务器、数据库和应用程序，提供整合、监控数据的能力，有助于避免遗漏关键事件。
  • 关联：寻找共同属性并将事件链接成有意义的集合。该技术提供执行各种关联技术的能力，以整合不同来源，从而将数据转化为有用信息。关联通常是完整SIEM解决方案中安全事件管理部分的功能。
  • 警报：作为对关联事件进行自动分析的结果，系统可以产生警报，通知接收者即时问题。警报可以发送到仪表板或通过电子邮件等第三方渠道发送。
  • 仪表板：提供可以将事件数据转化为信息图表的工具，以帮助发现模式或识别未形成标准模式的活动。
  • 报告：可以部署应用程序来自动收集合规性数据，生成适应现有安全治理和审计流程的报告。
  • 保留：基本上是采用历史数据的长期存储，以促进其随时间的关联，并提供合规性要求所需的保留。长期日志数据保留在取证调查中至关重要，因为不太可能在网络入侵发生时发现入侵。
  • 取证分析：能够根据特定条件跨不同节点和时间段搜索日志。这避免了必须在脑海中聚合日志信息，或为了特定数据而搜索成千上万条日志。

持续运营与证据保管

为了支持持续运营，此处列出的原则应作为安全运营政策的一部分被采纳。

审计日志记录需要对保护、保留和生命周期管理有更高级别的保证。审计日志可能存在法律、法规或监管合规义务，这些义务规定了问责制和完整性要求。

审计日志记录的持续运营由三个重要流程组成：新事件检测、添加新规则和减少误报。新事件检测用于检测信息安全事件。应创建定义安全事件是什么以及如何处理的策略。构建规则是为了允许检测新事件。规则允许将预期值映射到日志文件，以便在连续操作模式下检测事件。必须更新规则以应对新风险。最后，减少误报。持续运营审计日志记录的质量取决于随时间减少误报数量的能力。为了保持运营效率，这需要不断改进正在使用的规则集。请记住，新事件检测、添加新规则和减少误报都是审计日志记录的一部分。

下一个领域是合同或机构维护。应根据业务需求维护并定期更新适用监管机构、国家和地方执法部门以及其他法律管辖机构的联系人。这将确保已建立直接的合规联络，并使组织为需要与执法部门快速接触的取证调查做好准备。

必须建立处置政策和程序，并实施支持业务流程和技术措施，以安全处置并从所有存储介质中完全删除数据。这是为了确保数据无法通过任何计算机取证手段恢复。

事件响应和法律准备。如果信息安全事件后对个人或组织的后续行动需要采取法律行动，则应要求适当的取证程序，包括保管链，以保存和呈递证据，支持在相关司法管辖区下可能采取的法律行动。在通知后，受影响的客户或租户以及其他外部业务关系应有机会在法律允许的范围内参与取证调查。

请记住，存储需要成本，因此在规划事件数据保存时，必须根据业务和监管要求以及组织的保留责任仔细考虑存储。

保存由ISO 27037定义为维护和保护潜在数字证据的完整性和/或原始状态的过程。请记住这个考试定义。证据保存有助于确保证据在法庭上的可采性，但数字证据众所周知是脆弱的，很容易被更改或销毁。并且由于许多取证实验室的积压，数字证据在被分析或用于法律程序之前，可能会在存储中度过相当长的时间。它需要严格的访问控制，并防止意外或故意的修改，这就是我们对数字证据进行哈希处理的原因。

有两个概念是有效处理物理、数字或电子证据的核心：保管链和真实性。

保管链是从证据收集到在法庭上呈递期间对证据的保存和保护。它记录了证据从收集到销毁或永久归档的整个生命周期中由谁、做了什么、何时、何地以及如何处理。为了使证据在法庭上被认为是可采信的，应存在关于保管链的文件，并阐明从获取到最终处置过程中，对物品的收集、处理、状况、位置、转移、访问以及执行的任何分析。保管链的任何中断都可能对证据的完整性产生怀疑。这就是我们遵循正式的、有良好记录的程序的原因。换句话说，是数字或电子证据的标准操作程序。

当前用于证明真实性和完整性的协议依赖于哈希，哈希会创建一个对任何比特变化都敏感的唯一数字签名，例如SHA-256或SHA-512。如果签名与原始签名匹配或自原始收集以来没有改变，法庭将接受完整性已确立。

请记住，收集的任何证据都需要是真实的。证据需要与现场联系起来才能使用。你的收集过程必须保持证据的真实性、准确性、完整性、说服力和可采性。

  • 准确：你的收集过程必须保持证据的真实性。
  • 完整：应收集所有证据，包括支持或削弱其他定罪证据可靠性的证据。
  • 有说服力：证据应清晰易懂，并能让陪审团信服。
  • 可采信：它必须能够在法庭上使用。

如果你有多个司法管辖区，提供保管链可能具有挑战性。有时，提供保管链的唯一方法是在服务合同中包含相关条款，并确保云提供商将遵守与保管链问题相关的请求。

总结

在本节课中，我们一起讨论了数据审计政策、审计日志与事件、存储与审查、安全信息与事件管理系统、保管链和不可否认性。换句话说，证据需要是真实的、准确的、完整的、有说服力的和可采信的。

021：数据销毁与处置 🗑️🔐

在本节课中，我们将要学习CCSP认证数据安全领域的一个重要环节：数据销毁与处置。我们将探讨为何需要安全地销毁数据、相关的政策要求，以及在传统环境和云环境中不同的数据销毁方法。

在深入探讨之前，需要指出，为了帮助您备考，本教程中所有标为双星号（）**的内容都是CCSP考试必须掌握的重点信息。

数据销毁的重要性

数据销毁程序的一个关键部分是，在数据不再需要时对其进行安全处置。未能做到这一点可能导致数据泄露或合规性失败。安全处置程序旨在确保系统中没有留下任何可用于恢复原始数据的文件、指针或数据残留。

与其他数据管理功能一样，组织需要制定数据处置政策。该政策应包括数据处置流程的详细描述、组织需要遵守的任何适用法规，以及关于何时应销毁数据的明确指导。

制定数据删除政策的原因

以下是通常需要制定数据删除政策的原因：

  • 法规或立法要求：某些法律和法规要求对特定记录（例如包含个人身份信息或健康信息的记录）进行特定程度的安全处置。
  • 业务和技术要求：业务政策可能要求安全处置数据。此外，某些流程（如加密）也可能要求在创建加密副本后安全处置明文数据。

当然，我们也需要关注数据残留，即在尝试了清理和处置方法后遗留的任何数据。

云环境中的数据恢复挑战

在云环境中，攻击者恢复已删除数据并非易事，因为基于云的数据是分散的，通常存储在不同的物理位置并具有唯一的指针。由于云服务提供商采取了物理安全措施，攻击者要获得对CSP位置存储介质的任何物理访问权限都将是一个挑战。尽管如此，这仍然是一个存在的攻击向量，在评估业务需求时应予以考虑。

数据处置与数据生命周期

对于数据处置，数据处置政策处理的是数据生命周期中“销毁”阶段的活动。

传统环境中的数据处置选项

在组织拥有并控制所有基础设施（包括数据、硬件和软件）的传统环境中，数据处置选项是直接且明确的。

传统环境中的数据处置选项包括物理销毁、消磁、覆写和加密。以下是详细说明：

  • 物理销毁：这是指物理上摧毁存储介质。任何包含数据的硬件或便携式介质都可以通过焚烧、熔化、撞击（即敲打）、钻孔、研磨或工业粉碎等方式销毁。这是首选的清理方法，因为数据在物理上无法恢复。
  • 消磁：这涉及对存储数据的硬件和介质施加强磁场，使其有效变为空白。然而，此方法对固态硬盘无效。
  • 覆写：这是指用随机字符多次写入数据所在的特定磁盘扇区存储区域，最后一次写入全零和全一。对于大容量存储区域，这可能非常耗时。
  • 加密：这是指使用加密方法，以加密格式覆写数据，使其在没有加密密钥的情况下无法读取。

云环境中的数据处置挑战

由于前三个选项不完全适用于云计算，唯一合理的方法是加密数据。请记住，在云中，数据处置更加困难和危险。

用于处置数据的加密过程称为加密粉碎，也称为加密擦除或数字粉碎。加密粉碎是故意销毁最初用于加密数据的加密密钥的过程。 这包括使用强加密引擎加密数据，然后获取该过程中生成的密钥，用另一个加密引擎加密这些密钥，最后销毁这些密钥。

要正确执行加密粉碎，数据应被完全加密，不留任何明文，并且该技术必须确保加密密钥完全无法恢复。如果外部云服务提供商或其他第三方管理密钥，这可能很难实现。

为何传统方法在云中不可行

硬件和介质永远不能仅通过删除数据来清理。删除操作并不会擦除数据，它只是移除用于处理目的的数据逻辑指针。

在云中，许多传统选项（如物理销毁、消磁和覆写）不可用或不可行，因为硬件归云提供商所有，而非数据所有者所有。物理销毁通常是不可能的。此外，由于很难知道数据在任何给定时刻或历史上的实际具体物理位置，几乎不可能确定所有需要销毁的组件和介质。同样，由于相同的原因，覆写也不是云中清理数据的实用方法。

这使得加密粉碎成为云中数据处置的唯一可编程选项。

加密粉碎的注意事项

如果加密粉碎执行正确，应该没有残留。但是，如果某些材料未包含在原始加密中（例如在加密过程中处于离线状态的虚拟机实例，之后被添加到云环境），则可能被视为残留。与所有加密实践一样，正确的实施对于成功至关重要。

课程总结

在本节课中，我们一起学习了数据销毁与处置。我们讨论了物理销毁、消磁、覆写和加密等方法，并指出对于云环境，加密粉碎（也称为加密擦除或数字粉碎）是唯一现实可行的选项。同时，您需要为考试掌握：加密粉碎是故意销毁最初用于加密数据的加密密钥的过程。

022：云存储架构 🗂️

在本节课中，我们将学习云存储架构。作为CCSP认证中云平台与基础设施安全领域的一部分，理解不同的云存储类型及其架构至关重要。我们将逐一探讨各种存储方式，并明确它们在考试中的重点。

云存储概述

云中有多种存储数据的方式，每种方式都有其自身的优势和成本。接下来的内容将涵盖卷存储及其子类（基于文件的存储和块存储）、基于对象的存储、结构化和非结构化存储、信息存储与管理以及内容或文件存储。

卷存储

在卷存储中，客户被分配云内的一块存储空间。从客户的角度看，这块存储空间表现为一个附加到其虚拟机的虚拟驱动器。虚拟驱动器的运作方式与连接到实体设备的物理驱动器非常相似，其实际位置和内存地址对用户是透明的。

卷存储架构可以采取不同的形式。关于哪种类型的卷更受青睐，云专业人士间有大量讨论，主要是文件存储和块存储。让我们来看看这两种。

以下是两种主要的卷存储类型：

  • 文件存储：也称为文件级存储或基于文件的存储。数据以文件和文件夹的形式存储和显示，与传统环境中的文件结构相同，具有所有相同的层级和命名功能。随着云技术和大数据分析工具及流程的发展，文件存储架构变得越来越流行。
  • 块存储：与文件存储具有文件夹和文件的层级结构不同，块存储是一个空白的卷，客户或用户可以将内容放入其中。块存储可能提供更高的灵活性和性能，但需要更多的管理工作，并且可能需要安装操作系统或其他应用程序来存储、排序和检索数据。块存储可能更适合包含多种类型数据的用途，例如企业备份服务。

卷的存储架构可以包含纠删码，这基本上是一种在云中实现廉价磁盘冗余阵列（RAID）作为数据保护解决方案的手段。我将在几分钟内解释RAID系统是什么。

卷存储可以在任何云服务模型中提供，但通常与基础设施即服务（IaaS）相关联。

对象存储

对象存储顾名思义，数据以对象的形式存储，而不是文件或块。对象不仅包含实际的生产内容，还包含描述内容和对象的元数据，以及一个用于在整个存储空间中定位该特定对象的唯一地址标识符。这些对象可以通过应用程序编程接口（API）访问，也可能通过Web用户界面访问。

对象存储系统提供表征状态转移（REST）API，允许程序员处理容器和对象。应用程序编程接口（API）通常使用令牌而不是传统的用户名和密码。API可以分为多种格式，其中两种是：

  • 表征状态转移（REST）：一种软件架构风格，包含创建可扩展Web服务的指导原则和最佳实践。
  • 简单对象访问协议（SOAP）：一种用于在计算机网络中实现Web服务时交换结构化信息的协议规范。

对象存储系统不是将文件组织在目录层次结构中，而是将文件存储在称为“桶”的容器的扁平组织中，并使用称为“键”的唯一ID来检索它们。对象存储通常是存储操作系统镜像的方式，管理程序将这些镜像启动到运行实例中。

通常，对象存储可以通过将数据分散到多个对象存储服务器上（通过分片和复制）来实现冗余，以此提高弹性。这可以增加弹性和性能，并可能降低数据丢失风险。

对象存储架构允许进行显著级别的描述，包括标记、标签、分类和分类规范。这也增强了索引能力、数据策略执行（如数字版权管理或数据丢失防护系统）以及某些数据管理功能集中化的机会。

同样，任何云服务模型都可以包含对象存储架构，但对象存储通常与基础设施即服务（IaaS）相关联。

请记住考试要点：基础设施即服务（IaaS）使用两种存储类型：卷存储和对象存储。卷存储是一个可以附加到虚拟机实例的虚拟硬盘，可用于在文件系统中托管数据。附加到IaaS实例的卷的行为就像物理驱动器或阵列一样。对象存储类似于通过API或Web界面共享访问的文件。请记住这一点以备考试。

同时，请确保你理解在基础设施即服务（IaaS）中，用户负责管理应用程序、数据、运行时、中间件和操作系统。提供商仍然管理虚拟化、服务器、硬盘存储和网络。在IaaS中，用户或组织拥有最多的责任和控制权。

数据库存储

与传统的对应物类似，云中的数据库为存储的数据提供某种结构。数据将根据数据本身的特征和元素进行排列，包括归档数据所需的特定特征，称为主键。在云中，数据库通常是数据中心的后端存储，用户通过浏览器使用在线应用程序或API进行访问。

数据库可以在任何云服务模型中实现，但它们最常被配置为与平台即服务（PaaS）和软件即服务（SaaS）一起工作。

请记住考试要点：平台即服务（PaaS）利用两种数据存储类型：结构化和非结构化。

  • 结构化信息：具有高度组织性的信息，例如关系数据库。它无缝且易于通过简单直接的搜索引擎算法或其他操作进行搜索。
  • 非结构化信息：不驻留在传统行列数据库中的信息。非结构化数据文件通常包括文本和元数据内容。例如包括电子邮件、文字处理文档、视频、照片、音频文件、演示文稿、网页和许多其他类型的业务文档。请注意，虽然这类文件可能具有内部结构，但它们仍被视为非结构化，因为它们包含的数据无法整齐地放入数据库中。

请记住考试要点：平台即服务（PaaS）使应用程序的开发、测试和部署变得快速、简单且经济高效。通过这项技术，企业运营或第三方提供商可以管理操作系统、虚拟化、服务器存储、网络和PaaS软件本身。开发人员管理他们安装的应用程序和他们生成的数据。

你还需要记住考试要点：软件即服务（SaaS）利用两种主要的数据存储类型：信息存储与管理以及内容或文件存储。

  • 信息存储与管理：通过Web界面输入并存储在SaaS应用程序（通常是后端数据库）中的数据。这种数据存储利用数据库，而数据库又安装在对象或卷存储上。
  • 内容或文件存储：存储在应用程序内部的数据。

其他存储类型

你应该熟悉的其他存储类型包括：

  • 临时存储：这种存储类型与基础设施即服务（IaaS）实例相关，并且仅在实例运行时存在。它通常用于交换文件和其他临时存储需求，并会随其实例一起终止。你需要记住这一点以备考试。
  • 内容分发网络（CDN）：内容分发网络是一种数据缓存形式，通常位于高使用需求的地理位置附近，用于存放用户经常请求的数据副本。组织希望使用CDN的最佳例子可能是在线多媒体流媒体服务。与其将数据从数据中心拖拽到大陆上不同距离的用户那里，流媒体服务提供商可以将最常请求的媒体副本放置在可能发出这些请求的大都市区域附近，从而提高带宽和交付质量。CDN的例子包括Akamai Technologies、Amazon CloudFront或Azure CDN。
  • 原始存储和长期存储：原始设备映射（RDM）是VMware服务器虚拟化环境中的一个选项，它使存储逻辑单元号（LUN）能够从存储区域网络（SAN）直接连接到虚拟机。在Microsoft Hyper-V平台中，这是通过使用直通磁盘实现的。最后是长期存储：一些供应商提供专门针对数据归档需求定制的云存储服务。这些服务包括搜索、保证不可变性和生命周期管理等功能。
  • 集群存储：集群存储是使用两个或更多存储服务器协同工作以提高性能、容量和可靠性。集群将工作负载分配给每个服务器，管理服务器之间的工作负载转移，并提供从任何服务器访问所有文件的能力，无论文件的物理位置如何。存在两种基本的集群存储架构，称为紧耦合和松耦合。紧耦合集群具有物理背板，可在服务器之间提供高性能互连，以实现负载平衡、性能和最大可扩展性（随着集群增长）。松耦合集群提供经济高效的构建块，可以从小规模开始，并根据应用程序需求增长。

请记住考试要点：软件即服务（SaaS）使用Web交付由第三方供应商管理的应用程序，其界面在客户端访问。对于企业来说，使用SaaS可以简化维护和支持，因为一切都可以由供应商管理：应用程序运行时、数据、中间件、操作系统、虚拟化、服务器存储和网络。客户端仅负责他们在软件中生成的数据，以及可能在客户端前端的一些应用程序接口。

存储集群应设计为满足服务级别协议中规定的所需服务级别，为多租户托管环境中分离客户数据提供能力，并通过使用加密、哈希、掩码和多路径等保密性、完整性和可用性机制来安全存储和保护数据。

技术细节与RAID

在技术层面上，云计算中的持久大容量存储通常由旋转硬盘驱动器或固态硬盘组成。出于可靠性目的，磁盘驱动器通常被分组以提供冗余。典型的方法是廉价磁盘冗余阵列（RAID），这实际上是一组技术。RAID组配置了冗余磁盘，以便当其中一个磁盘发生故障时，磁盘控制器仍然可以检索数据。平均而言，磁盘驱动器每年的故障率为3%到5%。粗略地说，在5000个已安装的磁盘中，你可以预期每天发生一次故障。RAID技术在冗余磁盘的百分比和它们可以提供的总体性能方面有所不同。

存储功能的一部分是将磁盘切片并分组为任意大小的逻辑卷，也称为逻辑单元号（LUN）、虚拟硬盘、卷存储、弹性块存储（Amazon EBS）和Rackspace Cloud Block Storage等都是这方面的例子。这些存储卷没有文件系统。文件系统结构由供应给它们的虚拟机实例上的操作系统应用。

对于考试，你应该熟悉我在本屏幕上为你列出的RAID级别：

  • RAID 0：仅使用条带化。这里没有冗余的好处。如果其中一个磁盘发生故障，信息就会丢失。
  • RAID 1：仅使用镜像。在RAID 1中没有性能优势，但你确实有冗余。
  • RAID 3：使用奇偶校验和条带化，因此你确实有冗余，因为奇偶校验磁盘可以从丢失的磁盘重新创建信息。
  • RAID 5：使用奇偶校验和条带化，奇偶校验交错分布在驱动器上，而不是在单独的驱动器上。

管理平面

管理平面允许管理员远程管理任何或所有主机，而不必亲自访问每台服务器来打开它或在上面安装软件。

管理平面的关键功能是创建、启动和停止虚拟机实例，并为它们提供适当的虚拟资源，如CPU、内存、永久存储和网络连接（当管理程序支持时）。管理平面还控制虚拟机实例的实时迁移。然后，管理平面可以管理整个设备群中的所有这些资源。

管理平面软件通常运行在它自己的一组服务器上，并具有与受管物理机的专用连接。因为管理平面是整个云基础设施中最强大的工具，它还集成了身份验证、访问控制以及对正在使用的资源的日志记录和监控。

管理平面由权限最高的用户使用，即那些安装和移除硬件、系统软件、固件等的人员。管理平面也是个别租户访问云资源的途径，他们的访问权限有限且受控。

管理平面的主要接口是API，既面向被管理的资源，也面向用户。图形用户界面（GUI）或网页通常构建在这些API之上。这些API允许自动化受控任务，例如编写脚本和编排复杂应用程序架构的设置、填充配置管理数据库、在物理资产上分配资源以及配置和轮换用户访问凭证。

维护模式

在更新或配置云环境的不同组件时，会使用维护模式。在维护模式下，客户访问被阻止，警报被关闭或禁用，尽管日志记录仍然启用。你需要记住这一点以备考试。你应始终遵循供应商特定的指导原则和最佳实践，进入维护模式、在其中操作并成功退出。任何托管的虚拟机或数据如果需要在系统维护期间保持可用，应在进入维护模式之前进行迁移。

维护模式可以应用于数据存储和主机。服务级别协议应描述IT服务，记录服务级别目标，并指定IT服务提供商和客户在进入和执行维护模式时的职责。

总结

在本节课中，我们一起讨论了云存储架构，包括卷存储、对象存储、结构化和非结构化存储、信息存储与管理以及内容或文件存储。我们还讨论了您应该熟悉的其他存储类型：临时存储、内容分发网络、原始存储和长期存储。我们谈到了云存储集群，无论是紧耦合集群还是松耦合集群。我们还讨论了云管理平面中的存储问题，最后是维护模式。

023：云安全策略 🔐

在本节课中，我们将学习云安全策略的核心组成部分，包括数据加密、密钥管理、数据保护替代方案、数据防泄露以及安全信息与事件管理。这些知识对于保护云平台和基础设施至关重要。

加密技术

上一节我们介绍了云安全策略的重要性，本节中我们来看看实现数据保护的基础技术：加密。加密的挑战在于，它必须与业务考量、法规要求以及组织可能面临的其他限制直接相关。根据数据的状态（静态、传输中或使用中），会采用不同的技术。在云环境中，处理特定威胁（如保护个人身份信息或受法律监管的信息）或防御来自系统和平台管理员的未授权访问时，可能会适用不同的选项。

存储级加密

存储级加密的加密引擎位于存储管理层，密钥通常由云服务提供商持有、存储或保留。该引擎会对写入存储的数据进行加密，并在数据离开存储（例如被使用时）进行解密。这种加密类型与对象存储和卷存储都相关，但它只能防止硬件被盗或丢失，无法防止云提供商管理员访问或来自存储层之上的未授权访问。

卷存储加密

卷存储加密要求加密数据驻留在卷存储上。这通常通过一个加密容器来实现，该容器被映射为一个文件夹或卷。卷存储加密无法防止通过实例进行的任何访问，例如在实例上运行的应用程序内部进行操作的攻击。

以下是实现卷存储加密的两种方法：

  • 基于实例的加密：加密引擎位于实例本身。密钥可以在本地保护，但应在实例外部进行管理。基于实例的加密只允许通过卷操作系统访问数据，并能防止物理丢失或被盗、外部管理员访问存储、以及从系统中获取并移除的存储快照或存储级备份。
  • 基于代理的加密：加密引擎运行在代理实例或应用程序上。代理实例是一台安全机器，负责处理所有加密操作，包括密钥管理和存储。代理将数据映射到卷存储上，并提供给实例访问。密钥可以存储在代理上，或通过外部密钥存储（推荐方法）存储，由代理负责密钥交换和所需的密钥保护。

对象存储加密

大多数对象存储服务都提供服务器端存储级加密。但这种加密的有效性有限，因此建议在将数据推送到云存储环境之前，使用外部加密机制对数据进行加密。外部机制可以是文件级加密或应用程序级加密。

  • 文件级加密：例如信息权限管理或数字版权管理解决方案，其加密引擎通常实现在客户端，并会保留原始文件的格式。
  • 应用程序级加密：加密引擎位于使用对象存储的应用程序中。它可以集成到应用程序组件中，或通过一个在数据进入云端之前负责加密的代理来实现。该代理可以部署在客户网关或外部提供商的服务上。

数据库加密

您应该了解数据库加密的三种选项：

  • 文件级加密：数据库服务器通常驻留在卷存储上。对于这种部署，您加密的是数据库的卷或文件夹，加密引擎和密钥驻留在连接到该卷的实例上。
  • 透明加密：加密引擎位于数据库内部，对应用程序是透明的。密钥通常驻留在实例内，但其处理和管理可以卸载到外部密钥管理系统。这种加密可以有效防止介质盗窃、备份系统入侵以及某些数据库和应用程序级别的攻击。
  • 应用程序级加密：加密引擎位于使用数据库的应用程序中。由于数据在到达数据库之前已被加密，因此难以执行索引、搜索和元数据收集。

密钥管理

加密实现中最重要的部分是密钥管理，即对密钥的签发、复制、恢复和分发的控制。柯克霍夫原则指出，即使密码系统的所有细节（除了密钥）都公开，密码系统也应该是安全的。这简单意味着密钥是密码系统真正的力量所在。密钥在其整个生命周期中如何处理和管理成为密码学中最重要的事情，这也是加密密钥管理的前提。没有加密，就不可能以任何安全的方式使用云。远程用户使用加密来创建安全通信连接；云客户的企业使用加密来保护自己的数据；在数据中心内部，云提供商使用加密来确保不同的云客户不会意外访问彼此的数据。

从安全角度来看，首先需要消除对云提供商正在正确处理和控制加密过程的依赖或假设。其次，通过拥有独特且独立的加密机制，在数据和传输级别应用额外的安全性和保密性，确保您不受云环境中共享密钥或数据泄漏的约束或限制。

密钥的存储方式和位置会影响数据的整体风险。在规划密钥管理时，应考虑以下生命周期事项：密钥生成应使用随机数；加密密钥绝不应以明文形式传输，并应始终保持在可信环境中。此外，在考虑密钥托管或密钥管理即服务时，应仔细规划，考虑所有相关法律、法规和管辖要求。无法访问加密密钥将导致无法访问数据，这在讨论保密性威胁与可用性威胁时应予以考虑。最后，在可能的情况下，密钥管理功能应与云提供商分开进行，以强制执行职责分离，并在尝试未授权数据访问时迫使串谋发生。

对于云计算密钥管理服务，最常采用以下两种方法：

  • 远程密钥管理服务：客户在本地维护密钥管理服务。理想情况下，客户将拥有、运营和维护KMS，从而使客户能够控制信息保密性，而云提供商则可以专注于服务的托管、处理和可用性。
  • 客户端密钥管理：与远程密钥管理类似，客户端方法旨在让客户或云用户完全控制加密和解密密钥。主要区别在于，大部分处理和控制都在客户侧完成。云提供商可以提供密钥管理服务，但KMS驻留在客户本地，密钥由客户生成、持有和保留。这种方法通常用于软件即服务环境和云部署。

无论最终采用哪种方法，首选的解决方案都是不要将加密密钥与云提供商存储在一起。

密钥管理的常见挑战包括密钥访问、密钥存储以及备份和复制。最佳实践与法规要求相结合，可能会为密钥访问设定特定标准，同时限制或不允许云服务提供商员工或人员访问密钥。密钥的安全存储对于保护数据至关重要。在传统的内部环境中，密钥存储在安全的专用硬件中。这在云环境中可能并不总是可行。最后，在云中，数据备份和复制以多种不同格式进行，这可能影响长期或短期密钥管理有效维护和管理的能力。

云中的密钥存储通常通过内部、外部或第三方方式实现：

  • 内部管理：密钥存储在同时充当加密引擎的虚拟机或应用程序组件上。这种密钥管理类型通常用于存储级加密、内部数据库加密或备份应用程序加密。这种方法有助于减轻与介质丢失相关的风险。
  • 外部管理：密钥与加密引擎和数据分开维护。它们可以在同一云平台内部、组织内部或不同的云上。实际存储可以是一个专门为此任务加固的独立实例，或一个硬件安全模块。在实施外部密钥存储时，需要查看密钥管理系统如何与加密引擎集成，以及密钥的整个生命周期（从生成到销毁）如何管理。
  • 第三方管理：当密钥托管服务由可信的第三方提供时。密钥管理提供商使用专门开发的安全基础设施和集成服务进行密钥管理。您必须评估您打算签约的任何第三方密钥存储服务提供商，以确保允许第三方持有加密密钥的风险得到理解和记录。

通常，云服务提供商使用基于软件的解决方案来保护密钥，以避免基于硬件的安全模块带来的额外成本和开销。问题是，基于软件的密钥管理解决方案通常不符合美国国家标准与技术研究院联邦信息处理标准FIPS 140-2或140-3中规定的安全要求。因此，缺乏FIPS认证的加密对于美国联邦政府机构和其他希望使用云服务提供商的组织来说可能是一个问题。

加密的替代方案

由于性能、成本和技术能力等多种原因，使用加密并不总是一个现实的选择。因此，需要采用额外的机制来确保可以实现数据保密性。在这方面，可以使用掩码、混淆、匿名化和令牌化。

数据掩码与混淆

数据掩码或数据混淆是从特定数据集中隐藏、替换或省略敏感信息的过程。数据掩码通常用于保护特定数据集，如个人身份信息或商业敏感数据，以符合某些法规要求。它也可用于测试平台，当测试数据不可用时。常见的数据掩码方法有：

  • 随机替换：用随机值替换或追加原值。
  • 算法替换：用算法生成的值替换或追加原值。这通常允许双向替换。
  • 混洗：混洗数据集中不同行的值，通常来自同一列。
  • 掩码：使用特定字符隐藏数据的某些部分，通常适用于信用卡数据格式。

掩码的主要方法是静态掩码和动态掩码。静态掩码是创建一个带有掩码值的新数据副本。动态掩码有时称为即时掩码，它在应用程序和数据库之间添加一个掩码层。当表示层访问数据库时，掩码层负责即时掩码数据库中的信息。最后，删除法简单地使用空值或删除数据。

识别个人用户或个人信息有两个主要组成部分：直接标识符和间接标识符。直接标识符是唯一标识主体的字段，通常被称为个人身份信息。掩码解决方案通常用于保护直接标识符。间接标识符通常包括人口统计或社会经济信息、日期或事件。间接标识符本身无法识别个人，风险在于数据聚合，当我们开始将多个间接标识符与外部数据结合起来时，可能会导致信息主体暴露。间接标识符的挑战在于，这类数据可能被集成到自由文本字段中，这些字段往往比直接标识符的结构化程度低，从而使过程复杂化。

匿名化

匿名化是移除间接标识符的过程，以防止数据分析工具或其他智能机制从多个来源收集或提取数据来识别个人或敏感信息。匿名化的过程类似于掩码，包括识别要匿名的相关信息，并选择相关的数据混淆方法。

令牌化

令牌化是用一个无意义的等价物（称为令牌）替换敏感数据元素的过程。令牌通常是一组随机值，具有原始数据占位符的形状和形式，并通过令牌化应用程序或解决方案映射回原始数据。令牌化不是加密。令牌化将数据完全从数据库中移除，用识别和访问资源的机制取而代之。它用于在安全、受保护和受监管的环境中保护敏感数据。令牌化可以在内部实现（当需要集中保护敏感数据时），也可以使用令牌化服务在外部实现。令牌化有助于遵守法规或法律，降低合规成本，减轻存储敏感数据的风险，并减少对该数据的攻击向量。

云及其相关技术一直在发展，可能难以跟上。一些例子是比特分割和同态加密。比特分割通常涉及将加密信息拆分并存储在不同的云存储服务中。根据比特分割系统的实现方式，可能需要部分或全部数据集可用才能解密和读取数据。比特分割的优点是提高了数据保密性；在不同地理区域或司法管辖区之间进行比特分割可能使通过传票或其他法律程序更难获取完整数据；并且它具有可扩展性，可以集成到安全的云存储API技术中，并可能降低供应商锁定的风险。比特分割的挑战在于存储要求和成本通常更高；它是CPU密集型的，因为需要处理和重新处理比特的加密和解密；并且比特分割可能产生可用性风险，因为整个数据集可能无法在云提供商存储和处理比特的同一地理区域内可用。比特分割可以利用不同的方法，其中很大一部分基于秘密共享加密算法。

同态加密仍处于研究阶段，尚未准备好用于生产环境，但其目的是创造在不先解密的情况下处理加密数据的可能性。换句话说，它允许云客户将数据上传到云服务提供商进行处理，而无需先解密数据。

数据防泄露

对于基于云的数据防泄露系统，您需要考虑以下几点：云中的数据往往会在不同位置、数据中心、备份之间或在组织内外移动和复制，这种移动或复制可能对任何DLP实施构成挑战。此外，对企业云中数据的管理员访问可能很棘手，您需要确保了解如何在基于云的存储中执行发现和分类。数据防泄露技术也可能影响整体性能，因为扫描所有流量以查找预定义内容的网络或网关DLP可能会影响网络性能。基于客户端的DLP扫描工作站对所有数据的访问，这可能影响工作站的运行。您需要在测试和部署期间查看整体影响，并找出可能的瓶颈。

大多数数据防泄露解决方案包括一套技术，以促进三个关键目标：定位和编录整个企业中存储的敏感信息；监控和控制敏感信息在整个企业中的移动；最后，监控和控制终端用户系统上敏感信息的移动。要被视为一个完整的数据防泄露解决方案，DLP需要解决信息的全部三种状态，并通过集中管理功能进行集成。

管理控制台中可用的服务范围因产品而异，但大多数都具有屏幕上列出的这些常见功能：

  • 策略创建和管理：这些是策略或规则集，规定了各种DLP组件采取的操作。
  • 目录服务集成：与目录服务的集成，允许DLP控制台将网络地址映射到指定的终端用户。
  • 工作流管理：大多数完整的DLP解决方案提供配置事件处理的能力，允许中央管理系统根据违规类型、严重性、用户和其他此类标准将特定事件路由给适当的各方。
  • 备份和恢复：备份和恢复功能允许保存策略和其他配置设置。
  • 报告：报告功能可能是内部的，也可能利用外部报告工具。

我们已经在之前的课程中讨论过架构。这里我希望您记住的是：

  • 传输中的数据：有时称为基于网络或网关的DLP，其监控引擎部署在组织网关附近，以监控传出协议。拓扑可以是基于代理的、网桥、网络分路或SMTP中继的混合。
  • 静态数据：有时称为基于存储的数据，DLP引擎安装在数据静止的位置，通常是一个或多个存储子系统以及文件和应用程序服务器。这种拓扑对于数据发现和跟踪使用情况非常有效，但可能需要与基于网络或终端的DLP集成以进行策略执行。
  • 使用中的数据：有时称为基于客户端或终端的，DLP应用程序安装在用户工作站和终端设备上。这种拓扑提供了对用户如何使用数据的洞察力，并能够添加网络DLP可能无法提供的保护。基于客户端的DLP的挑战在于在所有终端设备（通常跨越多个地点和大量用户）上实施的复杂性、时间和资源。

安全信息与事件管理

您应该知道，安全信息与事件管理软件产品和服务结合了安全信息管理和安全事件管理。SIEM系统作为软件设备或管理服务出售，也用于记录来自多个系统的安全数据流，并生成合规性报告。SIM或SEM这两个缩写有时可以互换使用。提供长期存储、分析和报告日志数据的领域称为安全信息管理。安全管理的第二个部分，处理实时监控、事件关联、通知和控制台视图，通常称为安全事件管理。简而言之，SIEM将所有信息放入易于理解的通用格式，并提供警报和报告。它提供对网络硬件和应用程序生成的安全警报以及来自网络、防火墙、路由器、服务器、IDS、IPS的日志的实时分析，基本上它将所有信息整合在一起并关联数据，使您能够进行更好的分析并可能识别问题。

您应该了解的一些SIEM特性包括：集中收集日志数据、增强的分析、仪表板和自动响应。它存储来自各种系统日志的原始信息，将信息聚合到单个存储库，规范化信息以使其更有意义。它拥有可以处理、映射和提取目标信息的分析工具，以及警报和报告工具。

SIEM系统通常提供屏幕上列出的功能：

  • 数据聚合：日志管理从许多来源（包括网络、安全设备、服务器、数据库和应用程序）聚合数据，提供整合监控数据的能力，有助于避免遗漏关键事件。
  • 关联：寻找共同属性并将事件链接成有意义的集合。该技术提供执行各种关联技术的能力，以整合不同来源，从而将数据转化为有用信息。关联通常是完整SEIM解决方案中安全事件管理部分的功能。
  • 警报：对关联事件进行自动分析并生成警报，以通知接收者即时问题。警报可以通过仪表板或通过电子邮件等第三方渠道发送。
  • 仪表板：提供工具，可以将事件数据转化为信息图表，帮助发现模式或识别未形成标准模式的活动。
  • 合规应用程序：可用于自动收集合规数据，生成适应现有安全治理和审计流程的报告。
  • 保留：采用历史数据的长期存储，以促进跨时间的数据关联，并提供合规要求所需的保留。长期日志数据保留对于取证调查至关重要，并且不太可能在网络入侵发生时立即发现，因此这些日志在那个时候是必要的。
  • 取证分析：能够根据特定条件跨不同节点和时间段搜索日志。这减轻了必须在脑海中聚合日志信息或必须筛选成千上万条日志的负担。

为了支持持续运营，应采纳此处列出的原则作为安全运营策略的一部分。审计日志需要更高级别的保护、保留和生命周期管理保证。可能存在对审计日志的法律、法定或监管合规义务，这些义务规定了问责制和完整性要求。审计日志的持续运营由三个重要流程组成：新事件检测、添加新规则以及减少误报。我们来分解一下：

  • 新事件检测：为检测新的信息安全事件，应创建定义什么是安全事件以及如何应对的策略。
  • 添加新规则：构建规则以允许检测新事件。规则允许将预期值映射到日志文件，以便在持续运营模式下检测事件。必须更新规则以应对新风险。
  • 减少误报：持续运营审计日志的质量取决于随时间推移减少误报数量的能力，以保持运营效率。这需要不断改进正在使用的规则集。

以上是所有涉及审计日志的元素。下一个领域是联系人和权限维护。应作为业务需求的一部分，维护并定期更新与适用监管机构、国家和执法部门以及其他法律管辖机构的联系人。这将确保已建立直接的合规联络渠道，并使组织为需要与执法部门快速接触的取证调查做好准备。

安全处置。必须制定策略和程序，并实施支持性的业务流程和技术措施，以安全处置和完全移除所有存储中的数据。这是为了确保数据无法通过任何计算机取证手段恢复。

最后，事件响应和法律准备。在信息安全事件发生后，如果需要对个人或组织采取后续法律行动，应要求适当的取证程序，包括证据链，以保存和呈递证据，支持潜在的法律行动，并遵守相关司法管辖区的规定。在通知后，应给予受影响的客户或租户和/或其他外部业务关系（在法律允许的范围内）参与取证调查的机会。

总结

在本节课中，我们讨论了加密技术，包括存储级加密、卷存储加密和对象存储加密。我们还讨论了数据库加密，包括驻留在卷存储上的文件级加密、加密引擎驻留在数据库内部的透明加密，以及加密引擎驻留在应用程序的应用程序加密。我们还讨论了密钥管理和存储、加密的替代方案（如掩码、混淆、匿名化和令牌化）、数据防泄露系统，最后是安全信息与事件管理。

024：云平台风险与责任 👨‍💻

在本节课中，我们将学习CCSP认证“云平台与基础设施安全”知识域的核心内容：云平台的风险与责任划分。理解云服务提供商与客户之间的责任共担模型是确保云安全的基础。

概述

云平台的风险与责任由云服务提供商和客户共同承担。由于双方都会处理至少部分属于客户的数据，因此与数据处理相关的风险和职责需要明确划分。然而，无论责任如何分配，数据泄露的最终法律责任始终由作为数据所有者的云客户承担。

责任划分的核心原则

上一节概述了责任共担的基本概念，本节中我们来看看其核心原则。

客户需要理解，即使数据泄露是由于云提供商的疏忽或恶意行为导致的，客户作为数据所有者，仍需承担最终的法律责任。

尽管如此，提供商和客户仍需通过合同或服务等级协议明确界定各自的具体责任和义务。这种划分在很大程度上取决于客户向云服务提供商购买的服务模型和部署模型。

双方的核心关切点

理解了责任划分的原则后，我们来看看云提供商和客户各自最关心的问题。以下是双方关注点的对比：

  • 云客户的核心关切：客户最关心其数据和生产环境。云数据中心的生产环境是客户的生命线。数据泄露、服务故障和可用性缺失是对客户影响最大的事情。因此，客户会寻求对其数据的最大控制权，并希望获得尽可能多的数据中心运营管理权限和洞察力。客户希望实施自己的安全策略。
  • 云提供商的核心关切：提供商最关心基础设施的稳定运行。他们的核心任务是确保云平台的可用性、完整性和保密性。因此，提供商倾向于保留对底层基础设施的完全控制权，并限制客户对硬件和核心虚拟化层的访问与管理权限。

影响因素：服务与部署模型

责任的具体划分会受到服务模型和部署模型的直接影响。

  • 服务模型：例如基础设施即服务、平台即服务或软件即服务。模型层级越高，提供商管理的部分越多，客户的责任范围相应变化。
  • 部署模型：例如私有云、公有云、社区云或混合云。不同的部署模型在资源隔离、管理控制和安全责任上有所不同。

总结

本节课中，我们一起学习了云安全责任共担模型的关键内容。我们明确了云客户始终是数据安全的最终法律责任方，同时了解了提供商与客户基于合同划分具体职责的实践。双方的核心关切点（客户重数据，提供商重基础设施）以及服务与部署模型，共同决定了风险与责任的具体分配格局。掌握这些概念对于在CCSP考试中取得好成绩至关重要。

025：灾难恢复与业务连续性管理 🛡️

在本节课中，我们将学习CCSP认证中“云平台与基础设施安全”领域的一个重要组成部分：灾难恢复与业务连续性管理。我们将明确两者的区别，探讨核心概念，并了解在云环境中实施相关计划的策略与步骤。

概述

业务连续性管理与灾难恢复常被混淆或交替使用。作为安全专业人员，必须确保使用正确的术语并强调它们之间的区别。

业务连续性管理与灾难恢复的定义

上一节我们介绍了课程主题，本节中我们来看看这两个核心概念的具体定义。

  • 业务连续性：这是一个主动的过程，作为整体风险管理的一部分，定期审查和管理对服务、业务功能和组织持续可用性构成的风险与威胁。其目标是在发生中断时，保持业务运营和功能。
  • 灾难恢复：这是一个过程，旨在制定合适的计划和措施，以确保在发生灾难（如洪水、风暴、网络攻击等）时，企业能够做出适当响应，以尽可能短的时间恢复关键和基本操作，达到部分或全部的服务水平。其目标是快速建立、重建或恢复受灾难影响的业务领域或要素。

在传统的非云环境中，BC/DR 是一个用于共同描述业务连续性和灾难恢复工作的术语，通常归属于一个BCDR计划。

业务连续性计划的组成部分

理解了基本定义后，我们来看看业务连续性计划的具体构成。一个业务连续性计划包含三个主要功能领域：

以下是业务连续性计划的三个核心组成部分：

  1. 运营连续性计划：用于在从重大中断中恢复期间，将维持组织范围或设施范围基本流程的活动迁移到备用地点。
  2. 业务连续性计划：确保在组织恢复其主站点运营能力的同时，关键业务功能能在备用地点持续运行。其目标是在发生中断时保持业务运营。
  3. 灾难恢复计划：处理中断的影响，以及时恢复运营。这也涉及与备用处理设施、备份和容错相关的技术控制。其目标是在灾难发生后快速恢复受影响的业务领域。

简而言之：

  • 运营连续性 让你到达备用地点，以便继续处理基本功能。
  • 业务连续性 让你在备用地点启动并运行。
  • 灾难恢复 修复主站点的一切，以便你能从备用地点迁回。

云环境中的业务连续性与灾难恢复

如今，业务连续性与灾难恢复功能通常利用云来执行，而非传统的温站、热站或冷站。利用云服务时，有两个关键的成功因素：

以下是确保云中BC/DR成功的关键因素：

  1. 理解责任共担模型：明确你的责任与云提供商的责任。这包括理解任何相互依赖性（如供应链风险）和恢复顺序（即恢复过程中的优先级）。
  2. 明确服务等级协议：SLA应明确规定业务连续性与灾难恢复的哪些组成部分被涵盖，以及涵盖的程度。SLA就像是规则手册和法律合同的结合体，其中规定了服务可用性、安全控制、流程、通信支持等关键业务要素的最低水平，并由双方同意。

云客户应在签署任何表示接受服务运营条款的文件或协议之前，同意并完全满意所有与业务连续性和灾难恢复相关的细节，包括恢复时间、责任等。

云基础设施的某些特性（如快速弹性和按需自助服务）可以根据场景为业务连续性与灾难恢复的实现带来显著优势。例如，它们可以提供可快速部署以执行实际灾难恢复的灵活基础设施。

核心恢复指标

业务连续性与灾难恢复旨在防范数据不可用及其支持的业务流程无法运行的风险。我们通过实现三个主要指标来做到这一点：

以下是定义恢复要求的三个核心指标：

  1. 恢复点目标：帮助确定必须恢复和还原多少信息。另一种理解方式是：公司能承受丢失多少数据？公式表示为：RPO = 可接受的数据丢失量。
  2. 恢复时间目标：从中断到恢复处理的总时间。可以将其视为从RPO恢复到RTO所需的时间，以确保不超过最大可容忍停机时间。公式表示为：RTO = 可接受的恢复时间。
  3. 最大可容忍中断时间：组织在仍能维持使命的情况下可以容忍的最大停机时间。

RPO和RTO应根据每个资源的预期损失以及实现目标的成本与收益来设定。

此外，还应理解两个术语：

  • 平均故障间隔时间：衡量系统特定组件或部件发生故障之间的平均时间。
  • 平均修复时间：衡量修复故障组件或部件所需的平均时间。

业务连续性与灾难恢复规划策略

在制定业务连续性与灾难恢复策略时，需要审视其逻辑顺序。以下是关键的规划组成部分：

以下是制定BC/DR策略时需要考虑的核心组成部分列表：

  1. 位置：策略应解决重要资产的丢失问题，并在多个位置复制这些资产。考虑的位置取决于预期灾难的地理范围。
  2. 数据复制：在不同位置维护所需数据的最新副本。这可以在多个技术层面以不同的粒度完成（例如，块级、文件级、数据库级复制）。
  3. 功能复制：在不同位置重建处理能力。根据要缓解的风险和所选模型，这可能简单如选择额外的部署区域，也可能涉及大量的重新架构。
  4. 事件预期：规划、准备和配置是指导致实际灾难恢复故障转移的工具、功能和流程（如充分的监控）。越早检测到异常，就越容易实现恢复时间目标。
  5. 故障转移事件：故障转移能力本身需要某种形式的负载均衡器，将用户服务请求重定向到适当的服务。这可以是集群管理器、负载均衡设备或DNS操作等技术形式。
  6. 恢复正常：这是灾难恢复的结束。最重要的部分是充分记录经验教训，清理不再需要的资源（包括敏感数据），然后更新计划。这将成为业务连续性与灾难恢复流程的新基线。

业务连续性计划的设计与测试

业务连续性计划与传统实施计划有许多相似之处。两者都需要规划、概述、风险管理方法，并且需要被记录、测试和重新评估。

设计阶段的目标是建立和评估候选架构解决方案、技术备选方案，并充实程序和工作流程。在此阶段，应解决一些BC/DR特有的问题，例如：如何调用BC/DR解决方案？调用故障转移服务的手动或自动程序是什么？故障转移期间业务对服务的使用将受到何种影响？如何测试灾难恢复？需要哪些资源来设置、启动和恢复正常？

计划完成后，必须测试所有部分以验证其在真实事件中的有效性。测试策略应包括明确测试范围和目标。

演练类型

有多种不同类型的演练可以执行。安全专业人员计划进行的最常见演练类型包括：

以下是四种主要的BCP演练类型：

  1. 桌面演练/结构化走查测试：简单且低成本。团队成员开会讨论计划的每个要素和程序，评估有效性并记录改进领域。主要目标是确保所有领域的关键人员都熟悉业务连续性计划。
  2. 走查演练/模拟测试：比桌面演练更复杂。参与者选择一个特定的事件场景，并将业务连续性计划应用于其中。通常包括模拟灾难，所有团队练习他们的训练和判断，并模拟他们的行动。
  3. 功能演练/并行测试：第一种涉及实际将人员调动到其他站点以建立通信并执行业务连续性计划中规定的实际恢复处理的测试类型。目标是确定关键系统是否可以在备用处理站点恢复。
  4. 完全中断/全面测试：最全面和复杂的测试类型。尽可能真实地模拟现实生活中的紧急情况。组织通过在处理站点使用备份媒体处理数据和交易来实施其全部或部分业务连续性计划。

每次演练后，安全专业人员应进行事后报告，记录发现的项目并解决演练中发现的问题。行动项应被跟踪直至解决，并且在适当的情况下，应更新计划。

测试与维护

需要记住的是，业务连续性计划与任何其他安全事件响应计划一样，需要按计划间隔或在发生重大组织或环境变化时进行测试。每个计划都必须经过测试、审查和更新，以确保计划有效，并且人们知道在危机中该做什么。

总结

本节课中，我们一起学习了灾难恢复与业务连续性管理。我们探讨了相关云基础设施特性、业务连续性管理的核心指标（RPO， RTO， WRT， MTD），以及BC/DR的规划因素（如位置、数据复制、功能复制等）。我们还详细讨论了业务连续性计划的设计、演练与评估，包括各种测试类型（桌面演练、走查演练、功能演练、全面测试），最后强调了计划的维护与更新的重要性。

026：软件开发生命周期 (SDLC) 🛡️

在本课程中，我们将学习云应用安全领域的一个核心概念：软件开发生命周期。我们将了解其目的、核心阶段，以及为何在开发初期就融入安全考量至关重要。

在深入学习之前，需要说明：本课程中，所有为CCSP考试必须掌握的重点信息，将使用双星号标注并以不同颜色高亮显示。所有以此颜色高亮的内容都与考试相关。

软件开发生命周期流程旨在帮助开发出成本效益高、高效且高质量的产品。业界已发布多种SDLC模型，它们大多包含相似的阶段。屏幕上展示了几个例子，你可以看到它们之间的相似性。任何软件开发的生命周期都包含一系列相当直观的阶段。

一个公认的事实是：在应用部署后发现的安全问题，其修复成本会呈指数级增长。安全需要在前期就构建进去，而不是在最后才添加。通常，在应用设计阶段就融入安全特性，比在最后为修复漏洞而打补丁要便宜得多。后者通常成本高昂。

例如，你根据选定的模型和特定设计功能购买一套房子。但在施工期间，建筑师认为取消地下室、直接加建一层会更高效。如果你等到房子建成后才审查图纸，修复地下室问题将花费你多得多的钱。而如果在早期、开始打地基之前就提出，问题本可以被轻松解决和纠正。同理，将安全构建到应用中，比在最后试图“外挂”安全来修复问题要便宜得多。

我们学习和实践云安全开发生命周期的真正目的，是为了确保我们使用的云应用从一开始就尽可能安全，免受漏洞和其他可能导致数据泄露的风险影响。云安全软件开发生命周期与其他传统开发生命周期具有相同的基础结构，尽管在处理云环境时需要考虑一些额外因素。

就像数据一样，软件也有一个基于开发和使用阶段的有用生命周期。尽管阶段的名称和数量可能有争议，但它们通常至少包括屏幕上列出的核心阶段。下面我们来逐一分解。

规划与需求分析

这是确定业务和安全需求及标准的阶段。主要重点是识别项目经理和利益相关者，确定功能性和非功能性需求，并在初始设计开始前对其进行定义。识别与项目相关的安全需求和风险也在规划阶段进行，同时还要规划质量保证需求和测试。

定义阶段

在此阶段，我们清晰定义并记录产品需求，以便提交给客户并获得批准。定义阶段专注于识别应用的业务需求，例如会计、数据库或客户关系管理。无论应用的目的如何，在定义阶段彻底梳理业务需求的各个方面及其关联至关重要。我们应尽量避免在此阶段选择任何特定的工具或技术。过早选择的诱惑会导致我们有了一个既定结论（例如“我们将使用X技术”），而不是真正考虑所有可能最佳满足业务需求的可能性。这也是我们细化在需求收集和分析阶段确定的安全需求的地方。

系统设计阶段

系统设计阶段有助于明确硬件和系统要求，并有助于定义整体系统架构。在设计阶段，我们开始开发用户故事，例如用户想要完成什么、如何完成，以及界面将是什么样子、是否需要使用或开发任何API。这也是我们确定将使用何种编程语言（如Python、Visual Basic等）和架构（如REST、SOAP等）的地方。

开发阶段

一旦收到系统设计文档，工作被划分为模块、单元或冲刺，实际的开发就开始了。开发阶段是编写代码的阶段，需考虑先前确定的定义和设计参数。在此阶段可能会对代码片段进行一些测试，以确定在与其他开发周期或冲刺集成之前，代码是否按设计工作。然而，主要的测试将在流程的后期进行。

测试阶段

代码开发完成后，将根据已建立的需求进行测试，以确保产品真正解决了在规划和需求分析阶段收集的需求。在应用开发测试阶段，会对应用执行诸如渗透测试和漏洞扫描等活动。我们将使用静态应用安全测试（SAST）和动态应用安全测试（DAST）的技术和工具。SAST 基本上是离线分析未运行时的代码，而 DAST 则针对运行状态下的应用。我们将在本课程后面的软件安全测试模块中更详细地讨论这一点。

集成与安全运维阶段

一旦所有其他阶段完成，应用将进入所谓的集成与安全运维阶段。这是在成功完成全面测试、并且应用及其环境被认为安全之后。大多数SDLC模型将维护阶段作为其终点。在我们的模型中，我们将其单独列为下一阶段。但需要理解，集成、运维和维护可能同时发生。

运维和处置在一些模型中被包含，作为进一步细分传统上发生在维护阶段的活动的一种方式。大多数Web和云应用与传统应用略有不同，因为它们通常可以持续地就地更新，并且可能服务非常长的时间。只要供应商和应用仍然是一个可行的解决方案，它们可能会作为SDLC运维和维护阶段的一部分，保持打补丁和更新。一个例外情况是，供应商创建的应用包含了现有技术或库，并且当这些技术的新版本、更安全的版本发布时，供应商没有更新应用。软件会因此变旧，并且由于技术演进通常带来的巨大跨越，升级变得困难。

将新应用与现有应用集成可能是开发过程的一部分。然而，当开发人员和运维资源对支持组件和服务没有开放或无限制的访问权限时，集成会变得复杂，特别是在云提供商管理基础设施、应用和集成平台的情况下（例如在SaaS模型中）。从安全角度来看，一旦应用使用SDLC原则实施完成，应用就进入了安全运维阶段。

正确的软件配置管理和版本控制对应用安全至关重要。有一些工具可用于确保软件根据指定要求进行配置。其中两个工具是名为 Chef 和 Puppet 的程序。Chef专为云自动化设计，而Puppet技术或工具则专为简化而设计。我们来分解一下：

以下是配置管理工具 Chef 的主要功能：

  • 应用部署
  • 基础设施配置
  • 网络配置管理

Chef 是一种配置管理工具，它提供了一种将基础设施资源定义为代码的方式。用户可以通过代码管理基础设施，而不是使用手动流程。

以下是配置管理工具 Puppet 的主要功能：

  • 使用Puppet DevOps工具动态扩展和缩减机器。
  • 通过持续检查和确认主机上所需配置的状态，为每个主机定义不同的配置。
  • 提供对所有机器的集中控制，以便对配置所做的任何更改都可以轻松传播到所有相关机器。

Puppet 也是一种配置管理工具，可用于配置、部署和管理服务器。

安全运维阶段要求进行动态分析、漏洞评估和渗透测试等活动，作为持续监控计划的一部分。活动监控和一些OSI第7层防火墙（也称为Web应用防火墙，因为OSI第7层是应用层）也属于此阶段。

需要指出，处置阶段并未包含在CCSP通用知识体系（CBK）中，但值得在此提及。一旦软件完成其工作或被更新、不同的应用取代，就必须对其进行安全处置。大多数软件公司都有公布的软件生命周期，作为其面向客户信息的一部分，其中包括应用的生命周期，具体说明诸如为客户提供安全补丁的时长和种类等事项。过时且不再受支持的软件在许多方面对企业构成风险，主要是由于供应商在公布的寿命终止日期之后，停止了对任何新发现漏洞的支持或补丁开发。这就是为什么寿命终止的应用应该被处置，并由接管其功能的应用替换。当一个应用已完成其使命且不再需要时，我们需要以安全的方式处置它及其生成的数据。

从云的角度来看，确保数据被妥善处置具有挑战性，因为你无法物理移除驱动器。因此，我们需要实施 加密粉碎。其过程如下：

  1. 使用加密引擎对数据进行加密。
  2. 使用不同的加密引擎对加密密钥进行加密。
  3. 最终销毁那些密钥，使得最初加密的任何数据都无法恢复。

总结 📝

在本课程中，我们讨论了云安全开发生命周期。软件开发生命周期的核心阶段包括：规划与需求分析、定义、设计、开发、测试、集成与运维、以及最终的处置。我们还讨论了在云中处置任何数据的正确方法是通过加密粉碎。

027：软件测试 🔍

在本节课中，我们将学习CCSP认证“云应用安全”领域的一个重要组成部分——软件测试。我们将探讨相关的国际标准、测试框架、不同类型的测试方法以及具体的测试流程。课程内容将严格遵循考试要求，所有考试重点信息将用加粗标出。

概述 📋

软件测试是确保云应用安全的关键环节。本节课程将系统介绍软件测试的国际标准、核心框架、不同测试类型（如静态测试、动态测试）以及完整的渗透测试方法论。掌握这些知识，对于构建安全的云应用和通过CCSP考试至关重要。

ISO/IEC 27034-1 标准

首先，我们来看一个重要的国际标准。国际标准化组织（ISO）和国际电工委员会（IEC）共同制定并发布了 ISO/IEC 27034-1，即“信息技术安全技术-应用安全”。该标准定义了相关概念、框架和流程，旨在帮助组织将安全集成到其软件开发生命周期中。考生需记住，ISO 27034-1为应用安全的所有组件制定了一个框架。

该标准提出了组织规范性框架（ONF），作为应用安全最佳实践所有组件的框架。ONF包含以下部分：

  • 业务上下文：包括组织采用的所有应用安全策略、标准和最佳实践。
  • 法规上下文：包括所有影响应用安全的标准、法律和法规。
  • 技术上下文：包括适用且可用的技术。
  • 规范：记录组织的IT功能需求，以及解决这些需求的合适方案。
  • 角色、职责和资格：记录组织中与IT应用相关的参与者、与应用安全相关的流程。
  • 应用安全控制库：包含基于已识别威胁、上下文和目标信任级别，保护应用所需的已批准控制措施。

应用规范性框架（ANF）

上一节我们介绍了组织级的框架（ONF），本节中我们来看看针对具体应用的框架。应用规范性框架（ANF） 与组织规范性框架（ONF）结合使用，并为特定应用创建。ANF维护了ONF中适用于特定应用的部分，以使该应用达到所需的安全级别或目标信任级别。

ONF与ANF是一对多的关系，即一个组织规范性框架（ONF）将作为基础，用于创建多个应用规范性框架（ANF）。

ISO/IEC 27034-1定义了一个应用安全管理过程（ASMP） 来管理和维护每个应用规范性框架（ANF）。ASMP包含五个步骤：

  1. 指定应用需求和环境。
  2. 评估应用安全风险。
  3. 创建和维护应用规范性框架（ANF）。
  4. 配置和运行应用。
  5. 审计应用的安全性。

应用安全测试类型

在了解了管理框架后，我们进入具体的测试技术。通过测试软件对Web应用进行安全测试，通常分为两种截然不同的类型：静态测试和动态测试。

首先是静态应用安全测试（SAST）。 这通常被视为一种白盒测试，测试人员在不执行应用程序代码的情况下，对应用程序的源代码、字节码和二进制文件进行分析，以确定可能暗示安全漏洞的编码错误和遗漏。换句话说，静态应用安全测试在代码未运行时离线分析代码。

SAST可用于发现以下问题：

  • 跨站脚本（XSS）错误
  • SQL注入漏洞
  • 缓冲区溢出
  • 未处理的错误条件
  • 潜在的后门

其次是动态应用安全测试（DAST）。 这通常被视为一种黑盒测试，工具用于发现被分析应用程序中的各个执行路径，这意味着该工具是在应用程序运行状态下对其进行测试。理解SAST和DAST扮演不同角色，且一方并不优于另一方，这一点很重要。 静态和动态应用测试协同工作，以增强组织创建和使用的应用程序的安全可靠性。

测试本质上是动态的。 在动态测试中，我们测试系统并观察其行为。相比之下，静态测试技术则在不执行被测系统的情况下对其进行分析。

运行时应用自我保护（RASP） 通常被认为侧重于那些在其运行时环境中内置了自我保护能力的应用程序。这些能力对应用逻辑、配置以及数据和事件流有完全的洞察力。运行时应用自我保护通过自我保护和自动重新配置（无需人工干预）来防止攻击，以响应某些条件（如威胁、故障等）。

渗透测试方法论

除了自动化的SAST和DAST，模拟真实攻击的渗透测试是另一项关键评估手段。渗透测试的主要目标是模拟对系统或网络的攻击，以评估环境的风险状况。 成功渗透测试的关键在于明确的目标、范围、既定目标、商定的限制和可接受的活动。换句话说，就是建立完善的“交战规则”。

渗透测试的方法论有多种，但以下是一个已成为最佳实践的基本逻辑流程：

以下是执行渗透测试的基本步骤：

  1. 规划：在开始任何操作之前，必须先进行规划。例如，确定目标、制定攻击策略、目标和退出策略等。
  2. 侦察：规划好策略后，我们执行侦察。即搜索目标上任何可用的相关信息，以协助你规划或执行测试。目标是收集尽可能多的目标信息。侦察的一部分是扫描和枚举（也称为网络或漏洞发现）。这是从目标系统、应用程序和网络直接获取信息的过程。枚举阶段是渗透测试项目中被动攻击和主动攻击界限开始模糊的点。
  3. 漏洞分析与评估：在此阶段，我们分析数据以确定可能被利用并成功攻击目标的潜在漏洞。我们寻找系统、网络和应用程序之间可能导致可利用暴露的关系。
  4. 执行与利用：完成漏洞分析和评估后，我们进入执行和利用阶段。测试通常被分解为多个执行线程或测试场景组。在这里，我们利用发现的任何漏洞。
  5. 报告与记录：在测试过程中，我们收集并生成可用于得出结论和阐明发现的信息。此处的目标是清晰地呈现发现、使用的战术、采用的工具，并对测试收集的信息进行分析。这些报告必须受到严格保护，因为它们包含的信息非常敏感。

文档和分析报告应包括：

  • 目标系统中发现的漏洞
  • 安全措施中的差距
  • 入侵检测和响应能力
  • 日志活动和分析的观察结果
  • 建议的应对措施

漏洞测试（或评估）与渗透测试的主要区别在于： 在漏洞测试中，你执行除“执行与利用”外的所有步骤；而在渗透测试中，你执行包括“执行与利用”在内的所有步骤。考生需记住这一点。

其他安全评估与保证措施

完成渗透测试的讲解后，我们来看其他几种确保代码安全的方法。执行安全代码审查是评估代码是否具备适当安全控制的另一种方法。这些审查可以非正式或正式进行。

  • 非正式代码审查可能涉及一个或多个人检查代码部分，寻找漏洞。
  • 正式代码审查可能涉及使用经过培训的审查员团队，他们在审查过程中被分配特定角色，并使用跟踪系统来报告发现的漏洞。

由于在云中运行应用程序与传统基础设施存在显著差异，因此使用保证和验证技术（如软件保证、验证和确认）来解决应用程序的安全问题非常重要。

  • 软件保证：包含为确保软件按预期运行而开发和实施的方法和流程，同时减轻可能给最终用户带来伤害的漏洞、恶意代码或缺陷的风险。
  • 验证和确认：应在软件开发生命周期的每个阶段执行，并与变更管理组件保持一致。作为流程的一部分，你应该验证需求是否被指定且可衡量，测试计划和文档是否全面并始终应用于所有模块、子系统，并与最终产品集成。这两个概念都可以应用于企业内部的代码开发，以及外部采购的应用程序接口和服务。

OWASP测试建议

最后，我们参考一个广泛使用的实践指南。开放式Web应用程序安全项目（OWASP） 创建了一个测试指南，推荐了九种主动安全测试类别，我们在此列出以供参考（仅作信息用途）：

  1. 身份管理测试
  2. 身份验证测试
  3. 授权测试
  4. 会话管理测试
  5. 输入验证测试
  6. 错误处理测试
  7. 弱加密技术测试
  8. 业务逻辑测试
  9. 客户端测试

这些OWASP类别在云环境中与传统基础设施中同样适用。然而，与你选择的部署模型（如公有、私有或混合）相关的额外威胁模型可能会引入需要分析的新威胁向量。

总结 🎯

本节课中我们一起学习了软件测试的多个核心方面。我们讨论了国际标准 ISO/IEC 27034-1（信息技术安全技术-应用安全），以及应用规范性框架（ANF） 和组织规范性框架（ONF）。我们探讨了应用安全管理过程（ASMP） 和各类应用安全测试，包括静态应用安全测试（SAST）、动态应用安全测试（DAST） 和运行时应用自我保护（RASP）。我们还讲解了漏洞评估与渗透测试的区别，并详细介绍了渗透测试的方法论步骤：规划、侦察、漏洞分析与评估、执行与利用、报告与记录。此外，我们也涵盖了安全代码审查（正式与非正式）、软件保证与验证确认，以及开放式Web应用程序安全项目（OWASP） 的测试建议。掌握这些知识，将帮助你更全面地理解和实施云环境下的应用程序安全测试。

028：云服务应用架构要素 🔐

在本节课中，我们将学习CCSP认证中云应用安全领域的核心内容，重点探讨云服务的应用架构要素。我们将了解多租户环境下的风险、数据加密选项以及沙箱技术等关键概念。

概述

作为CCSP认证云应用安全领域的一部分，我们来深入了解云服务的一些应用架构要素。在开始之前，需要指出，所有以双星号标注并高亮显示的内容，都是CCSP考试必须掌握的重点信息。

多租户环境与数据隔离风险

在传统的企业环境中，所有基础设施和资源都由组织拥有和控制，不存在其他租户（包括组织的竞争对手）通过应用程序、操作系统、客户镜像和用户之间的无意数据泄露来访问组织数据的风险。

云环境的情况则完全相反，因为云采用了多租户架构。例如，一台典型的主机可以根据其CPU、内存和存储容量支持众多虚拟租户。

因此，所有这些可能性都存在。所以，必须通过大量使用对策来解决应用程序、操作系统、客户镜像和用户之间每个无意数据泄露的风险。这些对策需要确保访问控制、进程隔离，并阻止客户机或主机逃逸尝试。

通常，对策的实施将依赖于某种形式的远程管理，并且很可能需要与云服务提供商进行大量的协商与合作。

应用接口与风险管理

云操作的一个吸引人之处在于能够以新颖的方式灵活使用现有数据。这种能力通过部署各种各样的应用接口来提供和增强，其中许多接口可以由云客户选择，甚至在“自带设备”环境中，用户可以在自己的平台或设备上选择更多接口。

尽管选择多样很诱人，但它也带来了一些风险，因为提供此功能的API可能来源可疑。云客户的最佳利益是制定一个正式的策略和流程，用于审查、选择和部署那些可以通过某种方式验证的API。必须建立一种确定来源和软件本身可信度的方法，并将其作为策略或程序的一部分，纳入变更管理计划中。

本地应用云迁移的挑战

除了变更管理，本地应用（通常被称为“on-premise”应用）通常设计在快速的本地环境中运行，数据在本地访问、处理和存储。将这些应用迁移到云端并不总是可行，甚至可能不切实际。

遇到的问题可能很简单，比如需要回连企业网络，这会减慢应用程序速度；也可能很复杂，比如某些代码无法在某些基于云的Web平台上有效运行，因为它们是为本地环境设计的。

然而，一些应用程序，特别是数据库应用程序，在云中可能运行得更好。通常，云存储比老式企业机械硬盘更快，并且数据到达计算和存储组件的传输距离通常更短，因为它们都存储在同一逻辑单元中。

问题在于，并非所有应用都为云环境做好了准备。通常，必须重新评估和修改代码，以便在云中有效运行。可能需要使用过去未曾用过的加密技术，并且存在一系列其他问题。即使某些应用最终能在云中成功运行，它们也并非总是立即可用，可能需要更改代码或配置才能有效工作。

数据传输加密

在使用基于云的系统时，重要的是要记住它们是在可信和不可信网络（也称为半可信和敌对环境）内部和之间运行的。因此，在云中运行的系统和服务之间以及与之通信的数据应该被加密。

以下是更多数据传输加密选项的例子：

  • 传输层安全：TLS是一种协议，可确保互联网上通信的应用程序及其用户之间的隐私。当服务器和客户端通信时，TLS确保第三方无法窃听或篡改任何消息。TLS是安全套接层SSL的继任者。
  • 安全套接层：SSL是用于在Web服务器和浏览器之间建立加密链接的标准安全技术。此链接确保在Web服务器和浏览器之间传递的所有数据保持私密和完整。
  • 虚拟专用网：VPN，也称为IPSec网关，是一种使用公共线路（通常是互联网）连接到专用网络（如公司内部网络）而构建的网络。有许多系统使您能够创建使用互联网作为数据传输媒介的网络。

数据安全技术与控制措施

请记住，在企业中提供和保护机密服务时，使用密码学和加密的需求是普遍的。重要的是要了解您可能需要部署或使用的相关数据安全技术，以确保云中数据的机密性、完整性和可用性。

潜在的控制措施和解决方案包括：

  • 加密：用于防止未经授权的数据查看。
  • 数据防泄露：DLP用于审计和防止未经授权的数据外泄。
  • 文件和数据库访问监控：用于检测对存储在文件和数据库中的数据的未经授权访问。
  • 混淆、匿名化、令牌化和掩码：这些是不使用加密保护数据的不同替代方案。它是用随机字符或数据隐藏原始数据的过程。

诸如令牌化、数据掩码和沙箱化等技术和方法对于增强加密解决方案的实施非常有价值。

沙箱技术

沙箱化是一种软件虚拟化形式，它允许程序和进程在它们自己隔离的环境中运行。在云计算领域，沙箱化指的是在一个严格控制的环境中，利用一个受保护区域来测试未经测试或不可信的代码，或者通过执行和观察文件行为来更好地了解应用程序是否按预期方式工作，以发现恶意活动的迹象。

这些沙箱通常是内存中的受保护区域，不允许任何类型的进程在环境外运行，也不允许其他应用程序或进程从外部访问。换句话说，沙箱隔离并仅使用预期的组件，同时与其余组件保持适当的分离，例如能够将个人信息存储在一个沙箱中，而将公司信息存储在另一个沙箱中。

如今，许多开发人员会专门租用此类云平台进行测试，因为该模型基于计量使用、按使用付费，开发人员只需在使用时付费。一旦应用程序开发完成，他们可以关闭服务并停止付费。

一些供应商已经开始提供基于云的沙箱环境，组织可以利用这些环境来全面测试应用程序。您还应该知道，由于在沙箱内运行的程序对您的文件和系统的访问权限有限，它无法进行任何永久性更改。这意味着沙箱中发生的一切都留在沙箱中。

沙箱化也是传统基于签名的恶意软件防御的替代方案，被视为发现零日恶意软件和隐蔽攻击的一种方式。特别是，较新的浏览器实现了沙箱化和更强的ActiveX控制，以帮助缓解ActiveX漏洞。因此，如果它是经过签名的证书，它可以做任何它想做的事情；如果它没有签名，它就会留在沙箱中。

总结

在本节课中，我们一起学习了云服务应用架构的关键要素。我们探讨了多租户环境下的数据隔离风险、应用接口的管理、本地应用云迁移的挑战，并详细介绍了数据传输加密的多种选项（如TLS、SSL、VPN）。最后，我们了解了沙箱技术作为一种重要的安全隔离和测试手段。掌握这些要素对于设计和维护安全的云应用至关重要。

CCSP认证课程：05：云环境中的审计

在本节课中，我们将学习CCSP认证“云应用安全”领域的一个重要部分：云环境中的审计。我们将探讨审计的挑战、关键框架、内部与外部审计的角色，以及服务组织控制报告的类型和用途。

在深入课程之前，请注意，我会使用双星号标注来突出CCSP考试中你必须掌握的特定信息。屏幕上所有以该颜色高亮显示的内容都与考试相关。

云审计的挑战与基础框架

审计云环境是一项极具挑战性的任务。云安全联盟开发了云控制矩阵，旨在根据控制措施，对相关领域、控制项及其影响的组件进行列表和分类。

CCM是识别和列举各项控制措施及其潜在影响的宝贵资源。在CCM表格中，还为每项控制提供了最佳实践指南，并将CCM与多个框架和标准进行了映射，例如：

  • ISO 27001
  • NIST 800-53
  • COBIT
  • CSA可信云倡议

CCM及合适的框架应构成任何云战略、风险审查或基于合规性评估的基础。

内部审计：组织的第三道防线

随着组织将服务迁移到云端，云客户和提供商都需要持续保证控制措施已到位或正在识别中。组织的内部审计在业务职能和风险管理职能之后，充当第三道防线。

内部审计职能可以与利益相关者互动，以云视角审查当前的风险框架，协助制定高风险缓解策略，并执行多种云审计，例如：

  • 组织当前的云治理计划
  • 数据分类治理
  • 影子IT（指在组织内部未经明确批准而构建和使用的IT系统与解决方案）

云提供商也会进行内部审计，特别是在部署新服务时，以便在规划云控制设计期间获取客户所需的反馈并降低风险。

外部审计与独立验证

对内部控制进行独立验证的另一个潜在来源是外部审计师执行的审计。外部审计的范围与内部审计有很大不同，外部审计通常侧重于财务报告相关的内部控制。

验证控制和云计划的有效性始终是最佳选择。

服务组织控制报告

《鉴证业务准则公告》是一项法规，定义了服务组织如何使用各种服务组织报告来报告其合规性，这些报告被称为SOC 1、2或3。

自2017年5月1日起，SSAE 16已被SSAE 18取代。你需要记住的是SOC 1、2、3报告的种类，以及类型1和类型2报告的区别及其用途。以下是详细说明：

SOC 1报告
SOC 1审计侧重于描述安全机制以评估其适用性，并报告组织财务报告的内部控制。此项审查依据SSAE 16（现为SSAE 18）进行，它取代了旧的SAS 70。SOC 1报告的国际等效标准是ISAE 3402。

SOC 2报告
SOC 2审计涉及信任服务，并侧重于与保密性、完整性、可用性、安全性和隐私性相关的已实施安全控制。SOC 2报告适用于非财务系统，侧重于组织控制框架（如NIST 800-53、ISO 27001、COSO、ITIL等）在保密性、完整性、可用性、安全性和隐私性方面的实施情况。与SOC 1类似，SOC 2报告也是一项审查，但将控制评估扩展到了AICPA信任服务标准，并且通常是一份限制性报告。

SOC 3报告
SOC 3报告，也称为系统信任、网络信任或服务信任报告，同样涉及信任服务（安全性、可用性、保密性、处理完整性、隐私性），但由独立审计师执行。SOC 2与SOC 3的区别在于：

  • SOC 2报告提供了关于提供所列信任服务的控制措施的非常详细的数据，包括审计师执行的测试描述、测试结果以及审计师对单个控制和系统有效性的意见。此报告不供公众使用。
  • SOC 3报告不包含测试信息和现有控制措施的细节，仅报告系统是否符合已识别的特定信任服务标准的要求，旨在供公众使用。它通常提供一个认证印章，显示在网站上，例如“ISO 27001 Certified”。

报告类型：类型1与类型2

SOC报告有两种类型：

  • 类型1报告：属于时点报告，涵盖控制措施的设计。
  • 类型2报告：属于期间报告，涵盖控制措施的设计和运行有效性。

例如，在SOC 1类型1报告中，你的组织解释并记录系统，会计师向管理层证明控制措施在某个时点有效。在SOC 1类型2报告中，会计师实际上会在一段时间内测试这些控制措施，并向管理层证明控制措施在该时间段内有效运行。

总结

在本节课中，我们一起学习了云环境中的审计。我们讨论了内部审计和外部审计，并指出对云计划有效性进行独立验证始终是最佳实践。我们详细介绍了服务组织控制报告：SOC 1（财务系统）、SOC 2（非财务系统）以及由第三方服务机构执行的SOC 3（也称为系统信任、网络信任或服务信任报告）。我们还探讨了报告的类型：类型1报告（时点报告，涵盖设计）和类型2报告（期间报告，涵盖设计和运行有效性）。

030：物理与逻辑运营 🔐

在本课程中，我们将学习云安全运营与管理领域中的物理与逻辑运营。我们将探讨如何确保云数据中心的高可用性，并深入了解正常运行时间协会（Uptime Institute）制定的数据中心分级标准。这些知识对于理解云服务提供商的运营承诺至关重要。

高可用性与正常运行时间

上一节我们介绍了课程概述，本节中我们来看看云数据中心的核心要求。云数据中心必须足够健壮和有弹性，以抵御各种威胁，包括自然灾害、黑客攻击以及简单的组件故障。这种强度和能力必须全面且详尽，以便为具有广泛服务需求的众多客户提供近乎连续的系统运营和数据访问，这被称为“正常运行时间”。

目前，行业标准的云服务正常运行时间目标是 “五个九”，即 99.999% 的可用性。

公式： 可用性 = 99.999%

这意味着在一年中，计划外停机时间少于六分钟。这一期望通常通过服务等级协议 正式记录，并告知所有用户，以便他们了解系统的可用性。

需要注意的是，“正常运行时间”和“可用性”并非同义词。例如，系统可能处于运行状态但不可用；或者，客户因自身互联网服务提供商 故障而无法连接到数据中心。从客户角度看这是可用性缺失，但从提供商角度看并非正常运行时间缺失。数据中心是正常运行的，只是客户出于实际原因无法访问。通常，“正常运行时间”和“可用性”这两个术语传达的是相同的概念：云提供商在SLA规定的参数内提供服务的能力，且不会无故中断。隐含的理解是，对于超出提供商控制范围的原因导致的客户无法访问，提供商不承担责任。

为了确保系统可用性，重点在于确保所有必需的系统都能按照其SLA的规定保持可用。传统上，系统可用性在SLA中的衡量和记录是使用一个测量矩阵，如下所示。

数据中心冗余设计

为了确保系统可用性，重点必须放在确保所有必需的系统都能按照其SLA的规定保持可用。云基础设施需要为连续正常运行时间而设计和维护。这意味着每个组件都是冗余的。这有两个目的：使基础设施能够抵御组件故障，并允许在不影响云基础设施正常运行时间的情况下更新单个组件。

在设计数据中心时，冗余性不仅需要考虑IT系统和基础设施，还需要考虑支持数据中心运营的所有功能方面。

以下是需要考虑冗余的关键方面列表：

  • 公用事业：电力接收与分配、供水。
  • 通信与连接。
  • 人员配备。
  • 应急能力：主要是发电及其燃料。
  • 人员疏散路径。
  • 暖通空调 系统。
  • 安全控制。

有许多方法可以实现高可用性。一个例子是使用冗余架构元素来保护数据以防故障，例如磁盘镜像或RAID解决方案。另一个针对云环境的特定例子是在云架构中使用多个供应商来提供相同的服务。这允许您构建需要特定可用性级别的系统，使其能够在SLA规定的时间窗口内切换或故障转移到备用提供商的系统。

正常运行时间协会分级标准

目前，ISC² 在追求连续运营方面，参考正常运行时间协会 制定的数据中心冗余标准。Uptime Institute 是一个与IT服务相关事务的咨询组织。它发布数据中心设计标准，并认证数据中心是否符合该标准。

Uptime Institute 的标准分为四个等级，数据中心耐久性逐级递增。

第一级：基础站点基础设施

第一级数据中心设计简单，冗余性很少或没有，被标记为“基础站点基础设施”。它列出了数据中心的最低要求，必须包括：IT系统专用空间、用于线路调节和备份的不同断电源系统、为所有关键设备服务的足够冷却系统，以及用于长时间停电的发电机，并配备至少12小时的燃料以支持发电机在足够负载下运行IT系统。

考试要点： 请记住，12小时是所有四个等级的标准燃料要求。

第一级数据中心还具有以下特征：

  • 计划内维护将需要使系统（包括关键系统）离线。
  • 计划外维护和响应活动也可能使系统（包括关键系统）离线。
  • 不当的人员活动（无论是无意还是恶意）将导致停机。
  • 年度维护对于安全运行数据中心是必要的，并且需要完全关闭（包括关键系统）。没有此维护，数据中心可能会遭受更多的中断和故障。

这种类型的设施可能对仅需要或仅将数据中心服务用作其自身企业和数据的备份的组织有吸引力，甚至可能是组织自己的私有云，并且只需要偶尔且非常临时地可用。从这个角度来看，第一级数据中心可能适合作为组织的热站或温站，数据不频繁上传（例如每周或每月），或者甚至可能作为冷站，仅在组织遇到紧急情况并需要启动应急操作时才上传数据。因此，对于不需要持续正常运行时间和访问资源与数据的组织来说，第一级数据中心可能是成本最低的选择，因为它的功能性最低。

第二级：冗余容量组件站点基础设施

第二级数据中心比第一级稍微健壮一些，以其定义特征命名：冗余站点基础设施容量组件。它具有第一级设计的所有属性，并增加了以下要素：关键运营不必因任何冗余组件的计划更换和维护而中断。但是，配电系统和线路的任何断开都可能导致停机。与第一级类似，不当的人员活动可能导致停机，计划外的组件或系统故障也可能导致停机。

凭借基本的冗余优势，第二级数据中心显然更适合云运营，并且对此目的更具吸引力。它可能仍然比更高级别的产品更经济实惠，但现在可以作为连续使用的可靠替代方案。对于希望在公共云环境中运营同时保持相对较低开销的小型组织来说，这可能是一个不错的选择。

第三级：可并行维护站点基础设施

第三级设计被称为“可并行维护站点基础设施”。顾名思义，该设施既具有第二级构建的冗余容量组件，又具有多分布路径的额外优势，其中在任何给定时间只需要一条路径来服务关键运营。

将第三级与之前级别区分开来的特征包括：

  • 所有IT系统均配备双电源。
  • 即使任何单个组件或电源元件因计划维护或更换而停止服务，关键运营也可以继续。
  • 计划外的组件丢失可能导致停机。
  • 另一方面，单个系统的丢失将导致停机。这里实现的区别在于，组件是多节点系统中的一个节点，虽然每个系统都有冗余组件，但并非所有系统都是冗余的。
  • 包括设施整体年度维护在内的计划维护不一定会导致停机。但是，在此活动期间，停机风险可能会增加。这种暂时的风险升高不会使数据中心在此期间失去其第三级评级。

显然，提供第三级数据中心的云提供商是希望迁移到公共云的组织的可行候选者。大多数具有常规运营需求的组织可能会考虑第三级选项。那些具有特殊需求的组织，例如拥有高度敏感材料的政府机构、大量使用知识产权的实体，或者具有绝对持续正常运行时间要求的大型组织，则可能考虑第四级选项。但对于所有其他组织而言，第三级应该能满足其需求。

第四级：容错站点基础设施

“容错站点基础设施”是顶级数据中心产品。正如Uptime Institute在该等级描述中重复强调的，设施的每个和所有元素和系统，无论是用于IT处理、物理厂房、配电还是其他任何方面，都具有内在的冗余性，使得关键运营能够在任何组件或系统丢失的情况下，经受住计划内和计划外的停机。这是否意味着第四级数据中心坚不可摧，具有永久正常运行时间？当然不是。任何营销此类承诺的人都应受到怀疑。然而，它是最健壮、最具弹性的可用选项。

除了包含所有后续等级的特性外，第四级数据中心还将包括：

  • IT和电气组件的冗余，其中各种多个组件相互独立且在物理上分离。
  • 即使在丢失任何设施基础设施元素后，仍有足够的电力和冷却来支持关键运营。
  • 任何单个系统组件或分布元素的丢失不会影响关键运营。
  • 设施将具备基础设施控制系统的自动响应能力，使得关键运营不会受到基础设施故障的影响。
  • 任何单个丢失事件或人员活动都不会导致关键运营停机。
  • 计划内维护可以在不影响关键运营的情况下进行。然而，当一组资产处于维护状态时，数据中心可能因影响备用资产的事件而面临更高的故障风险。在此临时维护状态下，设施不会失去其第四级评级。

第四级数据中心应该适合服务于任何考虑云迁移的组织，无论其信息资产的敏感性或正常运行时间需求如何。同样，它也将是最昂贵的选择，并且可能仅限于那些有资源负担得起的组织。

总结

在本课程中，我们一起学习了物理与逻辑运营、实现高可用性以及正常运行时间协会的数据中心分级标准。我们详细探讨了四个等级：第一级（基础站点基础设施）、第二级（冗余容量组件站点基础设施）、第三级（可并行维护站点基础设施）和第四级（容错站点基础设施）。理解这些分级有助于评估云服务提供商的基础设施能力和相应的服务承诺。

031：容量监控与维护 🛠️

在本节课中，我们将要学习云安全运营与管理领域中的一个核心部分：容量监控与维护。我们将探讨如何监控数据中心资源、管理环境条件，以及执行系统维护和更新的最佳实践。

容量监控 📊

上一节我们介绍了云安全运营的总体框架，本节中我们来看看如何具体监控数据中心的容量。对于数据中心运营商而言，了解硬件、软件和网络的利用率以及资源需求至关重要。这些信息有助于运营商更好地平衡和分配资源，以满足客户需求并确保符合服务级别协议。

当我们谈论监控时，主要关注的是软件、硬件和网络组件。这些组件需要实时评估，以便了解哪些系统可能接近容量使用极限，从而使组织在问题出现时能够尽快响应。

以下是几种关键的监控类型：

  • 操作系统日志记录：大多数操作系统都具备用于监控性能和事件的基本工具集。云供应商可以设置操作系统日志，当使用率接近可能影响服务级别协议参数的容量利用率或性能下降水平时，向管理员发出警报。监控指标包括：

    • CPU使用率
    • 内存使用率
    • 磁盘空间（虚拟或物理）
    • 磁盘输入/输出时序（这是磁盘读写速度的指标）

  • 硬件监控：与操作系统类似，许多供应商在常见设备构建中包含了性能监控工具。这些工具可用于测量CPU温度、风扇速度、电压、功耗和吞吐量、CPU负载和时钟速度以及驱动器温度等性能指标。如果制造商设备本身不具备此功能，也可以使用商业产品来收集和提供这些数据并发出警报。

  • 网络监控：除了操作系统和设备本身，各种网络元素也需要被监控，这不仅包括硬件和软件，还包括布线、软件定义网络控制平面等分发层面。供应商应确保当前容量满足客户需求并能应对增长的需求，以保证云计算的灵活性和可扩展性特质，同时避免网络过载或产生不可接受的延迟。

与所有日志数据一样，性能监控信息可以输入到安全信息和事件管理（SIEM）、安全事件管理（SEM）或安全信息管理（SIM）系统中，进行集中分析和审查。

环境条件监控 🌡️

除了硬件和软件，监控数据中心内的环境条件也很重要。特别是温度和湿度，是优化运营和性能的关键数据点。

那么，温度和湿度在影响设备性能方面扮演什么角色呢？可以这样理解：环境温度过高可能导致设备过热。高容量电气组件会产生大量废热，设备可能对超出其运行参数的条件敏感。而环境温度过低则可能对健康和安全构成风险，接触冰点以下的裸露金属会灼伤或损伤皮肤。此外，在此条件下工作的人员会感到不适和不快，这可能导致不满情绪，进而引发安全风险。

环境湿度过高会促进金属部件的腐蚀，以及霉菌和其他生物的生长。湿度过低则会增加静电放电的可能性，这可能影响人员和设备，并增加火灾风险。

重要的是要获取数据中心内温度的真实情况，例如可以通过对遍布气流过程中的多个恒温设备的测量值进行平均来实现。虽然有许多具体而详细的建议，但美国采暖、制冷与空调工程师学会（ASHRAE）为数据中心推荐的一般范围是：

  • 温度：64 至 81 华氏度（即 18 至 27 摄氏度）
  • 湿度：露点 42 至 59 华氏度（即 5.5 至 15 摄氏度），相对湿度 60%

考试须知：您需要记住这些数值。在考试中，题目会同时显示华氏度和摄氏度，并且数值会四舍五入到最接近的整数。

虽然这些范围给出了数据中心内部环境条件的一般概念，但ASHRAE的指南对于基于设备类型、使用年限和位置的具体范围要详细得多。这些范围指的是IT设备进气口的温度。温度可以在数据中心的多个位置进行控制，例如：服务器进风口、服务器出风口、地板送风砖供应温度、暖通空调（HVAC）机组回风温度，当然还有机房空调（CRAC）机组供应温度。考试时请记住温度和湿度的推荐运行范围。

空气管理 💨

空气管理是供应给设备的冷空气与设备排出的热空气之间的平衡。有效的空气管理实施可以最大限度地减少冷却空气绕过机架进气口的情况，以及热废气再循环回机架进气口的情况。

为什么这很重要？因为空气管理系统可以降低运营成本、减少初期设备投资、提高数据中心的功率密度（瓦特/平方英尺），并减少与热量相关的中断或故障。

当我们谈论线缆管理时，持续的线缆管理是有效空气管理的关键组成部分。例如，实施线缆清理计划（作为持续线缆管理计划的一部分，移除废弃或无法操作的线缆）将有助于优化数据中心冷却系统的气流输送性能。

热点可能由于地板下或上方的障碍物（这些障碍物经常干扰冷却空气的分布）以及高架地板静压层中的线缆拥堵（这会急剧减少总气流，并降低通过穿孔地板砖的气流分布质量）而发生。您还应该知道，高架地板安装应提供最低 24 英寸的有效净空高度。考试时请记住，高架地板的最低要求是 24 英寸。

气流管理的另一个重要领域是通道隔离与遏制。顾名思义，数据中心设备按机架行排列，机架之间交替设置冷通道（机架进气侧）和热通道（机架热排气侧）。严格的热通道/冷通道配置可以显著增加数据中心冷却系统的空气侧冷却能力，如下图所示。这里要记住的主要一点是，隔离热通道和冷通道可以显著提高系统的空气侧冷却能力。

应遵循行业指南，提供足够的HVAC以保护服务器设备。本幻灯片列出了一些基本考虑因素：

  • 了解当地气候将影响HVAC设计需求。
  • 冗余HVAC系统应是整体设计的一部分。
  • HVAC系统应提供空气管理，将冷空气与服务器的热排气分开。
  • 应考虑节能系统。
  • 应提供备用电源，以在系统需要保持运行的时间内运行HVAC系统。
  • 最后，HVAC系统应过滤污染物和灰尘。

维护模式与正常模式 ⚙️

持续的运行时间需要不断维护整体环境。这也包括维护各个组件，无论是按计划进行还是在必要时进行非计划维护。在本课程中，我们主要关注一般维护事项、更新、升级和补丁管理。

数据中心的运行模式可以分为两类：正常模式和维护模式。实际上，从整体来看，数据中心将始终处于维护模式，因为对特定系统和组件的持续维护对于保持连续运行时间是必要的。因此，可以认为云数据中心处于持续的正常模式，而各种独立的系统和设备则持续处于维护模式，以确保不间断运行。这对于第3层和第4层数据中心尤其如此，其冗余组件、线路和系统允许在维护进行的同时，关键操作不受干扰。

因此，让我们从正常模式和维护模式的角度来看待系统和设备。

维护模式用于更新或配置云环境的不同组件。处于维护模式时，客户访问被阻止，警报被禁用，但日志记录仍然启用。考试时请记住，在维护模式下，客户访问被阻止，警报被禁用，但您仍然记录所有活动。 您应按照供应商特定指南和最佳实践进入维护模式、在其中操作，然后成功退出。如果系统在维护期间仍需可用，则在进入维护模式之前，应迁移任何托管的虚拟机或数据。维护模式可应用于数据存储和主机。

服务级别协议应描述IT服务，记录服务级别目标，并规定IT服务提供商和客户的责任。当系统或设备进入维护模式时，数据中心运营商必须确保某些任务成功完成，例如：

  • 防止所有新登录（原因与上一任务相同，我们不希望客户登录到受影响的系统和设备）。
  • 确保登录继续并进行增强日志记录。管理员活动比普通用户活动更强大，因此风险更高。因此，建议以比普通用户更高的速率和详细程度记录管理员操作。维护模式是一项管理功能，因此需要增加日志记录。

在将系统或设备从维护模式移回正常操作之前，重要的是测试其是否具备客户目的所需的所有原始功能、维护是否成功，以及所有活动的适当文档是否完整并已更新。

行业最佳实践包括确保我们遵守所有关于特定产品的供应商指南。事实上，未能遵守供应商规范可能被视为运营商未能提供必要的应有注意。换句话说，这表明我们没有做正确的事。而有记录的遵守供应商指令则可以证明尽职尽责，证明我们做了正确的事。

更新、升级与补丁管理 🔄

除了部署前的配置（也称为变更和配置管理，稍后详细讨论），供应商还会发布持续的维护指令，通常以更新或补丁的形式。这既可以是软件的应用程序包形式，也可以是硬件的固件安装形式。

更新流程应在运营商的治理中正式化，就像所有流程一样，并且它们都应源自某项政策。它至少应包括以下要素：

  • 记录更新是如何、何时以及为何启动的。
  • 如果是供应商发布的，则注明通信的详细信息：日期、更新代码或编号、解释和理由。其中一些可能通过引用包含，例如指向供应商发布更新公告页面的URL。
  • 通过变更管理流程推进更新。所有对设施的修改都应通过变更管理方法进行并记录在案。虽然我们稍后会详细介绍变更管理流程，但需要强调的是，在更新应用于生产环境之前，应将沙箱测试作为变更管理流程的一部分。

在高层次上，我们首先将系统和设备置于维护模式，然后对必要的系统和设备应用更新，注释资产清单以反映更改。之后，我们验证更新，在生产环境中运行测试以确保所有必要的系统和设备都已收到更新。如果有遗漏，则重新安装直到完成。接着，我们验证修改，确保更新的预期效果已生效，并且更新后的系统和设备与生产环境的其余部分正常交互。最后，我们恢复正常操作，恢复常规业务。

升级：在此上下文中，我们以此目的区分更新和升级：更新应用于现有系统和组件，而升级则是用新元素替换旧元素。升级流程在很大程度上应与更新流程类似，包括正式化、治理、变更管理方法、测试等。在升级过程中，需要特别注意记录资产清单中的变更，不仅要添加新元素，还要注释旧元素的移除和安全处置。当然，这意味着安全处置是升级流程中包含而更新流程中没有的一个要素。

补丁是更新的一种，最常与软件关联。我们在这里通过其频率来区分它们。供应商通常会出于对特定需求的即时响应（例如新发现的漏洞）以及常规目的（例如定期修复、添加或增强功能）而发布补丁。补丁管理流程必须以与更新和升级类似的方式正式化，并将其纳入政策等。然而，补丁会带来额外的风险和挑战。屏幕上列出的建议和考虑因素应在管理云数据中心的补丁时予以考虑。

首先看时机：当供应商发布补丁时，所有受影响方都面临二元风险。如果他们未能应用补丁，可能会被视为未能为使用未打补丁产品的客户提供应有的注意。如果他们仓促应用补丁，可能会对生产环境产生不利影响，损害客户的运营能力。当补丁是针对新发现的漏洞发布，并且供应商急于识别缺陷、找到并创建解决方案、发布修复程序并发布补丁时，情况尤其如此。在急于处理问题的过程中，特别是当漏洞被广泛宣传并引起公众关注时，补丁可能会引发其他漏洞，或通过削弱某些互操作性或接口能力而影响其他系统。

数据中心运营商可能会倾向于让业内的其他公司先应用补丁，以便根据竞争对手的经验来确定其效果和结果。这种选择的风险在于，在此期间，补丁本应修复的漏洞可能导致损失或损害，并可能因未能履行尽职调查而被起诉。

实施：补丁可以通过自动化工具或人工手动应用。两种方法都有明显的优点和风险。运营商将不得不决定在一般情况下（即通过政策）以及针对每个具体情况（当补丁发布时，如果情况需要）使用哪种方法。让我们看看每种方法的风险和收益：

  • 自动化：机械化方法比手动方法能更快地向更多目标交付补丁。补丁工具可能还包括报告功能，可以注释哪些目标已收到补丁（与资产清单交叉核对），并具有警报功能，可以在没有能力的人类观察者的情况下通知管理员哪些目标被遗漏。然而，工具可能无法彻底或正常运作，补丁可能被错误应用，或者报告可能不准确或描绘出不完整的画面。
  • 手动：训练有素且经验丰富的人员可能比机械化工具更值得信赖，并且可能理解异常活动何时发生。然而，在云数据中心需要打补丁的元素数量庞大，补丁过程的重复性和枯燥性可能导致即使是经验丰富的管理员也会遗漏一些目标。此外，该过程可能比自动化选项慢得多，并且可能不够彻底。

现在，关于日期：随着补丁在整个环境中推送，实际的时间戳在获取和确认接收时可能成为一个重要且具有误导性的问题。当补丁代理设置为根据内部时钟指定的时间检查补丁，而不同目标的内部时钟设置为不同的时区时（例如，客户地理位置分散的情况），这个问题会更加复杂。在云模式下，由于虚拟化的广泛使用，这个问题更加突出。所有保存为镜像且在当前补丁交付期间未启动的虚拟化实例，只有在下次启动时才会收到补丁。这意味着该过程将持续到所有虚拟机都变为活动状态为止，这可能代表从决定实施补丁到完成之间的相当长一段时间。结果是运营商决定实施补丁的时间与标注100%完成的时间之间存在相对较长的延迟。这反映了运营商流程的不足，特别是在监管机构和法院眼中。

也许最佳的技术是结合每种方法的优点，同时使用手动和自动化方法。手动监督在确定补丁的适用性以及测试补丁在环境中的适用性方面很有价值，而自动化工具可用于传播补丁并确保统一应用。

服务器最佳实践 🛡️

在屏幕上，我们有一些保护云环境中主机服务器的最佳实践建议：

  1. 安全构建：完全遵循操作系统供应商的具体建议，以安全部署其操作系统。
  2. 安全初始配置：这可能意味着许多不同的事情，取决于操作系统供应商、操作环境、业务需求、法规要求、风险评估和风险承受能力以及将在系统上托管的工作负载等多个变量。最佳实践的常见列表包括：
    • 主机加固：从主机中移除所有非必要的服务和软件。
    • 主机打补丁：安装用于创建主机服务器的硬件和软件供应商提供的所有必需补丁。
    • 主机锁定：实施主机特定的安全措施，这些措施因供应商而异。
  3. 安全持续配置维护：这通过多种机制实现，有些是供应商特定的，有些不是。参与以下类型的活动：
    • 对主机、客户操作系统以及在它们上面运行的应用程序工作负载进行补丁管理。
    • 对主机、客户操作系统以及在主机上运行的应用程序工作负载进行定期漏洞评估扫描。
    • 对主机和在其上运行的客户操作系统进行定期渗透测试。

总结 📝

本节课中我们一起学习了云安全运营中的容量监控与维护。我们讨论了如何监控硬件、软件和网络容量，以及环境条件（特别是温度和湿度）的重要性。我们还探讨了空气管理、通道隔离与遏制、HVAC设计考虑因素。接着，我们区分了正常模式和维护模式，并详细说明了更新、升级和补丁管理流程及其相关风险。最后，我们回顾了保护云环境中主机服务器的最佳实践。掌握这些知识对于确保云环境的安全性、可靠性和合规性至关重要。

032：变更与配置管理 🛠️

在本节课中，我们将学习CCSP认证中云安全运营与管理领域的一个重要组成部分：变更管理与配置管理。我们将探讨这两个核心流程如何确保云环境的安全与稳定，并了解它们在组织治理中的关键作用。

概述

变更管理与配置管理是IT服务管理（ITSM）的核心流程，尤其在云环境中至关重要。它们确保所有对系统、网络和服务的修改都经过系统化的规划、审批、实施和审查，从而维持环境的完整性、安全性和合规性。

上一节我们介绍了云安全运营的总体框架，本节中我们来看看其中两个紧密相关的具体流程：变更管理和配置管理。

基线、变更管理与配置管理

配置管理始于建立基线。基线是系统标准状态的准确记录，为后续的变更管理提供了参照依据。

  • 对于变更管理，基线是基于全面详细的资产清单，对网络和系统状态的描绘。
  • 对于配置管理，基线是所有系统的标准构建，从操作系统设置到每个应用程序的配置。

基线应是一张基于所需功能和安全要求的通用网络与系统地图。安全控制措施必须整合到基线中，并详细描述其目的、依赖关系和支撑理由（即我们希望通过每个控制实现什么目标）。

在考虑通过变更管理流程对环境进行修改时，将控制措施纳入基线至关重要。这样，我们在改变任何现有控制集或向环境添加新系统和功能时，就能充分了解风险管理状况，判断是否会因此增加风险，以及是否需要添加补偿性控制来管理新的风险水平。

持续将当前环境与基线进行比较，可以确定所有资产是否都已登记在册，并检测出任何偏离基线的情况。任何此类偏差，无论是有意还是无意、授权还是未授权，都必须记录并审查。这些偏差可能源于有缺陷的补丁管理流程、特定办公室或用户设置的“野”设备、外部攻击者的入侵或管理实践中糟糕的版本控制。

确定原因并进行必要的后续跟进，是分配给变更管理角色人员的职责。基线应始终反映组织的风险偏好，并在安全性与操作功能性之间提供最佳平衡。如果将其用作模板（特别是在配置管理中），那么它覆盖的系统越多，其价值就越大。

确保基线灵活实用，并且例外请求流程及时响应组织及其用户的需求。一个复杂、缓慢的例外流程会导致用户和管理者感到沮丧，进而可能引发未经变更管理权限批准的、未授权的变通方案。

偏差与例外

跟踪例外和偏差除了能确保法规遵从性和安全控制覆盖范围外，还有其他重要用途。

如果收到大量要求偏离基线的、相同或类似功能的例外请求，我们可能需要修改基线本身。如果我们持续收到修改基线元素的请求，那么该基线就没有起到应有的作用。此外，处理例外请求通常比修改基线以纳入新的、额外的安全控制来允许所接受的功能，需要更多的时间和精力。

变更与配置管理流程

与所有流程一样，变更和配置管理流程应在组织的治理中正式化。这项由标准、程序和流程支持的政策应包括以下内容：

以下是变更与配置管理政策应包含的核心要素：

  1. 变更与配置管理委员会（CCMB）的组成。
  2. 流程本身，包括范围、目的和受影响组织。
  3. 文档要求。
  4. 请求例外的说明。
  5. 变更或配置管理任务的分配，例如验证、扫描、分析和偏差通知。
  6. 检测到偏差后的处理流程和执行措施以及相关职责。

变更与配置管理委员会（CCMB）应由组织内所有利益相关方的代表组成。建议的代表包括来自IT、安全、法律、管理、用户组、财务、采购以及人力资源部门的人员。组织认为有用的任何其他参与者当然也可以加入CCMB。

CCMB将负责审查变更、配置和例外请求。委员会将确定变更是否会增强功能和生产力，变更是否有资金支持，变更将带来哪些潜在的安全影响，以及为了使变更成功且合理，在资金、培训、安全控制和人员配备方面可能需要哪些额外措施。

CCMB应足够频繁地召开会议，以免变更和例外请求被过度延迟，导致用户和部门对流程感到沮丧。然而，会议也不应过于频繁，以免为CCMB预留的时间成为负担。参与CCMB的人员都有其他主要职责，参与CCMB会影响他们的生产力。在某些情况下，根据组织情况，CCMB可能临时召开会议，仅在变更和例外请求达到一定阈值时才响应。这可能带来一些风险，因为如果CCMB成员仅临时会面，他们可能会对流程有些生疏。此外，如果CCMB不是定期优先安排的活动，协调这么多不同部门开会可能会很麻烦。

配置管理流程

配置管理流程在组织内，通过产品的生命周期，建立并维护产品、系统或被管理项的完整性。它指的是一种用于评估、协调、批准或否决以及实施构建和维护硬件或软件系统所用工件的变更的规范。

显然，控制变更的最佳方法是制定一个配置管理计划，确保变更仅以商定的方式执行。任何偏离计划的行为都可能改变整个系统的配置，并可能实质上使其作为安全可信系统的任何认证失效。

配置管理的核心目的是消除因存在不同版本工件而带来的混乱和错误。进行变更是为了纠正错误、提供增强功能或反映产品定义的渐进式改进。如果没有一个信息充分的变更管理流程，团队成员可能会无意中使用不同版本的工件；个人可能会在没有适当授权的情况下创建版本；并且可能会无意中使用错误的工件版本。

另一个需要理解的重要领域是软件配置管理。这涉及为软件项目识别配置项、控制这些配置项及其变更，以及记录和报告这些配置项的状态和变更活动。

第一步是识别所做的任何变更。当每个变更都需经过某种类型的文档记录，并且必须由授权个人审查和批准时，控制就发生了。记录和报告是在任何变更过程中，对软件或硬件配置的记述。审计允许对完整的变更进行验证，特别是确保任何变更不会影响已实施的安全策略或保护机制。

成功的变更管理流程需要一套定义明确且制度化的政策和标准，明确规定以下内容：

以下是变更管理政策应清晰定义的内容：

  1. 受变更管理管辖的工件集合。
  2. 工件的命名方式。
  3. 工件如何进入和离开受控集合。
  4. 处于变更管理下的工件如何被允许变更。
  5. 如何提供工件的版本以及在什么条件下可以使用每个版本。
  6. 如何使用变更管理工具来启用和强制执行变更管理。

软件工程研究所（SEI）的能力成熟度模型集成（CMMI）列出了这些实践，作为组织内变更管理能力的关键：

以下是CMMI中变更管理的关键实践：

  1. 识别将置于配置管理之下的配置项、组件和相关工作产品。
  2. 建立并维护一个用于控制工作产品的配置管理和变更管理系统。
  3. 创建用于内部使用和交付给客户的发布基线。
  4. 跟踪配置项的变更请求。
  5. 在配置项的上下文中控制变更。
  6. 建立并维护描述配置项的记录。
  7. 执行配置审计以维护配置基线的完整性。

请记住，配置管理是一个识别和记录硬件组件、软件及相关设置的过程。一个文档齐全的环境通过确保IT资源得到正确部署和管理，为健全的运营管理奠定了基础。

变更管理流程

变更管理结构应在组织政策中详细说明。还应创建用于变更管理流程操作方面的程序。

请记住，变更管理流程的结构应能使您记录以下环节：

以下是变更管理流程的关键环节：

  1. 请求。
  2. 影响评估。
  3. 批准或否决。
  4. 构建与测试。
  5. 通知。
  6. 实施。
  7. 验证。
  8. 版本控制与基线更新。

系统变更的结果应记录在适当的记录中，包括可能已进行的任何系统修改，以及在部署过程中学到的任何经验教训。

您需要理解，任何变更都必须经过配置与变更控制委员会（CCB）的正式提交和批准才能进行。变更管理的目标是响应客户不断变化的业务需求，同时最大化价值并减少事件、中断和返工；响应业务和IT的变更请求，使服务与业务需求保持一致；确保变更被记录和评估；确保已授权的变更以受控的方式被优先排序、计划、测试、实施、记录和审查；确保对配置项的所有变更都记录在配置管理系统中；最终优化整体业务风险。通常，最小化业务风险是正确的，但有时为了潜在利益，有意识地接受风险也是合适的。

一个专注于云的变更管理流程应包括以下政策和程序：

以下是云变更管理流程应包含的内容：

  1. 新基础设施和软件的开发与获取。
  2. 新软件的质量评估以及与既定安全基线的合规性。
  3. 系统变更，包括测试和部署程序。
  4. 应包括对所有变更的充分监督。
  5. 防止未经授权的软件和硬件安装。

配置管理数据库（CMDB）

配置管理数据库（CMDB） 是我们将所有资产（硬件、软件、数据等）整合在一起的地方，包括按照IT基础架构库（ITIL）的建议整合服务管理流程，涵盖库存、配置和IT资产管理。

CMDB能够强大地洞察基础设施当前及不断变化的概况。这可用于确定您的成本效益分析。

总结

本节课中我们一起学习了CCSP云安全运营领域的变更与配置管理。我们探讨了基线的概念及其作为变更参照的重要性，详细分析了偏差与例外的处理方式，并介绍了正式的变更与配置管理委员会（CCMB）的角色与运作流程。我们深入了解了配置管理流程如何维护系统完整性，以及变更管理流程从请求到验证的标准化步骤。最后，我们认识了配置管理数据库（CMDB）作为整合所有资产信息核心库的关键作用。掌握这些流程对于在云环境中实施有效、安全且合规的运营管理至关重要。

033：风险偏好与风险容忍度 🎯

在本课程中，我们将学习云安全运营与管理领域中的核心概念：风险偏好与风险容忍度。理解这两个概念对于制定有效的安全策略和通过CCSP考试至关重要。

在深入探讨之前，请注意，为帮助您备考，所有CCSP考试相关的关键信息将以特殊颜色高亮标出，并用双星号（**）进行强调。

理解风险偏好与风险容忍度

每个涉及风险的决策都包含两个方面：决策带来的潜在收益和与之相关的机会。

例如，银行根据客户的信用评分发放贷款。如果客户信用良好，从贷款利息中获利的机会就大于客户违约的风险。随着违约风险上升，利率也会提高，直到风险过高而无法批准贷款。

企业和个人每天都在做风险决策，决定愿意承担或不愿承担哪些风险。在进行风险容忍度评估时，他们会考虑在潜在风险实际超过机会之前，愿意将风险推进到何种程度。

举例说明：假设你有一栋两层楼的房子。睡前，你会锁好一楼所有的门窗，以降低夜间有人闯入的概率。然后你上楼，可能会打开二楼所有的窗户以获得新鲜空气。有人从二楼窗户闯入的风险存在吗？当然。但发生这种事的风险极低，你愿意接受它，因为新鲜空气的收益大于入侵者从二楼窗户进入的风险。这是一个你愿意承担的可接受风险。

相比之下，一个住平房的人可能不想在夜间开窗，因为从一楼窗户进入更容易。如果他们想开窗，可能需要安装补偿性控制措施，比如在窗户上加装栏杆，以防止入侵者进入。这仍然存在有人剪断栏杆的风险，但这已是你愿意接受的风险水平。

在云中与企业合作也是如此。每个企业根据自身情况，都有其特定的风险偏好和容忍度。有些企业可能愿意将数据分布在全球，而另一些则不然。有些企业受到严格监管，不允许承担某些风险；另一些则可能为了追求更敏捷灵活而愿意在安全上有所妥协。重要的是记住，每个企业都不同，对风险的容忍度也不同，并且这种容忍度会随时间或环境快速变化。

制定策略前的考量

在组织开始制定策略之前，需要权衡迁移到云端的风险是否被其将获得的收益所抵消。

我们首先需要识别利益相关者。这确保我们有合适的人员参与制定风险容忍度的表达。利益相关者可能包括业务部门领导、董事会、投资者和监管机构。这些群体的观点、认知和选择将影响组织接受风险的意愿和能力。

然而，大多数利益相关者不会直接参与制定组织策略。可能会邀请主题专家来解释策略的具体方面、阐述特定威胁、说明切实收益，并解释策略如何应对这些风险。高级管理层必须理解这些草案策略，以便在接纳它们及其蕴含的风险与收益，或根据需要进行修改时，做出明智的决策。

云环境下的关键策略

组织需要适当反映云计算模型的一些策略包括：

  • 信息安全策略
  • 可接受使用策略
  • 数据分类策略
  • 网络策略
  • 互联网安全、密码、反恶意软件策略
  • 软件安全策略
  • 灾难恢复与数据备份策略
  • 远程与第三方访问策略
  • 职责分离策略
  • 事件响应计划
  • 人员安全策略
  • 身份识别与访问管理策略
  • 法律合规策略
  • 加密策略

可能还有其他许多策略。

最终，策略的接受需要高级经理签署策略文件，并由董事会确认批准。策略一旦被正式接受，就必须发布并分发给受其影响的每个人。

云环境下的沟通挑战

在企业环境中，沟通本身已具挑战性。云计算使沟通更加复杂，原因包括：IT管理员可能不在本地、提供商与客户之间存在时区差异，以及提供商可能拥有成千上万的其他客户。

其他可能使沟通复杂化的因素包括：分散的管理团队、时区差异、对云计算模型和概念的理解不足、对业务驱动因素的理解不足，以及对组织风险偏好的理解不足。

云服务提供商与客户的责任

有时，云服务提供商可能无法满足组织的内部策略要求。当这种情况发生时，必须将这些不足纳入考量，并作为任何内部治理流程的一部分进行管理。这将确保任何商定的合同要素或服务水平协议不会违反组织策略，或将组织置于其风险容忍度水平之外的不当风险中。

云客户作为数据所有者，最终负责确保控制措施的有效性。但是，存储数据的安全和风险管理需要客户与提供商之间的合作。

在云计算世界中，云服务提供商从CSP架构的角度负责客户数据的安全和隐私，因为他们控制后端系统。然而，客户作为数据所有者，仍然对任何数据丢失负有最终责任。

如果是在传统的本地部署模型中，企业边界安全（即非军事区、网络分段、入侵检测/防御系统、监控工具及相关安全策略）将控制驻留在边界后并传输的数据。因此，在该示例中，企业将负责安全和隐私，并对任何损失承担责任。

风险管理相关术语

在深入探讨风险管理的细节之前，您需要熟悉一些风险相关术语。

  • 关键风险指标：KRIs是首先提醒您某些方面出现问题的指标。在金融行业，KRI可能是股市在一天内大幅波动。在云计算中，可能是宣布发现可能影响您云客户的新漏洞。核心思想是，您需要识别并密切监控那些最有可能提醒您风险环境发生变化的事项。

  • 风险偏好与风险容忍度：这两个术语相似，都描述了组织如何看待风险。随着组织的风险偏好或容忍度增加，其承担更大风险的意愿也随之增加；反之亦然。

  • 风险所有者与参与者：这些是组织内共同决定组织整体风险概况和偏好的个人。

风险的四种应对策略

风险管理的一部分是知道您想如何处理风险。组织在面对风险时始终有四种选择：风险规避、风险接受、风险缓解和风险转移。

以下是具体分析：

1. 风险规避
风险规避是指确定特定风险的影响或可能性太大，潜在收益无法抵消，并因此决定不执行某项业务功能。基本上，这意味着停止该活动，因为您不想接受其风险。

2. 风险接受
风险接受是指确定业务功能的潜在收益大于可能的风险或影响，并决定在不采取其他行动的情况下执行该功能。这通常是因为预期影响水平较低，是一种明确决定不进行缓解，而是承受风险的决策。这里的权衡是支持该决策的成本效益分析。

3. 风险缓解
风险缓解是通过实施安全控制措施来减弱特定风险的可能影响和/或可能性。这是通过应用控制措施将风险降低到可接受的水平来实现的。

4. 风险转移
风险转移，也称为风险分担，是指支付外部方来承担特定风险的财务影响，基本上是将风险转嫁给另一个实体，如保险公司。但请记住，并非所有风险都能转移。

剩余风险与总风险

剩余风险是在实施安全控制措施以降低或缓解风险后仍然存在的风险。这基本上是在应用适当控制措施来减少或消除漏洞后剩余的风险量。

总风险是如果没有实施任何防护措施，组织将面临的风险量。

您应该了解总风险与剩余风险的公式：

  • 总风险公式：威胁 × 漏洞 × 资产价值 = 总风险
  • 剩余风险公式：总风险 - 控制缺口 = 剩余风险

深入分析风险应对策略

风险规避不是处理风险的方法，而是在面对特定风险时，基于成本效益分析做出的回应。如果组织面临的风险其潜在成本远大于可能收益，组织可能会选择根本不进行会招致该风险的活动。这是消除特定风险的唯一可靠方法：不进行有风险的活动。

风险接受与风险规避直接相反。在检查某项活动的潜在收益和风险后，如果组织确定风险很小而回报可观，组织可能会选择接受该事业所涉及的风险，并在没有任何额外考虑的情况下继续推进该活动。换句话说，如果活动的风险估计在组织的风险偏好范围内，那么组织可能会选择风险接受，就像之前给出的打开二楼窗户的例子。

风险缓解是大多数安全从业者日常工作的核心选项。风险缓解是通过使用控制措施和对策将风险降低到可接受水平的实践。也就是说，组织实施控制措施，以使已知风险处于该组织的风险偏好范围内。

关于风险缓解有两点需要注意：

  1. 不可能完全消除风险。永远不要相信有人说某事零风险或某个控制措施提供100%安全。即使对业务功能应用了所有可能的控制措施，仍然会存在一定水平的风险，我们称之为剩余风险。如果实施控制措施后剩余的剩余风险在组织的风险偏好范围内，那么组织可能会选择执行该功能。如果剩余的剩余风险超过了组织的风险偏好，则说明控制措施不足，或者该业务风险太高而无法执行。
  2. 控制措施的成本必须小于业务流程的潜在收益，否则该流程就不盈利或不值得。永远不要给一辆5美元的自行车装一把10美元的锁。

控制措施的类型

组织在选择缓解风险时，可以考虑并使用不同类型的控制措施。在安全领域，我们通常将控制措施分为三种一般类型：物理控制、技术控制和管理控制。

  • 物理控制：限制对资产的物理访问，或以减少物理事件影响的方式运作的控制措施。
  • 技术控制：也称为逻辑控制。这些是增强机密性、完整性、可用性三要素某些方面的控制措施，通常在系统内以电子方式运作。可能的技术控制包括加密机制、限制用户权限的访问控制列表以及系统活动的审计跟踪和日志。
  • 管理控制：那些不一定属于物理或技术范畴，但能提供某些安全方面的流程和活动。

结合使用不同类型的控制措施是向组织提供深度防御（也称为分层防御）的好方法。这要求恶意行为者不仅要克服多个控制措施，还要克服多种类型的控制措施，从而需要不止一种技能才能访问或获取受保护的资产。

风险转移与责任归属

风险转移是一种处理与活动相关风险而不承担所有风险的方式。通过风险转移，组织找到其他方以承担事业潜在风险，而成本只是组织自己承担风险时潜在成本的一小部分。基本上，当您想到风险转移时，就想到一个词：保险。

并非所有风险都能转移。虽然财务风险很容易通过保险转移，但真正的风险几乎永远无法完全转移。

风险管理框架与责任

存在许多风险管理框架，旨在帮助企业制定健全的风险管理实践。然而，就CCSP考试而言，我们只需要熟悉ISO 31000、NIST SP 800-37和欧盟网络与信息安全局的框架。

一个关键问题是：谁被分配并负责风险？ 这是一个严肃的问题，答案很有趣：视情况而定。

最终，组织，即高级管理层或利益相关者，拥有公司运营期间存在的风险。然而，高级管理层可能依赖业务部门或数据所有者/保管人来协助识别风险，以便进行缓解、转移或规避。组织也可能期望所有者和保管人根据环境中的策略、程序和法规，在工作中最小化或缓解风险。如果期望未得到满足，可能会导致纪律处分、解雇或起诉等后果。

选择与实施对策

对组织而言，最重要的步骤之一是适当地选择应用于环境中风险的对策。必须考虑对策的许多方面，以确保它们适合任务，例如：

  • 问责性：谁可以被追究责任？
  • 可测试性：如何测试？
  • 可信来源：确保我们有已知来源。
  • 独立性：自决、一致应用。
  • 成本效益、可靠性、与其他对策的独立性（避免重叠）。
  • 易用性、自动化、适用性、安全性。
  • 保护资产的CIA：保密性、完整性、可用性。
  • 可回退性：在出现问题时能够撤销。
  • 在运营中不产生额外问题，且在其功能完成后不留下残留数据。

实施与维护

风险评估完成后，会有一系列需要采取的补救活动清单，组织必须确保拥有具备适当能力的人员来实施这些补救活动，并对其进行维护和支持。这可能要求组织为参与环境中安全机制的设计、部署、维护和支持的人员提供额外的培训机会。

此外，至关重要的是，要创建、实施、维护、监控和执行与每个策略项目相对应的、具有详细程序和标准的适当策略。组织应分配可对每项任务负责的资源，并随时间跟踪任务，向高级管理层报告进展，并在此过程中留出时间进行适当的审批。

安全架构师的思考

当安全架构师坐下来开始思考如何设计企业安全架构时，他们应该考虑很多事情：应该使用什么框架作为参考点？需要考虑哪些业务问题？谁是利益相关者？为什么他们只处理这个业务领域而不是那个？如何将系统设计整合到整体架构中？这个架构中的单点故障会在哪里？架构师的挑战在于协调所有这些思路，并将其引导到一个流程中，使他们能够设计出一个连贯且强大的企业安全架构。

风险响应

风险响应根据组织的风险框架，通过制定应对风险的备选行动方案、评估备选行动方案、确定与组织风险容忍度一致的适当行动方案，并基于所选行动方案实施风险响应，从而提供全组织一致的风险响应。

课程总结 🎓

在本课程中，我们一起学习了：

  • 风险偏好与风险容忍度的核心概念及其区别。
  • 云计算对企业风险管理的影响。
  • 风险管理涉及的四种选择：风险规避、风险接受、风险缓解（使用物理、技术和管理控制）以及风险转移。
  • 风险分配、对策的各个方面、风险对策的实施以及风险响应流程。

理解这些概念是构建有效云安全策略和通过CCSP认证的基础。

034：安全培训与意识 🛡️

在本节课中，我们将学习云安全运营与管理领域中的一个核心组成部分：安全培训与意识。我们将探讨培训、教育和意识之间的区别，介绍不同类型的培训计划，并了解相关的风险管理框架。

概述

安全培训与意识是确保组织内所有人员都能以安全方式履行职责的关键。在云数据中心环境中，由于员工通常具备一定的技术背景，这项工作可能相对容易，但仍需正式的培训计划来满足政策和法规要求。

培训、教育与意识

在深入探讨具体培训类型之前，我们需要明确培训、教育和意识这三个概念的区别。以下是CCSP认证中对这些术语的标准解释：

  • 培训：指由组织内部的专家进行的正式材料讲解，内容涵盖组织政策、法规要求以及行业最佳实践。
  • 教育：指在学术环境中进行的正式学习，通常是为了获得学位或认证学分。
  • 意识：指额外的、非正式的（通常是自愿的）材料宣传，目的是提醒员工并提高他们的注意力。

基于以上定义，我们将重点讨论安全培训、教育和意识计划。

培训计划的类型

安全培训计划通常分为三种交付类别：初始培训、定期培训和复习培训。接下来，我们将逐一审视这些类别。

初始培训

初始培训在新员工入职时进行，通常内容全面且详尽。所有人员，无论其职位或角色如何，都必须参加。培训内容应足够广泛，涵盖所有员工需要理解和遵守的安全政策和程序，同时也应具体到让每个人都知道如何执行基本的安全操作。

初始培训可能涵盖的主题包括：

  • 密码政策：包括密码的发放方式、格式、有效期、如何申请重置，以及强调保密的重要性。
  • 物理安全：包括设施访问权限、遇到不熟悉人员时的应对措施，以及紧急疏散程序。
  • 安全凭证或令牌的使用，以及如何报告安全问题（如异常行为、凭证丢失等），包括联系安全人员的方式。
  • 可接受使用政策（也称为“道路规则”），包括详细的执行机制。当然，所有人员在访问组织设施和资产之前必须签署该政策。

初始培训课程是所有员工首次接触安全办公室代表的机会。因此，最好由安全团队成员而非人力资源等其他部门的培训师来主持。培训师应解释安全措施的原因，使用真实世界的案例和轶事，并鼓励互动和提问，以建立积极的关系。

定期培训

定期培训旨在持续更新安全知识，建立在初始培训的基础之上。应根据组织需求、监管环境或行业波动定期进行，至少每年一次。

定期培训的内容应包括：

  • 组织内部安全实践和程序的任何更新和修改。
  • 法规和政策的变化。
  • 基础设施中引入的任何新元素。

定期培训也可以与意识工作相结合，并用于巩固在初始培训中培养的良好关系。最后，务必记录所有定期培训课程，包括内容和所有参与者的姓名，这对于在审计中展示尽职调查和满足合规要求至关重要。

复习培训

复习培训面向那些表现出需要额外指导的人员。这可能包括长时间离开工作岗位（例如一个月左右）或错过了定期培训的人员，也可能包括那些在安全实践方面存在不足的人员，例如无意中造成安全漏洞、安装了恶意软件或在审计中被指出不了解或不遵守正确安全实践的人员。

重要的是要记住，目标是培养运营与安全之间的友好关系，因此这些课程不应具有惩罚性或指责性。应告知参与者，安全失误不是严重过错，而是学习如何改进的机会。与所有培训事项一样，应记录每次复习培训，包括主题和参与者，以备审计和合规之用。

培训交付方式

所有培训都可以通过现场演示或在线课程的形式提供。两种方法各有利弊。

现场培训让参与者与主题专家互动，极具价值。参与者能更好地理解材料，并且如果以他们欣赏和理解的方式呈现，他们更有可能记住信息。然而，安排和记录现场课程存在一些困难，通常需要某种形式的考勤，这在员工规模变化时会变得复杂。

在线课程（基于计算机的培训）是一个极其强大的工具，可以简化安排现场课程的许多麻烦。它允许每位员工在方便的时候，从自己的工作场所（或根据交付方式，甚至从家中）访问材料，并按照自己的节奏学习。然而，这些特点也可能使在线培训容易受到外部干扰，许多员工只是将其视为一项必须完成的任务，而不是关注内容，他们只是快速点击直到结束。不过，在线课程工具通常提供出色的跟踪功能，即使面对较大的用户群体，也能提供细致的文档记录能力。

政策与支持

安全培训的另一个基本方面是政策。如果组织真正重视安全，那么这应该反映在其组织治理中。高级管理层需要支持培训计划，并通过尽可能积极参与现场课程来展示参与度。他们还应该建立并正式制定奖励计划，以表彰那些通过报告发现的安全问题而提供安全见解的员工。在资金充足的情况下，不要对无意中造成安全问题的员工采取惩罚措施。纪律处分应仅用于恶意或犯罪行为。

风险管理框架培训

由于存在许多旨在帮助企业制定健全风险管理实践的风险管理框架，组织应进行与其所遵循框架相关的正式培训。为了CCSP考试的目的，我们将只讨论ISO 31000、NIST SP 800-37和欧盟网络与信息安全局（ENISA）。

ISO 31000

ISO 31000（最后更新于2018年）是一项国际标准，专注于设计、实施和审查风险管理流程和实践。该标准解释说，正确实施风险管理流程可用于创造和保护价值，整合组织程序，成为决策过程的一部分，明确应对不确定性，确保风险管理计划是系统化、结构化和及时的，基于最佳可用信息，根据组织的业务要求和实际风险量身定制，考虑人为和文化因素，确保透明和包容，创建动态、迭代并能响应变化的风险管理计划，并最终促进组织的持续改进和提升。

NIST SP 800-37

美国国家标准与技术研究院（NIST）特别出版物800-37是实施风险管理框架（RMF）的指南。这个特定的风险管理框架是一种以全面、持续的方式处理所有组织风险的方法论。它取代了旧有的、在军事、情报和联邦社区广泛使用的、具有特定持续时间的周期性检查的认证和认可模型。该RMF严重依赖自动化解决方案、风险分析和评估，并根据这些评估实施控制措施，同时进行持续监控和改进。NIST SP 800-37是组织可以用来实施RMF的指南。尽管NIST标准是为联邦政府使用而开发的，但它们已开始在许多领域被接受为最佳实践。例如，美国的公司可能使用NIST模型和出版物来制定其信息安全计划以及风险管理计划和实践。NIST出版物和标准具有双重好处：既被广泛认为是专业和合理的，又是免费的。所有NIST文件都属于公共领域。

将NIST材料从其联邦治理领域的预期用途采纳并调整到私营部门或非营利事业中并不费力。但请注意，这些文件在国际市场上不像ISO/IEC标准那样被普遍接受。因此，如果您在美国境外开展业务，可能需要更详细地研究其他标准。一些海外公司甚至不会与未订阅并通过ISO标准认证的美国公司开展业务。

欧盟网络与信息安全局（ENISA）

您可以将欧盟网络与信息安全局（ENISA）视为欧洲版的NIST。它是在欧洲开发的标准和模型，虽然其性质在欧洲范围内是国际性的，但并未像ISO标准那样在全球范围内被广泛接受。ENISA负责发布云计算的优势、风险和信息安全建议。它识别了35种风险类型，并进一步根据可能性和影响确定了前8大安全风险，分别是：治理权丧失、供应商锁定、隔离故障、合规风险、管理接口故障、数据保护、恶意内部人员以及不安全或不完整的数据删除。

根据ENISA，云认证方案清单（CCSL）概述了可能与云计算客户相关的不同现有认证方案。CCSL还展示了每个认证方案的主要特征。例如，CCSL回答了诸如“基于哪些标准”、“谁颁发认证”、“云服务提供商是否经过审计？如果是，谁审计？”等问题。构成CCSL的方案包括：TÜV Rheinland认证云服务、云安全联盟（CSA）自我评估（也称为STAR Level 1）、CSA鉴证（也称为STAR Level 2）以及CSA持续监控和认证（称为STAR Level 3）。此外，它还列出了UCD自我评估、UCD STAR审计认证、ISO 27001、支付卡行业数据安全标准（PCI DSS）、LEET安全评级指南、AICPA SOC 1、SOC 2和SOC 3报告。

根据ENISA，云认证方案映射框架（CCSM）是CCSL的扩展，它提供了一个中立的、高层次的映射，将客户网络和信息安全需求映射到现有云认证方案中的安全目标，这有助于在采购过程中使用现有的认证方案。

总结

在本节课中，我们一起学习了安全培训与意识。我们明确了培训、教育和意识之间的区别，并详细介绍了初始培训、定期培训和复习培训这三种主要的培训计划类型。我们还探讨了培训的交付方式（现场与在线）、组织政策支持的重要性，以及针对ISO 31000、NIST SP 800-37和ENISA等风险管理框架的培训内容。这些知识对于在云环境中建立有效的安全文化和满足合规要求至关重要。

035：法律概念与合规要求 📚

在本节课中，我们将学习CCSP认证中“云法律风险与合规要求”领域的基础法律概念。这些概念是理解如何在跨国云环境中运营、确保一致性与公平性的基石。作为云安全从业者，掌握这些知识至关重要。

基本法律概念概述 🌍

随着技术的全球化发展，在满足不断演变的立法、法规和法律方面，挑战日益复杂。确保在传统本地环境、第三方托管环境乃至云计算环境中遵守这些规定，难度显著增加。本课程讨论的术语构成了我们进行跨国云活动的基础知识。

以下是本节将涵盖的核心法律概念：

  • 美国三大法律体系：刑法、民法、行政法。
  • 法律渊源：判例法、成文法、法规。
  • 国际冲突法原则：适当法原则与《法律冲突法重述（第二版）》。
  • 知识产权（将在后续模块详述）。
  • 隐私法。

接下来，我们将逐一详细探讨这些术语。

刑法 ⚖️

刑法涉及政府与任何违反成文法的个人、团体或组织之间的所有法律事务。它是一套定义政府所禁止行为、旨在保护公共安全与福祉的规则和法令。刑法不仅定义禁止行为，还规定了违法时的惩罚措施。

  • 成文法：由立法者制定的正式书面法令，用于管理州、市或国家。它通常命令或禁止某些行为，或声明某项政策。例如，交通法规。
  • 犯罪分类：根据严重性分类，不同类别对应不同的最高刑罚。例如，抢劫、盗窃和谋杀。
  • 执法与惩罚：刑法的执行称为起诉，只有政府可以进行。惩罚措施包括罚款、监禁，甚至死刑。

民法与合同法 🤝

上一节我们介绍了刑法，本节中我们来看看民法。民法是处理个人和社区事务（如婚姻、离婚）的法律体系，与刑法相对。它是一套管理私人公民及其纠纷的规则。

  • 诉讼方：民法事务的参与方严格限定为私人实体，包括个人、团体和组织。
  • 典型案例：在美国，涉及财产边界、矿产权和婚姻离婚的纠纷。
  • 惩罚措施：民事案件的惩罚措施包括经济赔偿或要求履行特定行动（通常针对违约），但不包括监禁或死刑。

合同是双方为进行某项特定活动（通常为互利）而达成的协议。云客户与云提供商之间的合同就是一个典型例子。

  • 合同要素：通常包括合同有效期、参与方列表、争议解决方式以及合同所适用的管辖法律。
  • 违约与纠纷：当一方未能履行合同规定的活动时，即构成违约。另一方可以提起诉讼，以获得法院命令的救济，例如金钱赔偿或强制违约方履行义务。

CCSP考生应熟悉以下合同性文件：

  • 服务等级协议
  • 隐私协议
  • 运营等级协议
  • 支付卡行业数据安全标准

合同纠纷通常在民事法院处理，涉及损失赔偿。在云环境中，CCSP应准备好处理与此类合同相关的风险。

州法与联邦法 🏛️

在了解了民法和合同法之后，我们需要区分美国的州法与联邦法。

州法指美国各州的法律。美国共有50个州，每个州都有自己的宪法、政府和法院。

  • 示例：限速法规、州税法、刑法典等。
  • 注意：在美国以外，“state”一词常作为“国家”的同义词，其成员实体可能称为“县”、“管辖区”等。

联邦法管辖整个国家，其管辖权超越州界。

  • 示例：反绑架法、反银行抢劫法。
  • 与州法的关系：联邦法通常优先于州法，特别是在涉及州际商业性质的事务上。然而，有时州法可能更严格（如加利福尼亚州），此时通常适用最严格的法律。管辖权和后续起诉问题通常由执法和司法机构事先协商确定。

侵权法与行政法 ⚠️

侵权法涉及因他人的不当行为而受到伤害的个人所能获得救济的权利、义务和补救措施体系。它主要服务于四个目标：

  1. 赔偿受害者因他人过错行为所受的伤害。
  2. 将伤害成本转移给法律上应负责的人。
  3. 阻止未来的伤害性或疏忽冒险行为。
  4. 维护受到损害的法律权利和利益。

行政法是影响大多数人的另一法律体系。这些法律并非由立法机关创建，而是由行政决策和职能产生。

  • 执行机构：许多联邦机构可以创建、监督和执行自己的行政法。它们拥有专属的立法部门、执法人员、法院和法官。
  • 示例：联邦税法由美国国税局管理，该机构制定法律、通过IRS特工调查和执行，并由其雇员中的律师和法官审理案件。

法律冲突与隐私法 🌐

在跨国云运营中，法律冲突是常见问题。以下是两个关键概念：

《法律冲突法重述（第二版）》：这是一套普通法（法官造法）发展的汇编，用于告知法官和法律界相关领域的更新。它是在美国各州法律规则存在冲突时，决定适用哪部法律的基础。

适当法原则：当发生法律冲突时，此原则根据合同语言中明示的选择或通过法律选择条款所体现的明确意图，来确定在哪个管辖区审理争议。如果没有明示选择，则可能使用默示选择来推断双方意图。

隐私法赋予个人决定何时、如何以及在何种程度上披露其信息的权利。隐私法通常还包括要求在不再需要时销毁个人信息的条款。

  • 示例法律：欧盟《通用数据保护条例》、经济合作与发展组织指南、支付卡行业数据安全标准、《健康保险携带和责任法案》。
  • 管辖权与治外法权：一个国家的法律效力并不止于其边境。如果另一国家的公民或甚至本国公民在境外违反该国法律，仍可能受到该国的起诉和惩罚。例如，黑客可能因攻击他国目标而被引渡至该国受审。

国际法决定了如何解决国家间的争端和管理国家间关系。它由国际公约、国际习惯、文明国家公认的一般法律原则以及司法判例和各国最高权威公法学家的学说组成。

法律、法规、标准与框架的区别 📊

理解这些术语的区别对于合规至关重要。以下是它们的核心区别：

  • 法律：由政府实体（如国会或议会）制定的法律规则。不遵守可能导致罚款或监禁。
  • 法规：由政府其他部门或政府授权的外部实体制定的规则。不遵守同样可能导致惩罚性程序。
  • 标准：由非政府组织制定的框架和指南，供企业遵循。监管机构可能因组织未采用行业公认的最佳实践和标准而认定其存在过失。
  • 框架：一种分层结构，指示可以或应该构建何种程序以及它们如何相互关联以支持信息安全战略和使命。

控制框架由组织建立，用以支持其政策、程序、标准和指南。所有框架都应具备以下共同要素：

  1. 一致性：在信息与隐私的处理和应用上保持一致。
  2. 可衡量性：提供确定进展和设定目标的方式。
  3. 标准化：依赖标准化，使结果可在不同组织或部门间有意义地比较。
  4. 全面性：至少涵盖组织的最低法律和监管要求，并可扩展以适应额外的组织特定要求。
  5. 模块化：仅需审查和更新需要修改的控制或要求。

框架示例：

  • 控制框架：美国国家标准与技术研究院的NIST SP 800-53、ISO/IEC 27001:2013、COSO（内部控制整合框架）、COBIT（企业IT治理与管理框架）。
  • 流程框架：ITIL（IT服务管理）、CMMI（能力成熟度模型集成）、六西格玛。
  • 架构框架：Zachman框架、TOGAF（开放组体系结构框架）、SABSA（业务安全架构）。
  • 安全计划开发框架：ISO/IEC 27000系列（信息安全管理体系）。

请注意，CCSP考试不涵盖特定法律（如FISMA或萨班斯-奥克斯利法案），但涵盖安全控制模型框架，如ISO 27000系列、COBIT和COSO，因为它们是国际标准。

总结 🎯

在本节课中，我们一起学习了CCSP认证所需的基础法律概念，包括：

  • 美国三大法律体系：刑法、民法、行政法。
  • 关键法律渊源：判例法、成文法、法规。
  • 核心法律类型：侵权法、合同法、州法、联邦法、隐私法、国际法。
  • 解决法律冲突的原则：适当法原则与《法律冲突法重述（第二版）》。
  • 法律、法规、标准与框架之间的区别，以及常见的安全与控制框架。

掌握这些概念是理解云环境复杂合规要求、评估法律风险并在全球范围内安全运营云服务的基础。

036：知识产权法律 📚

在本节课中，我们将要学习CCSP认证中“云法律风险与合规要求”领域的一个重要部分：知识产权法律。我们将了解知识产权的不同类型、保护方式以及相关的法律框架。

概述

知识产权是数字时代企业和个人的核心资产。理解其法律保护机制，对于在云环境中确保合规性和降低风险至关重要。本节将系统介绍知识产权的定义、主要类别及相关法律。

知识产权定义与范畴

知识产权是一个法律术语，用于描述由人类智力创造、具有商业价值的无形财产。这包括文字、文学作品、标识、符号或其他艺术创作。

世界知识产权组织将其定义为：具有商业价值的人类智力创造物。

知识产权主要分为两大类：

  • 工业产权：也称为商业产权，包括专利、发明、商标、服务标志、蓝图、商业秘密、工业设计等。
  • 版权：包括文学和艺术作品、现场或录制的表演、作者权利、软件、照片、雕塑等物品。

版权与合理使用原则

上一节我们介绍了知识产权的整体范畴，本节中我们来看看其中最常见的一类：版权。

版权保护的是思想的原创性表达。它授予原创作品创作者专有权利，使创作者能够因其作品获得认可和收益，并通过许可控制他人对其作品的使用。

版权侵权发生在非信息合法所有者的个人或组织，将受版权保护的材料提供或分享给他人时。

在美国，版权的保护期限为原创者去世后70至125年，具体取决于知识产权的创作性质。

合理使用原则是美国版权法中的一项重要限制。它允许在特定限制条件下，无需事先获得版权持有者许可即可复制和分发受版权保护的材料。该原则旨在平衡版权持有者利益与公众更广泛传播和使用创意作品的公共利益。

以下是美国版权法中合理使用的主要情形：

  • 评论
  • 搜索引擎
  • 批评
  • 戏仿
  • 新闻报道
  • 研究
  • 学术活动
  • 学术组织使用版权材料

商标与商业秘密

接下来，我们将探讨另外两种关键的知识产权：商标和商业秘密。

商标用于保护商品或服务的独特身份。它可以是一个词、符号、颜色、声音、形状等。商标本质上是品牌的知识产权保护，用于即时识别品牌，通常包括徽标或简短的音频旋律。

例如：NBC的三声音效、劳斯莱斯标志性的“欢庆女神”雕像、耐克的“Swoosh”标志、可口可乐瓶身、麦当劳的金色拱门或肯德基的桶形标志。

商标的保护期限取决于其商业使用情况。只要该财产仍在商业中使用，保护就可能持续，有时可被视为永久性权利。

商业秘密是指法院承认的私有商业材料的所有权，如客户名单、工艺流程、配方等。许多公司拥有对其业务至关重要的知识产权（即“秘方”），如果泄露给竞争对手或公众，将造成重大损害。

例如：可口可乐的配方或肯德基的保密食谱。

只要企业持续在商业活动中使用该秘密，并努力防止其泄露（例如使用保密协议），知识产权就能保持商业秘密保护状态。在这方面，它也可以被视为一种永久所有权。

在美国，商业秘密受《1996年经济间谍法》保护。要维持商业秘密状态，您必须在组织内实施充分的控制措施，确保只有有必要知情的授权人员才能访问它们。同时，必须确保任何无权访问的人员都受到保密协议的约束，该协议禁止他们与他人共享信息，并规定了违反协议的处罚。

根据《经济间谍法》：

  • 为外国政府利益窃取商业秘密，最高可处罚款50万美元和监禁15年。
  • 在任何其他情况下窃取商业秘密，最高可处罚款25万美元和监禁10年。

《1996年国家信息基础设施保护法》（1996年10月颁布）是《1996年经济间谍法》的第一章，它修订了《计算机欺诈和滥用法》，基本上规定了对任何未经授权故意访问计算机并获取已被确定需要防止未经授权披露的信息（如商业秘密）的人员的处罚。

专利及其保护

现在，让我们了解知识产权中最强有力的一种保护形式：专利。

专利授予新颖、有用且非显而易见的发明。换句话说，它必须是独特的发明。专利保护配方、工艺、产品、发明和植物。

可以申请专利的事物示例包括：

  • 新药物的配方
  • 新金属合金的冶炼工艺
  • 织物或纺织品图案
  • 通过其他植物插条嫁接而成、能在土壤中生长的新香料植物
  • 甚至一个更好的捕鼠器

专利授予发明实践专有权利，在美国由美国专利商标局授予，保护期最长可达20年；在全球范围内由世界知识产权组织管理。

专利是最强的知识产权保护类型。拥有特定知识资产的专利可以防止任何他人在未经所有者许可的情况下使用该资产，直至其到期。一旦专利到期，任何人都可以复制或实践它。

知识产权的执法

最后，我们来探讨知识产权的执法问题。虽然法院和政府承认财产权的所有权，但通常需要由所有者来执行这些权利。

例如，如果一家公司拥有某种药物配方的专利，而他人通过生产和销售相同配方的药物侵犯了该专利，则需要由受害方（原始专利所有者）对仿制者提起民事诉讼。

我们已经讨论过，商业秘密受《1996年经济间谍法》保护。

《数字千年版权法》 是美国版权法的一项修正案，旨在实施世界知识产权组织的两项1996年条约。它将生产和传播旨在规避控制访问受版权作品措施的技术、设备或服务的行为定为刑事犯罪，这些措施通常称为数字版权管理。

换句话说，它规定规避反盗版措施为犯罪行为，并禁止制造、销售和分发用于非法复制软件或其他材料的破解设备。

我们之前已经介绍过数字版权管理，这里简要回顾一下：数字版权管理被定义为一系列广泛的技术，从内容提供商的角度，授予他们对其自身数字媒体的控制和保护。其生命周期有三个关键组成部分：内容创建、分发和维护，以及最终的内容使用。

总结

在本节课中，我们一起学习了与云计算相关的法律，重点是知识产权。知识产权分为工业产权和版权。我们讨论了美国的合理使用原则、商标、专利、商业秘密，最后是知识产权的执法。理解这些概念对于在云环境中管理法律风险和确保合规性至关重要。

037：服务等级协议（SLAs）📜

在本节课程中，我们将学习服务等级协议。作为CCSP认证中“云法律风险与合规要求”领域的一部分，理解服务等级协议对于确保云服务满足业务与合规期望至关重要。

概述

服务等级协议是定义云服务提供商与客户之间服务期望的关键文件。本节我们将深入探讨SLA的定义、核心组成部分、审查要点以及相关的服务质量指标。

什么是服务等级协议？

服务等级协议是一份描述客户对供应商服务期望水平的文档。它明确了衡量服务的指标，并规定了当约定的服务水平未达到时的处理方式。

与客户和云提供商之间签订的合同类似，服务等级协议应涵盖与合规、最佳实践和满足各项要求的常规运营活动相关的内容。

区分合同与SLA

如何判断某项内容应属于合同还是服务等级协议？最简单的方法是：如果内容涉及指标或数字，则属于服务等级协议；否则，它应属于合同范畴。

SLA应包含的最低内容

一份服务等级协议至少应涵盖以下内容：

  • 可用性：例如，服务和数据的正常运行时间达到 99.99%。
  • 性能：例如，预期响应时间与最大响应时间。
  • 数据安全与隐私：例如，对所有存储和传输的数据进行加密。
  • 日志与报告：例如，所有访问的审计追踪，以及报告关键要求或指标的能力。
  • 灾难恢复预期：例如，最坏情况恢复承诺、恢复时间目标、最大可容忍中断时间。这些是我们讨论RTO、RPO和MTD时涉及的概念。
  • 数据位置：例如，满足当地立法要求的能力。
  • 数据格式与结构：例如，数据是否能够以可读且智能的格式从提供商处检索。
  • 数据可移植性：例如，将数据迁移到不同或多个提供商的能力。
  • 问题识别与解决：例如，是否设有帮助热线、呼叫中心或工单系统。
  • 变更管理流程：例如，更新或新增服务等变更的处理流程。
  • 争议调解流程：例如，是否存在升级流程及相应后果。
  • 退出策略：例如，对提供商确保平稳过渡的期望。

SLA的两大组成部分

服务等级协议应包含两个领域的组件：服务与管理。

上一节我们列出了SLA应涵盖的具体内容，本节我们来看看这些内容如何归类到两大组成部分中。

服务要素 包括：

  • 提供的服务详情与职责：明确谁负责什么，避免歧义。
  • 服务可用性标准：例如，不同时间段（如高峰与非高峰时段）可能对应不同的服务等级。
  • 升级流程。
  • 成本或服务权衡。
  • 服务等级协议下是否满足监管要求。

管理要素 应包括：

  • 测量、标准和方法定义。
  • 报告流程、内容与频率。
  • 争议解决流程。
  • 保护客户因SLA违约而免受第三方诉讼的赔偿条款。
  • 根据需要更新协议的机制。

审查SLA时的风险评估

在审查服务等级协议时，应关注以下风险评估方面：

  • 风险评估环境：如服务、供应商和生态系统。
  • 风险概况：SLA本身及提供服务公司的风险状况。
  • 风险承受能力：组织可接受的风险水平。
  • 风险缓解：可降低风险的缓解技术或控制措施。
  • 风险框架：使用何种框架（如NIST 800-53、ISO 27000、COSO、SABSA等）来评估持续有效性，以及提供商将如何管理此风险。

关键SLA组件示例

以下是一些你应该熟悉的关键SLA组件示例：

  • 正常运行时间保证：对服务可用性的承诺。
  • SLA惩罚条款：未达标的后果。
  • SLA惩罚排除条款：
    • 停机计算启动限制：一些云提供商要求应用中断一段时间（例如5到15分钟）后，才开始计入SLA违约。
    • 计划内停机：许多云提供商声明，如果提前通知，服务中断不计为计划外停机，因此不计算在惩罚内。有时，通知时间可能短至8小时。
  • 服务暂停：一些云合同规定，如果付款逾期超过30天（包括任何有争议的付款），提供商可以暂停服务。
  • 提供商责任限制：大多数云合同将除知识产权侵权索赔外的任何责任限制在过去12个月费用总额内。
  • 数据保护要求：大多数云合同规定客户最终对数据安全、保护和遵守当地法律负责。请记住，在云计算环境中，客户或企业始终要对任何治理、风险、合规和数据安全负责。
  • 违规通知：SLA应包含条款，要求提供商在意识到任何安全或隐私泄露后立即通知客户。

这些例子凸显了在与云提供商就SLA进行合作时，若未给予足够关注和尽职调查可能带来的风险。

服务质量指标

服务质量指标构成了SLA中度量与监控要求的关键组成部分。以下是应包含在SLA中的主要指标：

  • 可用性：在指定时间段内，相关服务的正常运行时间占总时间的百分比。
    • 可用性 (%) = (总时间 - 停机时间) / 总时间 * 100%
  • 停机时长：记录和测量每次服务中断实例的损失时间。
    • 例如：7月1日，上午9:20开始，10:50恢复，等于1小时服务损失。
  • 平均故障间隔时间：连续或重复性服务故障之间的预期时间。
    • 例如：365天中平均每1.25小时发生一次。
  • 容量指标：测量和报告容量能力及满足需求的能力。
  • 性能指标：用于主动识别性能瓶颈或退化区域。通常以每分钟请求数和连接数来衡量。
  • 成功率指标：基于约定标准列出响应成功率。
    • 例如：数据库事务完成成功率达99%。
  • 存储设备容量指标：列出与存储设备容量相关的指标和特性，通常以吉字节为单位。
  • 服务器容量指标：列出基于中央处理器频率（GHz）、内存、虚拟存储和其他存储卷影响的服务器容量特性。
  • 启动时间指标：报告初始化新实例所需的时间，从用户请求资源开始计算，通常以秒为单位。
  • 响应时间指标：报告执行请求操作或任务所需的时间，通常基于请求和响应时间以毫秒为单位测量。
  • 完成时间指标：提供完成启动或请求任务所需的总时间，通常以请求总数的平均值以秒为单位测量。
  • 平均切换时间指标：提供从服务故障切换到复制故障转移实例的预期时间，通常以分钟为单位测量，从开始到完成计算。
  • 平均系统恢复时间指标：突出显示在服务故障或中断后完全恢复的预期时间，通常以分钟、小时和天为单位测量。
  • 可扩展性组件指标：通常用于分析客户使用行为和模式，以实现服务器的自动扩展和收缩。
  • 存储可扩展性指标：指示在需要增加工作负载和存储需求时可用的存储设备容量。
  • 服务器可扩展性指标：指示在需要增加工作负载时可调用或利用的可用服务器容量。

调查与通知要求

服务等级协议或合同协议必须明确，是否允许对基于云的资产进行调查，或者在调查期间是否需要事先通知并获得接受。

总结

在本节课程中，我们一起学习了服务等级协议。我们探讨了SLA的基本定义、其核心组成部分（包括服务要素和管理要素），以及构成有效监控与度量基础的关键服务质量指标。理解这些内容对于评估云服务合同、管理风险并确保服务满足业务与安全需求至关重要。

038：保障框架与认证

在本节课中，我们将要学习云法律风险与合规要求领域的一个重要部分：保障框架与认证。我们将探讨几种关键的安全评估标准，了解它们如何帮助评估和验证IT产品的安全性。

在深入课程之前，需要指出，所有为CCSP考试必须掌握的具体信息，都会以屏幕所示的双星号标注形式高亮显示。所有以此颜色高亮的内容都与考试相关。

评估标准概述

上一节我们介绍了保障框架的重要性，本节中我们来看看几种具体的评估标准。这些标准为经过认证的第三方评估实验室提供了一个共享机制，使其能够根据一组安全要求来评估供应商的产品并公布结果。其目标是确定系统在现实世界中达到理想安全级别的程度，并据此决定是否采用该系统。

以下是几种主要的评估标准：

  • 可信计算机安全评估标准：也称为TCSEC或“橙皮书”。
  • 信息技术安全评估标准：即ITSEC。
  • 通用准则：也称为ISO/IEC 15408。

可信计算机系统评估标准

TCSEC是由美国国防部创建的一系列评估标准（彩虹系列）的一部分。例如，TCSEC本身也被称为国防部的“橙皮书”。它是一个保密性模型，评级从最低的D级到最高的A1级。

“红皮书”是TCSEC的网络解释，是一个保密性和完整性模型。此外还有“绿皮书”，即密码管理指南。我们将重点介绍橙皮书，即TCSEC。

TCSEC最初关注的是单机系统的保密性和功能性。其目标是指导设计者了解产品应具备的特性，指导评估者执行评估，并帮助采购者选择可信产品。它还基于强制策略、唯一标识、访问控制、标签、审计和持续保护等要求，提供了分级的安全类别。

美国国防部将TCSEC用作一个标准，为计算系统中安全保护的实施设定了基本标准，主要旨在帮助国防部找到符合这些基本标准的产品。它强烈侧重于强制执行保密性，而不关注安全的其他方面，如完整性或可用性。它现已被我们稍后将讨论的通用准则所取代。

TCSEC使用一个评级量表，D级表示最低保护，A1级为最高。

信息技术安全评估标准

接下来我们看看ITSEC。这是起源于欧洲并被国际采用的标准。它使用评估目标作为产品，使用安全目标作为产品声明的能力。

信息技术安全评估标准是一套用于评估产品和系统内计算机安全性的结构化标准。ITSEC于1990年5月首次发布，由法国、德国、荷兰和英国基于各自国家的现有工作制定。经过广泛的国际评审后，1.2版于1991年6月由欧洲委员会发布，供欧盟内部和认证计划使用。然而，ITSEC已基本被通用准则取代，后者提供了类似定义的评价级别，并实现了评估目标概念和安全目标文档。

与TCSEC相比，ITSEC中的安全要求规定得没有那么死板。相反，消费者或供应商有能力从一系列可能的要求菜单中选择一组要求，形成安全目标。然后供应商开发产品（评估目标），并根据该目标进行评估。这里的要点是，评估是分开的，分别检查有效性（即保障性）和功能性。同时，它也会评估漏洞，换句话说，是抵御攻击的能力。

在ITSEC中，供应商声称其产品根据安全策略、安全强化功能机制及其强度，以及评估目标的功能性和有效性级别进行评估。因此，ITSEC使用评估目标（即产品）和安全目标（即产品声明的能力）。评估目标基本上是任何IT产品或系统及其相关的指导文档，是评估的对象。

ITSEC的评级为E1到E6，如屏幕所示。

通用准则

现在我们来总结并介绍通用准则。由于其主要关注保密性，TCSEC被发现对于大多数非国防组织来说过于僵化。另一方面，ITSEC则被认为不够严格。因此，通用准则采取了与ITSEC非常相似的方法，提供了一套灵活的功能和保障要求。它侧重于标准化产品评估的通用方法，并在全球范围内提供此类评估的相互认可。

通用准则的出版物被称为ISO/IEC 15408，它同时关注保障性和功能性要求。这是第一个产品评估标准的国际标准，目前被广泛使用，因为它允许供应商或消费者以更细的粒度定义他们需要系统达到的安全级别。

通用准则认证的目标是确保客户所购买的产品已经过评估，并且供应商的声明已由中立的第三方验证。通用准则仅关注认证产品本身，不包括管理或业务流程，尽管它认为这些是有益的。仅依赖技术来实现稳健有效的安全是存在风险的。

通用准则引入了保护轮廓，作为功能和保障要求的通用集合。

以下是核心概念总结：

  • 评估目标：是评估对象的产品或系统。
  • 安全目标：是供应商记录的评估目标的安全特性。
  • 保护轮廓：是针对一类安全设备的已记录的安全要求。
  • 评估保障级别：从EAL1到EAL7。

你需要知道这些EAL级别是什么。我已经将它们高亮显示，你可以在屏幕上看到。EAL7是“形式化验证的设计和测试”，EAL1是“功能测试”。你需要知道每个级别的定义，因为考试中会出现专门考查定义的题目，你需要将其映射到相应的级别，如EAL1、2、3一直到7。

评估保障级别是衡量由评估分配的保密性、完整性和可用性的指标。它不涉及实施后的管理工作。评估保障级别是一组保障要求，代表了通用准则预定义保障量表上的一个点，范围从1到7，从用自然语言非正式表达，到用基于完善数学概念的、具有定义语义的限制性语法语言正式表达。

再次强调，EAL1是最低的非正式保障要求，而EAL7是最高、最广泛验证的保障声明。请记住，通用准则极大地有助于开发具有信息安全功能的产品和系统。

出于信息目的，我放置了一张图表，显示了通用准则的系统和子系统产品认证流程。你可以看到评估目标输入流程，然后是安全问题定义、评估目标的安全目标、安全功能要求、符合性声明、EAL1到EAL7的评估保障级别，最后是安全保障要求。

课程总结

本节课中我们一起学习了保障框架与认证。我们讨论了三种主要的标准：

  1. 可信计算机系统评估标准。
  2. 信息技术安全评估标准。
  3. 通用准则。

理解这些框架和认证对于评估云服务提供商的安全状况和确保合规性至关重要。

039：云安全联盟安全信任与保证注册表（STAR）📚

在本节课中，我们将学习CCSP认证“云法律风险与合规要求”知识域的一个重要组成部分：云安全联盟安全信任与保证注册表。我们将了解其背景、三个保证级别以及相关的核心框架。

课程概述

随着云计算的普及，行业缺乏统一的云安全标准和框架。为应对这一挑战，云安全联盟推出了安全信任与保证注册表。STAR是一个免费的公开注册表，旨在提升云服务环境的透明度和保证。云服务提供商可以在此发布其安全评估结果，而云服务用户则可据此评估提供商的安全性。

STAR的三个保证级别

STAR包含三个保证级别，这些级别与云安全联盟云控制矩阵的控制目标保持一致。CCM涵盖了14个安全领域的133项控制措施，帮助云客户评估云服务的整体安全风险。

以下我们将逐一探讨这三个级别。

第一级：自我评估

第一级是自我评估。这要求云服务提供商发布并公开其基于CSA共识评估倡议问卷或云控制矩阵的尽职调查自我评估报告。对于某些场景，自我评估可能已足够，但其他场景可能要求更高级别的第三方验证。

第二级：认证、STAR鉴证与C-STAR评估

第二级涉及认证、STAR鉴证与C-STAR评估。此级别要求发布由独立第三方基于CSA CCM、ISO/IEC 27001:2013或美国注册会计师协会的服务组织控制报告进行的评估结果。

上一节我们介绍了自我评估，本节中我们来看看更严格的第三方验证，特别是与服务组织控制报告相关的内容。

以下是关于SOC报告的关键信息：

  • SOC 1报告：这是一份财务报告，关注与实体财务报告相关的内部控制。其审计依据是SSAE 18标准。国际等效标准是ISAE 3402。
  • SOC 2报告：此报告关注非财务系统，评估组织在保密性、完整性、可用性、安全性和隐私方面的控制框架（如NIST、ISO 27001、COSO）实施情况。它通常是一份限制使用报告，因其包含详细的控制信息。
  • SOC 3报告：也称为系统信任报告。它与SOC 2类似，但主要区别在于，SOC 3报告是通用报告，细节有限，通常用于在网站上展示认证标志（如“ISO 27001 Certified”）。

此外，SOC报告有两种类型：

  • Type 1报告：这是一个时点报告，涵盖控制措施的设计。
  • Type 2报告：这是一个期间报告，涵盖控制措施的设计和运行有效性。

第三级：持续监控

第三级是持续监控。目前，云安全联盟仍在制定该级别的具体要求。它要求基于云信任协议发布并公开与安全属性监控相关的结果。

云控制矩阵

在了解了STAR的级别后，我们来看看其核心基础：云安全联盟云控制矩阵。

CCM专门用于为云供应商提供基本安全原则指导，并帮助潜在云客户评估云提供商的安全风险。它提供了一个控制框架，详细阐述了与CSA指南一致的安全概念和原则。

CCM的基础在于它与其他行业公认安全标准、法规和框架（如ISO 27001/2、COBIT、PCI DSS、NIST、Jericho Forum、NERC CIP）的对应关系。它可以增强或为云提供商提供的内部控制报告和鉴证提供指导。

以下是一个CCM模板的示例代码结构，展示了其组织方式：

域: 审计与问责
控制项: AU-01
控制描述: 必须记录和审查审计事件。
相关标准: ISO/IEC 27001:2013 A.12.4.1, PCI DSS 10.1

课程总结

本节课中，我们一起学习了云安全联盟安全信任与保证注册表。我们探讨了其背景、三个保证级别（L1自我评估、L2第三方认证与鉴证、L3持续监控），并深入了解了作为评估基础的云控制矩阵以及与之相关的服务组织控制报告。理解STAR及其组成部分，对于评估云服务提供商的安全性和合规性至关重要。

040：考试要点回顾 📚

在本节课中，我们将系统回顾CCSP认证考试的六个核心知识领域。我们已经完成了所有领域的学习，现在需要梳理并巩固每个领域的核心要点，为考试做好充分准备。

领域一：云概念、架构与设计

上一节我们介绍了课程的整体结构，本节中我们来看看第一个领域的核心要点。该领域关注云的基础概念和设计原则。

以下是您需要掌握的核心知识：

  • 理解业务需求：始终牢记，所有管理决策（包括安全和风险决策）都由业务需求驱动。安全与风险应在决策前被考虑，但可能不会凌驾于组织的业务和运营需求之上。
  • 掌握云术语与定义：确保清晰理解本课程中介绍的定义。CCSP考试大量涉及我们描述的术语和定义。
  • 描述云服务模型：理解三种云服务模型（IaaS, PaaS, SaaS）之间的差异及其相关特性至关重要。
  • 理解云部署模型：同样重要的是理解四种云部署模型（公有云、私有云、社区云、混合云）的特性及其差异。
  • 熟悉云计算角色与职责：确保了解并理解不同角色及其各自的责任。
  • 确定业务需求：理解业务影响分析的功能和目的，以及它如何帮助组织确定资产清单的价值和关键性。
  • 熟悉各云服务模型的边界：了解哪些模型将典型控制措施和依赖项分配给云服务关系中的参与方。
  • 理解合同协商空间：认识到在所有服务模型中，云提供商和云客户在合同定义责任和权利方面存在大量协商空间。
  • 理解云架构如何支持敏感数据安全：熟悉设备加固、加密和纵深防御如何增强云中数据的保护。了解在哪里可以找到安全云设计的框架、模型和指南。

领域二：云数据安全

在掌握了云的基础架构后，我们进入数据安全领域。数据是云环境中的核心资产，其安全至关重要。

以下是您需要掌握的核心知识：

  • 了解不同形式的数据分析：熟悉数据挖掘、实时分析和敏捷商业智能的描述。
  • 理解与数据所有权相关的角色、权利和责任：了解数据所有者、控制者、处理者和保管人是谁，以及各自相关的权利和责任。
  • 理解数据分类和分级的目的与方法：了解数据所有者为何以及如何对其控制下的特定数据集分配类别和级别。
  • 熟悉数据发现方法：了解数据如何、何时被标记以及由谁标记。同时了解基于内容的发现以及在发现工作中使用元数据。
  • 了解数据生命周期：按顺序了解数据生命周期的所有阶段，但请记住，它们不必按该顺序执行。为了考试，请按顺序记住它们，并认识到在实践中不一定按特定顺序执行。
  • 熟悉各种知识产权保护措施：了解版权、商标、专利和商业秘密的保护。
  • 了解数据保留、审计和处置策略应包含的内容：理解保留和处置条款、保留格式、法规如何规定这些事项等基本方面，以及每项策略都需要包含维护、审查和执行的细节。

领域三：云平台与基础设施安全

数据安全依赖于底层的平台和基础设施。接下来，我们探讨支撑云服务的平台与基础设施的安全考量。

以下是您需要掌握的核心知识：

  • 理解与云数据生命周期每个阶段相关的风险和安全控制：每个阶段都有其伴随的风险，这些风险通常与特定的一组或一类安全控制相关联。
  • 理解各种云数据存储架构：能够区分文件存储、块存储、数据库和内容分发网络。
  • 理解云中如何以及为何实施加密：了解密钥管理的基本要素，特别是要知道加密密钥不应与它们用于加密的数据存储在一起。
  • 了解新兴技术：如同态加密，以及未来它如何可能用于处理加密数据而无需先解密。
  • 熟悉数据混淆实践：了解数据脱敏、隐藏、匿名化和令牌化的不同技术。
  • 熟悉SIEM技术：了解SIEM实施的目的以及使用这些解决方案相关的挑战。
  • 理解出口监控的重要性：熟悉数据防泄漏解决方案的目标、它们如何工作，以及云客户尝试在云数据中心内实施DLP可能面临哪些挑战。
  • 了解客户与提供商之间的责任分担：这一点非常重要。请记住课程中提供的责任级别概念图表，其中各方的责任级别取决于所提供服务的量。客户始终对数据和治理、风险与合规负责，云服务提供商始终对物理安全负责。您还必须了解哪些是共同责任，这取决于服务类型。
  • 理解云中的业务连续性与灾难恢复：注意与传统环境中BCDR计划和活动的相似之处，但要特别关注云客户与云提供商之间必要安排的复杂性增加，以及合同中这些安排的重要性。

领域四：云应用安全

在稳固的基础设施之上运行的是应用程序。本节我们关注云环境中的应用安全，这是保护服务的最后一道防线。

以下是您需要掌握的核心知识：

  • 了解云数据中心设计中如何实施冗余：请记住，所有基础设施、系统和组件都需要冗余，包括公用设施（电力、水、传导性）、处理能力、数据存储、人员以及应急和应急服务。出口路径、应急照明和燃料也需要冗余。
  • 了解正常运行时间研究所发布的四个数据中心冗余等级：理解从第1级到第4级设计的复杂程度升级，以及每个等级之间的基本差异。
  • 了解培训与意识的重要方面：理解培训如何影响组织的风险，并了解哪些要素支持培训工作，特别是高级管理层的认可、充足的资金以及与工作任务的关联性。
  • 理解静态应用安全测试与动态应用安全测试的区别：了解SAST是白盒测试，涉及源代码审查；DAST是黑盒测试，在运行时（即应用程序运行时）执行。
  • 理解系统和组件监控：确保熟悉监控数据中心所有基础设施、硬件、软件和介质各个方面的重要性和目的，包括温度、湿度和事件日志记录。
  • 透彻理解维护策略和程序：这些策略和程序包括维护模式与正常操作、执行更新和升级的流程，以及手动与自动补丁管理的风险和益处。
  • 了解变更管理的目的和一般方法：理解变更管理委员会的组成及其运作方式。
  • 理解业务连续性与灾难恢复策略、规划和测试的所有方面：重点关注BCDR策略、规划和测试，特别是与云数据中心相关的部分。了解备用电源的考虑因素以及测试BCDR计划有效性的方法。

领域五：云安全运营

安全的设计需要有效的运营来维持。现在，我们转向确保云环境持续安全运行的日常活动和流程。

以下是您需要掌握的核心知识：

  • 了解提供商在数据中心提供安全物理、逻辑和网络元素的职责。
  • 理解提供商将如何使用安全流程、方法和控制措施，为客户提供一个可信的业务环境。
  • 了解在每个云服务模型中，哪一方最可能承担哪些特定的安全责任：了解在基础设施即服务、平台即服务和软件即服务配置中，提供商和客户各自的任务是什么。
  • 理解云客户和云提供商可能共享哪些责任：了解操作系统和应用程序基线化管理责任可能被共享，身份和访问管理在某种程度上也可能被共享。
  • 了解最可能用于云数据中心的不同类型审计报告：理解SOC 1、2、3报告以及类型1和类型2之间的区别。了解哪种报告更适用于详细分析，以及云客户最可能接触到哪种。
  • 理解ANF和ONF之间的区别：ONF代表所谓的“安全容器网络”，是一个组织利用的应用程序安全最佳实践目录的子组件。它由多个ANF组成。ANF代表围绕特定业务应用程序以达到目标信任级别的ONF组织的任何子集。请记住，一个ONF对应多个ANF。
  • 能够阐述STRIDE模型的组成部分：STRIDE威胁模型代表六类威胁：假冒、篡改、抵赖、信息泄露、拒绝服务和权限提升。不要忘记DREAD模型，它由损害潜力、可再现性、可利用性、受影响用户和可发现性组成。
  • 能够描述SDLC的阶段：确保理解SDLC模型中的阶段。SDLC包括以下阶段：定义、设计、开发、测试、安全运营和处置。
  • 理解身份和访问管理及其如何融入云环境：随着基于角色的访问控制的出现，身份和访问管理在管理用户方面起着关键作用。理解这一点以及联合身份的重要性。
  • 理解云应用架构的具体要求：并非所有应用程序都设计为在云中运行。务必理解在设计或尝试将应用程序迁移到云时架构上的差异。

领域六：法律、风险与合规

最后，任何安全实践都必须在法律和合规的框架内进行。本节总结云安全所涉及的法律、风险和合规性要求。

以下是您需要掌握的核心知识：

  • 基本理解相关的ISO和IEC标准：如ISO 27001。ISO标准不是法律，而是来自世界各地的专家共同制定的操作标准。许多国家和联盟（如欧盟）的许多政策都基于ISO相关标准。
  • 清晰理解围绕电子取证的相关问题：包括取证、证据链保管以及在云环境中进行取证收集所面临的挑战。由于地理和地缘政治分散等因素，在云环境中尝试进行电子取证可能非常具有挑战性。
  • 理解审计流程：理解基本的审计概念，如内部审计与外部审计，以及在执行审计时独立性的差异和重要性。可靠性较低的内部审计协助内部运营，而更为独立的外部审计则能更彻底地发现可能给组织带来风险的敏感问题。
  • 熟悉个人可识别信息的基本定义。
  • 熟悉合同规定与受监管的、国家特定法规之间的差异。
  • 理解敏感与非敏感PII之间的区别：使用直接和间接标识符。此外，请注意，即使PII本身可能是非敏感的，当与其他非敏感信息结合时，也可能变得敏感。
  • 确保牢固掌握本课程讨论的模型、框架和标准：包括ISO标准、NIST标准和ENISA标准。
  • 熟悉数据管理角色：确保理解各种数据角色、活动以及各自的责任。
  • 确保透彻理解服务等级协议的所有要素：理解服务等级协议如何适用于云计算。
  • 务必理解CSA安全、信任和保证注册的三个级别：即开放认证框架。

本节课中，我们一起系统回顾了CCSP认证考试六个领域的核心要点，从云基础概念、数据安全、平台安全、应用安全、安全运营到法律风险与合规。掌握这些要点对于通过考试和在实际工作中应用云安全知识至关重要。建议结合图表和实际案例进行深入理解，并做好充分的练习准备。

041：考试概览与准备策略 📘

在本课程中，我们将介绍CCSP认证考试的相关事项，并提供一些备考建议。无论您是否已满足屏幕上列出的官方要求，都可以参加CCSP考试。但请注意，只有在满足所有要求后，您才能获得正式认证；在此之前，您可能只会获得“准CCSP”资格。

认证要求与道德准则

要获得CCSP认证，您需要满足以下工作经验要求之一：

  • 拥有五年全职带薪工作经验。
  • 拥有四年工作经验，并持有有效的CSA CCSK（认证云安全知识）认证。
  • 若已持有CISSP认证，则可完全替代CCSP的经验要求。

除了满足经验要求，您还必须同意并遵守(ISC)²的道德准则，该准则可在 www.isc2.org/ethics 查阅。

认识CCSP六大知识域

上一节我们明确了考试资格，本节中我们来看看考试的核心内容。您需要熟悉CCSP的六个知识域。以下是基于考试权重划分的、各知识域可能的题目数量分布，这有助于您更有针对性地复习。

考试题型与策略

考试大部分题目是标准四选一单选题。部分题目会基于一个提供的场景或情境，您需要先阅读材料。

面对场景题的黄金法则：务必先看问题，再带着问题去阅读场景。请确保理解题目在问什么，并寻找关键词。例如，题目是问“以下哪项不是要求”还是“以下哪项是要求”？是要求“选择以下两项”还是“选择一项”？

考试至少包含125道选择题，其中25道是不计分的测试题。这些题目随机混合在试卷中，您无法区分，因此必须认真作答所有125道题目。

考试时间与变化

目前，您有4小时完成考试，平均每题约2分钟。但请注意，自8月1日起，考试时间将缩短为3小时。考试内容本身基本保持不变，主要变化是一些知识点可能在知识域之间迁移或重组。因此，您复习的内容依然有效，只是答题时间更为紧张。

考试结束后会立即显示成绩。请记住，未作答的题目不得分。

考前注册与现场须知

在Pearson VUE注册考试时，请确保提供的姓名与您考试当天出示的有效身份证件上的姓名完全一致。例如，如果您的证件显示“Robert”，即使您常用名是“Bob”，也必须注册为“Robert”，否则将被拒绝入场。

请提前到达考场。您可以携带饮料和食物，但必须存放在考场提供的储物柜中，仅在休息时可取用。请注意，休息期间考试计时不会停止，请谨慎管理时间。

核心备考技巧

以下是一些关键的备考与应试技巧：

  • 完成模拟试题：认真完成提供的模拟考试。
  • 研究错题：对做错的每一道题进行研究，可能需要查阅资料或深入学习。
  • 高效答题：答题时保持高效，不要浪费时间，并时刻留意剩余时间。
  • 排除法：在猜测答案前，尝试先减少或排除一些明显错误的选项。
  • 注意问题格式：再次强调，务必注意问题的提问方式。
  • 利用草稿板：使用考场提供的白板做笔记。
  • 审题与思考：阅读问题时问自己：这个问题是在寻找一个程序、政策还是法规？是问什么对公司最有利还是对安全最有利？我在此情境中扮演什么角色或应该站在什么立场？
  • 关键词与视角：记住，最佳答案并不总是最安全的那个。始终牢记答题时所处的视角。另外请注意，“客户”和“企业”在题目中通常可互换使用，含义相同。若未特别说明，则默认您处于客户或企业的视角；如果题目未提及，则通常是指云服务提供商。

通过考试与获得认证

一旦您通过考试，考试结束时会立即提供您的成绩。同时会获得如何下载认证申请表、填写、签署并提交给(ISC)²审核的指引。(ISC)²通常会在几天内发出正式认证通知。

总结

本节课中我们一起学习了CCSP考试的基本要求、知识域构成、题型策略、时间安排、考场规则以及一系列实用的备考与答题技巧。关键点包括：确保注册信息准确、掌握先读问题再读场景的方法、注意考试时间变化、在答题时保持正确的角色视角。祝您考试顺利，请务必努力学习！

posted @ 2026-03-29 09:16  绝不原创的飞龙  阅读(2)  评论(0)    收藏  举报