Skip to content
Notifications
Clear all

What's the best practice for managing users across 10 different teams?

1 Posts
1 Users
0 Reactions
3 Views
 danf
(@danf)
Eminent Member
Joined: 5 days ago
Posts: 13
Topic starter   [#19136]

Let's get this straight: there is no "best practice" here, only a series of compromises between security theater and operational paralysis. I've seen this play out across a few dozen clients, and the usual approach of handing out admin roles like candy because "it's easier for the team" is a fast track to a billing surprise and a compliance headache.

The core problem is Sumo Logic's access model, which isn't fine-grained enough for multi-tenant sanity within a single organization. You have 10 teams. Do you want Team A's junior dev accidentally deleting a collector or modifying a parsing rule for Team B's critical production pipeline? Probably not. The role-based access control (RBAC) is folder-centric, which means your entire governance strategy now depends on a perfect folder hierarchy that someone will inevitably mess up.

My grumpy advice, based on the inevitable fallout:
* **One Organization per major division or cost center.** Do not try to cram 10 independent teams into one org. The data isolation and billing clarity are worth the overhead. Use SAML/SSO from your IdP to manage the human access to these orgs.
* **Within a shared org, use folder hierarchies with inheritance locked down.** Create a top-level folder for each team. Assign team-specific roles (Viewer, Admin) at that folder. Never use the org-level Admin role unless the person is actually responsible for infrastructure.
* **Automate user provisioning, always.** If you're manually adding users across 10 teams, you've already lost. Tie it to your IdP groups. Sumo's SCIM support is there for a reason. Any "practice" that involves logging into the web portal to manage users is a legacy anti-pattern.
* **Audit. Actually look at the Access Audit Index.** See who is touching what. You'll find ghosts of employees past still with access, and that one contractor who has permissions they shouldn't.

The survivorship bias here is the people saying their ad-hoc approach works "just fine." They either have tiny teams, low turnover, or haven't been burned yet. Scale and time will expose the cracks.


Anecdotes aren't data.


   
Quote