🥇云安全监控 | 专业主机

将数据和应用程序移至云端对企业 SOC 提出了新的挑战，它们并不总是准备好监控其他人的基础设施。据 Netoskope 称，平均每个企业（显然是在美国）使用 1246 种不同的云服务，比一年前增加了 22%。 1246云服务！！！其中 175 个与人力资源服务相关，170 个与营销相关，110 个与通信领域相关，76 个与财务和 CRM 相关。思科“仅”使用 700 个外部云服务。所以我对这些数字有点困惑。但无论如何，问题不在于他们，而在于越来越多的公司开始非常积极地使用云，这些公司希望拥有与自己的网络相同的监控云基础设施的功能。而且这种趋势正在增长——根据根据美国会计协会的数据到 2023 年，美国将关闭 1200 个数据中心（已经关闭 6250 个）。但向云的过渡不仅仅是“让我们将服务器转移到外部提供商”。新的IT架构、新软件、新流程、新限制……这一切不仅给IT工作带来重大变化，也给信息安全工作带来重大变化。如果提供商已经学会以某种方式应对确保云本身的安全（幸运的是有很多建议），那么云信息安全监控，特别是在 SaaS 平台上，就会遇到很大的困难，我们将讨论这一点。

假设您的公司已将部分基础设施迁移到云端...停止。不是这样的。如果基础设施已经转移，而你现在才考虑如何监控它，那么你就已经输了。除非是亚马逊、谷歌或微软（然后有保留），否则你可能没有太多能力来监控你的数据和应用程序。如果您有机会使用日志，那就太好了。有时安全事件数据可用，但您无权访问它。例如，Office 365。如果您拥有最便宜的 E1 许可证，则您根本无法使用安全事件。如果您拥有 E3 许可证，您的数据仅存储 90 天，并且仅当您拥有 E5 许可证时，日志的持续时间才可用一年（但是，这也有其自身的细微差别，需要单独存储）向 Microsoft 支持请求许多处理日志的功能）。顺便说一下，E3许可证在监控功能方面比企业Exchange弱很多。要达到相同的级别，您需要 E5 许可证或额外的高级合规性许可证，这可能需要额外的资金，而这些资金并未计入您迁移到云基础设施的财务模型中。而这只是低估云信息安全监控相关问题的一个例子。在本文中，我不想假装完整，而是想提请大家注意从安全角度选择云提供商时应考虑的一些细微差别。在文章的最后，将给出一个清单，在考虑云信息安全监控问题已解决之前，值得完成该清单。

有几个典型问题会导致云环境中的事件，而信息安全服务没有时间响应或根本看不到它们：

安全日志不存在。这是一种相当普遍的情况，尤其是对于云解决方案市场的新手来说。但你不应该立即放弃它们。小型企业，尤其是国内企业，对客户需求更加敏感，可以通过改变已批准的产品路线图来快速实现一些所需的功能。是的，这不会是亚马逊的 GuardDuty 或 Bitrix 的“主动保护”模块的类似物，但至少是一些东西。
信息安全不知道日志存储在哪里，或者无法访问它们。这里有必要与云服务提供商进行谈判——如果他认为客户对他很重要，他也许会提供此类信息。但总的来说，当“通过特殊决定”提供日志访问权限时，情况并不是很好。
云提供商也有日志，但他们提供的监控和事件记录有限，不足以检测所有事件。例如，您可能只会收到网站上的更改日志或用户身份验证尝试的日志，但不会收到其他事件（例如网络流量），这将为您隐藏一整层旨在攻击您的云基础设施的事件。
有日志，但对它们的访问很难自动化，这迫使它们不能连续监控，而是按计划监控。而如果不能自动下载日志，那么下载日志，比如Excel格式的日志（国内很多云解决方案提供商都是如此），甚至可能会导致企业信息安全服务部门不愿意去修改。
无日志监控。这或许是云环境中信息安全事件发生最不明确的原因。似乎有日志，并且可以自动访问它们，但没有人这样做。为什么？

共享云安全理念

向云的过渡始终是在保持对基础设施的控制的愿望与将其转移到专门负责维护基础设施的云提供商的更专业的手中之间寻求平衡。而在云安全领域，也必须寻求这种平衡。此外，根据所使用的云服务交付模型（IaaS、PaaS、SaaS），这种平衡始终会有所不同。无论如何，我们必须记住，当今所有云提供商都遵循所谓的共同责任和共享信息安全模型。云负责一些事情，而另一些事情则由客户端负责，将他的数据、他的应用程序、他的虚拟机和其他资源放在云中。期望通过转向云，我们将把所有责任转移给提供商，这是鲁莽的。但在迁移到云时自行构建所有安全性也是不明智的。需要一种平衡，这取决于许多因素： - 风险管理策略、威胁模型、云提供商可用的安全机制、立法等。

