Tips for grouping users
The following are a few tips for grouping users in the database management system (DBMS):
- Create separate groups (roles) for system and object privileges. This enables the database administrators (DBAs) to manage privileges for the system roles and data owners to grant privileges to the object roles exclusively.
- Choose a naming convention that reflects each type of group (role) for easy reference. For example, for a group that will be able to edit all the landbase data, you could name the group LANDBASE_EDITORS.
- Grant privileges directly to the ArcSDE administrator user and grant privileges via groups (roles) for all other users. The ArcSDE administrator user is a unique entity. In most cases, only one such user exists for any database, and it is not part of a larger logical group of users. Experienced DBAs consider it good design to grant privileges directly to such application administrator accounts. By contrast, accounts for end users should receive privileges through groups that represent their job description, project responsibilities, or other logical classification within the organization.
- Avoid mixing roles with directly granted privileges for end user accounts. When end user accounts receive privileges through both roles and direct grants, a well-planned security model can quickly devolve into an unmanageable mess, requiring considerable time and effort to restore to an organized state. Set policies for data owners to follow when granting access to their schema objects.
In the rare case that an end user has truly unique security requirements, consider granting some privileges directly to avoid complicating the role-based security model. Document these cases; they should be the exception rather than the rule.