Bringing the very first line-of-business project to the cloud requires a series of critical decision points, including staff and process changes.
The financial model for cloud computing seems like an irresistible option for meeting budget pressures. After consuming services, you’re billed on a monthly basis. So the cloud computing services are considered an operational expense, not a capital expense.
You can reduce overhead by consolidating resources into large shared datacenters. This creates efficiencies in staffing and power consumption. You can scale your service usage up or down as you need—no overcapacity and no lost opportunity.
Finally, there are multiple ways that broadly deployed cloud-based applications can support your business needs. You can prepare for and account for an increasingly mobile workforce, a diverse collection of business partners and a worldwide supply chain.
While the cost and collaboration benefits might be obvious, the road to the cloud is not without its potholes, many of which are hidden. You’ll have to retrain your IT staff, create new requisition and operations processes, and update data security and compliance policies. Fortunately, you can address these challenges in a systematic way. Here’s a look at the major decision points a typical organization will face in taking its first line-of-business (LOB) project to an Internet-based cloud provider.
Business managers are always looking for applications to help them run their businesses more efficiently—whether it’s for analyzing data for faster decision making or getting greater visibility into business operations. And whether those capabilities come from commercial or customized apps, the burden is on IT to deliver and operate an ever-expanding set of services under continuous budget pressure.
When a business application is completely stand-alone with no compliance or security constraints, the consideration for cloud hosting is greatly simplified to cost of deployment and operation. Most business applications will require a more careful risk-and-benefit analysis before deciding how to manage cloud hosting:
The first two considerations have common solutions for most deployments. Compliance regulations depend on the location and type of data to be handled by the app. The major compliance issues—roughly in order of decreasing complexity—are:
Some cloud service users won’t be part of a corporate directory like Microsoft Active Directory. In that case, the cloud service needs to aggregate users from different identity providers (IdPs). These will have potentially different access rules to the cloud resources.
When there are both public and private (within the enterprise) users, cloud apps will require access to access and policy data. Thus, you could conveniently deploy that data to the cloud. This type of deployment will permit access from any type of device, even if that device isn’t part of the enterprise directory.
You’ll probably end up moving old data into the new database for cloud hosting, but handling the schema mapping and data migration should be no different than any other migration. There are tools that make the identity federation process easier. However, there could also be compliance issues associated with the data in either the database or the cloud resources.
The Windows Azure Access Control (AC) Service is a convenient cloud service that can aggregate claims from an on-premises Active Directory Federation Services (ADFS) server and an external IdP provided by Windows Live, Facebook or other social networking sites. Using cloud services for identity aggregation gives you support for many programming languages and many existing IdPs.
Using AC, you can easily map claims generated by ADFS, for example, to claims customized for a given on- or off-premises application. This approach reduces application complexity and maintenance costs. AC can also mediate the relationship of on-premises users, cloud resources and users accessing the data from the Internet (see Figure 1).
Figure 1 WindowsAzure Access Control Service can mediate between on-premises and cloud resources.
Few organizations can afford the same critical mass of IT personnel, expertise and processes as the major cloud infrastructure providers. And experience has demonstrated that you can run some apps more securely in the cloud than on-premises.
However, there will be new threats introduced as a result of public Internet connections. These types of threats are introduced by network de-perimeterization, so you’ll need to address them eventually anyway. Still, new public cloud deployments should be subject to security review. You should take the following considerations into account.
Within the enterprise domain, only domain-joined computers are permitted. You can use mechanisms like Network Access Protection (NAP) and IPsec to ensure that all machines are well-known and managed against security threats. However, you can also extend these mechanisms into the cloud.
Plus, cloud-based servers are covered by service-level agreements (SLA) which you must include in a security review. You need to ensure that uptime, security, privacy and compliance certifications are satisfactorily addressed.
Here are some of the specific attack points you should cover within the scope of a security review:
These types of attacks have all been seen in prior generations of enterprise services. You can use the data flow to analyze threats introduced when a public cloud is used with on-premises services (see Figure 2). Here are the three basic types of connections you’ll have to analyze:
Figure 2 Analyze the threats to your data flow before taking action.
You might not be able to determine how auditors will classify data before an application is ready for deployment. Even worse, data classification could change, even after the app is deployed. Compliance auditors prefer to conduct a finished app audit before it’s deployed, but that can be expensive.
Instead of holding up a deployment waiting for clarity, it’s easier to institute compensating controls to avoid compliance problems. These methods can help you avoid compliance issues with cloud deployments:
When you have to release data to users on the public internet, separate the LOB app from the compliance engine that will handle all the access and audit checks for sensitive data. These data flows illustrate that architecture (see Figure 3). This might appear complex, but there are only two major concepts you need to understand regarding separation of control:
Figure 3 Any compliance checks should be handled independent of the line-of-business apps.
Now you’ll need to determine where you’ll locate the compliance access engine. You could have the compliance engine hosted in the cloud for operational efficiency, or on-premises for enhanced security. You have to protect all connections that carry sensitive data.
We’ve explored four solutions here for moving into the cloud. Each solution addresses specific application needs or vulnerabilities. Your first step is to understand what data you’ll have to expose on the public internet. If that’s sensitive data, user authentication is critical. If it isn’t, then separating data and control might avoid any compliance issues. Once you make these choices, draw out a preliminary data flow diagram and look at the attack points. Taken together, this preparation should give you the confidence you need to tackle an LOB cloud deployment.