CRA Zugriffsschutz: Authentisierung, Identitäten und Berechtigungen sicher umsetzen

Der Cyber Resilience Act verlangt Schutz vor unberechtigtem Zugriff durch angemessene Kontrollmechanismen. Dazu zählen ausdrücklich Authentisierung, Identitäts- und Zugriffsmanagement. Hersteller müssen deshalb nicht nur einen Login anbieten, sondern den gesamten Lebenszyklus von Identitäten, Rollen, Sitzungen und privilegierten Zugriffen sicher gestalten.

Einordnung im CRA-Wissen: Dieser Fachartikel gehört zum Themenbereich Technische Produktsicherheit. Dort finden Sie die angrenzenden Anforderungen und eine praktische Reihenfolge für die Umsetzung.

Was verlangt der CRA beim Schutz vor unberechtigtem Zugriff?

Anhang I Teil I Nummer 2 Buchstabe d verlangt geeignete Kontrollmechanismen einschließlich Authentisierung, Identitäts- oder Zugriffsmanagementsystemen. Zusätzlich soll über mögliche unberechtigte Zugriffe berichtet werden können. Die konkrete Ausgestaltung folgt der Cybersicherheitsrisikobewertung.

Ein lokales Gerät ohne Benutzerkonten benötigt andere Maßnahmen als ein internetfähiges Administrationsportal. Entscheidend ist, welche Funktionen, Daten und Schnittstellen gegen welchen Angreifer geschützt werden müssen.

Was ist der Unterschied zwischen Authentisierung und Autorisierung?

Authentisierung klärt, wer jemand ist. Autorisierung bestimmt anschließend, was diese Identität tun darf. Beide Ebenen müssen getrennt geprüft werden. Ein sicherer Login verhindert keine Rechteausweitung, wenn ein normaler Benutzer anschließend direkt administrative API-Endpunkte aufrufen kann.

In der technischen Dokumentation sollte erkennbar sein, welche Identitätstypen existieren und welches Rollen- oder Berechtigungsmodell für sie gilt.

Welche Authentisierung ist angemessen?

Das hängt vom Risiko ab. Passwörter können für bestimmte lokale Szenarien ausreichend sein, sofern sie individuell und angemessen geschützt sind. Für hochprivilegierte oder entfernte Verwaltungszugriffe kann Mehrfaktorauthentisierung deutlich angemessener sein.

Der CRA schreibt nicht pauschal MFA für jedes Produkt vor. Hersteller müssen aber begründen können, warum der gewählte Mechanismus zum Risiko passt. Ein aus dem Internet erreichbares Adminportal mit schwachem Ein-Faktor-Zugang ist schwerer zu rechtfertigen als ein lokal isolierter Bedienzugang.

Wie geht man mit Standardpasswörtern um?

Universelle Standardpasswörter sollten vermieden werden. Sicherer sind individuelle Zugangsdaten, ein sicherer Onboarding-Prozess oder die verpflichtende Vergabe eines eigenen Geheimnisses bei der ersten Nutzung. Das ist zugleich ein wesentlicher Bestandteil von Secure by Default.

Auch versteckte Servicekonten, Wartungszugänge und fest eingebaute API-Schlüssel müssen erfasst werden. Ein nicht dokumentierter Herstellerzugang kann das gesamte Berechtigungskonzept aushebeln.

Was bedeutet Least Privilege?

Jede Identität erhält nur die Rechte, die sie für ihre Aufgabe benötigt. Das gilt für Endnutzer, Administratoren, Anwendungen, Hintergrunddienste, Container und Geräteidentitäten. Least Privilege begrenzt die Auswirkungen kompromittierter Konten.

Rechte sollten nicht dauerhaft aus Komfort erweitert werden. Für seltene administrative Tätigkeiten können zeitlich begrenzte oder ausdrücklich aktivierte Privilegien sinnvoll sein.

Wie sollte ein Rollenmodell aussehen?

Ein Rollenmodell sollte Funktionen statt Personen abbilden. Typische Rollen können Nutzer, Operator, Administrator, Auditor oder Service-Techniker sein. Für jede Rolle wird festgelegt, welche Aktionen und Datenbereiche zulässig sind.

Wie schützt man Sessions und Tokens?

Nach erfolgreicher Authentisierung wird häufig ein Session- oder Zugriffstoken zum eigentlichen Schlüssel. Deshalb müssen Lebensdauer, Speicherung, Übertragung, Widerruf und Rotation sicher gestaltet werden. Tokens sollten nicht in Logs, URLs oder ungeschützten lokalen Speichern landen.

