How to restrict access to web access data based on user role?

[markuxProof]

Greetings,

I'm having trouble solving a problem. I need to restrict the viewing of web access data. The rules for viewing are as follows:

• Normal user: You can see only the data related to your accesses.
• User Manager: You can view your web access data and all your managed data.
• No manager can see data from another management.
• Managers who are managers of other managers can see both the data of these managers and the data of those who are managed indirectly by them.

I made this diagram for a better understanding

C1 - Your data and all of the company's data
D1 - View your data, M1 data and data of all members of G1
D2 - View your data, data of, M2, M3 and the data of all members of G2 and G3
M1 - View your data and G1 data
M2 - View your data and G2 data
M3 - View your G3 data and data
G1, G2, G3 - Each member only sees their data

I have not been able to do this through SPL so far because the amount of data is too large and the queries take a long time to finish.
Anyone have any suggestions?

[martin_mueller · Accepted solution]

Mkay... I'd split this into two problems.

First, you have a hierarchy of groups and managers. This can be mapped well with indexes and role-based assigment of indexes.
For each group Gn you'd create one (set of) indexes and a role. That role inherits capabilities from the default user role, all it contains on top is "this role may search the (set of) indexes for this group".
Then you remove all default index visibilities from the default user role. Else everyone would be able to search all non-internal indexes.
Now you map your AD groups to roles: Each Gn gets the Gn role, each manager of Gn gets the Gn role, each director gets all Gn underneath that director, and the C-level gets all Gn roles.

Now you know for certain that no Gn member can search a Gn+1 index, and you have that distinction implemented in a fast way. Any further inefficient dashboard-based restriction you build on top will only have to crawl through this subset of data, speeding up things massively.

[markuxProof]

Hi Martin,

Thanks for the answer. This seems to me the most correct solution.
I will implement this way.

[aaraneta_splunk]

@markuxProof - Did the answer provided by martin_mueller help provide a working solution to your question? If yes, please don't forget to resolve this post by clicking "Accept". If no, please leave a comment with more feedback. Thanks!

[koshyk]

The best way to do is to create "separate" indexes based on your organisational structure (say your company is ABC)
The indexes should be

ABC_network_ops
ABC_os_windows
ABC_os_linux
ABC_database_oracle
ABC_database_db2

etc. and pump your data into individual indexes.
ASsign role access to specific indexes. For example, if you want to give data to "DBA's" , give them "ABC_database*" in their role.

Naming convention is of utmost important. I never use "default" indexes of any app, but always use our own indexes with correct naming conventions. The only thing you need to design is to make in-line with your organisational structure

[martin_mueller]

Is this supposed to be a suggestion to users, e.g. a pre-built filter in a dashboard, or a secure hard limit to what they can search even if they tried?

[ddrillic]

Are you asking me Martin?

[martin_mueller]

I'm asking about the question itself. If you can answer, fine 😛

[markuxProof]

Hi martin_mueller,

I want to implement a strict insurance limit for what they can view. Search will only be allowed for administrators. I was thinking of implementing this limit of the second way:

(Index = cisco_wsa OR index = active_directory) | Eval term = case (user_login = $env:user$, user_login, user_login = manager, bunit) | Search (user_login = term OR bunit = term) | ...

But implementing this in all queries is very costly for Splunk since the huge mass of data

[ddrillic]

Very interesting. We had a cheerful discussion recently about a similar design challenge at Is my setup for authentication and access control on data within different indexes and same dashboar...

[dflodstrom]

Is all of this data in the same index? Do these users all share the same role?

[markuxProof]

dflodstrom,

The data is of different index:

• Active directory (ldap | collect)
• Wsa cisco (syslog)

Groups / Users come from AD through LDAP Authentication

No roles have yet been defined for these groups / users, but it would not be a problem if they had to share the same roles