Kurzantwort
Eine Privacy-IRM-Plattform benötigt ein Berechtigungssystem, das über die Unterscheidung zwischen „Admin“ und „User“ hinausgeht. Erforderlich sind insbesondere rollenbasierte, objektbezogene, mandantenfähige und statusabhängige Rechte. Nutzer sollten nur auf diejenigen Informationen und Funktionen zugreifen können, die sie für ihre jeweilige Aufgabe benötigen. Dies gilt etwa für Verarbeitungstätigkeiten, Risiken, Dienstleister, Vorfälle, Datenschutz-Folgenabschätzungen, AI-Use-Cases, Maßnahmen und Freigaben.
Zu berücksichtigen sind darüber hinaus temporäre Berechtigungen, geregelte Administrationsprozesse, eine nachvollziehbare Protokollierung, regelmäßige Rechteprüfungen und eine belastbare Anbindung an das Identity and Access Management.
Datenschutzsoftware enthält sensible Unternehmensinformationen
Datenschutzsoftware dient regelmäßig der Dokumentation und Steuerung von Verarbeitungstätigkeiten, technischen und organisatorischen Maßnahmen, Auftragsverarbeitern, Betroffenenanfragen, Datenschutzvorfällen, Datenschutz-Folgenabschätzungen, Löschfristen und entsprechenden Nachweisen.
Eine Privacy-IRM-Plattform enthält damit jedoch nicht lediglich Verwaltungsdaten. In ihr werden regelmäßig sensible Informationen über die Datenschutz-, Risiko- und Governance-Strukturen eines Unternehmens verarbeitet.
Die Plattform kann erkennen lassen, welche Systeme personenbezogene Daten verarbeiten, welche Dienstleister eingebunden sind und welche Risiken, Schwachstellen oder offenen Maßnahmen bestehen. Hinzu kommen gegebenenfalls Informationen über Vorfälle, Beschwerden, unklare Rechtsgrundlagen, internationale Datenübermittlungen und interne Entscheidungen. Bei AI-Governance-Prozessen können weitere Angaben zu KI-Use-Cases, Datenquellen, Modellen, Anbietern, Risikoklassen, Freigabebedingungen, Monitoring, Human Oversight und möglichen Auswirkungen auf Betroffene enthalten sein.
Vor diesem Hintergrund ist auch die Privacy-IRM-Plattform selbst als schützenswertes System zu betrachten. Werden Zugriffsrechte zu weit gefasst, können Personen Informationen einsehen, die für ihre konkrete Aufgabe nicht erforderlich sind. Rollen und Rechte sind deshalb nicht lediglich eine Frage der Benutzeradministration, sondern ein wesentlicher Bestandteil der Sicherheits- und Governance-Architektur einer solchen Plattform.
Datenschutzsoftware kann selbst ein Datenschutz- und Sicherheitsrisiko begründen
Ein Datenschutzmanagementsystem soll Unternehmen dabei unterstützen, Risiken zu erkennen, zu bewerten und zu steuern. Gleichzeitig können durch das System selbst Risiken entstehen, wenn Berechtigungen zu weitgehend, dauerhaft oder nicht ausreichend kontrolliert vergeben werden.
Ein Fachbereich kann beispielsweise Zugriff auf die von ihm verantworteten Verarbeitungstätigkeiten benötigen. Daraus folgt jedoch nicht ohne Weiteres, dass auch sämtliche Verarbeitungstätigkeiten anderer Unternehmensbereiche einsehbar sein müssen. Ein lokaler Datenschutzkoordinator benötigt gegebenenfalls Zugriff auf die ihm zugeordnete Gesellschaft oder den jeweiligen Standort, nicht jedoch zwingend auf vertrauliche Vorfälle anderer Gesellschaften.
Entsprechendes gilt für weitere Rollen. Legal benötigt insbesondere Informationen mit Vertrags- und Haftungsbezug. IT Security benötigt technische Angaben. Das Management benötigt regelmäßig verdichtete Risiko- und Entscheidungsinformationen. Ein externer Datenschutzbeauftragter benötigt Zugriff auf die für seine Tätigkeit relevanten Vorgänge, ohne dass daraus automatisch ein uneingeschränkter Zugriff auf sämtliche im System dokumentierten Inhalte folgt.
Die DSGVO verlangt bei der Sicherheit der Verarbeitung geeignete technische und organisatorische Maßnahmen, mit denen ein dem Risiko angemessenes Schutzniveau gewährleistet wird. Zu berücksichtigen sind dabei insbesondere Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme sowie Risiken einer unbefugten Offenlegung oder eines unbefugten Zugangs.
Diese Anforderungen sind nicht nur für diejenigen Systeme relevant, die innerhalb des Verzeichnisses von Verarbeitungstätigkeiten dokumentiert werden. Sie sind auch bei dem System zu berücksichtigen, in dem Verarbeitungstätigkeiten, Risiken, Vorfälle und Maßnahmen selbst verwaltet werden.
Least Privilege in Privacy Operations
Das Prinzip des Least Privilege sieht vor, Zugriffsrechte auf dasjenige Maß zu beschränken, das für die Erfüllung einer konkreten Aufgabe erforderlich ist. NIST beschreibt Least Privilege entsprechend als Sicherheitsprinzip, nach dem Zugriffsrechte auf das für die jeweilige Aufgabenerfüllung notwendige Minimum begrenzt werden.
Für Privacy Operations bedeutet dies, dass Rollen nicht allein aus Gründen der Vereinfachung mit umfassenden Rechten ausgestattet werden sollten.
Ob ein Fachbereich umfassende Einsichtsrechte benötigt, ist ebenso zu prüfen wie die Frage, ob ein Datenschutzkoordinator organisationsweit Schreibrechte erhalten muss oder Legal standardmäßig auf sämtliche Vorgänge zugreifen sollte. Abhängig vom jeweiligen Aufgabenbereich können weitergehende Zugriffe erforderlich sein. Sie sollten jedoch nicht ohne Prüfung als Standard vorgesehen werden.
Least Privilege soll die Aufgabenerfüllung nicht unnötig erschweren. Maßgeblich ist vielmehr, welche Informationen und welche Aktionen eine Rolle tatsächlich benötigt, um die ihr zugewiesenen Aufgaben wahrnehmen zu können.
Ein Rollenmodell allein reicht regelmäßig nicht aus
Viele Systeme verfügen über ein Rollenmodell. Die bloße Existenz von Rollen sagt allerdings noch wenig darüber aus, wie differenziert Zugriffe tatsächlich gesteuert werden können.
Ein Modell, das lediglich zwischen Administrator, Manager, User und Read-only unterscheidet, dürfte für komplexe Privacy-IRM-Prozesse regelmäßig nicht ausreichen. Die Rolle allein beantwortet insbesondere nicht, auf welches Objekt sich eine Berechtigung bezieht, für welchen Mandanten sie gilt, welchen Status ein Vorgang aufweist und welche konkrete Aktion zulässig ist.
Ein Nutzer kann beispielsweise Owner einer Verarbeitungstätigkeit und gleichzeitig Reviewer einer Maßnahme sein. In einer anderen Gesellschaft darf dieselbe Person möglicherweise ausschließlich lesend zugreifen. Für einen bestimmten Datenschutzvorfall kann vorübergehend eine zusätzliche Berechtigung erforderlich sein. Im Rahmen eines Freigabeprozesses kann ein Nutzer kommentieren dürfen, ohne selbst über die Freigabe entscheiden zu können. Ein Auditor kann Nachweise einsehen, ohne diese verändern zu dürfen.
Solche Konstellationen sind insbesondere in größeren Organisationen regelmäßig zu berücksichtigen. Eine Privacy-IRM-Plattform benötigt deshalb neben Rollen eine Rechtearchitektur, die unterschiedliche Zugriffsdimensionen miteinander verbindet.
Rechte nach Rollen, Objekten, Mandanten, Status und Aktionen
Eine belastbare Berechtigungslogik sollte mehrere Dimensionen berücksichtigen.
Zu prüfen ist zunächst die Rolle des Nutzers. Dabei kann es sich beispielsweise um einen Fachbereichs-Owner, Datenschutzbeauftragten, Legal Reviewer, IT-Security-Reviewer, eine Managementrolle, einen Auditor, einen externen Berater oder einen Administrator handeln.
Daneben ist das jeweilige Objekt maßgeblich. Ein Zugriff kann sich etwa auf eine Verarbeitungstätigkeit, einen Dienstleister, ein System, eine Maßnahme, einen Vorfall, eine Betroffenenanfrage, eine Datenschutz-Folgenabschätzung, einen AI-Use-Case, ein Risiko oder einen Bericht beziehen.
Weiterhin ist der organisatorische Kontext zu berücksichtigen. Ein Objekt kann einer Gesellschaft, einem Standort, einer Business Unit, einem Projekt oder einem Team zugeordnet sein. Je nach Organisationsstruktur können mehrere dieser Ebenen gleichzeitig relevant sein.
Auch der Status des Vorgangs kann die zulässigen Aktionen beeinflussen. Zu unterscheiden sind etwa Entwurf, Prüfung, Rückgabe, Freigabe, Eskalation, Abschluss oder Archivierung.
Schließlich ist zu bestimmen, welche Aktion die betreffende Rolle ausführen darf. Dazu gehören insbesondere Lesen, Bearbeiten, Kommentieren, Prüfen, Freigeben, Ablehnen, Eskalieren, Exportieren, Löschen oder die Vergabe von Rechten.
Erst aus dem Zusammenspiel dieser Dimensionen lässt sich ein Berechtigungssystem ableiten, das den jeweiligen Governance-Prozess angemessen abbildet.
Ein Fachbereichs-Owner kann beispielsweise eine Verarbeitungstätigkeit in seiner Gesellschaft bearbeiten, solange sie sich im Entwurfsstatus befindet. Nach der Einreichung zur Prüfung kann es erforderlich sein, Änderungen einzuschränken. Rückfragen und Ergänzungen müssen weiterhin möglich sein, während die eigentliche Freigabe dem zuständigen Reviewer oder Approver vorbehalten bleibt. Nach Abschluss sollte zudem geregelt werden, auf welchem Weg Änderungen an einer bereits freigegebenen Version vorgenommen werden können.
Die Berechtigungsmatrix als Prüfgrundlage
Bei der Auswahl einer Privacy-IRM-Plattform sollte deshalb nicht lediglich gefragt werden, ob das System Rollen unterstützt. Aussagekräftiger ist die Frage, ob Rollen nach Aktionen, Objekten, Mandanten, Status und Freigaben gesteuert werden können.
Eine vereinfachte Berechtigungsmatrix kann beispielsweise wie folgt aufgebaut sein:
Eine solche Tabelle stellt kein allgemeingültiges Berechtigungskonzept dar. Sie verdeutlicht jedoch, dass Rollen nicht isoliert betrachtet werden sollten, sondern im Zusammenhang mit Objekten, Aktionen, Status und Organisationseinheiten.
Statusabhängige Rechte sichern den Prozessverlauf
Ein weiterer relevanter Aspekt sind statusabhängige Rechte. Ein Vorgang verändert während seines Lebenszyklus seinen fachlichen und organisatorischen Zustand. Damit kann sich zugleich ändern, welche Personen welche Aktionen vornehmen dürfen.
Eine Verarbeitungstätigkeit im Entwurf ist anders zu behandeln als eine bereits freigegebene Verarbeitungstätigkeit. Entsprechendes gilt für einen AI-Use-Case während der Erfassung gegenüber einem produktiv eingesetzten Use Case mit Freigabebedingungen, für eine Maßnahme im Entwurf gegenüber einer überfälligen kritischen Maßnahme oder für einen Datenschutzvorfall während der Erstbewertung gegenüber einem abgeschlossenen Vorfall mit dokumentierter Meldeentscheidung.
Das Berechtigungskonzept sollte deshalb insbesondere regeln, wer einen Entwurf verändern darf, welche Bearbeitungsmöglichkeiten nach der Einreichung bestehen und unter welchen Voraussetzungen eine bereits freigegebene Bewertung geändert oder erneut geöffnet werden darf. Ebenfalls zu bestimmen ist, wer Freigaben widerrufen, eskalierte Vorgänge schließen oder Maßnahmen als erledigt kennzeichnen kann.
Fehlen entsprechende Regeln, können Nutzer den Prozesszustand unbeabsichtigt oder bewusst verändern, obwohl die jeweilige Prozessphase dies nicht vorsieht. Eine nachträgliche Protokollierung allein ersetzt in diesem Fall keine angemessene Zugriffskontrolle.
Objektbezogene Zugriffe statt pauschaler Vollzugriffe
Für Privacy-IRM-Systeme ist regelmäßig die Möglichkeit erforderlich, Zugriffe auf einzelne Objekte zu beschränken.
Muss ein Fachbereich beispielsweise eine bestimmte Verarbeitungstätigkeit aktualisieren, folgt daraus nicht, dass sämtliche Verarbeitungstätigkeiten des Unternehmens einsehbar sein müssen. Ein externer Auditor kann bestimmte Nachweise prüfen müssen, ohne deshalb Zugriff auf alle Risiken, Vorfälle und Betroffenenanfragen zu benötigen. Gleiches gilt für einen lokalen Ansprechpartner, der bei einer bestimmten Datenschutz-Folgenabschätzung mitwirkt.
Eine Plattform sollte deshalb objektbezogene Zugriffseinladungen ermöglichen. Denkbar ist beispielsweise, einer Person ausschließlich die Bearbeitung einer konkreten Verarbeitungstätigkeit, die Kommentierung einer bestimmten Maßnahme, den lesenden Zugriff auf ausgewählte Nachweise oder die Mitarbeit an einem konkreten AI-Use-Case zu gestatten.
Damit kann Zusammenarbeit ermöglicht werden, ohne gleichzeitig umfassende Systemrechte vergeben zu müssen.
Temporäre Berechtigungen
Zahlreiche Zugriffe werden nur für einen begrenzten Zeitraum benötigt. Dies betrifft beispielsweise Auditoren, externe Berater, Fachbereichsmitarbeiter im Rahmen einer Betroffenenanfrage, Legal bei einer konkreten Vertragsprüfung oder IT Security bei der Bewertung eines Systems. Auch bei Datenschutzvorfällen kann für ein Incident-Team vorübergehend ein zusätzlicher Zugriff erforderlich sein.
Solche Berechtigungen sollten nicht automatisch dauerhaft bestehen bleiben.
Temporäre Rechte sollten daher mit einem Ablaufdatum versehen werden können. Darüber hinaus ist zu berücksichtigen, ob eine Begründung, Protokollierung und automatische Entziehung nach Abschluss eines Vorgangs oder Ablauf einer Frist vorgesehen werden kann.
In der Praxis kann ein Berechtigungsrisiko insbesondere dann entstehen, wenn ein ursprünglich gerechtfertigter Zugriff nach Wegfall seines Zwecks nicht wieder entzogen wird.
Geführte Fachbereichszugriffe
Datenschutzmanagement setzt regelmäßig die Mitwirkung der Fachbereiche voraus. Sie müssen Informationen bereitstellen, Verarbeitungstätigkeiten aktualisieren, Maßnahmen umsetzen, Rückfragen beantworten und Freigabeprozesse unterstützen.
Eine Privacy-IRM-Plattform sollte deshalb nicht ausschließlich auf Datenschutzexperten ausgerichtet sein. Gleichzeitig ist zu vermeiden, dass Fachbereiche mit für ihre Aufgaben nicht erforderlichen Informationen, Feldern oder Rechten ausgestattet werden.
Ein geeignetes Rechtekonzept kann Fachbereichszugriffe gezielt führen. Nutzer sehen dabei die ihnen zugeordneten Vorgänge und diejenigen Angaben, für deren Bearbeitung sie verantwortlich sind. Rückfragen, Aufgaben, Änderungsmöglichkeiten, Statusinformationen und Fristen können innerhalb dieses Umfangs bereitgestellt werden, ohne dass ein umfassender Zugriff auf die gesamte Datenschutzorganisation erforderlich ist.
Dies kann sowohl die Zugriffssicherheit als auch die praktische Nutzung des Systems unterstützen. Maßgeblich ist, dass die Mitarbeit am jeweils relevanten Objekt ermöglicht wird, ohne weitergehende Berechtigungen als erforderlich einzuräumen.
Administrative Rollen differenzieren
Administratorrechte sind wegen ihres regelmäßig weitreichenden Umfangs besonders zu berücksichtigen.
In manchen Systemen werden technische Administration und fachlicher Vollzugriff miteinander verbunden. Wer Nutzer anlegen oder Felder konfigurieren kann, erhält dadurch gegebenenfalls zugleich Zugriff auf fachliche Inhalte wie Datenschutzvorfälle oder Verarbeitungstätigkeiten.
Eine solche Kopplung ist nicht zwingend erforderlich. Eine Privacy-IRM-Plattform sollte vielmehr unterschiedliche administrative Aufgaben abbilden können.
Technische Administratoren benötigen nicht automatisch fachlichen Vollzugriff. Fachadministratoren müssen nicht zwingend sämtliche Systemkonfigurationen verändern können. Security-Administratoren können andere Berechtigungen benötigen als Datenschutzadministratoren. Auch Supportzugriffe des Anbieters sollten sachlich und zeitlich begrenzt sowie nachvollziehbar protokolliert werden können.
Insbesondere in größeren Organisationen kann eine solche Trennung dazu beitragen, privilegierte Zugriffe auf das erforderliche Maß zu beschränken und deren Prüfung zu erleichtern.
IAM-Anbindung als Bestandteil des Betriebsmodells
Die Anbindung an ein Identity and Access Management ist bei einer Privacy-IRM-Plattform nicht lediglich eine Komfortfunktion. Sie ist für die dauerhafte Verwaltung von Nutzern und Berechtigungen von erheblicher Bedeutung.
Werden Rollen und Nutzer ausschließlich manuell innerhalb der Datenschutzsoftware gepflegt, können Abweichungen zwischen der tatsächlichen Organisationsstruktur und den hinterlegten Zugriffsrechten entstehen. Mitarbeiter wechseln ihre Funktion, externe Personen verlassen Projekte, Gesellschaften oder Teams werden umstrukturiert und Nutzer scheiden aus dem Unternehmen aus.
Werden solche Änderungen nicht in der Privacy-IRM-Plattform nachvollzogen, können nicht mehr erforderliche Berechtigungen bestehen bleiben.
Je nach Organisation kommen deshalb insbesondere Single Sign-on, die Übernahme von Gruppen und Rollen, automatisiertes Provisioning und Deprovisioning, die Unterstützung externer Nutzer, regelmäßige Rechteprüfungen sowie die Protokollierung privilegierter Zugriffe in Betracht.
Die technische Anbindung allein reicht allerdings nicht aus. Auch das zugrunde liegende Rollenmodell muss sachgerecht ausgestaltet sein. Ungeeignet zugeschnittene IAM-Gruppen führen ansonsten lediglich dazu, dass zu weitgehende Berechtigungen automatisiert in ein weiteres System übertragen werden.
IAM-Gruppen, Plattformrollen und Governance-Rollen sollten daher aufeinander abgestimmt werden.
Regelmäßige Rechteprüfungen
Ein Berechtigungssystem muss während des gesamten Betriebs überprüft und angepasst werden. Rollen verändern sich, Projekte enden, Verantwortlichkeiten wechseln und externe Personen benötigen nach Abschluss ihrer Tätigkeit keinen weiteren Zugriff.
Eine Privacy-IRM-Plattform sollte deshalb regelmäßige Überprüfungen von Berechtigungen unterstützen.
Dabei stellt sich beispielsweise die Frage, welche Nutzer auf kritische Vorfälle zugreifen können, wer über Exportrechte verfügt, wer Freigaben erteilen darf und welche Personen administrative Berechtigungen besitzen. Ebenso sind temporäre Rechte, inaktive Nutzerkonten, fortbestehende externe Konten und möglicherweise zu weit gefasste Rollen zu berücksichtigen.
Eine Plattform kann solche Prüfungen unterstützen, indem sie entsprechende Berichte, Prüfworkflows und Nachweise bereitstellt. Die regelmäßige Überprüfung von Zugriffsrechten ist damit selbst ein Bestandteil des Datenschutz- und Governance-Betriebs.
Besondere Anforderungen an Exportrechte
Bei der Ausgestaltung eines Berechtigungssystems sind neben Lese- und Bearbeitungsrechten insbesondere Exportrechte zu berücksichtigen.
Durch einen Export können sensible Informationen aus dem kontrollierten Umfeld der Plattform herausgelöst werden. Die innerhalb der Plattform geltenden Rollen, Statusregeln und Zugriffsbeschränkungen wirken auf die exportierten Daten anschließend nicht ohne Weiteres in gleicher Weise fort.
Exportrechte sollten deshalb gesondert geregelt werden. Ein Leserecht muss nicht zugleich ein Exportrecht umfassen. Ebenso kann es erforderlich sein, Exporte auf bestimmte Datenbestände, Mandanten oder Gesellschaften zu beschränken. Bei besonders sensiblen Daten können eine Protokollierung oder zusätzliche Freigabeprozesse in Betracht kommen.
Für unterschiedliche Zwecke können unterschiedliche Informationsumfänge erforderlich sein. Das Management benötigt gegebenenfalls eine verdichtete Sicht, während für Audits detailliertere Nachweise erforderlich sein können. Fachbereiche wiederum benötigen regelmäßig nur einen begrenzten Ausschnitt.
Bei der Rechtegestaltung ist daher nicht nur zu prüfen, wer Informationen innerhalb des Systems einsehen darf, sondern auch, wer sie aus dem System exportieren kann.
Berechtigungen bei AI Governance
Mit AI-Governance-Prozessen können sich zusätzliche Anforderungen an die Zugriffskontrolle ergeben.
Ein AI-Use-Case kann Angaben über Modelle, Anbieter, Datenquellen, Risiken, Einsatzbereiche, Nutzergruppen, Human Oversight, Freigabebedingungen und Monitoring enthalten. Nicht jede dieser Informationen ist für jede Rolle erforderlich.
Ein Fachbereich kann beispielsweise den eigenen Use Case bearbeiten. IT Security benötigt gegebenenfalls Zugriff auf technische Informationen, Legal auf Anbieter- und Vertragsangaben und der Datenschutz auf Informationen zum Personenbezug sowie zu Risiken für Betroffene. Das Management benötigt demgegenüber möglicherweise insbesondere Status- und Risikoinformationen.
Werden AI-Funktionen unmittelbar in eine Governance-Plattform integriert, muss das Berechtigungsmodell auch für diese Funktionen gelten. Ein AI-Agent sollte nur auf diejenigen Informationen zugreifen und diejenigen Aktionen ausführen können, die für die Rolle des jeweiligen Nutzers und im konkreten Prozesskontext zulässig sind.
Die Nutzung eines AI-Agents darf daher nicht dazu führen, bestehende Rollen-, Objekt- oder Statusbeschränkungen zu umgehen. Ebenso ist bei erzeugten Zusammenfassungen oder vorbereiteten Aktionen zu berücksichtigen, welche Informationen die anfragende Rolle tatsächlich sehen und verarbeiten darf.
Zusammenspiel von Mandantenfähigkeit und Rollenmodell
Mandantenfähigkeit und Berechtigungssteuerung sind gemeinsam zu betrachten. Während die Mandantenstruktur organisatorische Einheiten voneinander trennt, bestimmt das Rollenmodell, welche Zugriffe innerhalb dieser Einheiten und gegebenenfalls übergreifend zulässig sind.
Eine Konzernzentrale kann beispielsweise ein übergreifendes Reporting benötigen, während einzelne Gesellschaften ihre operativen Vorgänge eigenständig bearbeiten. Eine Business Unit kann Informationen über mehrere Gesellschaften hinweg benötigen, ein Standort hingegen nur lokale Maßnahmen. Projektteams können wiederum Zugriff auf einzelne AI-Use-Cases erhalten. Für einen Konzern-Datenschutzbeauftragten kann eine übergreifende, risikoorientierte Sicht erforderlich sein.
Eine ausschließlich harte Mandantentrennung kann deshalb ebenso unzureichend sein wie ein zu weit gefasstes Rollenmodell, das bestehende organisatorische Grenzen faktisch aufhebt.
Für größere Organisationen sollten Mandanten, Objekte, Rollen, Berechtigungen und Reportingfunktionen deshalb aufeinander abgestimmt werden.
Berechtigungskonzept in Ailance
Eine Privacy-IRM-Plattform sollte insbesondere folgende Funktionen unterstützen:
| Anforderung | Bedeutung |
|---|---|
| Rollenbasierte Zugriffskontrolle | Rollen bilden typische Aufgaben ab und begrenzen pauschale Rechte. |
| Objektbezogene Rechte | Zugriffe können auf konkrete Verarbeitungstätigkeiten, Risiken, Maßnahmen oder Vorfälle beschränkt werden. |
| Mandanten- und Gesellschaftsbezug | Gesellschaften, Länder oder Organisationseinheiten können getrennt gesteuert und ausgewertet werden. |
| Statusabhängige Rechte | Entwurf, Prüfung, Freigabe, Eskalation und Abschluss können mit unterschiedlichen Berechtigungen verbunden werden. |
| Aktionsbasierte Rechte | Lesen, Bearbeiten, Prüfen, Freigeben, Eskalieren, Exportieren und Löschen werden getrennt gesteuert. |
| Temporäre Berechtigungen | Projekt-, Audit- oder Incident-Zugriffe können befristet und anschließend entzogen werden. |
| Feld- oder Bereichsbeschränkungen | Besonders sensible Informationen können zusätzlich geschützt werden. |
| Delegation und Stellvertretung | Vertretungen können eingerichtet werden, ohne dauerhaft weitergehende Rechte zu vergeben. |
| Admin-Trennung | Technische Administration und fachlicher Vollzugriff können voneinander getrennt werden. |
| IAM-/SSO-Anbindung | Nutzer, Gruppen und Rollen lassen sich mit der Unternehmensidentität verbinden. |
| Rechteprüfung und Rezertifizierung | Zugriffsrechte können regelmäßig überprüft und dokumentiert werden. |
| Audit Trail für Berechtigungen | Änderungen an Rollen, Rechten und Zugriffen bleiben nachvollziehbar. |
| Exportkontrolle | Datenexporte können gesondert geregelt, protokolliert und begrenzt werden. |
| Berechtigungen für AI-Agents | AI-Funktionen bleiben an Rolle, Kontext und Prozess gebunden. |
Der Umfang dieser Anforderungen ergibt sich aus der Art der in einer Privacy-IRM-Plattform verarbeiteten Informationen. Das System enthält regelmäßig zentrale Informationen über Datenschutz-, Risiko- und Governance-Prozesse eines Unternehmens und sollte entsprechend geschützt werden.
Berechtigungskonzept in Ailance
Ailance ist als Plattform für Governance-Prozesse angelegt. Das Rechtekonzept sollte deshalb an den innerhalb der Plattform verwalteten Governance-Objekten und Prozessen ausgerichtet sein.
Eine Verarbeitungstätigkeit, ein Risiko, ein Dienstleister, ein System, ein AI-Use-Case oder eine Maßnahme sind dabei nicht lediglich einzelne Datensätze. Sie stehen in Beziehung zu Rollen, Status, Verantwortlichkeiten, Freigaben und Nachweisen.
Daraus folgt, dass auch Zugriffsrechte objekt- und prozessbezogen ausgestaltet sein sollten.
Für einen konkreten Zugriff ist daher unter anderem zu bestimmen, welche Rolle ein Nutzer besitzt, in welchem Mandanten er handelt, auf welches Objekt sich die Aktion bezieht, welchen Status dieses Objekt aufweist und welche konkrete Handlung vorgenommen werden soll. Daneben kann relevant sein, ob erforderliche Freigaben vorliegen, ob ein Zugriff dauerhaft oder temporär erteilt wurde und ob sensible Informationen exportiert werden sollen.
Auch die Protokollierung oder Eskalation bestimmter Aktionen kann Bestandteil dieser Steuerung sein.
Damit unterscheidet sich ein Governance-Berechtigungssystem von einer reinen Benutzerverwaltung, die im Wesentlichen nur feststellt, ob ein Nutzer angemeldet und einer bestimmten allgemeinen Rolle zugeordnet ist.
Praktische Prüfung bestehender Berechtigungen
Unternehmen sollten regelmäßig prüfen, ob bestehende Rollen und Berechtigungen noch dem tatsächlichen Aufgabenbedarf entsprechen. Als Ausgangspunkt kann insbesondere diejenige Rolle betrachtet werden, die derzeit über die weitreichendsten Rechte verfügt.
Dabei sollten unter anderem folgende Fragen geprüft werden:
- Besteht tatsächlich ein Bedarf für den Zugriff auf sämtliche Mandanten?
- Ist der Zugriff auf alle Objekte für die jeweilige Aufgabe erforderlich?
- Werden neben Leserechten auch Änderungsrechte benötigt?
- Ist ein Export der betreffenden Daten erforderlich?
- Wann wurden die zugewiesenen Berechtigungen zuletzt überprüft?
Lassen sich diese Fragen nicht nachvollziehbar beantworten, betrifft dies nicht nur die Benutzeradministration. Es kann zugleich auf einen Überprüfungsbedarf hinsichtlich der Sicherheit und Governance des Datenschutzmanagementsystems hinweisen.
Fazit
Rollen und Rechte sind bei einer Privacy-IRM-Plattform ein wesentlicher Bestandteil der System- und Governance-Architektur.
Die Plattform verarbeitet regelmäßig sensible Informationen über Verarbeitungstätigkeiten, Systeme, Daten, Risiken, Dienstleister, Vorfälle, Betroffene, Entscheidungen und Nachweise. Entsprechend ist auch der Zugriff auf diese Informationen angemessen zu begrenzen und nachvollziehbar zu steuern.
Zu berücksichtigen sind insbesondere das Prinzip des Least Privilege, objektbezogene Berechtigungen, mandantenbezogene Zugriffskontrollen, status- und aktionsabhängige Rechte, temporäre Zugriffe, gesonderte Exportberechtigungen, die Trennung administrativer Rollen sowie eine Anbindung an bestehende IAM-Strukturen.
Maßgeblich ist, dass Nutzer diejenigen Informationen und Funktionen erhalten, die sie für ihre jeweilige Aufgabe benötigen, ohne darüber hinausgehende Zugriffe dauerhaft oder pauschal einzuräumen. Ein belastbares Berechtigungssystem ist damit Voraussetzung dafür, dass eine Privacy-IRM-Plattform die Datenschutz- und Governance-Prozesse eines Unternehmens angemessen unterstützen kann.
Fragen und Antworten
Welche Rollen- und Rechtefunktionen braucht eine Privacy-IRM-Plattform?
Eine Privacy-IRM-Plattform benötigt rollenbasierte, objektbezogene, mandantenfähige, statusabhängige und aktionsbezogene Rechte. Hinzu kommen insbesondere temporäre Zugriffe, kontrollierte Exporte, eine Trennung administrativer Rollen, IAM-Anbindung, Audit Trails und regelmäßige Rechteprüfungen.
Warum kann Datenschutzsoftware selbst ein Datenschutzrisiko darstellen?
Datenschutzsoftware enthält regelmäßig sensible Informationen über Verarbeitungstätigkeiten, Systeme, Dienstleister, Risiken, Vorfälle, Maßnahmen und Entscheidungen. Werden Zugriffsrechte zu weit gefasst, können Vertraulichkeits- und Sicherheitsrisiken entstehen.
Was bedeutet Least Privilege in Privacy Operations?
Least Privilege bedeutet, dass Nutzer nur diejenigen Informationen und Aktionen erhalten, die sie für ihre konkrete Aufgabe benötigen. Die erforderlichen Rechte können sich deshalb beispielsweise für Fachbereiche, Reviewer, Datenschutzbeauftragte, Legal, IT Security, Management und externe Berater unterscheiden.
Warum reichen einfache Rollen wie Admin und User nicht aus?
Privacy-IRM-Prozesse erfordern regelmäßig eine differenziertere Steuerung. Neben der Rolle müssen insbesondere das jeweilige Objekt, der Mandant, der Status eines Vorgangs und die zulässige Aktion berücksichtigt werden.
Was sind objektbezogene Rechte?
Objektbezogene Rechte beschränken einen Zugriff auf konkrete Verarbeitungstätigkeiten, Risiken, Maßnahmen, Vorfälle, Dienstleister oder AI-Use-Cases. Dadurch kann eine gezielte Mitarbeit ermöglicht werden, ohne einen umfassenden Zugriff auf das gesamte System einzuräumen.
Warum sind temporäre Berechtigungen wichtig?
Viele Zugriffe werden nur für Projekte, Audits, Incidents oder einzelne Prüfungen benötigt. Eine zeitliche Begrenzung verhindert, dass ursprünglich erforderliche Berechtigungen nach Wegfall ihres Zwecks dauerhaft bestehen bleiben.
Welche Rolle spielt die IAM-Anbindung?
Eine IAM-Anbindung verbindet Nutzer, Gruppen und Rollen der Privacy-IRM-Plattform mit der bestehenden Identitäts- und Zugriffssteuerung des Unternehmens. Dadurch können insbesondere Rollenwechsel, Austritte sowie Provisioning und Deprovisioning zuverlässiger abgebildet werden.
Warum müssen Exportrechte besonders berücksichtigt werden?
Durch einen Export werden Daten aus dem kontrollierten Umfeld der Plattform herausgelöst. Deshalb sollten Exportrechte gesondert vergeben, begrenzt und protokolliert werden. Bei sensiblen Daten können zusätzliche Freigaben in Betracht kommen.
Wie hängen Mandantenfähigkeit und Berechtigungen zusammen?
Mandantenfähigkeit bildet die organisatorische Trennung von Einheiten ab. Das Berechtigungssystem regelt, wer innerhalb oder über diese Einheiten hinweg lesen, bearbeiten, prüfen, freigeben oder berichten darf. Beide Ebenen müssen aufeinander abgestimmt sein.
Was bedeutet eine statusabhängige Berechtigung?
Bei einer statusabhängigen Berechtigung richtet sich die zulässige Aktion nach dem aktuellen Zustand eines Vorgangs. Für einen Entwurf können deshalb andere Bearbeitungsrechte gelten als für einen freigegebenen, eskalierten oder abgeschlossenen Vorgang.
Was bedeutet Berechtigung für AI-Agents?
Ein AI-Agent sollte nur auf diejenigen Informationen zugreifen und diejenigen Aktionen ausführen können, die nach der jeweiligen Nutzerrolle, dem Objekt, dem Prozessstatus und dem Governance-Kontext zulässig sind. Bestehende Berechtigungsgrenzen dürfen durch AI-Funktionen nicht umgangen werden.
Welche Rollen können besonders weitreichende Rechte besitzen?
Je nach System und Organisation können insbesondere Administratoren, lokale Koordinatoren, Projektrollen oder historisch gewachsene Power-User-Rollen über weitreichende Berechtigungen verfügen. Diese Rechte sollten regelmäßig auf ihre fortbestehende Erforderlichkeit überprüft werden.
German 
English 
Italian 
French