[系统运维] 云计算设计和规划安全控制措施

开发: C++知识库 Java知识库 JavaScript Python PHP知识库人工智能区块链大数据移动开发嵌入式开发工具数据结构与算法开发测试游戏开发网络协议系统运维
教程: HTML教程 CSS教程 JavaScript教程 Go语言教程 JQuery教程 VUE教程 VUE3教程 Bootstrap教程 SQL数据库教程 C语言教程 C++教程 Java教程 Python教程 Python3教程 C#教程
数码: 电脑笔记本显卡显示器固态硬盘硬盘耳机手机 iphone vivo oppo 小米华为单反装机图拉丁

-> 系统运维 -> 云计算设计和规划安全控制措施 -> 正文阅读

[系统运维]云计算设计和规划安全控制措施

设计和规划安全控制措施

为确保健全的安全策略和整体治理，云安全专家应该专注于几个不同的领域，本节将详细介绍这些领域。

物理和环境保护

物理和环境保护涉及所有物理设备和基础架构组件。虽然云基础架构所使用的访问和技术为客户提供了一套独特的服务，但其背后仍是一套传统的数据中心模型，尽管大多数清况下云基础架构规模要大得多。然而，由于云的定义是可通过广泛的网络（如公共Internet)访问的系统物理保护也必须扩展到用于访问云平台的系统。
实际数据中心内的物理资产包括服务器、制冷装置、配电装置、网络设备、物理机架和长达数英里的电缆以及实际的物理设施和位于场所内的辅助系统，如备用电池、电源管道、发电机、燃料箱和周围的外围设备。在数据中心外，还有更多的物理设备和基础架构对云安全专家也非常重要。包括数据中心所依赖的电力供给和网络管道，以及用户和客户访问的终端，如移动设备、工作站、笔记本电脑、平板电脑和其他任何客户端系统。
从物理的角度看，安全性的方法与任何其他系统没有什么不同，分层防御是指导原则。在数据中心大楼外，将拥有典型的安全措施，例如，围栏、摄像头、灯光、车辆出入控制和障碍物，以及驻扎在不同位置的安保人员。进入建筑物内部，应严格控制人员、门、钥匙卡访问、身份验证和其他类似于如何访问IT系统的各个方面，包括以徽章、代码和生物标识等形式实施的多因素身份验证。一旦进入系统所在的实际楼层空间，应通过使用物理罩和分区以及采用不同级别的访问控制和持续监测，实现进一步的控制和限制。某些情况下，可能存在合同或法规要求，即根据系统类型、对其拥有权限的辖区以及存储和使用的数据类型，将不同类型的系统从物理罩中分离出来。

数据中心所依赖的任何公用设施和基础设施（尤其在电力供给和制冷方面），都应在数据中心内外冗余。从外部应该有多个独立的电力供给进入数据中心。在数据中心内部，向机架和服务器供电的配电装置也应是冗余的。这样，无论内部或外部发生电源故障，都有独立的冗余电源。这同样适用于网络，在内部和外部具有独立的网络供给和冗余。
对于允许以任何身份进入数据中心的全部人员，应执行广泛且严格的背景调查流程。在系统安全方面应该根据最小特权原则授予人员物理访问权限。对于员工而言，重要的是要有合理的持续监测和审查，以及持续的培训，提醒员工注意策略、程序和保障措施。

系统和通信保护

尽管云基础架构是通过虚拟化呈现给客户的，但其底层是与传统数据中心相同的真实硬件和系统。根据所采用的云托管模型的类型，客户的暴露程度和责任各不相同。
尽管云服务提供商负责底层硬件和网络，而不管云服务模式如何，其余的服务和安全责任要么由客户承担，要么由客户和云服务提供商分担。云安全专家有责任清楚地理解客户和云服务提供商之间责任的界限，且相关责任应在合同和SLA条款中明确阐明并记录。
与任何应用程序一样，数据保护是首要问题，不同的数据状态需要不同的方法：

静止状态数据(Dataat Rest) 静止状态数据的主要保护方法是使用加密技术
传输状态数据(Datain Transit) 对于传输状态数据，主要的保护方法是网络隔离和使用加密传输机制（如TLS)。- 处理状态数据(Datain Use) 通过使用加密、数字签名或专用网络路径，使用安全的 API调用和Web服务保护此类数据。

保护虚拟化系统

