👨‍🚒 🤷🏽 👨🏻‍🎨 云安全监控 🙍🏿 👨‍❤️‍👨 🕺🏽

对于无法始终监控他人基础架构的公司SOC，将数据和应用程序传输到云是一个新问题。根据Netoskope的说法，一家中型企业（显然仍在美国）使用了1246种不同的云服务，比一年前增长了22％。 1246云服务！！！其中175个涉及人力资源服务，170个涉及市场营销，110个涉及通信领域，76个涉及金融和CRM。思科总共使用了700个外部云服务。因此，我对这些数字感到有些困惑。但是无论如何，问题不在于它们，而是事实上，越来越多的公司正在积极使用云，这些公司希望拥有与自己的网络相同的监控云基础架构的功能。而且这种趋势正在增长-根据美国审计署的数据，到2023年，美国将关闭1200个数据中心（已经关闭了6250个）。但是，向云的过渡不仅是“而是让我们将服务器转移到外部提供商”。新的IT体系结构，新的软件，新的流程，新的限制...所有这些不仅对IT的工作做出了重大改变，而且对信息安全也做出了重大更改。而且，如果提供商学习了如何应对云本身的安全性（建议的好处很多），那么信息安全的云监控将面临很大的困难，尤其是在SaaS平台上，我们将在后面进行讨论。

假设您的公司已将部分基础架构移至云端...停下来。不是那样的如果基础架构已转移，而您只是在考虑如何监控它，那么您已经迷失了方向。如果不是Amazon，Google或Microsoft（并带有保留），那么您可能将没有太多机会来监视数据和应用程序。好吧，如果您有机会使用日志。有时，将提供有关安全事件的数据，但您将无权访问它们。例如，Office365。如果您拥有最便宜的E1许可证，则根本无法使用安全事件。如果您拥有E3许可证，则仅在拥有E5的情况下，您的数据将存储在90天之内-日志的有效期限为一年（但是，与需要分别从Microsoft支持部门请求多个日志记录功能相关的某些细微差别）。顺便说一下，就监视功能而言，E3许可证比公司Exchange弱得多。为了达到相同的水平，您需要E5许可证或其他高级法规遵从性许可证，这可能需要财务模型中未包括的额外资金才能过渡到云基础架构。这只是低估与监视IS云相关的问题的一个示例。在本文中，我想提醒大家注意从安全的角度选择云提供商时应考虑的一些细微差别。并且在本文的结尾，将提供一个清单，该清单应在您认为监视云信息安全性的问题已解决之前完成。

导致云环境中发生事件的几个典型问题是IB服务没有时间响应或根本看不到的：

安全日志不存在。这是相当普遍的情况，尤其是对于云市场的初学者而言。但是，立即制止他们是不值得的。小型企业，特别是国内企业，对客户的要求更加敏感，可以通过更改批准的产品路线图来快速实现某些要求的功能。是的，它不会类似于Amazon的GuardDuty或Bitrix的Proactive Defense模块，但至少是类似物。
IB不知道日志存储在哪里或无法访问它们。在这里有必要与云服务提供商进行谈判-如果他认为客户对自己很重要，也许他会提供此类信息。但是总的来说，当“通过特殊决定”提供对日志的访问时，这不是很好。
云提供商也有日志，但是它们提供的监视和事件日志有限，不足以检测所有事件。例如，您只能获得网站更改日志或尝试验证用户身份的日志，但不能提供其他事件（例如，有关网络流量的事件），这些事件将对您隐藏一整层事件，这些事件表征了入侵云基础架构的企图。
有日志，但是对它们的访问很难自动化，这使它们无法根据计划进行连续监视。而且，如果您仍然无法以自动模式下载日志，则以Excel格式（例如，与某些国内云解决方案提供商一样）上载日志，可能完全导致不愿意从公司IS服务中将其弄乱。
没有日志监控。这也许是在云环境中发生信息安全事件的最不可理解的原因。似乎有日志，您可以自动访问它们，但是没有人这样做。怎么了

