Cloud Hosts And The Shared Responsibility Model
With hosting services on the cloud, the shared responsibility model establishes the extent of responsibility between the customer and service provider. Awareness of the model and the type of service you as a customer are using is critical to the success of cloud deployment, maintainability of infrastructure and security.
As users of cloud infrastructure, where does that put us?
Depending on the type of service, from do-it-yourself with servers hidden away in a corner of the office, to SaaS, where you just subscribe to a service and only need to manage the data in your instance or account, the division and classification is extremely important.
A common scenario that we often see with clients from SME(Small, Medium Enterprises) are WordPress implementations with vulnerabilities and exploits introduced due to misconfiguration or outdated libraries and components. Note that this example ignores purposeful attempts not to change the state of the implementation, due to fear of customizations breaking or incompatible plugins.
Here, we can see how the user’s (business owner, IT department or vendor) lack of understanding of the product affects security. Depending on the type of content, from a simple blog, an e-commerce site or a part of a Facebook app, you might want to consider hosting on a managed host providing a SaaS service. This type of service takes away the responsibility of updating and securing the framework, OS and library updates, automatic backups and scalability among other issues.
Let’s go into greater detail about the typical experience users will have with different systems, and the typical steps necessary for proper security.
SaaS:
This covers Applications such as Wix, Siteground, Salesforce, Gmail, Facebook and many others. Users will not interact with the environment the software is running on, and often even authorization roles are predefined. There are still security concerns the user should be aware of, such as activating multi-factor authentication and choosing secure login methods. In most cases users are well secured if advice in the user’s manual is followed.
PaaS:
This covers managed database hosting, web server hosting and runtimes such as Amazon Web Services’ RDS, Elasticsearch Service, Google App Engine or Windows Azure.
The operating system, execution environment, database and servers are all managed by the provider. In this case, user responsibility would start from secure configurations within the platform. For example, defining whitelisted IP addresses for API access, or setting user groups for authorization and permissions within the platform. Similar to SaaS systems, users are well secured if advice in the user’s manual is followed.
IaaS:
This covers virtual machines, storage options, load balancers, etc. Amazon Web Services’ EC2, Digital Ocean’s Droplets or Openshift’s platform.
IaaS gives you the most control over the environment, including the operating system, storage options and hardware used. The typical IT department today or anyone who has “rolled their own” servers would be most familiar with this. While virtualization, servers, storage and networking is covered by the service provider, everything about the operation system layer is the user’s responsibility. A patch management program should be put in place by the user to ensure the operation system and the frameworks used are kept updated. A secure configuration guideline should be used to ensure the various components are safeguarded. A good place to start would be the Center of Internet Security’s benchmarks.(https://www.cisecurity.org/cis-benchmarks/) This would also include checking the various services running on the operating system and open ports, firewall configuration, logging of system access and authorisation and authentication best practices. Some examples of this includes use of password authentication for SSH (if SSH is even needed), services running as root and handling of the root account. For older implementations, security concerns would include dormant resources as well as environments that do not account for newer services and APIs.
In summary: where more control and customisation is required, more responsibility lies with the user, and thus it is important to choose the right service type.
