Having a PaaS can yield huge advantages in terms of developer productivity and time to get an application up and running. At the same time it introduce several new security considerations that you should be aware of.
A generic PaaS
If you look at WSO2 PrivatePaaS for example, it’s a generic platform that support pretty much any type of application. Multiple databases (MySQL, Oracle, DB2, PostgreSQL etc…), multiple type of applications Java, PHP, Ruby etc… You can get the full picture of what type of technologies are supported through the above page. This gives immense flexibility from the platform point of view. Also it plays an important role interms of platform maturity.
A generic PaaS which support pretty much anything is a nightmare when it comes to having proper security rules in place. If there’s a standard that says any application using corporate data should talk to existing corp databases on Oracle, then the PaaS should be able to accomodate that. So you should be able to restrict databases exposed to application developers as well. Although there’s a generic PaaS installed it should be able to restrict based on what’s required.
Security spans across what’s provided from the platform to infrasturture level security as well as internal policies.
Infrastructure level security
A PaaS is most frequently stood up on top of an IaaS. This allows the platform to take advantage of cloudiness provided by the infrastructure.
If you’re exposing all middleware services that the platfrom provide for public use, then you don’t need to worry about having any rules at the infrastructure level. Otherwise you need to be concerned about which servers are given access. These requirements change based on the business requirements. Let’s consider a generic deployment diagram first. This outlines the servers that’s there in the solution.
In the above diagram, arrows represent data flows that’s possible between server instances. Users can get to all the applications deployed on the Application Server through a load balancer. From the Application Server node, you can access Data Services, ESB or the Business Workflow servers. You can access the database only through Data Services. There are firewall rules applied at the infrastructure level to restrict access.
Why do you need this?
This encourage adherance to certain service usage patterns. It might look inflexible and to some extent an annoyance. However, for the long run it’s going to encourage best practices. For applications requiring high performance, having to go to the database through another data services layer seems inherently restrictive and bad. From my personal experience this has not been the case. You always have the option of enabling response caching that yield some performance gain. If there’s a really specialized application with special performance requirements then most probably that will be deployed in it’s own set of machines. This you might have read as the “Private Jet mode for tenants”
Retain development time flexibility
The above firewall rules are applied at runtime for end user interactions. How does this translate to a developer developing these applications/data services/integrations? Does it limit or restrict the ability to access these servers because of firewall rules? Does it create more headaches? No!
Worker/Manager clustering to the rescue
WSO2 platform supports a worker manager clusting setup. There are management nodes that’s used to deploy artifacts and there’s worker nodes that serve runtime requests. Let’s look at a diagram,
When you’re deploying, you would interact with the manager node and deploy your artifacts. Manager node will then take the responisibility of announcing to all worker nodes that there’s a new artifact and they’ll all have that within a few seconds. Usually at the deployment time you configure it to route runtime requests only to the worker nodes. So manager node doesn’t serve live traffic. That’s a load balancer configuration. Getting all worker nodes updated with the latest artifacts are done via what we call the deployment synchronizer. If you so choose you can make manager node act as a worker too so it’ll also participate in serving live traffic. Most real world production deployments however tend to keep the manager nodes out of serving live traffic.
In a multi tenant environment, this gives the flexibility of putting certain applications or tenants to their own cluster of machines. Let’s look a bit more complex deployment diagram,
In the above deployment there’s a load balancer per cluster. Also there’s a top level load balancer that forward requests to the correct downstream load balancer. There’s an Application Server cluster. Also there’s a separate Application Server cluster hosting tenant example.com’s applications. PaaS gives you a shared architecture where all tenants’ data are shared across the cluster. If there’s a security requirement that particular tenant’s data should be isolated and be hosted on it’s own set of machines, this gives a cleaner way of doing that. However, it’s still tied into the same platform and services. So even though there are a separate set of machines governing certain applications and data they’re still able to get users/roles/authorization/authentication from the underlying platform. It’s still the same platform, on a private deployment space.
Runtime application security
The next important aspect to PaaS security is isolating data and code at runtime. WSO2 platform is a multi tenant PaaS that has proper isolation between data and runtime code. Even though each tenant is sharing the same JVM and same database instance, each tenant’s data is isolated from the other. One tenant’s users cannot share data between another tenant. You can write an explicit service that deliberately share certain portion of data to other tenants but there are runtime checks in place where it’s not possible to accidentally expose data.
At runtime, Java Security Manager is enabled that prevent access to priviledged operations. File system access, and priviledged methods.
Choice of technology
Even though the PaaS is generic, most organizations want to restrict the type of applications that they allow developers to develop. Also the libraries that can be used within the applications. As a developer, using maven you have the flexibility and freedom of using pretty much any library that’s available. However, this create security issues. These 3rd party libraries might not be thouroughly tested for security vulnerabilities. This can create issues with data loss and security breaches. Usually there should be a library nboarding process before developers are allowed to use a certain library.
Sometimes it helps to reduce choice available to one or two application types and whatever the standard database for applications. There are many things you can do to make new developer onboarding process easier on the new PaaS. Rather than presenting developers with a variety of choices, it helps to give what’s necessary for them and introducing new application types, data bases and other platform services and then rollout new ones as their experience grow. From a security perspective this is important as you can enable different application types when you have a formal process of auditing and reviewing in place.