云共享安全概念

迁移到云总是在保持对基础结构的控制权和将其转移给专门维护它的云提供商的更专业人士之间寻求平衡的追求。在云安全领域，也必须寻求这种平衡。而且，根据使用的提供云服务的模型（IaaS，PaaS，SaaS），这种平衡总是不同的。无论如何，我们必须记住，今天所有云提供商都遵循所谓的“分担责任和共享信息安全”模型。云负责某件事，客户端负责某事，已将其数据，应用程序，虚拟机和其他资源放置在云中。期望进入云后，将所有责任转移给提供商是愚蠢的。但是在迁移到云时自行构建所有安全性也是不合理的。需要一种平衡，这将取决于许多因素：-风险管理策略，防御机制的云提供商可以使用的威胁模型，法规等。

共享安全概念

例如，托管在云中的数据的分类始终是客户的责任。云提供商或外部服务提供商只能为他提供工具包，该工具包将帮助标记云中的数据，识别违规，删除违反法律的数据或使用一种或另一种方法对其进行掩盖。另一方面，物理安全性始终是云提供商的责任，它无法与客户共享。但是，数据和物理基础结构之间的所有内容正是本文讨论的主题。例如，云的可用性是提供商的责任，而设置ITU规则或启用加密则是客户的责任。在本文中，我们将尝试看看当今在俄罗斯颇受欢迎的各种云提供商所提供的信息安全机制的种类，其应用程序的功能是什么，以及何时将目光投向外部覆盖解决方案（例如，思科电子邮件安全）的方向，从而部分扩展了云的功能网络安全。在某些情况下，尤其是在采用多云策略时，您别无选择，只能一次在多个云环境（例如，Cisco CloudLock或Cisco Stealthwatch Cloud）中使用外部安全监控解决方案。好吧，在某些情况下，您会了解到，选择（或强加于您）的云提供商根本没有提供任何监视信息安全的选项。这令人不快，但也有很多，因为它使您可以充分评估与使用此云相关的风险级别。

云安全监控生命周期

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

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

让我们看看每个选项都有哪些功能。但是首先，我们需要了解将用于监视云平台的一般方案。我将重点介绍云中信息安全监视过程的6个主要组成部分：

基础设施准备。标识必要的应用程序和基础结构，以收集对存储中的信息安全重要的事件。
集合。在此阶段，安全事件会从各种来源进行汇总，以便随后传输到处理，存储和分析。
加工中。此时，将对数据进行转换和充实，以方便后续分析。
储存。该组件负责短期和长期存储所收集的已处理和原始数据。
分析。在此阶段，您可以检测事件并自动或手动响应事件。
报告中此阶段有助于为感兴趣的各方（管理层，审计师，云提供商，客户等）形成关键指标，这些指标可帮助我们做出某些决策，例如，更改提供商或加强IS。

了解这些组件将使您能够快速确定从提供商那里可以得到什么，以及您自己或在外部顾问的帮助下必须做什么。

内置云服务

我已经在上面写过，当今如此众多的云服务无法提供任何监视信息安全的可能性。通常，他们不太关注信息安全性主题。例如，俄罗斯最受欢迎的一种服务，用于通过Internet向政府机构发送报告（我将不特别提及其名称）。该服务的整个安全性部分围绕使用经过认证的加密信息保护工具进行。另一个用于电子文档管理的国内云服务的信息安全部分不再是一个示例。它讨论了公共密钥证书，认证的加密技术，消除Web漏洞，防御DDoS攻击，应用ITU，备份甚至进行定期IS审核。但是，没有关于监视的任何内容，也没有获得对该服务提供商的客户可能感兴趣的访问信息安全事件的可能性。

