Restrict users to see their logs (with config IDs) only

[splunklearner]

We have security logs coming to Splunk using data input configuration in Splunk.. The logs have a field called security configuration IDs and they are unique and each config id belongs to one app. Sometimes two or three belongs to one app. Approx they have 200 config IDs and they want to restrict users from not seeing other config ID logs. So they are asking to create 200 indexes with config id in index name and can restrict based on that.

But according to my knowledge...having more indexes is not a good idea. It needs more maintainance and stuff like that.

So what am thinking is while configuring data input I can name with config accordingly so that it will come under 'Source' field and a single index for all of them. When creating role I will be assigning that index and in restrictions I will be giving search filter that belongs to individual user.

My question is will this work as expected? Anyone already following this please confirm.

Even if we restrict A user with common index=X and Source=123456 (config ID) and save it... If he give index=A in search still he can see all config ID logs or only 123456 ID logs? Please confirm.

Any other alternative idea also please help me.

[isoutamo]

Personally I try to avoid search filters as much as possible, even creating more indexes etc. if you have extreme simple environment which contains only one role per user and one use case then those could work without issues? But as @richgalloway already said, when there are different search filter for each roles and any person have more than one role then those are combined together with AND operator (not with OR)! In real life this usually leads to situation when you couldn’t found nothing or at least what you are looking.

If possible use some template with automation tool to generate those indexes.conf, auth*.conf files and use apps or eg. Terraform or ansible to manage your splunk environment. In that way your management overhead isn’t so big and usually you will get better quality too as side effects.

[splunklearner]

@isoutamo If possible use some template with automation tool to generate those indexes.conf, auth*.conf files and use apps or eg. Terraform or ansible to manage your splunk environment. In that way your management overhead isn’t so big and usually you will get better quality too as side effects.---> I don't have any coding knowledge till date and not aware of this setup. Can you please explain more about this setup? If not possible soon what would be alternative solution? Creating indexes for each config ID (I thought it is also not a good idea). What if a single user has only single role or a user has different roles (different config IDs)!within same index... Still he would get index=A source=123456 AND source=56789? 

[isoutamo]

If you have test / dev environment you could easily add some roles which have different search filters. Assign those to your test users and use job inspector to see how splunk creates final SPL for those queries.

[richgalloway]

If you add a search filter for a role then the filter applies to *all* searches made by users with that role.

IOW, if you add "Source=123456" to the search filter with the intention of restricting results from index=A, it also will restrict the results from index=B and all other indexes.

[splunklearner]

@richgalloway IOW, if you add "Source=123456" to the search filter with the intention of restricting results from index=A, it also will restrict the results from index=B and all other indexes. ---> I didn't get this point. I will be creating a role A and selecting index A and then restricting with search filter (source=123456). So ideally user A will be assigned role A and he will have access to index A and source 123456. These source are unique and only one role for this source. This role may be assigned to multiple users. But how index B be involved here? Please clarify.

[richgalloway]

---

@splunklearner wrote:

@richgalloway IOW, if you add "Source=123456" to the search filter with the intention of restricting results from index=A, it also will restrict the results from index=B and all other indexes. ---> I didn't get this point. I will be creating a role A and selecting index A and then restricting with search filter (source=123456). So ideally user A will be assigned role A and he will have access to index A and source 123456. These source are unique and only one role for this source. This role may be assigned to multiple users. But how index B be involved here? Please clarify.

---

My presumption is that user A may sometimes need to search other indexes than just indexA.  If he chooses to search indexB then the search filter still applies, even though it may not make sense for that index.  This is why I agree with @isoutamo about avoiding search filters.

[splunklearner]

@richgalloway then how can I achieve this requirement please let me know. I don't have any coding knowledge at this moment. 

[richgalloway]

The only sure way to control access to data is by index.  Have a separate index for each set of access rules.

IOW, sources "123456" and "456789" should be in separate indexes and only roles that need access to the Source should have access to corresponding index.

[splunklearner]

@richgalloway but as I told we have nearly 200 config IDs and need to create 200 indexes which is very difficult to maintain? That is the concern here..

[isoutamo]

Still that is easier task than manage those search Filters 😉
I have managed more than 400 in one environment and when you are using Splunk Volumes for those it's not actually too big issue.

[isoutamo]

When we have roleA and roleB which have srcFilters 

• roleA: source=A
• roleB: source=B

Then splunk add those in every SPL queries which these users do like

• input: index=a foobar
• real SPL:  index=a source=A foobar 

then if user has both roles assigned to him/her 

• input: index=a foobar
• real SPL: index=a source=A AND source=B AND foobar

I suppose that this example opens your eyes how these srcFilters are working and where it leads.

[splunklearner]

real SPL: index=a source=A AND source=B AND foobar

I am confused here why AND will come. Do we have any documentation on this to prove this to our team mates?

[isoutamo]

I just checking this from https://docs.splunk.com/Documentation/Splunk/latest/Admin/Authorizeconf where you found this. It seems that currently you could select if this operation is AND or OR. This will helps and maybe these are currently more usable?

[default]

srchFilterSelecting = <boolean>
* Determines whether a role's search filters are used for selecting or
  eliminating during role inheritance.
* If "true", the search filters are used for selecting. The filters are joined
  with an OR clause when combined.
* If "false", the search filters are used for eliminating. The filters are joined
  with an AND clause when combined.
* Example:
  * role1 srchFilter = sourcetype!=ex1 with selecting=true
  * role2 srchFilter = sourcetype=ex2 with selecting = false
  * role3 srchFilter = sourcetype!=ex3 AND index=main with selecting = true
  * role3 inherits from role2 and role 2 inherits from role1
  * Resulting srchFilter = ((sourcetype!=ex1) OR
    (sourcetype!=ex3 AND index=main)) AND ((sourcetype=ex2))
* Default: true

[splunklearner]

@isoutamo So here default is true right? So will it take OR by default? 

When we have roleA and roleB which have srcFilters 

roleA: source=A roleB: source=B

Then splunk add those in every SPL queries which these users do like

input: index=a real

SPL: index=a source=A 

then if user has both roles assigned to him/her 

input: index=a

real SPL: index=a source=A OR source=B

so by default it will be OR right? Please confirm?

[isoutamo]

That’s also my understanding for it. Of course you should check what your environment have for it. Btool is good command to check it.

[splunklearner]

What and how to check in btool? Please guide me sir

[ITWhisperer]

You can put the restriction on the role (and assign the role to the relevant user) and this will work for source (amongst other fields).