SaaS, PaaS, and IaaS: A security checklist for cloud models
Key security issues can vary depending on the cloud model you're using. Vordel CTO Mark O'Neill looks at 5 critical challenges.
By Mark O'Neill, Vordel
The end-user organization could consider a Cloud Service Broker (CSB) solution as a means to create an independent audit trail of its cloud service consumption. Once armed with his/her own records of cloud service activity the CSO can confidently address any concerns over billing or to verify employee activity. A CSB should provide reporting tools to allow organizations to actively monitor how services are being used. There are multiple reasons why an organisation may want a record of Cloud activity, which leads us to discuss the issue of Governance.
For CSOs focused on IaaS
Challenge #4: Governance: Protect yourself from rogue cloud usage and redundant Cloud providers
The classic use case for Governance in Cloud Computing is when an organization wants to prevent rogue employees from mis-using a service. For example, the organization may want to ensure that a user working in sales can only access specific leads and does not have access to other restricted areas. Another example is that an organization may wish to control how many virtual machines can be spun up by employees, and, indeed, that those same machines are spun down later when they are no longer needed. So-called "rogue" Cloud usage must also be detected, so that an employee setting up their own accounts for using a Cloud service is detected and brought under an appropriate governance umbrella.
Whilst Cloud Service providers offer varying degrees of cloud service monitoring, an organization should consider implementing its own Cloud service governance framework. The need for this independent control is of particular benefit when an organization is using multiple SaaS providers, i.e. HR services, ERP and CRM systems. However, in such a scenario the CSO and Chief Technology Officer (CTO) also need to be aware that different Cloud Providers have different methods of accessing information. They also have different security models on top of that.
Some use REST, some use SOAP and so on. For security, some use certificates, some use API keys, which we'll examine in the next section. Some simply use basic HTTP authentication. The problem that needs to be solved is that these cloud service providers all present themselves very differently. So, in order to use multiple Cloud Providers, organizations have to overcome the fact they are all different at a technical level.
Again, that points to the solution provided by a Cloud Broker, which brokers the different connections and essentially smoothes over the differences between them. This means organizations can use various services together. In situations where there is something relatively commoditized like storage as a service, they can be used interchangeably. This solves the issue of what to do if a Cloud Provider becomes unreliable or goes down and means the organization can spread the usage across different providers. In fact, organizations should not have to get into the technical weeds of being able to understand or mitigate between different interfaces. They should be able to move up a level where they are using the Cloud for the benefits of saving money.
For CSOs focused on SaaS, PaaS and IaaS
Challenge #5: Protect your API Keys
Many Cloud services are accessed using simple REST Web Services interfaces. These are commonly called "APIs", since they are similar in concept to the more heavyweight C++ or Java APIs used by programmers, though they are much easier to leverage from a Web page or from a mobile phone, hence their increasing ubiquity. "API Keys" are used to access these services. These are similar in some ways to passwords. They allow organizations to access the Cloud Provider. For example, if an organization is using a SaaS offering, it will often be provided with an API Keys. The protection of these keys is very important.
More Salted Hash with Bill Brenner