云计算的安全问题将引起企业的重视
人们听说过很多关于多云战略的利弊，但令人吃惊的是一些组织认为他们不需要担心这个问题。他们确实也做到了。
企业需要重视云计算中的安全问题，当企业与多个云计算提供商进行交互时，安全性变得更加重要。采用多云对于大多数组织来说几乎是确定的，因为一个云计算提供商可能会提供另一个提供商不会提供的特定功能和定价。
由于安全的具体问题，多云策略成为企业面临的一项挑战。这可能是由于采用错误的安全方法，而随着时间的推移，其情况只会变得更糟，因为对云计算的应用承诺将会增加，企业选择的公共云提供商数量也会增加。
应用程序部署和安全性只有一种最好的方法，即使所有的宿主资源和行为相同。如果应用程序的部署和维护操作发生变化，这将使企业采用的安全程序变得复杂。这是因为在企业的托管选项中实施（甚至是功能）会有所不同。混合云也是如此，尤其是在多云环境下。每个云计算提供商和企业自己的数据中心都有独立的托管框架，企业需要确保它们的安全性。另外，通过提供商和虚拟专用网络（VPN）传递的工作流程也是其安全挑战的一部分。
面对云计算的安全问题
多云安全技术必须解决以下四种安全问题：
首先，无论使用哪种云计算，以及无论在公共云提供商之间移动或运行多少应用程序，他们都必须为托管在任何公共云中的应用程序和组件提供安全性。
其次，安全工具需要为每个多云提供商托管或连接的企业数据提供信息安全保障。
第三，当发生故障或组件在负载中扩展或减少时，它们必须在重新部署组件期间保证安全。
最后，安全技术需要适应新增的服务提供商或功能。
工具的分类
多云用户有三种工具可用于解决云计算中的安全问题：
-公共云安全服务和功能因供应商而异；
-网络安全和访问和转发控制功能；
-应用程序本身内置或添加到应用程序本身的应用程序安全工具。
企业期望在多云安全计划中使用所有这些功能。
应用程序安全工具对于多云用户来说是很好的选择，因为它们随应用程序一起移动。用户会使用许多不同的公共云提供商提供的服务。但是，这些工具通常旨在保护用户访问应用程序的点，他们不保护应用程序组件彼此连接的位置。企业需要检查自己的应用程序规范，以查看是否有组件保护功能。如果没有，可以使用API代理来保护这些组件接口。
接下来，企业为了解决云计算中的安全问题，需要了解服务提供商提供的工具。主要的公共云提供商拥有专门用于安全和访问控制的全套Web服务，其中包括身份管理和安全审计工具。当公共云被用作传统应用程序的前端时，这些工具的工作效果最好，这意味着与每个云提供商的远程和移动工作特性结合在一起。
如果企业采用的多云只有一个前端应用程序提供商，或者其前端提供商按其所服务的地理区域进行分组，那么这些技术可能成为用户安全性的第一道防线。
云计算提供商的工具非常适合用户访问控制。但是，为了保护应用程序，特别是跨云提供商边界扩展或被多个应用程序使用的微服务，企业可能需要查看API安全工具。微服务通常使用API代理来控制访问，这些还提供负载平衡。请注意，这些工具会增加组件间工作流程的开销。这可能是存在许多应用程序组件或微服务以及许多API的主要问题。
确保组件的安全
组件安全性是探索可用网络安全和访问控制功能的好地方。
企业网络是一种将用户与应用程序相连接的结构，并支持跨所有托管选项和云计算提供商使用的应用程序和组件互连。企业自己的光纤网络由一个VPN构建而成，并且每个多云提供商都将为企业在此处托管的应用程序拥有自己的专用地址空间。这些应用程序的onramps或外部API将被转换为企业的VPN上的地址，例如网络地址转换，亚马逊的弹性IP地址等等。
每个应用程序都有两套工作流程：应用程序边界内的工作和外部连接的工作。后者是企业将在VPN上看到的onramps，并且这些应该被收集到一系列具有IP地址块的应用子网中。这使企业可以更轻松地建立转发规则或防火墙规则，以通过IP地址限制流量；一个条目足以满足整个应用程序的需要。
跨多云边界的应用程序扩展和故障转移是一个主要的安全问题。企业每次移动或添加内容时，都必须记住以安全的方式进行连接。移动和缩放的一个通用解决方案是使用负载平衡器。这个工具将一个地址通告给企业的VPN，但它可以连接到应用程序或组件的任意数量的实例。而且，如果企业移动组件，其负载平衡器的地址不会改变。像这样的工具可用于私有云、Docker和其他应用程序部署框架。即使企业没有在负载下扩展应用程序，它们也可以在多云场景中移动组件时提供帮助。
无论企业在何处托管应用程序，其应用程序安全原则都是相同的。公共云和多云使用为应用程序安全增加了一些维度，并且这些可能会干扰处理云计算安全问题的传统技术，其中包括保护信息和访问。为了实现多云安全，企业需要采取正确的步骤，但随着云计算提供商数量的增加，应用这些安全措施的需求和方式也会不断变化。
网站栏目：云计算的安全问题将引起企业的重视
URL网址：http://scyanting.com/article/ccggj.html
