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
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
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
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
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