虚拟化构成了所有云基础架构的主干，并支持多种特性，这些特性帮助云环境成为独特且流行的技术和平台。鉴于虚拟化所扮演的可见且重要的角色，构成虚拟化基础架构的组件和系统是攻击方最明显和最具吸引力的目标。
管理平面具有对环境的完全控制权和允许管理任务的公开API，是需要充分保护的最明显和最重要的方面。管理平面由一系列API、公开的函数调用和服务以及Web门户或其他允许其使用的客户端访问组成。所有组件都存在潜在的漏洞。云安全专家需要对管理平面的每个级别和每项组件绘制一张威胁和漏洞的整体图景。如果云安全专家没有逐一分解每项组件，掌握其特定的漏洞和威胁，然后将组件风险组合在一起形成一张全面的视图，那么整个系统可能会因为遗漏一个漏洞而受到影响。
与任何系统一样，基于角色的访问控制在管理平面和虚拟化基础架构中极为重要。必须严格控制所有管理访问，并定期全面审计。非常详细的日志记录不仅应该发生在虚拟化基础架构的每一部分，还应该发生在W eb门户级别或者客户端访问管理平面的任何位置。所有日志的捕获方式都应该是从实际系统本身中删除、索引和评价的。这允许在实际组件受到损害时保存日志，并具有足够的管理访问权限来修改或删除本质上属于本地的日志。
除了维护自动伸缩和韧性等云特性外，虚拟化环境和基础架构的一个主要功能是促进和维护多租户特性。从创建和实现的角度看，允许多租户并不是一个重大挑战，因为从根本上讲，多租户是一项管理任务，而不是一项技术任务。从虚拟化的角度看，虚拟机只是主机；不依赖于虚拟机包含什么样的客户或合同要求。控制的重要性在多租户中发挥作用的地方是要求租户相互隔离和相互保护。这包括保持租户之间的系统交互和安全隔离，以及资源和利用率，确保所有租户都拥有其特定系统和应用程序所需的东西，以满足合同和SLA条款要求。
虽然日志记录和审计对安全性很重要，但这些都是相对被动的机制，并不能防止实际漏洞的早期利用。传统数据中心系统级别使用的许多相同方法和策略也适用于云环境中的虚拟化基础架构。主要的示例有建立信任区；以同样的方式，服务器和系统之间的网络分离将作为层次防御策略来实现。根据云环境或云客户合同的特殊需要，能够以多种方式划分信任区域。在实施信任区域之前，云服务提供商应该实施严格的威胁和漏洞评估，以确定其基础架构漏洞在哪里，以及信任区域在哪些方面可能获益。在不了解和不理解采购云环境的情况下，组织不希望采取基于其他云服务提供商实践的方法。沿着这条路走下去可能导致出现虚假的安全感在不需要的地方增加复杂性，甚至可能导致由于添加不必要的组件和机制而出现的新风险和新漏洞。
可使用多种不同的策略来建立和分割信任区域。最常见的方法是分离出系统架构的不同层（例如可将基础结构的Web／表示、应用程序和数据区域分开）。这使得每个区域都能利用与其实际需要和功能相关的、具体的工具和战略，获得自己的保护和持续监测能力。这允许应用程序和数据区域与外部网络访问和流量隔离，从而进一步增加安全控制措施和增强功能。
使用隔离和分段技术，负责管理系统的团队将需要访问的不再仅是应用程序运营内容。虽然通信通道将在内部开放，以便应用程序正常工作，但这并不便于管理团队获得访问所需的内容，而且从安全角度看，安全专家在任何情况下都不会希望为管理团队的访问打开外部连接。在这种配置中，允许管理员访问的最常见方法是使用虚拟专用网络(Virtual Private Network, VPN)或跳转服务器。通过VPN连接，管理员可使用大多数本机方法和协议来访问管理员的主机，因为从设备到云环境内部，主机都是安全的，因此不会暴露在公共Internet上。VPN连接将有自己的身份验证和授权机制，VPN使用加密通信隧道，从而增加额外的安全层。对于跳转服务器，其概念是在云环境中配置一台服务器，跳转服务器是开放的且暴露在公共Internet上，管理员可以连接到跳转服务器，并且可在内部访问适当的资源。这种方法允许安全性集中在跳转服务器上，而不是所有业务服务器上，并且允许在更小、更专业的规模上实施适当的访问控制、持续监测和日志记录。跳转服务器的安全性变得至关重要，但跳转服务器确实直接消除了主机本身的安全问题，并且允许管理员连接而不需要VPN软件和配置文件。另一个经常使用的概念是堡垒机(Bastion Host)。堡垒机是一台完全暴露在公共Internet上的服务器；堡垒机非常坚固以防止攻击，通常只用于特定的应用程序或用途。这种单一性允许更严格的安全强化和待续监测。然而，这些实现可以一起使用，以提高安全性。

云基础架构中的标识、身份验证和授权

