Availability zones in a region are independent data centers that protect the customer from data center failures. Larger CSPs like AWS, Azure, and Google define regions. Within a region, latency is low. However, a major disaster could impact all the data centers in a region and eliminate all availability zones in that region. A customer can set up their plan to include redundancy across a single region using multiple availability zones, or redundancy across multiple regions to provide the greatest possible availability of your necessary technology, processes, and data.
One drawback of multiregion plans is that the cost grows quickly. For this reason, many organizations only put their most critical data—the core systems that they cannot operate the business without—across two or more regions, but less critical processes and data may be stored in a single region. Functions and data that are on-premise may also utilize cloud backups. But they may not be up and running as quickly as the cloud-based solutions. The business keeps operating, although not all business processes may be enabled.
DRPs rely heavily on data backups. A DRP is about returning to normal operations. And returning the data to the on-premise environment is part of that. After the on-premise infrastructure has been rebuilt, reconfigured, or restored, the data must be returned.
One failure of many DRPs is the lack of an offsite backup or the ability to quickly access that data backup. In the cloud, a data backup exists in the locations (regions or availability zones) you specify and is available from anywhere network access is available. A cloud-based backup works only if you have network access and sufficient bandwidth to access that data. That must be part of the DRP, along with an offsite data backup. A physical, local backup can also be beneficial. Not every disaster destroys the workplace.
Cost-Benefit Analysis
Cloud computing is not always the correct solution. Which is the correct solution is a business decision guided by a cost-benefit analysis. Cloud computing benefits include reduced capital costs as the individual customers no longer have to buy the hardware and system software that the CSP provides. The lowered capital expenses are offset by higher operating costs, as the customers must pay for the services used.
In many countries, capital expenses and operational expenses are treated very differently for tax purposes. For example, capital expenses may be written off or depreciated over a number of years. To write off the entire business of expenses of new infrastructure, purchased and installed on-premise could take many years. Operational expenses, such as the cost of cloud computing, can usually be written off as a business expense in the year the expense is incurred.
The business must understand the cost and tax implications of moving to the cloud or investing in on-premise infrastructure to make the choice most beneficial to the business. A move to the cloud may be as much (or more) for financial reasons than technical ones. This move should be considered only if the benefits justify the cost or if the benefits lower the costs.
Functional Security Requirements
Functional security requirements can make the move to cloud computing or the governance of cloud computing safer for a customer's information and processes. However, there remains some challenges with cloud computing, including portability, interoperability, and vendor lock-in.
These challenges can be lessened through the use of a vendor management process to ensure standard capabilities, clearly identifying the responsibilities or each party and the development of SLAs as appropriate. For complex or expensive systems, the RFP process can be utilized to clearly state customer requirements. The security requirements should be part of the requirements specified in the RFP and can be part of the process of choosing a vendor. A vendor that cannot meet the customer's security needs can be eliminated early on.
Portability
One-time movement is when a customer moves to a cloud platform, with no intention of moving it again. This is not common. In a modern environment, movement to and from the cloud as well as between cloud services and CSPs is much more common. These movements are not simply a forklift operation where you pick up some on-premises solution and data and drop it into a cloud account. Each CSP uses different tools and templates. So, a move from one CSP to another requires mapping to the other with the associated data cleanup. Moving from your own infrastructure to a CSP has the same challenge.
Frequent movement between CSPs and between a CSP and your own infrastructure is significantly more difficult, and data can be lost or modified in the process, violating availability and integrity rules. Portability means that the movement between environments is possible. Portable movement will move services and data seamlessly and may be automated.
The movement of data between software products is not a new issue. It can be complicated in the cloud by the need to continue paying for the old service while porting to the new one. This puts time pressure on the porting.
Interoperability
With customers using a variety of cloud services, often from different vendors, interoperability is an important consideration. In addition, some situations may require a private cloud sharing data with an on-premises solution. The ability to share data between tools and cloud environments and between clouds and corporate infrastructure is important. One issue is that the security tools and control sets differ between CSPs. A gap in security may result. Careful planning is essential, and the services of a cloud broker may also be warranted.
One way to improve the situation is through application programming interfaces (APIs). If properly designed, the API can bridge the security gap between services and allow the sharing of data and processes across multiple platforms. For example, if a SaaS tool is used to build a data inventory and supports the corporate data/system classification scheme, an API could be built to securely share that information with the governance, risk management, and compliance (GRC) or system inventory tool. This creates a single source for data, sharing it with relevant systems, and removes the potential of multiple data classification in different systems.
Vendor Lock-in
Solving the interoperability and portability challenges will go a long way toward ending vendor lock-in. This occurs when a customer is tied to a specific CSP and moving would incur significant costs including financial, technical, and legal. Vendor lock-in remains a significant concern with cloud computing. Continued advances in virtualization, improvements in portability and interoperability, and a careful design within a reference architecture have decreased this issue.
An additional concern is the use of CSP-specific services. If these are used to build capabilities, moving to a new CSP also impacts this additional capability. This is similar to using nonstandard features of a compiler in the development process. It locks you into that development environment.
One example is the use of AWS CloudTrail. CloudTrail allows auditing of your AWS account in support of governance, risk management, and compliance. If the decision is made to move away from AWS, the GRC functionality will have to be rebuilt with new services, either with the new CSP or with another vendor.
With additional improvements and careful architecture, vendor lock-in should become an issue in the past. Until then, the security challenges of cloud computing in general, and portability and interoperability in particular, remain.
Security Considerations for Different Cloud Categories
In a cloud environment, security responsibilities are shared between the service provider and the customer. In the SaaS model, the customer has the least responsibility, and in the IaaS model, the customer has the most responsibility. In a PaaS, the responsibility is shared more equally.
The