The public cloud and the private cloud, who is more secure?

According to Bernard Golden, chief executive of Hyperstratus Consulting, a survey of one after another shows that security is the most worrying issue for potential users of public cloud computing. For example, a April 2010 survey noted that more than 45% of respondents felt the risk of cloud computing outweighed the benefits. A similar concern was found in a survey conducted by CAS and Ponemon Cato. However, they also found that, despite these concerns, cloud applications were being deployed. The continuation of similar surveys and results suggests that mistrust of cloud computing security continues.

Of course, most of the concerns about cloud computing are related to public cloud computing. The global IT practitioner is constantly proposing the same problem with a public cloud service provider. Golden, for example, went to Taiwan this week 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 public cloud computing safe enough that I should 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

The first lie is that the private cloud is safe, and 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 datacenter. The misconception arises from the fact that cloud computing contains two key distinctions that differ from traditional computing: virtualization and dynamism.

The first 1 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 the organization's defenses are not even aware of it. In other words, an insecure application can cause attacks on other virtual machines, and the security measures used by the user are powerless. There is no security problem because a user's application is located in a private cloud and does not protect the application.

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 element of another security flaw that arises from the private cloud.

Cloud computing applications benefit from automation to achieve flexibility and resilience, manage changing workloads by rapidly migrating virtual machines and start additional virtual machines, and respond to changing application conditions. This means that the new instance can be online within minutes without any human intervention. This 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 as a resource immediately.

It also means that any required security software must be automatically installed and configured without human intervention. Unfortunately, many organizations rely on security personnel or system administrators to manually install and configure the necessary security components, but this is usually the second step after the installation and configuration of the other software components of the machine.

In other words, many institutions do not match the reality of the cloud requirements in terms of security practices. It is incorrect to estimate that the private cloud itself is safe. Security vulnerabilities are sure to occur before your security and infrastructure practices are consistent with automated instances.

Moreover, it is important to make them consistent. Otherwise, you may be in the situation where your application automation exceeds your ability to respond to security practices. This is not a good phenomenon. There is no doubt that people do not like to explain why a security-like private cloud 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 lies

The second lie about cloud computing security is speculation about the security of the public cloud, especially the assumption 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 accessing the interface of the environment, and, more importantly, the internal security of the application itself.

Failure to properly configure applications, such as environmental security interfaces or failure to take appropriate application-level security precautions, can cause problems for users. No provider may be liable for such problems.

Let me provide an example. A company that works with us puts its core apps on Amazon's Web services. Unfortunately, the company has neither implemented security vulnerabilities for Amazon Web Services security, nor taken action on 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 appropriate for 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 poor use of Amazon's Web services security mechanism.

With regard to the user's application itself, it takes a bad security measure. It does not partition application code among different types of machines, and it loads all application code into the same instance. This instance receives communications from its corporate web site, as well as 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 it does not take important steps to address security issues, And this security issue is not a cloud service provider to bear the relevant responsibility. This is the sense of shared responsibility-both sides must establish their own security aspects of control. Failure to do so means that the application is unsafe. Even if the cloud service provider is doing the right thing within its control, the application will be 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 their company's responsibilities in the public cloud environment, insisting on turning every security issue into a concern for cloud service providers.

Frankly, it makes me feel that they are thoughtless 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 seems to be all about the security responsibility of the cloud service provider, and the further development is to assume that his company has nothing to do with any security incidents with applications running in the cloud service provider environment. So this is not surprising: The private cloud is strongly supported by the people concerned, claiming that the private cloud has superior security.

The reality is that users are increasingly deploying applications in the public cloud services 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 also need to take steps 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 seems irresponsible 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 vulnerable to attack. and a properly managed and configured public cloud application can achieve good security. To describe this situation is not black or simple, it will endanger this cloud environment.

A more constructive approach in both environments is to ask what action must be taken to achieve the goal of ensuring application security 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 a matter of how to turn black into white as much as possible.