视频监控云服务架构_如何有效实施监控云基础架构

视频监控云服务架构

As organisations are migrating more and more computing to the cloud, they are at risk of becoming more susceptible to malicious attacks. When it comes to the cloud, there’s a difference between what a cloud provider sees and what an attacker sees.

随着组织将越来越多的计算迁移到云中，他们面临着更容易受到恶意攻击的风险。 当谈到云时，云提供商看到的内容和攻击者看到的内容之间是有区别的。

A cloud provider’s perspective:

云提供商的观点：

• Cloud is ever present, ever accessible
  云永远存在，永远可以访问
• Provides a wide range of computing services
  提供广泛的计算服务
• Enables rapid development and deployment
  实现快速开发和部署
• Cloud consumption is rapidly increased
  云消耗量Swift增加

An attacker’s perspective:

攻击者的观点：

• Can be continuously and relentlessly attacked
  可以连续不断地受到攻击
• A wide surface area to attack
  攻击范围广
• Easy to make mistakes and configuration errors
  容易出错和配置错误
• Makes a super attractive target
  成为极具吸引力的目标

Most attacks are not new - things like malware, password brute forcing, credential theft, DDoS, and SQLi are all common in legacy and on-premise systems. Aside from these, there are also new types of attacks emerging in cloud environments such as password spraying, crypto miners, harvesting secrets/subscription keys, and file-less attacks.

大多数攻击都不是新鲜事物-诸如恶意软件，密码暴力破解，凭证盗窃，DDoS和SQLi之类的攻击在旧式和本地系统中都很常见。 除此之外，云环境中还出现了新型攻击，例如密码喷雾，加密矿工，收集机密/订阅密钥和无文件攻击。

For instance, password spraying works by taking one password and throwing them into multiple accounts, while password brute forcing takes one account and throws many passwords against it. There have been many reports of attacks along the supply chain and on misconfigurations in cloud infrastructure.

例如，密码喷雾通过采用一个密码并将其扔到多个帐户中来进行工作，而密码强行强制使用一个帐户并针对该帐户抛出许多密码。 关于供应链攻击和云基础架构配置错误的报告很多。

When we think about attacks on the cloud, we can group them as such:

当我们考虑对云的攻击时，可以将它们按以下方式分组：

Tenant level (Any organisation that puts their infrastructure in the cloud)

租户级别 (将基础架构置于云中的任何组织)

• User elevated to tenant admin
  用户提升为租户管理员
• Multi factor authentication changed
  多因素身份验证已更改

Subscription level

订阅级别

• External accounts added to subscription
  外部帐户已添加到订阅
• Stale accounts with access to subscription
  可订阅的陈旧帐户
• Attack detection service not configured properly
  攻击检测服务配置不正确

IAAS

国际会计准则

• Known hacker/malicious tool/process found
  发现已知的黑客/恶意工具/进程
• Account password hash accessed
  帐户密码哈希已访问
• Anti-malware service disabled
  反恶意软件服务已禁用
• Brute force login attack detected
  检测到暴力破解登录攻击
• Communication with a malicious IP
  与恶意IP通信
• TOR IP detected
  检测到TOR IP
• File-less attack technique detected
  检测到无文件攻击技术
• Outgoing DDoS attacks
  传出DDoS攻击

PASS

通过

• Malicious key vault access — keys enumerated
  恶意密钥库访问-枚举的密钥
• Anonymous storage accessed
  访问了匿名存储
• Activity from unfamiliar location
  来自陌生地点的活动
• SQL injection detected
  检测到SQL注入
• Hadoop YARN exploit
  Hadoop YARN漏洞利用
• Open management ports on kubenetes nodes
  在kubenetes节点上打开管理端口
• Authentication disabled for App/Web services
  App / Web服务的身份验证已禁用

SASS

萨斯

• A potentially malicious URL click was detected
  检测到潜在的恶意URL点击
• Unusual volume of external file sharing
  外部文件共享量异常
