Concept Contrast Fable

Access control and the principle of least privilege: one is the lock on the door, the other tells you how many keys the lock should have

Conclusion first:Access control is a set of mechanisms—accounts, roles, permissions, authentication—used to decide who can access what resources. The principle of least privilege is a security design concept requiring every subject to have only the minimum set of permissions necessary to complete its work. Access control can still operate without the principle of least privilege—doors can still be locked—but after locking them you will find that everyone has a key and every key can open every door.

Access control is a set of mechanisms—accounts, roles, permissions, authentication—used to decide who can access what resources. The principle of least privilege is a security design concept requiring every subject to have only the minimum set of permissions necessary to complete its work. Access control can still operate without the principle of least privilege—doors can still be locked—but after locking them you will find that everyone has a key and every key can open every door.

Fable

The money house's iron vault had twenty-four locks, and the master handed out only six keys

The Huaizhou Tongbao money house had an underground iron vault: three outer doors and one inner door, each with a different lock. The money house employed twenty-four clerks, and each held a set of keys—because when it was first built, the manager said: for convenience, issue one master key that opens all three outer doors and the inner door. After six months, with twenty-four master keys in twenty-four hands, the iron vault was about as secure as no lock at all.

The first thing the newly appointed chief steward Uncle Gu did after taking over was collect the keys. He removed all the old locks and replaced them with four sets of locks of different designs. Then he spent a month drawing up a "permission registry." Xiao Chen in the accounts room could only open the first outer door to get the ledgers; Master Zhao the silversmith could enter the first and second outer doors, but absolutely not the inner door. Porters entering the first door had to be accompanied by a steward. In the end, only Uncle Gu himself and one deputy steward could enter the inner door.

The clerks protested collectively: before, one key could go anywhere; now even walking around required someone to open a door, slowing work down. Uncle Gu brought out a barrel of tung oil and a stack of documents, collected all twenty-four old keys, soaked them in oil, and sealed them away as scrap iron. Then he opened the register and said: your previous rights were not 'convenience,' they were 'vulnerabilities.' If a gang of thieves kidnapped anyone in this money house and got a key, the whole vault would be emptied—because every key in each person's hand was identical to the vault keeper's.

Uncle Gu wasn't saying "don't lock it"—he was redefining, on the basis of the lock, who holds keys, what keys they hold, and why they may. His approach never denied the value of door locks; the locks on all four doors remained intact. But he changed key distribution from "everyone gets a master key" to "each person has exactly what they need."

There was one detail Uncle Gu insisted on: permissions in the register must not say "can enter the warehouse"—they must say "first outer door: Monday to Friday, 7 AM to 7 PM, retrieve ledgers." Time, space, and purpose—all three elements were indispensable. If the bookkeeper needed to get ledgers, he shouldn't be able to touch the silver chest along the way; if a porter needed to move wooden crates, he shouldn't know where the inner door key was kept.

Half a year later, the money house suffered a theft. The thief climbed over the back wall but only got through the first outer gate. Because he did not have the key to the second gate, he was caught on the spot by the patrol. If it were still the old system with one master key, the four gates would have been just a few extra steps for this thief. After this spread, three nearby money houses sent people to learn Uncle Gu's permission register, but in the end they were not learning how to make locks—lock technology had always been advancing—the key was learning the principle of issuing keys.

Later, when Uncle Gu checked the register, what he always asked was never "Is the lock sturdy?" but "Why was this key given to this person?" The lock governs whether one can enter; the principle for issuing keys governs whether one should enter. No matter how good the lock is, if everyone has a master key, the iron vault still has no boundary.

Access control

A combined mechanism for identity authentication, authorization decisions and access enforcement, including user management, role definition, permission assignment and policy enforcement. It defines "where the door is and what the lock looks like," and it sits at the execution layer.

Principle of least privilege

A security design principle requiring every subject to receive only the minimum set of permissions necessary to complete the task. It does not prohibit granting permissions; the key is that the answer to "why is this permission needed" must hold up every time. It is a design principle, not a specific tool.

Story Mapping

Twenty-four master keys: there is an access control mechanism but permissions are completely out of control—the lock is still there, but keys are everywhere
Uncle Gu collects keys and changes locks: implementing the principle of least privilege—not denying the value of locks, but redistributing keys
The three elements of a permission register (time, space, purpose): the design prototype for modern fine-grained permissions
Workers Protest That the Job Is Slow: The Eternal Tension Between Safety and Convenience—Least Privilege Usually Adds Friction
The thief was caught as soon as he entered the first door: the layered defense effect of least privilege in a real attack
Neighboring money houses came to learn the principle of issuing keys: least privilege is a design method, not a set of lock products
IAM role configuration disaster: the classic mistake of having access control but violating least privilege

Apply this to cloud platform permission auditing and role design

When doing an IAM permission audit, do not just look at which policies a role is bound to—check each user's policy union and ask: “Does he actually use this permission?” If a designer has SQL console permissions but never logs in, then no matter how well-written the policy itself is, this authorization already violates least privilege. When creating a new role, start from zero permissions, and write a reason for each resource access added; do not start from a broad default template and delete downward—until you forget to delete that one entry. Every time an employee changes roles or leaves, a permission convergence audit must be done to reclaim all excess authorizations accumulated over time in one pass.

Access control Principle of least privilege