SaaS, PaaS, and IaaS Roles and Responsibilities

Introduction

Whether your company employs SaaS, PaaS, or IaaS applications depends on flexibility requirements and cost. But once deployed, applications on all three platform types must be managed, which starts with understanding roles and responsibilities. Failure to manage your cloud systems properly can lead to all manner of problems from an outage with no plan on how to diagnose and fix, data breaches, data loss, and even complete loss of control over your own account.

Overview of SaaS, PaaS, and IaaS

Many small businesses are only end-users when it comes to applications hosted and delivered over the Internet (known as "cloud apps"). That is, they sign up for customer-facing apps—such as Google Workspace or Microsoft 365 business services for email and online file storage—and don't need to do much else other than pay the bill and use the applications. The application functionality, performance, updates, patches, underlying program code, underlying storage, network connectivity between components, server hardware resources to run it, and resilience are all the responsibility of the cloud service provider. If any of this doesn't work, you can gripe at the company and demand service credits. This is referred to as Software-as-a-Service (SaaS), because from your point-of-view as a customer, you're paying the service provider to simply make the software work.

SaaS includes any application where you can just browse to the website or download a mobile app, create an account, pay (if it's not free), and start using the services to do things technology users want to do. It includes Constant Contact, YouTube, DocuSign, Slack, QuickBooks Online, Salesforce, iCloud, Google Maps, Uber, and TikTok.

But a number of businesses, some with as few as a dozen employees, may use custom-developed software and databases hosted in the cloud. They'll hire an individual developer, or a small firm, to create and maintain the application, which can also include setting up the selected platform for hosting the application. Companies will do this for various reasons. Here are some basic examples:

  • Billing and customer relations for a company in a niche industry where the conventional, popular SaaS application such as QuickBooks doesn't meet the company's needs.
  • A system to store and manage sales and marketing data that requires a custom structured database, also offering algorithms created for trend analysis and projections for decision support.
  • A system that entertainment providers might subscribe to which collects usage metrics from visitors/users across multiple websites or apps, as well as solicits feedback, to suggest what content to present to the users, or advertisements to show to maximize views and revenue.

Application management gets more complicated when the company's cloud-hosted application is the company's product, as opposed to being used only internally by employees. That is, your customers visit your website or download your app, log in to use the application, and store and process their own information on your systems, or maybe simply to place orders for your products. Instead of creating login accounts manually in a controlled fashion as is done with each new employee, depending on the scale of the application, typically the system will allow any and all visitors to create and manage their login accounts. When your company offers such a site or app, your risk management plan must consider the potential costs of a breach of customer-owned data from your systems, as opposed to only your company internal data if you had no such customer-facing app. Which is worse depends on the nature of your business and the data, of course.

If you've invested in such applications, your customers and employee users will see it as a SaaS system as described above. But for managing the application, you should understand the two levels of service hierarchy that may be in play: Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS).

Platform-as-a-Service (PaaS) is where a cloud provider has built a system—a platform—that can support your custom-developed applications, without your having to configure the underlying servers or networking. Examples include:

  • Systems that allow you to create structured databases via the provider's website, and for back-end website software to send queries behind the scenes to save data, retrieve it, and run analysis functions. Examples range from the accessible and easy-to-use QuickBase to more professional systems such as Microsoft Azure SQL Database and Amazon Relational Database Service (RDS). The servers and storage behind these are all managed by the provider.
  • General file storage for your application software to save and retrieve unstructured files (documents) using conventional program code as if it were running on a regular computer. The data is stored in the provider's system, and all the details are managed by the provider.
  • Managed emulated Microsoft Windows Server instances that can run applications written to run on the Windows Server operating system, without the developer having to install Windows Server on a virtual machine. The provider manages the hardware resources, performance, and underlying software.
  • Google App Engine, Microsoft Azure Functions, and AWS Amplify or Lambda, which offer a broad set of functions for developers to write program code that can utilize user login (authentication) services, file storage, structured databases, subroutines, and query languages for complex analysis. The developer only needs to define user account requirements, set up the data structure, and write the basic application program logic; the provider is responsible for the performance and functionality of all of the back-end work of executing the complex queries and storing and retrieving the data.

Most custom-developed apps will use a PaaS model, as it generally offers the best balance of flexibility, costs, and time required for your developer to create a working application. As far as flexibility, there is some back-end configurability available depending on the provider. For example, you can specify that copies of your database are stored in multiple physical regions. With this, at a higher price, you can enable your application and data to be reachable if there is a region-wide outage that would otherwise have taken it offline.

Configuration and coding on a PaaS system is typically all done within a web browser, or for better performance, using a development environment application installed on a workstation that connects to the PaaS system, which may either be graphical or use a command line. From the end-users' point-of-view, your completed applications running on your PaaS system ideally appears as a user-friendly SaaS application.

Infrastructure-as-a-Service (IaaS) is necessary when a developer needs detailed control over all aspects of a cloud-hosted IT system. The customer gets access to remote physical computers and storage in the service, and on them can create anything from a handful of virtual servers to an entire virtual datacenter. Reasons for choosing to build this virtual infrastructure include:

  • You might have to scale up or down tremendously depending on customer demand for your application, and PaaS services that might otherwise work for you can't support this, or the pricing model to support this on PaaS is not acceptable.
  • You are willing to spend enough for high performance not available in a PaaS model.
  • You have very high security requirements and you need total control on the location of resources, which PaaS cannot offer.
  • You are running very old software, written for on-premises servers, which cannot run on modern versions of the operating systems which would be provided by current PaaS offerings.
  • You think you can control costs better by allocating minimal resources and monitoring carefully with custom-built monitoring tools.

With IaaS, the developer must create each virtual server, allocate a share of processor power and memory, allocate storage, install the operating system, and then install the software such as the database engine, code libraries, performance monitoring agents, etc. The developer must manage updates, patches, and diagnostics of the virtual servers. The IaaS provider is responsible only for the managing the physical hardware that you allocate, and replacing it if it fails. Examples of this are AWS EC2, and Microsoft Azure IaaS (formerly called Compute service).

In a typical business application, there are different tiers of security for the data, as well as who can run what code. Some segmentation is available in a PaaS system, depending on the provider, configurable through a set of commands to the PaaS system. With IaaS, if segmentation is needed, the developer must specify each virtual network switch, router, and firewall, manually configuring IP addressing, access control lists, and routing. In addition, redundancy, failover detection and execution, failback, and load balancing must all be manually configured.

An IaaS/PaaS hybrid environment is possible, of course. A developer might have a virtual Windows Server he installed himself in an IaaS system, but an application running on that server accesses a managed PaaS database system through simple text queries, where the back-end processing is handled opaquely by the PaaS provider.

Here's one way to sum up the difference between PaaS and IaaS: You won't see a developer or user on a purely PaaS system log in to a Windows computer hosted in the PaaS system. Applications hosted on PaaS systems are accessed by the user through a web browser, mobile app, or less often through locally installed software on a computer workstation, which would all communicate on the back end with the resources in the platform, over the Internet. The front end of an application running on an IaaS platform may appear exactly the same as a PaaS system to a user, as the user will not see the back end of the platform. However, with IaaS you may see developers and administrators, and maybe even users, log in to the virtual desktop computers (Windows or Linux, etc.) running on the IaaS platform by using Remote Desktop or PuTTY over the Internet, the same as you might with your own computers in the office. From there, administrators can manage the virtual computer or other computers in the same virtual network using the same administration consoles and other tools you typically find on Windows or Linux. Or users might run their applications installed on the remote virtual computer, without having to install it on their own computer or device.

Roles and Responsibilities

As explained in the companion article from J.D. Fox Micro, Cloud Providers and the Safety of Your Data, you are always ultimately responsible for your and your customers' data, regardless of what cloud services model is in use, but not directly for every aspect of its protection. This article will cover responsibilities for these various aspects, which include backups, encryption at rest, encryption in transit, access control, and egress monitoring, in each model. It will then give the same treatment to management of resilience, load balancing, scaling, performance monitoring, and network security. Here is how this can be handled in the various models.

Data Backups

A SaaS provider may or may not backup the data you save through their app. Typically the only way to find out is to ask. If they do backup, you should not rely entirely on it. The main reason is there is probably no way for you to monitor that it's being done. What happens if your data is deleted, and then the SaaS provider says their backup didn't work, and their terms of service specify they don't owe you anything for the failure? Some SaaS providers say they keep backups, but would only use it to restore their entire system after a major failure, meaning they won't recover data from their backup in response to your request. Also, they may or may not even tell you how often they take backups, and how long they retain older backups. This would matter if you were to discover one day that you deleted a file by accident several weeks before.

You can expect any PaaS provider of database or file solutions to offer a range of backup solutions. With IaaS, however, all backup activity must be manually configured and managed, including where the backup storage is and how that is secured. As mentioned, though, a developer using an IaaS could utilize PaaS storage to simplify allocation and management of the backup storage itself, assuming the PaaS system provides the flexibility, security, and control that led to use of the IaaS system in the first place.

Encryption at Rest

Encryption at rest applies when data is stored physically to the hard drives of the cloud service provider. It's important for protecting your data in the event an unauthorized user gains access to the files; if they're encrypted where they're saved, the thief will not be able to see the information. With SaaS, any encryption in the storage is completely opaque to the user. The security of this encryption, though, depends on how well the service provider protects its encryption keys, which can be used to unencrypt and therefore see all the data. If a number of employees of the service provider have access to the keys without proper oversight, or the keys are leaked, then the back-end encryption is nearly useless. To better control encryption at rest in a SaaS system, a user could use local software and encryption keys only known to the user to encrypt the file before uploading. This is not a common practice, however. Having users manage their own encryption adds administrative burdens as well as risk of losing data when users lose their own keys.

Any built-in back-end encryption offered by a PaaS provider is the same. A software developer managing a database in a PaaS system could more easily integrate its own encryption for data placed in records in the database. That way no one controlling or breaching the PaaS system could read the data. Managing the keys, however, would present some administrative difficulty, as they would need to be available to the program code (increasing risk of breach), or somehow secured with each user's credentials (increasing complexity). And lost encryption keys in a self-managed system could mean all data is irretrievable should a system fault occur requiring restoring to a new system from backup.

For IaaS, of course, any and all back-end encryption is entirely on the developer to manage, with the same challenges a PaaS developer would face as described above.

In all cases of encryption, understanding who is responsible is critical to developing a suitable information security policy.

Encryption in Transit

Encrypting data while it's being transferred over the Internet is easier to manage, as the encryption keys need only be temporary and thus can be changed regularly. This is why encryption in transit is nearly universal. With SaaS, it will always be in place, and it is very easy to deploy with a PaaS system. However, with IaaS, it is quite common for software developers not to be familiar with the most common system used for encryption in transit (PKI), which, while not overly complicated, is befuddling to someone without experience. Therefore we often see systems on IaaS platforms transmitting data in the clear, which is unacceptable in today's IT world.

Access control

Access control refers to user account authentication (someone typing in his login name and password to identify himself) and authorization (a designation of what data that user is allowed to see or change). In a SaaS system, the company administrator, or the users themselves, create login accounts using the SaaS application's regular interface. The company administrator would then assign any elevated permissions a user might need.

In a custom application running on a PaaS or IaaS system, the developer manages how the various accounts are created, whether for a fellow developer to modify the database schema and upload program code, or for the users to log in and use the application to save or retrieve company data.

PaaS systems often offer user account management and authentication functions as a feature, so the PaaS developer simply has to call into the function and everything is handled. The developer can even provide a SaaS-like front-end for users to create their accounts. IaaS developers can do the same thing, but would likely use a third-party system, such as Google Identity Platform (which a PaaS developer also could use).

We often see, however, developers who don't know how to use these services, and who create user accounts for access to the application data using a quick-and-dirty method. They build simple tables with user names and passwords, all unencrypted, with no modern secondary authentication methods, and with inadequate methods of designating what they're authorized to see. So while you as a company manager might be aware that your developers are handling the user accounts, you still need to recognize that they are responsible for implementing them in a manner that fits your company's information security and risk management programs.

This doesn't only apply to documents or the records in your databases. All platform types will have some sort of administration console where all aspects of the system can be viewed or changed. It is of critical important to restrict admin console access only to trusted, authorized, and competent users, who are read on to administration procedures designed to prevent catastrophic mistakes. Only the end user customer is responsible for this on any cloud platform, whether it's SaaS, PaaS, or IaaS. If your developer set up the platform and you have taken no control over this, your developer has complete control over the system. It's certainly possible, and recommended, for you to assign a trusted executive or third party to have the supervisory administrative role over the platform, and to reduce your developer to only the access he needs to manage and maintain the application he wrote for you.

There is then also the fact that users can, through SaaS functions, share company files with others in or outside the company, such as, for example, by sharing from Google Drive or sending an invitation from Microsoft OneDrive. It is entirely on the company to manage and control this, either by configuring restrictions in the SaaS application's administration console, or through information security policies when technical controls may not be adequate. In a PaaS or IaaS platform, the responsibility to control sharing is still on the company, although the developer will have the ability to apply finer technical controls to match the company's intent.

Egress Monitoring

Egress monitoring is a function where massive or otherwise unusual copying of data from a company application is detected and blocked to prevent third-party data theft or insider intrigue. SaaS systems, such as Microsoft 365, can come with quite elaborate and powerful monitoring and alerting systems. Others, such as Dropbox, have virtually none. Third-party cloud applications exist that can position themselves between your company's users and your SaaS applications to perform this egress monitoring. Whatever is used, it's the responsibility of the company to implement any egress monitoring that may be required as part of its information security plan.

With PaaS, you may find some tools built-in to the platform to send alerts due to unusual activity (such as all rows of a database being read by one user when normal application usage never does this). And, as you might expect, with IaaS, the only such monitoring and alerts available would be what the developer installed and configured into the virtual servers.

Resilience

Resilience is the ability of a system to continue running despite failure of servers, power outage at a data center, or communications interruptions.

With SaaS, users will typically not have any options to enhance whatever resilience the SaaS provider chooses to invest in.

With PaaS, the same concept applies to underlying hardware and software, but developers can take advantage of features, such as redundant copies of database tables to different physical locations, to improve resilience where required uptime justifies the additional expense.

With IaaS, all resilience must be manually configured. For servers that run program code, multiple servers can be allocated and programmed to monitor each other and take over in case of failure. For data storage, multiple copies can be written so that if one storage system fails or becomes corrupt, the other copy can take over. The developer using an IaaS system must put in the work to balance performance, cost, and resilience to meet requirements, allocating additional hardware resources from the IaaS provider as required. Mature IaaS systems offer services for monitoring that can automatically allocate resources according to parameters set by the developer.

Load Balancing and Scaling

Load balancing and scaling refer to the ability of applications to continue their usual level of responsiveness and performance despite usage spikes, without over-allocating server hardware in times where not needed. As far as SaaS/PaaS/IaaS, responsibility for this is similar to resilience.

Performance Monitoring

Performance monitoring is an enormously broad and complicated topic with regards to cloud applications, and it can apply to the whole system or any particular aspect of it. So comments in this article will be brief.

Performance monitoring in SaaS systems, of course, is entirely the responsibility of the service provider. You can find status pages on any large service provider's website indicating any detected problems and their plans for fixing them.

For PaaS, it is a shared responsibility. The underlying hardware, networking systems, and software components that make up the platform are on the service provider to monitor, while the developer must understand how to configure his own database resources and write efficient code and queries so as to meet performance requirements. In cases where the system is underperforming and investigation is required, the work should start with the developer, who may be able to get assistance from the service provider's technicians, depending on what level of support is offered in this regard.

With IaaS, performance monitoring is even more involved and tightly connected between the service provider's hardware and the configuration of the virtual machines, the operating systems on the virtual machines, the application software, and network communications. On systems with heavy loads that require close monitoring, an experience IT systems manager is highly recommended.

Network Security

Network security is likewise a broad and complicated matter. With most SaaS applications, all a user or company may typically configure, if anything, is to block access to the account based on IP address or location of the user. With PaaS and IaaS, usually all aspects can be managed by the developer or system manager, such as virtual port-based firewalls, application gateways, network segmentation, and virtual private networks. The primary purpose of network security is to present a first layer of defense from any kind of harmful connection attempts, which can range from attempting to swipe exposed data, to causing systems to shut down, to installing malware for longer-term infiltration and data theft or destruction.

Epilogue

Understanding roles and responsibilities is only a start, because as you see, the number of aspects of your SaaS, PaaS, and/or IaaS platforms that require management and attention isn't trivial, and each one holds its special administrative challenges given the various types of personnel involved.

If you use any kind of cloud applications for your business (and you most certainly do), contact J.D. Fox Micro for assistance.