Skip to content
Levitsky Concept
Initializing systems000%
Левицкий Концепт
All articles
Security

Access rights: why "everything for everyone" ends badly

June 30, 2026· 8 min read

In the first month of a system's life, rights are handed out quickly and generously — you have to launch, there is no time to sort it out. A year later it turns out that an intern can delete a multi-million rouble deal, a courier can see purchase prices, and three former employees still have active access. This condition is called permission creep, and it builds up unnoticed.

The principle of least privilege

The wording is simple: everyone has exactly the rights their tasks require and not one more. The point is not distrust of people — it is limiting the blast radius. If a manager's account is compromised through phishing, the attacker gains access to exactly what that manager could reach. The difference between "their own 40 clients" and "the entire base of 20,000 records" is the difference between a nuisance and a catastrophe with a multi-million rouble fine.

How permissions creep

  • A new employee is given a copy of a colleague's rights, and that colleague already had more than they needed — the error propagates.
  • Rights are granted for a one-off task and never taken back.
  • On transfer to another department, new rights are added without the old ones being removed.
  • An outside contractor is given full access "to avoid the hassle" and keeps it after the work ends.
  • Technical and integration accounts are created with maximum privileges because that is the fastest way to get running.

A role model in practice

Rights attach to roles rather than people, and roles attach to job positions. Onboarding and transferring an employee then becomes a single action instead of an investigation. A minimal set of roles for a typical company: employee (their own records), team lead (the group's records and reports), finance (payments and purchase prices), administrator (settings, without access to deal contents), auditor (read-only plus logs). We build this model in during CRM and ERP implementation — reworking it on a live system with accumulated data is considerably more expensive.

Separation of duties

A separate principle that is often ignored: critical operations should not be carried out by one person from start to finish. Whoever registers a counterparty should not also approve a payment to them. Whoever administers the system should not be able to quietly edit the log of their own actions. This protects not only against malice but against ordinary mistakes — a second pair of eyes catches a typo in the bank details before the money leaves.

What to do about administrators

A fully privileged account is rarely needed but constantly used, because it is convenient. The working practice: an administrator has two accounts, an ordinary one for day-to-day work and a privileged one for specific operations, with a mandatory second factor and a log entry. Check integration service accounts separately: they almost never need delete rights, yet they are granted by default. The classification of access control failures and the ways to test for them are covered in detail by OWASP.

Regular review

A one-off setup does not hold — team composition and tasks change. Once a quarter each department head receives a list of their staff with their rights and confirms or trims it. It takes 20 minutes per department and clears out 90% of the accumulated clutter. As a separate item, reconcile the list of active accounts against the staff roster: this is exactly how access left behind by departed employees is found.

A checklist to run today

  • How many users have full administrator rights? There should be no more than two or three.
  • Are there active accounts belonging to people who no longer work at the company?
  • Can a rank-and-file employee export the entire customer database with one button?
  • Is an activity log kept, and is it protected from being altered by the administrator?
  • Is contractor access revoked once a project ends?

Every point you answered with hesitation is an open door. Building a role model on an existing system takes one to three weeks depending on the number of objects involved. To see what this looks like in real products, take a look at our portfolio or discuss the task directly.

Need help with a project?

Let's discuss your task and propose a solution — from a website to SaaS and security.

Get in touch