Connecting to the Cloud, part 3rd: Cloud Governance and security-securing Hybridcloud applications

This article is the 3rd and final part of a series of articles on building mixed cloud applications, examining governance and security for cloud computing. This article expands the Hybridcloud application for part 2nd by examining how to add access control policies to the Amazon simple Queue Service (SQS). Learn more about how Hybridcloud applications authenticate themselves to cloud services and how to add audit trails to Amazon's S3 (simple Storage service). Finally, look at how Google Apps uses OAuth and how force.com cloud services can avoid inadvertent denial of service (Denial-of-service,dos) attacks through built-in testing.

Introduction

Cloud governance involves applying policies to the use of cloud services. When it comes to cloud governance, it's good to look at its downside: the organization's use of cloud services without any supervision, causing confusion. To avoid this confusion, apply policies when using cloud services to control the disclosure of privacy information to the cloud and control the misuse of cloud services (cloud services, after all, need to be paid). After governance and security are in place, you can confidently use cloud computing.

Experience from SOA governance

Common Acronyms


API: Application Programming Interface DSA: Digital Signature Algorithm Ip:internet protocol IT: Information technology REST: Image State Transport SOA: service-Oriented Architecture SSL: Secure Sockets Layer URI: Uniform Resource Locator Wsdl:web Service Description Language XML: Extensible Markup Language

Governance is only popular after SOA is adopted. In the SOA realm, governance is divided into design-time governance (defining policies for WEB services) and run-time governance (in effect, applying these policies to live data streams).

Cloud platforms, like services in SOA, are accessed primarily through the WEB services APIs, so they should belong to a category with SOA governance. At the very least, you can reuse the principles in SOA governance.

SOA governance often relies on registrars. This is a central point where users can view the services in an SOA and view the policies applied to the service. Standard WS and its complementary ws-attachment specification allows policies to be assigned to services in an SOA. Therefore, the service contains a pointer to the policy. Registrars manage this relationship between services and policies.

Another important function of SOA governance offerings is managing the lifecycle of services. This refers to the ability to control and track changes, and to control who has the power to change the service. When this functionality is in place, the organization can determine who created the service and when it was changed.

Does SOA governance mean that cloud governance issues have been resolved? This is not absolute. The messages sent by the cloud service and messages sent from the cloud are generally not SOAP, and these services are typically not WSDL-defined, and these two standards typically appear in SOA governance. This means that cloud services cannot be simply imported into the SOA Governance register. The WEB services used by cloud computing bypass SOAP and WSDL, but take advantage of lightweight rest-style services, which are widely used by developers for simplicity.

Virtual machines are another new aspect of cloud computing, which distinguishes cloud computing from SOA. In addition to leveraging WEB services, cloud computing also leverages virtual machines. The Amazon elastic Compute Cloud (EC2) environment can be viewed as a virtualized hosting environment, not a set of services. As a result, Amazon EC2 governance can be seen as an example of virtual machine governance. In particular, the deployment of virtual machines is likely to be a confusing situation, as organizations may use a number of virtual machines that are slightly different from each other. As with the experience of many VMware or Citrix Xen users, it is difficult for individual users to track virtual machines. Imagine that an organizational problem is much more complicated, and it's even more difficult if the virtual machine resides on a third cloud service.

However, there are some similarities between virtual machine (VM) governance and "lifecycle governance" of SOA governance. In the Amazon EC2 Cloud, the VM is an instance of the Amazon Machine Image (AMI). It is important to be able to enforce rules so that specific users can deploy certain AMI. At a more granular level, it is also important to be able to control who can reboot the VM, who can add capacity to the existing VM environment, and who can delete an existing virtual machine instance.