通常，通过云提供商在其网站和文档中描述信息安全问题的方式，人们可以理解他通常对此问题的重视程度。例如，如果您阅读了《我的办公室》产品的手册，那么根本就没有关于安全性的字眼，也没有单独的产品《我的办公室》的文档。旨在防止未经授权的访问的“ KS3”是FSTEC第17阶中执行“ My office.KS3”的子句的常用列表，但未描述其性能以及最重要的是如何将这些机制与公司信息安全集成。也许有这样的文档，但是我没有在My Office网站的公共领域中找到它。虽然也许我只是无法访问此机密信息？

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

Bitrix事件日志

如果您不考虑没有日志的选项，那么云提供商通常会为您提供三个用于监视安全事件的选项-仪表板，上传数据和通过API访问它们。第一个似乎为您解决了许多问题，但这并不是完全正确的-如果有几本杂志，则您必须在显示它们的屏幕之间切换，从而失去了大局。此外，云提供商不太可能为您提供关联安全事件并通常从安全角度进行分析的机会（通常，您正在处理需要了解自己的原始数据）。有例外，我们将进一步讨论它们。最后，值得一问的是，您的云提供商记录了哪些事件，以什么格式记录以及它们与您的IS监视过程对应多少？例如，用户和访客的标识和认证。使用同一个Bitrix，您可以记录此事件的日期和时间，用户或来宾的名称（在Web Analytics模块存在的情况下），可以访问的对象以及这些事件的网站其他典型元素。但是公司IS服务可能需要有关用户是否已从受信任设备登录到云的信息（例如，在公司网络中，Cisco ISE实施此任务）。像geo-IP功能这样的简单任务将有助于确定云服务的用户帐户是否被盗？即使云提供商将其提供给您，但这还不够。相同的Cisco CloudLock不仅分析地理位置，而且为此使用机器学习并分析每个用户的历史数据并跟踪各种异常以尝试识别和验证。只有MS Azure具有类似的功能（如果有相应的订阅）。

还有一个困难-因为对于许多云提供商来说，IS监视是他们刚刚开始处理的一个新主题，因此他们在不断改变自己的决策。今天，他们有一个版本的API，明天又是另一个版本，明天的第三天。还必须为此做好准备。具有可更改功能的同一事物，必须在您的信息安全监视系统中将其考虑在内。例如，亚马逊最初拥有单独的云事件监控服务-AWS CloudTrail和AWS CloudWatch。然后是单独的IS事件监视服务-AWS GuardDuty。一段时间后，Amazon启动了新的Amazon Security Hub管理系统，该系统包括对从GuardDuty，Amazon Inspector，Amazon Macie和其他几个接收的数据的分析。另一个示例是带有SIEM的Azure日志集成工具-AzLog。许多SIEM供应商都积极使用它，直到2018年Microsoft宣布终止其开发和支持，这使使用此工具的许多客户在遇到问题之前就已经解决（由于该问题已得到解决，我们稍后再讨论）。

因此，请仔细监视您的云提供商所提供的所有监视功能。或信任解决方案的外部提供商，这些提供商将充当SOC与要监视的云之间的中介。是的，它会更昂贵（尽管并非总是如此），但是您将把所有责任转移到别人的肩膀上。还是不全部？..回顾共享安全性的概念，并了解我们无法转移任何东西-您将不得不弄清楚不同的云提供商如何提供对您的数据，应用程序，虚拟机和云中其他资源的信息安全监控。我们将从亚马逊在此部分提供的内容开始。

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

是的，是的，我了解亚马逊并不是最好的例子，因为它是一项美国服务，在与极端主义和俄罗斯禁止的信息传播作斗争的过程中可以被封锁。但是，在此出版物中，我仅想说明不同的云平台在信息安全功能方面的差异，以及从安全角度将关键流程转移到云时应注意的事项。好吧，如果一些俄罗斯的云解决方案开发商对自己有所帮助，那就太好了。