例如，对云中托管的数据进行分类始终是客户的责任。云提供商或外部服务提供商只能帮助他提供一些工具来帮助标记云中的数据、识别违规行为、删除违法数据或使用一种或另一种方法掩盖数据。另一方面，物理安全始终是云提供商的责任，无法与客户共享。但数据和物理基础设施之间的一切恰恰是本文讨论的主题。例如，云的可用性是提供商的责任，而设置防火墙规则或启用加密是客户的责任。在本文中，我们将尝试了解俄罗斯各种流行的云提供商提供了哪些信息安全监控机制，它们的使用特点是什么，以及何时值得考虑外部覆盖解决方案（例如，Cisco E-邮件安全），可扩展云在网络安全方面的功能。在某些情况下，特别是如果您遵循多云策略，您将别无选择，只能同时在多个云环境中使用外部信息安全监控解决方案（例如，Cisco CloudLock 或 Cisco Stealthwatch Cloud）。好吧，在某些情况下，您会意识到您选择的（或强加给您的）云提供商根本不提供任何信息安全监控功能。这是令人不快的，但也不是一点点，因为它允许您充分评估与使用此云相关的风险级别。

云安全监控生命周期

要监控您使用的云的安全性，您只有三个选择：

依赖云提供商提供的工具，
使用第三方解决方案来监控您使用的 IaaS、PaaS 或 SaaS 平台，
构建您自己的云监控基础设施（仅适用于IaaS/PaaS平台）。

让我们看看这些选项都有哪些功能。但首先，我们需要了解监控云平台时将使用的通用框架。我想强调云中信息安全监控流程的 6 个主要组成部分：

基础设施准备。确定必要的应用程序和基础设施，以将对于信息安全重要的事件收集到存储中。
收藏。在此阶段，从各个来源聚合安全事件，以便后续传输进行处理、存储和分析。
治疗。在这个阶段，对数据进行转换和丰富，以方便后续分析。
贮存。该组件负责短期和长期存储收集的已处理数据和原始数据。
分析。在此阶段，您可以自动或手动检测事件并做出响应。
报告。此阶段有助于为利益相关者（管理层、审计师、云提供商、客户等）制定关键指标，帮助我们做出某些决策，例如更换提供商或加强信息安全。

了解这些组成部分将使您将来能够快速决定可以从提供商那里获得什么，以及您必须自己做或在外部顾问的参与下做什么。

内置云服务

我在上面已经写过，当今许多云服务不提供任何信息安全监控功能。总的来说，他们不太关注信息安全这个话题。例如，俄罗斯流行的一种通过互联网向政府机构发送报告的服务（我不会具体提及它的名字）。有关此服务安全性的整个部分都围绕着经过认证的 CIPF 的使用。国内另一家电子文档管理云服务的信息安全部分也不例外。它讨论了公钥证书、经过认证的加密技术、消除 Web 漏洞、防御 DDoS 攻击、使用防火墙、备份，甚至定期的信息安全审核。但没有提及监控，也没有提及访问该服务提供商的客户可能感兴趣的信息安全事件的可能性。

一般来说，通过云提供商在其网站和文档中描述信息安全问题的方式，您可以了解其对这个问题的重视程度。例如，如果您阅读“My Office”产品的手册，则根本没有有关安全性的字眼，但在单独产品“My Office”的文档中却没有任何有关安全性的字眼。 KS3”，旨在防止未经授权的访问，通常列出了“My Office.KS17”实现的 FSTEC 第 3 阶要点，但没有描述它是如何实现的，最重要的是，如何实现将这些机制与企业信息安全相结合。也许这样的文档存在，但我没有在公共领域的“My Office”网站上找到它。虽然也许我只是无权访问这些秘密信息？...

对于 Bitrix 来说，情况要好得多。该文档描述了事件日志的格式，有趣的是，还描述了入侵日志，其中包含与云平台潜在威胁相关的事件。从那里您可以提取 IP、用户或访客名称、事件源、时间、用户代理、事件类型等。确实，您可以从云本身的控制面板处理这些事件，也可以上传 MS Excel 格式的数据。现在很难自动处理 Bitrix 日志，您必须手动完成一些工作（上传报告并将其加载到 SIEM 中）。但如果我们记得直到最近这样的机会还不存在，那么这就是巨大的进步。同时，我想指出的是，许多国外云提供商都提供了类似的“针对初学者”的功能——要么通过控制面板用眼睛看日志，要么将数据上传给自己（但是，大多数以. csv 格式，而不是 Excel）。

在不考虑无日志选项的情况下，云提供商通常会为您提供三种监控安全事件的选项：仪表板、数据上传和 API 访问。第一个似乎可以为您解决许多问题，但这并不完全正确 - 如果您有几本杂志，您必须在显示它们的屏幕之间切换，从而失去整体图片。此外，云提供商不太可能为您提供关联安全事件并从安全角度一般分析它们的能力（通常您正在处理原始数据，您需要自己了解这些数据）。也有例外，我们将进一步讨论它们。最后，值得问一下您的云提供商记录了哪些事件、以什么格式以及它们如何与您的信息安全监控流程相对应？例如，用户和访客的识别和认证。相同的 Bitrix 允许您根据这些事件记录事件的日期和时间、用户或访客的姓名（如果您有“Web Analytics”模块）、访问的对象以及网站的其他典型元素。但企业信息安全服务可能需要有关用户是否从可信设备访问云的信息（例如，在企业网络中，此任务由思科 ISE 实施）。像geo-IP功能这样简单的任务如何帮助确定云服务用户帐户是否被盗？即使云提供商为您提供了它，这也还不够。同样的 Cisco CloudLock 不仅分析地理位置，还使用机器学习来分析每个用户的历史数据，并监控识别和身份验证尝试中的各种异常情况。只有 MS Azure 具有类似的功能（如果您有适当的订阅）。

