Least Privilege

Least privilege gives an identity only the permissions needed for its assigned work. Permission includes both an operation and its resource scope: reading assigned orders is different from exporting every customer's records.

Reading does not authorize a refund

An assistant can have permission to read an order status while lacking permission to issue a refund. The application must evaluate the requested action separately. A prompt that asks the model to act as an administrator does not change that authorization.

Service identities also need limits. A broadly privileged service should not lend all its privileges to every user request.

The same principle on the network

Permissions are usually discussed as identity and action. A network rule is the same idea with different parameters, and it is the one most often left broad — because the broad version is what makes an urgent problem go away at 2am.

A network rule is narrow only in the parameters it actually constrains — the source, the destination, the protocol and port, and the direction — and each of those is a place where “temporarily” widens it. Allowing the application tier to reach the database on its one port is the narrow form; allowing the whole address range to reach anything on any port is the version that gets added during an incident and stays for two years.

Prefer identifying the source by what it is rather than where it happens to be — the security group or tag attached to that workload, instead of a subnet range that will later contain something else. An address-based rule silently starts applying to whatever is deployed into that range next.

Some rules genuinely have to be opened in a hurry, and what makes one recoverable afterward is that it arrives with an owner recorded on it, a stated removal time, and a recurring review that lists whatever is past that time. Without those, nobody can distinguish a deliberate exception from a forgotten one — and when that distinction is unavailable, teams tend to leave every rule in place because removing one that is still needed can cause an outage. That default keeps unneeded access open with no one accountable for it, so the unknown rules need an owner and a verification step, such as checking recent traffic or restricting the rule, before they are removed or renewed with an expiry.

Keep the two layers apart, because treating them as interchangeable is how a network change becomes an unnoticed data exposure. A network rule decides who can reach a service; the database’s own grants decide what a connection may do. Opening a path does not grant access to data, and closing one does not revoke it — so both layers need their own least-privilege decision, and a review of one tells you nothing about the other.

Keep the limit current

Deny requests without an applicable allowance, enforce checks in trusted services, and test allowed and denied cases. Remove permissions when work or membership changes. A hidden button is not enforcement if the operation remains callable directly. Record enough decision evidence to investigate failures without copying unnecessary sensitive content.

References

• OWASP Authorization