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:
authorize.confto include all the other indexes, but exclude
sensitive_dataThis is not a great approach for a few reasons:
All internal indexesbecause you could inadvertently expose the
index!=sensitive_dataand 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.)
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.
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
It would really nice if one of the following was an option:
Be able to negate a wildcard pattern for
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
name = All internal indexes
indexes = [^s].*
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.
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.
Nice one @rich7177! I like your suggestion the best! Simple and obvious.
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.
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.