还有另一个困难 - 由于对于许多云提供商来说，信息安全监控是他们刚刚开始处理的新主题，因此他们不断改变解决方案中的某些内容。今天他们有一个版本的 API，明天有另一个版本，后天有第三个版本。您还需要为此做好准备。功能也是如此，功能可能会发生变化，您的信息安全监控系统必须考虑到这一点。例如，Amazon 最初拥有单独的云事件监控服务——AWS CloudTrail 和 AWS CloudWatch。随后出现了一个单独的用于监控信息安全事件的服务——AWS GuardDuty。一段时间后，亚马逊推出了新的管理系统 Amazon Security Hub，其中包括对从 GuardDuty、Amazon Inspector、Amazon Macie 和其他几个系统收到的数据进行分析。另一个例子是 Azure 日志与 SIEM 集成工具 - AzLog。它被许多 SIEM 厂商积极使用，直到 2018 年微软宣布停止开发和支持，这让许多使用该工具的客户遇到了问题（我们稍后会讲如何解决）。

因此，请仔细监控云提供商为您提供的所有监控功能。或者依赖外部解决方案提供商，他们将充当您的 SOC 和您要监控的云之间的中介。是的，它会更昂贵（尽管并非总是如此），但你会将所有责任转移到别人的肩上。或者不是全部？...让我们记住共享安全的概念，并了解我们无法改变任何事情 - 我们必须独立了解不同的云提供商如何提供对数据、应用程序、虚拟机和其他资源的信息安全的监控托管在云中。我们将从亚马逊在这一部分中提供的内容开始。

示例：基于AWS的IaaS信息安全监控

是的，是的，我知道亚马逊不是最好的例子，因为这是一项美国服务，它可以作为打击极端主义和传播俄罗斯禁止的信息的一部分而被封锁。但在这篇文章中，我只想从安全的角度展示不同的云平台在信息安全监控能力上的差异，以及在将关键流程转移到云端时应该注意什么。好吧，如果一些俄罗斯云解决方案开发人员学到了一些对自己有用的东西，那就太好了。

首先要说的是，亚马逊并不是一座坚不可摧的堡垒。他的客户经常发生各种事件。例如，198 亿选民的姓名、地址、出生日期和电话号码被从 Deep Root Analytics 中窃取。以色列公司 Nice Systems 窃取了 Verizon 用户的 14 万条记录。但是，AWS 的内置功能允许您检测各种事件。例如：

对基础设施的影响 (DDoS)
节点妥协（命令注入）
帐户泄露和未经授权的访问
不正确的配置和漏洞
不安全的接口和 API。

造成这种差异的原因是，正如我们上面所发现的，客户自己对客户数据的安全负责。而如果他懒得开启保护机制，不开启监控工具，那么他只会从媒体或者从他的客户那里得知这起事件。

为了识别事件，您可以使用 Amazon 开发的各种不同的监控服务（尽管这些服务通常由 osquery 等外部工具进行补充）。因此，在 AWS 中，所有用户操作都会受到监控，无论它们是如何执行的 - 通过管理控制台、命令行、SDK 或其他 AWS 服务。每个 AWS 账户的活动（包括用户名、操作、服务、活动参数和结果）和 API 使用情况的所有记录均可通过 AWS CloudTrail 获取。您可以从 CloudTrail 控制台查看这些事件（例如 AWS IAM 控制台登录），使用 Amazon Athena 分析它们，或将它们“外包”给外部解决方案，例如 Splunk、AlienVault 等。 AWS CloudTrail 日志本身放置在您的 AWS S3 存储桶中。

另外两项 AWS 服务提供了许多其他重要的监控功能。首先，Amazon CloudWatch 是一项针对 AWS 资源和应用程序的监控服务，除其他外，它还允许您识别云中的各种异常情况。所有内置 AWS 服务，例如 Amazon Elastic Compute Cloud（服务器）、Amazon Relational Database Service（数据库）、Amazon Elastic MapReduce（数据分析）和 30 种其他 Amazon 服务，都使用 Amazon CloudWatch 来存储其日志。开发人员可以使用 Amazon CloudWatch 的开放 API 将日志监控功能添加到自定义应用程序和服务中，从而允许他们扩展安全上下文中的事件分析范围。

其次，VPC 流日志服务允许您分析 AWS 服务器（外部或内部）以及微服务之间发送或接收的网络流量。当您的任何 AWS VPC 资源与网络交互时，VPC 流日志会记录有关网络流量的详细信息，包括源和目标网络接口，以及您的 IP 地址、端口、协议、字节数和数据包数。锯。那些对本地网络安全有经验的人会认为这类似于线程网络流，可以由交换机、路由器和企业级防火墙创建。这些日志对于信息安全监控非常重要，因为与有关用户和应用程序操作的事件不同，它们还允许您不错过 AWS 虚拟私有云环境中的网络交互。