AWS机会评估评估

首先，我必须说，亚马逊不是坚固的堡垒。他的客户经常发生各种事件。例如，1.98亿选民的姓名，地址，出生日期和电话从Deep Root Analytics被盗。以色列尼斯系统失窃了1400万个Verizon订阅记录同时，AWS内置功能使您可以检测各种事件。例如：

对基础架构的影响（DDoS）
节点危害（命令注入）
帐户泄露和未经授权的访问
配置错误和漏洞
未受保护的接口和API。

如上文所述，这种差异是由于客户本人负责客户数据的安全性这一事实造成的。如果他不担心会包含保护机制并且不包括监视工具，那么他将仅从媒体或客户那里了解此事件。

为了检测事件，您可以使用由Amazon开发的各种监视服务（尽管它们经常被osquery等外部工具所补充）。因此，在AWS中，无论如何执行，都将跟踪所有用户操作-通过管理控制台，命令行，SDK或其他AWS服务。可通过AWS CloudTrail获得每个AWS账户的所有操作记录（包括用户名，操作，服务，活动参数及其结果）和API使用情况。您可以从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 Flow Logs服务使您可以分析AWS服务器（外部或内部）以及微服务之间发送或接收的网络流量。当任何AWS VPC资源与网络交互时，VPC流日志会记录网络流量信息，包括源和目标网络接口，以及IP地址，端口，协议，字节数和看到的数据包数。那些具有本地网络安全经验的人将其视为NetFlow流的类似物。可以由交换机，路由器和企业级防火墙创建。这些日志对于信息安全监视非常重要，因为与用户和应用程序活动事件不同，它们还使您不会错过AWS虚拟私有云环境中的网络通信。

因此，这三个AWS服务（AWS CloudTrail，Amazon CloudWatch和VPC Flow Logs）一起可以非常有效地查看您的账户使用情况，用户行为，基础架构管理，应用程序和服务活动以及网络活动。例如，它们可用于检测以下异常：

尝试扫描站点，搜索后门，通过“ 404错误”爆发搜索漏洞。
Injection- (, SQL injection) “ 500”.
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规则不断检查服务器驱动器是否出现这种情况。而且，最重要的是，在本出版物的上下文中，任何违规行为都会产生事件，您的IS服务可以对其进行分析。您使用的Amazon服务的持续配置请求会在违反策略时生成事件。例如，代替定期执行AWS Config请求以验证所有虚拟服务器磁盘是否已加密，可以使用AWS Config规则不断检查服务器磁盘是否出现这种情况。而且，最重要的是，在本出版物的上下文中，任何违规行为都会产生事件，您的IS服务可以对其进行分析。您使用的Amazon服务的持续配置请求会在违反策略时生成事件。例如，代替定期执行AWS Config请求以验证所有虚拟服务器磁盘是否已加密，可以使用AWS Config规则不断检查服务器磁盘是否出现这种情况。而且，最重要的是，在本出版物的上下文中，任何违规行为都会产生事件，您的IS服务可以对其进行分析。AWS Config Rules可用于针对这种情况不断检查服务器磁盘。而且，最重要的是，在本出版物的上下文中，任何违规行为都会产生事件，您的IS服务可以对其进行分析。AWS Config Rules可用于针对这种情况不断检查服务器磁盘。而且，最重要的是，在本出版物的上下文中，任何违规行为都会产生事件，您的IS服务可以对其进行分析。

AWS还具有与传统公司信息安全解决方案相同的功能，该解决方案还会生成您可以并且应该分析的安全事件：

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

我不会详细介绍在信息安全方面可能有用的所有Amazon服务。要了解的主要事情是，它们都可以生成事件，我们可以并且应该在信息安全的背景下进行分析，为此，需要使用Amazon的内置功能和外部解决方案（例如SIEM），这些事件可以将安全事件带到您的监控中心并对其进行分析，以及来自其他云服务或内部基础架构，外围设备或移动设备的事件。