• Password spray login attack
  密码喷雾登录攻击

We should think about all these areas that need to be secured. Besides securing cloud infrastructure, it is also important to apply a good monitoring mechanism to respond to any kind of incident. But the problem is — are SOCs (Security Operations Centre) really prepared?

我们应该考虑所有需要确保的领域。 除了保护云基础架构之外，应用良好的监视机制以响应任何类型的事件也很重要。 但是问题是，是否真的准备好SOC(安全运营中心)？

There are many challenges surrounding the implementation of a cloud monitoring system that prevent SOCs from keeping up to date.

围绕云监控系统的实施存在许多挑战，这些问题阻止了SOC保持最新状态。

• Most cloud platforms are tenants or are based on subscription models, therefore creating new boundaries
  大多数云平台是租户或基于订阅模型，因此创建了新的界限
• Many cloud services = many attack types, and these attacks are becoming more sophisticated
  许多云服务=许多攻击类型，并且这些攻击正变得越来越复杂
• Since cloud environments are still relatively new, gaining familiarity with this new technology involves a steep learning curve
  由于云环境仍是相对较新的，因此熟悉这项新技术会涉及陡峭的学习曲线
• If you have an on-premise SOC and you want to create a hybrid environment, it makes detection and investigation complex
  如果您具有本地SOC，并且要创建混合环境，那么检测和调查将变得很复杂
• Cloud infrastructure and services are a lot more dynamic in nature. Organisations will keep on running new services while cloud service providers rapidly will concurrently release new features. Furthermore, DevOps and SRE teams make frequent changes to their production systems. It will take a huge amount of effort to keep SOCs up to date with these new services.
  云基础架构和服务本质上更具动态性。 组织将继续运行新服务，而云服务提供商将Swift同时发布新功能。 此外，DevOps和SRE团队会对其生产系统进行频繁更改。 要使SOC保持这些新服务的最新状态，将需要付出巨大的努力。

If our servers are on-premise, we have control over the network. If an incident happens, we can perform actions like blocking IP or taking down the machine. However, we may not have the same flexibility on the cloud. Monitoring will require establishing partnerships with SOC analysts, cloud resource owners, subscription owners, and cloud service providers. SOC analysts may even need intervention from cloud resource owners in order to obtain resources to conduct investigations or for implementing remediation steps.

如果我们的服务器是本地服务器，则我们可以控制网络。 如果发生事件，我们可以执行诸如阻止IP或关闭计算机之类的操作。 但是，我们在云上可能没有相同的灵活性。 监视将需要与SOC分析人员，云资源所有者，订阅所有者和云服务提供商建立伙伴关系。 SOC分析人员甚至可能需要云资源所有者的干预才能获得进行调查或实施补救步骤所需的资源。

In order to implement an effective cloud monitoring system, we have to identify the odds and events that are generated in the aforementioned attacks. We can divide event types into four categories:

为了实施有效的云监控系统，我们必须确定上述攻击中产生的几率和事件。 我们可以将事件类型分为四类：

• Control plane logs — ex: Create, update, and delete operations for cloud resources
  控制平面日志—例如：创建，更新和删除云资源的操作
• Data plane logs — ex: Events logged as a part of cloud resource usage or Windows events in a VM, SQL audit logs etc.
  数据平面日志-例如：作为云资源使用的一部分记录的事件或VM中的Windows事件，SQL审核日志等。
• Identity logs — When you design cloud infrastructure, you need to identify the identity architecture. It should be possible to map identity with any action, such as AuthN, AuthZ events, AAD logs etc.
  身份日志-设计云基础架构时，需要标识身份架构。 应该可以通过任何动作来映射身份，例如AuthN，AuthZ事件，AAD日志等。
• Baked alerts — ex: Ready to consume security alerts, ASC, CASB etc.
  烘焙警报—例如：准备使用安全警报，ASC，CASB等。

It’s very beneficial to have a common raw events repository and an alert/log template that can help in log analytics. Additionally, it’s also better to include these data as a common template:

