There are a multitude of articles, videos, infographics, and probably even poems out there on the internet walking through the differences between the three main cloud service delivery models. In fact, Google kindly let me know that there are “About 11, 800,000 results” for the query “iaas saas paas”, which, in my head, reads as “Yass, sass! Pass!”
That's exactly what an excited wide receiver yells at a quarterback who just said something sassy to an opposing linebacker. If you needed a way to remember these models, you’ve got it now.
I do plan to provide some background context around the Infrastructure-as-a-Service, Platform-as-a-Service, and Software-as-a-Service delivery models for those reading who may not be familiar with those concepts, but I also intend to take a more specific look at that sassy quarterback with a focus on security.
Since these three models are often represented together in the form of a pyramid with IaaS at the base, PaaS in the middle, and SaaS at the top, and that pyramid serves a semantic purpose, this article will follow that representation, starting with the pyramid’s base: IaaS.
Infrastructure-as-a-Service (IaaS)
With the IaaS model of cloud service delivery, a vendor (e.g., Amazon) provides fundamental building blocks of compute, storage, and networking resources, and the customer, who can access those resources on-demand over the internet, pays for those resources as they use them. The cloud provider, or vendor, is primarily responsible for maintaining the underlying hardware infrastructure to support the service, and the customer has full control to spin up virtualized resources like virtual machines (VMs) with desired amounts of CPU and RAM, volumes for extended storage, databases for an application that may need to store data, load balancers to balance web traffic across a cluster of other VMs for high availability, and even firewalls for controlling and filtering out unauthorized network traffic from their environment. Creativity and money are ultimately the limiting factors in what can and cannot be built by a customer leveraging infrastructure as a service, sort of like how creativity and time left until bedtime are the limiting factors for a kid with a box of LEGOs — build what you want. To give a quick plug, I’m currently using Linode’s LEGOs — I mean IaaS — to host my portraiture portfolio website https://sketchyactivity.com. I was previously using Heroku (which is PaaS, to be discussed next), but they are introducing new costs starting in November so I wanted to move to a service with more stable pricing and a greater degree of flexibility.
Extending upon IaaS is the wonderful concept of infrastructure as code (IaC), which is documented well by Red Hat. With IaC, we take our ability to provision resources in the cloud on-demand with IaaS, and we do it automatically by writing code that hits APIs offered by the IaaS provider (using API keys to authenticate and authorize). While this might not seem too valuable if you only need to spin up one constant virtual machine for a lightweight app or service, IaC can be a major asset if the resource requirements for your app change over time. After all, elasticity is one of the fundamental benefits provided by cloud computing since being able to programmatically scale resources up or down depending on demand also means you are paying only for resources you need over any given time period. Using IaC also means you can house infrastructure configuration in version control, which comes with its own universe of benefits.
Now, IaaS certainly offers a great deal of flexibility and freedom, which really is powerful, but with that power comes with responsibility, as stated by Peter Parker’s Uncle Ben in his well-known 2002 Ted Talk.
IaaS vendors, like all cloud service providers, treat security as a shared responsibility meaning they will maintain the security of physical infrastructure up to the hypervisor (their software running virtual machines) but customers building their own infrastructure with IaaS are responsible for making that build secure as well as making the policies and governance around its management secure. This includes but is not limited to:
Frequently and regularly updating VMs — this is the easiest one, but it’s often forgotten
Following the principle of least privilege, e.g., not using a root user for daily tasks on VMs, or setting up RBAC to provide your internal team with limited access only to what they need to manage infrastructure
Requiring that anyone accessing and managing infrastructure with IaaS is using MFA to log in
Not hardcoding or storing secret values in version control, e.g., API keys for the IaaS API if using IaC; this one’s generally applicable
Disallowing root login and password authentication for SSH; use key-based authentication instead.
Setting up a firewall that allows only the traffic required to provide your service to intended audiences
Setting up monitoring and alerting about system resources to stay updated on the state of your infrastructure
Setting up a CI/CD pipeline for software being deployed on the infrastructure which includes automated testing
Setting up redundant infrastructure as well as backups for recovery in case of failure; make sure to test both to ensure you can meet your recovery time objectives (RTOs) and recovery point objectives (RPOs)
Reviewing audit logs to monitor IaaS activity
Setting up encryption — at rest or in transit, or both, depending on your needs; this may include setting up and regularly renewing your own SSL certificates, e.g., with Let’s Encrypt
Reviewing your specific compliance requirements and configuring your system to meet those
In short, IaaS is the most flexible cloud service delivery model, but it also requires the most time and attention to maintain a secure environment. IaaS may look like the cheapest option based simply on the pay-per-use costs listed by IaaS vendors, but it inherently comes with more security risks for the IaaS customer (and potentially the customer’s customers) since the customer owns such a hefty portion of the shared responsibility. Because of this, IaaS is a more appropriate fit for teams who are trained on and experienced in configuring, managing, maintaining, patching, and generally securing servers at a low level. Without that experience, the business risk likely is much more expensive than the low pay-per-use cost of some virtual machines, and a different delivery model may be a better fit, which leads us to PaaS.
Platform-as-a-Service (PaaS)
As we move up the cloud pyramid that I referred to before into the middle layer of PaaS, the space available shrinks a bit compared to the IaaS base — that’s some basic pyramid geometry for you. In the smaller space of the PaaS layer, we have less freedom but also less responsibility for security as the customer.
The purpose of PaaS is to narrow the scope of customer responsibility in such a way that it simplifies the process of developing and deploying software. In other words, the customer is given a platform on which to work around which guardrails are put in place by the vendor, and the space beyond the guardrails is the vendor’s responsibility.
The customer may, on occasion, linger at the edge of the platform, lean on a guardrail, and stare longingly into that great beyond, but the convenience of clicking a button to deploy their app will beckon them back inward.
The customer can build and deploy application resources and manage data without having to tinker with and configure underlying infrastructure which means rather than having the low-level responsibilities of keeping a server updated and locked down with attention to all the requirements previously discussed, they can put more focus on the application itself — the business logic, the improvements for end users, new features, etc. Since I’m a big fan of analogies, think of it this way: on one hand, someone is offering you — at a low price — a toolbox filled with tools that only work if you put time into consistently repairing them after using them. They work great so long as you maintain them, and you can build a ton of stuff, but if you forget to maintain them, the things you build will collapse and potentially hurt someone, which is quite risky for you especially since you’ve never had to maintain some of these tools. That’s IaaS. Now, on the other hand, someone is offering you, at a higher price, a small pouch of tools that they’ve approved for your use, with the guarantee that they will be responsible for maintaining the tools. You can’t build as much, sure, but you don’t have to spend hours maintaining your tools to make sure what you build works properly and doesn’t hurt anyone. You get to just use them. All you need to focus on is the structural integrity and security of the things you build. That’s PaaS. As a PaaS customer, you still have sort of a building-block-based approach to setting up your environment; the difference is that the building blocks presented as options tend to be a bit less granular and based more on pricing tiers like “Free”, “Production”, “Advanced”, and “Enterprise”, where the price for each tier increases significantly, as they do for Heroku. The general idea is that, as a customer, you can choose pre-configured resources for data storage and computation with varying degrees of capacity and security depending on your specific requirements (where bigger requirements = bigger price), you pay for those resources at intervals, and you use them to build and run your application(s) freely without concern for what’s underneath. Also, not only is each resource you select pre-configured, but all the resources selected are pre-integrated automatically by the platform which means you don’t (generally) need to troubleshoot communication problems between things like databases and web services. In my experience using Heroku, using PaaS simplifies collaboration with other developers, setting up CI/CD pipelines, auto-scaling based on demand, configuring dev, test, and prod environments for a given app, monitoring app activity, managing SSL, and even setting up integrations with other services. These benefits are significant but it’s worth noting that they come at the expense of your wallet and your ability as a developer to easily port your app to another platform. This is because each PaaS provider’s “building blocks” are unique to them as a provider and sometimes can even come with configuration requirements that introduce a need to modify your application code. Once you’ve started depending on a feature set offered exclusively by one vendor, moving elsewhere even in the face of increased pricing or service decline becomes less practical, which is why vendor lock-in is a common problem experienced by PaaS customers.
Now, I’ll put my security glasses back on (I lost them before but found them in my safe; that’s a security joke) and we can look at PaaS from the perspective of security requirements. We’ve established that PaaS customers have a smaller share of the shared responsibility than IaaS customers, and PaaS providers take on that extra responsibility of managing underlying infrastructure. Even with that, PaaS customers are still responsible for:
Analyzing their own compliance requirements and selecting pre-configured resources that meet those requirements (e.g., selecting an environment that runs in network isolation on dedicated resources versus one that is publicly accessible and runs on shared resources). This includes looking at encryption requirements — does the platform encrypt data at rest?
Setting up monitoring and alerting about problems with their application(s)
Configuring role-based access control within the platform (i.e., who can deploy, add new collaborators, manage application data, purchase new resources, delete existing resources, etc.)
Setting up a CI/CD integration with automated tests that must pass before new application versions are deployed by the platform
Monitoring activity of collaborators with access to the platform
Ensuring platform-related configuration variables are not stored in version control or publicly available (e.g., credentials for pre-configured databases); the same applies to any other secret values
Requiring all team members with access to the platform to use MFA to log in (assuming that’s an option)
Establishing a plan for when there is a service outage; this includes having a migration plan either to another PaaS vendor or to some other environment
Staying on top of the quality of their own software (obviously, but it felt wrong to omit this)
Configuring and renewing SSL certs via the platform if applicable
Staying on top of payment and payment-related warnings that could affect your service
Monitoring the service quality of the provider should also be considered a responsibility of the customer; even vendor lock-in mentioned previously can be considered a security threat to your business, especially if the provider significantly changes pricing models (starts robbing you because they can) or their infrastructure quality declines causing unavoidable outages.
With these requirements in mind, the PaaS model is a decent choice for teams of developers who aren’t too proficient with server management, configuration, and security patches but do want some flexibility in the development, testing, and deployment of their service.
In a nutshell, PaaS allows us to hand over a suitcase of low-level responsibilities and freedoms from our IaaS years in exchange for a pricey Gucci bag of guardrailed guarantees of infrastructure security, convenience, and refocused energy on our own applications over which we still have full control.
That brings us to SaaS.
Software-as-a-Service (SaaS)
You’ve made it to the apex of the cloud pyramid. Congratulations! Can you see your attack vectors from here? To access this final delivery model (well, final for this article; there are actually more), we had to submit our technical exploration license to a troll who guards the Bridge of SaaS.
“You have not the right to low level mods,” he said, “but these wares of soft have provisions broad.”
After recovering from the profundity of his trollish poetry and dropping the weight of more security responsibilities at his feet, we were off.
With SaaS, we (the customer) are not developing, building, or deploying a service. Rather, a vendor is delivering some application or service over the internet which we, as customers with internet connections, can access and consume on-demand. We’re talking Microsoft 365 apps like Word, OneDrive, and Teams, Google apps like Gmail, Drive, and Docs, and so on. There’s generally no need to install or maintain any software as a SaaS end user aside from a web browser, which means you are free from all complex software and hardware management. The vendor (e.g., Microsoft or Google to follow the previous examples) is accountable for most of the shared responsibility in the SaaS model. More specifically, the vendor holds most of the responsibility for security of the cloud (i.e., greasing the gears under the hood of their service), while the customer holds responsibility for security in the cloud (i.e., using the service in a secure way). That’s not to say that the SaaS vendor is fully responsible for everything from the hardware up to the software service they’re providing, though, since a SaaS vendor may (likely) use a separate PaaS or IaaS service as we’ve discussed to provide their own SaaS service. For example, if I want to launch a web app to provide a paid service for people, I would most likely use virtual infrastructure from Linode to run that service — I wouldn’t be responsible for the maintenance of the underlying hardware, but I would certainly be responsible as previously discussed for the secure and resilient configuration of my resources to protect myself and my customers.
From the customer perspective, SaaS tends to come with general benefits like easy access from anywhere via the internet, high reliability, payment flexibility (e.g., we all know Gmail is free), strong security, and generally the abstraction of the “how it works” away from the “what it provides”. When I’m accessing software over the web like Gmail, or Word, or OneDrive, I access it with the expectation that it’s just going to load, that it’s secure, that I’m not going to lose any data, etc., because I’ve placed trust in an established vendor’s guarantees of those things. Now, with SaaS, the software being provided as a service, while possibly somewhat customizable by end users (e.g., for changing styles and themes and certain settings based on personal preferences), is packaged in a way that intentionally confines users to using it as expected. End users are not tasked with developing SaaS services further before using them or making them more secure as services — that part is handled.
Ultimately, SaaS customers are purely responsible for the secure use of SaaS since that’s the full scope of their control. This generally includes largely data-, account-, and information-centric security responsibilities like:
Not exposing or sharing sensitive information with users who should not have access
Not sharing account credentials with other users and not reusing a password for the SaaS account that is used elsewhere
Enabling optional security features on the SaaS account like MFA; if an admin, enforcing an MFA requirement for all other organization users
Training other end users of the SaaS product in the organization on how to use it securely if applicable; for example, if a new product is being launched to deliver a service to a full organization (e.g., a new intranet or a CRM for a higher education institution)
If an admin, setting up role-based access control from the SaaS product’s administrative settings if applicable (for organizations), following the principle of least privilege
If an admin, setting up monitoring and alerting from the SaaS product’s administrative settings if applicable (for organizations)
If an admin, tracking information or identity compromises from the SaaS product’s administrative settings if applicable (for organizations)
Keeping up to date with notifications from the SaaS provider about changes to their product, especially if managing the product as an admin for an organization
Verifying that the SaaS product supports the organization or business’s security, policy, and legal requirements before purchasing if you’re part of decision-making about SaaS product purchases
Verifying that the SaaS product supports disaster recovery and general business continuity before purchasing if you’re part of decision-making SaaS product purchases
Specific security requirements around the use of a SaaS product will vary depending on the product itself but general information security best practices around things like password management, MFA usage, information protection, monitoring and alerting, access control, etc. are widely applicable to maintaining security when using this service model. To reiterate, SaaS is both simple and confining, and it’s not for developers hoping to launch their own service as is IaaS or PaaS, but rather it’s for end users with an internet connection and a specific goal met by a specific SaaS product.
Conclusion
To summarize this quite lengthy article, let’s take a look back at the cloud pyramid, but this time with an additional component. I guess technically this image is adding another thousand words but at this point who’s counting? I am. We’re at 3160 so far.
I was struggling to find articles online that really dove into the semantics behind the use of a pyramid to represent the relationship between each of these three service models. As a result, I started doing some thinking and realized that by drawing a box sitting over the pyramid, the visual can really emphasize the how the ratio of customer-to-vendor responsibility in the shared responsibility model of cloud security changes across each of these service models. We established that IaaS offers the most technical and creative freedom to customers, but IaaS customers also hold the most responsibility for security in comparison to the other two models. Of course, responsibilities held by the customer are consequently not held by the vendor. So, as you move upward through PaaS to SaaS, the scope of customer responsibilities around security (the space in the pyramid) decreases overall while that of the service provider (the space around the pyramid) increases.
Perhaps the most important note to end with is that cloud security, regardless of the service model — is never a one-sided responsibility.
Top comments (0)