对安全专业人员的云计算和云安全这两个部分组成的系列，我们一头扎进你曾经想知道云（但不敢问）的一切。现在，您已经对云的真正含义及其运行方式有了更好的了解，让我们深入研究如何保护云基础架构。即，我们将讨论应该用来帮助确保安全设置环境的顶级安全控件。

云安全的挑战

首先，让我们快速介绍一下确保云环境安全的独特之处以及存在的挑战。正如我们在本系列的第1部分中讨论的那样，云基础架构的最大好处是速度和易于部署。在云环境中，开发人员和DevOps只需单击几下即可部署新的基础架构。这极大地加快了创新的速度，但是缺点是您的员工相对不熟悉网络配置和创建基础架构的安全性。

因此，云基础架构固有的最大风险之一就是配置错误，可以利用这些错误配置来访问您的环境。云安全的许多最佳实践都围绕着最大程度地减少错误配置的发生并在错误配置发生时迅速进行补救。

安全专业人员面临的挑战是，您必须找到一种在不影响开发人员快速迁移能力的情况下保持云环境安全的方法。这通常意味着实施护栏和自动化，这使开发人员可以轻松地正确配置资产而不会降低资产的速度。找到一种不影响部署速度和简便性的方法来确保安全的重要性不能被夸大：如果设置了障碍，开发人员将找到规避这些障碍的方法，并且与发现的情况相比，您的组织将面临更大的风险与开发人员合作并在满足开发人员需求的同时保持安全的一种方法。

另一个重大挑战是云基础架构中发现的变化率。云中部署的简便性和速度意味着事物的变化要比本地环境中的变化快得多。此外，许多云环境中使用的一项关键功能是自动扩展，即根据需要自动扩展或缩减运行工作负载的服务器数量。这种不断的变化使安全团队很难保持环境的安全。答案是自动化。从自动失败配置资产失败到自动隔离似乎已受到威胁的资产，这可能意味着任何事情。

既然您已经对保护云环境所带来的挑战有了基本的了解，那么让我们开始讨论一下最佳实践吧。

建立基线

在做其他事情之前，您需要创建一个基准，然后执行它。从安全的角度来看，基准线精确地列出了您的云环境应该是什么样的，概述了诸如哪些服务被授权使用以及哪些服务未被授权使用之类的事情。它还指定了应如何配置这些服务，谁可以访问云基础架构的哪些部分，谁可以对该云基础架构进行更改，等等。基线是每个人都可以参考的文档。这在云中至关重要，因为不再是运行基础架构的IT和安全团队，还是DevOps团队和开发人员本身。基线确保每个人都保持一致。它还应该列出诸如组织如何响应事件的过程。事件响应计划在这里至关重要，

您现在可能要问的是首先如何创建基准。我们建议从现有的最佳实践建议开始，例如为AWS，Azure和Google Cloud Platform（GCP）创建的CIS基准。它们提供了用于安全配置云基础架构的广泛的最佳实践。每个云提供商还可以使用自己的最佳实践。它们都是一个很好的起点，从那里，您可以决定哪些建议对您的组织有效，哪些无效。

加强基线

我们都知道，没有强制执行的文件或政策只是一张纸。那么，您如何采用所创建的基准并加以实施，以使人们真正遵循呢？以及如何执行它而不阻止需要快速迁移的开发人员？

有几种方法可以做到这一点。一种是使用DivvyCloud之类的云安全状态管理（CSPM）解决方案，它可以帮助您创建和实施基准。这可以使您了解配置错误和策略合规性，以便及时进行补救。DivvyCloud是创建和实施可在多个帐户和多个云提供商之间使用的基准的好方法。DivvyCloud的另一个强大功能是，当发生故障或配置错误时，它可以自动修复有问题的资产以符合基准策略。

CSPM是企业级别的必需品。如果您在多个云提供商之间运行多个云帐户，则安全性会变得非常复杂。但是，如果您还不处于企业级别或尚不能投资CSPM，最好的方法是使用“基础架构即代码”解决方案，从而可以为云基础架构创建模板，根据您的要求正确配置所有内容基线。通过让开发人员使用这些模板来创建新的基础结构，不仅可以使开发人员以正确的配置快速轻松地部署所有内容，还可以大大减少人为错误的可能性。最受欢迎的基础架构即代码解决方案是Terraform因为它可以跨多个云提供商使用。但是，需要注意的重要一点是，仅创建基础结构即代码模板是不够的，您仍然需要一种方法来监视所有内容，仅因为您的云基础结构已正确部署并不意味着某人无法对其进行更改马路。您可以使用InsightVM产品中的云配置评估（CCA）功能之类的工具来监视错误配置。使用CCA之类的工具非常有用，因为您可以使用与监视其他形式的风险（例如软件漏洞）相同的工具来监视配置错误。AWS，Azure和GCP也具有自己的特定于平台的监视，但是重点是要使用某种形式的监视。

访问管理