拥有一个通用的原始事件存储库和一个警报/日志模板可以帮助进行日志分析，这是非常有益的。 此外，最好将这些数据作为通用模板包括在内：

Event ID, Event name, Subscription ID, Resource name, Resource ID, Event time, Data centre, Meta data, Prod or dev, Owner ID, User ID, Success or failure.

事件ID，事件名称，订阅ID，资源名称，资源ID，事件时间，数据中心，元数据，产品或开发，所有者ID，用户ID，成功或失败。

This can help build your custom monitoring scenarios and help your SOC to run investigations.

这可以帮助构建您的自定义监视方案，并帮助您的SOC进行调查。

Some alerts and logs can be false positives which may generate lots of load for the SOC. To prevent overloading, we can configure some limits so that it can be redirected to the resource owner. If the resource owner feels like a certain alert or log needs an investigation, they can then redirect them to the SOC.

某些警报和日志可能是误报，可能会给SOC带来很多负担。 为了防止过载，我们可以配置一些限制，以便可以将其重定向到资源所有者。 如果资源所有者感觉需要某种警报或日志，则可以将其重定向到SOC。

SIEM (Security information and event management) system’s design and architecture is evolving too. If your on-premise infrastructure already has SIEM setup, it’s better to start bringing cloud events to an on-premise SIEM. Most cloud providers have connectors to popular SIEM’s that makes integration seamless. Over time, you can also consider moving to a cloud-based SIEM so that you can move on-premise events to the cloud SIEM. The last approach is to combine cloud and on-premise things into one big data platform. It provides more flexibility and a great user experience.

SIEM(安全信息和事件管理)系统的设计和体系结构也在不断发展。 如果您的内部部署基础结构已具有SIEM设置，则最好开始将云事件引入到内部SIEM。 大多数云提供商都提供了与流行的SIEM的连接器，从而使集成变得无缝。 随着时间的流逝，您还可以考虑迁移到基于云的SIEM，以便可以将本地事件迁移到云SIEM。 最后一种方法是将云和本地事物组合到一个大数据平台中。 它提供了更大的灵活性和出色的用户体验。

There are various mechanisms to fetch events:

有多种获取事件的机制：

• REST API calls
  REST API调用
• Connectors by SIEM vendors
  SIEM供应商提供的连接器
• Conversion to standard Syslog format
  转换为标准Syslog格式

Skilling up your analysts and engineers is the key to success. Start by providing trainings about cloud concepts like IAAS, PASS, and SAAS. You can begin with IASS as it is more close to on-premise before moving on to PASS, which is more complex than IASS. Try to avoid specific things, accept flexibility, find people who understand data, and keep learning.

技能娴熟的分析师和工程师是成功的关键。 首先提供有关IAAS，PASS和SAAS等云概念的培训。 您可以从IASS开始，因为它更接近本地，然后再进行PASS，这比IASS更为复杂。 尝试避免特定的事情，接受灵活性，找到了解数据的人并继续学习。

To be successful in implementing a proper monitoring system, we have to configure it right. We can apply tools like Azure CIS benchmark to achieve this. Prioritisation is super critical. We have limited resources but have hundreds of use cases. We can use threat modelling to prioritise monitoring scenarios and cut noises.

为了成功实施适当的监视系统，我们必须正确配置它。 我们可以应用诸如Azure CIS基准测试之类的工具来实现这一目标。 优先级至关重要。 我们的资源有限，但有数百个用例。 我们可以使用威胁建模来确定监视方案的优先级并降低噪音。

And last but not least, we cannot forget the importance of constantly scaling up team skills, designing the right SIEM architecture, and establishing a mechanism to keep up with new features in the cloud.

最后但并非最不重要的一点是，我们不能忘记不断提高团队技能，设计正确的SIEM架构并建立一种机制以跟上云中新功能的重要性。

翻译自: https://medium.com/paloit/how-to-effectively-implement-monitor-cloud-infrastructure-f14d28260345

视频监控云服务架构