与应用程序一样，云系统需要标识、身份验证和授权。然而，这种需求也扩展到包括非个人实体，例如，设备、客户端和其他应用程序。联合身份(FederationIdentity)是云计算的另一个重要方面，尤其是对于拥有大量客户和用户的公有云。联合身份允许使用“原生(N ative)" 系统来提供标识和身份验证，而不需要用户基础来与云服务提供商建立安全凭证。 联合身份
联合身份涉及各个不同组织所采用的策略和技术的标准基础，以便各个组织能够加入其身份系统并允许应用程序在保持其自主性的同时接受其安全凭证。通过建立每个成员组织必须遵守的策略和指导原则，并通过每个成员组织提供的身份来建立信任，接受这些身份的每个应用程序都了解联合身份中的每个身份提供方(Identity Provider, IdP)都已经接受足够的背景调查，得到了证明。当作为联合身份一部分的系统或用户需要访问接受来自该联合身份的凭证的应用程序时，该系统或用户必须通过自己的身份验证流程获取本地令牌，然后将这些令牌传递给应用程序以完成接受和访问。参与的成员运行自己的“身份提供方“，接受该凭证的系统称为 “依赖方”。标识
身份标识指以某种方式将实体（个人或系统／应用程序）与任何其他身份区分开来的流程几乎所有组织都已建立了一套身份标识系统通常基于某种形式的LDAP。许多组织（如学术机构、小企业和非营利组织）倾向于使用开源或其他类似的身份系统，而在企业界，私有和商业支持的系统（如动态目录）往往占主导地位。随着大型公有云体系的出现，许多组织和云服务提供商都转向了OpenID和OAuth标准。无论组织使用哪种特定风格的身份提供方，绝大多数都使用安全声明标记语言(SecurityAssertion Markup Language, SAML) 和WS-Federation标准来传递身份信息。
身份验证
虽然身份标识建立了一个实体或个人的独立存在体，但身份验证是一套可确定所提供的身份标识真实性的流程。根据策略，这是在系统可正确信任访问请求的程度上完成的。如前所述，这可通过多种方法实现，从用于较低安全级别的基本用户ID/口令组合，到强壮的多因素身份验证（应该在所有可能的实例中使用，但始终用于管理和特权访问）。身份验证流程由身份提供方处理。
确保在执行身份验证的所有实例中都使用了多因素身份验证，特别是管理账户和特权账户用户，这一点尤其重要。安全专家们必须掌握什么是多因素身份验证、在何处使用多因素身份验证，并了解为什么多因素身份验证对于促进安全至关重要。
授权
一旦建立身份并在所需的范围通过身份验证流程，授权将授予用户或系统进程适当的实际角色和权利，以获得对数据和应用程序的访问权。在身份验证流程中，身份提供方向依赖方发送关于用户的预设属性。然后，依赖方使用属性信息（姓名、位置和职务等）来确定要授予的访问权限的适当级别和类型，或是否授予访问权限。即使在联合身份系统中，依赖方也会做出这种决策，因为授权与实际的应用程序关联，并且授权根据受访问数据的策略、需求或规则做出决策。
在决定是否授予访问权限以及访问级别时，应用程序可从身份提供方获取有关实体的任意数量的属性。判断可基于单个属性，也可基于复杂条件和属性组合。以大学的图书馆在线期刊系统为例。大多数情况下，基于许可协议准入的唯一要求是个入与大学有联系，而具体的隶属关系类型并不重要。这种情况下，身份提供方仅需要承认此用户是大学的有效附属机构成员，就满足了依赖方的许可要求，因此授予了访问权。另一方面，系统和应用程序使用非常复杂的决策算法来确定授予什么级别的访问权限。例如，组织运行的应用程序可能允许组织网络上的用户立即访问，但需要对不在组织网络上的应用程序执行更广泛的验证。作为第一个有条件的步骤，依赖方可检查用户从何处连接。如果用户在组织网络上，则可立即授予访问权限。如果用户不在组织网络上，依赖方可要求用户通过身份提供方执行身份验证流程。身份验证成功后，身份提供方将向依赖方提供更多用户信息，以确定访问权限。
无论实体试图访问哪条途径，都必须通过策略和审计遵守最小特权和风险评估的原则。对系统的每次访问都基于数据安全的风险评估，这是根据组织策略和访问方式建立的。如果参与方提供的安全凭证和属性与已确定的数据安全可接受风险一致，则可继续访问。

审计机制