总之，这三项 AWS 服务（AWS CloudTrail、Amazon CloudWatch 和 VPC Flow Logs）共同提供了对您的账户使用情况、用户行为、基础设施管理、应用程序和服务活动以及网络活动的相当强大的洞察。例如，它们可用于检测以下异常：

尝试扫描网站、搜索后门、通过突发的“404 错误”搜索漏洞。
通过突发“500 错误”进行注入攻击（例如 SQL 注入）。
已知的攻击工具有sqlmap、nikto、w3af、nmap等。通过对User Agent字段的分析。

Amazon Web Services 还出于网络安全目的开发了其他服务，可让您解决许多其他问题。例如，AWS 有一个用于审核策略和配置的内置服务 - AWS Config。该服务提供对您的 AWS 资源及其配置的持续审核。让我们举一个简单的例子：假设您想要确保在所有服务器上禁用用户密码，并且只能基于证书进行访问。 AWS Config 可以轻松检查所有服务器的这一点。还有其他策略可以应用于您的云服务器：“没有服务器可以使用端口 22”、“只有管理员可以更改防火墙规则”或“只有用户 Ivashko 可以创建新的用户帐户，而且他只能在星期二进行。 ” 2016 年夏天，AWS Config 服务得到扩展，可以自动检测违反已制定策略的情况。 AWS Config 规则本质上是对您使用的 Amazon 服务的连续配置请求，如果违反相应的策略，则会生成事件。例如，可以使用 AWS Config 规则持续检查服务器磁盘以确保满足此条件，而不是定期运行 AWS Config 查询来验证虚拟服务器上的所有磁盘都已加密。最重要的是，在本出版物中，任何违规行为都会生成可供您的信息安全服务分析的事件。

AWS 还拥有与传统企业信息安全解决方案相当的解决方案，它也会生成您可以并且应该分析的安全事件：

入侵检测 - AWS GuardDuty
信息泄漏控制 - AWS Macie
EDR（虽然它谈论云中的端点有点奇怪） - AWS Cloudwatch + 开源 osquery 或 GRR 解决方案
Netflow 分析 - AWS Cloudwatch + AWS VPC Flow
DNS 分析 - AWS Cloudwatch + AWS Route53
AD-AWS 目录服务
账户管理 - AWS IAM
SSO-AWS 单点登录
安全分析 - AWS Inspector
配置管理 - AWS Config
WAF - AWS WAF。

我不会详细描述在信息安全方面可能有用的所有亚马逊服务。最重要的是要了解，所有这些都可以生成我们可以并且应该在信息安全背景下进行分析的事件，为此目的，使用 Amazon 本身的内置功能和外部解决方案，例如 SIEM，它可以将安全事件发送到您的监控中心，并与来自其他云服务或内部基础设施、周边或移动设备的事件一起进行分析。

无论如何，这一切都始于为您提供信息安全事件的数据源。这些来源包括但不限于：

CloudTrail - API 使用和用户操作
Trusted Advisor - 根据最佳实践进行安全检查
配置 - 帐户和服务设置的清单和配置
VPC 流日志 - 与虚拟接口的连接
IAM-身份识别和认证服务
ELB访问日志-负载均衡器
检查器 - 应用程序漏洞
S3——文件存储
CloudWatch - 应用程序活动
SNS 是一种通知服务。

亚马逊虽然为其生成提供了如此广泛的事件源和工具，但其在信息安全背景下分析收集的数据的能力非常有限。您必须独立研究可用的日志，寻找其中的相关妥协指标。亚马逊最近推出的 AWS Security Hub 旨在通过成为 AWS 的云 SIEM 来解决这个问题。但到目前为止，它才刚刚开始，并且受到与其合作的来源数量以及亚马逊本身的架构和订阅所建立的其他限制的限制。

示例：基于Azure的IaaS信息安全监控

我不想就三个云提供商（亚马逊、微软或谷歌）中哪一个更好进行长时间的争论（特别是因为他们每个人仍然有自己的具体细节并且适合解决自己的问题）；我们重点关注一下这些厂商提供的信息安全监控能力。必须承认的是，亚马逊AWS是这一领域的先驱之一，因此在信息安全功能方面走得最远（尽管许多人承认它们很难使用）。但这并不意味着我们会忽视微软和谷歌为我们提供的机会。

微软的产品一向以“开放性”着称，Azure的情况也类似。例如，如果AWS和GCP总是从“不允许的就是禁止的”的概念出发，那么Azure的做法恰恰相反。例如，在云中创建虚拟网络并在其中创建虚拟机时，默认情况下所有端口和协议都是开放和允许的。因此，您将不得不花费更多的精力来对 Microsoft 云中的访问控制系统进行初始设置。这也对您在 Azure 云中的监控活动提出了更严格的要求。

