Getting Data In

Best practice to restrict access to view events by sourcetype?

myandow
Path Finder

Is there a best practice to restrict access to events in Splunk by index and sourcetype?

I have tested using the "Restrict search terms" setting, but have found that there are far too many unintended side-effects that make this an undesirable option. As far as I can tell the best option is to use the forwarder to split up sourcetypes by index, and then assign the access to each index via roles.

Am I missing any other options? What do other people do to provide this functionality?

0 Karma
1 Solution

rjthibod
Champion

To answer your primary question, indexes are the only guaranteed way to restrict access per role or user.

Now, how you separate sources/sourcetypes in indexes depends on how your deployment is configured. There is no prescribed way to do this, because the actual implementation of the separation is tangential to how splunk enforces RBAC at the index level. So, you can separate the data at the Universal Forwarder, Heavy Forwarder, or Indexer.

Just an FYI, note that any saved searches that run against the data need to take into consideration the RBAC you have setup at the index level. You need to make sure you don't transgress the RBAC limits with a saved search that writes data to a summary index that is visible to users that shouldn't see the data.

Also note that Datamodel acceleration does follow RBAC rules you setup at the index-level.

View solution in original post

splunklearner
Path Finder

@sloshburch @rjthibod Can you please explain what is RBAC with indexes approach? The wildcard approach?

0 Karma

rjthibod
Champion

To answer your primary question, indexes are the only guaranteed way to restrict access per role or user.

Now, how you separate sources/sourcetypes in indexes depends on how your deployment is configured. There is no prescribed way to do this, because the actual implementation of the separation is tangential to how splunk enforces RBAC at the index level. So, you can separate the data at the Universal Forwarder, Heavy Forwarder, or Indexer.

Just an FYI, note that any saved searches that run against the data need to take into consideration the RBAC you have setup at the index level. You need to make sure you don't transgress the RBAC limits with a saved search that writes data to a summary index that is visible to users that shouldn't see the data.

Also note that Datamodel acceleration does follow RBAC rules you setup at the index-level.

sloshburch
Splunk Employee
Splunk Employee

Yea, you guys nailed it. RBAC with indexes are really the best approach. A great build on this is to use naming conventions that allow you to use wildcards in the role definition of indexes allowed. Lemme know if that isn't clear.

rjthibod
Champion

The wildcard approach is exactly what I use my app. Works great for me and our unique data source.

0 Karma
Get Updates on the Splunk Community!

Federated Search for Amazon S3 | Key Use Cases to Streamline Compliance Workflows

Modern business operations are supported by data compliance. As regulations evolve, organizations must ...

New Dates, New City: Save the Date for .conf25!

Wake up, babe! New .conf25 dates AND location just dropped!! That's right, this year, .conf25 is taking place ...

Introduction to Splunk Observability Cloud - Building a Resilient Hybrid Cloud

Introduction to Splunk Observability Cloud - Building a Resilient Hybrid Cloud  In today’s fast-paced digital ...