Security

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

markuxProof
Path Finder

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

diagram

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?

0 Karma
1 Solution

martin_mueller
SplunkTrust
SplunkTrust

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.

View solution in original post

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

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.

0 Karma

markuxProof
Path Finder

Hi Martin,

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

0 Karma

aaraneta_splunk
Splunk Employee
Splunk Employee

@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!

0 Karma

koshyk
Super Champion

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

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

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?

0 Karma

ddrillic
Ultra Champion

Are you asking me Martin?

0 Karma

martin_mueller
SplunkTrust
SplunkTrust

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

0 Karma

markuxProof
Path Finder

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

0 Karma

ddrillic
Ultra Champion

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

0 Karma

dflodstrom
Builder

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

0 Karma

markuxProof
Path Finder

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

0 Karma
Get Updates on the Splunk Community!

How to Monitor Google Kubernetes Engine (GKE)

We’ve looked at how to integrate Kubernetes environments with Splunk Observability Cloud, but what about ...

Index This | How can you make 45 using only 4?

October 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with this ...

Splunk Education Goes to Washington | Splunk GovSummit 2024

If you’re in the Washington, D.C. area, this is your opportunity to take your career and Splunk skills to the ...