I'm a CIO or CSO of a corporation that has yearly revenues of $1 billion or more. What are the security concerns that I have before I'm willing to deploy my IT infrastructure into a cloud? Let's flesh out the following security issues: What belongs in the cloud? How should sensitive data be protected? How are encryption upgrades addressed? How do I limit access to sensitive data? And how will critical systems metadata (data describing data) be tracked?
See also: Cloud security: The basics
Let's assume that each corporation has a variety of firewall segments and corresponding network equipment within the cloud-computing vendor's cloud. Each segment will have a variety of applications it supports. Because other companies may be in the same cloud, they may share the same firewall segment and network components, the same database, virtualized operating system, and virtualized storage. (Related: Small clouds: Security selection criteria)
First, let's look at some realistic security constraints about the cloud vendor. It may be difficult to deploy all a corporation's infrastructure within the cloud because of a lack of standardization within the businesses' current IT applications. For example, one of the clients I worked for had a mainframe solution that was integrated with a web service. The web service interfaced with a POS (point of sale) system and communicated with the mainframe using a proprietary port over TCP/IP. The mainframe received and stored sensitive credit information. For this solution, all of the POS solution, web service, and TCP/IP communication could be put in the cloud. But, the mainframe's application, proprietary storage infrastructure, and encryption techniques make it hard to put it into the cloud. The mainframe application could be potentially ported but would likely require a difficult rewrite. It would not be wise to do this without performing a ROI (return on investment) review.
A second concern is access to sensitive data. How is sensitive data stored in the cloud? SAN (storage area network) subsystems stripe data over many drives in the storage array. Do I want to stripe encrypted data over the entire array of disks? My concern is that corruption in a database, file system, or a disk or solid state drive may spread to other applications sharing data (virtualized) within the same subsystem. So I want a method to isolate the encrypted data in the database, file system, or on disk. The bounding of data will limit the effects if corruption occurs.
Thirdly, how is the encryption algorithm for the stored data going to be updated? Encrypted data that is stored within various databases and file systems will need to be upgraded because as processor speeds increase it is easier to hack data. So this data will need to be unencrypted with the older encryption algorithm and re-encrypted with a new algorithm. Because of the newer algorithm, the newly encrypted data may take up a larger footprint in the database or file system. This also needs monitoring.
Next, I want very granular access controls to the application data within the cloud vendor. I want a LDAP (Lightweight Directory Access Protocol) directory or an Active Directory interfaces to the database, file system, and/or portion of drives that only specific individuals from the cloud client can access the data. I want one cloud-vendor directory for all cloud clients partitioned by cloud client/segment/application/user stating which individuals can access different application databases, file systems, or portion of disk or solid-state drive. This locked down access prevents unauthorized users and administrators from inappropriately accessing data.
Lastly, I'm looking for a place to keep the segment and corresponding application metadata. This is so that I can put in or extract from the cloud the segments and applications that my company owns. I recommend using LDAP directories or Active Directory to keep the cloud client's metadata. The cloud client can use this flexibility to extract and then enhance certain application(s) for competitive reasons. The cloud client could also remove the segments and applications due to a lack of satisfaction with the cloud vendor. This directory metadata hierarchy would have a Segment definition with virtual firewall, switch, router, and load-balancer metadata for a given network segment. The children of the segment parent would be the metadata for each application the segment support.
In summary, cloud computing can only outsource corporate applications and infrastructure that are using common standards. Stored sensitive data needs to use common encryption methods, protocols and have a protective boundary around an applications encrypted data. The encryption method needs to have an upgrade path for data in the database and/or file system. The sensitive data also needs a global cloud vendor LDAP directory or Active Directory driven access defined on client/system/application/user hierarchy to limit who has access to an application's data in a database, file system, or disk/solid state drive. Lastly, the directory should also contain a hierarchy of cloud computing metadata that enables easy addition or removal of applications within the cloud.
Machler is an independent IT architect/marketing consultant focused on IT and product solutions that intersect both marketing and engineering. Reach him at firstname.lastname@example.org.
This story, "Security for Large-Company Cloud Providers" was originally published by CSO.