The “User Account Lifecycle” defines the collective management processes for every user account. These processes can be broken down into Creation, Review/Update, and Deactivation—or “CRUD”. If your organization utilizes IT resources of any kind, you rely on user accounts to access them.
As any given account follows its own timeline according to a specific user, lifecycle management efforts frequently overlap. This overlap causes difficulties in environments relying on manual management where efforts must be replicated ad nauseam. The difficulties are exacerbated for large-scale organizations because of sheer volume. Set term lengths similarly complicate management for educational institutions and seasonal work.
Creation
Beginning on Day 1, every user must have an account to access their IT resources. User accounts contain identity information that determines access, similar to a digital passport. IT resources can be more general (e.g. Active Directory, email account) or more specific to that user’s role(s) (e.g. Adobe Creative Cloud, payroll system).
Account creation requires far more than typing a person’s name and email address. Most organizations will need to enter a user into their HR and payroll systems. The user will also need a directory account; this is an Active Directory (AD) account for most.
Users still require permissions and group memberships, which determine access rights to various folders and shares within the network. You wouldn’t want every employee to have unrestricted access to a cabinet of each other’s HR files. Similarly, you wouldn’t want those same files stored on the network without protection. Network permissions and group memberships are further complicated by the different levels within the file system’s hierarchical structure. Because it’s easier, some newly created users are given too much access.
Account creation continues with user provisioning. Does the user need access to Google resources (G Suite)? They’ll need that account set up. How about the organization’s Dropbox storage? They’ll need that one too. What about a CRM system like Salesforce? Individual account setup is not included. In modern business environments, software applications facilitate operations. Most enterprise software applications require user accounts.
Reviews & Updates
Access rights must be regularly reviewed to maintain a streamlined, compliant network. A user’s needs and permissions will change over time due to promotions, role changes, reorgs, or newly implemented IT resources. The accumulation of access rights is often referred to as “permission bloat”.
Permission bloat is inherently problematic as it makes determining who has access to what a nightmare—a massive compliance risk. Manually preventing permission bloat requires a near-perfect memory. You have to remember the access each role should have to compare against which users have what rights and permissions.
Manually reviewing and updating user accounts and their access rights requires communication between managers and IT staff. Access governance or role-based access control solutions maintain access rights according to a given user’s role configuration. The configurations for each role must still be maintained, however. Unnecessary access is merely a compliance violation, malfeasance, or an incentive for fraud waiting to happen.
Reviews and updates are the user account lifecycle’s most cyclical aspect. Theoretically, an organization’s review and update process never finishes. For example: by the time processes are “finished”, the first 20% of accounts have to begin this stage all over. The process, then, never really accomplishes more than 80% completion at any time. The 80%/20% example rings particularly true for manual efforts. Automated solutions may execute updates but still require configuration reviews to ensure each role remains compliant and secure.
Deactivation
When a user departs an organization, all of their associated accounts must be deactivated and deprovisioned. Security risks are the more obvious reason for following deactivation procedures. A malicious ex-employee can take sensitive data (e.g., client information, intellectual property, account credentials) or damage your environment in worst-case scenarios. Ex-employees may access your IT resources until deactivation—for days, weeks, months, or years. Stalled deactivation is especially dangerous for cloud-hosted resources.
The other primary reason for adhering to a standard deactivation process is to prevent the accumulation of “orphaned accounts”. Orphaned accounts are those no longer associated with an active user and remain in your environment. This digital detritus clutters your ability to accurately assess your environment while also taking up storage space. Further, should your organization be successfully attacked by a malicious intruder, orphaned accounts make perfect camouflage for them.
CRUD
The acronym “CRUD” stands for “Create, Read, Update, Delete”. CRUD operations refer to the 4 basic commands required for persistent storage and relational databases.i SQL commands respectively replace “Create” and “Read” with “Into” and “Select” for database tables.ii CRUD serves as an easy reminder for managing user accounts:
- Create: the creation of a user account and all of its necessary attributes (e.g. name, email address, permissions)
- Read: Displaying all user accounts and their attributes without changing any data
- Update: Overwriting existing user account attributes to make changes
- Delete: Removal of a user account and its attributes
i. https://searchdatamanagement.techtarget.com/definition/CRUD-cycle
ii. https://www.sqlshack.com/crud-operations-in-sql-server/