Enough has been said and circulated over any possible media you can imagine about Cloud security.No matter how thoroughly testers test cloud solutions , “security advocates” going crazy about the so called lack of security of sensitive data over the cloud. They are right to express their concerns and vendors should pay attention. Moreover, we should keep always in mind that one of the most important reason for slow cloud migration is security.
Cloud security has been so hot to debate about, that even after a decade or so, we started to re-thing how to use common terms such as “web-application”, “internet of things” etc. in a politically correct manner…As a consequence, politically correct vendors have taken all the necessary measures to assure and re-assure customers about their security mechanisms implemented on top of SaaS, PaaS etc.
– And why are we STILL talking about cloud security?
– It’s because people have a mental disorder about their stuff!
Let me explain. It is OK for someone to have his stuff “somewhere” stored securely, as long as he knows (or at least he thinks he knows) where his stuff is. The problem starts when you tell him: “listen, to have the requested service, I have to transfer a bit of your stuff here, process it and then store it temporarily to over there… Don’t worry. It will be all secure and you won’t notice anything”.
Nop. No way! No matter the Service-Level Agreement (SLA) or the fancy security you implement there will be always a prejudice towards your service. It’s not about your service. It’s about knowing where my stuff is at any given time! So, what can you do as an honest SaaS vendor for your security “aware” customers? Actually a lot! Basically you have to alleviate their concerns over multi-tenancy, virtualization and unauthorized information flow.
Here is my short “security bucket list”:
- Credential Autonomy/Automation: As cloud users invoke services across multiple clouds, you have to provide access control policies able to support the transfer of customer’s credentials across different layers of services and resources. If you are a bit confused, think of it as the user’s global cloud single-sign-on for persistent authorization of their identity across multiple clouds.
- Multitenancy access control: It is common, when allowing access to multiple domains to observe interference among tenants due to flawed access control mechanisms. You should evaluate and re-evaluate hundred times more your access policies in order to prevent unauthorized information flow leading to side-channel attacks.
- Think decentralized: As you cannot pre-estimate the degree of granularity of your services access control over their resources, you should think in a decentralized manner. You should -by design– allow each service to retain administrative control over its resources. This will come handy when you will have to deal with several independent clouds requiring a plethora of authorization rules.
- Resource Watchdog: To cope with multiple and heterogeneous cloud environments you should implement a Resource Watchdog that will be responsible for managing your virtual resources. You do that in order to monitor your deployed resources and to guarantee their availability at all times -but most importantly- to manage scalability issues both for users and resources.
- Super SLA: Most of the times you have to deal with the situation of having different policy models implemented for resources and for services. In these cases you should build a super SLA that will enforce secure collaboration between the domains and guarantee that the services offered are based on the agreed access control rules.
