How to restrict access to one certain index without changing all the other roles?

[neiljpeterson]

The use case seems simple enough:

Lets say we have index sensitive_data that contains... sensitive data. We want to ensure that ONLY role data-team has access to this index. How to do this reliably?

---

There are a few ways to achieve this, but none are reliable or convenient:

• We could edit our [default] role in authorize.conf to include all the other indexes, but exclude sensitive_data This is not a great approach for a few reasons:
  • It adds extra overhead: Adding a new index for general consumption has an additional step (add the new index to the white list)
  • It is error prone: Everyone who admin user permissions needs to know NOT to use All internal indexes because you could inadvertently expose the sensitive_dataindex.
  • We could of course set up scripting to deal with the extra step, and alerting to catch the occasional whoops. But those are just hacks.
  • We could use a search filter to to say index!=sensitive_data and add that to our [default] role (This approach is not recommended for some reason, I have not experimented with it personally. I am curious to know why, or what problems this could cause.)
  • We could index this sensitive data on a separate indexer. (Our forwarders would then be tied to that indexer specifically.)

---

Ideally, we could restrict access to an index such that no other settings could override this restriction, either inadvertently or otherwise, unless it was clear to the admin making the change what the effect was.

I found several other answers here that deal with this question but none are very current, so I thought it would be worthwhile to bring it up again.

• http://answers.splunk.com/answers/170362/how-to-restrict-user-access-to-a-new-index.html
• http://answers.splunk.com/answers/80812/what-is-the-precidence-for-excluding-an-index-from-a-role-us...
• http://answers.splunk.com/answers/32940/restrict-index-access.html

Does anyone know a better way of doing this? Is it Splunk's express intention that Splunk not contain highly sensitive data where its exposure would amount to a critical breach?

I'm sure there are Splunk customers that deal with PII, PCI, HIPPA, SOX extra, so how do you guys deal with this issue?

Thanks in advance

[lemmons2]

I have the same question and so I was wondering if anyone has any updates on this?
I would like to set up a standalone search head to allow access to a sensitive-data index, and then set up my other search heads (1 cluster, several other standalones) so they CANNOT search on this sensitive data index at all.

[Richfez · Accepted solution]

I opened a case on this just last week, it's almost like you were reading my mind (or vice versa)!

The answer I received back was that at the moment they have nothing in place apart from the suggestions you have already listed, and they suggested the search filter method. I didn't really like that answer a lot, but I guess it'll work. It just seemed like a hack to restrict via search filter access to an index when granting access is applied directly at the role level on the indexes. It isn't like you create a searchfilter = index=index1 OR index=index2... for the role..

So, I suggested they add a srchIndexesDisallowed line. There would be precedence required, in that this overrides srchIndexesAllowed=*, but would not override srchIndexesAllowed=index1,index2,index_secret.

I think with srchIndexesDisallowed line added to the existing srchIdexesAllowed line, you would have all the flexibility you need.

[Richfez]

Good News!

It appears that in Splunk Enterprise 8.1 they have added this.

Direct quote from authorize.conf for version 8.1+ (just search for it in there):

srchIndexesDisallowed = <semicolon-separated list>
* A list of indexes that this role does not have permission to search on or delete.
* 'srchIndexesDisallowed' takes precedence over 'srchIndexesAllowed', 'srchIndexesDefault'
  and 'deleteIndexesAlowed'. If you specify indexes in both this setting and the
  other settings, users will be unable to search on or delete those indexes.
* Follows the same wildcarding semantics as the 'srchIndexesDefault' setting.
* If you make any changes in the "Indexes" Settings panel for a role in Splunk Web,
  those values take precedence, and any wildcards you specify in this setting are lost.
* No default.

[vasial]

@Richfez, just FYI
Looks like srchIndexesDisallowed was added but doesn't quite work as you wished ( in my experience atleast 😞

https://community.splunk.com/t5/Security/Restricting-index-access-with-srchIndexesDisallowed-overwri...

[chrismorris]

I was hoping I could define an index in an app and restrict visibility to the index using default.meta. When I looked for the indexes under settings it isn't there.

When I look at indexes in the index section there are no controls around permissions. This sort of configuration would be a tremendous help.

[dd_msearles]

It seems odd this doesn't exist...

[neiljpeterson]

Nice one @rich7177! I like your suggestion the best! Simple and obvious.

[ericg57]

Is this suggestion now an option with splunk 6.5.1? Curious to try it out.

[FritzWittwer_ol]

We have chosen the solution with whitelisting, e.g. each role has only access to a certain index, or a few Indexes, but there is no role except the admin role which has Access to all Indexes. For us this was the only solution as we have disperse user groups with different kinds of more or less sensitive data.
We decided against the solution with search filters as it does not seem to be robust enough, although we know from at least know big company in the financial sector which does use search filters, and feeds them from an external database as their rule set is enormous complex.
Of course we have been in a much simpler position as we did this from the beginning, so it was no big deal.

[neiljpeterson]

It would really nice if one of the following was an option:

• Be able to negate a wildcard pattern for srchIndexesAllowed (in authorize.conf) like

  srchIndexesAllowed= ;NOT sensitive

• Be able to define or redefine a regex pattern that makes up All internal indexes and All non-internal indexesand have that be revaluated whenever indexs.conf changes

  [indexgroup_all-non-sensitive]
  name = All internal indexes
  indexes = [^s].*