What is the difference between system access and data access control?

System access control (Zugangskontrolle) governs who may use a system at all; it acts at log-on. Data access control (Zugriffskontrolle) governs what an identity that is already signed in may do with the data: read, change, delete, export. Ahead of both sits physical entry control (Zutrittskontrolle), which restricts entry to rooms.

What is the difference between RBAC and ABAC?

With RBAC, rights attach to roles to which users are assigned; that is clear and easy to audit. With ABAC, a rule set decides on the basis of attributes such as department, data classification, device state or time of day. ABAC is more fine-grained and more flexible, but harder to maintain and harder to audit. The two are often combined.

Does the GDPR require access control?

Art. 32 GDPR sets out no list of measures; it requires a level of protection appropriate to the risk. Restricting access to what the task requires is in practice almost always part of that where personal data is involved, and it is a standard item in supervisory examinations. How it is designed follows from the risk to the data subjects.

How often should access rights be reviewed?

There is no statutory deadline. A full recertification at least annually is common, with a shorter cycle for privileged accounts. Independently of that, rights have to be adjusted as events require: a move between departments, a change of role, a longer absence, and on leaving.

Is a role concept enough without logging?

No. Without logging it is impossible to reconstruct after an incident who accessed which data, and the effectiveness of the rule remains unevidenced. Logs should themselves be access-protected and not alterable by the people being monitored. How they are evaluated has to be agreed in advance with data protection and employee representatives.

How do you keep access rules current across many systems?

Through classification rather than a maintained list. In Rizzqo an asset picks up the access control requirements held for its category, and the list adjusts when the classification changes. Answers and evidence sit on the object, and the protection need inherited from the processes it carries sets the yardstick for appropriateness.

Access Control: Levels, Models, Weak Points

Access control is the measure that appears most often as a cause in security incidents, usually not because it was absent but because it was never brought up to date over the years. It consists of three parts that only work together: a rule, its technical enforcement, and evidence that it was observed.

Zutritt, Zugang, Zugriff

German professional usage distinguishes three levels that English collapses into the single term access control. The three-way split comes from the annex to the former Bundesdatenschutzgesetz; the GDPR did not carry it over, but it remains in common use in German practice and travels well in audits. Anyone dealing with German auditors will meet all three words.

Level	Protects against	Typical controls
Zutrittskontrolle (physical entry)	unauthorised entry to rooms and buildings	locking systems, badge readers, visitor rules, security zones
Zugangskontrolle (system access)	unauthorised use of systems	authentication, multi-factor methods, screen lock, network segmentation
Zugriffskontrolle (data access)	unauthorised reading, alteration or deletion of data	role and entitlement concept, tenant separation, logging

The distinction is more than terminology. An attacker who defeats system access meets data access as a second layer, provided it has been differentiated at all. Where every signed-in user can see everything, one account brings down the entire estate.

Models

Model	Principle	Suited to
DAC	the owner of an object grants rights themselves	small environments, file shares; hard to evidence
MAC	centrally imposed rules that users cannot change	high confidentiality requirements, self-contained environments
RBAC	rights attach to roles, users are assigned to roles	the standard in enterprise applications
ABAC	decisions based on attributes: user, object, context, time	dynamic and cloud environments, fine-grained rules

RBAC dominates today, supplemented by attribute-based conditions for context such as location, device state or time of day. More important than the choice of model is that roles are derived from tasks and not from what individuals have historically accumulated.

From rule to implementation

A sound approach runs to five steps: set the access rules in a policy, derive roles from business processes, establish a governed procedure for requesting and approving access, enforce the rights technically, and review what has been granted at regular intervals. The last step decides effectiveness: the other four can be done once, this one cannot.

Enforcement includes logging. Without a record of successful and rejected access to data that needs protection, neither can an incident be investigated nor can the effectiveness of the rule be evidenced. Logs themselves have to be access-protected and must not be alterable by the people being monitored.

Regulatory context

Art. 32 GDPR requires a level of protection appropriate to the risk; restricting access to what is necessary is one of the standard measures for that, and supervisory authorities ask about it routinely. ISO/IEC 27002 treats access control as a topic area of its own, with implementation guidance running from the access control policy through the management of privileged rights to secure log-on.

Typical weak points

Shared accounts whose actions cannot be attributed to a person
Administrative rights in the account used for everyday work
Rights added on a move between departments but never withdrawn
Far-reaching entitlements in test systems that hold production data
Service and interface accounts with no owner and no expiry date

How Rizzqo ties access rules to the system

An access rule does not apply to a company; it applies to a system. In Rizzqo the dispatch follows from that: once an asset is assigned a category and subcategory, the requirements held for that classification appear against it, among them the access control requirements from ISO/IEC 27002. Reclassify a system and its requirement list adjusts, with newly applicable requirements added and no-longer-applicable ones removed.

Each requirement is answered by the asset's owner, with a reason and evidence held on the object, a role concept or the outcome of a recertification for instance. Judging appropriateness rests on the inherited protection need: a system inherits it from the primary assets it carries, so the strictness of the rule is measured against what actually hangs on it.

Browse all entries Back to top

Access Control