随着开发和运营团队不断把资源迁移向云端，企业对于基于云的服务也使用越来越多，致使安全团队不得不时刻准备应对不预期的问题——大量新的预警和事件。在之前的文章《日志管理与分析（六）–日志的审核与响应》中，概念化的讲述了日志的异常与分析、事故响应流程等

随着业务量的增长，服务器的增长，同时应用日志的数量也是呈现几何的速度增长。大部分人的认为日志数据对业务来说只是开发人员排除故障的依据，除此以外对业务而言是没有任何的意义的。我相信，对很多人的认知来说日志也就那么点的作用。不可或缺，但是也是很鸡肋。需要它的时候，迫不及待，不需要它的时候弃之如敝履。

本章围绕云计算、云安全以及云日志的基本概念。目的并不是让你成为这些主题的专家，而是为你提供基本知识，以及做出云日志方面的明智决策所需的理解。你对云概念的细节了解越多，就越容易在选择提供商时做出正确的决定。

1. 云计算

本质上，云计算是一个用于描述用户与一组计算机资源（CPU、内存、磁盘等）交互方式的术语。对于最终用户，他好像在使用一个计算机系统。但是，实际上用户使用的可能是许多不同（往往进行虚拟化）的组件。云计算的关键特征之一是弹性。弹性是扩展（在需要更多资源时）和资源不再需要时收缩的能力。

在文章部分，会使用“提供商”和“消费者”两个术语。提供商是提供云服务的一方，可能是第三方实体，也可能是公司内部的一个群体。消费者是消费云服务的人。

1.1 服务交付模型

服务交付模型指的是特定的计算机资源交付给最终用户的方式。软件即服务（Software as a Service）、平台即服务（Platform as a Service）和基础设施即服务（Infrastructure as a Service）。

1.软件即服务（SaaS）

SaaS用于描述存在于提供商基础设施上的软件。消费者使用客户端或者web浏览器交互并使用该软件。从消费者的角度看，他们是与单一计算机系统交互。他们不负责软件和硬件维护、保护等工作。要注意的是，SaaS提供商可能是Salesforce.co这样的第三方外部提供商，也可能是消费者所在组织内的内部提供商。云日志提供商属于这种交付模型，也就是说，一个组织接受日志，以便为其他组织分析日志。

2.平台即服务（PaaS）

在PaaS模式下，消费者可以将定制的应用程序或者工具部署到提供商的云。和PaaS一样，消费者对底层硬件或者网络没有控制权（在有些情况下，消费者可能访问防火墙配置），但是和SaaS不同，消费者对于部署的应用程序和相关配置有控制权。云日志提供商不允许消费者安装自己的应用程序。

3.基础设施即服务（IaaS）

最后一种服务交付模型处理基础设施。IaaS允许消费者配置计算资源，如CPU、内存、磁盘、网络和其他相关资源。消费者通常控制操作系统、部署的应用程序和存储容量。他们不能控制底层基础设置。

4.存储即服务

顾名思义，存储即服务处理云中的存储。消费者和提供商签署一个协议，租用提供商网络上的空间。加个通常根据每GB存储和某种数据传输率确定。最常见的用例是场外备份和检索服务。中小规模消费者可以从这种服务获得很大的利益，因为IT、硬件、软件和网络管理都由提供商承担。

1.2 云部署模型

云计算系统可能进行私有部署，或者托管在云客户的场地中，可以和有限数据的可信合作伙伴共享，可以由第三方托管，也可以是公共可以访问的服务，即公共云。

理解部署模型的两个关键概念是场内和场外。场内指的是基础设施位于消费者的场地--也就是他们的数据中心。场外指的是云处于消费者的场地之外--也就是云提供商的数据中心。

1.公共云

顾名思义，公共云的基础设施可供公众访问，这种云一般是由行业集团或者公司拥有，以各种不同的形式销售云服务。云的基础设施由某个组织运营，可以由该组织或者云提供商管理。基础设施可以在场内，也可能在场外。

2.私有云