使用ELK的AWS监控

无论如何，这一切都始于为您提供IB事件的数据源。此类来源包括但不限于：

CloudTrail-API使用情况和用户操作
可信顾问-最佳实践的安全检查
Config —
VPC Flow Logs —
IAM —
ELB Access Logs —
Inspector —
S3 —
CloudWatch —
SNS — .

亚马逊提供了各种各样的事件源和生成工具，在信息安全的背景下分析收集到的数据的能力非常有限。您将必须独立研究可用的日志，在其中寻找相应的危害指标。亚马逊最近启动的AWS安全中心旨在通过成为AWS的一种基于云的SIEM来解决此问题。但是，尽管它只是其旅程的开始，并受到其使用源的数量以及Amazon本身的体系结构和订阅所建立的其他限制的限制。

示例：在基于Azure的IaaS中监视IS

我不想就这三个云提供商（亚马逊，微软或谷歌）中哪个更好（特别是因为它们各自都有自己的特点并适合解决其问题）进行长时间的辩论；专注于这些播放器提供的安全监视功能。不可否认，Amazon AWS是该细分市场中的首批产品之一，因此在信息安全功能方面取得了最先进的发展（尽管许多人承认使用它们很困难）。但这并不意味着我们将忽略微软为Google提供的机遇。

微软产品始终以其“开放性”而著称，在Azure中情况也是如此。例如，如果AWS和GCP始终源于“禁止一切不允许的事情”的概念，则Azure采取了完全相反的方法。例如，在云中创建一个虚拟网络并在其中创建一个虚拟机，默认情况下所有端口和协议都是打开并启用的。因此，您将不得不花更多的精力在Microsoft的云中对访问控制系统进行初始设置。而且，这在监视Azure云中的活动方面也对您提出了更严格的要求。

AWS的独特之处在于，当您监视虚拟资源时，如果它们位于不同的区域，则很难将所有事件和它们的单个分析结合起来，以消除需要使用各种技巧的风险，例如为AWS Lambda创建自定义代码，该代码将在区域之间传递事件。 Azure中没有这样的问题-它的活动日志机制可以不受限制地监视整个组织中的所有活动。这同样适用于AWS安全中心，该中心最近由亚马逊开发，用于将多个安全功能整合在一个安全中心内，但仅限于其区域内，但是与俄罗斯无关。 Azure有自己的安全中心，不受区域限制的约束，提供对所有云平台安全功能的访问。此外，对于各种本地团队，他可以提供自己的防御能力，包括由他们管理的安全事件。 AWS安全中心仍在努力变得像Azure安全中心一样。但是，值得一提的是，您可以从Azure中挤出很多以前在AWS中描述的内容，但这仅对于Azure AD，Azure Monitor和Azure Security Center最为方便。尚未以最方便的方式管理所有其他Azure防御机制，包括安全事件分析。可以通过渗透所有Microsoft Azure服务的API解决部分问题，但这需要付出更多的努力才能将云与SOC集成在一起，并需要合格的专家（实际上，和其他任何东西一样。 SIEM使用云API）。稍后将讨论的一些SIEM已经支持Azure，并且可以自动化监视它的任务，但是它存在一些困难-并非所有人都可以获取Azure拥有的所有日志。

Azure活动日志

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

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

活动日志-该日志回答有关在云资源上进行任何写操作（PUT，POST，DELETE）的经典问题“谁”，“什么”和“何时”。与读取访问（GET）相关的事件以及许多其他事件均不属于此日志。
诊断日志-包含有关使用订阅中包含的特定资源进行的操作的数据。
Azure AD报表-包含与组和用户管理有关的用户活动和系统活动。
Windows事件日志和Linux Syslog-包含来自云中托管的虚拟机的事件。
Metrics — “” . . 30 .
Network Security Group Flow Logs — , Network Watcher .
Storage Logs — , .

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