Bei sensiblen Aktionen kann eine erneute Authentisierung sinnvoll sein. Nach Passwortänderung, Konto-Sperrung oder Rollenentzug sollten bestehende Sessions entsprechend behandelt werden.

Wie funktioniert sicherer Passwortreset?

Der Resetprozess darf nicht schwächer sein als der normale Login. Ein Angreifer sollte ein Konto nicht über leicht erratbare Sicherheitsfragen oder dauerhaft gültige Resetlinks übernehmen können. Tokens sollten kurzlebig, einmalig und sicher übertragen werden.

Auch Supportprozesse sind relevant. Wenn ein Helpdesk Passwörter ohne ausreichende Identitätsprüfung zurücksetzt, entsteht ein Social-Engineering-Angriffspfad außerhalb des eigentlichen Produkts.

Was gilt für Servicekonten und Maschinenidentitäten?

Produkte kommunizieren häufig mit Backends, APIs oder anderen Geräten. Auch diese Identitäten brauchen eindeutige Credentials, begrenzte Rechte und einen Lifecycle. Geteilte Geheimnisse über tausende Geräte erhöhen das Schadenspotenzial erheblich.

Wo möglich sollten individuelle Geräteidentitäten oder kurzlebige Credentials verwendet werden. Rotation und sichere Provisionierung gehören bereits in Secure by Design.

Wie schützt man Fernwartungszugänge?

Remote Support ist besonders kritisch, weil ein Herstellerzugang viele Kundensysteme betreffen kann. Fernwartung sollte nur aktiviert sein, wenn sie benötigt wird, starke Authentisierung verwenden, Aktionen protokollieren und klare Berechtigungsgrenzen besitzen.

Ein pauschaler „Masterzugang“ ist riskant. Besser sind kundenspezifische Freigaben, zeitliche Begrenzung oder explizite Aktivierung. Der Kunde sollte nachvollziehen können, wann ein Zugriff stattgefunden hat.

Wie werden APIs gegen unberechtigten Zugriff geschützt?

API-Sicherheit darf nicht allein auf dem Frontend beruhen. Jede serverseitige Operation muss Berechtigungen selbst prüfen. Direkte Objektzugriffe, Parameteränderungen und Funktionsaufrufe sind typische Wege für horizontale oder vertikale Rechteausweitung.

Tests sollten deshalb mit unterschiedlichen Rollen und fremden Objekt-IDs arbeiten. Ein sichtbarer ausgegrauter Button beweist keine Autorisierung.

Wie sollte das Produkt unberechtigte Zugriffe melden?

Der CRA nennt ausdrücklich die Fähigkeit, über mögliche unberechtigte Zugriffe zu berichten. Das kann lokale Warnungen, Security Logs, Administratorbenachrichtigungen oder Export an ein Monitoring-System umfassen.

Die Auswahl muss zum Produkt passen. Der Beitrag CRA Logging & Monitoring erläutert, welche Ereignisse und Daten sinnvoll sind.

Wann sollte ein Konto gesperrt werden?

Brute-Force-Schutz kann durch Rate Limiting, progressive Verzögerungen, temporäre Sperren oder zusätzliche Authentisierung umgesetzt werden. Eine harte dauerhafte Sperre nach wenigen Fehlversuchen kann allerdings selbst für Denial-of-Service missbraucht werden.

Die Lösung sollte Angriffe erschweren, ohne legitime Nutzer leicht aussperren zu lassen. Auch dieser Trade-off gehört in den Testplan.

Wie behandelt man privilegierte Aktionen?

Änderungen an Rollen, Schlüsseln, Sicherheitsoptionen, Updatequellen oder Netzwerkregeln verdienen besonderen Schutz. Möglich sind erneute Authentisierung, Vier-Augen-Freigaben in B2B-Systemen oder zusätzliche Warnungen.

Mindestens sollten solche Aktionen manipulationsgeschützt protokolliert werden. So lassen sich spätere Vorfälle nachvollziehen.

Was ist bei Multi-Tenant-Produkten wichtig?

Bei mandantenfähigen Produkten ist die Trennung zwischen Kunden ein zentrales Sicherheitsziel. Jeder Datenzugriff und jede administrative Funktion muss den Tenant-Kontext korrekt erzwingen. Fehler in dieser Ebene können zu massenhaften Datenoffenlegungen führen.

Tests sollten gezielt versuchen, IDs, Tokens oder Rollen zwischen Mandanten zu verwenden. Die Isolation gehört in die Risikobewertung und technische Dokumentation.