同样，从名称就可以看出，这种云是私有的，是供单一组织使用。云的管理由该组织或者云提供商负责。私有云既可以是场内的，也可以是场外的。

3.社区云

有共同关注点的组织可以采用社区云。共同关注点可以是“任务、安全需求、策略或者依从性考虑”。云的管理由社区或者云提供商执行。社区云可以是场内的，也可以是场外的。

4.混合云

混合云考虑以某种方式将两种或者更多的云类型（公共、私有等）组合在一起，提供可移植性。例如，云日志提供商可能允许消费者创建自己的私有云，以便提供商的应用程序栈可以放在同一个位置。这样做的好处是为消费者提供处理灾难恢复、集中化、依从性等问题的手段。

2. 云日志

虽然本篇的主题是关于云日志的，但是前面必须提到关于云计算的许多信息。这是因为，云日志只是云计算的一个应用。换言之，正是云计算才使云日志得以存在。日志即服务（LaaS）。LaaS指的是提供商用云设置来提供日志记录服务。也就是说，提供商获取日志数据，并代表其他人实施分析。

下图展示了云日志的概要描述。

 

图中是一系列将日志记录到云中的设备。提供商给你一个IP地址或者主机名，让你的syslog配置指向它。但是实际情况可能会更加复杂，至少对于云日志提供商来说是这样。例如IP地址的另一端可能是负载均衡器，用于处理入站连接。平衡器把请求发给许多机器中的一个，这些机器获取数据、规范化、索引，并将日志存储起来供以后检索。

云日志存储的复杂度和功能正在不断增加。下面介绍了云日志实体共有的特性和功能：

·日志获取方法：为了将数据输入到云中，大部分云日志提供商支持syslog（TCP/UDP和安全/TLS）和一个专有的API（通常是通过HTTP/HTTPS的REST风格API）。syslog覆盖世界上95%以上的设备。API允许将云日志构建到你的应用程序中。

·部署模型：有些云日志提供商在云计算提供商的基础上构建他们的服务，而其他一些提供商构建自己的云。提供商甚至可能支持混合模型。

·日志保存：所有提供商都支持日志数据的长期保存，不同之处在于存储的收费。通常，购买者控制保存数据的周期（几天、几周、几个月）。有些提供商只允许最多留存6个月的数据。

·核心功能：日志云服务的基本核心功能包括日志数据获取、日志数据索引（用于快速搜索等）、长期存储和用于搜索及审核数据的用户界面（通常基于web）。除了这些，还有关联、定制警报和定制报告等额外功能（有些提供商并不支持这些功能）。

·记账：大部分云日志供应商支持随用随付模型。你不需要签订合同，只需为发送给供应商和希望保存的日志数据付费。而且，大部分提供商有“购买前试用”计划，这种计划本质上允许你每天免费发送少量日志消息，以尝试服务是否令你满意。

·灾难恢复(DR)：有些云日志提供商在服务条款中说明，他们不对数据丢失负责。事实是，云日志行业必须解决这个问题，才能使其成为较大型消费者的可行选择。

这一领域正在以非凡的速度成长和扩张。提供商不断出现，并且都有最新的突破性功能。然而，许多提供商只将重点放在运营，而不是安全和依从性方面。

如果你所在公司遇到需要采用服务，需要向他们提出有关服务的问题。了解他们所提供服务的内容。下面是一些需要询问的基本问题：

1）有没有安全主管或者CSO能够帮助设置安全态势？

2）采用什么安全控制来保护我的数据？

3）提供商的总体安全态势如何？

4）我的数据和其他人的数据如何隔离？

5）采用什么部署模型？

6）采用何种记录计划？

7）关于正常运行时间和如下项目的可用性，它们提供何种SLA：

a）日志获取服务

b）日志保存服务

c）用户界面

d）报告系统

8）提供商支持什么样的警报选项（电子邮件、短消息等）？

9）他们是否提供关联？如果有，采用什么形式，统计还是基于规则？

