3 Network Access Control
Learn how network access control connects identities and context to specific permissions, and how to design, enforce, and review reliable access policies.
Purpose and foundations
Network access control determines which users, devices, or services may use a resource, which actions they may perform, and under what conditions. Resources include network services, applications, devices, and data. The aim is to allow authorized activity while limiting unnecessary or unauthorized access.
An access request can be understood by identifying three elements: the subject making the request, the resource it wants to use, and the action it wants to perform. A subject may be a user, device, or service; a resource may be an application or data; and an action may be connecting, reading, modifying, or administering.
establishes or verifies identity. evaluates what that identity is allowed to do. must come before , but successful does not by itself grant permission to every resource.
Principles for managing access
Use : grant only the permissions needed for assigned tasks, and limit them to the necessary resources and duration. This principle applies to users and software services.
means that a request is denied when no rule explicitly permits it. This is easier to reason about than a default-allow policy that relies on exceptions.
Separate duties and administer permissions carefully. Avoid giving one account unnecessary control over both routine work and security administration. Review access when a person’s role or a resource’s requirements change. Logging and periodic reviews can help identify excessive or outdated access, and permissions that are no longer needed should be removed.
Rules must be enforced consistently by network devices and services to be effective. A policy can combine access models, such as assigning permissions by role and then applying device status or resource sensitivity as additional conditions.
Access-control models
An attaches permissions to a resource. For example, a file server or firewall might list the users, groups, addresses, or services allowed to perform particular actions.
assigns permissions to roles, then assigns users to appropriate roles. A HelpDesk role might be permitted to reset employee passwords but not change firewall settings. Roles simplify administration, but should remain narrowly defined.
evaluates attributes of the subject, resource, requested action, and possibly the environment against policies or rules. For example, a policy could permit a clinician to read a record only when it belongs to their care unit and the request comes from an approved device.
Applying permissions to network resources
A permissions plan describes who may do what for each resource. For example, an organization could apply these permissions to an employee portal, a finance database, and a network-management console:
Employee: Read and update their own profile in the portal; no access to the finance database or network console.
Finance analyst: Read and update assigned records in the portal and finance database; no access to the network console.
Network administrator: No access by default to the portal or finance database; administer the network console using a privileged account.
Network policy can add conditions to those permissions. For instance, database connections might be allowed only from the finance application server, and console administration only from a designated management network. A rule should specify the relevant source, destination, service or port, action, and any required conditions. More specific restrictions should not be accidentally overridden by broad permissions.
A corresponding set of rules could permit employees to reach the portal over HTTPS; permit the finance application server to reach the finance database on its required database service; and permit administrators to reach the management console only from approved management devices. Other connections to the database and management console can be denied, with denied attempts logged for review.
These restrictions narrow exposure. Employees do not gain database access merely because they can reach the portal, and a device’s presence on an internal network does not automatically authorize access. Network location alone should not create implicit trust; access is evaluated for the subject and the resource.
Writing and enforcing reliable rules
When writing or reviewing a rule, check that it answers these questions:
Who or what is requesting access? Identify the user, group, service, or device.
Which resource is protected? Be precise about the host, application, data, or network segment.
Which action is allowed? Distinguish reading data from changing it or administering a system.
What conditions apply? When appropriate, consider device trust, location, time, connection method, or resource sensitivity.
What happens when no rule matches? Prefer an explicit deny-by-default outcome.
How is access reviewed? Record decisions where appropriate and remove permissions that are no longer needed.
A evaluates applicable information and rules. A applies the resulting decision to the request. These functions may be implemented across identity systems, network gateways, firewalls, and applications.