Referencing Users and User Groups in Security Policies
A user is the actor who accesses network resources, serving as an important identifier of network access behavior. As a result, users can be important for firewalls to perform network access control.
When user management and authentication are deployed on a firewall, the firewall can identify IP addresses of network traffic as users and record the mapping between users and IP addresses in the online user table. Configuring security policies based on users is essentially applying security policies based on the IP addresses of the users. User-based security policies improve the usability and accuracy of access control.
- Setting of users and user groups reflect the real organizational structure. User-based access control meets real service requirements and is easy to understand, improving policy usability.
- The online user table records the IP addresses used by users in the current login state. The IP addresses are fixed and prevent access control issues in scenarios where IP addresses dynamically change.
User Organizational Structure
The user organizational structure on a firewall is a mapping of the actual organizational structure in the society. It is the basis for user-specific access control. The user organizational structure contains two types of user objects in two dimensions, as shown in Table 3-2.
Organization Dimension |
Practical Significance |
User Object |
Applicable Scenario |
|---|---|---|---|
Vertical |
Real organizational structure |
User group/User |
A user belongs to a user group (department), which reflects a typical tree structure and the subordinate relationship. Administrators can create user groups (departments) and users based on the organizational structure, which is easy to query and locate. |
Horizontal |
Logical grouping |
Security group |
Logical groups across multiple departments are based on security levels or service access permissions, meeting management requirements. Some third-party authentication servers have similar horizontal groups, which correspond to security groups for interconnection. |
In other words, user group – user shows a vertical organizational structure, which reflects the ownership of users. A security group is a horizontal logical structure, which reflects the security level and service access permissions. Security groups have two typical application scenarios:
- Cross-department groups can be created based on projects. Access control policies can be configured for users from different departments who are added to the same security group.
- An enterprise has adopted a third-party authentication server and enabled horizontal groups (such as security groups on the AD server and static and dynamic groups on the SUN ONE LDAP server). To configure policies based on these groups, the administrator needs to create security groups with the same organizational structure as that on the authentication server.
For details about the principles and configuration methods of users, user groups, and security groups, see the product documentation.
Referencing users, user groups, or security groups in security policies.
When a user group, security group, or user is referenced as a matching condition of a security policy, the user has all access permissions of the user group and security group to which the user belongs. Note that when a user group and a security group are referenced in a security policy, the inherited policies of the user in the two groups are slightly different.
- User group: Affiliated users in a user group and users in all lower-level user groups inherit the security policies and access permissions of the user group.
- Security group: Only affiliated users inherit the security policies and access permissions of a security group. Users in sub-security groups do not inherit the security policies and access permissions of their upper-level security groups.
However, when you need to configure special permissions in addition to the inherited policy permissions for a user – user group, the inheritance of security policy permissions based on the user – user group will be invalid. Take Figure 3-2 as an example. Assume that all employees in the R&D department have the same basic access permission (resource A) and R&D department 1 has a specific permission (resource B).
In this scenario, you need to configure security policy A to allow R&D employees to access resource A. Besides, the security policy B also needs to be configured for the specific permission of R&D department 1.
First, according to the matching rules of security policies, security policy B for R&D department 1 must be placed before security policy A. Otherwise, the access requests of the users in R&D department 1 match security policy A and do not continue to match security policy B. Therefore, the users can only obtain the permissions to access resource A.
Second, both resource A and resource B must be specified in security policy B. According to the matching rules of security policies, the access requests of users in R&D department 1 match security policy B and does not match security policy A. The users can obtain only the access permissions specified by security policy B. That is, in this scenario, the child security groups cannot inherit the access permissions of the parent security groups.
Table 3-3 shows the correct security policy configurations.