Security

Restrict Index access

mm12
Explorer

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
 
 

 

 

Labels (1)
Tags (1)
0 Karma

gcusello
SplunkTrust
SplunkTrust

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

0 Karma

Anton
Explorer

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
SplunkTrust
SplunkTrust

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

0 Karma

Anton
Explorer

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 

User management.jpg

Tags (1)
0 Karma

PickleRick
SplunkTrust
SplunkTrust

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
Engager

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. 

0 Karma

isoutamo
SplunkTrust
SplunkTrust

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
SplunkTrust
SplunkTrust

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
SplunkTrust
SplunkTrust

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

0 Karma

gcusello
SplunkTrust
SplunkTrust

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

Get Updates on the Splunk Community!

Database Performance Sidebar Panel Now on APM Database Query Performance & Service ...

We’ve streamlined the troubleshooting experience for database-related service issues by adding a database ...

IM Landing Page Filter - Now Available

We’ve added the capability for you to filter across the summary details on the main Infrastructure Monitoring ...

Dynamic Links from Alerts to IM Navigators - New in Observability Cloud

Splunk continues to improve the troubleshooting experience in Observability Cloud with this latest enhancement ...