Bernard Golden, chief executive of Hyperstratus Consulting, wrote that one after another survey showed that security is the most worrying issue for potential users of public cloud computing. For example, a April 2010 survey found that more than 45% of respondents said cloud computing risks outweigh the benefits. A survey conducted by CAS and Ponemon Cato also found that users have such concerns. However, they also found that, despite the user's doubts, cloud applications were being deployed. The continued release of similar surveys and results suggests that mistrust of cloud computing security continues.
Admittedly, most concerns about cloud security are related to public cloud computing. The global IT practitioner is constantly proposing the same problem with a public cloud service provider. For example, Golden recently went to Taiwan and delivered a speech at the Taiwan Cloud SIG Conference. 250 people attended the meeting. As expected, the first question that people ask him is "is the public cloud environment safe enough for me to use a private cloud to avoid security issues?" All seem to think that public cloud providers are untrustworthy.
However, the discussion of cloud security boils down to the "public cloud is unsafe, private cloud security" formula seems too simplistic. Simply put, there are two big lies (or two basic misunderstandings) in this view. The main reason is that this new computing model forces a dramatic change in security products and methods.
The first cloud security lie: private cloud is safe
The first lie is that the private cloud is safe. This conclusion is based solely on the definition of a private cloud: The private cloud is deployed within the boundaries of the enterprise's own data center. The misconception arises from the fact that cloud computing contains two key distinctions that differ from traditional computing: Virtualization and dynamics.
The first difference is that the technology base of cloud computing is based on an application management program. The management program can isolate calculations (and their associated security threats) from traditional security tools, and check for inappropriate or malicious packets in network traffic. Because virtual machines in the same server can communicate entirely through communication in the hypervisor, packets can be sent from one virtual machine to another without having to go through a physical network. Generally installed security devices check traffic on the physical network.
Crucially, this means that if a virtual machine is compromised, it can send dangerous traffic to another virtual machine, and traditional defenses will not even be noticed. In other words, an insecure application can cause attacks on other virtual machines, and the security measures used by the user are powerless. Just because a user's application is in a private cloud does not guarantee that the application will not have security issues.
Of course, one might point out that this problem comes with virtualization and does not involve any aspect of cloud computing. This view is correct. Cloud computing represents a combination of virtualization and automation. It is the second factor that leads to another security flaw in the private cloud.
Cloud computing applications benefit from automation for flexibility and resiliency, manage changing traffic load types by rapidly migrating virtual machines and start additional virtual machines, and respond to changing applications. This means that the new instance can be online within minutes without any human intervention. This also means that any necessary software installation or configuration must also be automated. Thus, when a new instance is added to an existing application pool, it can be used immediately as a resource by other applications.
It also means that any necessary security software must be automatically installed and configured without human intervention. Unfortunately, many organizations now have to rely on security personnel or system administrators to manually install and configure the necessary security components, and this is usually the second step after the installation and configuration of other software components of the machine.
In other words, many organizations do not match the practical aspects of the security practices and cloud requirements. The idea that the private cloud itself is safe is now considered incorrect. Security vulnerabilities are sure to occur before user security and infrastructure practices are consistent with automated instances.
Moreover, it is important to make them consistent. Otherwise, this can happen: the user's application automation exceeds the ability to respond to security practices. This is not a good phenomenon. There is no doubt that people do not want to face the fact that a private cloud that seems secure ultimately has security vulnerabilities, because the automation features of cloud computing are not yet extended to all aspects of the software infrastructure.
So the result of the first big lie about cloud computing is that the private cloud itself is unsafe.
The second cloud security lie: The public cloud is unsafe
The second lie about cloud computing security is the assumption of public cloud security, especially the mistaken belief that the security of public cloud computing depends entirely on the cloud service provider. The reality is that the security of the service provider domain is the responsibility shared by the provider and the user. The service provider is responsible for the security of the infrastructure and the interface between the application and the managed environment, the user is responsible for the security of the connection to the environment, and, more importantly, the internal security of the application itself.
Failure to properly configure an application, such as an environment security interface, or failure to take appropriate application-level security precautions can cause problems for users. Any provider may not be responsible for this security issue from within the user application.
Let the author provide an example. A company that works with us puts its core apps on Amazon's Web services. Unfortunately, the company does not have security measures for the vulnerabilities that Amazon Web Services security might have, nor does it take any safeguards against application design issues.
In fact, Amazon provides a virtual machine-level firewall (called a security group). People configure this firewall to allow packets to access specific ports. The best practices associated with security groups are partitioning them so that they provide a very granular access port for each virtual machine. This ensures that only traffic that is applicable to that type of machine can access an instance. For example, a Web server virtual machine is configured to allow traffic on port 80 to access this instance, and the database virtual machine is configured to allow traffic on port 80 to access this instance. This prevents attacks from external sources that exploit web traffic to database instances that contain important application data.
To build a secure application, people must use security groups correctly. But the following user did not do so. It uses a security group for traffic that accesses all instances. This means that any type of traffic that accesses any instance can access each type of instance. This is clearly an example of the lack of proper use of the Amazon Web Services security mechanism.
As for the user's application itself, it also uses bad security measures. Instead of partitioning the application code among different types of machines, it loads all the application code into the same instance. This instance can receive traffic from its corporate web site and code that contains proprietary algorithms.
The key fact of the situation is that if the user assumes that all security responsibilities are borne by the cloud service provider (Amazon Web service in this case), this would be a serious oversight because the user himself did not take important steps to address the security issue, The security issue is that any cloud service provider will not be responsible. This is the sense of shared responsibility-both sides must establish their own security areas of control. Failure to do so means that the application is unsafe. Even if the cloud service provider is doing everything right and perfect within its control, the application will become unsafe if the owner of the application does not perform its duties correctly.
' I've seen a lot of security people discuss issues with public cloud service providers, Golden said. They refuse to assume the responsibility of their companies in the public cloud environment, insisting on turning every security issue into the concerns of cloud service providers.
Frankly, it makes me feel that their ideas are very rash. Because it implies that they refuse to do the necessary work seriously in order to create an application that is as secure as possible based on the public cloud service provider. This attitude shows that it seems that all security responsibilities are in the cloud service provider, and that further development is to assume that his company has nothing to do with any security incidents in applications running in the public cloud service provider environment. Thus, this argument is not surprising: The private cloud is strongly supported by the people concerned, claiming that the private cloud has superior security compared to the public cloud.
The reality is that users are increasingly deploying applications in the public cloud service provider environment. It is important for security organizations to ensure that they take all possible steps to execute applications as securely as possible. This means that users themselves need to take some relevant measures in this regard.
So security is the third track of cloud computing. Security has been said to be the inherent benefits of private cloud and the fundamental flaw in public cloud computing. In fact, the facts are more ambiguous than those implied. It is not very responsible to assert that the public cloud environment has security flaws and does not seriously consider how to mitigate these unsafe factors.
A private cloud application that is poorly managed and poorly configured is equally vulnerable to attack. and a properly managed and configured public cloud application can achieve good security. The description of this situation as a black-and-black is simple, will endanger the normal development of the cloud environment.
When choosing between two different cloud environments, it is more constructive to ask what actions must be taken to achieve the goal of securing the application as much as possible, in terms of time, budget, and risk tolerance. Considering a specific environment and application, security is never a simple question of black or white, but rather how to illuminate the security gray zone of the two cloud types as far as possible. Not being aware of this point of view is no good for ensuring that an enterprise's infrastructure is as efficient and cost-saving as possible.
(Responsible editor: admin)