Restrict Index access

[mm12]

Hi ,

I  have a index sensitive_data that contains sensitive data. I want to ensure that ONLY one particular user with roles power, user has access to this index, but other users with same roles should not have access to this  particualr index.  How to do this reliably?

What have I done is I created a LDAP group and mapped the role with this group and allowed the index access to particular role. Please someone helps whether the approach is correct.

[role_power]
cumulativeRTSrchJobsQuota = 10
cumulativeSrchJobsQuota = 200
list_storage_passwords = enabled
schedule_search = disabled
srchDiskQuota = 1000
srchMaxTime = 8640000
rtsearch = disabled
srchIndexesAllowed = *
srchIndexesDisallowed = sensitive_data

[role_user]
schedule_search = enabled
srchMaxTime = 8640000
srchDiskQuota = 500
srchJobsQuota = 8
srchIndexesAllowed = *
srchIndexesDisallowed = sensitive_data

[role_sensitive-data-power]
cumulativeRTSrchJobsQuota = 0
cumulativeSrchJobsQuota = 0
importRoles = power
srchIndexesAllowed = sensitive_data
srchMaxTime = 8640000

[role_sensitive-data-user]
cumulativeRTSrchJobsQuota = 0
cumulativeSrchJobsQuota = 0
importRoles = user
srchIndexesAllowed = sensitive_data
srchMaxTime = 8640000

Thanks

[gcusello]

Hi @mm12,

if you want that only one user can access those index, you have to:

• create a new role,
• give access to your sensitive_data index only to the new role,
• create a new AD group containing only the user enabled to access the index,
• assign that role to that group.

Ciao.

Giuseppe

[Anton]

Hi @gcusello

However, the authentication is based on the connection order. So if this sensitive user is authenticated based on the first group based on order, he/she will only be able to have the role to see the index mapped to the first group. 

I asked Splunk support officially on this and they do not have any idea/solution on this. 

Regards,

Anton 

[gcusello]

Hi @Anton ,

as I said, you have to divide your data in two indexes:

• one with events containing sensitive data,
• another containing all the other events.

then you have two create a specific role to access this index (only this role is enabled to access this data), assigning this role only to the user to enable.

in this way, only the enabled user should access the index, even if it has also other roles.

The important thing is that you have a dedicated index for this because data access grants in Splunk are defined at index level.

Let me know (and at all the Community) what Support will say to you.

let me know if I can help you more, or, please, accept one answer for the other people of Community.

Ciao and happy splunking

Giuseppe

P.S.: Karma Points are appreciated 😉

Ciao.

Giuseppe

[Anton]

Hi,

Firstly, thanks for the fast reply however there are cases where the users are required to access both sensitive and non-sensitive indexes at the same time using the same user. 

Another concern is on the scaling factor.  

Below is my scenario 

[PickleRick]

The short technical answer is that index access is granted on a per-role basis. So unless you have your roles configured so that a user is given a specific role depending on whether he's supposed to see that index or not, you can't do anything about it. It's simply how Splunk works.

But Splunk can perfectly well work with users having multiple roles assigned.

Multiple LDAP strategies and multiple roles are two different things. So if you need to manage two separate LDAP strategies - tough luck. If you have two separate authentication/authorization sources, you have to work it. But if you just want to separate roles, just include your users (or not) into two groups mapped to different roles and you're done.

[kfchen]

Hi PickleRick,

thanks for your insights. I am currently using multiple LDAP strategies and it is causing my alot of problems like Anton mentioned with the connection order. We are looking into possibly transition from managing multiple LDAP strategies to "one LDAP strategy, many LDAP group" but that would require alot of man power on our end. Would love to hear your thoughts on managing LDAP strategies vs LDAP groups. 

[isoutamo]

There are at least two major things what you must remember:

1. LDAP strategies are applied by ASCII order of their names
2. if account/group has found on strategy, but it haven't any access to resources (mappings) then it has used as no access. It don't try to found it any more from other strategies.

The 2nd one is something which could hit you quite easily and without any real warnings.

[PickleRick]

Yep. As @isoutamo said - only one LDAP strategy is effective at any given moment for a particular user. So different strategies are meant to be used if you have separate sources of authentication and authorization (when - for example - your company has two separte divisions, each with its own AD environment).

You don't want to configure separate strategies just to authenticate different groups from the same authentication source. That should be done by managing group (and thus associated role) membership.

[isoutamo]

Hi

as other already said when you inherited roles which have some index access and especially when they have disallow etc. you are in deep s...t when you try to guess what are the final combined access.  Usually you cannot do it that way!

On last conf there was excellent presentation about how to manage RBAC on splunk. https://conf.splunk.com/watch/conf-online.html?search.event=conf23&search=PLA1169B#/ You should read & listen that presentation and after that you are understanding better that problematic and how to fix it.

r. Ismo

[gcusello]

Hi @Anton ,

at first never use inherited roles because you have the same grants of the original role and you loose control on grants!

Then you have to create two indexes:

• one containing only events with sensitive data, accessible only from a dedicated role not from the others,
• a second one containing all the other events accessible both from the below dedicated role and the other enabled roles.

in this way the special role can access all the events in both the indexes (sensitive and not sensitive), instead the others enabled roles can access only the public events index and not the sensitive events index.

Ciao.

Giuseppe