Wie geht man mit Offline-Geräten um?

Auch Offline-Geräte können unberechtigten Zugriff erleiden. Physische Schnittstellen, lokale Administratorfunktionen, Wartungsports und gespeicherte Credentials müssen deshalb betrachtet werden. Physischer Besitz eines Geräts darf nicht automatisch vollständige administrative Kontrolle bedeuten, wenn das Risikomodell dies nicht zulässt.

Je nach Produkt können Hardware-Schutz, PIN, Schlüssel, sichere Bootmechanismen oder deaktivierbare Wartungsschnittstellen relevant sein.

Wie testet man Zugriffsschutz?

Der Testplan sollte Anmeldung, Reset, Sessionverwaltung, Rollen, direkte API-Aufrufe, horizontale und vertikale Rechteausweitung, Servicekonten und Fernwartung umfassen. Zusätzlich werden Rate Limits, Konto-Sperren und Logging geprüft.

Der Artikel CRA Security Testing ordnet diese Prüfungen in das regelmäßige Testprogramm ein.

Wie dokumentiert man Identity & Access Management?

Hilfreich sind eine Liste der Identitätstypen, Rollenmatrix, Authentisierungsverfahren, Sessionkonzept, Servicekonto-Lifecycle, Fernwartungsregeln und Testnachweise. Die Dokumentation sollte erklären, welche Risiken jeweils adressiert werden.

Bei Änderungen an Rollen oder Authentisierung ist die technische Dokumentation gegebenenfalls zu aktualisieren.

Welche typischen Fehler treten auf?

• Frontend blendet Funktionen aus, Backend prüft Rechte nicht.
• Ein einziges Administratorkonto wird von mehreren Personen geteilt.
• Servicekonten haben globale Rechte ohne Notwendigkeit.
• Tokens bleiben nach Logout oder Rollenentzug gültig.
• Resetprozesse sind schwächer als der Login.
• Fernwartung ist dauerhaft aktiv und schlecht protokolliert.
• Fehlgeschlagene oder verdächtige Zugriffe erzeugen keinen Hinweis.

Wie können KMU Zugriffsschutz strukturiert aufbauen?

Ein pragmatischer Start besteht aus einem Identitätsinventar und einer Rollenmatrix. Danach werden für jeden Zugang Authentisierung, Rechte, Credential-Speicherung, Widerruf und Logging festgelegt. Kritische Fernzugriffe werden separat betrachtet.

Diese Baseline lässt sich bei jedem Release automatisiert oder manuell prüfen. So wird Zugriffsschutz nicht zu einer Sammlung historisch gewachsener Sonderfälle.

Wie schützt man Credentials im Produkt?

Passwörter sollten nicht im Klartext gespeichert werden; private Schlüssel und API-Secrets brauchen ebenfalls einen angemessenen Schutz. Welche Technik nötig ist, hängt von Plattform und Angreifermodell ab. Hardwarebasierte Schlüsselspeicher können bei bestimmten Geräten sinnvoll sein, sind aber keine universelle Pflicht.

Entscheidend ist, dass ein kompromittierter Benutzerkontext oder Dateizugriff nicht automatisch alle langfristigen Geheimnisse offenlegt. Schlüsselschutz und Rotation gehören deshalb mit in das Sicherheitsdesign.

Welche Rolle spielt Provisionierung?

Geräte- oder Serviceidentitäten müssen sicher erzeugt und dem richtigen Produkt zugeordnet werden. Unsichere Provisionierung kann starke Kryptografie später vollständig aushebeln. Besonders in Fertigung und Lieferkette sollte klar sein, wer Credentials erzeugt, überträgt und aktivieren darf.

Test- und Produktionsschlüssel müssen getrennt sein. Auch ausgeschleuste oder reparierte Geräte brauchen definierte Verfahren.

Wie reagiert man auf kompromittierte Konten?

Der Hersteller sollte einen Prozess für schnelle Sperrung, Tokenwiderruf, Credentialwechsel und Analyse haben. Bei Hersteller- oder Servicekonten kann ein einzelner Kompromittierungsfall viele Produkte betreffen, weshalb zentrale Revocation-Fähigkeiten besonders wichtig sein können.

Hinweise aus Logs sollten in den Schwachstellen- oder Incident-Prozess überführt werden, wenn ein Produktproblem zugrunde liegt.

Wie werden Konten sicher außer Betrieb genommen?