AWS 有一个特点，当您监控虚拟资源时，如果它们位于不同的区域，那么您很难将所有事件结合起来进行统一分析，为了消除这种情况，您需要采取各种技巧，例如为 AWS Lambda 创建您自己的代码，用于在区域之间传输事件。 Azure 不存在这个问题 - 它的活动日志机制可以不受限制地跟踪整个组织的所有活动。这同样适用于 AWS Security Hub，它是亚马逊最近开发的，旨在将许多安全功能整合到一个安全中心内，但仅限于其所在区域内，但这与俄罗斯无关。 Azure拥有自己的安全中心，不受区域限制，提供云平台所有安全功能的访问。此外，对于不同的本地团队，它可以提供自己的一套保护功能，包括他们管理的安全事件。 AWS Security Hub 仍在努力变得与 Azure 安全中心类似。但值得补充的是美中不足 - 您可以从 Azure 中挤出很多之前在 AWS 中描述的功能，但这仅适用于 Azure AD、Azure Monitor 和 Azure Security Center。所有其他 Azure 安全机制（包括安全事件分析）尚未以最方便的方式进行管理。该问题已通过 API 得到部分解决，该 API 渗透到所有 Microsoft Azure 服务中，但这需要您付出额外的努力来将云与 SOC 集成，并且需要合格的专家（事实上，与任何其他与云配合使用的 SIEM 一样）蜜蜂）。稍后将讨论的一些 SIEM 已经支持 Azure 并可以自动执行监视它的任务，但它也有其自身的困难 - 并非所有 SIEM 都可以收集 Azure 拥有的所有日志。

Azure 中的事件收集和监视是使用 Azure Monitor 服务提供的，它是收集、存储和分析 Microsoft 云及其资源（Git 存储库、容器、虚拟机、应用程序等）中的数据的主要工具。 Azure Monitor 收集的所有数据分为两类：指标（实时收集并描述 Azure 云的关键性能指标）和日志（包含组织成记录的数据，描述 Azure 资源和服务活动的某些方面）。此外，使用数据收集器 API，Azure Monitor 服务可以从任何 REST 源收集数据以构建自己的监视方案。

以下是 Azure 为你提供的一些安全事件源，你可以通过 Azure 门户、CLI、PowerShell 或 REST API 访问这些事件源（有些只能通过 Azure Monitor/Insight API）：

活动日志 - 此日志回答了有关云资源上的任何写入操作（PUT、POST、DELETE）的“谁”、“什么”和“何时”等经典问题。与其他一些事件一样，与读取访问 (GET) 相关的事件不包含在此日志中。
诊断日志 - 包含有关订阅中包含的特定资源的操作数据。
Azure AD 报告 - 包含与组和用户管理相关的用户活动和系统活动。
Windows 事件日志和 Linux 系统日志 - 包含来自云中托管的虚拟机的事件。
指标 - 包含有关云服务和资源的性能和运行状况的遥测数据。每分钟测量一次并存储。 30天内。
网络安全组流日志 - 包含使用网络观察器服务和网络级别的资源监控收集的网络安全事件的数据。
存储日志 - 包含与访问存储设施相关的事件。

对于监视，可以使用外部 SIEM 或内置 Azure Monitor 及其扩展。稍后我们将讨论信息安全事件管理系统，但现在让我们看看 Azure 本身为我们提供了哪些安全上下文中的数据分析功能。 Azure Monitor 中与安全相关的所有内容的主屏幕是 Log Analytics 安全和审核仪表板（免费版本仅支持一周的有限数量的事件存储）。该仪表板分为 5 个主要区域，以可视化方式显示您正在使用的云环境中发生的情况的摘要统计信息：

安全域——与信息安全相关的关键量化指标——事件数量、受损节点数量、未打补丁的节点数量、网络安全事件等。
值得注意的问题 - 显示活跃信息安全问题的数量和重要性
检测 - 显示针对您的攻击模式
威胁情报 - 显示正在攻击您的外部节点的地理信息
常见安全查询 - 典型查询将帮助您更好地监控信息安全。

Azure Monitor 扩展包括 Azure Key Vault（保护云中的加密密钥）、恶意软件评估（分析虚拟机上的恶意代码防护）、Azure 应用程序网关分析（分析云防火墙日志等）等。。这些工具丰富了处理事件的某些规则，使您可以可视化云服务活动的各个方面（包括安全性），并识别操作中的某些偏差。但是，正如经常发生的那样，任何附加功能都需要相应的付费订阅，这将需要您相应的财务投资，您需要提前计划。

Azure 具有许多内置威胁监视功能，这些功能集成到 Azure AD、Azure Monitor 和 Azure 安全中心中。其中，例如，检测虚拟机与已知恶意IP的交互（由于存在与微软威胁情报服务的集成）、通过接收云中托管的虚拟机的警报来检测云基础设施中的恶意软件、密码虚拟机上的“猜测攻击”、用户识别系统配置中的漏洞、从匿名器或受感染节点登录系统、帐户泄露、从异常位置登录系统等。如今，Azure 是为数不多的为你提供内置威胁情报功能以丰富收集的信息安全事件的云提供商之一。

