For my research project, I have a problem. I want to set up a SIEM solution within the Elastic Cloud. In the SIEM solution, I aim to establish multi-tenancy for different customers, ensuring that each customer's data is separated. I plan to achieve this using pipelines and indices, or using multiple deployments.
I can't find a solution on the internet, so I hope you guys can help me!
Hi @Maxim_Palenov , thanks for your reply.
I looked at Kibana Spaces, but I think it only allows you to separate data at the UI level. I want it physically separated so that client data is not mixed up.
I think this is only possible with pipelines and indexes or multiple deployments.
Yes, Kibana Spaces don't split data into separated indices or data streams but rather tags each data entry with a space id. Kibana Server APIs extract space related data by using space information. This approach is in use by various MSSP solutions using Kibana spaces to manage data for different customers. So Kibana spaces is a standard way to organize multi-tenancy.
Another solution would be running multiple ES and Kibana instances but Elastic Cloud doesn't provide this out of the box. You need to create multiple deployments which is obviously not multi-tenancy.
I'd also recommend to check out Elastic Serverless. It's a fully managed solution where you pay only for used resources. There is a chance multiple Elastic Serverless deployments will fit your needs.
Hi @infraendboss, it depends on your requirements for multi-tenancy, i.e. how exactly it should work and what data should be shared between tenants and what data should be isolated.
If you need the source data generated by beats/Agent, such as logs-*, to be shared between tenants, but each tenant should have their own set of Kibana entities (dashboards, data views, detection rules, etc), then creating a Kibana space per tenant should do the job. You will need to explore Elastic Security system requirements | Elastic Security Solution [8.13] | Elastic to learn how to set up RBAC per tenant / Kibana space.
If you need the source data, such as logs-*, to be isolated between tenants (each tenant should have their own data), then you could still use a single Elastic deployment and create a Kibana space per tenant. But in contrast with the first approach, you'd have to set up your data sources (beats or Agent) to send data to indices like logs-tenant1-*, logs-tenant2-*, and then set up a more involved RBAC to ensure isolation between tenants using index-level privileges.
Finally, if you need the highest degree of isolation between tenants, you could use multiple deployments + cross-cluster search. Each tenant would have their own Elastic deployment with source data + optionally Kibana entities, and in addition you might want to have a "main" deployment that would be connected to all tenants' deployments via CCS and you'd be able to have, for example, a common set of detection rules working with source events of all the tenants.
The first approach would be the easiest to implement, the the second and third approaches could require substantial effort.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.