As industry is moving fast toward Cloud adoption, although not new (Amazon AWS platform was launched in July 2002), it’s no surprise that Cloud is still one of the hottest technologies around.
Started with Simple Queue Service (first AWS service launched in November 2004), Cloud today is far away from the simple file sharing service.
At the beginning, main advantage of Cloud computing model was to reduce IT costs by introducing a “shared DC” (Data Center) model, along with, at that time, already heavily used technologies like server virtualization and , a bit later, containerization which serve the same purpose.
Today, Cloud computing is much more then that, where major Cloud vendors are offering more than 200+ services, and that number is still growing.
Thus you should look at the Cloud as probably one of the fastest way to implement a new technology like Machine Learning, Big Data, AI, IoT etc., where traditionally time consuming tasks like creation of DWH or Data Lake or Oracle Real Application Cluster can be completed within several hours, allowing even small enterprises with no in-house experts or with a tight budget to be competitive, while reducing time/budget for large enterprises at the same time.
Unfortunately it is not all bright as you might think despite a massive media coverage of the Cloud technology, as in many cases I can see clearly see wrong implementation when I have to review Cloud SW, especially SaaS (Software as a Service).
Shared responsibility model
When adopting a Cloud, you are accepting a “Shared responsibility model”.
For that reason it might be beneficial first to understand what it actually mean.
There are two parties in Shared responsibility model: Cloud provider and client, where client can be you/your company, or in case of SaaS (Software as a Service) another vendor like Salesforce for example.
Cloud provider responsibility is to take care for Compute, Storage, Databases, Networking, Availability Zones, Regions etc.
Client responsibility is to take care of customer data, Apps, Identity Access, Network (Firewall rules), Data encryption, Architecture & Security in general.
Shared responsibility model In Action
In June, 2019, Google experienced a catastrophic multi-hour outage that affect not only YouTube, Gmail and other Google services, but Google Cloud users as well.
As per shared responsibility model, in this case Cloud provider (Google in this particular case) is responsible for its infrastructure, which is completely out of your control, as by adopting Shared responsibility, you accept to take a little risk to loose some control under your IT system to reduce costs or to adopt a new technologies faster.
You can find out more about that incident on the following link:
In May, 2019, Salesforce – the largest SaaS vendor had one of its biggest outages in the history, where large part of its infrastructure was down, and many customers cannot access their SaaS apps.
As per shared responsibility model, Cloud provider (in this case Salesforce is Cloud provider and SaaS vendor at the same time) is responsible for incident, similar to previous example.
On the following link you can find more details about:
On the other side, client responsibility is to create Cloud solution based on best security practice, to setup VPC (Virtual Private Network) properly, take care for open ports, Firewall rules, to choose encryption (Server side vs Client side), leverage VPN, establish monitoring and alerting, choosing among multi-tenant, dedicated host, dedicated instance etc.
In case that you as a client, have missed to setup your part properly, its your responsibility and you should fix it, not your Cloud provider.
Here we can see one of the most recent examples:
Security & Data leaks
Security, and Cloud Shared responsibility model, along with GDPR and similar regulations are one of the main challenges in front of IT.
Just in the last year (2018) there have been more data breaches than ever.
Here are the list of the largest ones:
- Aadhaar – 1.1 billion
- Marriott – 500 million
- Exactis – 340 million
- MyFitnessPal – 150 million
- Quora – 100 million
- MyHeritage – 92 million
- Google+ – 52.5 million
- Facebook – 29 million
If all those users where unique, that would mean that every third person is affected by a personal information data leak just in 2018, but even in case that some of those leaks are overlapping, the numbers are still terrifying.
SaaS and Shared responsibility model
Although at the high level you want to think that purchasing a SaaS type of some software product is just like purchasing any other product like car or bicycle, where it’s enough to rely on the contract you have with your SaaS vendor, it’s a far more complex then that.
In case of SaaS, previously mentioned shared responsibility model is still valid. The only difference is that responsibility is shared between the Cloud provider and SaaS vendor.
This is critical to understand as your SaaS vendor is responsible for architecture & security that has to ensure scalability, performance, data protection and proper data handling in place that will comply with EU GDPR and similar regulations.
By choosing a SaaS model, you accept that your SaaS vendor will take care for application you are purchasing, but also for your customers data.
Although you will have a contract with SaaS vendor, your obligation to protect your customers data are still enabled, although you have no control on it, as only SaaS vendor has a superuser rights .
For that reason it is extremely important to get deep understanding and to bi intimate with every detail of SaaS based SW, as even if you have the best contract in the world, in case of data leakage it’s worthless (and GDPR related fines could be huge).
To avoid such situations you need to understand the basics.
Let’s say your SaaS vendor claims that you are well protected as they have data on rest and network encryption in place (although actually Cloud provider ensures that, not a SaaS vendor).
In case your SaaS provider is hacked, intruder will be able to simply copy all of your documents and documents won’t be encrypted, as encryption/decryption has been made on the server side.
On the other side, if vendor is using client-side encryption, even though your vendor is hacked, hacker won’t be able to read your documents as they are encrypted on the client side (you are responsible for encryption keys).
It’s also beneficial to know on top of which Cloud vendor your SaaS application is running, to be able to check what security options are available.
On the following link you have a list of security options available on AWS:
If you already decided to go with SaaS architecture, try to negotiate with your SaaS vendor smartly to get the best deal, especially from perspective of getting full control under your data monitoring, alerting and handling.
You can also take a look at one of my previous articles to get more details:
SaaS – GDPR recommendations from leading SaaS vendors
Now that you are aware how important is to get all detail related to architecture & security implementation of your SaaS vendor, let’s take a look what leading SaaS vendors advice as a best practice.
Adobe is one of the top three players in Marketing SaaS (along with Salesforce and Oracle).
On the following link you can find Adobe GDPR related document:
The most important part is that Adobe suggests:
Remove personal identifiers where possible. Brands should consider the role for privacy-enhancing techniques like data hashing , data obfuscation or data anonymization. Doing this will help minimize compliance obligations.
Best Cloud architecture for a large enterprises
On the following link:
you can find exceptional document written by Joe McKendrick, industry expert in a Cloud architecture domain.
The next link is even better (pdf downloadable document – free registration needed):
Main idea behind this article is to describe Industry Cloud architecture which is based on dominant Business Oriented Architecture (either on-prem or in some of the Cloud variants), with emphasis on industry specialization (like banking, telco, retail…), but that is topic for some other article.
What is important for Shared responsibility model and Cloud Security are the sections of the article that are related to banking industry, which should maintain the highest standards when it comes to security, so it might help you to mitigate challenges with shared responsibility model.
Some of the interesting parts from the article are listed below:
Financial institutions continue to express reluctance in outsourcing their core banking and most of their mission-critical systems to the cloud, especially to the public cloud, where there were damaging and highly publicized security breaches.
Part of the concern relates to financial institutions’ fiduciary responsibilities to their customers. If financial and/or other highly sensitive data gets compromised, customers (and financial institutions) face major liabilities resulting from identity theft, fraud, and other malicious acts.
Financial institutions will continue to take a measured approach toward cloud adoption. There have been too many recent data breaches that have scared consumers and make financial institutions wary.
Interesting part related to choosing a Cloud provider:
When it comes to both core and ancillary systems, financial institutions prefer to go with cloud providers with well-established financial and IT reputations; that can be trusted with demanding levels of governance and security; and that can provide cost-effective services that “fill the gaps” in corporate internal infrastructures and product/service offerings.
For all of these reasons, financial services companies are opting for a hybrid IT infrastructure that incorporates elements of public cloud, industry cloud, and internal IT to optimize resources in support of their business.
Main point you can take from the article is that hybrid Cloud architecture is probably the best possible architecture for financial institution, which means for a large enterprises as well, as you will have a maximum flexibility and control, but still get all the benefits from the Cloud.
This is one of the longest articles I’ve written so far, but with so many feedback on my previous article related to SaaS and GDPR, I hope this one will be helpful as well.