如上所述，安全功能及其生成的安全事件并非对所有用户均等可用，而是需要包含您所需功能的特定订阅，从而生成适当的事件以进行信息安全监控。例如，上一段中描述的一些用于监视帐户异常的功能仅在 Azure AD 服务的 P2 高级许可证中可用。如果没有它，您将不得不“手动”分析收集到的安全事件，就像 AWS 的情况一样。此外，根据 Azure AD 许可证的类型，并非所有事件都可用于分析。

在 Azure 门户上，您可以管理您感兴趣的日志的搜索查询，并设置仪表板以可视化关键信息安全指标。此外，您还可以选择Azure Monitor扩展，它允许您扩展Azure Monitor日志的功能，并从安全角度对事件进行更深入的分析。

如果你不仅需要使用日志的能力，还需要为你的Azure云平台提供一个全面的安全中心，包括信息安全策略管理，那么你可以谈论需要使用Azure安全中心，其中大部分有用的功能需要花费一些钱才能获得，例如威胁检测、Azure 外部监控、合规性评估等。（在免费版本中，您只能访问安全评估和消除已识别问题的建议）。它将所有安全问题整合到一处。事实上，我们可以谈论比 Azure Monitor 为您提供的更高级别的信息安全，因为在这种情况下，通过使用许多来源丰富了整个云工厂收集的数据，例如 Azure、Office 365、Microsoft CRM Online、Microsoft Dynamics AX 、outlook.com、MSN.com、微软数字犯罪部门（DCU）和微软安全响应中心（MSRC），其上叠加了各种复杂的机器学习和行为分析算法，最终应该提高检测和响应威胁的效率。

Azure 也有自己的 SIEM - 它于 2019 年初出现。这就是Azure Sentinel，它依赖于Azure Monitor的数据，也可以与之集成。外部安全解决方案（例如 NGFW 或 WAF），其数量不断增加。此外，通过集成 Microsoft Graph 安全 API，您可以将自己的威胁情报源连接到 Sentinel，从而丰富了分析 Azure 云中事件的功能。可以说，Azure Sentinel是第一个来自云提供商的“原生”SIEM（同样可以托管在云中的Splunk或ELK，例如AWS，仍然不是传统云服务提供商开发的）。 Azure Sentinel 和安全中心可以称为 Azure 云的 SOC，并且如果您不再拥有任何基础设施并且将所有计算资源转移到云中（这将是 Microsoft 云 Azure），则可能仅限于它们（有一定保留）。