The last item above (that is, removing the Amazon AMI instance) is particularly important because organizations must pay to use these instances. Pricing is based on use (when the image is running) and data traffic. Without a cloud governance system, you might run more instances of AMI machines that do not need to run, resulting in unnecessary costs. However, the converse is also true: if there is no cloud governance solution, you may accidentally delete useful AMI instances. The life cycle management of an AMI instance avoids unwanted instances, just as the useless services are constantly growing in the organization when SOA governance processes do not use a governance framework.

Process rather than product

SOA governance is generally considered to be a process rather than a product. Cloud governance also adheres to this rule. Implementing governance rules requires the developer to know that the governance framework is ready. For example, if the SOA governance registrar is deployed, developers must be aware that the WEB services (especially their WSDL definitions) should be registered here. WEB services are under surveillance if they are not registered. If developers are not required to register for cloud services through the organization where the cloud services are located, similar events may occur in SOA governance.

In the domain of SOA governance, there is a run-time governance in addition to the design-phase governance provided by the Registrar, and the rules configured in the Registrar are implemented at this stage. The rule enforcement point of a service is usually embodied as an embedded proxy or network medium, such as an XML gateway.

The Registrar and runtime implementation points (such as proxies or XML gateways) in SOA governance do not exist in cloud computing. This means that cloud computing services do not have a central point for users to view all services and related policies. Although policies are implemented on the cloud side of the connection (implemented by cloud service providers), they are not implemented on the client side. Therefore, the governance of cloud computing faces important challenges.

Useless cloud

Cloud computing is similar to earlier WEB services in many ways. Developers may decide to use the new technology alone and eventually use it. The company's IT managers are not aware of this situation. Then, slowly add governance to this umbrella. At this point, many organizations have entered the early stages of governance of cloud computing. It is not uncommon for developers to play with an AMI image in a project, even if the initial prototyping requires the use of a personal Amazon account and credit card.

Client-side governance-failed to implement?

Cloud service providers often do not have to submit service downtime information to their customers in advance. In addition, cloud service providers are not responsible for notifying cloud service users when a service unexpected stop occurs. To monitor the response time and availability of cloud services, you must have a client component. Client components, such as XML gateways, monitor connections to the cloud platform. If the connection is slow, the XML gateway emits a warning, or takes remedial action, such as using its cache to respond. By using caching in this way, you can mitigate the impact of cloud service downtime.

The XML gateway on the client can also scan cloud data to see if it leaks privacy information or company sensitive data. Before you pass data to a cloud provider, you should encrypt the data or selectively encrypt part of the data. For example, an XML gateway should be able to ensure that data that is passed to the cloud provider is stripped of its identity, so that the data is not associated with the privacy information.

XML gateways, such as the Vordel XML Gateway Cloud Edition, will filter the data flow to the cloud platform and apply the policy to the cloud service access. In this way, the XML Gateway provides a channel for the client to connect to the cloud service.

Apply control to the Hybridcloud application

In part 2nd of this series, you begin to create the Hybridcloud application, which leverages Amazon Web Services. When considering cloud governance and security, you will see how Amazon Web Services validates the application and how it applies policies to it.

Amazon Key

The Hybridcloud application leverages the Amazon SQS cloud service. SQS like all Amazon Web Services (AWS), you need to use the access key ID and the associated private key. We saw Amazon keys in Hybridcloud Java™ code and hard-coded these keys into applications used in the Amazon SQS Cloud. What are these keys, let's take a look at them in detail.

What is RSA?

The letter "RSA" is the initials of "Rivest, Shamir, Adleman", and they first invented the RSA asymmetric encryption algorithm.

Readers who are familiar with the public Key Infrastructure (PKI) may think that these two keys are, in fact, common and private keys, which are asymmetric associative key pairs, just as RSA or DSA uses for digital signatures and encryption keys. The access Key ID is used as an identifier that identifies the party accessing the AWS service. It is conceptually similar to a user name and can be sent in an unencrypted request. In fact, when Amazon S3 cloud service is used for online storage, the Access Key ID forms part of the URL. If you assign an Access Key ID of "12456789" to a user, the URL used to get one of the bucket files that the user stores on the Amazon S3 will be: https://s3.amazonaws.com/123456789- Bucketname/filekey.