简而言之，您应该限制谁可以访问您的云基础架构。首先，请确保用户正在使用单点登录（SSO）工具访问您的云帐户。您不希望将云登录信息与其他登录信息分开存储和管理，因为如果有人离开公司，您将无法轻松删除其对云基础架构和所有其他工具的访问权限。您还希望考虑在组或团队级别而不是个人级别分配权限。这样可以确保一致性，并避免混淆不匹配的用户权限。例如，使用AWS IAM（身份和访问管理），您可以为组织中的每个团队创建组，为该组的所有成员赋予相同的权限。在组级别和个人级别上更改权限还可以减少某人潜入雷达以获取其不应具有的访问权限的机会。

另一个重要的最佳实践是，除非绝对必要，否则不要使用root用户。根用户是建立云帐户时创建的用户。它具有其他用户（包括管理员）没有的访问权限。这个用户功能强大。如果该用户受到损害，则可能会造成一些相当严重的损害。为此，请确保仅在绝对必要时才使用根用户。在其余时间中，物理上会锁定根用户的凭据，并在使用时要求多因素身份验证（MFA）（坦率地说，您应该对所有用户）。大多数云平台都可以创建一个凭证报告，向您显示谁有权访问哪些凭证以及这些凭证的用途。这些报告可以帮助确定是否使用了root用户，如果使用了root用户，则在几乎所有情况下，您都可以创建权限受限的新用户来替换root用户。

设置漏洞监控

即使在云中，您仍在使用可能具有软件漏洞的虚拟机。就像本地网络一样，需要对其进行监视和打补丁。实例可以每分钟一分钟上下旋转，因此仅依靠每周一次的扫描报告无法充分了解当前的实际风险评分。这就是为什么您应在实例上使用Rapid7的Insight Agent之类的代理为您提供有关正在发生的情况和存在的漏洞的最新信息，以便您可以就补救措施做出明智的决定。

当检测到漏洞时，所有云提供商都可以使用补丁程序管理器来部署补丁程序，但是许多云环境是不可变的，这意味着它们旨在禁止对基础架构进行任何更改。在这些情况下，要纠正漏洞，您将创建一个新映像，该映像使用已安装补丁程序的更新的OS版本。然后，使用新映像创建新的虚拟机，然后终止旧实例。

记录一切

在进行安全调查时，日志是您最好的朋友。没有它们，您将在黑暗中射击。所有云提供商都提供日志记录功能。在AWS中，它是CloudTrail，在Azure中是Monitor，在GCP中是Cloud Logging。它记录重要的所有活动的所有地区和服务，即使你不是目前使用的人。正如我们在第一部分中所解释的，有人可以在您未积极使用或监视的区域中启动新服务，这就是为什么您应该监视所有区域和所有服务的原因。这些日志将告诉您正在发生的事情，以及是否有未经授权的访问。

从云提供商处收集日志后，请对其进行保护，以免对其进行操作。确保没有人可以访问它们并且它们已加密。大多数云提供商还提供验证文件，可以检测是否已更改某些内容。

然后，您需要一种通过警报对日志中可疑活动做出反应的方法。一种选择是使用云提供商提供的本机日志监视服务，以提醒您任何可疑的操作。在AWS中，此警报服务称为CloudWatch，在Azure中称为Monitor，在GCP中称为Cloud Monitoring。但是，这种方法的问题是您必须构建并维护每个警报，并且容易发生许多错误警报。

另一种选择是使用来自云提供商的威胁检测服务。在AWS中，它是Guard Duty，在Azure中，它是高级威胁防护，而在GCP中，它是事件威胁防护。但是，几乎每个组织都具有本地网络和远程员工以确保安全，并且这些服务无法监视那些环境。此外，随着安全团队变得越来越复杂，他们经常发现他们需要云提供商所提供产品中没有的功能。

这就是为什么许多公司使用具有威胁检测功能的第三方SIEM的原因，例如InsightIDR。使用这种工具，您可以在一处监视云环境和所有其他环境。如果攻击者横向移动，例如在受损的笔记本电脑和云环境之间移动，这尤其关键。您需要将数据全部集中在一个地方，以便进行全面调查，评估影响，找出攻击者现在的位置，以及您需要集中精力进行修复的地方。

巩固您的团队

简化流程是保持最高安全目标并确保正确分配和遵循策略和程序的关键。拥有独立的内部部署和云安全团队正在乞求成立孤岛，并产生不清楚的角色，这可能在事件期间造成混乱。一个统一的团队来监督安全性，以及一个监视所有环境的工具，可以使其保持简单。当然，您可以让一个团队拥有独立的子团队来处理云，内部部署等，但是您确实需要对负责确保环境的每个元素的人员有明确的责任感和责任。否则，任务可能会像土豆一样被传递出去，并且手指开始变尖。

自动化一切

自动化是当今（尤其是在云中）可伸缩性和效率的关键。云中的事物快速移动，仅人类无法跟上步伐，但自动化可以。您可以自动化配置基础结构，加入新员工甚至更新EC2实例的方式。一种方法是使用像InsightConnect这样的安全自动化和协调解决方案，该解决方案可以连接您的所有工具，简化容易发生人为错误的重复性任务，并提高人类根本无法实现的沟通和响应效率。您可以自动化的程度越高，人为错误成为一个因素的机会就越少。

版权申明：本站文章均来自网络，如有侵权，请联系01056159998 邮箱：itboby@foxmail.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有