但由于 Azure 的内置功能（即使您订阅了 Sentinel）通常不足以监控信息安全并将此过程与其他安全事件源（云和内部）集成，因此有一个需要将收集到的数据导出到外部系统，其中可能包括 SIEM。这是通过使用 API 和特殊扩展来完成的，这些扩展目前仅正式适用于以下 SIEM - Splunk（适用于 Splunk 的 Azure Monitor 附加组件）、IBM QRadar (Microsoft Azure DSM)、SumoLogic、ArcSight 和 ELK。直到最近，还有更多这样的 SIEM，但从 1 年 2019 月 XNUMX 日起，Microsoft 停止支持 Azure 日志集成工具 (AzLog)，该工具是在 Azure 出现之初且缺乏处理日志的正常标准化 (Azure Monitor 甚至还不存在）使得外部 SIEM 与 Microsoft 云的集成变得容易。现在情况发生了变化，微软推荐Azure Event Hub平台作为其他SIEM的主要集成工具。许多人已经实现了此类集成，但要小心 - 他们可能不会捕获所有 Azure 日志，而只会捕获部分日志（请参阅 SIEM 文档）。

在结束对 Azure 的简短游览之后，我想给出有关此云服务的一般性建议 - 在您谈论 Azure 中的信息安全监控功能之前，您应该非常仔细地配置它们并测试它们是否按照文档中所写的那样工作，并且正如微软顾问告诉你的那样（他们可能对 Azure 函数的功能有不同的看法）。如果有财力，在信息安全监控方面，可以从Azure中挤出很多有用的信息。如果您的资源有限，那么就像AWS的情况一样，您将只能依靠自己的力量和Azure Monitor为您提供的原始数据。请记住，许多监控功能需要花钱，最好提前熟悉定价政策。例如，您可以免费存储 31 天的数据，每个客户最多可存储 5 GB - 超过这些值将需要您支付额外的费用（客户每增加 GB 存储大约需要 2 美元以上，存储每 GB 大约需要 0,1 美元）每个月存储 1 GB ）。使用应用程序遥测和指标以及使用警报和通知也可能需要额外的资金（有一定的限制是免费的，这可能不足以满足您的需求）。

示例：基于Google Cloud Platform的IaaS信息安全监控

与 AWS 和 Azure 相比，谷歌云平台看起来还很年轻，但这在一定程度上是好的。与AWS不同的是，AWS逐渐增强了其功能，包括安全功能，但存在中心化问题； GCP 与 Azure 一样，可以更好地进行集中管理，从而减少整个企业的错误和实施时间。奇怪的是，从安全角度来看，GCP 介于 AWS 和 Azure 之间。他还为整个组织进行了一次活动注册，但并不完整。部分功能仍处于测试阶段，但逐渐消除这一缺陷，GCP将成为信息安全监控方面更加成熟的平台。

GCP 中记录事件的主要工具是 Stackdriver Logging（类似于 Azure Monitor），它允许您收集整个云基础设施（以及来自 AWS）的事件。从 GCP 的安全角度来看，每个组织、项目或文件夹都有四个日志：

管理活动 - 包含与管理访问相关的所有事件，例如创建虚拟机、更改访问权限等。无论您的意愿如何，该日志都会被写入，并存储其数据 400 天。
数据访问 - 包含与云用户处理数据相关的所有事件（创建、修改、读取等）。默认情况下，不会写入此日志，因为它的体积膨胀得非常快。因此，它的保质期只有30天。此外，这本杂志上并没有写所有内容。例如，与所有用户均可公开访问或无需登录 GCP 即可访问的资源相关的事件不会写入其中。
系统事件 - 包含与用户无关的系统事件，或更改云资源配置的管理员操作。它始终被写入并存储 400 天。
Access Transparency 是一个独特的日志示例，它捕获在工作职责中访问您的基础设施的 Google 员工（但尚未涵盖所有 GCP 服务）的所有操作。该日志将存储 400 天，并且并非对每个 GCP 客户都可用，但前提是满足许多条件（黄金级或白金级支持，或者作为公司支持的一部分存在某种类型的 4 个角色）。类似的功能也可用，例如在 Office 365 - Lockbox 中。

日志示例：访问透明度

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

可以通过多种方式访问这些日志（与之前讨论的 Azure 和 AWS 的方式大致相同） - 通过日志查看器界面、通过 API、通过 Google Cloud SDK 或通过您所在项目的活动页面对活动感兴趣。以同样的方式，它们可以导出到外部解决方案以进行额外分析。后者是通过将日志导出到 BigQuery 或 Cloud Pub/Sub 存储来完成的。

除了 Stackdriver Logging 之外，GCP 平台还提供 Stackdriver Monitoring 功能，该功能允许您监控云服务和应用程序的关键指标（性能、MTBF、整体运行状况等）。经过处理和可视化的数据可以让您更轻松地发现云基础设施中的问题，包括安全方面的问题。但应该注意的是，在信息安全的背景下，此功能不会非常丰富，因为今天 GCP 没有相同 AWS GuardDuty 的类似物，并且无法识别所有注册事件中的不良事件（Google 开发了事件威胁检测，但它仍处于测试阶段，现在谈论它的用处还为时过早）。 Stackdriver Monitoring 可以用作检测异常的系统，然后对其进行调查以找出其发生的原因。但鉴于市场上缺乏GCP信息安全领域的合格人才，这项任务目前看起来很困难。

还值得提供一些可在 GCP 云中使用的信息安全模块的列表，这些模块与 AWS 提供的类似：

Cloud Security Command Center 类似于 AWS Security Hub 和 Azure Security Center。
云 DLP - 使用 90 多种预定义分类策略自动发现和编辑（例如屏蔽）云中托管的数据。
Cloud Scanner 是一款针对 App Engine、Compute Engine 和 Google Kubernetes 中已知漏洞（XSS、Flash 注入、未修补的库等）的扫描器。
Cloud IAM - 控制对所有 GCP 资源的访问。
Cloud Identity - 从单个控制台管理 GCP 用户、设备和应用程序帐户。
云 HSM - 保护加密密钥。
云密钥管理服务 - GCP 中加密密钥的管理。
VPC 服务控制 - 在 GCP 资源周围创建安全边界，以防止泄漏。
Titan 安全密钥 - 防止网络钓鱼。

其中许多模块都会生成安全事件，这些事件可以发送到 BigQuery 存储进行分析或导出到其他系统（包括 SIEM）。如上所述，GCP是一个积极开发的平台，谷歌目前正在为其平台开发许多新的信息安全模块。其中包括事件威胁检测（现已推出测试版），它会扫描 Stackdriver 日志以搜索未经授权的活动痕迹（类似于 AWS 中的 GuardDuty），或策略智能（在测试版中提供），它允许您针对以下情况制定智能策略：访问 GCP 资源。

我对流行云平台的内置监控功能做了一个简短的概述。但是，您是否有能够处理“原始”IaaS 提供商日志的专家（并非每个人都准备好购买 AWS、Azure 或 Google 的高级功能）？此外，许多人都熟悉“信任，但要验证”这句格言，这在安全领域比以往任何时候都更加真实。您对向您发送信息安全事件的云提供商的内置功能有多信任？他们对信息安全的关注程度如何？

有时值得考虑可以补充内置云安全性的覆盖云基础设施监控解决方案，有时此类解决方案是深入了解云中托管的数据和应用程序安全性的唯一选择。此外，它们更加方便，因为它们承担了分析来自不同云提供商的不同云服务生成的必要日志的所有任务。这种覆盖解决方案的一个例子是思科 Stealthwatch Cloud，它专注于单一任务 - 监控云环境中的信息安全异常，不仅包括 Amazon AWS、Microsoft Azure 和 Google Cloud Platform，还包括私有云。

示例：使用 Stealthwatch Cloud 进行信息安全监控

AWS提供了灵活的计算平台，但这种灵活性使企业更容易犯错误，从而导致安全问题。共享信息安全模型只会对此做出贡献。在云中运行的软件存在未知漏洞（已知漏洞可以通过 AWS Inspector 或 GCP Cloud Scanner 等进行对抗）、弱密码、不正确的配置、内部人员等。而这一切都体现在云资源的行为中，可以通过思科 Stealthwatch Cloud 进行监控，这是一个信息安全监控和攻击检测系统。公共云和私有云。

思科 Stealthwatch Cloud 的主要功能之一是对实体进行建模的能力。有了它，您可以为每个云资源（无论是 AWS、Azure、GCP 还是其他资源）创建软件模型（即近实时模拟）。其中可以包括服务器和用户，以及特定于云环境的资源类型，例如安全组和自动缩放组。这些模型使用云服务提供的结构化数据流作为输入。例如，对于 AWS，这些将是 VPC Flow Logs、AWS CloudTrail、AWS CloudWatch、AWS Config、AWS Inspector、AWS Lambda 和 AWS IAM。实体建模会自动发现任何资源的角色和行为（您可以谈论分析所有云活动）。这些角色包括 Android 或 Apple 移动设备、Citrix PVS 服务器、RDP 服务器、邮件网关、VoIP 客户端、终端服务器、域控制器等。然后，它会持续监控他们的行为，以确定何时发生危险或威胁安全的行为。您可以识别密码猜测、DDoS 攻击、数据泄露、非法远程访问、恶意代码活动、漏洞扫描和其他威胁。例如，检测从对您的组织来说不典型的国家/地区（韩国）通过 SSH 对 Kubernetes 集群进行远程访问尝试的情况如下所示：

这就是所谓的从 Postgress 数据库泄露信息到一个我们之前没有接触过的国家的情况：

最后，这是来自中国和印度尼西亚的来自外部远程设备的太多失败的 SSH 尝试的样子：

或者，假设根据策略，VPC 中的服务器实例永远不会成为远程登录目标。我们进一步假设该计算机由于防火墙规则策略的错误更改而经历了远程登录。实体建模功能将近乎实时地检测并报告此活动（“异常远程访问”），并指向特定的 AWS CloudTrail、Azure Monitor 或 GCP Stackdriver Logging API 调用（包括用户名、日期和时间等详细信息） ).这促使国际电联规则发生变化。然后这些信息可以发送到 SIEM 进行分析。