安全域-与信息安全相关的关键定量指标-事件数量，受感染节点的数量，未打补丁的节点，网络安全事件等。
值得注意的问题-显示活动IB问题的数量和重要性
Detections — ,
Threat Intelligence — ,
Common security queries — , .

Azure Monitor扩展包括Azure Key Vault（保护云中的加密密钥），恶意软件评估（针对虚拟机上的恶意代码的保护分析），Azure Application Gateway Analytics（尤其是对云防火墙日志的分析）等。。这些工具通过事件处理的某些规则得到了丰富，使您可以可视化云服务活动的各个方面，包括安全性，并确定某些工作偏差。但是，通常，任何其他功能都需要适当的付费订阅，这需要您进行适当的金融投资，您需要提前计划。

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

如上所述，保护功能及其生成的安全事件并非均能被所有用户访问，而是需要包含您所需功能的特定订阅，该订阅会生成用于监视信息安全的适当事件。例如，上一段中描述的某些监视帐户异常的功能仅在Azure AD的P2高级许可证中可用。没有AWS，您将不得不像AWS一样“手动”分析收集的安全事件。而且，根据Azure AD的许可证类型，并非所有要分析的事件都对您可用。

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

如果您不仅需要使用日志的能力，还需要Azure云平台的全面安全中心（包括管理IS策略），那么您可以讨论使用Azure安全中心的需要，其中大部分需要付费，例如威胁检测，监视Azure之外，合格性评估等（在免费版本中，您只能访问安全评估和解决已发现问题的建议）。它将所有安全问题集中到一处。实际上，我们可以谈论比Azure Monitor提供更高级别的信息安全性，因为在这种情况下，您在云工厂中收集的数据会使用各种来源进行丰富，例如Azure，Office 365，Microsoft CRM Online，Microsoft Dynamics AX，Outlook .com，MSN.com，Microsoft数字犯罪部门（DCU）和Microsoft安全响应中心（MSRC），它们叠加在各种复杂的机器学习和行为分析算法上，最终将提高威胁检测和响应的效率。

Azure拥有自己的SIEM-它于2019年初出现。这是Azure Sentinel，它依赖于Azure Monitor中的数据，也可以与之集成。外部安全解决方案（例如NGFW或WAF），其列表会不断更新。此外，通过集成Microsoft Graph Security API，您可以将自己的威胁情报源连接到Sentinel，从而丰富了分析Azure云中事件的能力。可以说Azure Sentinel是出现在云提供商中的第一个“本地” SIEM（可以放置在云中的同一Splunk或ELK，例如AWS，传统的云服务提供商仍未开发）。 Azure Sentinel and Security Center可以称为Azure云的SOC，如果您不再具有任何基础结构，并且将所有计算资源都转移到了云中，那么它将受到限制（有一定保留），并且它将是Microsoft云蔚蓝

但是，由于Azure的内置功能（即使带有Sentinel订阅）通常不足以进行IS监视以及将此过程与其他安全事件源（云和内部事件）进行集成，因此需要将收集的数据导出到外部系统，其中可能包括SIEM。这是通过API的帮助以及目前仅对以下SIEM正式可用的特殊扩展的帮助而完成的-Splunk（Splunk的Azure Monitor插件），IBM QRadar（Microsoft Azure DSM），SumoLogic，ArcSight和ELK。最近，有更多这样的SIEM，但是从2019年6月1日起，Microsoft停止支持Azure日志集成工具（AzLog），该工具在Azure诞生之初并且由于缺乏正常使用日志的标准化（甚至不存在Azure Monitor）而变得容易将外部SIEM与Microsoft Cloud集成。现在情况已经改变，Microsoft建议将Azure Event Hub平台作为其余SIEM的主要集成工具。许多人已经实现了这种集成，但是要小心-它们可能无法捕获所有Azure日志，而只能捕获其中的一部分（请参阅SIEM文档）。

