这篇博客介绍了如何利用OpenCV库强化在云端的图像处理。内容涵盖图像强化技术，旨在提高计算机视觉应用的性能。
opencv图像强化
“Hardening” is one of those words that always appear in all kinds of meetings but nobody is clear about what it is. Loved by some, hated by others, it reminds me of that phrase about big data:
“强化”是经常在各种会议中出现的词语之一，但没人知道它是什么。 受到某些人的爱，却受到其他人的恨，这让我想起了有关大数据的那句话：
“Big data is like teenage sex: everyone talks about it, nobody really knows how to do it, everyone thinks everyone…”
“大数据就像十几岁的性行为：每个人都在谈论它，没有人真正知道如何做，每个人都认为每个人……”
Dan Ariely — Professor of Psychology & Behavioral Economics @ Duke University
Dan Ariely-杜克大学心理学与行为经济学教授
But really, what’s hardening? Hardening is the process of strengthening a system to reduce the exposure surface and attack vectors using different tools and configurations.
但是，实际上，有什么要硬化的？ 硬化是使用不同的工具和配置来增强系统以减少暴露表面和侵蚀矢量的过程。
The concept is simple but also generic. Hardening can be applied to any computer system: applications, operating systems, networks, databases, cloud platforms… But the issue we are dealing with today is the automation of hardening images in cloud systems such as AWS, Azure or GCP.
这个概念既简单又通用。 强化可以应用于任何计算机系统：应用程序，操作系统，网络，数据库，云平台……但是，我们今天要解决的问题是在AWS，Azure或GCP等云系统中自动强化图像。
独联体基准 (CIS Benchmarks)
The entity with the greatest recognition in the area of strengthening operating systems is the CIS (Center of Internet Security), which has quite exhaustive security controls. These controls are divided into two different levels:
在加强操作系统方面最受认可的实体是CIS(互联网安全中心) ，它具有相当详尽的安全控制措施。 这些控件分为两个不同的级别：
Level 1 (L1): It is considered a basic recommendation that can be implemented fairly quickly and is designed not to have a major impact on performance. The aim is to reduce your organization’s attack surface while keeping machines usable and not hampering business functionality.
级别1(L1) ：被认为是可以很快实施的基本建议，其设计不会对性能产生重大影响。 目的是减少组织的攻击面，同时保持机器的可用性，并且不妨碍业务功能。
Level 2 (L2): It is considered “defence in depth” and is intended for environments where security is essential. Recommendations associated with the Level 2 profile can have an adverse effect on your organization if not implemented properly or without due care.
级别2(L2) ：被认为是“深度防御”，适用于对安全性至关重要的环境。 如果未正确实施或未给予适当注意，则与2级配置文件相关的建议可能会对您的组织产生不利影响。
On its website, the CIS provides some Python scripts to provide a solution to these different controls and thus ensure that you comply with their regulations:
CIS在其网站上提供了一些Python脚本，以提供针对这些不同控件的解决方案，从而确保您遵守其法规：
CIS also has its own built hardened images for the different cloud platforms, but with an additional price of $15/month per machine, quite expensive, isn’t it?
CIS还为不同的云平台构建了自己的强化映像 ，但是每台机器每月额外收取15美元的价格，这是相当昂贵的，不是吗？
But now we have those Python scripts. Why pay when you can do it yourself?
但是现在我们有了那些Python脚本。 如果您自己可以付款，为什么还要付款？
1.自定义脚本 (1. Customize scripts)
CIS python scripts present a problem: the configuration of the operating system from which they start differs from the configuration of the AWS or Azure instances and therefore if we execute the scripts without modifying we will not be able to access our instances again. ⚠️
CIS python脚本存在一个问题：它们从其启动的操作系统的配置与AWS或Azure实例的配置不同，因此，如果我们在不修改的情况下执行脚本，将无法再次访问我们的实例。 ⚠️
So the first task is to detect which controls corrupt our instance and which don’t. To do so, it is necessary to understand the logic of the controls, avoiding trivial tests and putting effort into complying with those that may really pose a risk, as well as knowing the context in which the scripts will be executed.
因此，首要任务是检测哪些控件损坏了我们的实例，哪些没有损坏。 为此，有必要了解控件的逻辑，避免进行琐碎的测试，并努力遵循可能真正带来风险的测试，并了解执行脚本的上下文。
Let’s see a practical example: The following image shows a level 1 control that indicates that access to the /etc/motd file should be restricted to the root user.
让我们看一个实际的例子：下图显示了一个1级控件，该控件指示对/etc/motd文件的访问应仅限于root用户。
However, in AWS this file does not exist and the /etcúnicamente folder is editable by the root user, therefore, the test should pass correctly but it will not because the file does not exist and therefore, the CIS analysis, when trying to check its permissions will fail, giving the control as failed.Is this control so important? Obviously not, so just get rid of it.
但是，在AWS中，此文件不存在，并且/etcúnicamente文件夹可以由root用户编辑，因此，测试应该正确通过，但是不会，因为文件不存在，因此，当尝试检查其文件时，会进行CIS分析。权限将失败，从而使控件失败。此控件如此重要吗？ 显然不是，所以就摆脱它。
Once the problematic tests have been excluded, we’re going to create our own script and then automate the creation of images.
一旦排除了有问题的测试，我们将创建自己的脚本，然后自动创建图像。
2.合规 (2. Compliance)
As we fine-tune the scripts to cover as many controls as possible, we will perform scans to see the result.
当我们对脚本进行微调以覆盖尽可能多的控件时，我们将执行扫描以查看结果。
The following image shows an analysis of the CIS (L1 and L2) on a machine recently created in AWS with Ubuntu 16.04, where we see that out of 412 security controls, only 209 have passed.
下图显示了在最近使用Ubuntu 16.04在AWS中创建的机器上的CIS(L1和L2)的分析，我们发现在412个安全控件中，只有209个已通过。
On the other hand, in this image we have the analysis of the CIS (L1 and L2) on a machine in AWS with Ubuntu 16.04 where we have already executed our scripts and we see that 357 controls pass satisfactorily:
另一方面，在此图像中，我们对具有Ubuntu 16.04的AWS中的计算机上的CIS(L1和L2)进行了分析，在该计算机上我们已经执行了脚本，并且看到357个控件令人满意地通过了：
As I mentioned in the previous point, achieving 100% compliance is really complicated and impractical, as well as a waste of energy, so it is important to understand the controls we have left unchecked. Once satisfied with the result, we can guarantee the percentage of compliance that these scripts guarantee, as in the table below:
正如我在前面提到的那样，实现100％的合规性确实是复杂且不切实际的，而且浪费能源，因此了解我们未经检查的控制措施非常重要。 对结果满意后，我们可以保证这些脚本所保证的合规性百分比，如下表所示：
3.自动化 (3. Automation)
With the scripts already adjusted and tested, we just need to automate the flow so that the hardening process can be performed daily and the new images generated can be consumed by other users, even anonymously.
在脚本已经过调整和测试的情况下，我们只需要自动化流程就可以每天执行强化过程，并且其他用户甚至可以匿名使用生成的新图像。
In this case, I’ve made the example for AWS and through Github Actions but any other CI is welcome (Travis, Jenkins, CircleCI…). In the image below you can see the 8 phases that make up the script developed for it and its execution in that CI:
在这种情况下，我已经通过AWS和Github Actions制作了示例，但欢迎使用任何其他CI(Travis，Jenkins，CircleCI…)。 在下图中，您可以看到组成为该脚本开发的脚本以及在该CI中执行脚本的8个阶段：
Get latest image: AWS updates its OS images daily, so we need to get the most recent but stable image.
获取最新映像： AWS每天都会更新其操作系统映像，因此我们需要获取最新但稳定的映像。
Create an instance: Once we have image id, we launch an instance where we will run the script.
创建一个实例 ：一旦有了图像ID，我们将启动一个实例，在该实例中运行脚本。
Run Script: We upload the scripts and execute them through SSH, WinRM or some service such as AWS Systems Manager.
运行脚本 ：我们上传脚本并通过SSH，WinRM或某些服务(例如AWS Systems Manager)执行它们。
Reboot: Scripts require a restart for the new configuration to be loaded.
重新启动 ：脚本需要重新启动才能加载新配置。
Healthy checks: As we’ve seen, the scripts could corrupt the images, so we made sure through running a battery of tests.
健康检查 ：如我们所见，脚本可能会破坏图像，因此我们通过运行一系列测试来确保。
Create new image: Confirmed that the instance works correctly, we create a new image from it.
创建新图像 ：确认实例正常运行，我们从中创建一个新图像。
Share/Publish the new image: If other accounts or regions must use it, we must make it public or share it with interested accounts.
共享/发布新图像 ：如果其他帐户或地区必须使用它，我们必须将其公开或与感兴趣的帐户共享。
At this point, we already have original hardened AWS images. Now we can use IAM policies or other services such as AWS Service Catalog to facilitate the use of these secure images instead of the original ones that do not have such a robust configuration. And of course, to notify in the appropriate channel the new images generated:
至此，我们已经拥有原始的强化AWS映像。 现在，我们可以使用IAM策略或其他服务(例如AWS Service Catalog)来简化这些安全映像的使用，而不是使用没有如此强大配置的原始映像。 当然，要在适当的频道中通知生成的新图像：
Now comes the most complicated part of this whole process. Promote among the teams the use of these secure images, to, in the future, restrict the use of original images and not hardened.
现在是整个过程中最复杂的部分。 在团队之间促进这些安全图像的使用，以在将来限制原始图像的使用，而不是对其进行强化。
翻译自: https://medium.com/swlh/hardening-images-on-cloud-b4269944ee6c
opencv图像强化
1038
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