Bucket is a file storage container that is defined in Amazon S3. To define the space you need on the S3, you must create a bucket and give it a unique name throughout the Amazon system.

The access Key ID is completely visible in the URL, which means it is also stored in a log of the network infrastructure that S3 the Amazon to route the request to access the file. Therefore, access Key IDs can be accessed by any router or agent. It does little to authenticate because it's easy to find. In fact, it is used for identifying purposes, not for authentication.

Secret Access Key is used for authentication. However, it is not sent by the client to the AWS service. Instead, it is used to create some form of digital signature that is used to prove that you have Secret Access Key. This proof of ownership is similar to the SSL handshake protocol using encryption to prove that the client is the holder of the private key without sending the key itself. The client can use the key to indicate that the key is under its control.

For PKI public and private keys, there is a mathematical relationship between them. Data encrypted with a private key can be decrypted using the corresponding public key. This is the basis for digital signatures based on PKI. Only the holder of the key can create the signature, and anyone who can access the public key (through the X.509 certificate) can verify the signature.

The Secret Access Key in the Amazon Web Services model does not have these properties. Instead, you can view it as a secret between Amazon.com and developers who use AWS resources, such as its cloud services. You cannot share Secret access keys with others and avoid them from accessing the Amazon cloud service. Because developers need to pay for using cloud services, Secret Access Key is dangerous to fall into the hands of others, potentially incurring huge bills. If you suspect that third parties have access to Secret access key, you can create a new Secret access key online.

In your Hybridcloud application, the key is hard-coded in the application itself. However, unless you use Java obfuscation (obfuscator), an attacker may reverse engineer an application to discover the key. This is the main reason why you need to use Java obfuscation.

Hybridcloud Application Policies

In part 2nd of this series, you saw the Hybridcloud application sending X-ray data to the Amazon SQS. Because the X-ray image is a private medical data, it must be scanned at the client to see if there is privacy data. It is too late to scan the data after it reaches Amazon SQS. This is another reason to use a local gateway to connect to cloud computing resources.

Another security matter for the Hybridcloud application is to lock access to the Amazon SQS service, allowing only trusted clients to access the service. This can be achieved using the Amazon SQS policy. Define the Amazon SQS policy in JavaScript Object notation (JSON).

Let's examine some of the Amazon SQS policies that you might apply to Hybridcloud applications (for details and source code, see part 2nd of this series).

First, this strategy specifies that only developers with 1234567890 of the Amazon Web Services account can access the queue, which is owned by developers with Resource Uri/987654321/queue1 (see Listing 1).

Listing 1. View Amazon SQS Policy