思科 Stealthwatch 云支持的任何云环境都可以实现类似的功能：

实体建模是一种独特的安全自动化形式，可以发现人员、流程或技术中以前未知的问题。例如，它允许您检测安全问题，例如：

有人在我们使用的软件中发现了后门吗？
我们的云中是否有第三方软件或设备？
授权用户是否滥用权限？
是否存在允许远程访问或其他意外使用资源的配置错误？
我们的服务器是否存在数据泄露？
是否有人试图从非典型地理位置连接到我们？
我们的云是否感染了恶意代码？

检测到的信息安全事件可以以相应票证的形式发送到 Slack、Cisco Spark、PagerDuty 事件管理系统，也可以发送到各种 SIEM，包括 Splunk 或 ELK。总而言之，我们可以说，如果您的公司采用多云策略并且不限于任何一个云提供商，具有上述信息安全监控功能，那么使用 Cisco Stealthwatch Cloud 是获得一套统一监控的不错选择为领先的云厂商——亚马逊、微软和谷歌提供能力。最有趣的是，如果您将 Stealthwatch Cloud 的价格与 AWS、Azure 或 GCP 中信息安全监控的高级许可证进行比较，结果可能会发现，思科解决方案甚至比亚马逊、微软的内置功能还要便宜。和谷歌解决方案。这很矛盾，但却是事实。您使用的云及其功能越多，整合解决方案的优势就越明显。

此外，Stealthwatch Cloud还可以监控您组织中部署的私有云，例如基于Kubernetes容器或通过监控Netflow流量或通过网络设备（甚至是国产）镜像接收的网络流量、AD数据或DNS服务器等。所有这些数据都将通过思科 Talos（全球最大的非政府网络安全威胁研究人员组织）收集的威胁情报信息得到丰富。

这使您可以为您的公司可能使用的公共云和混合云实施统一的监控系统。然后可以使用 Stealthwatch Cloud 的内置功能对收集到的信息进行分析或将其发送到您的 SIEM（默认支持 Splunk、ELK、SumoLogic 等）。

至此，我们将完成本文的第一部分，其中我回顾了用于监控 IaaS/PaaS 平台信息安全的内置和外部工具，这些工具使我们能够快速检测和响应云环境中发生的事件我们的企业选择了。在第二部分中，我们将继续这个主题，并以 Salesforce 和 Dropbox 为例来研究监控 SaaS 平台的选项，并且我们还将尝试通过为不同的云提供商创建统一的信息安全监控系统来总结和整合所有内容。

来源： habr.com

云安全监控