10）和上面的第8条类似，他们如何安装维护，换言之，他们是否在每周二凌晨3点进行维护？在维护期间，服务的可用性如何？

Loggly，它提供了一个基于web的API来将数据获取到云中。这是你用于搜索日志数据的机制。

云日志提供商应该支持这样的定制API：

1） 你可以从自己控制的任何系统或者应用程序发送日志数据，这些系统和应用程序可能不支持syslog。

2）你可以构建自己的警报系统。通过定期查询云，你也可以编写脚本搜索各种关心的事件，然后发送电子邮件、短消息等。你甚至可以与内部工作单系统接口。

3）相互制衡。例如，你可以计量发送到提供商的数据量，核对数额。你甚至可以检测发送到云的数据有没有及时到达，在失败时（从提供商那里得到一个错误的响应）重新发送。

3. 监管、依从性和安全问题

你所处行业（银行、医疗、***等）要求监管依从性，确保你能够对抗外部和内部威胁、数据丢失等。《日志管理与分析（四）–日志管理规程》中分别从PCI DSS、ISO 27001、HIPAA举例详述了监管、依从性对不同行业的日志要求。

考虑到云日志提供商部署自己的软件和服务，因此需要解决监管、依从性和安全问题。确实如此，许多法律法规的要求都没有面向云计算。因此，作为云消费者，需要理解下面这些由你负责。

·使用云服务的监管适用性。

·云提供商和云消费者之间的依从性职责划分。

·云提供商生成依从性所需证据的能力。

·云消费者在弥补云提供商和审计人员/评估人员之间鸿沟中的角色。

确保你和内部审计团队一起工作，协调到云提供商的过渡。

为适应新技术的发展，解决云计算、物联网、移动互联和工控领域信息系统的等级保护工作的需要，由公安部牵头组织开展了信息技术新领域等级保护重点标准申报国家标准的工作，等级保护正式进入2.0时代。

等保2.0云计算方面的安全扩展要求，每一级安全扩展要求都分为五个部分，即安全物理环境、安全通信网络、安全区域边界、安全计算环境和安全建设管理。

在安全物理环境中，等保2.0强调“保证云计算基础设施位于中国境内”，同时“确保云服务****、用户个人信息等存储于中国境内”。

从上面两条规定，我们看到云计算基础设施和数据不能出境。随着国内数字经济的发展和云计算的深入推进，云计算基础设施将得到进一步发展。对国内数据中心而言，这也是一个利好消息。

关于云计算安全扩展要求的解读可以参考网络上的资料。

至于IT安全，云提供商的安全态势实际上和常规组织没有什么不同。当然，考虑到虚拟硬件的使用、数据隔离方面的考虑和身份管理等，它们需要处理额外的问题。

云提供商应该遵循的最佳实践：

·内部人员（提供商内部）可能泄露你的数据。

·云提供商应该在招聘过程中包含背景调查。

·云提供商应该实施安全策略、控制等，这些措施应该与要求最严格的客户相符。

·协议或者服务条款应该概述安全策略、备份和恢复、业务持续性等细节。

·云提供商应该在接收到请求时，提供简述提供商IT安全态势的文档。

从依从性和安全的角度，很容易理解使用公共云提供商的含义。在这种情况下，使用混合部署模型变得更加有趣。

 

混合云跨越私有云和公共云。界限变得模糊，因为在这种部署中，消费者在提供商的站点和自己的站点上都使用云资源。有许多因素需要考虑，如：

1）谁负责加固两个站点之间链接的安全？

2）谁负责场内设施的安全？

3）谁负责场外设施的安全？

4）如果泄露发生在消费者端而非云提供商一端，事故响应和升级如何处理？

5）根据组织所处的监管和法规下，你可以参与混合部署吗？

转移到云的任何决策都有许多需要考虑的细节。但是从企业的责任和需求开始推进云计算，就可以更加清晰地完成过渡。

3.1 云中的大数据

正如Stephen Marsland在他的著作中提到的，“如果数据有质量，那么地球就是一个黑洞”。

