What is your Enterprise Roles/Capabilities and Authentication Strategy?

[paimonsoror]

I was hoping to pick the brains of the community here to see what larger companies are doing when it comes to roles/capabilities and authentication.

I inherited Splunk at my company, as well as about 100+ ldap groups along with it. Essentially the way that the previous admins handled authentication and data onboarding is as follows:

• Each group that comes to us to onboard data gets an index, or several depending on the data we are ingesting
• That group gets 4 LDAP groups created for them, 2 'user' level groups, and 2 'power' level groups, one for our test environment, and one for the production environment
• That LDAP group, only has access to the index that the group owns
• The group selects a primary owner of the LDAP group, and a secondary owner of the LDAP group
• That group handles the approval of new users to the ldap group

After speaking to a few people at conf, I realized that this might not be the best strategy as it really silo's the data and prevents data collaboration. For users to access other indexes, they need to request to be added to the appropriate ldap groups for that data. That request could take several days.

Another problem that we have encountered with this is that suddenly various groups have added splunk related LDAP groups to their 'onboarding roles'. That means as new people enter their team, they suddenly have either usr or power roles into splunk, without really either needing it, or having proper training.

I was wondering what other enterprise users are doing when it comes to authentication. In my head I imagine just a handful of roles, each with a different level of access. For example, a very very low level role that has low search limits, and access to non-sensitive indexes. We then have different ldap groups for different 'levels' of access, and depending on what data each index has, that index belongs to a certain level (imagine a bronze, silver, gold) level access. The top-most group I imagine would be the one that has access to nearly all data, which would probably be our network and security teams.

Any and all input would be useful!!

[ddrillic]

We pretty much follow what you described and we have around 100 integral groups.

About -

-- After speaking to a few people at conf, I realized that this might not be the best strategy as it really silo's the data and prevents data collaboration.
I think that in a large fragmented (typical) company, the siloing phenomenon is common. I wouldn't fight it and just accept it as reality ; - )

-- For users to access other indexes, they need to request to be added to the appropriate ldap groups for that data. That request could take several days.

In these cases, we add the additional indexes to the proper roles, so the roles get to be cross-groups.

-- Another problem that we have encountered with this is that suddenly various groups have added splunk related LDAP groups to their 'onboarding roles'.

This is not easy. One thing we tried (without much success) is to ensure that anybody who is being added to these Splunk's specific ldap groups gets, ahead of time, the proper classes.

[paimonsoror]

Thanks for the response. So it sounds like we are on the right track here and just need to be a little more strict on the management and ownership side to make sure that global groups comply with our standards.

[ddrillic]

I think so - I believe in most large organizations, this is the approach taken. So, right, please go ahead and also please let us know because we all wonder how to improve on this base approach.

[coltwanger]

We've got pretty strict access rules. We have an index for each in house developed application, one index for staging, and one for production data. (approx 100 indexes). We have an index for each infrastructure "type" (cisco, aruba, paloalto, f5, checkpoint, etc.). We planned it this way because we were not sure how we wanted to handle accesses to data in the future, and since that's determined on a per index basis, we split it all out per index.

For larger user groups (Windows Server Admins, Linux Server Admins, Network Engineers), we have generalized Active Directory groups made for them. Think: "EnterpriseWindowsAdmins", "EnterpriseNetworkEngineering", etc. Users have their managers submit an access request (ticket) to our Access Management team (as an enterprise, we require manager approval for access to AD groups). We then put in place secondary approval by the Splunk Administrators. So we review and approve/deny all access requests to Splunk data for validity.

These AD groups are then mapped to a Splunk role which provides access to indexes for devices that group happens to manage. For example, the "EnterpriseNetworkEngineering" team will get access to the following indexes:

• cisco
• f5
• checkpoint
• paloalto
• aruba

But they would not get access to:

• windows
• internal app-specific indexes
• ids/ips indexes

The thought process is that they have a work-related need to access the data for the devices they manage (and technically they can access it already with admin access to these devices, Splunk is just now centralizing their data). They do not have a work-related reason to access device logs that they do not manage.

Occasionally, there is the one-off where someone from the Windows Server team may be assisting in troubleshooting a network device, or has a legitimate need that we validate to view data for that device. For this, we'll create an index-specific AD group (ex: SplunkF5Index)and process it the same way (manager approval, submits the ticket, secondary Splunk admin approval). We map that to a role in Splunk which gets access to only that index.

No users are granted Power capabilities at this time, and the Splunk team handles all "help" requests like dashboard/report creation, app installations and general help with SPL. We also are the only team that onboards data into Splunk.

For reference, we're a 350GB/day shop with about 1100 forwarders and an 8 year retention period. We've had Splunk in house for one year. We don't have a lot of technical teams that need access to Splunk, so the administration from the group/role side is pretty minimal. I approved two accesses this month to an existing group for new hires to that team. We don't provide any training and link them to the Splunk basic virtual training and most users can take it from there. Occasionally I'll look through the search history and if there's something outlandish I may shoot them an email to help them make their searching more efficient.

[paimonsoror]

This is great, it actually sounds like you are doing something very similar to the way we are, minus that we are providing power user access (which im not too fond of since it doesn't give me a chance to vet out these users before they get the power user rights).

Thanks for your quick response, looking forward to hearing what others have to say as well.