Cloud Service Providers (CSP) offer a range of infrastructure, platforms, and software for customers to consume. Whether you are looking to move infrastructure and applications wholesale to the cloud or simply consume service offerings, cloud adoption has many benefits. While those most often touted include reduced total cost of ownership, scalability, availability, and agility; you should also consider the potential security benefits that you can get from moving to the cloud.
The shared responsibility model of cloud services breaks down into three general areas; Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), and Software-as-a-Service (SaaS). While cloud service offerings can blur the lines between these areas, they are a good starting point to understanding where provider responsibility stops and customer responsibility starts. Amazon Web Services (AWS) has a variety of IaaS, PaaS, and SaaS offerings that customers can utilize.
Amazon Elastic Compute Cloud (EC2), which includes the Virtual Private Cloud (VPC), Elastic Load Balancer (ELB), and Elastic Block Storage (EBS) services, forms a true IaaS offering. Relational Database Service (RDS), RedShift, Elastic Map Reduce (EMR), and DynamoDB are all managed database type offerings that are more like PaaS in the responsibility spectrum. AWS also has pure SaaS offerings like WorkDocs, WorkMail, Simple Email Service (SES), and Simple Workflow Service (SWF). The responsibility model for these services places almost everything in Amazon’s bucket and customer responsibility is limited to the data they are processing in those services. In addition to these clear-cut examples, Amazon also offers many services that don’t fit neatly into an “as-a-Service” bucket. Elastic BeanStalk is a sort of PaaS that gives the customer deeper control over the underlying infrastructure than a typical PaaS. Lambda could be considered a PaaS with less customer responsibility because it executes customer provided code in a fully managed container, or it could be placed in the SaaS bucket.
More simply put, a CSP is only responsible for the part of the service over which they have direct and complete control. If customer applications, actions, or configuration can influence the security of a service, then the CSP will not take responsibility for that level in the service hierarchy. In EC2, the AWS IaaS offering, everything from the hypervisor layer down is AWS’s responsibility. A customer’s poorly coded applications, misconfigured operating systems, or insecure firewall settings will not affect the hypervisor, it will only affect the customer’s virtual machines running on that hypervisor. It remains the customer’s responsibility to ensure the integrity, confidentiality, and availability of the systems, applications, and data that they host on EC2.
Regardless of where CSP offerings fall on the responsibility spectrum, using them puts less of the burden for security on the customer since CSP assumes more responsibility for ensuring the integrity, confidentiality, and availability of the systems. Services like RDS place the responsibility on AWS with regards to patching, database backups, and system availability.
Procuring a pure SaaS, like SalesForce or WordDocs, provides a customer with very little to configure, while the bulk of the security related concerns (as well as management of the cloud solution as a whole) is with the CSP. This also means that the customer must trust that the CSP’s security measures are adequate, since they cannot change them and may have little to no visibility into them.
When choosing a CSP to host company infrastructure or to build a CSP offering of your own, the shared responsibility model should be of vital concern. Whether planning to use an IaaS or PaaS to build your own SaaS offering, you should factor the security responsibility heavily into the decision. While IaaS may bring increased flexibility to architect the solution, it also means a larger share of the security workload. Companies should also consider what security certifications the CSP has and for which services these certifications are held. Certifications verified by third parties provide a level of assurance that the CSP’s systems and the underlying security measures meet the requirements set out by the certifying body, and that the CSP is following industry best practices. If you are trying to build an application on a CSP that must meet certain compliance requirements, such as health care applications or Federal Government applications, then you need to carefully consider the CSP you choose before moving towards using their services.
CSPs, such as AWS, provide companies an environment that undergoes numerous audits and has a variety of compliance certifications, ranging from PCI DSS Level 1 to ISO 27001, from HIPAA to FedRAMP. These, as well as other certifications, provide your organization assurance that the AWS offerings covered by the certification are secure and that they are doing their part to ensure the security of the systems. CSPs, like AWS, that hold a variety of certifications and conforms with numerous compliance requirements represent an ideal choice for those organizations looking to architect a secure solution in the cloud.
Our next blog posting in the series, The AWS Shared Security Model: A Path Towards FedRAMP Compliance, explores how AWS FedRAMP compliance can be leveraged to reduce the effort for CSPs to achieve FedRAMP compliance for their service offerings hosted on AWS.