什么是海量数据呢？我们来看一个真实的公司。该公司有超过5000台服务器、2000台路由器和交换机，大约600台安全设备（防火墙、IDS、IPS、VPN、内容服务交换机、防病毒）和50000个以上的桌面防火墙和主机防病毒软件（桌面和编写电脑）。这至少可以称得上是一个大型网络了。在整个企业中，从所有系统中产生的日志消息每秒大约有10万条。我们假设平均日志消息大小为300字节。你可以想想，每小时有多少消息？一天有多少消息？

我们提倡记录日志，并持续评估所收集的信息。通过这一过程，你可以不记录任何不打算查看、不关心或者没什么价值的信息。但是有些人希望或者必须收集尽可能多的日志数据。对于具有严格的查询和分析需求、且体积持续增长的数据（数据密集型应用程序），传统的关系数据库（RDBMS）已经穷于应付，NoSQL也就应运而生。它的原意是成为现代化的web级数据库。常见的特征有：无模式、简易复制支持、简单API、最终一致性/BASE（不是ACID）、巨大的数据量等。

虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位，但是由于其天生的几个限制，使其很难满足上面这几个需求：

1. 扩展困难：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难;

2. 读写慢：这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重;

3. 成本高：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升;

4. 有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储;

业界为了解决上面提到的几个需求，推出了多款新类型的数据库，并且由于它们在设计上和传统的NoSQL数据库相比有很大的不同，所以被统称为“NoSQL”系列数据库。总的来说，在设计上，它们非常关注对数据高并发地读写和对海量数据的存储等，与关系型数据库相比，它们在架构和数据模型方量面做了“减法”，而在扩展和并发等方面做了“加法”。现在主流的NoSQL数据库有BigTable、Hbase、Cassandra、SimpleDB、CouchDB、MongoDB和Redis等。

和传统RDBMS中扩展机器的技术做个比较，这种技术是在机器上添加更多的CPU、RAM和多个输入/输出通道。例如，具备两个I/O通道的机器每秒吞吐量为100MB，它需要花费3小时才能读取2TB的数据。为什么会这样？随着时间的推移，传输率已经有了提高，但是磁盘驱动器的寻道时间并没有同样幅度的提高。因此，许多人（包括云日志提供商）使用实现NoSQL概念的系统和软件，提供更快的搜索、索引和其他功能。

Hadoop示例：

Hadoop是一种领先的MapReduce实现。MapReduce技术分为两个步骤，在映射步骤中，主节点取得输入数据并将其分解为较小的块。在归纳步骤中，主节点取得返回的所有数据并进行某种组合，向客户端返回一个答案。图展示了Hadoop的逻辑布局。

 

图中我们有一个商用机器的Hadoop云。这些机器代表客户端运行作业（客户端可以是最终用户、应用程序等）。客户端期待的是问题的答案。映射/归纳方法效果如此之好的原因是数据和需要在数据上完成的后续分析都可以进行批处理。图中的Hadoop云是一个分布式系统，允许数据分块且并行处理。Hadoop和MapReduce的另一个核心技术是数据本地化。数据本地化处理文件系统上数据的映射步骤。这使得Hadoop群集管理员能够配置最接近数据的服务器执行作业。这能够减少网络宽带的消耗，缩短响应时间。

Hadoop的出现，颠覆了数据的使用方式，但是Hadoop的安全性一直是个潜在的隐患。，如果安全问题延伸讨论的话，Hadoop同样面对安全问题：Namenode或者jobtracker缺乏安全认证机制、DataNode缺乏安全授权机制、Service to service安全认证等

3.2 云中的SIEM

传统上，SIEM系统是一个紧缩型套装产品。这意味着你要购买软件的许可证，并根据软件的复杂度，向咨询人员付费，由他们花费长时间来安装和配置SIEM。多数公司不愿意花费数十万美元（或者更多）在SIEM部署上。实际上，许多软件公司都在争相翻新软件，使其成为可以在云中部署的产品。