在结束对Azure的简短介绍之后，我想对该云服务进行一般性的建议-在对Azure中的安全监视功能进行任何说明之前，您应该非常仔细地配置它们，并测试它们是否按文档中的内容以及顾问告诉您的内容进行工作Microsoft（他们对Azure功能的性能可能有不同的看法）。如果您具有Azure的财务功能，则可以挤出很多有关信息安全监视的有用信息。如果您的资源有限（如AWS），则您将仅依赖于自己的资源和Azure Monitor为您提供的原始数据。请记住，许多监视功能需要花钱，最好事先熟悉价格。例如，您可以免费为每个客户免费存储31天的数据，每个客户不超过5 GB-超出这些值将需要您额外付费（用于存储客户每增加1 GB的费用大约为$ 2 +，以后每增加1 GB的费用为$ 0.1 ）使用应用程序遥测和度量标准可能还需要额外的财务资源，以及使用警报和通知（一定的限制是免费的，可能无法满足您的需求）。

示例：基于Google Cloud Platform的IaaS中的IS监视

在AWS和Azure的背景下，Google Cloud Platform看起来还很年轻，但这在一定程度上是不错的。与AWS不同的是，AWS正在逐步增强其功能（包括防御功能），但在集中化方面存在问题；与Azure一样，GCP可以更好地集中管理，从而减少了企业中的错误数量和实施时间。从安全角度来看，奇怪的是，GCP位于AWS和Azure之间。他还为整个组织进行了一次活动注册，但还不完整。某些功能仍处于beta模式，但应逐渐消除这种缺陷，GCP在信息安全监控方面将成为更加成熟的平台。

在GCP中记录事件的主要工具是Stackdriver Logging（Azure Monitor的类似物），它使您可以跨整个云基础架构（以及AWS）收集事件。从GCP的安全性角度来看，每个组织，项目或文件夹都有四个日志：

管理员活动-包含与管理访问有关的所有事件，例如，虚拟机的创建，访问权限的更改等。无论您的意愿如何，该日记本始终会被写入，并且可以将其数据存储400天。
数据访问-包含与处理来自云用户的数据有关的所有事件（创建，修改，读取等）。默认情况下，该日记本不会编写，因为其体积会迅速膨胀。因此，其保质期仅为30天。此外，本期刊几乎未写任何内容。例如，不向所有用户公开可用资源或无需访问GCP即可访问的资源相关事件。
系统事件-包含与用户无关的系统事件，或更改云资源配置的管理员的操作。它始终被写入并存储400天。
访问透明性是一个独特的日志示例，它记录了Google员工（但不是所有GCP服务）的所有操作，这些员工将访问您的基础结构作为其工作职责的一部分。该日志的存储时间为400天，并非对所有GCP客户都可用，仅受多种条件（金牌或白金支持，或存在4种特定类型的角色作为公司支持的一部分）。也可以使用类似的功能，例如，在Office 365-密码箱中。

日志示例：访问透明

