Smarter by Design.Simpler for Business
TR7Enterprise Application Delivery & Security Platform
What is the least privilege principle; how is it met in TR7 user management?
Short answer
The least privilege principle is giving each user and each account only the narrowest permission needed to do its job (NIST · Least Privilege). It ensures that, when an account is compromised or an incorrect operation is performed by mistake, the damage stays limited to that account's permissions. TR7's management user model is based on this principle (The Authorization and Access Model): User Type in the Device Users form determines the areas the user can access and the level, and the menus for which the user has no permission are hidden; in the Read-only User, Monitor User, Traffic User, WAF User and Traffic+WAF User roles, the user is limited to specific vServices with User vServices, and fields such as Backend Service Permission and Certificate Selection open additional permissions separately. In the Add form, User type comes as Admin by default and Access CLI over WEB is on; for this reason, for each user, the narrowest role suited to the job and only the access that is needed are selected deliberately. When Automatic User Creation is on, users created automatically at first login with LDAP, RADIUS or TACACS+, on the other hand, are assigned Read-only user by default.
Where It Is Used in TR7
| Where | Field / label | What for |
|---|---|---|
| Settings → User Management → Device Users | User Type | Selecting the narrowest role suited to the job |
| Same form | User vServices, Backend Service Permission, Certificate Management, Certificate Selection | Narrowing the vServices the role covers, and turning on the additional permissions within the role only when needed |
| Same form | Access CLI over SSH (off by default), Access CLI over WEB (on by default in the Add form) | Giving command line access only to those who need it |
| Settings → User Management → Device Users → User Management Settings | Automatic User Creation, Default User Type to Create (default Read-only user) | A user who logs in from an external source for the first time starting with the lowest permission |
| Settings → System Logs → User Logs | User Logs | Tracking how the granted permissions are used |
How It Is Applied in TR7
- A person who will only do monitoring is given the Monitor User or Read-only User role; if needed, the vServices the person can see are limited with User vServices (Can I define users who only have monitoring rights, or who can manage only specific vServices?).
- A person responsible for a single application is given Traffic User (Traffic+WAF User if WAF is also needed), and only the vServices of that application are selected in User vServices; Backend Service Permission and Certificate Selection are turned on only if needed (How do I make sure a user edits only the vServices assigned to them and does not touch Backend Services and certificates?).
- In daily work, task-specific roles are used instead of Admin; a second factor is added to management login with Two-factor Authentication (2FA) in Management Access.
Common Misconceptions
- "Giving the Admin role is more practical." Broad permissions enlarge the affected area in an incorrect operation or when the account is compromised; User Type is selected limited to the job.
- "Least privilege is set up once." As duties change, roles and scope fields are reviewed; the accounts of people who leave are removed.
- "Automatically created users come with permissions." The user created with Automatic User Creation is assigned the Default User Type to Create value; as long as the value is not changed, it is Read-only User. These users are created with Access CLI over WEB on; if it is not needed, it is turned off in the user's edit form.
How it is done in the documentation
