Is SAP HANA really multitenant?
In latest release (SAP HANA SP09) SAP released new SAP HANA feature – Multitenant Database Containers (MDC). I am personally excited by this news and I am seeing there quite a huge potential. But what are the real use cases for this feature? Is it making SAP HANA really cloud product which can be used to serve different customers? Or it is feature for one customer which can help him consolidate his workloads…
I am getting these questions quite often and honestly I did not yet formed my own opinion myself. Although this might be little illogical I decided to write a blog on this topic because it might be good way to draw some attention to this point and maybe (hopefully) trigger some discussion on this topic.
This blog is containing my own ideas and opinions – it is NOT reflecting opinion of my employer in any way.
Concept of Multitenant Database Containers (MDC)
MDC containers are nicely explained in many other materials, blogs and articles – so I will not attempt to document something what is already covered. For explanation I can point for example to SAP HANA Master Guide (page 25) available here: http://help.sap.com/hana_platform
In short – with latest SAP HANA release you are able to create multiple separate database containers which will be listening on specified ports and which will be independent on each other. This brings many benefits against traditional MCOD and MCOS deployment models (see SAP HANA Master Guide mentioned above for definition and explanation).
I would not hesitate to say that this new option might be seen as replacement for MCOD and MCOS making them obsolete and I would not expect big disagreement from the community.
Can SAP HANA be used for multiple customers?
But does this feature really replace virtualization? Can one SAP HANA installation be used by different customers? Is this concept safe enough?
Currently I would be very careful in deploying SAP HANA in this way. By saying this I do not mean it is not possible – all I am trying to say is that extra effort is required before such deployment can be used.
What is my main concern? Typically shared environments are offering very strong separation which is achieved on network level. Customers are really using same infrastructure however this infrastructure is configured in a way that network packet cannot leave from one tenant into another tenant – unless of course this is desired and it is intentionally configured – and even in such case these packets are traveling across one or more firewalls controlling that this traffic is really something expected.
This is very important for security because humans are very creative and they tend to find most unbelievable ways how to break into places which were (until that moment) seen as impenetrable.
Probably all hypervisors (including VMware) are offering this strong separation. Individual Virtual Machines (VMs) are having own IP address and hypervisor is ensuring that packets are delivered only to the particular VM which is expected to receive them.
Issue with SAP HANA being used by multiple customers is that such strong separation on network level is not possible. I have no reason to not trust SAP when they say that SAP HANA is internally multitenant. But I know for sure it is not externally multitenant on network level – it simply cannot be on its own at this phase. It is still one environment accessible by many customers. If customer can connect to one port (associated with their database container) then there is chance he might be able to connect to the other port which is associated with database container of different customer. At least this will happen if no additional actions are taken to secure such setup.
What could be done to improve such setup? Well after talking to different people I found that there are number of ways how you might increase the security of such setup.
For example you might encrypt communication channels and encrypt the storage to make it harder to access the data from other tenants. However this is not blocking the access to the other tenants – it is only making it more difficult.
Another alternative might be to put firewalls around SAP HANA to filter the traffic and to ensure that each tenant is blocked from connecting to ports (representing database containers) that do not belong to given tenant. This might be working solution however it is increasing the costs and overall complexity of such solution. Also might impact bandwidth and latency of particular flows spoiling performance. And last but not least – effort to automate such setup is increasing considerably.
Last area worth mentioning is openness of SAP HANA itself. SAP HANA is not “only” database – it is more than this – it is platform in which we can develop applications. However from security perspective this brings a lot of risks. I am not SAP HANA developer so I might be wrong here (and feel free to correct me here if you think so) but I can imagine smart developer coding application which will allow him to connect to port belonging to another tenant’s database container which might be network flow not controlled by firewall because it is on same server.
Bottom line – I am seeing all options above only as obstacles which are making it more difficult for attacker to breach into database containers belonging to other tenants. And honestly at this point I do not know what is the best infrastructure architecture to securely deploy SAP HANA used by different customers.
And this is where I am seeing additional effort required. This is either something individual providers will have to figure out themselves or something where SAP can create reference architecture.
Of course it is obvious that such reference architecture would boost MDC adoption among various providers offering SAP HANA to their customers while absence of it will be strong inhibitor. And since objective of sharing workloads is motivated by intention to decrease the costs this will in turn impact adoption of SAP HANA itself.
Is there any smarter solution?
I am seeing approach I described above as very complex and not very transparent and I believe there is better option however SAP would have to step into the new area where they are not yet operating. This act might also have some drawbacks which were described in following blog: http://diginomica.com/2013/12/20/multi-tenant-multi-instance-saas-spectrum
Here I would like to outline that all descriptions below are my own speculations of what could be done to make SAP HANA truly multitenant. This is NOT what SAP suggested that they plan to do or what is on their roadmap.
In my opinion major improvement would be if SAP HANA would adopt some principles from virtualization – in particular Software Defined Networking (SDN) approach. There is no need to virtualize complete VMs – it would be sufficient to allow SAP HANA to associate each database container with its own IP address and then ensure routing of particular network packets to the right destination. In short it would be doing similar network service VMware hypervisor is doing to individual VMs.
On top of this SAP HANA would need similar options like VMware to define internal routing so that it is clear which database containers inside one SAP HANA installation belong to the same customer and are allowed to see each other and which are blocked on internal network level (inside SAP HANA instance).
Why is this critical? Because if done properly it will push down the separation between tenants to the network level (although virtualized) ensuring that no breach could happen on application level – and all this without the need to build overcomplicated network architectures.
It would also enable additional features which are seen in virtualized world (here I will use VMware as reference). I can imagine having similar features like vMotion – where database container could be moved to another node without any disruption – as IP address would remain same it could be stateful move completely transparent to external applications. Feature like VMware Distributed Resource Scheduler (DRS) where SAP HANA itself could relocate containers based on actual utilization and respecting preconfigured rules. Or features like VMware Fault Tolerance where container would be internally redundant preventing any disruption in case that one node will fail.
All this could be complemented by allowing differences in revisions on individual nodes – which could help to ensure that any updates are completely without any downtime – where nodes will be upgraded one by one and containers would be relocated without any disruption to the node with latest revision.
In summary such step might open quite a lot of options for SAP HANA where SAP HANA would become virtualization layer on its own – completely separating application (database container) from underlying infrastructure (hardware, OS, instance processes).
Summary
To summarize – I believe that SAP HANA Multitenant Database Containers (MDC) are interesting option how to consolidate workloads for large customers having multiple SAP HANA landscapes or in other similar situations where strong separation is not that critical.
On the other hand I am not yet convinced that SAP HANA MDC containers can be used (at least not out-of-the box) as shared solution for different customers on same SAP HANA installation. It might be possible – but not without very careful assessment of risks and creation of infrastructure architecture which would ensure full separation of individual clients.
I do not know how much is SAP ambitious with SAP HANA and if they really intend to turn SAP HANA into fully multitenant software but I am curious to see how things will develop with next releases of SAP HANA.
Updates
In this section I will try to list the most important updates since this blog was written in January 2015.
I am not going to summarize the comments below the blog as I might misinterpret them – be sure to read them as they offer additional insight into the subject from recognized experts in the SAP HANA space…
17.12.2014
Yes this date is correct – apparently I did not do my homework correctly – in SAP Note 2096000 – SAP HANA multitenant database containers – Additional Information SAP is stating following information: “It is not recommended with SPS09 to run a hosted environment with several databases from different … customers together in one multitenant container system. This kind of usage is reserved for SAP internal usage only.”
16.4.2015
Again in SAP Note 2096000 – SAP HANA multitenant database containers – Additional Information SAP published information that: “Using ‘Backint’ with external backup tools for recovering MDC systems/tenants requires revision 94. This fix will allow to use Backint for backing up and recovering exactly the same tenant of an MDC system. It may not be used for restoring it into another tenant in the same or in another MDC system (tenant copy).“
Be sure to check with backup vendor if their solution is prepared for MDC setup – there is good reason for this question as command line call (using hdbsql) can fail if not correctly executed – multitenant installation need to have parameter -d correctly specified otherwise it is not clear where the tool is trying to connect (which would result in error).
Tomas,
For me the recent release of Multi-tenancy is really for the HCP HANA instances to allow PaaS developers to maintain a single code base and make code deploys easier, rather than having to deploy on to a separate instance for each customer.
I do not see Multi-tenancy really coming to on-premise properly until SP10 or SP11 and then I think customers will see an actual architectural shift in HANA deployments. So for example, it would be possible to distinguish an SP11 HANA deployment and a pre-SP11 HANA deployment for example.
This is all pure guess work though, but I think there are clues in the way SAP applications are being written, the simplification of the data model for the Suite and certain statements about simplification in general may support a large architectural shift.
Chris
Hello Chris,
thank you very much for you comment - this is definitely nice use case where this will help - especially if you need high amount of relatively small databases... in that case MCOS would be really tough and MCOD would be limited..
but on the other hand in such case (if my understanding is correct) the owner is developer and not end customer and technicaly this use case falls into category where you do not really need strong separation - in this case multitenancy is not multi-customer setup as there is just one customer (developer himself)... correct?
Tomas
Tomas,
The best person to ask about this is Chris Paine (@Wombling) because he is the person from whom I first heard about the difficulties in managing an HCP application for many customers in a single tenant HANA database.
Chris
The big factor for HCP here will be speed of deployment and cost.
Getting a small HANA db for a customer is currently expensive, but this will bring down SAP operating costs, which in turn should bring down costs to customers.
Also, speed to provision and deploy should improve.
For other SAP SaaS based apps this would be a bonus! Ie currently a 24h turnaround on getting a new SuccessFactors instance, this should be reduced.
Tomas' point about network level security not being as important for a developer leveraging the multitenancy is a fair one. Indeed it would probably make my life much harder if I attempted using individual dbs for each tenant!
I hope that we have the option for a happy medium where both options are supported as Tomas makes some very well argued points.
Cheers,
Chris
5*
what more to say
Andy.
Thank you very much...
Hi Tomas,
basically you summarised the category I fit into:
To summarize – I believe that SAP HANA Multitenant Database Containers (MDC) are interesting option how to consolidate workloads for large customers having multiple SAP HANA landscapes or in other similar situations where strong separation is not that critical.
And for me and other people like me, this is a major milestone in the evolution and path to maturity of Hana as a DB for On-Premise, in as much as, looking forward, we won't be forced to have a 1:1 relationship between Appliances and DB Instances in Production which will lower the costs.
But on the other side, your thoughts on security and isolation are things which I have not previously considered with regard to MDC and so, your blog has opened my eyes to something I hadn't previously considered - thank you for that. Even in the relative safety of our on-premise data center, doesn't mean we can ignore security vulnerabilities, and based on your input I will not be surprised that an outside agency executes penetration tests of a SAP solution using a Hana MDC and reports the vulnerability that at the DB they can hop from DB Container to DB Container, therefore, even in the relative luxury and safety of our own DC we need to be thinking about this risk and how to mitigate it.
Best regards,
Andy.
Thank you again - I really appreciate your feedback...
Hi Thomas,
as the others already stated: good blog post!
I am not involved in the MDC development or planning, but my view on it is this:
As with other features that had been introduced I am sure MDC will develop and evolve over time. And the purpose, use case and limitations will likely change a lot over this time.
Having written this, I am as curious as you are to see what solutions will leverage MDC.
- Lars
Hello Lars,
thank you very much for your comment... based on overall feedback to this blog I learned one important thing - there are (at least) two basic points of view:
1.) developer point of view
Here we are having all use cases where we are looking at developers that are going to use MDC to delivery multitenant applications or environments. Key advantage here is that database is not directly exposed to end customers and stays under control of one subject (who could be developer himself). In such scenario I totally understand and agree that MDC containers will open huge options. As developers could easily create for each customer different MDC container and then easily drop it as they need.
However it is important to understand that from infrastructural point of view the database is owned by one entity that does not need that strict separation on infrastructure level. As a matter of fact for these use cases - network separation might be seen as additional complexity to deal with without getting any added value.
2.) infrastructure point of view
Here we are having classical use cases - having customers running on shared infrastructure (containing HANA and non-HANA applications, containing systems not under full control by provider, maybe even including systems where customer might have OS access, etc.) In this case tenant is seen as "slice" of this shared infrastructure and is not limited only to a "slice" of database – this means slightly different definition on tenant.
In such picture you do not have full control over the environment and network isolation is very simple and elegant way how to keep overall solution very secure. Here I am finding it difficult to place SAP HANA with MDC containers into this picture so that each MDC container on one SAP HANA database can become part of different infrastructure tenant.
Of course this does not mean MDC containers cannot be leveraged in such environment. I still see huge benefit of MDC containers for single customers (where whole DB is part of one infrastructure tenant) and where each MDC container is used for different systems owned by that customer. But at the same time I am seeing that SAP is very close to get this “infrastructure oriented gap” addressed and to deliver SAP HANA in completely new and innovative way.
Summary
I understand and agree that MDC containers are new - and I am aware that SAP is not yet done with development and we can look forward on next releases and only guess what new innovations will come. However at the same time I believe that now it is the right moment to open discussion about potential use cases to ensure that SAP is aware how else SAP HANA MDC containers could be used and what is missing to get this done.
Hello Tomas,
Aside of developer and infrastructure issues, I think that the MDC feature could also bring functional benefits. For instance, having ECC and SCM in a same HANA system, could make it possible to do "cross-database reporting" - less interfaces, less unnecessary data transfer between applications, less redundancy, and etc.
Regards,
André
Hello Andre,
I totally agree - and my intention was not to say that MDC containers are not having added value - that was not the message...
I personally see big value of MDC technology for example as replacement of MCOS deployment approach which was associated with many constrains, or as co-location approach as you mentioned. Also HPC use case mentioned by Chris Kernaghan and by Chris Paine where you need many small databases makes perfect sense...
My point was to elaborate on what SAP HANA multitenancy really means as this word can be interpreted by different ways - for example as ability to host different customers in similar way like VMware can do it - and that it not the case (and as I found after writing this blog - this is also confirmed by SAP Note 2096000).
Here I believe that SAP might go further and bring even more value into MDC containers - turning SAP HANA into fully multitenant application - both internally and externally delivering full network separation - when HANA could become kind of virtualization layer on its own.
Tomas
Hello,
In (my) ideal world I would be looking at following roadmap from SAP:
1.) SAP adopting SDN (Software Defined Networking) principles giving each MDC container its own IP address (rather then just port) and ensuring proper network separation - this would be complemented by internal "networking" which would decide which MDC containers could see each other and which are isolated
2.) In next step SAP would leverage SAP HANA System Replication to create vMotion like feature (let's call it DCM - Database Container Migration) - allowing customers to move containers between nodes without disruption (given the fact that each container has its own IP this would be seamless operation)
3.) Then SAP could improve performance monitoring and create decision logic to autoinitiate DCM (see point 2.) across the cluster - this would act like VMware DRS (Distributed Resource Scheduler) - ensuring that if one server is overloaded then action is taken to redistribute the workload -- this would also allow more elastic scaling - where each MDC container could have kind of "autogrow entitlement" based on customer specification or license agreement
4.) Then SAP might leverage DCM (see point 2.) to create internal High Availability - where container would be internally replicated on two nodes and in case of failure it would simply switch over to "shadow" container (something like VMware Fault Tolerance)
5.) Next step might be SAP allowing different versions in one SAP HANA cluster - where one node of the cluster might be upgraded and then upgrade of MDC container would be performed leveraging DCM feature (see point 2.) and moving to node with more recent version of SAP HANA -- this would bring totally nondisruptive way to upgrade cluster - where each container can be upgraded at different time
If these points would be adopted then SAP HANA could become "cloud application" where individual servers would be added to the "shared pool" of computing resources and SAP HANA would ensure total separation (virtualization) of MDC containers from underlying hardware.
This is my "dream" vision of what SAP HANA could become. 😉
Tomas
Hmm , so you are saying SAP should now either write their own virtualization software or acquire an existing one 🙂
Hello,
not really - I do not think SAP indends to support virtualization of competitive products..
If they would start writing virtualization software (or they would acquire that) they would have conflict on interests. In order to be best in virtualization they would have to support competitive products which would draw them away from SAP products...
I think they do not need full virtualization - why to have OS below MDC container? That is adding no value and just making things difficult to manage - all that is needed is that MDC will start behaving more like VM...
I do not know the best solution - above you see my view however there might be better way to do it...
Tomas
Hello,
I would like to point to following SAP note that is covering very important aspects of using MDC containers... MUST KNOW kind of stuff...
2096000 - SAP HANA multitenant database containers - Additional Information
Information there is also confirming some points from this discussion thread...
"Multi tenant database containers are suggested to be used in a trusted environment. It is not recommended with SPS09 to run a hosted environment with several databases from different domains, singular and separate data sources, or customers together in one multitenant container system. This kind of usage is reserved for SAP internal usage only."
Tomas
I beleive MDC is more focussed to HEC scenarios where the HANA appliances (more so when HA/DR mechanisms are considered] are NOT shared amongst customers. But because the current boxes are expensive, the TOC reduction measures in terms of putting all 'relevant' application data into teh same hardware is considered.
As long as it is for ONE customer, the security concerns described in the blog wont apply [Or the same security concerns as for a single tenant db apply].
So atleast for midsized customers, going forward with SPS11/12, having ERP/BW/CRM etc etc hosted as tenants in the same HANA SID could become the norm [ note : currrently with MDC, some functionality in the area of DR/recovery - especially with scaleout systems is still being worked upon]
Nice Blog Tomas 🙂
Good Blog...
HANA for multiple customer and implementation challenges. Nice blog.
A good use of HANA MDC is if you have 2 BW on Oracle & want to migrate to HANA.
One issue is if the 2 BW servers are on different time zones now, when you go to MDC BWoH, they must be on the same time zone.
HANA will use the O/S to determine what timezone it is using.
The problem with multi-container system is that the <sid>admin user is the same among all of the tenants, so you cannot have one tenant with one timezone and another tenant with another timezone.
Not sure all that would be affected when changing timezones on a BW system when migrating to HANA... Log history, process chain schedules, other?
Hello,
I am supporter of UTC timezone 😉 I tend to believe that databases and application servers should not be "bothered" by timezones and all desired conversions should happen between application server and client... but I fully understand that this can sometime lead to issues and experienced few of them myself...
Tomas
Hi Tomas
I see MDC mostly for SAAS purposes at the moment and it seemed to have been build specifically for what SAP wants to accomplish with their S/4 HANA public cloud and other such ventures. It doesn't have a focus on service providers or anything like that. It's also still early days in my opinion as MDC has a number of restrictions and let's say missing features. SAP will be adding lots of interesting options and perhaps at some point in time MDC will be the default option when it's slim enough etc. Your comment on network security is interesting. The different MDC containers currently still use the same <sid>adm as mentioned by someone else here already in the comments. That's not ideal either.
That said, I think for service providers it's more interesting right now to look at what other vendors are offering in terms of virtualizing SAP HANA and to me VMware is a front runner in that space at this moment in time.
It seems like the focus of SAP is on their own cloud environment. It It's very hard to get clear information from SAP on what is possible, where there are still restrictions and so on so I've resided to discussing and talking more to those vendors instead of SAP which is a pity as I had hoped SAP would chime in more.
We are currently leveraging SAP HANA Tailored Datacenter Integration combined with VMware 6 for our service provider SAP HANA cloud environment. At the moment that seems to be the best solution at hand.
Kind regards
Tom
Hello Tom,
thanks for comment... regarding TDI I tend to see only marginal benefits...
there are some benefits for non-Lenovo customers because Lenovo HW (which we are using most) is having kind of "software defined storage" (there is GPFS instead of traditional storage) which is extremely elastic - so all the storage TDI where you will start using external storage would actually make things more complicated... similar logic applies to network TDI...
in area of compute node TDI there might be some potential benefit however I am still seeing that benefit as small - you might "avoid" official models but you will be "punished" by not being supported by HW vendor for overall solution in case of trouble + you need to invest into team designing and constantly maintaining the solution..
regarding VMware - I would see VMware as way how to set SAP HANA free from its still strong dependency on particular HW however SAP set so many rules and limitations that real benefits are again small... just looking at today's version of SAP Note 1995460 - Single SAP HANA VM on VMware vSphere in production:
- no scale-out
- one VM per hypervisor (for productive VMs)
- only 1 TB limit...
I am sorry but my opinion is that this is maybe good for development systems but not very useful for productive systems (too small and too limited)... and since quality should follow same setup as production I tend to again see this as not very flexible and versatile option...
I think SAP need to either:
1.) finally release all constrains on VMware so that it can become really flexible and elastic solution like it is today for all non-HANA technologies
-- or --
2.) turn MDC into kind of "virtualization" layer on its own - like I described in the blog above...
Today SAP HANA is very closely tied to the HW which is limiting the options for providers - which is in turn making whole solution more complex - which is making it more expensive for customers - which in turn is driving SAP HANA adoption away... Best what can SAP do to improve SAP HANA adoption is to make the rules for providers more simple so that they can offer less complicated solutions with lower costs to customers...
Regarding SAP not giving away much info - I am having similar experience - it almost looks like that there is embargo on this topic... Since I am optimistic person I want to believe that this means that SAP is having some nice surprise for us on SAP Sapphire... Let's see what SAP will prepare for us...
Tomas
Hi Tomas
That SAP note needs an update soon 🙂 . You can find some relevant information on VMware 6 capabilities (in terms of limit increase) in the VMware OTF (Online Technology Forum) which took place, replays should be available.
It's a matter of time in my opinion but I definitely agree we've been waiting for a long time already and it would be nice if SAP would lean in and speed things up.
Kind regards
Tom
Hello,
thanks for the tip... also found this link SAP HANA on VMware vSphere which seems to confirm that SAP plans to fix this...
vSphere 6.0 - limit 4 TB
Scale Out - planned for H1 2015
8 CPU Sockets per server - planned for H1 2015
This is definitely good news - finally getting SAP HANA out of the "jail" 😆
Tomas
Hi Tomas,
I like your blog and your analysis. Now I want to ask you if you had the opportunity to take a look at SAP HANA SPS10.
I am not fully sure right now if the following features were already present in SPS09 (I have to recheck the guides), but I know you can now create a tenant database with high isolation level (different os user and group), and on top of that you can set a different host for the main nameserver of the new tenant database.
For sure they added a new feature for the secure internal communication in SPS10. The internal processes can communicate using SSL in this scenario, which will increase the security of distributed tenants belonging to the same system.
What do you think about these new features? did you take a look at it?
Hello,
multi-tenancy can be discussed on different levels - I liked the slide #5 from SAP Note 1788665 (see slide deck attached to the note) where Arne Arnold outlined vertical view - defining following potential layers where multi-tenancy might happen:
I think this classification makes everything clear. First you need to define where on which level you expect multi-tenancy to happen and then you need to live with fact that all underlying layers are "shared" between tenants (and you need to ensure this is not an security issue).
This means that MDC containers are defining multi-tenancy on "Database layer" (above "Operating System layer" = OS is shared) while virtualization is making multi-tenancy below OS (OS is dedicated).
Skipping long chain of thoughts I believe MDC containers are not positioned to replace virtualization for multi-customer scenarios (at least not as MDC is defined today) as there is not sufficient tenant separation looking from infrastructure point-of-view (where I see shared OS as risk).
Of course here I assume we are talking about enterprise-level infrastructures where we need strong network separation (infrastructure level multi-tenancy) = we expect that there is no option (even if you have root level access) to get from one infrastructure tenant (= customer) into other infrastructure tenant (= customer) - of course unless you explicitly define such connectivity because it is requested.
To be more specific here are good use cases for SAP HANA MDC usage:
Following use case is (in my personal opinion) NOT secure enough:
Reason why I believe last use case is not safe enough is exactly because of missing low-level network separation (tenants are sharing IP address and only port is different).
Increasing security as you outlined is definitely step into good direction however I do not think this is sufficient. Encrypting communication is not same as not having access to the communication - there is "increased" risk that communication can be decrypted, etc.
You might consider putting firewalls everywhere around SAP HANA and limit customer to use only particular port - however I still see risks where person will leverage extraordinary features of SAP HANA and will find way how to get to different tenant across "shared OS" (layer that I consider to be security risk). You might call me paranoid if you wish - but recent news are proving that you cannot be paranoid enough... 😉
In simple words - people are smart and should not be underestimated... Here I would expect SAP to either continue to keep the position which is today documented in SAP Note 2096000 (see quote below - mainly for SP09) or to come with "reference architecture" for multi-customer setup which is internally tested by SAP using ethic hacking (where people are trying to compromise the designed setup) - of course this would have to be repetitive process as every new feature might open security hole (which would probably slow down release speed of SAP HANA).
Different alternative which I outlined in blog above is about option where SAP might decide to "extend" SAP HANA to operate on multiple layers in parallel = keeping database part, removing OS as not required part and partially playing role of hypervisor for network virtualization (where OS would be below-hypervisor = not considered as risk). However it does not seem as direction SAP is heading.
Hope I answered your question...
Tomas
Hello,
maybe summary of my very long answer (speaking on my own behalf only)...
all depends on what your security expectations are and how strong separation you consider as minimal - looking very high level I believe that for single customers this might be sufficient (depending on customer security requirements) however I do not believe this meets security requirements for providers to host multiple customers...
Tomas
Hi Tomas,
but for Customers to host their own multiple system's db in the same Hana it's ok ?
Best regards,
Andy.
Hello,
from security point-of-view I think that yes - of course unless customer is having specific security requirements (maybe because of legal regulations - I am not expert on these)
main argument here is that if whole infrastructure is dedicated then you do not need to be so much paranoid as if infrastructure is shared... risk can be defined as combination of probability and impact - where with dedicated infrastructure the probability of attack is same or lower (then in shared infrastructure) and impact is generally much lower (same customer)
to be even more specific - if you would consider multiple DEV containers in one SAP HANA database all belonging to same customer - is there really so strong need (like with multi-customer situation) to ensure that user of one container cannot breach into another container? I believe that potential damage is much lower...
of course then there is another aspect of having MDC - you should consider impact of following:
Tomas
Hi Tomas,
reading the thread and your feedback, let's say a customer is for example running systems with sensitive data, then these ones should avoid the MDC until the security is improved and ring fencing so to speak is possible at the MDC level
Andy.
Hello,
as I wrote above "all depends on what your security expectations are and how strong separation you consider as minimal"
if your "minimal" non-MDC (dedicated) solution would be based on defining separate network zones (VLANs) to host this system and to protect it from other SAP HANA systems by firewall then MDC will not meet this security standard...
on the other hand if your DEV server would be sitting next to your PRD server (sensitive system) - both on same VLAN and able to connect to each other - then MDC based solution will be offering comparable level of security...
Tomas
Thanks for your answer!
I totally agree with you. In fact, I consider it is almost a matter of semantics. We all need to have clear in mind if we are using the same definition of a word, in this case "multi-tenancy". And as you well explained, we have different layers and we have to specify where we are situated when we talk about this feature.
One more thing I want to highlight:
"You might consider putting firewalls everywhere around SAP HANA and limit customer to use only particular port - however I still see risks where person will leverage extraordinary features of SAP HANA and will find way how to get to different tenant across "shared OS" (layer that I consider to be security risk). You might call me paranoid if you wish - but recent news are proving that you cannot be paranoid enough... ;-)"
I cannot agree more with that statement. That's totally true. As the recent news, we must be paranoid and we cannot underestimate anybody. Sometimes security is not about adding patches and more features, sometimes it is just about doing it simpler. As you said: a lower-level network separation.
Best regards,
Sergio