Identitäten brauchen neben Onboarding auch ein definiertes Offboarding. Verlässt ein Mitarbeiter, Kunde oder Dienst die zulässige Nutzung, müssen Konten deaktiviert, Sessions beendet, Tokens widerrufen und gegebenenfalls geteilte Geheimnisse ersetzt werden. Bei Geräteidentitäten kann zusätzlich eine Entkopplung vom Backend erforderlich sein.

Besonders wichtig sind technische Konten, die nicht im normalen Benutzerverzeichnis sichtbar sind. Serviceaccounts, CI/CD-Credentials oder Integrationsschlüssel bleiben sonst nach organisatorischen Änderungen unbemerkt aktiv.

Wie behandelt man API-Keys und Automatisierungszugänge?

API-Keys sind Identitäten und sollten nicht wie dauerhaft gültige Passwörter ohne Lifecycle behandelt werden. Sinnvoll sind eindeutige Zuordnung, minimale Berechtigungen, Ablauf oder Rotation, sichere Speicherung und die Möglichkeit zum sofortigen Widerruf. Ein Schlüssel sollte möglichst nicht von mehreren unabhängigen Systemen geteilt werden.

Für Integrationen kann außerdem ein Berechtigungsmodell auf einzelne Funktionen oder Datenbereiche begrenzen, was der Schlüssel tatsächlich tun darf. So reduziert ein kompromittierter Integrationszugang seinen möglichen Schaden.

Was ist ein Break-Glass-Zugang?

Ein Break-Glass-Zugang dient seltenen Notfällen, wenn normale Administrationswege nicht verfügbar sind. Gerade weil er besonders mächtig ist, braucht er strengere Kontrollen: sichere Verwahrung, begrenzten Personenkreis, dokumentierte Aktivierung, unmittelbares Logging und Überprüfung nach jeder Nutzung.

Ein dauerhaft aktives universelles Masterpasswort ist kein guter Break-Glass-Prozess. Der Notfallzugang sollte so gestaltet sein, dass seine Nutzung auffällt und anschließend Credentials oder Freigaben erneuert werden können.

Wie werden Berechtigungen regelmäßig überprüft?

Rollen und Rechte verändern sich mit dem Produkt. Ein regelmäßiges Access Review sollte prüfen, ob administrative Rechte noch benötigt werden, verwaiste Konten existieren und neue Funktionen versehentlich bestehenden Rollen zu viel Zugriff geben. Bei B2B-Systemen können solche Reviews auch vom Kundenadministrator unterstützt werden.

Der Review muss nicht täglich stattfinden. Ein risikobasierter Rhythmus sowie anlassbezogene Prüfungen nach Rollen-, Personal- oder Architekturänderungen sind häufig praktikabler.

Wie sollte man Zugriffsrechte nach Produktänderungen neu bewerten?

Neue Funktionen verändern häufig unbemerkt das Berechtigungsmodell. Ein vorhandener Operator darf vielleicht plötzlich Daten exportieren, ein Servicekonto erhält Zugriff auf eine neue API oder ein Administrator kann neue Schlüssel verwalten. Deshalb sollte jede sicherheitsrelevante Funktion einen kurzen Rollen- und Rechtecheck auslösen.

Besonders wichtig ist die Rückwärtskompatibilität. Alte Rollen dürfen durch neue Standardzuordnungen nicht automatisch mehr Rechte erhalten, als ursprünglich vorgesehen war. Ein Regressionstest für zentrale Berechtigungen schützt vor genau solchen schleichenden Erweiterungen.

Wie sollte ein Berechtigungsreview praktisch ablaufen?

In regelmäßigen Abständen sollte geprüft werden, welche Rollen und Servicekonten tatsächlich noch benötigt werden. Dabei werden überhöhte Rechte, verwaiste Konten, alte API-Zugänge und ungenutzte Administrationspfade entfernt oder eingeschränkt. Besonders nach Personalwechseln, neuen Integrationen oder größeren Produktupdates ist ein solcher Review sinnvoll. Die Entscheidung sollte dokumentiert werden, damit später nachvollziehbar bleibt, warum bestimmte Berechtigungen bestehen und wann sie zuletzt überprüft wurden.

Wo steht die Zugriffsschutz-Anforderung im CRA?

Die ausdrückliche Grundlage findet sich in Anhang I Teil I Nummer 2 Buchstabe d der Verordnung (EU) 2024/2847. Dort werden Schutz vor unberechtigtem Zugriff, Authentisierung, Identitäts- und Zugriffsmanagement sowie die Meldung möglicher unberechtigter Zugriffe genannt.