这正是托管安全服务提供商（MSSP）多年以来真正的优势（实际上，在云日志这一术语出现之前，MSSP就已经在提供云日志了）。他们提供的模型通常有只监控、只管理或者监控与管理。下图展示了SIEM云的逻辑布局。

 

SIEM云在功能集上稍微成熟一点，SIEM云有健全的功能集，他们都可以通过一个或者一组API访问。这不仅对于向内部客户及系统（运营、安全运营中心（SOC）、网络运营中心（NOC）、记账、人力资源等）提供服务很关键，对于外部客户同样重要。例如，客户通常希望从提供商向其内部系统输出工作单。大部分提供商实现某种基于web的API（REST风格、SOAP等）。这使得客户很容易编写自定义应用程序代码来获取这些工作单。

3.3 云日志的优缺点

下面不是一个全面的列表，但是概述了在云日志中常会碰到的优缺点。当然根据你自身的需求，可能必须进行某些分析。

优点	缺点
管理：由别人管理硬件、软件 随用随付模型：对你所使用内容的付费 你控制发送的内容和时间
API支持：许多日志记录提供商有健全的API，你可以用它以syslog之外的手段向云传输日志数据。你一般还使用这个API搜索云数据	API支持：这可能既是优点，也可能是缺点。如果API本身不安全（身份认证和隐私），而且你需要处理监管和依从性问题，可能是个难点
场外存储：存储的任务由供应商处理。你一般可以选择保存的时长和数据量	场外存储：根据安全控制、信任矩阵和提供商采用的其他安全相关准则，在云中存储你的日志数据可能不现实。确定提供商是否采用混合部署模型，允许它们整个应用栈的一部分保存在你的数据中心
	安全：安全是一个关注点，因为迁移到云可能产生“优雅的失控”。需要了解提供商的整体安全态势

3.4 其他资源

如果你要对云相关信息的搜索可以访问以下网站：

·NIST云计算：http://www.nist.gov/itl/cloud/

·云安全联盟（CSA）：http://cloudsecurityalliance.org

当然，互联网搜索可以返回更多的结果。

 4.总结：

·云服务交付模型：三种基本类型是SaaS、IaaS和PaaS

·云部署模型：四种基本类型是公共、私有、社区和混合

·云日志：这是一个年轻的领域，每天都在生长。在你将所有日志数据放到云中之前，一定要了解你和组织的需求。要向提供商询问使用中感兴趣的任何问题。

·云中的SIEM。MSSP支持这一模型已经有多年的历史。传统的紧缩型套件SIEM供应商开始意识到这一模型的价值，争相在产品中加入云能力和服务。

·安全考虑：一定要理解提供商实现IT安全的方式。还要确保理解在云环境中运营时，你在法律和监管依从性方面所负的职责。

日志记录的发展趋势：

·日志标准得到日志生成者的广发采纳。应用程序和设备制造商以及云平台制造商都以标准格式生成日志

·应用程序开发人员在编写应用程序时立即采用日志标准和标准库及API，实现实用的日志。形成的数据不仅基于标准，而且全面、不过分臃肿，可用于大部分运营、安全和监管需求。

·我们将拥有更加透明、直观和可审核的系统，不管采用的是移动、云、虚拟还是传统方式。

·协助分析日志的工具必须更加智能，同时更加易用。这些工具可以消费数据，不管数据是遵循标准的还是遗留的，并且根据数据生成有用的建议和结论。而无须太多的人工调整和交互。

·更多的公司提升自己的日志成熟度曲线，更多组织在分析和理解日志数据上变得更有能力。这种能力并不廉价，但是之前所提供的工具和日志的改进，会使它们变得更容易承受。

·在IT领域内外的人在工具、改进的日志和改进的成熟实践和过程的支持下，将日志用于更多的目的，这些支持手段专注于获得更多对业务和技术以及系统保护、法规依从性有益的见解。

文章参考：《日志管理与分析权威指南》

https://blog.csdn.net/m0_37803704/article/details/80739349

本文作者：Lemon

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/121793.html