{"Version": "2008-10-17", "Id": 12345678901234567890 "Statement": {"Sid": "Queue1_sendmessage", "multiplying": "Allow", " Principal ': {"AWS": "1234567890"}, "Action": "Sqs:sendmessage", "Resource": "/987654321/queue1"}

Now, take a closer look at the content of the policy. The first thing you see is version information. At that time, the only valid value for the field was 2008-10-17. Next, you can see the ID of the rule. It must be a unique identifier in Amazon Web Services. "Statement" is a practical strategy. In this strategy, you can see that Resource is the Amazon SQS queue. You are specifying that a particular "Principal" (in this case, an AWS user) can access a particular queue, and that only the specified principal can access the queue.

You can also set a policy that controls access to the SQS queue based on the date, time, and source IP address, as shown in Listing 2.

Listing 2. Setting policies to control SQS queue access

"Condition": [{"Dategreaterthan": {"Aws:currenttime": "2009-04-10t09:00:00z"} "Datelessthan": {"Aws:currenttime ': ' 2009-04-10t17:30:00z '} ' IPAddress ': {' Aws:sourceip ': [' 4.3.2.1/24 ']}}]

In this example, the policy indicates that the client can access the queue only in April 2009 10 9 o'clock in the morning to 5:30 and is limited to specific IP address segments.

You can set and remove specific access to each queue using the Addpermission and Removepermission methods.

Of course, the Amazon SQS strategy is operated by a cloud service provider. However, if you want to encrypt data that is sent to a cloud provider, or if you need to scan before sending it, the client XML gateway device is the best tool for accomplishing this task.

Now that you know how to lock in Access to the Hybridcloud application on the Amazon SQS service, you can then take a rough look at cloud security solutions from Amazon, Google, and Salesforce.

Amazon S3

The Amazon S3 (simple Storage service) is a cloud serving for online storage. It is used by Web sites as back-end storage devices, such as photo-sharing site SmugMug. Of course, it can also be used to store private company data. The data that you store on the Amazon S3 may be sensitive, depending on the context. If your data is private, use an XML gateway to encrypt it before uploading it to the Amazon SQS service. In addition, you want to track how data is accessed in the Amazon SQS. In addition to privacy issues, you want to keep track of the use of S3 because it pays. No one wants to receive a staggering amount of bills, and the bill cannot be fully audited. To do this, it is important to open the logging of the Amazon S3 service.

An easy way to turn on the Amazon S3 bucket log is to open the log record of the S3 instance using the Cloudberry Explorer application. Cloudberry Explorer provides a good GUI front end for Amazon S3. In Cloudberry Explorer, you only need to select a bucket and click the Logging button on the toolbar. Now tick the Use logging check box. Select the bucket to include the log file from the Drop-down list. In our case, this bucket is cloudberry.log. In fact, the logs are written on Amazon cloud services. Log files must be written to the same geographic bucket (that is, the US application must be written to the US log). The cost of the log file is added to the monthly bill because it uses the Amazon S3 storage space. However, the amount of log space required to audit who visited your Amazon S3 storage service is not very large, so this overhead is very small (relatively).

Google Apps

Google provides a tool called Google Secure Data Connector (SDC) that connects client-side Java applications to Google Apps cloud services. It provides an encrypted connection between the local network and Google Apps. This is primarily used to connect Google Apps applications to the local network. It is built to ensure that Google Apps is able to connect through this connection. In addition, it provides a filter that restricts which Google Apps part can access which internal system, much like a firewall rule, but it is only application-level. In addition to controlling which applications can be accessed, you can add user-level control. This allows the organization to control who can access the Google Apps service.

The Google Apps SDS identity Framework uses OAuth. For example, the host's Google Apps service can use OAuth to represent the identity of their (and their users) to local applications. There is no widespread deployment of OAuth. However, Amazon's support for OAuth could change the situation.

Force.com: protection and rigorous testing

As you can see in the 1th part of this series, Salesforce's force.com cloud service uses a programming language called Apex. Force.com requires that the Apex code residing on its cloud platform contain "guarantees" to ensure that the code runs as expected. This must account for more than 75% of the Apex class of the developer, preferably 100%. The purpose of implementing such measures is to avoid inadvertent denial of service (Denial-of-service,dos) attacks across the system. For example, you must capture infinite looping code that consumes a large amount of resources in a specialized test code. To add another protection, force.com also enforces restrictions (called rulers) to execute rules at the stack depth and string size level.

While other cloud providers do not have force.com-like test constraints, it is helpful to follow their recommendations, even if you do not use force.com as a cloud platform. In addition to preventing DoS attacks, you need to make sure that the bill that the cloud provider sends is basically in line with expectations.

Concluding

Many of the plans used to address cloud security are in place, such as the Cloud secure Alliance. Currently, the leading cloud providers are Amazon, Google and force.com. However, the cloud is not entirely trustworthy: with data management issues, the mini-advertisements Commission has been asked to investigate the risks associated with cloud computing. With the deepening understanding of cloud governance and security, it is believed that cloud governance and security products can make progress.