{  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" }

通过Log Viewer界面，API，Google Cloud SDK或项目的Activity页面（根据您对事件感兴趣的方式），可以通过几种方式（与Azure和AWS先前考虑的方式几乎相同）访问这些日志。同样，它们也可以导出到外部解决方案以进行其他分析。后者是通过将日志导出到BigQuery或Cloud Pub / Sub存储来完成的。

除了Stackdriver Logging，GCP平台还提供Stackdriver Monitoring功能，该功能可让您跟踪云服务和应用程序的关键指标（性能，MTBF，常规状态等）。经过处理和可视化的数据可以使您更轻松地在云基础架构中发现问题，包括在安全上下文中。但应注意的是，此功能在信息安全的上下文中将不会非常丰富，因为今天GCP不再具有相同的AWS GuardDuty的类似物，并且无法从所有记录的事件中区分出不良事件（Google开发了Event Threat Detection，但到目前为止在Beta中，并尽早谈论其实用性）。 Stackdriver Monitoring可以用作检测异常的系统，然后将对其进行调查以查找异常发生的原因。但是，在市场上缺乏信息安全GCP领域合格人员的情况下，此任务目前看来很困难。

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

Cloud Security Command Center是AWS Security Hub和Azure Security Center的类似物。
Cloud DLP-根据90多个预定义的分类策略，自动检测和编辑位于云中的数据（例如，屏蔽）。
Cloud Scanner是App Engine，Compute Engine和Google Kubernetes中已知漏洞（XSS，Flash Injection，未修补的库等）的扫描程序。
云端IAM-对所有GCP资源的访问控制。
云身份-通过单个控制台管理GCP用户帐户，设备和应用程序。
Cloud HSM-加密密钥保护。
Cloud Key Management Service-GCP中的加密密钥管理。
VPC服务控制-在GCP资源周围创建安全边界，以防止它们泄漏。
Titan安全密钥-防止网络钓鱼。

这些模块中的许多模块都会生成安全事件，这些事件可以发送到BigQuery进行分析或导出到其他系统，包括SIEM。如上所述，GCP是一个积极开发的平台，现在Google正在为其平台开发许多新的信息安全模块。其中包括Event Threat Detection（事件威胁检测）（现已在Beta中提供），该功能可扫描Stackdriver日志以查找未授权活动的痕迹（类似于AWS中的GuardDuty）或Policy Intelligence（可用于alpha中），这将允许开发对GCP资源的智能访问策略。

我对流行的云平台中的内置监视功能进行了简短回顾。但是，您是否有能够处理IaaS提供商原始日志的专家（不是每个人都准备购买AWS或Azure或Google的高级功能）？此外，许多人都知道“信任，但会验证”这句谚语，在安全领域它一如既往地真实。您对发送IB事件的云提供商的内置功能有多信任？他们有多少专注于信息安全？

有时值得寻求用于监视云基础架构的叠加解决方案，以补充内置的云安全性；有时，此类解决方案是获取位于云中的数据和应用程序的安全性数据的唯一方法。此外，它们更加方便，因为它们承担了分析不同云提供商的不同云服务生成的必要日志的所有任务。这种强加解决方案的一个示例是Cisco Stealthwatch Cloud，它专注于唯一的任务-监视云环境中的IS异常，不仅包括Amazon AWS，Microsoft Azure和Google Cloud Platform，还包括私有云。

示例：使用Stealthwatch Cloud监视安全性

AWS提供了一个灵活的计算平台，但是这种灵活性使公司更容易犯导致安全问题的错误。共享的IS模型对此做出了贡献。在云中运行具有未知漏洞（例如，AWS Inspector或GCP Cloud Scanner可以对抗已知漏洞），弱密码，错误配置，内部人员等的软件。所有这些都会影响云资源的行为，思科Stealthwatch Cloud可以观察到这种行为，这是一个用于监视信息安全和攻击检测的系统。公共云和私有云。

思科Stealthwatch Cloud的关键功能之一是能够对实体进行建模。借助它，您可以为每个云资源创建一个软件模型（即几乎实时模拟）（无论是AWS，Azure，GCP还是其他东西都没关系）。这些可能包括服务器和用户，以及特定于您的云环境的资源类型，例如安全组和自动扩展组。这些模型使用云服务提供的结构化数据流作为输入。例如，对于AWS，这些将是VPC流日志，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 Cloud支持的任何云环境都可以使用类似的功能：

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

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

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

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

这使您可以为公司可以使用的公共云和混合云实施统一的监视系统。然后，可以使用Stealthwatch Cloud的内置功能来分析收集的信息，或将其发送到您的SIEM（默认情况下，支持Splunk，ELK，SumoLogic和其他几个功能）。

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

云安全监控