Provisioning and Deprovisioning
Teams handle provisioning and deprovisioning by linking an identity store to target apps and databases. This link creates accounts when people join and deletes them when people leave. Most teams start by mapping job titles to broad group roles. When these roles are too wide, one user can read or change sensitive production data. Old accounts also stay active if the sync fails or someone uses local keys. How provisioning and deprovisioning work in modern stacks A central directory acts as the
User Provisioning (SCIM) + Automated Deprovisioning: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
Teams handle provisioning and deprovisioning by linking an identity store to target apps and databases. This link creates accounts when people join and deletes them when people leave. Most teams start by mapping job titles to broad group roles. When these roles are too wide, one user can read or change sensitive production data. Old accounts also stay active if the sync fails or someone uses local keys.
How provisioning and deprovisioning work in modern stacks
A central directory acts as the main source of truth for all staff members. When HR adds a new hire, the directory makes a fresh user profile. The system reads the user's job title and team name from that record. Next, it assigns the person to matching groups inside the central directory. Those groups link to roles in cloud platforms, code tools, and data stores.
Sync protocols push this group data out to connected target apps on a schedule. The target app sees the new user and builds a local account for them. When a worker changes teams, the directory updates their group list right away. The sync process then swaps their old app roles for the new ones. If a worker leaves the company, HR marks their main profile as inactive. The directory then tells every linked app to turn off or delete that account.
Databases and servers often need extra setup beyond basic app sync tools. Admins might map directory groups to database roles or copy SSH keys to servers. Each step relies on clean group maps to keep user permissions tight and clear.
What native account sync solves and what it misses
Central account sync stops manual ticket work and cuts down on orphan accounts. Security teams can see which users belong to which high-level groups at any time. Auditors can check that former staff members lost their main login rights on time. It also helps new hires get their basic tools on day one.
Still, account sync only decides who can log in to a system. It does not check what a user does after the session starts. A developer who needs database read rights for one bug keeps that role all year. While logged in, that person can run a broad query and pull all customer emails. Native sync cannot rewrite phone numbers, card numbers, or national IDs in query results.
User Provisioning (SCIM) + Automated Deprovisioning: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, many data stores and servers still rely on shared local admin accounts. Directory sync cannot track who uses a shared password or an old local key. Once a user opens a session, native directory tools are blind to individual commands. Teams still face risks from bad queries, leaked keys, and wide standing roles.
Steps to keep user roles tight and clean
Start by making HR software the single trigger for all account life cycle changes. Map every group to a clear job need instead of a whole department. Split read roles from write roles in every database and cloud console you run. Never put shared admin passwords in team chat rooms or static config files.
Run monthly checks to find local accounts that bypass your central directory sync. Remove standing write roles from daily user profiles to stop bad commands in production. When someone needs to fix a live bug, approve single actions instead of full roles. Mask sensitive fields like emails and card numbers by rewriting matched fields in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the main difference between provisioning and deprovisioning?
Provisioning sets up accounts and grants roles when a worker joins or changes teams. Deprovisioning removes those roles and closes accounts when a worker leaves the job.
Why do orphan accounts still happen with automated sync?
Admins often create local database users or server keys outside the main directory. Because the central directory does not know about them, it cannot turn them off.
Does account sync protect sensitive data inside a database?
No, account sync only controls who can log in to the database. Once inside, a user with read rights can still pull raw emails or card numbers.