传统意义上的审计包括确保符合法规要求、策略和指导原则。从安全的角度开展审计实务，以衡量满足来自各种来源的安全控制措施的有效性，这些来源共同构成了系统或应用程序的完整安全需求。许多情况下，这将包括内部安全策略要求、合同要求，包括来自美国地方、州或联邦政府的监管合规要求，以及任何行业或组织要求（如PCI-DSS)。审计是通过分析安全控制措施需求来执行的，这些需求与配置和内部策略相结合，然后通过收集日志、屏幕截图、数据集或任何其他内容，以证明符合管理层、客户或独立形俯审计师的要求。
在当今的IT环境中，审计用于超出传统需求的范围：审计用于从内部角度开展持续的安全合规性和测试，并且越来越多地用于向客户和委托方提供价值和性能的证据。审计证据可以用于显示系统性能、正常运行时间、用户访问和负载，以及几乎任何其他可以收集和量化的指标。
与传统数据中心和托管模型相比，审计在云环境中带来了额外挑战和复杂性。云环境是大型的分布式托管平台，许多情况下需要跨越多个数据中心，甚至跨越多个国家和地区。许多系统也托管在混合云环境中，跨越多个云服务提供商和／或托管模型，或者甚至是云环境和传统数据中心托管配置的组合。根据所使用的云模型(IaaS、PaaS或SaaS)，审计范围将根据客户拥有的访问级别和云服务提供商按合同提供的信息级别来定义。云服务提供商和云客户之间的合同和SLA条款应该清楚地说明审计的要求和双方之间的责任划分，以及任何审计测试和报告的频率。由于云平台是一个多租户环境，在几乎任何情况下，任何渗透测试或审计测试都必须在云服务提供商和云客户之间先期协调，以确保安全测试不会与托管在同一环境中的任何其他云客户的需求相冲突。
由于底层的云系统和架构是由云服务提供商控制的，并且是云服务提供商的责任，因此任何审计要求都必须在合同中明确说明，并由云服务提供商提供支持和协助。尤其是在大型公有云上，承载着成百上于个不同的客户，因此每个客户都不可能在任何意义上实施彻底的审计。云客户将需要依赖受委托代表云服务提供商的审计，并有相应的合同措辞要求开展审计活动。通常，云服务提供商将委托一家信誉良好的大型审计团队审计云环境，审计团队应满足云服务提供商的单个租户和客户的需求，并提供足够详细的报告，以满足云租户的期许。
云服务提供商可使用的重要方法是根据严格的标准，通过对其云环境的认证。如果使用公认的既定标准，云客户可接受该认证，作为云服务提供商满足安全控制实施、策略和持续审计需求的证据。云服务提供商的一大优势是利用其自助服务功能向云客户提供一组审计工具和报告。通过自助服务门户，云服务提供商可让客户访问一套预构建的报告、日志收集功能和脚本，这些功能为大量控制测试和数据点集合提供度量标准。帮助客户在需要时从审计工具中提取审计报告和证据，而不必云服务提供商或审计师的参与。云环境在审计合规方面的另一大优势是使用虚拟化和服务器镜像。云服务提供商或云客户能够构建一个包含所有已实现和已测试的安全控制措施的基础镜像，然后使用该镜像部署环境中的任何其他主机。这极大地减少了在传统数据中心为构建每台服务器需要耗费的时间和精力，以及在认为服务器可使用之前实施和测试基线的必要性。在使用相同镜像的云环境中，客户从一开始就知道每个主机实例都是完全兼容的，并且配置正确以满足其安全基线要求还可以构建包含持续监测工具或数据收集工具的镜像，以便当主机联机（特别是通过自动伸缩）时，这些功能已经建立并从一开始就处于运行状态。在每台服务器上建立维护钩子对于拥有自助审计功能和待续监测功能起着重要作用，而不必花时间确保维护钩子在每个实例中都正确地安装、配置和运行。
日志收集
与传统数据中心相比，云环境中的日志收集带来了额外挑战。这两种情况下，通常可使用相同的方法聚合日志，但云环境中最重要的挑战是云客户可访问哪些日志，访问级别是高度可变的，具体取决于云部署的类型以及和云服务提供商的合同。
在IaaS环境中，云客户将拥有对操作系统和虚拟设备级别日志的最大访问权限，以及对平台和应用程序级别日志的最大访问权限。这将需要一个已实施的策略来收集和汇总日志。但是，除非云服务提供商通过合同条款提供，否则不能访问虚拟机管理程序或更多样的网络级别的日志。在PaaS环境中，云客户可在平台和应用程序级别使用相同等级的综合日志，但不一定提供操作系统和网络设备级的日志，除非是云服务提供商特别提供的。SaaS环境中的应用程序级日志也存在相同的问题。
数据包捕获

云环境中的数据包捕获涉及许多与日志收集相同的挑战。可用的数据包捕获级别将取决于云部署的级别和对必要网络设备的控制措施级别，以及在什么时候需要捕获特定数据包。如有必要在虚拟机上捕获数据包，并且在IaaS环境中，云客户可能具有其需要的访问级别。但在PaaS或SaaS环境中，云客户将完全依赖于云服务提供商提供的服务。如果数据包捕获需要在网络内或网络设备之间，访问将是灵活可变的，并依赖于合同条款。在所有情况下，如果数据包捕获需要更高的网络级别（或边界路由器），云服务提供商的参与将是必要的。