In the age of Cloud computing one of the most important challenges is how to keep security while moving your enterprise apps in the Cloud.
In this article I’m going to explain what challenges you might experience if you are blindly follow all hypes from the tech industry.
Today enterprises are under tremendous pressure to lower down IT costs that are coming from:
- maintain existing infrastructure (Data Centers, servers, network, storage)
- lower down costs for upgrading installed on-premises software (OS, databases, apps…)
- moving forward faster by implementing new technologies as they become available (AI & Machine Learning, 4th generation of Big Data…)
While trying to achieve all mentioned goals, enterprises are forced to move some load into the Cloud, where SaaS (Software as a Service) might, on the first sight, come to rescue.
You can take a look at two wonderful articles what enterprises need to consider before moving some load into the Cloud:
https://www.zdnet.com/article/gdpr-an-executive-guide-to-what-you-need-to-know/
and
https://www.infoworld.com/article/3226386/what-is-saas-software-as-a-service-defined.html
On the other side, year after year, we also get new, more restrictive security regulations, especially when handling customers private data that are regulated under the GDPR (General Data Protection Regulation).
If you just take a look at GDPR related fines, you should take security seriously, as total fine can be measured in percentage of total annual income.
Here are just a few examples that have happened very recently:
https://www.cnet.com/news/facebook-will-reportedly-be-fined-a-record-5-billion-over-privacy-mishaps/
https://www.cnet.com/news/british-airways-faces-record-breaking-230m-gdpr-fine-for-2018-data-breach/
Analyzing major SaaS vendor side data breaches, pattern is almost always the same, and can be grouped by following cases:
- vendor side data breach
- SaaS application misconfiguration
- SaaS software bugs
- Bug in patching script
- SaaS SW upgrade script
- contract insider/vendor insider (remember Snowden)
Vendor side data breach
As you can observe, majority of risks when implementing SaaS solution is coming from the vendor side as it has a full control, and we can read about new data breaches on daily basis, where not only small local companies have been affected so far, but also large ones from the Global Fortune 500 list.
Here you can find some of vendor side data breaches them, where many famous names from the Global Fortune list have been affected:
or example where, through the vendor data breach, even FSB (Russian counterpart of American NSA) was hacked
https://www.zdnet.com/article/hackers-breach-fsb-contractor-expose-tor-deanonymization-project/
In such cases, where data breach comes from the vendor side, all common security available by all Cloud providers like encrypting Cloud storage, network encryption etc. are completely useless.
Depending of kind of breach (if hacker will have access to the Cloud Console, which is usually protected by 2 factor authentication + fix IP address on firewall side), there are many other ways to get access (e.g. by getting access to account key, accessing Cloud terminal console, client libraries and many other ways).
In such cases, you as a SaaS application user are completely helpless, as you only have access to the SaaS application (no ssh access, no control of Cloud infrastructure, you are not able to perform forensics, security audit etc.) and/or REST API access, as only SaaS provider have Cloud root account access and complete control over Cloud infrastructure where your application is running.
The only think you can do is to open a ticket to your SaaS vendor and to report to regulatory agency and tell them about data breach when you find out.
Contract damage coverage issue
Usually SaaS contracts are relatively small and penalty paid by them (in case of data breach) can cover just a tiny part of total damage that can be measured in percentage of yearly income of the customer, not to mention reputation loss and customers lost to competition.
SaaS vendor company size
For any kind of issue you might have, with small SaaS vendors you are usually dealing with several vendors in chain (e.g. your System Integrator, SaaS vendor, Cloud platform provider like AWS/Azure/GCP etc.) which may slow down issues resolution you will have, as vendors first need to troubleshoot among them to check on which layer is the problem and who is responsible for solving it.
Large SaaS vendors are exception as they are having their own Data Center, thus you are going to deal with only one vendor.
With enterprise SaaS vendors you can be sure that penetration testing, security audits, controls and check procedure have to be on a much higher level as larger vendors can afford it, where smaller vendors want to spare some money on that.
Internal vendor architecture
All SaaS vendors will show you GDPR compliance paper suggesting that you are completely secured.
Besides that, all SaaS vendors will tell how they care about security claiming to have data encryption and network encryption in place, which are, by the way, not features of your SaaS vendor, but Cloud vendor like AWS/Azure…
Unfortunately this is what distinguishes marketing from reality, and the worse thing you can do is to accept such false illusion of security.
Later on this article you can find out that with SaaS you have the least amount of control of your SaaS SW along with data stored in the SaaS app.
For that reason industry is moving fast to create alternative approach that can take the best of both worlds: SaaS and IaaS, when speaking about a Cloud.
Majority of SaaS vendors are using Open Source technology (which is great thing), but in most cases in their community edition (this is something that majority of vendors won’t tell you).
As all Open Source projects have at least one commercial company behind which, in addition to providing support & bug fixes, also develop new features, in particular security related one.
Why internal SaaS architecture is so important?
Let’s assume that SaaS vendor is using Open Source Community version of Kafka/MongoDb/ElasticSearch/PostgreSQL or MySql stack for storing and processing your data (among them your sensitive, GDPR related data).
In such cases all of your sensitive data will be processed and stored in the Public Cloud in a plain text – JSON format that anyone with access to a file system can read without decryption.
It also means that in all cases when data breach comes from the vendor side, attacker won’t have much trouble to fetch all sensitive data that are stored there despite, as mentioned earlier, Cloud data on rest and network encryption.
Partial solution is to use commercial versions of Open Source projects (e.g. MongoDb can used encrypted data instead of plain text JSON, similar is with Kafka and others), but then we are getting into the next problem.
SaaS – performance perspective
In case of data encryption, Kafka for example, won’t be able to use zero-copy feature, which will significantly slowing down your SaaS service.
This is one of the several ways how such (SaaS) vendors are cheating with performance results, as they are compare their unencrypted SW with some other vendor, that uses commercial version of the Open Source SW – meaning with data encryption in place.
For all mentioned reasons, large enterprises are carefully investigate and challenge SaaS vendor in every possible way.
How to overcome SaaS security issues?
Industry, although not yet fully aware of all real security concerns and SaaS shortcomings, still can offer a plenty of alternative options, and some of them I’ll describe here, sorting the list by security level in descending order.
1. On-premises/Hybrid Cloud + SaaS
Some vendors have basically on premise solution (that can be deployed in the Cloud as well) where only part of its application (like real time calculation/batch engine) is provided as SaaS.
That allows complete control over a solution (main part of application might be on-premises or in variation of IaaS Cloud), and to pass only non-sensitive (primary key + some numbers) data to SaaS component for processing, without storing/keeping sensitive data in the Cloud.
That kind of architecture is almost as secure as Cloud appliance and on-premises solution.
2. Private/Public Cloud Infrastructure-as-Code template
In Infrastructure-as-Code architecture you have all flexibility to choose from Private or Public Cloud offering (bare metal or shared instance, many Compute & Storage options…) as one advantage over a classical SaaS offerings.
Another great advantage is – ownership of your Cloud infrastructure, which means you’ll be the Cloud root account owner that allows you to have complete access control, monitoring, you can perform forensics, security audits, administration and all other activities you have in on-premises.
What distinguishes this architecture from the classical Private/Public Cloud Iaas is the third and most important advantage.
With Infrastructure-as-Code you can purchase software from the Web Store (like Amazon, Microsoft…), and with several mouse clicks (exposed by template – similar to classical wizard when installing a new software in your local machine) you can install and configure deployed software automatically.
Basically that means you’ll get up & running apps with a few mouse clicks, while keeping full control related to administrator rights.
If you arrange upgrade/patches with a vendor, you get the best from both worlds: all SaaS advantages (minimal effort to install, configure and maintain your software) + full ownership of your Cloud infrastructure where you are the only one who can access your data.
3. Classical SaaS with additional security features
Well established SaaS enterprise vendors are always using commercial infrastructure software components, especially when it comes to storing and processing customers data.
Instead of, for example keeping your sensitive data in MongoDb plain text JSON format, commercial software can offer several hundreds additional security features on top of what you are getting with SaaS vendors that are based on open Source Community infrastructure components + common Cloud provider security features (like Cloud Storage encryption & Internal network encryption).
Here I just want to list some of them (e.g. if Oracle infrastructure components where used, but some of them are also available with other commercial vendors).
- RLS (row level security / label security) – each user can see only customers that belongs to him
- VPD (Virtual Private Database) – each user can see only customers that belongs to him (option 2)
- FGAC (Fine-Grained Access Control) – each user can see only customers that belongs to him (option 3)
- Fine Grained Auditing
- Column masking (only policy defined persons can see sensitive column data)
- Secure External Password Store
- Tablespace encryption (not to confuse it with Cloud Storage encryption, it’s within a database additional encryption)
- Data redaction (additional protection of sensitive data)
- TDE (Transparent Data Encryption) – sensitive data encryption within a data files at OS level
- SQL Firewall
- Database Vault – prevents DBAs to see your data (DBA can see only metadata, not actual data)
- many security features added to audit logs
- backup encryption
- 500+ additional security features at all levels
Although I’m a great supporter of OpenSource SW, from the previous list hopefully you can get impression of width and depth commercial infrastructure components when compared with Open Source Community editions.
You can also see that it’s not all about encrypting data, as commercial features protects against DBA (Database Administrators), sysadmins (System Administrators), end users (each SaaS end client user can see only customers data that belong to him), access granulation (e.g. two SaaS app users can see same data rows but one of them will have some sensitive columns encrypted), role separation etc.
In case of SaaS architecture, especially if you are planning to store GDPR sensitive data, this is a must have for all enterprises that cares about security (and possible fines in case of ignoring it).
There is still one bad news I have to share.
Even in case of implementing all those security features from the SaaS vendors that are using commercial infrastructure components (database/application servers/integration layer etc.), in case of data breach on SaaS vendor side where attacker will get root Cloud account or private key of your favorite SaaS provider, it will takes only a minute till intruder will get your data (no matter if it is encrypted, double encrypted or so).
In such cases the only option which might help is to use Database Vault option, which is (due to the license costs) not very often installed.
More often attacker will get Cloud terminal or key store access where enterprise features will help to prevent more damage.
This also raises another question about SaaS and its future against other Cloud trends (Cloud Appliance, Hybrid Cloud, Private Cloud Data Center, IaaS + Code-as-a-Template) that will try to address security challenges.
As you can see the whole book can be written about that topic.
For all reasons mentioned in this article, when selecting SaaS vendor you should always start with some basic question like:
- Where vendor is going to keep sensitive data (what kind of databases, integration layer)?
- In which format you are storing customer GDPR related data (within rdbms, JSON/plain text…)?
- Where physically you are storing customers data (in which DCs, availability zones, regions…)?
- For how long you are storing customers data?
- How client can control data handling?
- How backup&recovery will be performed?
- How client can integrate monitoring with existing on-premise one?
Summary:
Due to the space constraints, I haven’t mentioned Multitenant Public Cloud issues, SSO (Single Sign On) and many other issues that cannot fit with your on-premise architecture.
Anyway, in case you are in a process of moving some of your on-premise apps into the Cloud, I hope this article (along with many external links provided) will help you to find the best solution that will satisfy specific requirements.
Comments